From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 02 May 2026 08:56:33 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wJChk-0005MG-7Z for bitcoindev@gnusha.org; Sat, 02 May 2026 08:56:33 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7dbbb806e10sf7042533a34.1 for ; Sat, 02 May 2026 08:56:31 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1777737386; cv=pass; d=google.com; s=arc-20240605; b=Oa3z6yB4f47bsyyQobJJzNNjLeJxRg2/q7zrPZFIF+/SdfKjHJPd4y7noT14EzgOxf GDdS1qeK+qSWZ+0G+z1evzSHJJpCiAT9UwpvcrHdWlnAAZtBT9q2GJpv36O4Eebs/cEx ciGrn6sGX7EDnFFtV6ufvETbL/BE+NM03G9Ht8XAOKgijpkB6bgcHaURB/C8TqmNG1b0 g5A0tbE/zCsMv+o+7/Egap7UJevj/G9PMb10ZZtfMz9EP0mWJVXW509FoGLcyK5somMz wfXkqaflg4NbWGtMQI6VMvKFczTTdJiLvrTql8eK4aKI3Dp+6XaOiZnJuctQI2CX0vZ5 fzaA== ARC-Message-Signature: i=3; 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=DZiGNaEqenj1OTf8rhPCtvV5vARqHV8IrtdXSefb0N4=; fh=3lORiloAEFifaQ39ZeB0BqWa4edv2EtI0hP9o8G9viM=; b=A4t4q2+GdK0H0gUe6G61QD0YKv4AyX9SDlg2MkYgKF+KCQm62wc959rtlg9wd7K+QL weRb5t9P2pyvlVnxED8HovjCTUOnJbXwFbg7cjb8MI8/2AMQV2I5zCyEbioYksA3nIjI V0CfYjT1c1nRHdtu5xjwjFCCFV1a4AdrcmpzVpTR7gnlENeIZkYcdWKR43fBnRbtqYMh hspJAebniH9bT3HUTUSRZHNcpFdFuNzMT+c3+46m51DekNynSXLnwDttsfdPPV2AtnMO 43EoSXRRuMhCm0DvZCwaXCbiL2KvpXlUjZmqN5NjQNV7MAHLR8ip86f7lhQO6e8YE6wk HHMg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=BGiFMrRd; arc=pass (i=1); spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=stewart.chris1234@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=20251104; t=1777737386; x=1778342186; 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=DZiGNaEqenj1OTf8rhPCtvV5vARqHV8IrtdXSefb0N4=; b=UKfFN1CBySt9y7Wnh/0JP4VFLChz7lGli504+wFjrnvd2DXZRZc0CJPnLhUcv5Gd70 QKcf8q33Q15MZwwjcMGbBvW1Y0uO+lL7pOrfBvTQn4K/mE2zcmJTe+k+/XiGXbBZOwaT kUDDolgLTG5f39+M0gqAAs9H81RSa7Fj0/SoT8jQ6tslVgo3W6Csg6R5m7qpb1k3ZHHp qqWd5tQymQEwq0K5/5e9yVhemc6CKYZKe9iSybQEX31xWSlzBOxxSVwMzadl95d3eAR3 jWKwtMZOPQ673Hy3yJ0qFarc6a5FniboQ3QkvpvBKXsJ8SXlJggzAvufD+QGlyPff7+5 nhOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777737386; x=1778342186; 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=DZiGNaEqenj1OTf8rhPCtvV5vARqHV8IrtdXSefb0N4=; b=WAbjqWKUwcZkjlquZ2BIugVOvjdx9OrPm/yEjPxd042ZznoO1lPYo0c5MJelkuHW9w g3jbg3QpcPhLp4MrjZiYiIxiUHOtzjtuAJdUsJG3zha1LPEgXlNmjew0Hx2O9LEEL9mX RBxqqhAK0hAZoQY/M+7fTGNghwrRWAFEfIZEYSIfrVu7RYdM2Vs7po6UDV0ZOgmmyw57 Fwr+MseHgWhKarQzhYWnVCpjtxptr5sfykAu2/snbqg7M11Obn20KFL3kuvSNwcsr+fb w9Qnp9YWx4KXN2IrjCXGEnxQhBDxpKZgWY7126o8PdXmbYBy4377s9lzNxv8jhO+5/Ae j5FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777737386; x=1778342186; 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-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=DZiGNaEqenj1OTf8rhPCtvV5vARqHV8IrtdXSefb0N4=; b=Q+A82xA71RN/OwcFBW8C5B5XCj91mntJ2NeWphEPs/x3wfhIVwz6DW2nayDp2MRFCJ vv5Cnd/Qfl1UwWxpbWpfSrewFRi4wc8MFTcaquila6O0aBdkkUEcnxQZyJ7NJOuWsQMP X32qaisCjlq9T+bWktWyDCOaXPAEkV54wUZOm9j5wrQyHLswNqCMQNwxgB1QNJ4bEkXP pQYbDDICTNY77YS5Kb2DQVYY5KCiTdtJLaId8dzaZcc+G6h+tPhw+QA0Fcc+a2U2p1Lw xBPiUqiRYqXy5eLJHY43exCuqj5Fd/CzN+SGsCOZDhTap/gtY733+QNLGzVv5hXHq9v/ Z2jQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/XBzAkLvRADnud2ZMlmnoCGbdGszXRQvFfaMSp+wfmo5xleNcCx2kFNpX9yJXk/PyNluBfdjO4HIO3@gnusha.org X-Gm-Message-State: AOJu0YyAGHrQ0S6I8/XCMKihOgjq7vWfkZvm7sG1nyGF8EuUfLTCSUAe UdPFoGir4BGXjfWKuFN8eKmeB7HOS+I9ZTbplYQnvQ0xLb/XawBgfhXT X-Received: by 2002:a05:6820:827:b0:696:15ed:6a09 with SMTP id 006d021491bc7-69697a0a780mr1701662eaf.24.1777737385480; Sat, 02 May 2026 08:56:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOXvXMpIssis3cxu95mp6D1kk6UjBp7Ib7MoQQNiTt0VA==" Received: by 2002:a05:6820:1693:b0:67d:fa47:dad3 with SMTP id 006d021491bc7-696790e44a9ls2139096eaf.2.-pod-prod-03-us; Sat, 02 May 2026 08:56:21 -0700 (PDT) X-Received: by 2002:a05:6808:1983:b0:460:f435:2a70 with SMTP id 5614622812f47-47c8933833bmr2164399b6e.47.1777737381154; Sat, 02 May 2026 08:56:21 -0700 (PDT) Received: by 2002:a05:600c:22d0:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-48a96edf642ms5e9; Sat, 2 May 2026 08:26:29 -0700 (PDT) X-Received: by 2002:a05:600c:3495:b0:485:364e:9328 with SMTP id 5b1f17b1804b1-48a988a2284mr49674685e9.16.1777735587586; Sat, 02 May 2026 08:26:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1777735587; cv=pass; d=google.com; s=arc-20240605; b=DGwmWko5ayR8THAsBzKrPzwqM2ctOh4fn9W25Nl5UHT1O8DE26Zji/1DQQgyCKPmsO JNNi8GDMNDmM/TRwqjTm7X81Lamu28P0RBelUp0FlZ0OGAOkeNBx8eyXLeWhJfb3TBW9 PSF+vHSrJkWg8kLbJV16tJbU9uI35eYQz1n89ghUIFMKF6lw1evL+zbShpBX+Y5/2Wnv YbqQNJt5cnxPYKCSnIn+8qqSCELlnenaBWTaK3utwzg1zDhIq+phigVTM6hE2cgJEkGs QzQEN35cgQqVXTQL3pQraPJ3iRZj8+lfFmuCGJEr7I/iP8OtqXvNY2rTYwWMT5rI8K1w KtaA== ARC-Message-Signature: i=2; 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=2vfKt8zNXRFM+i/0chtPa65gOegWhyb9Rn3lY3jPslo=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=lxYF3RxZPYagR/J6OPSxfBTxvuOMjmkFNLjH3IIBDgfZYx7sj1Hxdd44oTsJ1HNDar C7Y5kasXpOokWzbY47LntlM0ANrOQ5/ombhgJ1A109M8DUfm2S5RWjdbuw6eOJKeMRVW QkiOrYxzt3zDGpLT6nsf+i0jeqvluezKzEJi/8AtrRJekUCEZcLZH9zRNRCQNlrnQD/A IjSlThNLocwRL8ihqfQAZQX28ZO2avUHR0ggw8n2TwWPTWEAn4CuR48oj/K4RpYAD7pS w981GesOzPOxnPTh+CXfiIVXFWzCz4Wuwt174cjk+bsUbt6ky22JHNM9eAZ5apgPeTuI ibFg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=BGiFMrRd; arc=pass (i=1); spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com. [2a00:1450:4864:20::12f]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-48a8eb80dc6si917105e9.2.2026.05.02.08.26.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2026 08:26:27 -0700 (PDT) Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) client-ip=2a00:1450:4864:20::12f; Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a3d42263e4so3504283e87.2 for ; Sat, 02 May 2026 08:26:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777735587; cv=none; d=google.com; s=arc-20240605; b=hwVVf9mhirsv+u2yuBzVlDBgO8VhpC+46UDpB/crUPpNLvpWvrhqP2Vf7EIEUQJg7l lMtagd/BnjFlNHlYDLsKI5CC+eThR0TKyWHJ/4CCAzwgnNSGXIMSt8+eyn4FNTDvgsbw xEleAXiZHP68OvB9Kemz6i0w+7CWUrFi5Sgj5sj6jptTGDdBRfAV1OI9iZnhA25prdWG fXfH/62iffy6exmyyHK7VLbqs+Jb9ru1MItlLcSY1p7HmGfaAKr9OxaYXv0XOKsikOih LxApE2WMjooGc0lQCdp1TvSZTzR0r+tmuyE6lUFMKP5s5HBnIMQXZ5ZBFqylDUBhpl3T VJ0Q== 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=2vfKt8zNXRFM+i/0chtPa65gOegWhyb9Rn3lY3jPslo=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=Vlnkk+OtyT9dRJLV+ZOHFKEd9TkpwbOTITz+jOIBJuNV3PUNMwUF3jBte2jRnsEi2a GlkCKywtRH61bv8uB3hIVBzVmHWlntiez4bmkJYkOByNznV0ROrwQ/aManrdcEjBF+Kk cM5He3Tl9qj7HeA/plw7h6gIP8sQIxGNhl2EEdqIVFCSa21lZ97er0ebVUSvgCA3ivxB nZrnHvknna8o7BNPdiY2A460xswSXdXIa/D3Eqd3dtIKqshLyZ1afe8IUwBHxPqexhzV 3rGKVYaNO3+GguaUepWq17zA+9XF2eVv5tTwGS1mHQCd575IaETOY2XjGxM7Nt9gqpP/ D/Bw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDieuWVAF0jDD9wlv6WJOR9D36vidqkc9OCb4hW9PptGTAgKxRQ125XoJXgfyg72J 3zUw6HnAYLw3oUp2q7ls1snwafAFoInwNwOb5rXlePklmR+5U+VeMX+SKPN/7g9GXLNxYRwf4wE eDO+APyTe0wRhdrmPjuWdJnvi6Jeq/8r703g4TPG/6ZZT6Pr3h1ebYrBaKEfyvdU9d2e0rvz+l3 imMs2PeAnqeMmLPrVzfzpeIDqhkGZREsZoiT0UpT2RTewlr5b1qsCNBu9KALC1V5Fza1LySp9ZY gKU8jcuaUc03TOPGyA== X-Received: by 2002:a05:6512:4007:b0:5a4:74e:5f75 with SMTP id 2adb3069b0e04-5a862ec0f9emr837721e87.1.1777735586487; Sat, 02 May 2026 08:26:26 -0700 (PDT) MIME-Version: 1.0 References: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> In-Reply-To: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> From: Chris Stewart Date: Sat, 2 May 2026 10:26:15 -0500 X-Gm-Features: AVHnY4LFc36vj8VNPzw7WAMFNoeSQdiN170qLg1I7p5ghV3nK3PZUdUIF3PuyO8 Message-ID: Subject: Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses To: jeremy Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000002320a90650d752c1" X-Original-Sender: stewart.chris1234@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=BGiFMrRd; arc=pass (i=1); spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=stewart.chris1234@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 (/) --0000000000002320a90650d752c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do concede your point that witness stripping isn't well understood by the general community. Here is a writeup I did for readers of the mailing list that may not understand what Jeremy is talking about the characteristics of a 64 byte transaction[0]. There is a big distinction between pre-segwit 64 byte transactions and segwit 64 byte transactions. > 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) I find this confusing. Can you give 2 hex encoded transactions (funding transaction, spending transaction) that do this? regtest is fine, i can just decode locally. Splitting hairs semantically if understand the transactions you are proposing above, "donating" to a "future miner" i.e. sending money to *anyo= ne (not a specific someone)* in the future that can mine a block - doesn't seem much different to me than "anyone can spend the funds". I'll await your transactions though in the case that I am missing something. [0] - https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73?u=3Dchr= is_stewart_5 On Fri, May 1, 2026 at 4:15=E2=80=AFPM jeremy wr= ote: > For fun, let's start with a pop-quiz: > > Select all that apply: There can exist a transaction of ___ bytes > serialized 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 byte= s > are invalid.* > > In a [personally run] straw-poll of devs at a recent conference, no-one > knew this precise edge condition or that the transactions could have a > meaningful 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 > throughout 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 > spend the funds, or one that burns them.* > > This is not strictly correct. Here are a few examples of current and > future 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 > should 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 sh= im > 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 > complexity to ensure that there is always a valid way to add a padding by= te > 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 > spend the funds, or one that burns them. * > With something like: > > *> There are documented use cases for 64-byte transactions that this > proposal 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-4f4c= ea2b83ecn%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/= CAGL6%2BmGeqx8TvWSfSg_FdrbHVy%2B3Sk5VmQ%2B_WPjGjhXbp%3DLiBA%40mail.gmail.co= m. --0000000000002320a90650d752c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do concede your point that witness stripping isn= 9;t well understood by the general community. Here is a writeup I did for r= eaders of the mailing list that may not understand what Jeremy is talking a= bout the characteristics of a 64 byte transaction[0]. There is a big distin= ction between pre-segwit 64 byte transactions and segwit 64 byte transactio= ns.


> A transaction that donates= to a future miner from a segwit (any=20 version) output via a spend to something like <512> OP_CSV (->=20 push2 bytes 512 csv -> 0x02 0x00 0x02 0xb2)

I find=20 this confusing. Can you give 2 hex encoded transactions (funding=20 transaction, spending transaction) that do this? regtest is fine, i can=20 just decode locally.

Splitting hairs=20 semantically if understand the transactions you are proposing above,=20 "donating" to a "future miner" i.e. sending money to anyone (not a specific someone) in the future that can mine a block - doesn't seem much different to m= e than "anyone can spend the funds". I'll await your transacti= ons though=20 in the case that I am missing something.


On Fri, M= ay 1, 2026 at 4:15=E2=80=AFPM jeremy <jeremy.l.rubin@gmail.com> wrote:
For fun, let's start with a pop-= quiz:

Select all that apply: There can exist a tra= nsaction of ___ bytes serialized size that BIP-0054's 64-byte restricti= on invalidates:

A) 64 Bytes
B) 0 Bytes
C) 1.5MB
D) 32 Byt= es
E) 5MB


The answer is A, 64 Bytes, and -- perhaps surprisi= ngly -- C, 1.5MB.=C2=A0

Why is this the case?

BIP-0054 uses t= he term 64-byte transaction, but defines it as follows:

= > Transactions whose witness-stripped serialized size is exactly 64 b= ytes are invalid.

In a [personally run] straw-= poll of devs at a recent conference, no-one knew this precise edge conditio= n or that the transactions could have a meaningful witness. For clarity, th= e restriction on bytes is on INVALID_TX_NONWITNESS_SIZE, not on the size wi= th Witness.

Therefore, it is more accurate to refer to t= his in all sentences throughout the BIP as:

> transactions with exactly 64 bytes of non-witness data,
<= div>
due to the propensity for confusion.

BIP-0054 also makes a comment that the transactions it invalidates ar= e essentially useless:

> 64-byte transaction= s can only contain a scriptPubKey that lets anyone spend the funds, or one = that burns them.

This is not strictly corr= ect. Here are a few examples of current and future uses for 64-byte transac= tions:

Current Uses:
- = A transaction that donates to a future miner from a segwit (any version) ou= tput via a spend to something like <512> OP_CSV (-> push2 bytes 51= 2 csv -> 0x02 0x00 0x02 0xb2)
- That same output which is used= as a connector output for things that should be claimed by a miner at a fu= ture time
- Pay-to-Anchor / ephemeral anchor outputs -- while ty= pically p2a is for txns you want to add a subsidy ability, a 64-byte txn co= uld be used to shim a keyed anchor to a p2a output after a certain delay.

Future Uses:
- Future work whi= ch might use output scripts for e.g. Transaction Sponsor encodings
- Future covenants work which encodes time-of-creation run scripts t= hat e.g. quine an input; possibly in conjunction with sponsors
<= div>- Future where we have expensive reusable PQ or Contract public keys th= at are posted once and referred to by index


While, in a sense, current uses are much more concerning than futu= re uses, with introspection opcodes, it might create substantive additional= complexity to ensure that there is always a valid way to add a padding byt= e without upsetting a state machine.

As there are now documented u= se cases for 64-byte transactions that this proposal makes more difficult t= o do, I recommend replacing the text in the BIP that says

> 64= -byte transactions can only contain a scriptPubKey that lets anyone spend t= he funds, or one that burns them.

With something like:

=
> There are documented use cases for 64-byte transactions = that this proposal makes more difficult to cleanly do, but we do not believ= e 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 &= 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/123e5545-2eda-4eca-9532-4f4cea2b83ecn%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.= com/d/msgid/bitcoindev/CAGL6%2BmGeqx8TvWSfSg_FdrbHVy%2B3Sk5VmQ%2B_WPjGjhXbp= %3DLiBA%40mail.gmail.com.
--0000000000002320a90650d752c1--