From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Nagaev Boris <bnagaev@gmail•com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Wed, 30 Apr 2025 18:30:45 +0200 [thread overview]
Message-ID: <613DAEA9-4911-4C32-8300-C6D8C87DD92E@sprovoost.nl> (raw)
In-Reply-To: <CAFC_Vt7TP3YKcnQzZaAkJMQ8zHTVoLwgByx9bU8pt7e2fMT9Cw@mail.gmail.com>
> Op 30 apr 2025, om 17:37 heeft Nagaev Boris <bnagaev@gmail•com> het volgende geschreven:
>
> On Tue, Apr 29, 2025 at 12:13 PM Sjors Provoost <sjors@sprovoost•nl> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/613DAEA9-4911-4C32-8300-C6D8C87DD92E%40sprovoost.nl.
next prev parent reply other threads:[~2025-05-01 3:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost [this message]
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 3:01 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=613DAEA9-4911-4C32-8300-C6D8C87DD92E@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox