From: Bob Burnett <bob.burnett@barefootmining•com>
To: Greg Maxwell <gmaxwell@gmail•com>,
Antoine Poinsot <darosior@protonmail•com>
Cc: Peter Todd <pete@petertodd•org>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
Date: Wed, 21 May 2025 02:10:13 +0000 [thread overview]
Message-ID: <BY5PR03MB5171FCC38022BF80272729FD969EA@BY5PR03MB5171.namprd03.prod.outlook.com> (raw)
In-Reply-To: <CAAS2fgRyu1HKHDk_aCyHXqe+sgYpcApjmXx3Ps4ChpBAxeBcpw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13990 bytes --]
For those who don’t know me, I run a mining company called Barefoot Mining– not the biggest mining company but not the smallest either. Whether I would be considered major or not can be judged by others.
That said, I suggest being very careful about projecting the current behavior of major miners as the norm or representative of the future. We are extremely early in the development of the mining industry and there is a high likelihood that over the next few years that there will a dramatic change in the list of major miners – and there very well may be changes in the philosophies and priorities of these miners as well.
I spent most of career in the personal computer industry going back to ’86 (most notably as the CTO of Gateway) and I learned many things from my experience. One important thing was that the pace with which companies could rise to or fall from prominence was jaw-dropping. Assuming that “major miners” was meant to mean a group that largely is comprised of pubcos, none of the major players in the mining industry have been doing it for long - with most going public very recently (’22 and ’23). They but pups as companies and we’ve already seen a huge flameout or two. The next three to five years will likely result in a few more flameouts and some large new entrants that may approach mining from a completely different perspective. A second learning I will share from my PC development days was that predicting usages and user behavior is next to impossible. The safest and most accommodating path is to give as much user optionality/configurability as possible. My high-level recommendation is to work on paths that give users more choice not less. This is applies to OP_RETURN but, even more importantly, I think it is the best design direction in general.
To offer what may be a new lens in which to view miners, I’ll share a bit of my philosophy and vision for my company. I view Barefoot as being in the business of block production and I desire the maximum amount of flexibility/choice in making blocks. My strategy to develop and monetize block space goes beyond just fighting for a piece of the block reward. I believe that over time many miners will reach the same conclusion that this is the best path to differentiation. If not, the miners become just hashers, and I believe that is a very dangerous path for Bitcoin.
Finally, I don’t see any compelling reason for a change in OP_RETURN policy or configurability. I speak to a lot of other miners as well and I don’t know of one a single one that feels any change is beneficial to them now.
From: bitcoindev@googlegroups.com <bitcoindev@googlegroups.com> on behalf of Greg Maxwell <gmaxwell@gmail•com>
Date: Tuesday, May 20, 2025 at 7:41 PM
To: Antoine Poinsot <darosior@protonmail•com>
Cc: Peter Todd <pete@petertodd•org>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
> Certainly it makes sense to go for instance up to 1 KB. But what is the rationale for going from 1 KB to 99 KB?
Because major miners already allow the 1KB to 99KB, limiting in relay what miners easily mine only causes harm: It doesn't prevent the usage except to the extent that the user prefers to not submit directly (even though web-centric developers generally *prefer* the APIs to the p2p network), it keeps miners in the business of having to adjust the software for their own needs, encourages private submission, etc. Essentially a policy limit that miners are already bypassing is merely performative.
And then if/when someone *would* want to embed between 1kb and 99kb in outputs, they'll just go ahead and do it with fake outputs to the great detriment of the system.
I would flip this argument the other way: With a small increase failing to actually achieve consistency with mining policy? Why do it at all? For the benefit of some single user's narrow use that doesn't even seem to really care? I don't find that compelling.
> It is easy to relax a standardness limit, but very hard to go back
It's already been relaxed.
On Tue, May 20, 2025 at 9:54 PM 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com<mailto:bitcoindev@googlegroups.com>> wrote:
> With that in mind, I thought it'd be worthwhile to Devil's Advocate the change, and go through
> some technically valid arguments against it:
Let me add a steel man for another argument against the change as proposed.
# Lifting the limit *entirely* is unnecessary
Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in the presence of sustained
economic demand. They may only cause a minor and temporary inconvenience to users of such
transactions until they set up a separate transaction relay network or start using competing direct
submission services.
That said they can be an effective barrier to bootstrapping such demand in the first place. If we
take the example of inscriptions, it is not hard to imagine that if the leaf script size had been
limited by standardness from the get go (which may be undesirable for other reasons) inscriptions
would have never really taken off.
The renewed discussion around relaxing the OP_RETURN standardness limit is due to newfound evidence
that people attempting to use the transaction relay network are working around the limitation by
using fake public keys in forever-unspendable outputs, which impose a much greater cost to node
runners than simple OP_RETURN outputs. This was illustrated by Citrea's BitVM bridge design which
requires storing some data specifically in the output(s) of a transaction.
Such design only needs to store a small amount of data there. However we need to consider forward
compatibility in changing the limit, as tailoring it to the very specific instance of Citrea may not
be a good fit for future usecases. We may not notice the publication of a future design until it is
actively being used, at which point its developers might understandably be reluctant to go back and
make the change. Another possibility is that developers of a future application might just not be
interested in engaging with our negative externality concerns after the fact, but would have just
used OP_RETURN outputs in the first place if there were an available option.
This is a valid argument for leaving some wiggle room for forward compatibility with yet-unknown
usecases. However if we think on the margin it is not a convincing for going all the way to the
maximum standard transaction size. Certainly it makes sense to go for instance up to 1 KB. But what
is the rationale for going from 1 KB to 99 KB?
It is easy to relax a standardness limit, but very hard to go back. In a sense, what we want for
standardness rules is the opposite of what we want for consensus. Relaxing the limit on the size of
OP_RETURN outputs may enable unforeseen usages that we would not be able to prevent anymore once it
is done. For this reason, we need to be conservative in picking the new limit.
Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary. Instead of the implicit
~100 KB limit, a more conservative limit of 1 KB should be preferred.
On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd <pete@petertodd.org<mailto:pete@petertodd•org>> wrote:
>
>
> On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
>
> > As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_drama.
>
>
> I agree with the linked write-up: the quality of debate has been
> atrocious. We've had a bunch of people who should know better, making
> points that don't make technical sense, and a bunch of passerby's
> repeating that nonsense (as well as even more nonsensical arguments).
>
> With that in mind, I thought it'd be worthwhile to Devil's Advocate the
> change, and go through some technically valid arguments against it:
>
>
> # Uninterrupted Illicit Data
>
> Credit where credit is due, this was the only reasonable argument
> against that was actually brought up on GitHub. In short, OP_Return,
> unlike other standard ways of embedding data in Bitcoin transactions,
> allows for long uninterrupted, arbitrary, messages to be embedded
> verbatim.
>
> The claimed risk is that this data could then end up peoples' hard
> drives, complicating forensics analysis in the future and potentially
> falsely incriminating people. (if you can encode your illicit data such
> that the right bytes happen to match Bitcoin opcodes, you can already
> embed it verbatim, uninterrupted, as seen by how inscriptions embed data
> in witnesses; Martin Habovštiak already brought this up on this very
> list).
>
> We already have this issue with dumb virus detection software. Which is
> why a few years ago code was added to XOR "encrypt" the block*.dat files
> by default (chainstate is also XOR "encrypted").
>
> The only remaining argument here is if we should go to the trouble of
> adding code to Bitcoin Core to convert existing block*.dat files to the
> XOR scheme, without re-downloading.
>
>
> # Setting Policy Expectations For a Consensus Change
>
> While it is clearly infeasible to prevent people from publishing data
> with Bitcoin's existing consensus rules, it is hypothetically possible
> to make data publication somewhat more expensive with consensus changes.
> Gregory Maxwell outlined how to do so on this mailing list years ago
> (I'm not going to dig up the reference). Basically his approach works as
> follows:
>
> 1) Limit all data in the chain to be either hash digests, signatures,
> pubkeys, or trivial values like true and false.
>
> 2) Require transactions to prove that every item of data is what it
> claims to be with, e.g. a hash digest pre-image, a valid signature (for
> a pubkey), or the fact that a signature was valid. I may be wrong. But I
> believe that with protocol changes it is possible for Lightning and
> Ark to work in this model.
>
> 3) Phase out non-compliant transactions, e.g. applying a block-weight
> multiplier that increases over time to eventually make them entirely
> unaffordable.
>
> Note that such a scheme will require massive ecosystem wide change:
> even existing address standards will need to be modified (and made
> larger) to prove that you are paying to a real address rather than
> something encoding data.
>
> Also note that even this consensus change still won't entirely
> prevent people from publishing data! No-matter what we do you can always
> grind pubkeys and hashes to set the first 4-6 bytes of them to the value
> that you want. Thus if you're pushing 32 bytes of data, encoded as 33
> bytes including the serialized length, and get 5 bytes per push, you
> have an overhead of about 6.6x. Existing data encoders have been happy
> to pay even more money than that in terms of increased fees during fee
> spikes; the difference in cost between witness space and txout space is
> already 4x, and some are happy to publish data that way anyway.
>
> A tricky thing here is upgrade paths. If we make these rules apply to
> all transactions, with any version number, we've radically limited our
> ability to upgrade the Bitcoin protocol in the future. We probably can
> make this not apply to transactions and taproot script types with
> unknown version numbers. However we'd have to do something like ensure
> it only applies to insecure transactions without signatures. And even
> then some miners will bypass this by mining that stuff anyway for a fee.
> That's pretty ugly. Maybe we can make a mechanism where miners signal
> support to allow new version numbers first, prior to an upgrade. But
> that also adds plenty of complexity.
>
> That said, if the Luke's of the world want to make a reasonable
> technical argument, come up with a reasonable scheme like the above and
> show that it has a chance of actually getting implemented.
>
> --
> https://petertodd.org<https://petertodd.org/> 'peter'[:-1]@petertodd.org<http://petertodd.org/>
--
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<mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com.
--
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<mailto:bitcoindev+unsubscribe@googlegroups•com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com<https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/BY5PR03MB5171FCC38022BF80272729FD969EA%40BY5PR03MB5171.namprd03.prod.outlook.com.
[-- Attachment #2: Type: text/html, Size: 20229 bytes --]
next prev parent reply other threads:[~2025-05-21 2:13 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] Relax OP_RETURN standardness restrictions '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
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-03 5:14 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-01 3:01 ` Anthony Towns
2025-05-02 18:56 ` Greg Tonoski
2025-05-05 6:04 ` Bitcoin Error Log
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` [bitcoindev] " Bob Burnett
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
2025-05-05 21:45 ` Peter Todd
2025-05-05 23:55 ` Greg Maxwell
2025-05-25 15:53 ` waxwing/ AdamISZ
2025-05-20 16:26 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-20 23:12 ` Greg Maxwell
2025-05-21 2:10 ` Bob Burnett [this message]
2025-05-21 7:41 ` [bitcoindev] " Sjors Provoost
2025-05-21 13:38 ` Bob Burnett
2025-05-21 14:47 ` Pieter Wuille
2025-05-21 17:19 ` Bob Burnett
2025-05-21 17:52 ` Pieter Wuille
2025-05-21 18:12 ` Bob Burnett
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-05 9:18 ` Anthony Towns
2025-05-05 21:34 ` [bitcoindev] Weak blocks give an advantage to large miners Peter Todd
2025-05-06 8:56 ` Sjors Provoost
2025-05-07 20:42 ` James O'Beirne
2025-05-02 20:43 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
2025-05-04 20:04 ` Nagaev Boris
2025-05-05 11:42 ` Greg Maxwell
2025-05-05 14:32 ` Nagaev Boris
2025-05-05 21:30 ` Peter Todd
2025-05-05 14:05 ` Greg Maxwell
[not found] ` <20250502064744.92B057C0EE2@smtp.postman.i2p>
2025-05-07 1:20 ` pithosian
2025-05-07 11:32 ` Greg Maxwell
[not found] ` <20250507121109.6CEA77C0AAF@smtp.postman.i2p>
2025-05-07 16:55 ` pithosian
2025-05-12 13:47 ` [bitcoindev] " Anthony Towns
2025-05-14 15:54 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
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=BY5PR03MB5171FCC38022BF80272729FD969EA@BY5PR03MB5171.namprd03.prod.outlook.com \
--to=bob.burnett@barefootmining$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/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