From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 06 May 2026 04:43:33 -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 1wKaf6-0004K2-TN for bitcoindev@gnusha.org; Wed, 06 May 2026 04:43:33 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-40ee506cf49sf8570955fac.2 for ; Wed, 06 May 2026 04:43:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1778067807; cv=pass; d=google.com; s=arc-20240605; b=fUuDNicKXwdKwi4Kq5/cEncv8X8lXMfx3fmKKhBq9l9v6roRlMY4ne9G9NVN8jegrg Y32K79kfKN9Q6RO1wytZPfCbjaNHQL3wt6cCAyEuhdyIHj25RshLn1NMqFWWWhyhABmj VylTu4Qci0ZLfZYMaUf0BkTJCLM1biMjsHwGaX33B7Rh5wM0ymKTRFCpZ7a8A6JnoQBF r7okuVQtESnAdv+CeIRCZYY7iPGw6OHG0iATIB5z71yulPVfn7JQrH5Ni1+RMubsLeIm PuQcm4T9lNcdv1+FTHa21iJXCwFfFy/wMaEZBpRsJ+f0R+kj8YXlRLbOAjqlyZsWhFd5 L7VQ== 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=6HVFzX36KfgpE+/kxUwdXoDWNYyg6Gdxyjoo7483jjc=; fh=JOL3fE/1m8Bx1Konm+JndI3/ZDb02gTkuK163rIj6EY=; b=G/4R8dFRxRdiLqJ+gRM7VIC4bdGfjTQZSblfG2LNDvREpVUI9H0LkdGopNGR4ge1a7 dDbvY0QkIm4nlsN+XoyjQNOfPiK8B4Oox29t5rjgRcmACdnJ4otsoo0cx49ApxtNSs5i vWzwBXEKiGRLfPwqbC+aLO8csj8RuALvi3u4ruOPrL9HufTk+2LDjCFrEQOQZEZGE39O IlO+69GdPgbRTjIfu5ph7r80rjVf9Eb20zc6w1VuPCn4/eHluwJ953beKt8cdY5uYjeV auefCzTLI+QFAF4qBF7YQxajq0ouvuPkGB5NdcYMIfFH9ujOtLtQoSnfUgOU9NcMLzsW T/fQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=xs+y2nH8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 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=1778067807; x=1778672607; 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=6HVFzX36KfgpE+/kxUwdXoDWNYyg6Gdxyjoo7483jjc=; b=EtECW8Wwpv1wIaS4elbchcaDkxrilpjQB9ffqRaW7klfD79a6Jmy1o+IiW1b1AdaWl KMPIh45C9KomIxzexfZW0sYXWKBDj5VLEqSWwt8iowYN1eGLxPwf9O9MpLbdypI9hs93 SmSdpmfSNRM6dWCMhuNmzCNsfIZZXSl8iUioqD3QuLBvX6visAvn0JiYU4r/Brt0zRdl MAy6SByO1j3w+eimjRwq5nUSex1qc8amNTV0TVKrAMzNTzYVX3d/bGXkWzCZDNgSHvuV klAO2PHZ/LqtZBfcRQDhOOCBg3JxPPAVBR6Iu+pyFBZ00OiV/T5+1JiussTYA807Rlxn 8uzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778067807; x=1778672607; 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=6HVFzX36KfgpE+/kxUwdXoDWNYyg6Gdxyjoo7483jjc=; b=eoczTkpcYQiXoHtjdWzMF7M5hBu/d82+4+YeuRtAWQ+WL0WiVgJ/IuOwoEmP29nghj 5U2Tddhv3i6luwTGZy1ejLOY8eDy72GcXK0OVzrOlh+PL3TSreEnadQbjj2yPvAQf/1D RQug9ZPfjmoYTEtS8WxP2sddGejZxFac9VA4mc/upNCG57l7n+PoRuPLL8Uw8fEaAkCJ 00RmH7lWLM6m9f3UZE+pPP6UKRk82eMLFzUiMeXQJCblODTLQWQwnTnuHSpQIUulICzM xYjGHZO5TVqvYx2GpgqZ1yTtkNR9Tq6bm4ftdh7qa83nh0X08nLE1n92flhwMNh8+V+3 OKhQ== X-Forwarded-Encrypted: i=2; AFNElJ966v/vBBEY78wusNJZ0hb8KuhHDtq43U/vdxOch6EFW6NgNA0kZggbjbfjTELHFLGdPciPnuswEWH1@gnusha.org X-Gm-Message-State: AOJu0YwHzY7tu3nguSeBk2kSR3uk2NgfmplsjXyCUsSnbhXYyF3V2U5z Ar5rLsvCenf7j3qzMknY7HljH1Gw5yHiB8RC26HPQDT+3ItEVshNmG0Y X-Received: by 2002:a05:6870:c18e:b0:42d:c200:4214 with SMTP id 586e51a60fabf-434f663b9ecmr1775101fac.18.1778067806397; Wed, 06 May 2026 04:43:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPKIaMZUntwHcfIccJY7ZBYZ72G4TzXVFoPAke+fhpBCQ==" Received: by 2002:a05:6870:d0ce:b0:416:1b5c:16df with SMTP id 586e51a60fabf-434300bd956ls4078774fac.2.-pod-prod-08-us; Wed, 06 May 2026 04:43:19 -0700 (PDT) X-Received: by 2002:a05:6808:c3ec:b0:46a:c987:ba00 with SMTP id 5614622812f47-4804246a6f8mr1724128b6e.32.1778067799564; Wed, 06 May 2026 04:43:19 -0700 (PDT) Received: by 2002:ab3:6203:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2fd82f4e006msc7a; Wed, 6 May 2026 04:10:19 -0700 (PDT) X-Received: by 2002:a05:651c:41d8:b0:38e:2fcc:78ed with SMTP id 38308e7fff4ca-393c3efed97mr13167261fa.0.1778065817033; Wed, 06 May 2026 04:10:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778065817; cv=none; d=google.com; s=arc-20240605; b=VX3usI+SEWI8QPYqg/ZtzV8bkWmXOgztCPraPp5jWQymihmRu/rhjhe8CNSDBYdS0V MTeZb3hhKEpDdZbcvph7L2clQPFEjdPrykTH1NKfgTzJ1C2nza6gXoLSb5yOlSlJMlcT SjkVx4eb/RqGutREBJeMGNqpFEIMe4z/ZcX7KxhwSeCSxyiGH051G6LCGcBFu+54/jIt YX9WzHaXgcDvZytCfqCqL9mvZ9v5hr+iecgBKepnSMmc4DmB+9jmTlSZSsGVpoGud/p2 7qT3MKOgNLHVNE8mHk58uYTKdhzT6lo5AsgQkPW6JfPnuqSQTT4NVnJBM3oqQgVfMU2c pB8A== 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=+dlwFtgmxWsjJ7EDkxgqzyzEUMvMRGxbsi/ufYK0dgM=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=EggcdhixQCWNqwISd9HYFYXlSgpjBXdpJBecIuhLhPvoW54rWeUC7al1gymdi14S5d 3mKIyJCKLWTG7nCirOLKbSg7h99kwCN2kyQmyZkZj/Zq8yIoNF3I6MoCqt3ewlCshFi3 iLmVdj8+yfNt5uQbP2/90r7bazlTwcrUCEo2nK3GMHYvU+k76OTbzxcWXUHOr4R78ZFy 9ariplwz4FJeqkv48EOw9S4HknnekZKPlDIgUD+eHfTzSrzCtMZtML5Vu59CGKP4wxF2 3Wtyw38eD5OtHS/aDnQMfu6VDTQjMzybis3g8P5htzK0EtdQjyD/kbXbHiCbffNOd4gN W54g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=xs+y2nH8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch. [79.135.106.118]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3936137a064si3452531fa.5.2026.05.06.04.10.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 04:10:17 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) client-ip=79.135.106.118; Date: Wed, 06 May 2026 11:10:14 +0000 To: jeremy From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses Message-ID: In-Reply-To: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> References: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 66f4928f1a4a3d5e15e0b2dc79d5dc19be72f89b 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=xs+y2nH8; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 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 Jeremy, Thanks for taking the time to lay out your objection here. I=E2=80=99m glad= we now have a clear statement of it. As AJ points out, your examples are all anyone-can-spend, so BIP 54 is corr= ect here. But it's fair that it could be clearer with regard to witness-strippe= d serialized size. Thanks for pointing this, i'll push an update. What's more important is your claim that invalidating 64-byte transactions could complicate working with advanced scripting features that may eventual= ly be added to Bitcoin. If that's the case i agree it should *at least* be discussed in BIP 54's rationale section. However, every time this was brought up, no one could come up with an examp= le that barely resembles today's Bitcoin. Of course one can come up with hypothetical constructions of a very different Bitcoin in which a 64-byte transaction could be useful. But that is not the goal. The goal is to find = a script for a 64-byte transaction that is *plausible* Bitcoin would adopt in= the future. And as long as we are going to have a model where coins commit to their spending conditions, a 64-byte transaction is always either burning the spe= nt coin's value or letting anyone spend it, regardless of the introspection or covenanty features that get added to these spending conditions. Therefore i do not currently see any plausible Bitcoin scripting upgrade th= at not only could not be designed to accommodate the 64-byte witness-stripped = size exception, but also whose usage could even result in a 64-byte transaction = in the first place. Antoine On Friday, May 1st, 2026 at 5:15 PM, jeremy wrot= e: > 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 BytesE) 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: > > 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 meani= ngful witness. For clarity, the restriction on bytes is on INVALID_TX_NONWI= TNESS_SIZE, not on the size with Witness. > 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 es= sentially 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 > 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 witho= ut 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 the = 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: > > 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 cas= es 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/bitcoinde= v/123e5545-2eda-4eca-9532-4f4cea2b83ecn%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/= A-Yiqh9r08Wd0V1KwMr7MlVObsiW3esWqySZZzm7aZBV3xBpL0qVJSpF07GfQBoq9YFpBLdlo0k= 2_tGU5CZ-i0_91MEketsaN8V4FpUnno0%3D%40protonmail.com.