From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 28 Mar 2025 07:34:51 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tyAnK-00058y-Q0 for bitcoindev@gnusha.org; Fri, 28 Mar 2025 07:34:51 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-2c2d8a35eaasf1908779fac.0 for ; Fri, 28 Mar 2025 07:34:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1743172485; cv=pass; d=google.com; s=arc-20240605; b=SUvOz+4Cl4fIUWpfOyy8v9xPnzgLu4seyLlCQfK6SuCSceyz1XppZ30Ko7o2oAHCsa HA7bxPT80f8xMusrQAzdz9feAkPcuiypcXJ+NMo00R0y5fqfnUFIT7soxPxpwbRDYlBV YkPLDqr7krLaKbKaCejLMKGno+gxEZY3Em1reJlBpnwcMrtfhASYn/9VJOoYr96/BrAm 91rF1e5/hRDo8d6Qoi9B8Omp6pEizIIE/65JDuvSOFRdndoCe9VtFKONuzYzbVH/ZOjX v4ZVwNt1EwnxFVB/1S6CmpLW9vGR48c1jwZhF84X1j2QiZX6iZpBLxY6nKBUSMiORtiy Eykg== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=EpzI+KKeXD91UwTB4IVT/XCjFLXF8HYfnyxfI9MsltA=; fh=DSnhUqTUdmPz09drotFcd41+C/KpS5e25cIFEUZcHSM=; b=FTGecW3wNKDW4bBIh8/pMEGUpa3/UYyp+tHFGrXxPoDakwB1rk8z1LR6hWXT7ovOPR x0K7AQZnzfOhEoisruJdiiMcsFohxnNYgHBaJM6owAO12EuISG+QRD04UxBB4BfVevzR r7CPJOuSPkJ3RgMMXMPcDe4reeBC5oGEf01wQtXQd2nmyU+iJO1ifTA7ZTR3BZQsC6D5 d2wueCgZhmp2fzMWiUlTYwMP9O8rLfiN/BgV1K3xoCV9fpqgEBKBdJs8EMdstemlcbPg fsLxcAQ0YPeMnv366OKu6T5AZ/yvBzEMqjZKjFwa011SG7juk+xPJkeOQmJMpwhj1es8 xc3g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=dW359MQC; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b2d 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=20230601; t=1743172485; x=1743777285; 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=EpzI+KKeXD91UwTB4IVT/XCjFLXF8HYfnyxfI9MsltA=; b=AMpCQuLevHeOmUZOt/mqNjzxHhOV79UbCFdJ0c5mZ4hLT1odaXi1n8inwfCJuS2cA6 ICv/kqstPeCC7o7paX955hWJN76BwGX8rKQWQud0sMkZXFQ1+m/5BCG60lFM3D5k4FY7 SmM5Xf9nAs7BloBZCd+vxv0Nwt7iPdE/VSrW8zsopNd8tnHZ0Jwy8w/oedzDZV7y4DZE /DryoKxoy07DPaLjPcfgnIC9waiUetdJ4Br24vR67zxhktGPwIjed7FMqIougmUeOjyQ KTFUb85eD7RDXl8BoAQuKl5VpyRR9kgttL2ugA3FV5YvpD50B6jBQ+CzF5IMYKz/sEX/ Z00w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743172485; x=1743777285; 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=EpzI+KKeXD91UwTB4IVT/XCjFLXF8HYfnyxfI9MsltA=; b=ftak0JExvzHti+tTnu20MjUyl5oZEiBuqng4E5D4OVWXXluBqoRJDn1ae25rMdipXI VqpJpAcZx+UszYH+Dt7PG1/nDnEe9fogi80GvB9jdo4itpGImdGdYPazINeB1x405A05 muW67es0lWT0tENQujjJy8TO+hrwzldKnLKcYk/IZQMCVBPiHxWq656SluvuwMn1Ixis VZM+Vw0AgexWGeDwxMV2ZUmH2v5m05TPJjT5ItaUIxTneyWqtc9SJKq2qRM8N9TIyHXb ruWdPb/Z9giTZxWwXHZr9Zt0gAP4mp7gCq0XIxI0zv58lU0VNlIY9PR2HpsC9JA2veve d/xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743172485; x=1743777285; 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-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=EpzI+KKeXD91UwTB4IVT/XCjFLXF8HYfnyxfI9MsltA=; b=m0oTtgBGkvad3bertSN0arhpJO4LpNJ0zmCd9nf3cWWkCREkidH1UuNOURbewatHB7 CGxTqr+bY93vggOuBDkfAX37tnzkEQGT6w871nJhfmLU/tijO5yEVfxe8jGDSW/UHHfP X++aMUXkuKIYF7CQKKO/9MKxfmRA9+31CH6Kta7HS5GrfXEBlqpzlkFuzD3FZr2szwnT +evPWQj+keb8pvtUyRdCnhZK3Ob8emGdWK0/GJnaht8D0UyUUVGSDnTbDTZ0mYXXzrFH mjJBeVPj7mvpFFNY4NYrlVfy8DYOdZTXSBObFKjGRNlfNCB8HWkhGy+9OqrO2E29GLYW ZIbw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUWfRGtgL6zN8QXA7i2ScilDo8ir1HwbJG1weoiHt4PxCS0OWjZdqhgB4IiYjYsR2f8/uS9w1F/Z6D7@gnusha.org X-Gm-Message-State: AOJu0YzBnxI6IyKbhZa9Higu9efpPIWYlg2welvQrgOCNs/AAjILveQU +WlTb6qcx12/NxIHQ5Z+x3gIGVPLMKkraPtmvUItAFK8iu7TwWkL X-Google-Smtp-Source: AGHT+IE4dhe6Ik8M9pxMCM/8mXCPnuD6YrScpg3iBO7EMvdbMCaLGBrh1oQ4yN3YGGc8RI69Td9VrA== X-Received: by 2002:a05:6870:2891:b0:29e:569a:f90d with SMTP id 586e51a60fabf-2c84823dfeamr5103055fac.32.1743172484827; Fri, 28 Mar 2025 07:34:44 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKcfsw1geE3fcV2wkZRLqUTeMJ3EsWmGdnlR6igQUUAzQ== Received: by 2002:a05:6871:8d8c:b0:29f:bc7e:8f47 with SMTP id 586e51a60fabf-2c8470149a2ls652903fac.1.-pod-prod-09-us; Fri, 28 Mar 2025 07:34:41 -0700 (PDT) X-Received: by 2002:a05:6808:144e:b0:3f9:641b:63ef with SMTP id 5614622812f47-3fefa5c27b5mr5057261b6e.28.1743172481822; Fri, 28 Mar 2025 07:34:41 -0700 (PDT) Received: by 2002:a05:6808:2797:b0:3f6:a384:eb6f with SMTP id 5614622812f47-3feef8f0f2dmsb6e; Fri, 28 Mar 2025 06:55:05 -0700 (PDT) X-Received: by 2002:a05:6e02:2512:b0:3d5:81aa:4d0a with SMTP id e9e14a558f8ab-3d5ccdc959emr75402675ab.6.1743170104502; Fri, 28 Mar 2025 06:55:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1743170104; cv=none; d=google.com; s=arc-20240605; b=Bymw80n3vJKvDh+Gv+sEQlXQA/DmOiYO7xzPowS6tfNpkTdsTrE1u7QaI48x2IE8/7 Qkd1ADOHrdmRjRew18Oqr6rZjGd7EkRuTjR1KzeIxya2UGz5zHA3/nATYIH/BycKe/Gn 31IBKAczfRh1JPNQKZhSRP4fAEEQGL1YVa/OJwgxmVPKjeXghQVM2Vst4JIKYmJE5krE syTT1ug1NBcP4X/cHsUBI+c9o+iFOCJ+njgca6gzCRranOfzODntFdW0W9MD7Mwsh7BK gSoeDD53x9PNuR+7MoC0aAOZlfgJdyUEPNNITf0AX0J/7KXPzLbYw2ffKW2tADNtGW+u hzEw== 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=5GDTOHkG6dayl5oqko2qTPglO7jVJoOcEK8LDb/jK74=; fh=O/ornqcoA7r9FeoVIqy0bzOi0AZDoaGld/T7oI+UKaQ=; b=VOHPn8N1fmVkcyl3X7BYU7ARBtyFvCwl/njzCpbCaSAdYraZKbVafcmlc4YaDhWWNt YtXo7X7B7YMMrQOLSEMy6czUNi3RfIOk9j9t9+sRh7tWCzYG1N8CD0Lyn6KRrkMdXHu4 BLROPKpWn0WIjbD/m1kJBxFpwEvLUnFN8TgFgPL8nrozztGI9clu7arVIdLE+kgrEQmy DAXQzgGsH2z0Aa85xKR0u42arJXdENSnPjKjacbvAL+hrsQkc7dExExpi7PpfADOgfu4 ODOlZUweESLTE/IItutwwVOJFjeQqs14DIFFHdXvgdPTLozV4k7RuABqeCLpAXCJOcbW Crrw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=dW359MQC; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b2d 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-yb1-xb2d.google.com (mail-yb1-xb2d.google.com. [2607:f8b0:4864:20::b2d]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3d5d5af433fsi865055ab.4.2025.03.28.06.55.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Mar 2025 06:55:04 -0700 (PDT) Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b2d as permitted sender) client-ip=2607:f8b0:4864:20::b2d; Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-e69483d136eso1345926276.3 for ; Fri, 28 Mar 2025 06:55:04 -0700 (PDT) X-Gm-Gg: ASbGncv3D6SbOhMxKVlN0VTpUIPV/GAxNUzcXD3WPFIIC3M52o0oAqwUVatdDpLjAzw IMQLa/V2ERB2WPDgVVZstaQo3x0mCjCCDoYwQN0NsPuWEwA/ruV0bj2tPgKib5mdGRs6J3u6+Ni aXw6YRsqO1B9d/csLbnmkIfnqPlGCU X-Received: by 2002:a05:6902:1682:b0:e5d:b9a0:a14a with SMTP id 3f1490d57ef6-e694358e54fmr9880694276.24.1743170103663; Fri, 28 Mar 2025 06:55:03 -0700 (PDT) MIME-Version: 1.0 References: <17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D@sprovoost.nl> <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl> In-Reply-To: <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl> From: Chris Stewart Date: Fri, 28 Mar 2025 08:54:52 -0500 X-Gm-Features: AQ5f1JoZMyGRboL_-6S0K9mCJUn0yY__FQhkrHzVLyA_54N0IIfmly3AEq4spTA Message-ID: Subject: Re: [bitcoindev] Consensus Cleanup BIP draft To: Sjors Provoost Cc: Bitcoin Development Mailing List , jeremy Content-Type: multipart/alternative; boundary="000000000000cfe7680631676a75" X-Original-Sender: stewart.chris1234@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=dW359MQC; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b2d 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 (/) --000000000000cfe7680631676a75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Hi Sjors,* Sorry to be a bit pedantic here, but I think this distinction is important. Are you referring to a pre-SegWit transaction or a SegWit transaction? It= =E2=80=99s crucial to analyze these separately, as SegWit was designed to solve transaction malleability, which affects how we assess backward compatibility concerns when disallowing 64-byte transactions. In the future, it would be helpful to explicitly specify =E2=80=9Cpre-segwi= t=E2=80=9D or =E2=80=9Csegwit=E2=80=9D when discussing potential transactions. In my draf= t BIP , I differentiate between these two types when evaluating the backward compatibility risks of disallowing 64-byte transactions. Additionally, as I mentioned earlier (and as I believe Jeremy has also raised concerns about), there are potential *future* compatibility issues with segwit transactions. I'll take a closer look at the Stack Exchange examples and share my thoughts there when I have a bit of time. Thanks for diving into this in detail=E2=80=94I really appreciate it. *- Chris* On Fri, Mar 28, 2025 at 7:48=E2=80=AFAM Sjors Provoost = wrote: > Hi Chris, > > Thanks for that example. > > I also realised that there indeed can exist 64 byte transactions that > can't be malleated into a different size (see Stack Exchange link below). > The example uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so as long as our > hypothetical smart contracting system uses those flags for its burn-all / > giveaway-all clauses, then if it produces a 64 byte transaction by mistak= e, > it's recoverable. > > But a SIGHASH_ALL could get stuck (can't be confirmed, can't be modified)= . > And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, once > committed inside a CTV tree, can't be modified. > > - Sjors > > Op 28 mrt 2025, om 12:02 heeft Chris Stewart > het volgende geschreven: > > Hi Sjors, > > An example is any segwit transaction that 1 input 1 output that pays to a > 2 byte witness program. Since witness data doesn't count towards the 64 > byte limit, the witness could be of arbitrary size. This was pointed out > > by garlonicon on > delvingbitcoin. This type of witness program is used for pay-to-anchor > outputs currently - although I don't believe anchor outputs make sense in= a > 1 input 1 output transaction? The author of pay to anchor outputs is awar= e > of this issue > , > but I haven't heard of any further updates since his post on delving. > > -Chris > > On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM Sjors Provoost wrote: > >> >> > Op 27 mrt 2025, om 21:45 heeft jeremy het >> volgende geschreven: >> > >> > I'm also personally strongly against removing 64-byte transactions. >> It's a wart in how transactions work, and future upgrades (especially >> around tx programmability) might integrate very poorly with this kind of >> edge condition. >> >> Do you have an example in mind where a 64-byte transaction could appear >> in such a system? >> >> Given the limited space, in particular no room for a public key or >> signature, I could imagine a burn or anyone-can-spend clause. Those don'= t >> have to be exactly 64 bytes. Even if 64 byte transactions are generated = by >> accident, I believe they can be tweaked after the fact (though that clai= m >> could use more scrutiny): >> >> https://bitcoin.stackexchange.com/q/125971/4948 >> >> > --=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%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh%3Da3ag%40mail.gmail.co= m. --000000000000cfe7680631676a75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Sjors,

Sorry to be a bit pedantic here, but I think this disti= nction is important. Are you referring to a pre-SegWit transaction or a Seg= Wit transaction? It=E2=80=99s crucial to analyze these separately, as SegWi= t was designed to solve transaction malleability, which affects how we asse= ss backward compatibility concerns when disallowing 64-byte transactions.

In the future, it would be helpful to explicitly specif= y =E2=80=9Cpre-segwit=E2=80=9D or =E2=80=9Csegwit=E2=80=9D when discussing = potential transactions. In my draft BIP, I differentiate between these two types when eva= luating the backward compatibility risks of disallowing 64-byte transaction= s. Additionally, as I mentioned earlier (and as I believe Jeremy has also r= aised concerns about), there are potential future compatibility is= sues with segwit transactions.

I'll take a closer look at the Stack Exchange examp= les and share my thoughts there when I have a bit of time.

Thanks for diving into this in detail=E2=80=94I really = appreciate it.

- Chris


On Fr= i, Mar 28, 2025 at 7:48=E2=80=AFAM Sjors Provoost <sjors@sprovoost.nl> wrote:
Hi Chris,

Thanks= for that example.

I also realised that there inde= ed can exist 64 byte transactions that can't be malleated into a differ= ent size (see Stack Exchange link below). The example uses=C2=A0SIGHASH_SIN= GLE | SIGHASH_ANYONECANPAY, so as long as our hypothetical smart contractin= g system uses those flags for its burn-all / giveaway-all clauses, then if = it produces a 64 byte transaction by mistake, it's recoverable.

But a SIGHASH_ALL could get stuck (can't be confirmed= , can't be modified). And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGH= ASH_ANYONECANPAY, once committed inside a CTV tree, can't be modified.<= /div>

- Sjors

Op 28 mrt 2025, om 12:02 heeft Chris Stewart <stewart.chris1234@gmail.com<= /a>> het volgende geschreven:

Hi Sjo= rs,

An example is any segwit transaction that 1 in= put 1 output that pays to a 2 byte witness program. Since witness data does= n't count towards the 64 byte limit, the witness could be of arbitrary = size. This was pointed out b= y garlonicon on delvingbitcoin. This type of witness program is used f= or pay-to-anchor outputs currently - although I don't believe anchor ou= tputs make sense in a 1 input 1 output transaction? The author of pay to an= chor outputs is aware of this is= sue, but I haven't heard of any further updates since his post on d= elving.

-Chris

On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM Sjors Provoost <sjors@sprovoost.nl> wrote= :

> Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail.com> het volg= ende geschreven:
>
> I'm also personally strongly against removing 64-byte transactions= . It's a wart in how transactions work, and future upgrades (especially= around tx programmability) might integrate very poorly with this kind of e= dge condition.

Do you have an example in mind where a 64-byte transaction could appear in = such a system?

Given the limited space, in particular no room for a public key or signatur= e, I could imagine a burn or anyone-can-spend clause. Those don't have = to be exactly 64 bytes. Even if 64 byte transactions are generated by accid= ent, I believe they can be tweaked after the fact (though that claim could = use more scrutiny):

https://bitcoin.stackexchange.com/q/125971/4948

--
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%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh= %3Da3ag%40mail.gmail.com.
--000000000000cfe7680631676a75--