From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 14 May 2026 07:11:19 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wNWmU-0006f3-Ja for bitcoindev@gnusha.org; Thu, 14 May 2026 07:11:19 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-439b8d149bfsf4695196fac.1 for ; Thu, 14 May 2026 07:11:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778767872; cv=pass; d=google.com; s=arc-20240605; b=FlSNO+TbGuK579l3hmB+0Owc6t4j9FNapeIUaek+9QxlCwwFYLf4faZluG41a5EawV 5NFASs0RfFNt/FdvwS7/3TQXup7MYL42TvvXnuyCY+6fTjvlIkgXoLaGioB9cH9Yi+ML ZGiNEga6Np5BjDX1UArZwjOAxC7B9sm8E966fdpRAl9bTAZ104HHqVKQFaGqSnVjbYgL XbAVvU9VXE9WfS+vkGcZvVUWuull2nMUmEtRXjCNAgigB46lMwPzbsn/ZuqQ6iAu/+8E n3GzrB8DxZwgzwvllED63PMpmzNzQmhzziNE0QUGQXyB0hFss3t63aJWLmA7+YCwrh/A fW9g== 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=W54NltlcTfQatKZW2z5Sgexq/RNCFKS8uuXcHPiq7n8=; fh=aERKHa5Hwuqq24zCyv0tRBxvJXnv7t9xjQ4LpX91/Ms=; b=fJQqd6Tkvs7PLcgrmTjl8r28PWiXla+ZcMwEFRQg6HCg6vmBO1NLFcIl51KGHw8hZQ 1nbwTyfvA5mcJ4kbmaXQA1uEc0mr5qbgXZwl4Edp1LQAwaKgHEEa/n/xt4fJHz+NYv+N ItR3ujIOk6ofRSmXynJtDm5WeS8OAf8KaUlAXF4r+obDqt3nxCqKvoTf2jO6KwUuisF1 kTx/NQsEYpfTqJmMeugsN7v1e44l2KocvvoIQXKeiePArlRgrjribUxkmExkg1/90eYR qJWFc6WJb9js6zCQluolKNtxzy/o+XNWjhzWZ8ugTuCaY3VpzFsLRy0yOk1D0qU8wELv rDWw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ZgVuYj5q; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 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=20251104; t=1778767872; x=1779372672; 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=W54NltlcTfQatKZW2z5Sgexq/RNCFKS8uuXcHPiq7n8=; b=o2gpnCzSU3MIA1W4cJfIt6YA/tIWEB6SYXaJXpYctv4r8LUXedxN5YCqX9e5jVpg6V vgx3s8TK36hRq0B/VIW4eT/7wjY6U9MmSi+YkgpUHviFLbxayIyD1bPvTgZX8UJOhT8W jb/Io/iaP3Sb6SY6C0MsA65qwMiYOCE3AWw7jcZuJfxSMScowL5d84meFx99LMsFPg4P 3IUgWsRTuPcfR9+yK+jrwxYIcJeuStvvFfyBS46+Sv8EIXgrx4NAE+8lrH1nW4T0Yik4 nVx0Qob2Gccz1LD37fRI0CCHY6IWvUC1/F0kwlkNTrV+OMirT+WD24TgGs3Iog5w103Q lGJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778767872; x=1779372672; 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=W54NltlcTfQatKZW2z5Sgexq/RNCFKS8uuXcHPiq7n8=; b=OGK4LRYyOrNZgthvivEgoPvxtlsCSlugndms6kZSbTosHYHCU+HcMXuXfyibuYfuD1 kHow4HrChjYxY6OF29FvLX5mddFXD7OOPogL2nZyCfgiN10LAUruJs4HMruPqU087DTg zNabILsSauu/YA6ygVIS6gbFijdHR+XhRqZ2EESF47faN8Zo2vEsOniaPA/GwVvK3MuS mbNOmLf47eLrckg7w3O07gI6Vhj2zLzQS3ad/xVk0DTNgJ8eJaO7cJcf5AFyYKHH9ZDa I3bgU3vDNX1b+P1DX3v15hc/c07vTc0X8QGRhD2k+hbCjAbtgXBfwfZ2NTNPQosdmx4/ sKQQ== X-Forwarded-Encrypted: i=2; AFNElJ+1I9HltVaKAB7prCZBTvNBICi2p25gapmqQeeadsHEBIrx1ahH8xzrLOSyHRJcz7l4dHBRz8LLDxAm@gnusha.org X-Gm-Message-State: AOJu0YxeOPMoQ5jsR+Dqtubbw+Zld6zjrKbWx69vvv7WfyIws7bpUkjY eKDu3TN0NpvG9IZg9vub8zvBYgAKMXoN5h1Q4IuCCk9cMW83yTbSkce1 X-Received: by 2002:a05:6871:3a0f:b0:417:435c:b9ef with SMTP id 586e51a60fabf-439ce0ebb25mr4478719fac.11.1778767872221; Thu, 14 May 2026 07:11:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMO20VGbSYwsoUUG3HCjyVOi1qVfnHKJ7nCniI9i1qnrVw==" Received: by 2002:a05:6870:6041:b0:430:2c03:d0f5 with SMTP id 586e51a60fabf-43a01129c5fls367762fac.0.-pod-prod-05-us; Thu, 14 May 2026 07:11:06 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/5zd95weSaykyNLbf4Lx3mV/DgyYkVS5dpLBtqezDx0yK0Y+FixT8mLcE/D7p4Ahy0q93ZnCwlNgmV@googlegroups.com X-Received: by 2002:a05:6808:2217:b0:47a:ae7:b604 with SMTP id 5614622812f47-482b2b60470mr5097943b6e.21.1778767866290; Thu, 14 May 2026 07:11:06 -0700 (PDT) Received: by 2002:a05:600d:8446:10b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-48fc9147e3fms5e9; Thu, 14 May 2026 06:50:53 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/8oxjS/+NsHHxHz7eo4821L4CFfkrHfcouh08zkKBZLFf/wwC5GRvdj6uxsYC0Wj7ABPO/kgD1QM00@googlegroups.com X-Received: by 2002:a05:600c:3e0c:b0:48e:6db3:ff2e with SMTP id 5b1f17b1804b1-48fc9a2ca70mr113265555e9.15.1778766651792; Thu, 14 May 2026 06:50:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778766651; cv=none; d=google.com; s=arc-20240605; b=S0wnwPzYI5E5WWo+1/05CrZl4fjD5vNHcsVBIGn6gZyznaQaIMORJXzc54m1SccRh6 +fdR8mx0alQVkgNooMt14U0nJrhWA+8lkEKk8lMg5xoFl+0i9EBFCKVcry8pcVx962jU ZSQM/dbQ/1FtbJvbspXXRVyPU1KwiPwz+QoFWEhOG3t9zlH0X0IMhJd7B/ZoAqxzTK2o qxslpPXmiLaipADcyfnZV8OM6kQeeCZZVGqaj2/uUtyIXrWCU7H24cAzb70Huq729Qi2 C+Gq+g87VX3BK4J7VDf/QhnCTw8vZPN8xwn9lQfQ21Yv+sFfakXoshXG+Yxn+eASG27H haVQ== 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=R9SK5jTWTSPnLRBophBzO0MBUZJSFaBmiae3ae/hJLc=; fh=WMvlZM7VfbkMWEedQvztCFiAhPdAQh1ok7iymfuuMos=; b=FWaQ/gmetsawoCl+o/0rJxe8Sn2mGjtLA0zn6myhHzMIun5Hg0+pmGpW9SlnI/opOp CkSNlMirwNiUijRafeYVFZQT8ZNk74uZhraA3RzG7kdGdSI+SY3wIxdLRHMbMJVUHeKj NdOzY8TdmanumifnuaQxuqzuB2QqcmA7xPtBvOs9sTuUJxRj6IcxPqJHM/bNYdo9mfqr uxSriV+K/KY40nwE/rjKBi6OABXo5T7/N5xtK+uZ3tmbli5woe8kixAkkG0G8TrUsPks H2GWQkWVXUKnRpNJJo7EhrrjCZxmzv7PaixDHxq60XsIpy8vHzzZpIva09VMrwAmZu4i XKaQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=ZgVuYj5q; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43101.protonmail.ch (mail-43101.protonmail.ch. [185.70.43.101]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-48fd70809b5si250295e9.3.2026.05.14.06.50.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 06:50:51 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 as permitted sender) client-ip=185.70.43.101; Date: Thu, 14 May 2026 13:50:49 +0000 To: eric@voskuil.org From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: 'jeremy' , 'Bitcoin Development Mailing List' Subject: Re: RE: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses Message-ID: In-Reply-To: <00a501dcd9b6$59406560$0bc13020$@voskuil.org> References: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> <00a501dcd9b6$59406560$0bc13020$@voskuil.org> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 8fd859823a8f24ea5ce1a966379e7103f519bf02 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=ZgVuYj5q; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.101 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 (-) Hi Eric, Fair enough. The BIP rationale should discuss explicitly your point that it= introduces a "seam", instead of just mentioning it in a footnote. Also i c= larified how the full node consensus failure point is not the motivation fo= r 64-byte txs invalidations since it can be better addressed differently, a= s you previously pointed. Changes here: https://github.com/bitcoin/bips/pull/2159. Also took Jeremy's= feedback that "64-byte transactions" should spell out that it refers to wi= tness-stripped serialized in more places than only the specifications. Best, Antoine -------- Original Message -------- On Saturday, 05/02/26 at 00:15 eric@voskuil.org wrote: 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 > > For fun, let's start with a pop-quiz: > > Select all that apply: There can exist a transaction of ___ bytes seriali= zed size > that BIP-0054's 64-byte restriction invalidates: > > A) 64 Bytes > B) 0 Bytes > C) 1.5MB > D) 32 Bytes > E) 5MB > > > The answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB. > > Why is this the case? > > BIP-0054 uses the term 64-byte transaction, but defines it as follows: > > > Transactions whose witness-stripped serialized size is exactly 64 bytes= are > invalid. > > 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. > > Therefore, it is more accurate to refer to this in all sentences througho= ut the > BIP as: > > > > transactions with exactly 64 bytes of non-witness data, > > due to the propensity for confusion. > > BIP-0054 also makes a comment that the transactions it invalidates are > essentially useless: > > > 64-byte transactions can only contain a scriptPubKey that lets anyone s= pend > the funds, or one that burns them. > > > This is not strictly correct. Here are a few examples of current and futu= re uses > for 64-byte transactions: > > 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. > > > 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 > > > 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. > > 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 > > > 64-byte transactions can only contain a scriptPubKey that lets anyone s= pend > the funds, or one that burns them. > > With something like: > > > 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. > > > Or a more accurate reflection of the BIP-0054 authors' opinion. > > Jeremy > > > -- > 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> . -- 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. --=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/= MgHn_5awXJ1_23y-bU1gDdEuxICa5pwAthGV4k2H3OHYvpTNLLZvfdXrCUxDvfdOjWAFAgF8KSj= yEX2-gB0776yVx8lRI_ztQTO9321HLg4%3D%40protonmail.com.