pull down to refresh
That’s the first case:
The soft forking chain gains majority hashrate and wipes out the non-forking chain. In that case, the miners that mined the non-forking chain bet incorrectly and lose their rewards.
When miners are working on two chaintips, only one of them will become part of the longest chain. From the perspective of the longest chaintip, the stale chaintip might as well not exist: the miners expended the effort to mine, but their block reward doesn’t exist in the longest chain.
There are three possible outcomes:
- The soft forking chain gains majority hashrate and wipes out the non-forking chain. In that case, the miners that mined the non-forking chain bet incorrectly and lose their rewards.
- The soft forking chain only garners minority hashrate and falls behind in total work. Miners that mined the soft forking chain expended the effort to create the blocks but didn’t get paid in the main chain. They give up and rejoin the majority chain.
- Neither side wants to give up their rewards, the split is made permanent, and each set of miners gets paid only on their chaintip. Both sides have slower blocks until they reach the next difficulty adjustment, which takes longer for the minority hashrate side, significantly longer if the split is very uneven. If it is almost completely one-sided, mining 2016 blocks at the pre-split difficulty may well be economically unfeasible.
All that to say, whoever ends up on the losing side of reorgs “gives up”/looses revenue.
Oh, I see what you mean. Right, if we were on BIP-110 rules and switched to Bitcoin Core rules, that would be considered a hard fork. But going from Bitcoin Core to BIP-110 would be a soft fork attempt, although a failed soft fork does behave like a hard fork from the perspective of the soft forkers (although they explicitly updated to it, so there wouldn’t be nodes left behind due to not realizing what happened). I explain it a bit more comprehensively here: https://bitcoin.stackexchange.com/a/30821/5406
I was surprised how you identify me, and the labels of my contributions are confusing:
E.g., I opened the following PR in 2024 and it got merged in 2025, but neither of those two bars lists any Tests.
I’m also not sure how you compiled that list of Maintainers. Some of the dates seem incorrect to me (e.g. Pieter stepped back in 2022), Luke and Cory never were Bitcoin Core maintainers, and some other people are missing. Perhaps check out this: https://bitcoin.stackexchange.com/q/176/5406
Maybe I’m reading too much into it, but it seems to show the commit count trending down since May 2025. It makes me think that the drama and general increase in harassment of Core contributors has been at least distracting Bitcoin Core contributors if not outright making them reconsider their career choices.
It would also reduce the blocksize and significantly reduce the transaction throughput, but blockspace demand right now is just a little less than blockspace production. So I would expect the feerates to explode again like they did in 2024 and 2017. While I’ve expected for a very long time that small payments would get priced out over time, such a move would probably make transactions very expensive immediately. What should then be the next move after that?
Thanks.
I’m not worried about blocksize or blockchain growth. When Segwit was activated, it was with the understanding that it was a blocksize increase that allowed blocks to be up to 4 MB.
The blockchain only grew by about 83.5 GB in 2025. That’s an average blocksize of about 1.57 MB (53,082 blocks in 2025).
For comparison, it grew by 88.7 GB in 2024 and 92 GB in 2023.
Blockchain size in bytes on Dec 31:
The UTXO set also shrank in count in 2025 (after growing significantly between 2023-04 and 2024-07):
TBH, a lot of the narratives seem pretty decoupled from what’s actually happening.
If you think a blocksize decrease or removing the segwit discount should be considered, why do you think that would be expected to lead to an improvement? And what improvements and other effects would you expect?
Blocks aren't bloated due to inscriptions... maybe the UTXO set is, but not blocks themselves. Blocks are the same size.
That’s not right. Inscriptions are stored in the witness section, so they do tend to increase block size. You can have only 1 MB of non-witness data, but blocks can be up to 4 MB if there is a lot of witness data.
Inscriptions were first popularized early 2023. Here is a chart of the 7-day average blocksize including that period:
And UTXO set bloat can and does occur with 10 byte op_returns (with bip-110 doesn't fix) so imo bip-110 changes nothing.
Every Bitcoin transaction must have at least one output. Inscription transactions publish the data in the witness of an input, but they still must have an output. This is why they often have one output with minimal amount.
Transactions with OP_RETURN outputs need an input to fund the transaction, but they already have an output for the OP_RETURN.
Yeah, all those tiny islands all over are hard to keep track of
Papua New Guinea is in Oceania, and the Guyanas in South America are named from an Amerindian term meaning “land of many waters”.
Your question piqued my interest, so I looked this up. The Guilf of Guinea is the name of the part of the Atlantic Ocean stretching from Gabon to Liberia and Guinea seems to have been used colloquially to refer to the entire West Coast of Africa for some time.
Via https://www.reddit.com/r/AskHistorians/comments/3450ws/why_are_so_many_countries_called_guinea/:
That’s how many of the European colonies in the region took on names like French Guinea, Spanish Guinea, Portuguese Guinea, and German Guinea.
- Portuguese Guinea became Guinea-Bissau (named after the city of Bissau).
- French Guinea became just plain Guinea (though it's sometimes called Guinea-Conakry after its capital).
- Spanish Guinea became Equatorial Guinea after its location near the equator.
- German Guinea dropped the Guinea part entirely became Togo and Cameroon, after their historical names.
Guinea, Equatorial Guinea, and Guinea-Bissau are also my kryptonite. I also keep mixing up Zimbabwe and Zambia.
Basically, there had been an idea a long time ago that trustless sidechains might enable the scaling of some types of activity on the mainchain (just how Lightning scales payments, but not users) and BitVM-based bridges are another step closer to that vision.
Scaling at the base layer is limited, and building layer2s, sidechains, rollups, and other schemes on top of it to allow us to share UTXOs more efficiently might be a way to enable global adoption without making it impossible to run a node at home.