From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 17:46:57 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEGoZ-0002VR-Ic for bitcoindev@gnusha.org; Wed, 29 Oct 2025 17:46:56 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-654fa531042sf614858eaf.1 for ; Wed, 29 Oct 2025 17:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761785209; x=1762390009; 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=/VqI6OAxoBVzcj58e8Hso3sG+et7Y4KaoerAu6CPUuc=; b=PXZohoRYU3vuFG5qZ6qAFEVqw8SWzB0aZdl53rHaI4Ywwb/9YwP7xlYHIwhnAf0kPD Bogzb6b+MmoWy8VfPnQ1NjF2daXffo91xKTMGcf5JKjT/Nik2gQxKTPCwORtxM1jA0lr sEziCCSgLcwzGQZFCZ3S9ih8PKUQzEpgan5L+vPZY+66wKxwGhpgSlujMEGB3hEycPEn JlCqOr9Wh1qGfJQHIzf+j/uW+TeVF+CjvcBLOJxBa9QBEdA00dbrDXia1cr4U9X2vvlX m+qDtjJ7Kq4KJ4wzOAMhKbtWjEHy/b1AoKq2tnNXoQO1uNBc5LYi0FoQtomHFvWmJOgv RWog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761785209; x=1762390009; 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=/VqI6OAxoBVzcj58e8Hso3sG+et7Y4KaoerAu6CPUuc=; b=RM+CLh8IaG+Ogof86U07Pyw7C4mkZvHdWeU8ULjT60Tu3HbvmYLQJHITqmpzUEQJ4O ZH4HYVtRNugH+n3v0B+m2Oy1KAd+ln02RAxEwgPEfmgJ7FjhU8DSB/oJwdO6cs0NtcmP PmZbS//uOgbmlUW7VDZnUBG16FXFt9vzMDG4UfRIPXAyCkvTv2UptPZHUH8QbljMSwvQ +vaaNkDJTMpx/7mGR7gn2d8+gF9igLZT/4yqWXeLdcz2afdP938i+qUtxGqqt8YXx60s DxINeNuyW14hu8p3u8C3HAzLzWzobHxM1e/mQ22HImYBvEysYHTzs6/kNSFZDXH/xNn2 dZgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761785209; x=1762390009; 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=/VqI6OAxoBVzcj58e8Hso3sG+et7Y4KaoerAu6CPUuc=; b=VJIKEE7PXrGr/fNwt0hNbM67qH4FgE6woSP84KLVVzDW2RE0pULXK2zL9m6IarXBVZ X1a2TxubqwTEc+WrGQFgp5pUrbEmgKWi7UngIugmhrTfaQ86PYt7oV1yaZCFZt8N5RMO pyrbsxww4BXfRuLB0ofmILjFHCvVWgoF5iPNv/RcDNqmujmhYEiACQQFZk4lTO7/RvyP DpN9TIpIFkB/A0T//nST3ZKQI8rQHFtFR1+3zaXvxq/3hPbf/lfF4ZJmAzvT4AlRiHMu lbE7Vtk/4+/Au7vVVu1VP2/SwbHyLRlzrH82OgFCitMrM3yOsmlb56PuYrQfn5EAv/GR P0aw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVOQTtEAHlA3BdQABbW/hL7eBKL5tQS+lpo2HboIL40l/0yct+Wg5tlFDQD/md11G3PO47wqS5MQ05m@gnusha.org X-Gm-Message-State: AOJu0YxoVkUwnTRGZwWrqj3z6uknB6XOEEn34194L5kDwrsgde1nUWy4 AOfX/Xd0GryYB/XtYu59FfVoHCbXbxqEKcyDsOlQBGEvSBmv1THaRJVz X-Google-Smtp-Source: AGHT+IF+Rq21EPh59oAc3wtNzofX7uEO4gi/gIn9gYUvbNzb+Faa9tkskCnKhljOpRyHm1f9KJZ75w== X-Received: by 2002:a05:6870:9e94:b0:3cd:a995:6c6 with SMTP id 586e51a60fabf-3d745b880bemr2487459fac.13.1761785209036; Wed, 29 Oct 2025 17:46:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aeFv+6q6T9ybwS+l17RyUQFbn0JGxuUKdQOlcRS4my6A==" Received: by 2002:a05:6870:7052:10b0:3d2:c10b:cb41 with SMTP id 586e51a60fabf-3d8bc1edb61ls136569fac.2.-pod-prod-09-us; Wed, 29 Oct 2025 17:46:45 -0700 (PDT) X-Received: by 2002:a05:6808:2396:b0:43d:4d13:1108 with SMTP id 5614622812f47-44f89eb187dmr732457b6e.49.1761785205373; Wed, 29 Oct 2025 17:46:45 -0700 (PDT) Received: by 2002:a05:690c:a5c1:b0:74f:1486:e2a9 with SMTP id 00721157ae682-78629398ee3ms7b3; Wed, 29 Oct 2025 17:31:10 -0700 (PDT) X-Received: by 2002:a05:690c:7086:b0:785:e76e:59bf with SMTP id 00721157ae682-7863910af84mr15801087b3.50.1761784269574; Wed, 29 Oct 2025 17:31:09 -0700 (PDT) Date: Wed, 29 Oct 2025 17:31:09 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15784_822977151.1761784269291" X-Original-Sender: antoine.riard@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_15784_822977151.1761784269291 Content-Type: multipart/alternative; boundary="----=_Part_15785_1022037185.1761784269291" ------=_Part_15785_1022037185.1761784269291 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dathon Ohm, I did a cursory review of your BIP proposal, not on the technical matter as= =20 there is no reference implementation available, but I did one on the legalities= =20 raised in the text (grep'ing the word "legal" one can find 15 references versus=20 only 2 references to the word "technical"). Under European law, there is a clearly established line of jurisprudences= =20 exonerating internet service providers or hosting operators to have to install a system= =20 for filtering all electronic communications passing via its services which woul= d apply indiscriminately to all its users for any kind of content (CJUE,=20 24-11-2011, aff C-70/10 Scarlet Extended SA c/ SABAM, CJUE, 16-02-2012, aff C-260/10=20 SABAM c/ Netlog). Rather to engage in generic filtering on the burden of services providers,= =20 courts have generally yielded decisions asking for fine-grained deletion of a=20 specific content, as a safeguard of other interest at stake, notably users's right to privacy= =20 [0]. Further, in the eventuality of an extended filtering system would have to= =20 be put in place by a service provider, and if said filtering system design would= =20 be unable to dissociate between legal content and illegal content, the introduction= =20 of this filtering system would consistute an infringement of the freedom of=20 expression and information (CJUE, 26-04-2022, aff C=E2=80=91401/19). Those judicial decisi= ons are=20 litteraly encompassing peer-to-peer softwares in their scope, as somehow before=20 Bitcoin, they was something called Bittorent. Moreover, this line of jurisprudence underlights that any interference with= =20 one's fundamental right of expression should be lay down under clear and precise= =20 rules governing the scope of the interference. This is not a mere formality, as= =20 again and again too restrictives measures are strike down (CEDH, 02-02-2016,=20 Index.hu/Hungary, aff. n=C2=B0 22947/13). As far as I know, I'm not aware of any European=20 continental country that has made a legislation on how one is allowed to use his right= =20 to the freedom of expression in the context of publishing stuff in a Bitcoin= =20 block. Under the US law, I won't risk making legal comment for now, as for anyone= =20 who is following the work of the Electronic Frontier Foundation from times to=20 times, there is a pending case in front of the US Supreme Court, Cox Communications, Inc= =20 vs. Sony Music Entertainment specifically on the liability of Internet service=20 providers. But culturally the US are even more protective on the freedom of expression,=20 which puts an even higher legal bar for any restriction of it. I concur with Gregory Maxwell. There is zero need to change the consensus= =20 rules. In the idea one would like to limit one's responsability arising from how= =20 bitcoin consensus data can be encoded or decoded to "obviously" "illegal" content= =20 (as strictly defined by a specific national legislation) [1], fuzzy encoders and=20 decoders for end-to-end or point-to-point communication could be formalized as BIP=20 documents, that would put an asymmetric cost on the decoders, with the upper bound=20 being the impossibility of decoding. Fuzzy algorithms is not sci-fi tech it's actually what is used for=20 Minisketch. Best, Antoine OTS hash: f0e10776d4e4d32873ca319daf3b76c8e645a0d510a6bb803bb8685292c119d4 [0] "Those addresses are protected personal data because they allow those= =20 users to be precisely identified" [1] This is not a mere technicality, under information theory, one could=20 come up with a alphanumeric encoding algorithm that could certainly yield text-based=20 religious blaspheme in a lot of countries in the world from years-old un-reorgable historical= =20 blockchain data. We're all used to "The Times 03 Jan..." in the genesis block, but it's just= =20 picking hex as a decoding algorithm... Le mardi 28 octobre 2025 =C3=A0 05:14:47 UTC, dath...@proton.me a =C3=A9cri= t : > Hi list - > > Thanks for all of the feedback everyone! > > I am working on a new draft of the BIP that will hopefully address=20 > everyone's concerns and avoid the misunderstandings that have arisen. > > I apologize for not being able to respond to all of you, but know that I= =20 > did indeed read your messages. > > Best, > > Dathon > On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell =20 > wrote: > > The only consensus normative data encoding in Bitcoin is the order data= =20 > goes into hashes. The representations in memory, rpc, in the p2p network,= =20 > etc. are already different and could be made arbitrarily different withou= t=20 > any consensus change. Case in point: the data is now normally encrypted o= n=20 > disk and in P2P. There are also proposals such as BIP 337:=20 > https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of=20 > these things are consensus changes-- many aren't even bippable because th= ey=20 > don't have interoperability considerations (e.g. representations on=20 > disk/memory). > > Forget for a moment the (un)likelyhood that the concerns being discussed= =20 > are meaningfully modulated by exactly how data is represented in p2p,=20 > memory, rpc, disk, etc.. for assumption just assume they are. > > If so, the correct move would be to change those encodings rather than an= y=20 > consensus rule change--- particularly because any consensus rule method= =20 > will simply be evaded, and can't provide the level of swizzling that=20 > changing the encoding can accomplish. Encoding changes are also=20 > substantially non-coercive: people who think they're valuable can adopt= =20 > them and leave other people alone. > > Good news for everyone except those who consider coercing others to be a= =20 > terminal goal.=20 > > > > On Mon, Oct 27, 2025 at 6:35=E2=80=AFPM Kyle Stout w= rote: > >> Dathon, >> >> > if Bitcoin provides an officially supported method of storing arbitrar= y=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= =20 >> and technically unsound. It's technical theater that creates a distincti= on=20 >> without any meaningful difference. >> >> First, Bitcoin has no concept of a file viewer. To interpret *any*=20 >> embedded data other to validate it against Bitcoin's rules, you must use= a=20 >> third party tool. Practically speaking, the differences are negligible i= n=20 >> terms 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 by= tes=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 accusatio= n. >> >> Regards, >> >> Kyle >> >> >> >> On Monday, October 27, 2025 at 1:36:33=E2=80=AFAM UTC-4 dath...@proton.m= e wrote: >> >>> Peter -=20 >>> >>> Thank you for demonstrating what non-contiguous data looks like.=20 >>> >>> I trust you when you say that you can parse the BIP's contents from thi= s=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-lengt= h=20 >>> OP_RETURN, sending all ~100 USD in fees to the miner.=20 >>> >>> Since legally hazardous content can be generated from any input data,= =20 >>> including your 30-input consolidation transaction (as long as the corre= ct=20 >>> third-party program is used), it would not make sense to hold node=20 >>> operators legally responsible for storing and distributing such input d= ata.=20 >>> >>> However, if Bitcoin provides an officially supported method of storing= =20 >>> arbitrary data (i.e., OP_RETURN), and the capacity of that method is la= rge=20 >>> enough to store hazardous content in a contiguous format (an increase t= o=20 >>> 100kB is currently underway as Bitcoin Core 30 gains adoption), then on= e=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.=20 >>> >>> 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.=20 >>> >>> Best,=20 >>> >>> Dathon=20 >>> >>> >>> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd < >>> pe...@petertodd.org> wrote:=20 >>> >>> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin=20 >>> Development Mailing List wrote:=20 >>> >=20 >>> > > Hi list -=20 >>> > >=20 >>> > > Due to Bitcoin Core v30 gaining in popularity, it has become=20 >>> necessary to move forward on luke-jr's ML proposal to temporarily limit= =20 >>> arbitrary data at the consensus level, which so far has 3 weeks with no= =20 >>> objections:=20 >>> > >=20 >>> > > https://github.com/bitcoin/bips/pull/2017=20 >>> >=20 >>> >=20 >>> > Transaction=20 >>> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c=20 >>> > contains the full text of this BIP as of writing(1), while=20 >>> simultaneously being=20 >>> > compliant with that BIP.=20 >>> >=20 >>> > Clearly, this approach is ineffective.=20 >>> >=20 >>> > 1)=20 >>> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbd= ae55df/bip-%3F%3F%3F%3F.mediawiki=20 >>> >=20 >>> > --=20 >>> > https://petertodd.org 'peter'[:-1]@petertodd.org=20 >>> >=20 >>> > --=20 >>> > You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group.=20 >>> > To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>> an email to bitcoindev+...@googlegroups.com.=20 >>> > To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40peterto= dd.org.=20 >>> >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a= 517e93cf9n%40googlegroups.com >> . >> > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJi= q1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com > . > > > --=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/= f07bc89c-fcf0-4e3c-85ab-593a509c1265n%40googlegroups.com. ------=_Part_15785_1022037185.1761784269291 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dathon Ohm,

I did a cursory review of your BIP proposal, not = on the technical matter as there
is no reference implementation availa= ble, but I did one on the legalities raised
in the text (grep'ing the = word "legal" one can find 15 references versus only 2
references to th= e word "technical").

Under European law, there is a clearly esta= blished line of jurisprudences exonerating
internet service providers = or hosting operators to have to install a system for
filtering all ele= ctronic communications passing via its services which would
apply indi= scriminately to all its users for any kind of content (CJUE, 24-11-2011,aff C-70/10 Scarlet Extended SA c/ SABAM, CJUE, 16-02-2012, aff C-260/10= SABAM c/ Netlog).
Rather to engage in generic filtering on the burden= of services providers, courts
have generally yielded decisions asking= for fine-grained deletion of a specific content,
as a safeguard of ot= her interest at stake, notably users's right to privacy [0].

Fur= ther, in the eventuality of an extended filtering system would have to be p= ut
in place by a service provider, and if said filtering system design= would be unable
to dissociate between legal content and illegal conte= nt, the introduction of this
filtering system would consistute an infr= ingement of the freedom of expression and
information (CJUE, 26-04-202= 2, aff C=E2=80=91401/19). Those judicial decisions are litteraly
encom= passing peer-to-peer softwares in their scope, as somehow before Bitcoin, t= hey
was something called Bittorent.

Moreover, this line of = jurisprudence underlights that any interference with one's
fundamental= right of expression should be lay down under clear and precise rules
= governing the scope of the interference. This is not a mere formality, as a= gain
and again too restrictives measures are strike down (CEDH, 02-02-= 2016, Index.hu/Hungary,
aff. n=C2=B0 22947/13). As far as I know, I'm = not aware of any European continental
country that has made a legislat= ion on how one is allowed to use his right to
the freedom of expressio= n in the context of publishing stuff in a Bitcoin block.

Under t= he US law, I won't risk making legal comment for now, as for anyone who is<= br />following the work of the Electronic Frontier Foundation from times to= times, there
is a pending case in front of the US Supreme Court, Cox = Communications, Inc vs. Sony
Music Entertainment specifically on the l= iability of Internet service providers. But
culturally the US are even= more protective on the freedom of expression, which puts
an even high= er legal bar for any restriction of it.

I concur with Gregory Ma= xwell. There is zero need to change the consensus rules.

In the = idea one would like to limit one's responsability arising from how bitcoin<= br />consensus data can be encoded or decoded to "obviously" "illegal" cont= ent (as strictly
defined by a specific national legislation) [1], fuzz= y encoders and decoders for
end-to-end or point-to-point communication= could be formalized as BIP documents,
that would put an asymmetric co= st on the decoders, with the upper bound being the
impossibility of de= coding.

Fuzzy algorithms is not sci-fi tech it's actually what i= s used for Minisketch.

Best,
Antoine
OTS hash: f0e1077= 6d4e4d32873ca319daf3b76c8e645a0d510a6bb803bb8685292c119d4

[0] "T= hose addresses are protected personal data because they allow those users t= o be precisely identified"
[1] This is not a mere technicality, under = information theory, one could come up with
a alphanumeric encoding alg= orithm that could certainly yield text-based religious blaspheme
in a = lot of countries in the world from years-old un-reorgable historical blockc= hain data.
We're all used to "The Times 03 Jan..." in the genesis bloc= k, but it's just picking hex
as a decoding algorithm...

Le mardi 28 = octobre 2025 =C3=A0 05:14:47 UTC, dath...@proton.me a =C3=A9crit=C2=A0:
Hi list -

Thanks for all of the feedback every= one!

I am working on a new draft of the BIP that will hopefully a= ddress everyone's concerns and avoid the misunderstandings that have ar= isen.

I apologize for not being able to respond to all of you, bu= t know that I did indeed read your messages.

Best,

Dath= on
On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell <gmax...@gmail.com> wrote:
The only consensus normative data encodin= g in Bitcoin is the order data goes into hashes. The representations in me= mory, rpc, in the p2p network, etc. are already different and could be made= arbitrarily different without any consensus change. Case in point: the d= ata is now normally encrypted on disk and in P2P. There are also proposals= such as BIP 337: https://git= hub.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of these thin= gs are consensus changes-- many aren't even bippable because they don&#= 39;t have interoperability considerations (e.g. representations on disk/mem= ory).

Forget for a moment the (un)likelyhood that = the concerns being discussed are meaningfully modulated by exactly how data= is represented in p2p, memory, rpc, disk, etc.. for assumption just assume= they are.

If so, the correct move would be to cha= nge those encodings rather than any consensus rule change--- particularly b= ecause any consensus rule method will simply be evaded, and can't provi= de the level of swizzling that changing the encoding can accomplish. Encod= ing changes are also substantially non-coercive: people who think they'= re valuable can adopt them and leave other people alone.

Good news for everyone except those who consider coercing others to = be a terminal goal.



On Mon, Oct 27, 202= 5 at 6:35=E2=80=AFPM Kyle Stout <kyles...@gmail.com> wrote:
Dathon,

> i= f Bitcoin provides an officially supported method of storing arbitrary data= (i.e., OP_RETURN), and the capacity of that method is large enough to stor= e hazardous content in a contiguous format (an increase to 100kB is current= ly underway as Bitcoin Core 30 gains adoption), then one does not need to m= isinterpret 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 oth= er to validate it against Bitcoin's rules, you must use a third party t= ool. Practically speaking, the differences are negligible in terms of techn= ical difficulty, as humorously demonstrated here: htt= ps://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, yo= u're file carving.

Second, by definition, you= 're misinterpreting the data vis-a-vis Bitcoin since it has no native c= oncept of 'image', 'video', etc. Arbitrary bytes are meanin= gless. The purpose of having OP_RETURN as a standard output is to protect t= he 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 st= op 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 eit= her way, and they must be interpreted by third party software either way. I= f 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=E2=80=AFAM UTC-4 dath...@proton.= me wrote:
Pe= ter -

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:
>
> > 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 ob= jections:
> >
> > https://github.com/bitcoin/bips/pull/2017
>
>
> Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149= ed1138cb6c
> contains the full text of this BIP as of writing(1), while simulta= neously being
> compliant with that BIP.
>
> Clearly, this approach is ineffective.
>
> 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae5= 5df/bip-%3F%3F%3F%3F.mediawiki
>
> --
> https://petertodd.org &= #39;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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-= e0a517e93cf9n%40googlegroups.com.

--
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 bitc= oindev+...@googlegroups.com.

--
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/f07bc89c-fcf0-4e3c-85ab-593a509c1265n%40googlegroups.com.
------=_Part_15785_1022037185.1761784269291-- ------=_Part_15784_822977151.1761784269291--