Something I’ve not seen mentioned here yet is that one of the reasons it’s such an effective way to make money is specifically because loads of people are buying into it. When you buy a stock (or a derivative like an S&P 500 index tracking fund), it increases its price. If you’re just one person with a normal-person amount of money, it won’t be enough to register, but if you’re part of a group of millions of people, or an investor with billions at your disposal, it’ll make a visible difference, and if people see that happening consistently, they’ll want to join in and there’ll be a positive feedback loop. It only stops when there’s a big enough panic that lots of investors can no longer afford to maintain their investment and have to sell at the same time, and then you can even get a positive feedback loop in the other direction when people see the price plummeting and decide they need to sell before it plummets any further.
Stocks are supposed to represent the value of a company’s current assets and expected future profits, but this kind of feedback loop muddies the water. With something like Bitcoin, which intentionally has no inherent value, because enough people have agreed to pretend otherwise, it’s gained effective value, and can be exchanged for money, or in some cases, goods and services. That’ll remain the case until everyone agrees that they don’t want Bitcoin, so could go on forever.
Like other commenters have said, start by asking the upstream developer (whether that’s by sending a message with a link to the fork or by sending a mega-PR that says you don’t expect it to be merged as-is in the description). They should be the best judge of how they’d prefer to handle it. The thing I’d add is that you should try to avoid taking it personally if their preferred approach isn’t one you think is a good idea. Sometimes good fixes end up never merged because of disagreements becoming too heated even if everyone’s basically on the same page about the fox being good. There’s also a decent chance that your refactors are things the upstream developer explicitly doesn’t want and would otherwise have done them themselves and implemented the same fix, too, or they don’t agree that your fix is good enough. They won’t want to be on the hook for maintaining contributions that use approaches and code style that they don’t like, and that’s okay. They also might know something you don’t about their project that would make something that’s obviously a good idea to you obviously a bad idea to them.
Basically, just try and remember that if it’s a hobby project, it makes progress when the maintainer is having a good time, and gets abandoned when they’re not anymore, so try and avoid making a mess and having arguments when they’re the one that’ll have to deal with any fallout from any mistakes.