Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions

From: Sjors Provoost <[email-masked]>
Date: Wed, 30 Apr 2025 18:30:45 +0200

> Op 30 apr 2025, om 17:37 heeft Nagaev Boris <[email-masked]> het volgende geschreven:
> 
> On Tue, Apr 29, 2025 at 12:13 PM Sjors Provoost <[email-masked]> wrote:
>>> If that wasn't bad enough, exploiters get a 75% discount on transaction fees.
>> 
>> At the time SegWit was proposed it was clear that the worst case block size would increase to 4 MB. It took a few years for people to figure out how to take advantage of that. Somewhere between 2015 and early 2017 would have been good time to object to the SegWit discount, but removing it now would be a hard fork. Fwiw I think the discount was a good idea.
> 
> Can you elaborate on why removing the SegWit discount now would be a
> hard fork, please? This would be a tightening of consensus rules -
> blocks that are valid under the current rules become invalid under new
> rules, but not vice versa.
> 
> (I'm not proposing this, just a technical question.)

Good point. It might indeed be a soft fork: https://bitcoin.stackexchange.com/a/121185/4948

It just has to be combined with a block size decrease.

I think it would boil down to reducing MAX_BLOCK_WEIGHT from 4 million to 1 million, while at the same time reducing WITNESS_SCALE_FACTOR from 4 to 1.

So it undoes the block size increase created by SegWit. From the perspective of pre-segwit nodes, they would see that typical blocks got smaller, because they don't see the witness data.

I also can't think of a vice-versa example. One could start by adjusting all the tests in Bitcoin Core to verify if there really isn't one.

It would however be a confiscatory soft fork. E.g. if you have a pre-signed 1.1 MB transaction, it won't fit in a block. Similarly, though less severe, a 101 KB pre-signed transaction would no longer be standard, so you'd have to find a miner or accelerator.

Those transactions may sound silly, but soft fork proposals have been criticised for far less likely confiscatory surface. See e.g. the original Great Consensus Cleanup thread from 2010.

Note that a similar, albeit temporary, block size decrease has been proposed before, see [0].

> The initial size limit upon activation depends on when it is activated: for example, if in 2018 January, it would begin at ~356k; or if in 2024 June, it would begin at just over 1 MB.

It kept the SegWit discount intact, though it added a byte based ceiling:

> The weight of a block may not exceed double the size limit in bytes.

It was never assigned a BIP number, so I'm not sure how serious this proposal was. In any case, it got no traction, nor did any other block size decrease proposal.

So even if there was support for removing the witness discount, since you can't do that without also decreasing the block size, I don't think this avenue is worth exploring.

- Sjors

[0] https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/613DAEA9-4911-4C32-8300-C6D8C87DD92E%40sprovoost.nl.