From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 27 Oct 2025 12:58:39 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDTMU-0005F7-N6 for bitcoindev@gnusha.org; Mon, 27 Oct 2025 12:58:39 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-3d28b320e76sf4447186fac.3 for ; Mon, 27 Oct 2025 12:58:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761595112; cv=pass; d=google.com; s=arc-20240605; b=dQ6ezg4UputNwvWLwgWLUMkcon7UstyabTS0GbuUQF0DhTb/2THQQApfruQCM3VgBt MP452/XESrOe1/nxGKkfCdSk5s7FDMLe+a3sX1ZbO9H064QcVpBgJQs6MRVfNtndGb6u 3Ds5nTD+EI8jWOjLeLRxq5+ThHHvj4E3/P4dSPn/Vv0GemvEVxuCWN44yxVqqBuIlMZg nrxqzHc3E4f/zD/MwRHVqXxZxBeZhXxB8lyH0yY02AsevAuC5wl1lIl1Wx4OufDumwmA axTDIo1LbeE3pT9N03WFVzLQi4jg2vJ7MyhkI7gPXggqW99eGdG+obkGI6GaEHVYtnjc IeXw== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=whr3okgGlXlYRVpir45GC3xojPeMqXrFxI55PBA+YDU=; fh=JYjIIpNqo1TXcwFf0zQHwUaa46+siGAGDQQ9Ju/pGPU=; b=fKTZa9UiEJVeJxuLln8NLmQArISoiJveyj2WHsFQ+1hQj78JlGinlT5zK6UQklgwbX Qvv7nO3jUht41amkaUjqXFM/jEyFFdbGKuOS/p0X6haDUHjk+/g+lJxgQ2LKZdanUagj 8hHHrUCHMvHg4DWvnvDVHt/hr3Ooj0iBQWovnSp4AbFwy3BlS0Nrt/Wasy/wdno5lzDm M2UjGEsNT5GzqG5F91oezrRoDWGt8MyWJNIyEHANd9eLi9CxQCc9wjF5XMUF7BZlKnBb OuJ0OfrkYrhbavsxufVxujijb1PnJ7mDOrMn24IwOc4+VN+EJTKj9LVJDcxgvP0BwGIB q2Uw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="d+A0/CwC"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761595112; x=1762199912; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=whr3okgGlXlYRVpir45GC3xojPeMqXrFxI55PBA+YDU=; b=dn+DaMkrHk2hEvKHLN8LB3CTt6fr4idHXLFE1KqDB9ew6xjJlCIKFvWKI18VvKJfQz +SiXg6Rs7amiLkCc4nM8nAxLYDZsDRQs3E4Lyt6iejkGpkuGxOH3oW3jj53JrUfS9UBc 9v2klyjHONwHjrCM0u6dew4gMNEnadtxDgADLuJScRHGinvYos1/zq2bnPBFluUkfY5K ZhZs31xPW3uk9VcgtDdqv9iSW/JKOcA5cGoory3JhyUDgAagBXdK0C9zHkmr7u+FUgLF ExAUV48u4zHGZioc986Ab7w28NmP7fzCP81eZra9Q4mlfBylPZzK3KxTeqBzezGoyN5u F5JA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761595112; x=1762199912; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=whr3okgGlXlYRVpir45GC3xojPeMqXrFxI55PBA+YDU=; b=Dno5Mrcd+wVBj1KzzSRLjC3boVc3xQ72opUfzMpgPs6EQ3XMqSOC98xqO6x8PM1oq3 fwpmECJTlo2ebXKN/YtyRgvPej9GQfOc4qi+CRMwcjb7sxIXu53M3K0pqUYlu4qShFAx w/B2ljibggCqtdWHrENmFGk5G+4aCzAmSxvwTHoEuoAmR6DV0nDYPzHDw+Jv5WU2e6ar V+cXFrDUnk4PblqtH737GmBvWzu3NWiw9q3bh5Ogs75s4oCY+6w39xecx10mOSF73hK2 Tg1cd8rWBX+lpyhJpMbV3rljo1nf5Gm6Qg4zv31/5a33Lzp0JRUr8yiTv0NqjshEpoJl k6CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761595112; x=1762199912; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=whr3okgGlXlYRVpir45GC3xojPeMqXrFxI55PBA+YDU=; b=YHSwleq0bY8mlNEQg14d4919Y6krK4t7qC2M/HMq0ZqLszDbgxWVyhxE9ZbFXS3x9T UKXLn1Si79G1fM/BPH+WPdIENkNzqSyqhT8+LEzFYmWElyZPIXpK/7PSL6OaNn+M/Mow OqYlruFCSz4Nu/8IKNjfspoNAmRBOzJTzyqwLmzZyMIORgyhEyJRvNnjrZ6Qax518aLd 6uHpVXaOgNnwElfA1XVG7+7gcheWCrMNDmiGSKy3OvWvOH3wxQzhC/CKn8X/Ju8LLZX1 LoqjmHoFPDoSswgp2MtcZ/Bh0Urvwx05XEhV5Du3L7dcD0T6MeYqXXxmIEDLMSMp9xW1 JQZQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVbytH+03TdvBVL5YqoQMXTr9XkbmqI9OGttb1SLvHT2q28GKQmZZeGtXzEROkea11LEwHaMfW3/maD@gnusha.org X-Gm-Message-State: AOJu0YwQRoD0XMa3EOOBdbyyxYOxdcMa3jOm9wukrndgDBWJrpltPwdF DXGoWxFnwOcuNHMRKNJU454OBcwBXAeGgn+mlxJXDI9jAJkA71MIZ6+I X-Google-Smtp-Source: AGHT+IE4AhgXy+GBCktiqDBoQVexdPuGMRss0TExdrTsB2KGS/YPR4wlItOsaffNBtmTF56m+RMjPw== X-Received: by 2002:a05:6870:8997:b0:3d4:3:6568 with SMTP id 586e51a60fabf-3d5d964ccb3mr504381fac.24.1761595112342; Mon, 27 Oct 2025 12:58:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZZJvLN9Chn/bw8ZmFsLGlwFcSq4RftSMo3etcjlxfs6w==" Received: by 2002:a05:6870:c0f:b0:363:4ae7:c37f with SMTP id 586e51a60fabf-3cdc64ed774ls2370032fac.0.-pod-prod-05-us; Mon, 27 Oct 2025 12:58:27 -0700 (PDT) X-Received: by 2002:a05:6808:1701:b0:44d:ae60:6606 with SMTP id 5614622812f47-44f6b96a2ecmr551818b6e.13.1761595107637; Mon, 27 Oct 2025 12:58:27 -0700 (PDT) Received: by 2002:a05:6808:488a:10b0:44d:a6f9:ac05 with SMTP id 5614622812f47-44da6f9bd79msb6e; Mon, 27 Oct 2025 12:56:27 -0700 (PDT) X-Received: by 2002:a05:6870:91d4:b0:36e:f8c2:7454 with SMTP id 586e51a60fabf-3d5d9c77107mr479873fac.37.1761594986293; Mon, 27 Oct 2025 12:56:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761594986; cv=none; d=google.com; s=arc-20240605; b=b+4m76x1WvRmhjERNtNgnkdb0V6kex5MCBo6lDPf2ppBnCM86srD21BpU8LANkvJLn qyx0O87ZEaa9+ljl3ayX75cE2/Pea2rXVVELdwCxgkuB4TYTLCEnzx2RbRro/BpO+85t pgYHVq0K3clwH8YhTV7tCctnZG0TYbGReMkqugrwy0M9s+gLlWzbSukClvd/FBBEbDKN aJ+Ko+sNRodlr04hXkjbslEMmc8KyAnJLi285IaxtGXcJpE4XnaQI/hNOqzC6QFNXOca In5Pzt/FjuBh7DArdHUtic8M3vq7upePwlBu3gdB39xjNn8ey59q6iD5cqZRf1L0pCWE d++Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=lX6JcNxQj1q9qfPpLwoOFx5xlSr8RA3DqzIZSz9GEaU=; fh=xT+RF+HX1NZ6/Rk4KhPvOJyR5rAK+N67T2pmO/4ZPeI=; b=cMOrW+FDrTx0F3QBwhy7XO7PitDYA22w+wl/CLVJo4SSAoTyZvnjkzpzcaM5CsgzxN onVxm/Cr2tZFrB5mkkI9J+W/k5nLwrWMlHBupDSyWTRd5sK9qEun2/FItKAZEc1IDRhZ 8oDmR6WBGqqogSGU45VfaE/zfNKmkxwzMp2czQO3vIsutP7A+7dNjBYoFI6iah4oQcAB 2IMI77cS59ePhUSrNvgmKmadbjlWahTIJCDSTwY3RR5lFh2W/Fz8bn79Rp3iquHwuqK8 UGUP48AODTaUN0vNExZNs5GibHb54kyx7IplWIauUhm8nHUQn99aXaRUO7Qjd/YwCU74 AfKw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="d+A0/CwC"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com. [2607:f8b0:4864:20::635]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-3d2013071bbsi263862fac.1.2025.10.27.12.56.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Oct 2025 12:56:26 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) client-ip=2607:f8b0:4864:20::635; Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-290dc630a07so36135485ad.1 for ; Mon, 27 Oct 2025 12:56:26 -0700 (PDT) X-Gm-Gg: ASbGncsMnATwnFuXKuL8lVDgFSJMZ1u/lI2UphXgfnXlUxs9I5FsaOs3YlrZ10nqOVw tOCgF8jOuixKyl9YyqTB9+kc3PJrwHiJFSidjLTHP9HZUwcGa66E1LXYlLjHEuIRU6tD5f5FhR7 azIL1DrvR60n4VP0spNIFXB1dPFDwe5cLYKVXx7MPBW6HBsSgUV2jCFhv42KMdvzNaPtok/90ce rJtBwyIDi4jFSGF1fCtVAg/pN83inMBqJXVZWfNF+2cTZBqCN/vaZ6DS5b9 X-Received: by 2002:a17:902:d2d1:b0:235:ed02:288b with SMTP id d9443c01a7336-294cb52dbffmr12467525ad.30.1761594985488; Mon, 27 Oct 2025 12:56:25 -0700 (PDT) MIME-Version: 1.0 References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> From: Greg Maxwell Date: Mon, 27 Oct 2025 19:56:13 +0000 X-Gm-Features: AWmQ_blMGq45lSyxUf0skuXtJrDWjX_ho4i1cguDYHqAXGX8PqRHZzpADrSUsrA Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: Kyle Stout Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000005923c20642294b33" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="d+A0/CwC"; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::635 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000005923c20642294b33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The only consensus normative data encoding in Bitcoin is the order data goes into hashes. The representations in memory, rpc, in the p2p network, etc. are already different and could be made arbitrarily different without any consensus change. Case in point: the data is now normally encrypted on disk 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 consensus changes-- many aren't even bippable because they don't have interoperability 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, memory, rpc, disk, etc.. for assumption just assume they are. If so, the correct move would be to change 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 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 t= o > 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 an= d > 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 byt= es > 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=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, >> including your 30-input consolidation transaction (as long as the correc= t >> third-party program is used), it would not make sense to hold node >> operators legally responsible for storing and distributing such input da= ta. >> >> However, if Bitcoin provides an officially supported method of storing >> arbitrary data (i.e., OP_RETURN), and the capacity of that method is lar= ge >> 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 i= s. >> >> 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 >> 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/3c718237072c107ced8c3531a487354fbda= e55df/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%40petertod= d.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-e0a5= 17e93cf9n%40googlegroups.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/= CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com. --0000000000005923c20642294b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The only consensus normative data encoding in Bitcoin= is the order data goes into hashes.=C2=A0 The representations in memory, r= pc, in the p2p network, etc. are already different and could be made arbitr= arily=C2=A0different without any consensus change.=C2=A0 Case in point:=C2= =A0 the data is now normally encrypted on disk and in P2P.=C2=A0 There are = also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master= /bip-0337.mediawiki=C2=A0 none of these things are consensus changes-- = many aren't even bippable because they don't have interoperability = considerations (e.g. representations on disk/memory).

<= div>Forget for a moment the (un)likelyhood that the concerns being discusse= d are meaningfully=C2=A0modulated by exactly how data is represented in p2p= , memory, rpc, disk, etc.. for assumption just assume they are.
<= br>
If so, the correct move would be to change those encodings ra= ther than any consensus rule change--- particularly because any consensus r= ule method will simply be evaded, and can't provide the level of swizzl= ing that changing the encoding can accomplish.=C2=A0 Encoding changes are a= lso substantially non-coercive: people who think they're valuable can a= dopt them and leave other people alone.

Good news = for everyone except those who consider coercing others to be a terminal goa= l.=C2=A0



On Mon, O= ct 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., O= P_RETURN), and the capacity of that method is large enough to store hazardo= us content in a contiguous format (an increase to 100kB is currently underw= ay as Bitcoin Core 30 gains adoption), then one does not need to misinterpr= et the data in order to view the content.

This see= ms to be the crux of your argument. I believe it is misleading and technica= lly unsound. It's technical theater that creates a distinction without = any meaningful difference.

First, Bitcoin has no c= oncept of a file viewer. To interpret any embedded data other to val= idate it against Bitcoin's rules, you must use a third party tool. Prac= tically speaking, the differences are negligible in terms of technical diff= iculty, as humorously demonstrated here: https://x.com/rot13maxi/stat= us/1963318690759192622 . Contiguous or not, you're file carving.=C2= =A0

Second, by definition, you're misinterpret= ing the data vis-a-vis Bitcoin since it has no native concept of 'image= ', 'video', etc. Arbitrary bytes are meaningless. The purpose o= f having OP_RETURN as a standard output is to protect the UTXO set from bei= ng abused. It isn't some kind of 'blessing' to store files. Tha= t's absurd. As you admit, it's impossible to stop people from writi= ng arbitrary bytes to the blockchain, so this is damage mitigation, not an = invitation.

Third, contiguity is not a legally mea= ningful predicate. "Your honor, we tried to limit the contiguous bytes= !" is simply not going to fly. The bytes exist either way, and they mu= st be interpreted by third party software either way. If anything, this pat= h 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 yo= u insist on only accepting 'approved' arbitrary bytes, you're o= pening the door to a knowledge/intent accusation.

= Regards,

Kyle

=C2=A0
<= br>
= On Monday, October 27, 2025 at 1:36:33=E2=80=AFAM UTC-4 dath...@proton.me wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">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/bitcoin/bips/blob/3c718237072c107ced8c3531= a487354fbdae55df/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/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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegrou= ps.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/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40ma= il.gmail.com.
--0000000000005923c20642294b33--