pull down to refresh
It's a hard fork, they just somehow think they're 'going to win'.
The bcashers thought the same
It's a soft fork.
A soft fork can still produce a chain split.
If miners do not enforce BIP 110, nodes running BIP 110 will fork off from the main chain in September.
Yeah, I know.
BIP-110 is much closer to Segwit than to BCH, given that Segwit was a softfork, while BCH was a hardfork.
True.
And also BCH enabled much bigger blocks, which hurts decentralization. Meanwhile BIP-110 aims to do the opposite by reducing block bloat caused by inscriptions.
So the comparison to BCH makes no sense.
Blocks aren't bloated due to inscriptions... maybe the UTXO set is, but not blocks themselves. Blocks are the same size.
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.
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.
Hi @Murch ! Thank you for your working on Bitcoin!!!
What I meant to say is that if people are concerned about the block size... why not just promote a block-size decrease in a soft-fork?
Or why not have a soft-fork to remove/reduce the segwit discount? Bip-110 does neither of these things!
Bip-110 doesn't do anything about 'runes' memecoins... it doesn't prevent any endless number of op_return-based-metaprotocols which spam the utxo set at low fee rates...
My understanding is that the bloating of the utxo set is a far greater risk than the bloating of blocks... which runes memecoins could still cause. Yet... bip-110 still allows 80+ byte op_returns at all!
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?
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?
I know this question wasn't directed at me, but here are my thoughts anyway:
I think that the witness discount distorts incentives, since it makes inscriptions significantly cheaper compared to any other kind of transaction. Large inscriptions also lead to bigger blocks.
If the witness discount were removed, data embedding would probably shift to the less harmful OP_RETURN outputs, since this would then be the cheapest way.
Or why not have a soft-fork to remove/reduce the segwit discount?
Yes, I would really be in favor of this!
My understanding is that the bloating of the utxo set is a far greater risk than the bloating of blocks... which runes memecoins could still cause.
UTXO set bloat becomes less of a problem with Utreexo.
Also OP_RETURN outputs are not part of the UTXO set.
Then, outside of treating the 'segwit' discount (which bip-110 doesn't even address) OR simply reducing the blocksize (which is obviously much simpler...)
What is the point of Bip-110? This is why I don't use knots or support bip-110. They don't really know what they are trying to solve.
Blocks aren't bloated due to inscriptions... maybe the UTXO set is, but not blocks themselves. Blocks are the same size.
Blocks might have the same weight but one look at a block explorer shows that blocks are not the same size in terms of bytes:
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.
OP_RETURNs are not part of the UTXO set.
OP_RETURNs are not part of the UTXO set.
No they aren't... but someone can 'pretend' than an op_return creates a 'token' therefore 'pretending' that one op_return and lots of outputs... means lots of tokens. "Runes" memecoins do this but there are unlimited arbitrary possibilities.
Blocks might be the same size in terms of weight but one look at a block explorer shows that blocks are not the same size in terms of bytes:
Blocks are bigger due to the 'witness discount', witness data weighs less than transactional data
No they aren't... but someone can 'pretend' than an op_return creates a 'token' therefore 'pretending' that one op_return and lots of outputs... means lots of tokens. "Runes" memecoins do this but there are unlimited arbitrary possibilities.
Yeah, they can pretend but Bitcoin nodes do not care about Runes. It's just an unspendable script with an OP_RETURN and some unimportant data to them.
Blocks are bigger due to the 'witness discount', witness data weighs less than transactional data
Correct. This witness discount is exactly what inscriptions make use of, causing blocks to balloon up.
Yeah, they can pretend but Bitcoin nodes do not care about Runes. It's just an unspendable script with an OP_RETURN and some unimportant data to them.
Correct. That's why it's impossible to stop. Even if bip-110 were fully implemented and adopted... it wouldn't stop runes memecoins or any other arbitrary schemes for gambling on random data.
Bip-110 has an 83 byte op_return limit right? So it doesn't stop Runes at all
This is not a hard fork. Also you can "fork yourself" and you have money in both branches, so no risk for you actually (you can wait as long as you want and see who wins).