From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 27 Oct 2025 22:14:54 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.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 1vDc2n-0001zd-Ow for bitcoindev@gnusha.org; Mon, 27 Oct 2025 22:14:54 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3d5bf21f7dbsf143350fac.0 for ; Mon, 27 Oct 2025 22:14:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761628487; cv=pass; d=google.com; s=arc-20240605; b=bTtQVoknBJvTxnizYIzxulbvWZQ7CU1uzGH0d3WxcUAH41/rv0igINvsxXQpUI5Uz2 wTTVrtjI+Skybdllhxb9D6vJD/BaWvYWlkFix3AkovF2pPqZFxGzHh2U5H+pCSEcJqHA pKP2/7w6jYtv0MZxTHuC1ZYGqvAPmsYyDUCtBE4XaDm3ISxwwZYYtKOkRkgOfffmnIX5 81JX1/CNWdZOI8AfGZiZNk7aKgwBba4TDB08gwbMXboIHdeqHMJKt2iDpvRuqdxZiqPY Z84cwwPG7GOzf5Z31iAyJyEDJLlZb08EG8aa1XRgJ7kibyjkA75QXXGfxoKbHCbBMkBt 8Ktw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=m8rkvRovlfESBGPY13XpuHLitSbP97rE6PBnDd09rjA=; fh=mS8pRTMZ8uqNWtncUi6rnljq44hyaYzaA57f/fGrcZ0=; b=Xbdn/QdsFi+i6yz0wDRqNRE8tpxaXGHoYtfNL/SlP6+UfP8Z6ZWSaeAhutyzt52nCJ pbJBunwDBvjcbzeUVkZjp/1zi1TmOkeAmSfQckBvrnI0T4ibkz0K9iIQRft5n87G82Uo dY0B5QCwaSti/bcV9IPrX/ST/44KKtuiHt7eSV2cvq6gVRr0QJ2A6kkZHv8QS6iQbDx7 EL1EFVxbN92cbkXaQ+KahQFchGk+1zsGV1zrZw1idITk0pXuMO8pln07db1071C7jIx0 Ct/XMoZejs7QP0TyaQhiftY9iOv9YKVl2mtSHNdh+Z31KSQgu+5eNOOoN3ltaAOW4YXP uQOw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=KVs70EoT; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.30 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761628487; x=1762233287; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=m8rkvRovlfESBGPY13XpuHLitSbP97rE6PBnDd09rjA=; b=NPsqvSG/XYQ4QWFZNPNsLbH8QpuEtPAKd8HzaJxv+zgdncOcCvLxlzHrioEx/dy/AX 47eQovFcR8FGp5PfXri4nTP+po4clEMtJ8lW/q4k1LdkyvJdakvxTjIoaO+EM+8gMnjn qTuRCz4rl9R70IUipCv9cqbcmf66d3UGmTpTRaD8NISLI9XCDsHYcSSMb7bHg2APGbZO xmY/5kCDFxXMDN6RDfAm1SSx1avmDpiDqIGEbh/xS5ufVzIKQbI0TfHTwnd0eUcIwD+R mFlIHZrcIXqnGzzcTMnOoyp1fJ0envrxSKNoCltbW1Bvj8f1t+myQJJw5wAHxSLpvA2U G9aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761628487; x=1762233287; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m8rkvRovlfESBGPY13XpuHLitSbP97rE6PBnDd09rjA=; b=MaDxBlACxhO7sJcArDgUDXVOdmDAmIN9+/rdB4hhDrjEl2EXvSydLnDZU8diGKkG4a 6y2CG1FUiLpMK9cb5UEEbpYJJZZPtAd6LbX0Oq0qodYDGsysJNlErgWWAAs1T4zvQZQa RtxczmC6SKQHuAaluK/rgHGqatOHaHL9pcVNHV00nh8WAnXYDBk1h0bXL/aYe+eudZMc eFE6ThTMs/ko7fGhdFGPVmoIVshYFKf7BELFuWYmZPWy3ckQXADNPIf5+3brZY21vK5n b21McDvzORO1DXWb3baaS4kAa5A0ybXCfKzH5G/ow2QC9yUZTnv5ijIjWIH7hE9Kw9NJ Jr9Q== X-Forwarded-Encrypted: i=2; AJvYcCV/SjGHsASPtZV3LV5vEvWE2yAsfRJRNoCv7j2632j6LfZZXaao0Q+ebIaoxxVKAocH9JuZQTRht0xp@gnusha.org X-Gm-Message-State: AOJu0YyWRwJ3yB6NaYCNNVVPqp8MtPgQGYHXVRB6YEwI7N8ofyGr5p+P 9ltOeKWbBUlmDTOabFgRihq8N3a4gHTyzhLCJxTO67VDMTG4smzDqVtD X-Google-Smtp-Source: AGHT+IElZFe2PxML44HMs2SgmcZM/rLPd+xiNcG6oysdKDEch0mXr4YCN/gRNSsMrMHcvGEOwQeplA== X-Received: by 2002:a05:6870:2192:b0:35b:eccc:f94f with SMTP id 586e51a60fabf-3d5d75dedb2mr488165fac.1.1761628487238; Mon, 27 Oct 2025 22:14:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YlpkGZXq42tgS1synRC6RTH43h1CGfBgxj+i7c7GXAJw==" Received: by 2002:a05:6820:831a:b0:64c:a14f:bd81 with SMTP id 006d021491bc7-654f8acc24dls271460eaf.0.-pod-prod-01-us; Mon, 27 Oct 2025 22:14:43 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCW1AhjCLhcwMENHr7eFY/iWa37UV4H2H8sdnSmvLpGXfVcIe790x10oPSp/BSV5VTPwMZNon4d6qsxc@googlegroups.com X-Received: by 2002:a05:6808:1055:b0:44f:6d9e:61ff with SMTP id 5614622812f47-44f6d9e6259mr517355b6e.39.1761628483371; Mon, 27 Oct 2025 22:14:43 -0700 (PDT) Received: by 2002:a05:6808:6681:10b0:44f:6c18:6870 with SMTP id 5614622812f47-44f6c186eadmsb6e; Mon, 27 Oct 2025 22:13:33 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVc/rgY15nEq2gl7CSIPdkigR6VA78ukdILynqoYkVXc4eSbc84rLnJoCtDMJ/RdWyAQShzTERokj2P@googlegroups.com X-Received: by 2002:a05:6830:3153:b0:7c2:789b:8338 with SMTP id 46e09a7af769-7c6781e0fc9mr1024690a34.26.1761628413111; Mon, 27 Oct 2025 22:13:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761628413; cv=none; d=google.com; s=arc-20240605; b=gnr+wjbhR/LME179Qum4ZmnZVzWVlaVgrZGIaY+sYzZPvT9NO1DSqPSFz7MrV3MCUi hyvNmGY8460g7YbIX+ggAsrBLFamJSnO00SNjIFlScSSUTQtoR8ikaSJ9lpzLKsVgWWY 8CAnIlsGRnVprugkw3TmSoM19N2qmV0AVrCJlM/uwpW3HJfN7fpzP0Tu0hHYHu+NGiWF vtOmIqp0xQKwd/M332rDcVkWspwoRbhSaYYqz6gv1Xez7JjMa3q6de1Xm6WBXuTh4+fL pAwrUoOHqWuzxskwf66b36TUnUPMzrDzycpKQhBre6vd4t9N5I0QX/13wTatMAU1nOlS Xiow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=xeNDlBoj+9thasqxRqWEdGOS8wUwlGxhG9ui6Ub53qQ=; fh=0SdGbUxOFwURQ3OJ8UumNEaKc68UNPyJ4TZbEL3ocsk=; b=C19mFZVfF48g8NjR5y2tRSuEDBcobNzPROTC0Zs3hNmA+P8KerEv1WzhqdwcR60Y6F EZ98N51MfSI1u9pMWNtrvHBDprJ2fC87ToyStYv+IbfdKZwDyZpbCPfG6oSvdFAcCtNt lMcgZh764UE4wD+61z5jgbWP1TMn4HGIZCPq+sN4kyc6TsWDbfR6rTbAykdgflREh4U+ qitOuNxgrx3UobVDYHwpU08z/twZKtea0sDBH3HgSXT+1PzN0jZXjSRzuiHADanq/kqg cFRRCaTLLeUOv12zwqFXMutUlLMZ3Q/WJxIzL9JDdT03WqGc62rGLVZrNErJHK5zWTY+ nWTQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=KVs70EoT; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.30 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24430.protonmail.ch (mail-24430.protonmail.ch. [109.224.244.30]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7c530bb1226si125236a34.1.2025.10.27.22.13.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Oct 2025 22:13:32 -0700 (PDT) Received-SPF: pass (google.com: domain of dathonohm@proton.me designates 109.224.244.30 as permitted sender) client-ip=109.224.244.30; Date: Tue, 28 Oct 2025 05:13:28 +0000 To: Greg Maxwell From: dathonohm via Bitcoin Development Mailing List Cc: Kyle Stout , Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork Message-ID: In-Reply-To: References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> Feedback-ID: 164672733:user:proton X-Pm-Message-ID: 1b9468a0903c142131a37df9bac5bcb7ec0ae186 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_dKIJcJIjqdTolt6t9c2qoM729zBRXgEKbVblYFmA" X-Original-Sender: dathonohm@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=KVs70EoT; spf=pass (google.com: domain of dathonohm@proton.me designates 109.224.244.30 as permitted sender) smtp.mailfrom=dathonohm@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: dathonohm@proton.me Reply-To: dathonohm@proton.me 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: -1.0 (-) --b1=_dKIJcJIjqdTolt6t9c2qoM729zBRXgEKbVblYFmA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list - Thanks for all of the feedback everyone! I am working on a new draft of the BIP that will hopefully address 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 di= d indeed read your messages. Best, Dathon On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell = wrote: > The only consensus normative data encoding in Bitcoin is the order data g= oes into hashes. The representations in memory, rpc, in the p2p network, et= c. are already different and could be made arbitrarily different without an= y consensus change. Case in point: the data is now normally encrypted on di= sk and in P2P. There are also proposals such as BIP 337: https://github.com= /bitcoin/bips/blob/master/bip-0337.mediawiki none of these things are conse= nsus changes-- many aren't even bippable because they don't have interopera= bility considerations (e.g. representations on disk/memory). > > Forget for a moment the (un)likelyhood that the concerns being discussed = are meaningfully modulated by exactly how data is represented in p2p, memor= y, rpc, disk, etc.. for assumption just assume they are. > > If so, the correct move would be to change those encodings rather than an= y consensus rule change--- particularly because any consensus rule method w= ill simply be evaded, and can't provide the level of swizzling that changin= g the encoding can accomplish. Encoding 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, 2025 at 6:35=E2=80=AFPM Kyle Stout wrote: > >> 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 cu= rrently 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 a= nd technically unsound. It's technical theater that creates a distinction w= ithout any meaningful difference. >> >> First, Bitcoin has no concept of a file viewer. To interpret any embedde= d data other to validate it against Bitcoin's rules, you must use a third p= arty tool. Practically speaking, the differences are negligible in terms of= technical difficulty, as humorously demonstrated here: https://x.com/rot13= maxi/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 a= re 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 f= rom 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 byte= s exist either way, and they must be interpreted by third party software ei= ther way. If anything, this path is going to represent a voluntary self-pol= icing 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 p= rotocol data. If you insist on only accepting 'approved' arbitrary bytes, y= ou'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.m= e 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 thi= s transaction, but all it looks like to me (and the Bitcoin network) is a U= TXO 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 wrote: >>> >>>> On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Develo= pment Mailing List wrote: >>>> >>>> > Hi list - >>>> > >>>> > Due to Bitcoin Core v30 gaining in popularity, it has become necessa= ry 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 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed11= 38cb6c >>>> contains the full text of this BIP as of writing(1), while simultaneou= sly being >>>> compliant with that BIP. >>>> >>>> Clearly, this approach is ineffective. >>>> >>>> 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a48735= 4fbdae55df/bip-%3F%3F%3F%3F.mediawiki >>>> >>>> -- >>>> https://petertodd.org 'peter'[:-1]@petertodd.org >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Gro= ups "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/bitcoi= ndev/aP6gYSnte7J86g0p%40petertodd.org. >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.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. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-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/= XFyaw5Bf4-4bAO3wBt3Wk2aSclxSGQ8n-uT4BR6ga864yMCf5Fe-xFQ8VnlYHH6bQ3s5jSQrfs0= 2E-MNJbAXVmq3_vlQpgNcsOmiYTFwmcg%3D%40proton.me. --b1=_dKIJcJIjqdTolt6t9c2qoM729zBRXgEKbVblYFmA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list -

Thanks for all of the feedback everyone!

I am working on a new draft of the BIP that will hop= efully address everyone's concerns and avoid the misunderstandings that hav= e arisen.

I apologize for not being abl= e to respond to all of you, but know that I did indeed read your messages.<= /div>

Best,

Dathon
On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell <gmaxwell= @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: ht= tps://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of t= hese things are consensus changes-- many aren't even bippable because they = don't have interoperability considerations (e.g. representations on disk/me= mory).

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

If so, the correct move would be to ch= ange those encodings rather than any consensus rule change--- particularly = because any consensus rule method will simply be evaded, and can't provide = the level of swizzling that changing the encoding can accomplish. Encoding= changes are also substantially non-coercive: people who think they're valu= able can adopt them and leave other people alone.

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



On M= on, Oct 27, 2025 at 6:35=E2=80=AFPM Kyle Stout <kylestout85@gmail.com= > wrote:
= Dathon,

> if Bitcoin provides an officially supported= method of storing arbitrary data (i.e., OP_RETURN), and the capacity of th= at method is large enough to store hazardous content in a contiguous format= (an increase to 100kB is currently underway as Bitcoin Core 30 gains adopt= ion), then one does not need to misinterpret the data in order to view the = content.

This seems to be the crux of your argumen= t. I believe it is misleading and technically unsound. It's technical theat= er 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 neg= ligible in terms of technical difficulty, as humorously demonstrated here: = https://x.com/rot13maxi/status/1= 963318690759192622 . 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. Arbi= trary 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 dama= ge mitigation, not an invitation.

Third, contiguit= y 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 anythi= ng, this path is going to represent a voluntary self-policing that will res= ult 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 yo= u insist on only accepting 'approved' arbitrary bytes, you're opening the d= oor to a knowledge/intent accusation.

Regards,

Kyle



On Monday, Octobe= r 27, 2025 at 1:36: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 thi= s transaction, but all it looks like to me (and the Bitcoin network) is a U= TXO 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 arb= itrary data at the consensus level, which so far has 3 weeks with no object= ions:
> >
> > 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/3c71= 8237072c107ced8c3531a487354fbdae55df/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/bitcoin= dev/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 e= mail to bitcoindev+unsubscribe@goo= glegroups.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 "= 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://grou= ps.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehO= L8PYhWgewbg%40mail.gmail.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/bitcoindev/XFyaw5= Bf4-4bAO3wBt3Wk2aSclxSGQ8n-uT4BR6ga864yMCf5Fe-xFQ8VnlYHH6bQ3s5jSQrfs02E-MNJ= bAXVmq3_vlQpgNcsOmiYTFwmcg%3D%40proton.me.
--b1=_dKIJcJIjqdTolt6t9c2qoM729zBRXgEKbVblYFmA--