From: Peter Todd <pete@petertodd•org>
To: Antoine Poinsot <darosior@protonmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position
Date: Fri, 2 May 2025 20:03:28 +0000 [thread overview]
Message-ID: <aBUlEOBqqrOIGHWC@petertodd.org> (raw)
In-Reply-To: <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]
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 'peter'[:-1]@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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aBUlEOBqqrOIGHWC%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-05-02 22:23 UTC|newest]
Thread overview: 42+ 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-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 ` Peter Todd [this message]
2025-05-02 22:58 ` [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
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-02 20:43 ` Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
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=aBUlEOBqqrOIGHWC@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(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