path: root/da/da3c486301ce0581d79b0fb087c001fd575e51

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 <bitcoindev+bncBDML5DFJWQEBBAXHTK7QMGQEK2NMAPA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com>
 <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com>
 <TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4=@protonmail.com>
 <afedbc69-8042-4fe8-99c2-279173a440f3n@googlegroups.com> <17A67D4A-3EF4-4676-8356-B1DE6B0C2D8D@sprovoost.nl>
 <CAGL6+mE8JQGJErgJH03sz8Nzo+wkgx74jgFWp7hFT0MuHiPg_g@mail.gmail.com> <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl>
In-Reply-To: <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl>
From: Chris Stewart <stewart.chris1234@gmail.com>
Date: Fri, 28 Mar 2025 08:54:52 -0500
X-Gm-Features: AQ5f1JoZMyGRboL_-6S0K9mCJUn0yY__FQhkrHzVLyA_54N0IIfmly3AEq4spTA
Message-ID: <CAGL6+mHuVgWc9ATjRnBz+b7SJyz84La8q9jeM=yiw-Anh=a3ag@mail.gmail.com>
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
To: Sjors Provoost <sjors@sprovoost.nl>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>, jeremy <jeremy.l.rubin@gmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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
<https://github.com/bitcoin/bips/blob/a3d12410d3e3361932e44f34f8420331cf5f9=
b59/bip-XXXX.mediawiki#backward-compatibility>,
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 <sjors@sprovoost.nl>=
 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 <stewart.chris1234@gmail.com=
>
> 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
> <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=3D=
chris_stewart_5>
> by garlonicon <https://delvingbitcoin.org/u/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
> <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=3D=
chris_stewart_5>,
> 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 <sjors@sprovoost.n=
l> wrote:
>
>>
>> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail.com> 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

<div dir=3D"ltr"><p class=3D"gmail-"><strong>Hi Sjors,</strong></p>
<p class=3D"gmail-">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.</=
p>
<p class=3D"gmail-">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 <a href=3D"https://github.com/bitcoin/bips/bl=
ob/a3d12410d3e3361932e44f34f8420331cf5f9b59/bip-XXXX.mediawiki#backward-com=
patibility">draft BIP</a>, 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 <em>future</em> compatibility is=
sues with segwit transactions.</p>
<p class=3D"gmail-">I&#39;ll take a closer look at the Stack Exchange examp=
les and share my thoughts there when I have a bit of time.</p>
<p class=3D"gmail-">Thanks for diving into this in detail=E2=80=94I really =
appreciate it.</p>
<p class=3D"gmail-"><strong>- Chris</strong></p></div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fr=
i, Mar 28, 2025 at 7:48=E2=80=AFAM Sjors Provoost &lt;<a href=3D"mailto:sjo=
rs@sprovoost.nl">sjors@sprovoost.nl</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div>Hi Chris,<div><br></div><div>Thanks=
 for that example.</div><div><br></div><div>I also realised that there inde=
ed can exist 64 byte transactions that can&#39;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&#39;s recoverable.</div><d=
iv><br></div><div>But a SIGHASH_ALL could get stuck (can&#39;t be confirmed=
, can&#39;t be modified). And IIUC with OP_CTV even a SIGHASH_SINGLE | SIGH=
ASH_ANYONECANPAY, once committed inside a CTV tree, can&#39;t be modified.<=
/div><div><br></div><div>- Sjors</div><div><div><br><blockquote type=3D"cit=
e"><div>Op 28 mrt 2025, om 12:02 heeft Chris Stewart &lt;<a href=3D"mailto:=
stewart.chris1234@gmail.com" target=3D"_blank">stewart.chris1234@gmail.com<=
/a>&gt; het volgende geschreven:</div><br><div><div dir=3D"ltr"><div>Hi Sjo=
rs,</div><div><br></div><div>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&#39;t count towards the 64 byte limit, the witness could be of arbitrary =
size. This was <a href=3D"https://delvingbitcoin.org/t/great-consensus-clea=
nup-revival/710/74?u=3Dchris_stewart_5" target=3D"_blank">pointed out</a> b=
y <span><a href=3D"https://delvingbitcoin.org/u/garlonicon" target=3D"_blan=
k">garlonicon</a> on delvingbitcoin. This type of witness program is used f=
or pay-to-anchor outputs currently - although I don&#39;t believe anchor ou=
tputs make sense in a 1 input 1 output transaction? The author of pay to an=
chor outputs is <a href=3D"https://delvingbitcoin.org/t/great-consensus-cle=
anup-revival/710/78?u=3Dchris_stewart_5" target=3D"_blank">aware of this is=
sue</a>, but I haven&#39;t heard of any further updates since his post on d=
elving.</span></div><div><span><br></span></div><div><span>-Chris</span></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM Sjors Provoost &lt;<a href=3D"ma=
ilto:sjors@sprovoost.nl" target=3D"_blank">sjors@sprovoost.nl</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
&gt; Op 27 mrt 2025, om 21:45 heeft jeremy &lt;<a href=3D"mailto:jeremy.l.r=
ubin@gmail.com" target=3D"_blank">jeremy.l.rubin@gmail.com</a>&gt; het volg=
ende geschreven:<br>
&gt; <br>
&gt; I&#39;m also personally strongly against removing 64-byte transactions=
. It&#39;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.<br>
<br>
Do you have an example in mind where a 64-byte transaction could appear in =
such a system?<br>
<br>
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&#39;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):<br>
<br>
<a href=3D"https://bitcoin.stackexchange.com/q/125971/4948" rel=3D"noreferr=
er" target=3D"_blank">https://bitcoin.stackexchange.com/q/125971/4948</a><b=
r>
<br></blockquote></div></div></blockquote></div><br></div></div></blockquot=
e></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAGL6%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh%3Da3ag%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/bitcoindev/CAGL6%2BmHuVgWc9ATjRnBz%2Bb7SJyz84La8q9jeM%3Dyiw-Anh=
%3Da3ag%40mail.gmail.com</a>.<br />

--000000000000cfe7680631676a75--