pull down to refresh

These people are going to cause a hard-fork and fork themselves onto their own chain.
And they are chomping at the bit to do it, led by 'influencers' and bad arguments.

Incredible.

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).

reply

It's a hard fork, they just somehow think they're 'going to win'.
The bcashers thought the same

reply

It's a soft fork.

reply

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.

reply

Yeah, I know.

reply

BIP-110 is much closer to Segwit than to BCH, given that Segwit was a softfork, while BCH was a hardfork.

reply

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.

reply

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.

reply
112 sats \ 13 replies \ @Murch 30 Jan
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.

reply

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!

reply
202 sats \ 2 replies \ @Murch 7h

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?

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.

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.

reply
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

reply
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.