From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 27 Oct 2025 11:35:49 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDS4K-0004Nf-GX for bitcoindev@gnusha.org; Mon, 27 Oct 2025 11:35:49 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3c9a0df3932sf3307172fac.1 for ; Mon, 27 Oct 2025 11:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761590142; x=1762194942; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=izbylklSJEEs65C5XzrGlSSfyliA++QfZm1wv02lGUE=; b=T24fbf02H2/rPtsAxmfb7YngxUA7W7pg6xZJfzZfdsyP7/FiqDkoHOjxCOCw5oMkbJ zrmXL9nBBwA/a0FJKwbT9+wCnT6Bc/KLXwvZxNug3SbVif/UUTB5bIXM2BlzVxPkiSH4 nCJ4YGESI+WcE4jMMoLtE7+xZ2VFX2AjTL/3cPvvnE+9GNfdA1n+UnQ3dSC6XafHtCwc L66GtHYNnFca7olqhIrzC/3ZflMwynaWQukvw5OzsNECDKXNRbrFhWeVTwbp2SiRnlXe WimBNjDyKARxDH7FY/w292bqdYnKt7z2RG2XLJDXauMGJ1YVPXla2vZL8npB+Yl63181 XPOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761590142; x=1762194942; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=izbylklSJEEs65C5XzrGlSSfyliA++QfZm1wv02lGUE=; b=aEU95iTVX5vTGlhhT3lonT9fMKVyRDOSJjankfQZKPGI+jfIGAmAHEK6sAzCrbv6Kx ypi2lVpf0F98ygHuftemsz41qI0StzLA511ONU9YwjLguD/EKhW+SQvrUe26RHXOUNxQ Ubp52GhXYbieDCMKhgg0lXRAlHoFxFxiJM5BoyocbX0QMTMU2xuP51T6J5jtKhm4MVSq a0eLErj7RO/sql0PPWOubLqe8sBVEyXhpd7D5KTT4owWpZogEjFWX7GFj94ed6BsT8TF eAPZ9I7ojYh+tlhQm4h47zb7De2XsXZ4LlXssZXfEIeUtJOwF2COI1MNZLH1GNAkjQcq q6Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761590142; x=1762194942; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=izbylklSJEEs65C5XzrGlSSfyliA++QfZm1wv02lGUE=; b=eg+OsIhcy1Ttc6zipMJ2agQ+ArRf3K0r2ITMAczuf5RAWjQjNRrRD3WhI59dEvdFNi vMbGVZQNLVLID9mQF2y9T3EukueONUl+ZBeRQXMsfIkLjmdrsNdefN5tq961KPyCHD8Q WtHRWhG1xa9Kqk5wpBJuyDQ3+TGyEzh1nvpLAyKKumFaJHa6p27qxAjHCA0QV8dLgcDX +gvjY0uy5eUuuRzl4ghrSeihIPyHvKWNnSebzeLtCKZNEQ70phD01SAa+Piafg8Th/IF srdpHod4XFMvVs4JBe5BhiSm82tlJtZ5fUMiUcSQwT1sXaS9ad2SJv8L0AWOsS3pxPS/ owQw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWeVecbneyXtY79cJ9HRvHT0i4v+BcKI3jliRvJVYmXEoMhoB3l/kkLmYBgmebynisMo2C2zllqv02L@gnusha.org X-Gm-Message-State: AOJu0YzZYxAtcXQR6gzmwFFDe85JQc06oTUfTykcQNMmvdbXTZINFBXt o9sTon6lvpvWcSMcSIOhr3I1r9KnbzcYxonQ0JI0B9ECalqlcz4uC6sC X-Google-Smtp-Source: AGHT+IHAAXOMZwR0a58lfat7Q09GrRVEYv3EzeDDO3u+vOrGTGT44awtiOjF6owJyZxUhvWo4iGNEw== X-Received: by 2002:a05:6870:96a1:b0:3d2:75dc:de7b with SMTP id 586e51a60fabf-3d5d9b77d92mr180752fac.11.1761590142238; Mon, 27 Oct 2025 11:35:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+a8l/fC3qUf0AjWC/N1lB9Okcu5jjVnnWWzO/1W9mXVlA==" Received: by 2002:a05:6870:8291:b0:3d5:d8b2:8545 with SMTP id 586e51a60fabf-3d5d8c2acf5ls71951fac.2.-pod-prod-04-us; Mon, 27 Oct 2025 11:35:37 -0700 (PDT) X-Received: by 2002:a05:6808:a589:20b0:43f:3d56:4dad with SMTP id 5614622812f47-44f6bb041e9mr335521b6e.38.1761590137079; Mon, 27 Oct 2025 11:35:37 -0700 (PDT) Received: by 2002:a05:690c:38d:b0:74f:1486:e2a9 with SMTP id 00721157ae682-785daab994dms7b3; Mon, 27 Oct 2025 11:29:18 -0700 (PDT) X-Received: by 2002:a05:690c:67c2:b0:735:4c38:34 with SMTP id 00721157ae682-78617e99134mr7195127b3.27.1761589757527; Mon, 27 Oct 2025 11:29:17 -0700 (PDT) Date: Mon, 27 Oct 2025 11:29:17 -0700 (PDT) From: Kyle Stout To: Bitcoin Development Mailing List Message-Id: <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_21524_1766362618.1761589757188" X-Original-Sender: kylestout85@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_21524_1766362618.1761589757188 Content-Type: multipart/alternative; boundary="----=_Part_21525_1826862515.1761589757188" ------=_Part_21525_1826862515.1761589757188 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dathon, > if Bitcoin provides an officially supported method of storing arbitrary= =20 data (i.e., OP_RETURN), and the capacity of that method is large enough to= =20 store hazardous content in a contiguous format (an increase to 100kB is=20 currently underway as Bitcoin Core 30 gains adoption), then one does not=20 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= =20 technically unsound. It's technical theater that creates a distinction=20 without any meaningful difference. First, Bitcoin has no concept of a file viewer. To interpret *any* embedded= =20 data other to validate it against Bitcoin's rules, you must use a third=20 party tool. Practically speaking, the differences are negligible in terms= =20 of technical difficulty, as humorously demonstrated here:=20 https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not,=20 you're file carving.=20 Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin=20 since it has no native concept of 'image', 'video', etc. Arbitrary bytes=20 are meaningless. The purpose of having OP_RETURN as a standard output is to= =20 protect the UTXO set from being abused. It isn't some kind of 'blessing' to= =20 store files. That's absurd. As you admit, it's impossible to stop people=20 from writing arbitrary bytes to the blockchain, so this is damage=20 mitigation, not an invitation. Third, contiguity is not a legally meaningful predicate. "Your honor, we=20 tried to limit the contiguous bytes!" is simply not going to fly. The bytes= =20 exist either way, and they must be interpreted by third party software=20 either way. If anything, this path is going to represent a voluntary=20 self-policing that will result in more culpability. Right now, arbitrary=20 bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes=20 relay opaque protocol data. If you insist on only accepting 'approved'=20 arbitrary bytes, you're opening the door to a knowledge/intent accusation. Regards, Kyle =20 On Monday, October 27, 2025 at 1:36:33=E2=80=AFAM UTC-4 dath...@proton.me w= rote: > 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= =20 > transaction, but all it looks like to me (and the Bitcoin network) is a= =20 > UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length= =20 > OP_RETURN, sending all ~100 USD in fees to the miner. > > Since legally hazardous content can be generated from any input data,=20 > including your 30-input consolidation transaction (as long as the correct= =20 > third-party program is used), it would not make sense to hold node=20 > operators legally responsible for storing and distributing such input dat= a. > > However, if Bitcoin provides an officially supported method of storing=20 > arbitrary data (i.e., OP_RETURN), and the capacity of that method is larg= e=20 > enough to store hazardous content in a contiguous format (an increase to= =20 > 100kB is currently underway as Bitcoin Core 30 gains adoption), then one= =20 > does not need to misinterpret the data in order to view the content. In= =20 > that case, node operators could conceivably be held responsible for=20 > possession and distribution. > > Since arbitrary data storage does nothing to benefit Bitcoin as=20 > permissionless money, there is no good reason to force this additional=20 > 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 =20 > wrote: > > > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin=20 > Development Mailing List wrote: > >=20 > > > Hi list - > > >=20 > > > Due to Bitcoin Core v30 gaining in popularity, it has become necessar= y=20 > to move forward on luke-jr's ML proposal to temporarily limit arbitrary= =20 > data at the consensus level, which so far has 3 weeks with no objections: > > >=20 > > > https://github.com/bitcoin/bips/pull/2017 > >=20 > >=20 > > Transaction=20 > 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c > > contains the full text of this BIP as of writing(1), while=20 > simultaneously being > > compliant with that BIP. > >=20 > > Clearly, this approach is ineffective. > >=20 > > 1)=20 > https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae= 55df/bip-%3F%3F%3F%3F.mediawiki > >=20 > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > >=20 > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd= .org > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com. ------=_Part_21525_1826862515.1761589757188 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dathon,

> if Bitcoin provides an officially support= ed 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 form= at (an increase to 100kB is currently underway as Bitcoin Core 30 gains ado= ption), then one does not need to misinterpret the data in order to view th= e content.

This seems to be the crux of your arg= ument. I believe it is misleading and technically unsound. It's technical t= heater that creates a distinction without any meaningful difference.
<= div>
First, Bitcoin has no concept of a file viewer. To int= erpret any embedded data other to validate it against Bitcoin's rule= s, you must use a third party tool. Practically speaking, the differences a= re negligible in terms of technical difficulty, as humorously demonstrated = here: https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or no= t, you're file carving.=C2=A0

Second, by definit= ion, you're misinterpreting the data vis-a-vis Bitcoin since it has no nati= ve concept of 'image', 'video', etc. Arbitrary bytes are meaningless. The p= urpose 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.<= /div>

Third, contiguity is not a legally meaningful pr= edicate. "Your honor, we tried to limit the contiguous bytes!" is simply no= t 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 repres= ent a voluntary self-policing that will result in more culpability. Right n= ow, arbitrary bytes don't mean anything in Bitcoin. If it's valid, it's val= id. Nodes relay opaque protocol data. If you insist on only accepting 'appr= oved' arbitrary bytes, you're opening the door to a knowledge/intent accusa= tion.

Regards,

Kyle

=C2=A0

On Monday, October 27, 2025 at 1:3= 6:33=E2=80=AFAM 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, i= ncluding your 30-input consolidation transaction (as long as the correct th= ird-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 10= 0kB 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 ca= se, node operators could conceivably be held responsible for possession and= distribution.

Since arbitrary data storage does nothing to benefit Bitcoin as permiss= ionless 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 De= velopment Mailing List wrote:
>=20
> > Hi list -
> >=20
> > 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 ob= jections:
> >=20
> > https://github.com/bitcoin/bips/pull/2017
>=20
>=20
> Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149= ed1138cb6c
> contains the full text of this BIP as of writing(1), while simulta= neously being
> compliant with that BIP.
>=20
> Clearly, this approach is ineffective.
>=20
> 1) https://github.com/b= itcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.= mediawiki
>=20
> --
> https://petertodd.org 'peter'[:-1]@= petertodd.org
>=20
> --
> 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/aP6gYSnt= e7J86g0p%40petertodd.org.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com.
------=_Part_21525_1826862515.1761589757188-- ------=_Part_21524_1766362618.1761589757188--