From: Kyle Stout <kylestout85@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Mon, 27 Oct 2025 11:29:17 -0700 (PDT) [thread overview]
Message-ID: <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> (raw)
In-Reply-To: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me>
[-- Attachment #1.1: Type: text/plain, Size: 5303 bytes --]
Dathon,
> if Bitcoin provides an officially supported method of storing arbitrary
data (i.e., OP_RETURN), and the capacity of that method is large enough to
store hazardous content in a contiguous format (an increase to 100kB is
currently underway as Bitcoin Core 30 gains adoption), then one does not
need to misinterpret the data in order to view the content.
This seems to be the crux of your argument. I believe it is misleading and
technically unsound. It's technical theater that creates a distinction
without any meaningful difference.
First, Bitcoin has no concept of a file viewer. To interpret *any* embedded
data other to validate it against Bitcoin's rules, you must use a third
party tool. Practically speaking, the differences are negligible in terms
of technical difficulty, as humorously demonstrated here:
https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not,
you're file carving.
Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin
since it has no native concept of 'image', 'video', etc. Arbitrary bytes
are meaningless. The purpose of having OP_RETURN as a standard output is to
protect the UTXO set from being abused. It isn't some kind of 'blessing' to
store files. That's absurd. As you admit, it's impossible to stop people
from writing arbitrary bytes to the blockchain, so this is damage
mitigation, not an invitation.
Third, contiguity is not a legally meaningful predicate. "Your honor, we
tried to limit the contiguous bytes!" is simply not going to fly. The bytes
exist either way, and they must be interpreted by third party software
either way. If anything, this path is going to represent a voluntary
self-policing that will result in more culpability. Right now, arbitrary
bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes
relay opaque protocol data. If you insist on only accepting 'approved'
arbitrary bytes, you're opening the door to a knowledge/intent accusation.
Regards,
Kyle
On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote:
> Peter -
>
> Thank you for demonstrating what non-contiguous data looks like.
>
> I trust you when you say that you can parse the BIP's contents from this
> transaction, but all it looks like to me (and the Bitcoin network) is a
> UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length
> OP_RETURN, sending all ~100 USD in fees to the miner.
>
> Since legally hazardous content can be generated from any input data,
> including your 30-input consolidation transaction (as long as the correct
> third-party program is used), it would not make sense to hold node
> operators legally responsible for storing and distributing such input data.
>
> However, if Bitcoin provides an officially supported method of storing
> arbitrary data (i.e., OP_RETURN), and the capacity of that method is large
> enough to store hazardous content in a contiguous format (an increase to
> 100kB is currently underway as Bitcoin Core 30 gains adoption), then one
> does not need to misinterpret the data in order to view the content. In
> that case, node operators could conceivably be held responsible for
> possession and distribution.
>
> Since arbitrary data storage does nothing to benefit Bitcoin as
> permissionless money, there is no good reason to force this additional
> legal risk on node operators, who already face enough challenges as it is.
>
> Best,
>
> Dathon
>
>
> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org>
> wrote:
>
> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin
> Development Mailing List wrote:
> >
> > > Hi list -
> > >
> > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary
> to move forward on luke-jr's ML proposal to temporarily limit arbitrary
> data at the consensus level, which so far has 3 weeks with no objections:
> > >
> > > https://github.com/bitcoin/bips/pull/2017
> >
> >
> > Transaction
> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
> > contains the full text of this BIP as of writing(1), while
> simultaneously being
> > compliant with that BIP.
> >
> > Clearly, this approach is ineffective.
> >
> > 1)
> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.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/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7611 bytes --]
next prev parent reply other threads:[~2025-10-27 18:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout [this message]
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros
2025-11-08 9:30 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-08 15:38 ` Greg Maxwell
2025-11-08 16:40 ` Daniel Buchner
2025-11-08 17:55 ` Chris Riley
2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 21:39 ` Greg Maxwell
2025-11-09 20:07 ` dathonohm via Bitcoin Development Mailing List
2025-11-11 7:43 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-11 16:23 ` Greg Maxwell
2025-11-09 1:21 ` Murch
2025-11-09 20:56 ` onyxcoyote
2025-11-09 21:34 ` Peter Todd
2025-11-10 19:46 ` Lucas Barbosa
2025-10-28 9:16 ` /dev /fd0
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=7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com \
--to=kylestout85@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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