From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 29 Oct 2025 18:15:53 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vEHGZ-000397-Ul for bitcoindev@gnusha.org; Wed, 29 Oct 2025 18:15:53 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3c9662c5fb0sf1261246fac.2 for ; Wed, 29 Oct 2025 18:15:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761786946; cv=pass; d=google.com; s=arc-20240605; b=Z/PjNyzjyrScp4JT2tbdiuRMIwfcl5uvqudat3ezCa55whFRon0MTG1cV/Fv3zuIid LF83yIKG3iUOUtBistSgLR7hNREqNv/3exJKiLmEj4S11GI45o9TembOGmwo1o2PYPhC Yc2j8EGFEbbkeHYgabGO8r/OphWomvEZIlfRuwQcab8PXqrM375BBvkPJIEw9Vfxf0/e 00gACqdMUvss7dv+3vQS5DdKAxrFf0km7Z49gHKHlTG7mE0HYG4dTuIYzSkgmwCEF6L4 Zt4fRdEVevJYVjF3mAeQaQwa+B3LSUyywApO/7/dY15qZP822legcNFdmDK1LZ84y3rD jlBw== 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=Fswn/TwMEUfbPu27c9+ZCLJ4EwIeN/UeHTD6fLxaN1E=; fh=VO+BRi4DalsAtGynt4nBRHuWaaRo24uZTHUVW/5QeXY=; b=iCqHmfkLo1Cgw7uL94ITsG94zCJNahgaRk0t35XWbCFjVyiOFFtgAi7zetWYgy+CLL /E2Dpian8rlbcX9l6cFmPQcpdjpItfS1013bbImJKottDl9r1BSv5wVFB9gFlWltlVof +Vn4K2lcNofSzN+eBp2O9uEnqNHbYHU9RzDDNFvKZIMGgpiNVPfZATrpPQgEBTTY2oVj 8UKE8tQJjETCcbWpoF0oZgxPSCdB1xl6T8LmtiU2y9EX82JTfMog54Wxd5T9xzTt3e7r Vjy23kWs2mE/Md1QEEvRfAaXGSlZimS8EDEPrfOhXHRxBEkbtZDETOtMsG4FcTPXfxjV YbAg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Meq9HwbQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2f as permitted sender) smtp.mailfrom=alicexbtong@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=1761786946; x=1762391746; 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=Fswn/TwMEUfbPu27c9+ZCLJ4EwIeN/UeHTD6fLxaN1E=; b=cazlOGvodevEVIFnJtUPaKi5iyD48I8RKwD2JKHb22ALvMYWX/HpAUD0lfZkcsCy+t UC4m2zVJrJyAyqw25mtp1b28JBUAvmkwzQDHy8gPwIG4kgpzu7/46/yQtI0l9T0AqSiX jkaf6KR2juA8EZgulXOEWI+BKsVMW4umErylmRUKCVXYGdDj4sG6rdstaSG7+upv1/0r AKIRCiDcRhuHQD+7wK6VkIKVHDCe6aookJsDgWc0WxpjDrP1yAtK3qYW1Uzt+Pkm5Usb 02890fstuOT0rq5clVRU6PIPkykbcKg2jO8SOj3veecMB9/duKNhklPpdReVL2k/iNWj Ly6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761786946; x=1762391746; 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=Fswn/TwMEUfbPu27c9+ZCLJ4EwIeN/UeHTD6fLxaN1E=; b=Nt4HTEsZ+X88Dnfo2jqPcm0x/W1LXDuavMGm68mJiNq4xKnksYgGXOVeem9JmcdNvF ALnlooleGsTQ/9xkio1COHH4/2zHpncE9bsNozjj0OdggcxoNSKAiYbg0r2+Ub2zxuMr x9m+MV6SV/B5RSxFSeRYfPToBt0o4ZwU0Iowwm5jdppin2ban39K7GersIs0nd0eU33Z UJN1oG8BdwDusvl9BqER482DRJHY6EExX3fVy5L06DKxYdMiq4+nLNqrLDoCQ8DJxo3T g1LLtEpeCO0hzng1GrEaBov/cT1t5XtjOrvW8/Vx/u4fiVHgJuvaogzj5oXC5JQfxrI1 WoTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761786946; x=1762391746; 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=Fswn/TwMEUfbPu27c9+ZCLJ4EwIeN/UeHTD6fLxaN1E=; b=wu6GP1hG9eBYrqP8usxYxLxoFwc+a9avjWRE4mwmPCP1Gz+SeG9j5Am7wPbZxV6hBq ykfMX6maeGV3orQp5upOoz0708fjow+aNCrfGz54SsMP/7Y7Vcu1SUOiIOynxAy7EQ97 ILNLlwGKl7zkon1VR3IpTZStw9w/xUd8jAAYcekbQwC6FssApvNHopqQxNGMN22kiJO6 aDX6B3D7lDJvk3MhJEV5GOxReoHaSr9NhgW6JHstMlMlbqSBTE+EStcaZj+sWdgWA2dG iV7UGh6sQUKCMnYAWcuATH+aGquCtduMQUXTEnRY3y+JCIyx7rnHMjnmx2B+8OGEaOGZ J5cg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUnlMVsVpFofjPpSwf3kda7JZwZruyO7kIRhNmiOP9zhiB/uFinm4YsESd1eW0ohLk7RJlfOrTKrU0t@gnusha.org X-Gm-Message-State: AOJu0YyXBooaJb1l7fI1xMVqerB2BCB5+EbMshVGTJ3pbNyTicEFC3KN Qux44GaYWm2XUOmxhiokmIlE2zg1Ek+YFUH9LbM6/K7X7MDwIBb9y2R7 X-Google-Smtp-Source: AGHT+IEBFyo+KCdofwZX15GAOLxPyBQSjMXYI0Ve67JK08Ye0IWKZY1NqBfOuM9xy0qW9OUwso60IA== X-Received: by 2002:a05:6870:702b:b0:3d2:e11d:ad1 with SMTP id 586e51a60fabf-3d8ca1fde9fmr849978fac.45.1761786945510; Wed, 29 Oct 2025 18:15:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YqbkbC7tu9Wo8sV/9Ps630Ix7cvjQ2nUv5YnEAHPTgQA==" Received: by 2002:a05:6871:2b92:b0:3d3:799e:b427 with SMTP id 586e51a60fabf-3d8becc8ff6ls149512fac.1.-pod-prod-08-us; Wed, 29 Oct 2025 18:15:41 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVupkvQpAOa/2OAw5y7qnP586EloWxccU3GlguXHQqz1jnDwe0+FO4cmUxfyhwC2cLUg/w5NWZsQ5h9@googlegroups.com X-Received: by 2002:a05:6808:1b8d:b0:443:4ba1:4916 with SMTP id 5614622812f47-44f89ed2d6cmr681281b6e.55.1761786941562; Wed, 29 Oct 2025 18:15:41 -0700 (PDT) Received: by 2002:a05:6808:488a:10b0:44d:a6f9:ac05 with SMTP id 5614622812f47-44da6f9bd79msb6e; Tue, 28 Oct 2025 02:16:38 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWX9pVq7mlG6Zntcj1G/tReeL9yqtskU8b8Jac7jhqV3/o/012Q3YJ5Log/w0vHH8QjmUMX729aS8xL@googlegroups.com X-Received: by 2002:a17:902:eccb:b0:264:7bf5:c520 with SMTP id d9443c01a7336-294cb52499fmr34489545ad.44.1761642997011; Tue, 28 Oct 2025 02:16:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761642997; cv=none; d=google.com; s=arc-20240605; b=LzzrCkAL2dEpusxrc7rV2FkbAy9WRLibWNfbXMxCkBTtvHE77/cDyG8mvbcfKvAt8r QGJC86Y6jKsERbGW9SNbyalKgvO4Lnsp13YbQYTQ7xv2OmCtsPt2aDYE9/3ySt7x2clX TWZRdUFliuvz5C/nAlBWErXF3vZSflmhpsBdrnhvOLv0nY+zARShUlVAv0q+C9mlKmAe o7yQqKilZ+F29WVQziYT1Gx24SQHXYJj1sJghBFAwhU8n4nYui+QJtBPtZLuGjKN3oOv zlqomXN7LNTOVj+abT7OfGfkko0wvxwTWFqqfx8dBAWBJhb9n+jkAO9n5vo/Ntrhtirh lBJg== 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=XSOvFzMcvQ7hCOfx56ckvI2Tf1+rYTExFlsDCyzyOcU=; fh=jwmajh3NWYgtuJpeS6IEJWDqg2DEflrribe6aHhhetQ=; b=MqUb8Cl7g5KLxUJyykJh26PWyYwn7T2Ub8haLc6n2FehZf3+X09a17DQ1KlEo3vVJS VMdP+yFxG3guDMCJOny45sO4z34EoWQ3NK5JnrpU3lc6kKe+uMS7En7nBqrwkIZa6QFt WLqc95HZP/xUkXNEiS4Px6jKcBFzg/7ouV1nOsIqItqVxpGiEv+OCGar31m9xH5lHbi+ VfDXq2Iap/G91gdXfDLiUZSo8i0nqkHLaq8x2JZA67HEX6HwiZexN7Yaijq49vXN8h7I pRIPBRD59sL2uYEkBW6BHO8n95nKItLsLh71BjnRWjyrdtN5ExZijUeXFwmtAqtx6988 CTJg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Meq9HwbQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2f as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com. [2607:f8b0:4864:20::c2f]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2949a89efa2si4724825ad.4.2025.10.28.02.16.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Oct 2025 02:16:36 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2f as permitted sender) client-ip=2607:f8b0:4864:20::c2f; Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-654eb78f721so1947599eaf.1 for ; Tue, 28 Oct 2025 02:16:36 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXBliLsDMpDnhxmRXTfKF9lgIo1mM1iQuYvjDNbx2SPMoP64BtzylkJbHoVGvG5v+VSILO0gD6rNfSl@googlegroups.com X-Gm-Gg: ASbGncvl0mhO2us39gDikaO5pnNCNJarbwGTbntMW7e+3PK29rePOJioMIXSNZ2i4e1 hIrF/tQCuKHvPFVc7j+tEtAkCsi8l+4oAK61cPB9MBdVJqS1DVu/1db9S56Ka/zysqV653C2opy VKjA7+owVmRmFMT5QYBcaLM3WeTeBVs4+ywaEZVCcTLioPBgKkJcSEBY7rfhfPShn2Ozk5xvwQO HjNjIwGlhd5rZwUUqsNkT9e9khKFlpAaTpgvQIC2dtAZvo6/TVvgSUXgEKp2wuEBdFbGm/RAWLD tKpxzJkKoryxsiRtbPqVW+xC8QE3Bmp55Q== X-Received: by 2002:a05:6820:16a0:b0:654:fa8e:b740 with SMTP id 006d021491bc7-6566ef0d476mr1280092eaf.0.1761642996164; Tue, 28 Oct 2025 02:16:36 -0700 (PDT) MIME-Version: 1.0 References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: From: "/dev /fd0" Date: Tue, 28 Oct 2025 14:46:26 +0530 X-Gm-Features: AWmQ_bl2W8lASGfu-wFix4zWCtxNeOJ4vOW9zlKXYAl_DYa8pJmr7s_hlnixb5s Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: Greg Maxwell Cc: Kyle Stout , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000001ed4e064234799f" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Meq9HwbQ; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::c2f as permitted sender) smtp.mailfrom=alicexbtong@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 (/) --00000000000001ed4e064234799f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, > 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). [Compression][0] of raw transactions is interesting although it won't be helpful in this case. I had reviewed the pull request that implemented BIP 337 in bitcoin core and was closed. Maybe we can add it in knots. > 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. I am not sure if encoding or encryption would be the right approach but this is worth trying. I have opened an [issue][1] in knots repository to discuss these ideas and also created a web [page][2] that shows the binary for OP_RETURN in a transaction. [0[: https://github.com/bitcoin/bitcoin/pull/29134 [1]: https://github.com/bitcoinknots/bitcoin/issues/229 [2]: https://opreturn01.github.io/ /dev/fd0 floppy disk guy On Tue, Oct 28, 2025 at 1:28=E2=80=AFAM Greg Maxwell w= rote: > 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 withou= t > 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 th= ey > 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 an= y > 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 arbitrar= y >> data (i.e., OP_RETURN), and the capacity of that method is large enough = to >> store hazardous content in a contiguous format (an increase to 100kB is >> currently underway as Bitcoin Core 30 gains adoption), then one does not >> need to misinterpret the data in order to view the content. >> >> This seems to be the crux of your argument. I believe it is misleading >> and technically unsound. It's technical theater that creates a distincti= on >> 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 i= n >> 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 by= tes >> 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 accusatio= n. >> >> 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 >>> UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-lengt= h >>> 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 corre= ct >>> third-party program is used), it would not make sense to hold node >>> operators legally responsible for storing and distributing such input d= ata. >>> >>> However, if Bitcoin provides an officially supported method of storing >>> arbitrary data (i.e., OP_RETURN), and the capacity of that method is la= rge >>> enough to store hazardous content in a contiguous format (an increase t= o >>> 100kB is currently underway as Bitcoin Core 30 gains adoption), then on= e >>> does not need to misinterpret the data in order to view the content. In >>> that case, node operators could conceivably be held responsible for >>> possession and distribution. >>> >>> Since arbitrary data storage does nothing to benefit Bitcoin as >>> permissionless money, there is no good reason to force this additional >>> legal risk on node operators, who already face enough challenges as it = is. >>> >>> Best, >>> >>> Dathon >>> >>> >>> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd < >>> pe...@petertodd.org> wrote: >>> >>> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin >>> Development Mailing List wrote: >>> > >>> > > Hi list - >>> > > >>> > > Due to Bitcoin Core v30 gaining in popularity, it has become >>> necessary to move forward on luke-jr's ML proposal to temporarily limit >>> arbitrary data at the consensus level, which so far has 3 weeks with no >>> objections: >>> > > >>> > > https://github.com/bitcoin/bips/pull/2017 >>> > >>> > >>> > Transaction >>> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >>> > contains the full text of this BIP as of writing(1), while >>> simultaneously being >>> > compliant with that BIP. >>> > >>> > Clearly, this approach is ineffective. >>> > >>> > 1) >>> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbd= ae55df/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, sen= d >>> an email to bitcoindev+...@googlegroups.com. >>> > To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40peterto= dd.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/bitcoindev/7abf7055-6b85-492f-ada2-e0a= 517e93cf9n%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/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/= CALiT-ZrT%2BR7ApsQJOtKM5h5xTThGL-WMyCRDwt29sXmt4AA%2BRg%40mail.gmail.com. --00000000000001ed4e064234799f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

> There are also proposals = such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.media= wiki =C2=A0none of these things are consensus changes-- many aren't= even bippable because they don't have interoperability considerations = (e.g. representations on disk/memory).

[Compression][0] of raw trans= actions is interesting although it won't be helpful in this case. I had= reviewed=C2=A0the pull request that implemented BIP 337 in bitcoin core an= d was closed. Maybe we can add it in knots.

> F= orget 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, th= e 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 e= ncoding can accomplish.=C2=A0 Encoding changes are also substantially non-c= oercive: people who think they're valuable can adopt them and leave oth= er people alone.

I am not sure if encoding or encryption would be th= e right approach but this is worth trying. I have opened an [issue][1] in k= nots repository to discuss these ideas and also created a web [page][2] tha= t shows the binary for OP_RETURN in a transaction.=C2=A0

[0[:=C2=A0<= a href=3D"https://github.com/bitcoin/bitcoin/pull/29134">https://github.com= /bitcoin/bitcoin/pull/29134
[1]:=C2=A0https://github.com/bitcoinknots/bitcoin/is= sues/229
[2]:=C2=A0https:/= /opreturn01.github.io/

/dev/fd0
flop= py disk guy

On Tue, Oct 28, 2025 at 1:28=E2=80= =AFAM Greg Maxwell <gmaxwell@gmail= .com> wrote:
The only consensus normative data encoding in Bit= coin is the order data goes into hashes.=C2=A0 The representations in memor= y, rpc, in the p2p network, etc. are already different and could be made ar= bitrarily=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 a= re also proposals such as BIP 337: https://github.com/bit= coin/bips/blob/master/bip-0337.mediawiki=C2=A0 none of these things are= consensus changes-- many aren't even bippable because they don't h= ave interoperability considerations (e.g. representations on disk/memory).<= /div>

Forget for a moment the (un)likelyhood that the co= ncerns being discussed are meaningfully=C2=A0modulated 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 chan= ge those encodings rather than any consensus rule change--- particularly be= cause any consensus rule method will simply be evaded, and can't provid= e the level of swizzling that changing the encoding can accomplish.=C2=A0 E= ncoding changes are also substantially non-coercive: people who think they&= #39;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.=C2=A0



=
On Mon, Oc= t 27, 2025 at 6:35=E2=80=AFPM Kyle Stout <kylestout85@gmail.com> wrote:
=
Dathon,

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

This seems to be the crux of your argument. I believe it is mislea= ding and technically unsound. It's technical theater that creates a dis= tinction 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.c= om/rot13maxi/status/1963318690759192622 . Contiguous or not, you're= file carving.=C2=A0

Second, by definition, you= 9;re misinterpreting the data vis-a-vis Bitcoin since it has no native conc= ept of 'image', 'video', etc. Arbitrary bytes are meaningle= ss. 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 mi= tigation, not an invitation.

Third, contiguity is = not a legally meaningful predicate. "Your honor, we tried to limit the= contiguous bytes!" is simply not going to fly. The bytes exist either= way, and they must be interpreted by third party software either way. If a= nything, this path is going to represent a voluntary self-policing that wil= l result in more culpability. Right now, arbitrary bytes don't mean any= thing in Bitcoin. If it's valid, it's valid. Nodes relay opaque pro= tocol data. If you insist on only accepting 'approved' arbitrary by= tes, you're opening the door to a knowledge/intent accusation.

Regards,

Kyle

=C2=A0

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, 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%= 2BpehOL8PYhWgewbg%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/CALiT-ZrT%2BR7ApsQJOtKM5h5xTThGL-WMyCRDwt29sXmt4AA%2BRg%= 40mail.gmail.com.
--00000000000001ed4e064234799f--