pull down to refresh
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.
For a softfork to be activated, it needs to gain support. To gain support, people need to talk about it and address the concerns that were raised. There seem to be few people talking about OP_CAT and, as far as I am aware, the concerns have not been adequately addressed. It currently seems to have little momentum and there hasn’t even been an activation mechanism discussed, let alone an activation client published.
At this time, there seems to be a low likelihood of OP_CAT being adopted any time soon.
Even if some bitcoiners enact OP_CAT, others might not, or they might fork another chain.
If a new feature introduced by a soft fork is enforced by a minority of the hashrate, it cannot be relied upon and therefore is unlikely to achieve any meaningful usage.
I see, that explains it. I experienced the same when I was a bit off-center for Algeria. And I outright mis clicked for Togo into Benin instead and it was accepted:
Yeah, that I2P example felt a bit off-base. Nodes self-announce their (network-respective) address for each network they support to each peer after establishing a connection, i.e., on clearnet, a node will announce its clearnet address to peers. Such peers may then forward the address when they get asked for a batch of addresses by another node. I don’t remember whether nodes only gossip addresses of the respective network on each network, or whether they generally gossip addresses from all addresses (probably the latter?), but a node that doesn’t use I2P wouldn’t announce an I2P address, so we’d never try to connect to it with I2P.
The services flags indicate which optional peer services a node offers which is different from whether nodes understand a protocol feature. I would expect that they continue to get used.
OTOH, if BIP 434 is adopted, the protocol version might not need to be bumped further after the bump for BIP 434.
Nice work, thanks!
I must admit, I find this chart a bit concerning.