From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 01 May 2026 15:15:42 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wIw98-00049F-0C for bitcoindev@gnusha.org; Fri, 01 May 2026 15:15:42 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-4346755f7dcsf1072646fac.3 for ; Fri, 01 May 2026 15:15:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1777673736; cv=pass; d=google.com; s=arc-20240605; b=Bl7ugDcr3/H6CTDTa6YijiZMIS2HvIGEjAns1+LhkZSWS1wGliWYHJ5y/jzK7quhsy aWOSNthD7R+IwbQXDCM6oCkoUi41DRefOPOIaLkLf7ezNxsM2i3u9SyNAgotJK+KAk2e jLrtjUqpKFjhbD5rQ1FlOncSnUXYsEeBGK1x81sFfRpDyAmz079dioUEQzk6czkz/Ags vBWmxWRKGHsTK3IWkUaeGRy5+J3JBk3slg7kQ4wqOjLUL+ewOlipdB4qCiW4Z3sLKB74 xO4H5XYgBy2W18tCCauJnUay498aBQrw8knYYL4zt2oy9HDJwSn0SX2k7U4n3ygmAq7B PyDw== 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:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:to:from:sender:dkim-signature; bh=urVrLWnFpAK7rn3EU4OPZFlKHye2C6KOz/CcP+pD18k=; fh=KWhNyQ3tKJy69Pu8iMwq402Zna96ckk1r1N1jU5soag=; b=T3hKnmlEiHxTYiMbCIqXVQVwgOM4m26fhDWn63YmUluOIVjzEKiSVpRk1FKxaL/FEv kd8Qf8y7tHPCJ+jhXwFajiV1F4RgZTnDxYpqWKMbuRklEMWHXIhfPvBYuG6XHsoIezPO GE7RXZegRt0/kzEnv8G1JUdmbeWt7gFhCxNdsvYva0mg2bDyoIW9aiOY2eWyG7rfDpsB dKMhIUXFbmlbZAjasUsmq8VRicLbkS8vfXw/X2i4T7nwUlovJ7KypgSortdmp+HVp7Rc Mrwtvhqct08eBqHCrQU7m55nM+jSzfI57ZcUaNYuvHo2Pw1T2YRRyZt4rzhlZUuyJm9h ifHw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=mhbA2cBO; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=eric@voskuil.org; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777673736; x=1778278536; 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:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:to:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=urVrLWnFpAK7rn3EU4OPZFlKHye2C6KOz/CcP+pD18k=; b=yXPwGzUMo/0Kof8F0V0gau05D/KLOzx9EbRXfPLp9MEVGw7Sa/jxFOok1n+r36xK9k r4w8107tPfFZStUcezP+6SgTpOBakpEZHaEghUc7t849XHBMntdtxrwMwigvxVclsMtE 6C5nFUM1BLnJvQ6m+smcyjHDQXAourNCY9nCa95tMoStQdSMnRVZJT+eKucFgXGEGByJ 1hE86A69HfiDY2Z40hZQYDbaG5VxWDGUTBV6wtguA7wP8DcqtjNBQXolhL/g3GxZZ+bx WmACzG1BZA1tB2CznIUX1txSy4ft4MrhF6tW70XMy1nlLqxsCVinANErP+TFmul15fkz ObkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777673736; x=1778278536; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:to:from:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=urVrLWnFpAK7rn3EU4OPZFlKHye2C6KOz/CcP+pD18k=; b=RYPB85P3FF3BEkkCT72shMU90QvpWmAxdRNk1a9TxFvWwWS5PZyWzEAfXxk/hdzJ6K o/SuyCNfDA8vodpgZDjGfgBwQyjPKSgfutJYgw4v/r2rcID93sVoUd0TvhzvlzqncNUo lD4CfVKfwgdHn9zTZLSeZBOkuzGmqwyuRuTeVC4+eFIWSlU5Ey7+zFAk3wJ5wHzJxA+x FzJQA2gIXltoF4mkYB5Dco3ILXmopz3LIRjl9SUhSySuTevkGPX8E7NnHvwQaMFWIf1O 3CcYXbG7ISTuf23MCLm3ZVjigowq+UIDSqIBVpCnDc5LJalqg3e42pC4w1k3HuObHtPx Dxdg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ+eS4KUoqX//GKba1ZYzETpj2LrA44041M2IUUdyM8ZpujWuRV39TfS+wOjJoYtwiF7D9VavjTSBdW3@gnusha.org X-Gm-Message-State: AOJu0YwWVJxjduFi9t7JiKnevLQgDCgy/QtIOE8qmhGLuLWk42Hzq451 0E8baBJPS4+4Qk2r/qdEM9GrRLjQgtoCrCqGhQiqKhI0S5tBNEb0gMRV X-Received: by 2002:a05:6820:2d05:b0:696:7697:6472 with SMTP id 006d021491bc7-696979c9856mr524828eaf.5.1777673734871; Fri, 01 May 2026 15:15:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOuvrz85bAMbKH/apagMSB0d4fEge7lyQRmLErB4ewr9Q==" Received: by 2002:a05:6820:82a:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-69678bb169cls1645928eaf.0.-pod-prod-02-us; Fri, 01 May 2026 15:15:30 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9QsjTeE3IAoy20TZWKEZMi/LP0lFIvRzetUa6znwwCeBdE7aGNsu9xmnmoPMJ8yXM7YNFGpe5N9hTL@googlegroups.com X-Received: by 2002:a05:6808:6f91:b0:47b:d07b:ecac with SMTP id 5614622812f47-47c88e89654mr746382b6e.10.1777673729985; Fri, 01 May 2026 15:15:29 -0700 (PDT) Received: by 2002:a05:620a:224b:20b0:8f9:4d19:af67 with SMTP id af79cd13be357-8fd081e3473ms85a; Fri, 1 May 2026 15:03:33 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ92xAYIA18OXb5reVEtxHrRVFO3wu7KGhFLrfEzdvosR0ipw0XxouhcwsINq/Gb31QCg6oEPDJySizc@googlegroups.com X-Received: by 2002:a05:622a:1f19:b0:50f:b3d2:6ee1 with SMTP id d75a77b69052e-5104bef2b7dmr16505621cf.31.1777673013381; Fri, 01 May 2026 15:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777673013; cv=none; d=google.com; s=arc-20240605; b=Fxd/+zUkH56G/8Pxn1YIj4wrvdRY1SYAYvOmWxiAicWGC3f1SzywYTWJdHzROMnIAi FmpDush3Sn4lJlp51UvM6YaPlDkccVEXeboxX8vpJAafaUGJe8HbGz/BxaatEuOsE1Pk +lFeb1EdeFCZenCq4agDpQB9SQ51UwxUqvkAGtv3Z4zrEu9XQ0ku+6nXCYgHYoHxlFSD R5QVwK6/8qyCECveCDbx32m7/VzhLasp+Rs2bxlDiUrNEY+2dqO/FVUutn8RIOWy1sxx dNT2lHVI2rFnqidf4V1XGAZNYuDTJdqfB9KhAQTkFyB0FPurqnWRBpXW6oByB1/ttaKl uB1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:to:from :dkim-signature; bh=gvrvSg1u9LbtDfK2+3V7KRGz2XFxorQmU0y7U0v4+tI=; fh=0QcjbHOqzNx8Vp2s6C36mSgPk6yv2RSvubqwB9f3hYY=; b=dqv8wNS6No+TrAY/Qmbat8YgMgu8YC/SWqqgT6ZcWVCUWGUuHUwnIEc9lyFfOSFXs4 5rPoxwn3esybLLW+yoooJ8UpZ97D2f/4y3IMX7mDDaB6FXlY/5Hdw/yF2VOkkdfhjS6l 64cp92O1HThTL3ez5fc0j267jr1Lqye69pa/eUX9lXNt/cWntCatLTVkjmlMGl7jxrOD tdjPiJfRUX6fWT+IDc3reEOjiCgZFICcHtS7frgDHd0xXPu3kP5Xyoz+DDC8moGM0l9V iv7Za/e6WLmPxv9Jqc9fhpZsqPxXRoPzs+GIO+8h+oP+qPrdtkbgHhJfoMiF369timS3 NOyw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=mhbA2cBO; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=eric@voskuil.org; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com. [2607:f8b0:4864:20::f30]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-5104098f252si955581cf.6.2026.05.01.15.03.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2026 15:03:33 -0700 (PDT) Received-SPF: pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f30 as permitted sender) client-ip=2607:f8b0:4864:20::f30; Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-8b4eb1fd5d0so16285446d6.0 for ; Fri, 01 May 2026 15:03:33 -0700 (PDT) X-Forwarded-Encrypted: i=1; AFNElJ+455M1h7oz7DhBJ6J3UN1EX6tc2cj5sFzqPtnrIwFVrzPg5veWHn92ZMZDVyJwZv5uJTbufRBwIJ5i@googlegroups.com X-Gm-Gg: AeBDievGZw08PN39L+ZNRin/mo3V90KJ1NSvTiBli1v/VLykdgox2ue452yry9TrkH5 2tGFBTPhs1Bs0Q7/M6Cb2u9lV0pYU5wSdlkxZ+eRgrOoMkLwbAvjrjlnhxZpk4DVZH8rF+WONxp +Ux3QW7R8rzQDPFUYIPaOrZz31OJi1Iyd53WNqee+3Hvgpngue8AfRUpgLAvOVYZxzsOjS+63S5 TYpuhcHQwSEu7JaRF2uM4qWCb3A1p3gOWWiGB/OQRYpHA3zMtub1cCRrmPyagmLPsWRXFhDb9TF GngHsAKskzkgZyt1KEYvVT9VMRfX6VS0R2G/W9V6uRczQ+Nu+zICZ/5S4W/C9KkN8qXJhLdwBcz X2c/RWGEuY3XFEw73xWNOCyHq3MGnyqByUvpKR5svoE3tdhYpkc8w1rxohyr42MbQ8+a37pi7D9 mzN7yt0FBX6O6w8ujbsM/j5Lk7m4L8CVBCsYNw34Fa X-Received: by 2002:a05:6214:6002:b0:8b0:2dc3:319f with SMTP id 6a1803df08f44-8b665452b74mr20266266d6.2.1777673012623; Fri, 01 May 2026 15:03:32 -0700 (PDT) Received: from ERICDESKTOP ([216.212.108.156]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b53c0e6d72sm39704126d6.26.2026.05.01.15.03.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 May 2026 15:03:32 -0700 (PDT) From: To: "'jeremy'" , "'Bitcoin Development Mailing List'" References: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> In-Reply-To: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> Subject: RE: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses Date: Fri, 1 May 2026 18:03:31 -0400 Message-ID: <00a501dcd9b6$59406560$0bc13020$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFU2+tzP1bbwq0OMkB6MFziKTLoALcJrdZQ Content-Language: en-us X-Original-Sender: eric@voskuil.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@voskuil.org header.s=google header.b=mhbA2cBO; spf=pass (google.com: domain of eric@voskuil.org designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=eric@voskuil.org; 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.8 (/) Thanks Jeremey for this additional information. This exclusion is one of th= e reasons I originally pushed back, but I wasn't personally aware of any cu= rrent use cases. I would also suggest that the Rational section text in this area, while ref= erencing my critiques in a footnote, doesn't capture the essence of them in= the paragraph. It points out that I pushed back on importance, but exclude= s the reasons, which I consider essential in terms of making an informed de= cision. There is a referenced thread on Delving, and a related discussion o= n bitcoin-dev. I won't recount the details here, but I think the paragraph = could more fairly represent the discussion, including the fact that the tec= hnical aspects were eventually agreed. The TLDR is that: (1) Merkle root malleation affects validation optimizations, not validation= inherently. (2) both forms of malleation can be mitigated by a node with no material pe= rformance hit (we do this). (3) the material impact is to SPV wallets, as they must obtain the coinbase= to mitigate. This reference: "It was suggested that the known vulnerabilities could instead be mitigated= by committing to the Merkle tree depth in the header's version field" Was added to the discussion by me, but is not the essence of my critique. I= t pertains to #3 and is not necessary for a node to mitigate malleation. My pushback was that we are trading optimization implementation details for= a consensus rule, and that the rule could create unforeseen problems by ot= herwise arbitrarily restricting the tx domain (which you have now pointed o= ut below). I did not assume that everyone would see this modest SPV wallet = benefit as worth the tradeoff. I am not personally taking a stand on that q= uestion, but I do think it could be presented more clearly. Best, Eric > -----Original Message----- > From: bitcoindev@googlegroups.com On > Behalf Of jeremy > Sent: Friday, May 1, 2026 5:15 PM > To: Bitcoin Development Mailing List > Subject: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential > Legitimate Uses >=20 > For fun, let's start with a pop-quiz: >=20 > Select all that apply: There can exist a transaction of ___ bytes seriali= zed size > that BIP-0054's 64-byte restriction invalidates: >=20 > A) 64 Bytes > B) 0 Bytes > C) 1.5MB > D) 32 Bytes > E) 5MB >=20 >=20 > The answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB. >=20 > Why is this the case? >=20 > BIP-0054 uses the term 64-byte transaction, but defines it as follows: >=20 > > Transactions whose witness-stripped serialized size is exactly 64 bytes= are > invalid. >=20 > In a [personally run] straw-poll of devs at a recent conference, no-one k= new > this precise edge condition or that the transactions could have a meaning= ful > witness. For clarity, the restriction on bytes is on > INVALID_TX_NONWITNESS_SIZE, not on the size with Witness. >=20 > Therefore, it is more accurate to refer to this in all sentences througho= ut the > BIP as: >=20 >=20 > > transactions with exactly 64 bytes of non-witness data, >=20 > due to the propensity for confusion. >=20 > BIP-0054 also makes a comment that the transactions it invalidates are > essentially useless: >=20 > > 64-byte transactions can only contain a scriptPubKey that lets anyone s= pend > the funds, or one that burns them. >=20 >=20 > This is not strictly correct. Here are a few examples of current and futu= re uses > for 64-byte transactions: >=20 > Current Uses: > - A transaction that donates to a future miner from a segwit (any version= ) > output via a spend to something like <512> OP_CSV (-> push2 bytes 512 csv= - > > 0x02 0x00 0x02 0xb2) > - That same output which is used as a connector output for things that sh= ould > be claimed by a miner at a future time > - Pay-to-Anchor / ephemeral anchor outputs -- while typically p2a is for = txns > you want to add a subsidy ability, a 64-byte txn could be used to shim a = keyed > anchor to a p2a output after a certain delay. >=20 >=20 > Future Uses: > - Future work which might use output scripts for e.g. Transaction Sponsor > encodings > - Future covenants work which encodes time-of-creation run scripts that e= .g. > quine an input; possibly in conjunction with sponsors > - Future where we have expensive reusable PQ or Contract public keys that= are > posted once and referred to by index >=20 >=20 > While, in a sense, current uses are much more concerning than future uses= , > with introspection opcodes, it might create substantive additional comple= xity > to ensure that there is always a valid way to add a padding byte without > upsetting a state machine. >=20 > As there are now documented use cases for 64-byte transactions that this > proposal makes more difficult to do, I recommend replacing the text in th= e BIP > that says >=20 > > 64-byte transactions can only contain a scriptPubKey that lets anyone s= pend > the funds, or one that burns them. >=20 > With something like: >=20 > > There are documented use cases for 64-byte transactions that this propo= sal > makes more difficult to cleanly do, but we do not believe these use cases= will > ever be valuable or worth protecting. >=20 >=20 > Or a more accurate reflection of the BIP-0054 authors' opinion. >=20 > Jeremy >=20 >=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+unsubscribe@googlegroups.com > . > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532- > 4f4cea2b83ecn%40googlegroups.com > 9532- > 4f4cea2b83ecn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoo > ter> . --=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/= 00a501dcd9b6%2459406560%240bc13020%24%40voskuil.org.