From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 20 May 2025 14:54:35 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uHUuw-00009z-6M for bitcoindev@gnusha.org; Tue, 20 May 2025 14:54:35 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-2d50f1673ddsf3572680fac.3 for ; Tue, 20 May 2025 14:54:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1747778068; cv=pass; d=google.com; s=arc-20240605; b=BknjZAUfhn0Q9rC9aMDtgNNXTAQ9PhmI3aU8G8ZXoTQGqOpJgYTS0aiXYXfU8AoVXw qV270ywS+N8FI4TG3rhULsMijAY/163PEwP69Oa8Jt5PgqX+qEq8y92ROuI7myCLQUnQ e4B6J/FfkdeMk+Rt3JgZwOwBh6a2mgkHhQSGYTJQB1JRFAadnY9Q2tNeNBdF9HSjB4WC wPQimMfym7S3wz/0mF+V//wFOK/Zz5/RoiCfgPUGbSp267uKY29lAgmVZtoVZsx2d1tw 3X0DVIdDg3ZRkELQ1Wnxg2uhpWjnbo5qBNXr2mhZOIiXlz78YFeWGc7dBrBOv7qYj9oq 98wA== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=; fh=0+akn6Fj5VYtzYT9n/ry5+VW3OtYXBcyKQx9g8hW2gY=; b=fqJ6Q9UcTYVZ4e0F2VLSFc9nlFdUZwSgla99KXEp+MGWW6DJH+C3XuvqKFNJcG3Zdr 1AybL1HaCH8KcFVob4j9GYx/aHY+axtRJwarAfRKL+uYcK+Gq/VOv69iLfAWHkZaEjL2 NKpUQdUXiAQTxzhsy2+X2zwarkD9+QbZkkZL4u4wFkTJK9m9x8olx4Gqr0afkyyCWSYD UvQwTXM2k/gln7XzW5CR5bowTDwQgTO6cGGwDCSdOeiW3SP3BWlATbX+nIlo1AzOACkE l5iINaajn2oeiKhSPEthbehZhkYAubfTvQz7Wx0mReUwBg7gQ3zGpAp/2+jcc76jZXAS OsrA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JlCh5Yy7; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1747778068; x=1748382868; 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 :content-transfer-encoding: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=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=; b=rBuFovL+NnSazuciNcLiTMwSWNpfJ0h81lC1RGX8ZsD/nIvVoxIn8NiW3nWe5BREUH XebVwoRKdGhG1LK2nMZMTPmr0iGYf8Db4VNv+kmZhmYUJdVx7LMbNsj3969KA1HeBn5P 865Q4US1mrwHPjQAm7rYaqZs/XpefS7THUU8xsxRIyc7cJZr/w83vSKfNBkLCSxXCqBL qNWRy8Sp3YyHhL2Zd0aNDmUaf4fnv4eXsVM/yfM8+iBvRR2Zaew3fsyxOiToOED504jD r+fHVZ2Je3p7XXkj24LgkVZws2mu+/3wr/s0bqd11zA2V1FAw/VmXKxZWe32z3ctOx0+ HVFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747778068; x=1748382868; 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 :content-transfer-encoding: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=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=; b=m174WDYXFa4rplSy8Pw0XUstdGa6SSwrCafOytAEUiLh8dMoh9eGBsY4nkLypRrFml 37Z/JimWrGDzcAHlNmcQm0GfZA/snUVAeEZ5wMfWfYUPR+yNlVQvrjbJ4vXVku5Rz2dh 3S3l+Zc/60w7dEIJrcNXf5tzkqsQJKpXcqFMCtvxnX9AY7+cjnMycadI123CtgeCQifM w3iBULQzNcMIKyL/nijcWTtLvDKj0mJTSc+ELqhp1dsKeJba+mjMcsnFklNE+EOP6H14 sFrXuDfjs8VbMHfSSiig7wfA1yi1lv/QSh17hBK2BmANW/S61FcFSzN64KcOtSR7BKDl yQyQ== X-Forwarded-Encrypted: i=2; AJvYcCX7kamoZXdhh7rwK4MsH4zayPr6SIHc3F8Go47X1Xr/OvbrpFwHdVl0UpplZUJ5EdWWvngQjLeUwySt@gnusha.org X-Gm-Message-State: AOJu0YxjmdaoSDg6D4xQv5OATpy+eadRIbsyRgoIYf4xJiTGIEZaiqSo 7yaZxRFxMxcESwqCFiCeHzghUsXoNnxH6m4tyafpS6kD0l6VZYCDIfR0 X-Google-Smtp-Source: AGHT+IGhpNAmvMdk0ftSWR3QZoF+ie6XfEJUE8X9fEGHUUgtGcSNwWRf2UW7yYowLCI8RDbAmk/bbw== X-Received: by 2002:a05:6870:de12:b0:29e:2d18:2718 with SMTP id 586e51a60fabf-2e3c1e6b6a0mr11291773fac.28.1747778067955; Tue, 20 May 2025 14:54:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEByI2K1sZPagWl2B7by97dXAyLNrW0626mVUqa9oQdsA== Received: by 2002:a05:6871:20c5:b0:2da:fbc:5e7 with SMTP id 586e51a60fabf-2e39c84e483ls3172863fac.0.-pod-prod-07-us; Tue, 20 May 2025 14:54:23 -0700 (PDT) X-Received: by 2002:a05:6808:3a14:b0:3fc:1f7b:c39f with SMTP id 5614622812f47-404d874a88amr12363634b6e.18.1747778063401; Tue, 20 May 2025 14:54:23 -0700 (PDT) Received: by 2002:a05:6808:6389:b0:3fa:da36:efcd with SMTP id 5614622812f47-404da18c90emsb6e; Tue, 20 May 2025 09:26:12 -0700 (PDT) X-Received: by 2002:a05:6830:3908:b0:72c:10d5:783e with SMTP id 46e09a7af769-734f6ae8ab6mr12587858a34.10.1747758371152; Tue, 20 May 2025 09:26:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1747758371; cv=none; d=google.com; s=arc-20240605; b=QpxV1rdlx4h7eHNhpW6bwnBoo7RW/yP5sXlnr5By4lAkcKlDu8RtFsUFTmu3vEiv5s 1S8gC9WnEPc/mVJbb0vHCnRRiymA/l71BS3SQi0V9pYdBUD67hHIGIyQZMTzSm0vfQiC u6kZ9Z0fMcwEUzqDl9ZXU8S6d/IS2lR+ZP4A4jNbfBb/a1vqPnDdIVmLit4spxjLfTq/ qENZ4GtxFg3iPSj/v58pLbqOc8/cW8vmhmNFkfl4dSpFaFbylzHc7A+ffrVIdORddTDQ uQep/3WeFGqMIHYZvG+Bom51Dq5Y9oQ4ehknatCGSDYMZwifi5AQeU7B8/0OCFE61Jb5 t7zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=JfzHZzGdLtkiR6p6ZkytN/Gcr70piMNzCxIhyBR37XY=; fh=yPd8HNyAt94w6+9mawPnFhKq8crEnOt8R5D/kg3m3ro=; b=HJI8VpbW+Eux/65m6VlNEN6wQ86SZs3Csh/AG3JPGsJC6FxE4R33d/ttSp0iKePhYJ YtD1o6oJkgz6NMT1l5o/m/Fe+Ny1+dwvktt6f60nE+pr5W07XFy+Mi1+7JHe2cK7GKVn bKAYrjs9JlzPCdWuY2nkPhCuIXD0C5XVcFikmitK6mrsEwYayCMHaToRxvgIOCnUbI2Z ba14Eb20DCwXgyHB8tX6OlyQNzyvGwEa+WscTkUO0r8apPP/gkffzreesYBj0wfn5Hcp N2c+VxE2uymcegJL9ynzpKsAkrqsQBrMUQqSiMSn/Iw8Y4WNLlcP2BPXaDW5yKhp35z9 d51g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JlCh5Yy7; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch. [109.224.244.16]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-734f6a3e497si458965a34.1.2025.05.20.09.26.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 09:26:11 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) client-ip=109.224.244.16; Date: Tue, 20 May 2025 16:26:06 +0000 To: Peter Todd From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position Message-ID: <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com> In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 43b9ce9dc80ab00a01121428c73a810c436d7ff7 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JlCh5Yy7; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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 (-) > With that in mind, I thought it'd be worthwhile to Devil's Advocate the c= hange, and go through > some technically valid arguments against it: Let me add a steel man for another argument against the change as proposed. # Lifting the limit *entirely* is unnecessary Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in t= he presence of sustained economic demand. They may only cause a minor and temporary inconvenience to= users of such transactions until they set up a separate transaction relay network or star= t using competing direct submission services. That said they can be an effective barrier to bootstrapping such demand in = the first place. If we take the example of inscriptions, it is not hard to imagine that if the lea= f script size had been limited by standardness from the get go (which may be undesirable for other= reasons) inscriptions would have never really taken off. The renewed discussion around relaxing the OP_RETURN standardness limit is = due to newfound evidence that people attempting to use the transaction relay network are working aro= und the limitation by using fake public keys in forever-unspendable outputs, which impose a much = greater cost to node runners than simple OP_RETURN outputs. This was illustrated by Citrea's Bit= VM bridge design which requires storing some data specifically in the output(s) of a transaction. Such design only needs to store a small amount of data there. However we ne= ed to consider forward compatibility in changing the limit, as tailoring it to the very specific i= nstance of Citrea may not be a good fit for future usecases. We may not notice the publication of a f= uture design until it is actively being used, at which point its developers might understandably be = reluctant to go back and make the change. Another possibility is that developers of a future applica= tion might just not be interested in engaging with our negative externality concerns after the fac= t, but would have just used OP_RETURN outputs in the first place if there were an available option= . This is a valid argument for leaving some wiggle room for forward compatibi= lity with yet-unknown usecases. However if we think on the margin it is not a convincing for goin= g all the way to the maximum standard transaction size. Certainly it makes sense to go for insta= nce up to 1 KB. But what is the rationale for going from 1 KB to 99 KB? It is easy to relax a standardness limit, but very hard to go back. In a se= nse, what we want for standardness rules is the opposite of what we want for consensus. Relaxing = the limit on the size of OP_RETURN outputs may enable unforeseen usages that we would not be able to= prevent anymore once it is done. For this reason, we need to be conservative in picking the new lim= it. Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary= . Instead of the implicit ~100 KB limit, a more conservative limit of 1 KB should be preferred. On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd wrote: >=20 >=20 > On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin D= evelopment Mailing List wrote: >=20 > > As i have repeatedly asked people to take conceptual discussions to the= mailing list, i am circling back to this thread to answer objections. I ha= ve also written my point of view and reasons for proposing this change in a= blog post which goes into more details: https://antoinep.com/posts/relay_p= olicy_drama. >=20 >=20 > I agree with the linked write-up: the quality of debate has been > atrocious. We've had a bunch of people who should know better, making > points that don't make technical sense, and a bunch of passerby's > repeating that nonsense (as well as even more nonsensical arguments). >=20 > With that in mind, I thought it'd be worthwhile to Devil's Advocate the > change, and go through some technically valid arguments against it: >=20 >=20 > # Uninterrupted Illicit Data >=20 > Credit where credit is due, this was the only reasonable argument > against that was actually brought up on GitHub. In short, OP_Return, > unlike other standard ways of embedding data in Bitcoin transactions, > allows for long uninterrupted, arbitrary, messages to be embedded > verbatim. >=20 > The claimed risk is that this data could then end up peoples' hard > drives, complicating forensics analysis in the future and potentially > falsely incriminating people. (if you can encode your illicit data such > that the right bytes happen to match Bitcoin opcodes, you can already > embed it verbatim, uninterrupted, as seen by how inscriptions embed data > in witnesses; Martin Habov=C5=A1tiak already brought this up on this very > list). >=20 > We already have this issue with dumb virus detection software. Which is > why a few years ago code was added to XOR "encrypt" the block*.dat files > by default (chainstate is also XOR "encrypted"). >=20 > The only remaining argument here is if we should go to the trouble of > adding code to Bitcoin Core to convert existing block*.dat files to the > XOR scheme, without re-downloading. >=20 >=20 > # Setting Policy Expectations For a Consensus Change >=20 > While it is clearly infeasible to prevent people from publishing data > with Bitcoin's existing consensus rules, it is hypothetically possible > to make data publication somewhat more expensive with consensus changes. > Gregory Maxwell outlined how to do so on this mailing list years ago > (I'm not going to dig up the reference). Basically his approach works as > follows: >=20 > 1) Limit all data in the chain to be either hash digests, signatures, > pubkeys, or trivial values like true and false. >=20 > 2) Require transactions to prove that every item of data is what it > claims to be with, e.g. a hash digest pre-image, a valid signature (for > a pubkey), or the fact that a signature was valid. I may be wrong. But I > believe that with protocol changes it is possible for Lightning and > Ark to work in this model. >=20 > 3) Phase out non-compliant transactions, e.g. applying a block-weight > multiplier that increases over time to eventually make them entirely > unaffordable. >=20 > Note that such a scheme will require massive ecosystem wide change: > even existing address standards will need to be modified (and made > larger) to prove that you are paying to a real address rather than > something encoding data. >=20 > Also note that even this consensus change still won't entirely > prevent people from publishing data! No-matter what we do you can always > grind pubkeys and hashes to set the first 4-6 bytes of them to the value > that you want. Thus if you're pushing 32 bytes of data, encoded as 33 > bytes including the serialized length, and get 5 bytes per push, you > have an overhead of about 6.6x. Existing data encoders have been happy > to pay even more money than that in terms of increased fees during fee > spikes; the difference in cost between witness space and txout space is > already 4x, and some are happy to publish data that way anyway. >=20 > A tricky thing here is upgrade paths. If we make these rules apply to > all transactions, with any version number, we've radically limited our > ability to upgrade the Bitcoin protocol in the future. We probably can > make this not apply to transactions and taproot script types with > unknown version numbers. However we'd have to do something like ensure > it only applies to insecure transactions without signatures. And even > then some miners will bypass this by mining that stuff anyway for a fee. > That's pretty ugly. Maybe we can make a mechanism where miners signal > support to allow new version numbers first, prior to an upgrade. But > that also adds plenty of complexity. >=20 > That said, if the Luke's of the world want to make a reasonable > technical argument, come up with a reasonable scheme like the above and > show that it has a chance of actually getting implemented. >=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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2= M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com.