path: root/35/7a774b3935d4215c86d5d83bbd906c18c77a54

Delivery-date: Fri, 28 Mar 2025 07:34:48 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABB7XGTK7QMGQEDW6HXRA@googlegroups.com>)
	id 1tyAnH-00058o-Kb
	for bitcoindev@gnusha.org; Fri, 28 Mar 2025 07:34:48 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-6025b3cfff5sf499454eaf.3
        for <bitcoindev@gnusha.org>; Fri, 28 Mar 2025 07:34:47 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1743172482; cv=pass;
        d=google.com; s=arc-20240605;
        b=IOR8/W7NX1rhENUIekKfPFHU8RKL3jCwoUEpqbGVGB8U35vTSKuVPT4cXm/URyHeqa
         U4Ata0sHOghh6PYzH4wfMBF0GvH0iXKeLbCNACZkGVLTnXMidbpESelwgT++pQOdVMLB
         297HVYe3FBOQqx7E9BReENnmYXmYy7Xyz8ItTgOwRM/zvwKxhBRfwtAOA9pKPt4jA2UR
         35n83g0dV/NaF5ShQqPYPj2tYYFTZ8H/ycF0YkDFvV1WNSwC7sqgRd4fhGSOxguQOB+7
         oyAfwAO5yh469SzHbsuMdpjH57q/qldiIx3XFGrbyXBmh9y/jLRJgyxt0N5YOYKlxVN1
         tofA==
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:references:to:cc:in-reply-to:date
         :subject:mime-version:message-id:from:feedback-id:sender
         :dkim-signature;
        bh=8kbi1cIeEYpPKk/1KCv+Gkt5hjWjAJcS+ooQ56B7u3k=;
        fh=PPtVDgcE1OhgFbb7y4NjHPwZsQK9IJQBBvVEWHHZOpE=;
        b=l1dDCcXgUosZdSjmjTpggr9VzSmYmu2hEttxJYByAA3uBOCOsflxiGyyCiuIfCLiQc
         VKIbb5BVdbch+cecXf50q++ZWXO0aeONuJYmZGHXnx5mKp/7L9O7Ptsx00z/Rb7tqajM
         K0lZfyXI4S/+vexVwnKhTvxge9fm2S1O3blooUcwGYdrg9fq+lI4mxkrpXbyPAz5PjVs
         y4wb5ndL3vphhpqlJJ4xHiGVPg4OHaGkIvTVIw28atvV2sCjMKsa2hbN0bhVWc6KieIa
         imy2rUGdt+Q+Qa2C95APhZEYlOQ0MhWW0psp+Z/sVBOZEcerwcTv/jFRYPWGGVaaQwOJ
         CAFg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@sprovoost.nl header.s=fm3 header.b=GY1dn866;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=XBqFFdCt;
       spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.148 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1743172482; x=1743777282; 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:references:to:cc:in-reply-to:date:subject
         :mime-version:message-id:from:feedback-id:sender:from:to:cc:subject
         :date:message-id:reply-to;
        bh=8kbi1cIeEYpPKk/1KCv+Gkt5hjWjAJcS+ooQ56B7u3k=;
        b=gZ50ekp1n7z4U3/ud6X6RDpsI4Kq0gHAIoAHf7HB5YwXLkIwfZZ5aHoh1AENroZt0J
         c6LvfPsVz+rwH+jGjXVFHCTTrmDigtT5RfYZppt6wHpB9QqE4jiljE0oPyRpmuV+KnVu
         P517msAwnDADi/wIh37V2Qif26kATG/1hKLLQBMWTH/iUHeFWAgDlcIeFuqJFR+OL9JF
         SieZ86xzgEpHgTzQx6UuooZmUd2O6cCLHizHNGDoTekpoLnFTjzPbdujqRvhyCi/nvvY
         Mw2UlznxwgX2TQ0kdX3o+/OdUJ1fLtox6+eis6YUCk6JFhuhWzBp0Tv133MjkfU5kGNn
         WIxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1743172482; x=1743777282;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:references:to:cc:in-reply-to:date:subject
         :mime-version:message-id:from:feedback-id:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8kbi1cIeEYpPKk/1KCv+Gkt5hjWjAJcS+ooQ56B7u3k=;
        b=IM93Zzgq83VrQc6wxng//saep2RirNqmYri8LoyUIPqEgs454Qx833dUDVs7tWP2FV
         LWeA20P5v+kMaM21JxV+1g1M9ARiRCwez39QIyH3Z9VeVwLbQocc1N2GV72Ea2vlkBcy
         ALaUdnUkvRmDZx1Fyn5dL2RMo8ZdLfjLaaKIM3In1h6k6RL53nh74/otpv+j5sAoDb8n
         aV8nrSbLFqb7q9BpZVA3UBRcGViXB/c5by+SMETJYPosMX21boGQL4DsrsVWusD6yFOy
         KCd020jBfzLH9kUymdmz2k0jBkPWZCdAKqINwr/9YiaceZx84DJs4U84I4aYp8RQdGxG
         sNZA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXRfJs8pWwMyb1cr8rhf7Dk6bgAcNWh+p4H4oIsINE39EhxUFxUmdA3iPOqFqDD9cLkdSsYXlXvfcpO@gnusha.org
X-Gm-Message-State: AOJu0YyCVHERMPL9u28URB/hftVjKh07HBdPTla+ggc78ym7mhPfL/D0
	wQE752eAKc7MTVYdoqoydwEfxZmSGygjxmbWjYMFZlc/E5u3oCGo
X-Google-Smtp-Source: AGHT+IGRPsH+IqFXToxpQqJluuTL5dHe3WE4JrSBwt/eIEbmrbpt3bWgEjVOX1XykWpq2JKdc9y6Pw==
X-Received: by 2002:a05:6870:82a0:b0:2c6:72d3:fc93 with SMTP id 586e51a60fabf-2c847faf430mr4673282fac.12.1743172481320;
        Fri, 28 Mar 2025 07:34:41 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALzyhtSlfwYmFalHR0QI3TEAyHZwGJQxQqAB5fN23Vyyg==
Received: by 2002:a05:6870:4691:b0:2c1:3442:67b9 with SMTP id
 586e51a60fabf-2c846fd7351ls575849fac.2.-pod-prod-04-us; Fri, 28 Mar 2025
 07:34:38 -0700 (PDT)
X-Received: by 2002:a54:4391:0:b0:3f9:8b5b:294c with SMTP id 5614622812f47-3fefa602f85mr4137209b6e.31.1743172478447;
        Fri, 28 Mar 2025 07:34:38 -0700 (PDT)
Received: by 2002:a05:6808:1aa6:b0:3f9:f009:458e with SMTP id 5614622812f47-3feefa6b8b7msb6e;
        Fri, 28 Mar 2025 05:48:56 -0700 (PDT)
X-Received: by 2002:a05:6a21:7a81:b0:1f5:9301:1c02 with SMTP id adf61e73a8af0-1fea2f30d1dmr12490218637.25.1743166135060;
        Fri, 28 Mar 2025 05:48:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1743166135; cv=none;
        d=google.com; s=arc-20240605;
        b=IMnc3LexCD9iTFrnpH+CAvJm4YI3VrZgguYz25/pKWqD5heiDpfqBkt8odyvosD+p7
         +1DaGw6M+qQbEUlZzuT6l3FLgCGHyFCQ8HsJASaApLjOozAw70xnfP88s6uXW0CxrFJ9
         p/nmMzIOyhnA3hbco183fmPxoAG0rZt/CsQOlGDJ50ZxI/MkiKv6DCqbnD3wBok/q+JB
         zg6eHvbv1myCvrc159iTz9cmJpD5a/a/gfxrs+HMXNatWIlXyrrnY4vTmZ68dUWwwh0j
         hASknucP3ROkWdOxdSnFbMPHeH9efi59pK7Zlqjm/jvlBZXzGxUesM45xRyU53o5aa+F
         19kw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:feedback-id:dkim-signature:dkim-signature;
        bh=bDpYgXsBT0R3nZFB8VN77Yz1MaARI7ebjKLApismcgo=;
        fh=0LKvqGVzj/s8vZgfCgMK9Mm3QVZh/npHZsKTYbmOc7c=;
        b=I2jDrQ4BGsZi9mVIUtq/ltB4EIqncFQAFbascBraNkBydTqdxA2UTXwmnCyDQDtVfA
         SIWzgcWXNoV4j7UjcAWWvFswvFmoUgiJ/DlQDTN1Vq8Bljj/cbEydlVbEV3Q2oYFzOrj
         wiRnsoupuxX9AasR9KufQPHs5iMplHNDS+atfAX1FBwi0owYb9fwVl8gdQub0owephDr
         AmEFFLjYx/MrdprJd0rEVUK7cxRBXs+sNO6/eeR+QfJV5Zw+SYp2hUdEAm46MwnhN5aF
         FcNKOmfvinET6vokMJMFSzj90ON/35P7PJlDT0U0pT4JA1LHAzYA7LuWFhCQRfZDa0Na
         tLLg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@sprovoost.nl header.s=fm3 header.b=GY1dn866;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=XBqFFdCt;
       spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.148 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl
Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com. [103.168.172.148])
        by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-af93b743ec8si106233a12.3.2025.03.28.05.48.54
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 28 Mar 2025 05:48:54 -0700 (PDT)
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.148 as permitted sender) client-ip=103.168.172.148;
Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47])
	by mailfout.phl.internal (Postfix) with ESMTP id DDDF5138382B;
	Fri, 28 Mar 2025 08:48:53 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
  by phl-compute-07.internal (MEProxy); Fri, 28 Mar 2025 08:48:53 -0400
X-ME-Sender: <xms:tZrmZ59z7MWH2slKUPBDp4PViUivx-lJmTGtlZDUfIjhNTZslGyMCQ>
    <xme:tZrmZ9swGHYDu92Ic6Nnf5cOegEb23yMnJArn_Z0cifxDgzs1fNB9j8YivsLCkjES
    Fv86qIBbpzzZ8xqRQ>
X-ME-Received: <xmr:tZrmZ3Dnde8YYDx2n7zxohnj6QfUyK2pS71c5UjBE1g9WpSa8eOT0qiNN2XMo-GWYIna>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujedufeefucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdt
    jeenucfhrhhomhepufhjohhrshcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovh
    hoohhsthdrnhhlqeenucggtffrrghtthgvrhhnpeegteehveettdeukeegveeuieefudff
    gfdufefhheejtddvgfduudeukeegvedvgfenucffohhmrghinhepuggvlhhvihhnghgsih
    httghoihhnrdhorhhgpdhsthgrtghkvgigtghhrghnghgvrdgtohhmnecuvehluhhsthgv
    rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhjohhrshesshhprhhovh
    hoohhsthdrnhhlpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgt
    phhtthhopehsthgvfigrrhhtrdgthhhrihhsuddvfeegsehgmhgrihhlrdgtohhmpdhrtg
    hpthhtohepsghithgtohhinhguvghvsehgohhoghhlvghgrhhouhhpshdrtghomhdprhgt
    phhtthhopehjvghrvghmhidrlhdrrhhusghinhesghhmrghilhdrtghomh
X-ME-Proxy: <xmx:tZrmZ9eWRaO6zo4Tp1dG2zenjhxEUJ3KnYe7Bbh3TEjw7LtnxnvdiQ>
    <xmx:tZrmZ-MnnsbVvraUxA-9kRlfP0wYZVzR3fd3pnGNoZPen658MGELkw>
    <xmx:tZrmZ_mJV8mR5WDQ6qrTPnraitFAH_3d1upcTS7puM_z8S_ZWx_3pA>
    <xmx:tZrmZ4sGZfLUkc2uEtN9Z6oKdLuQKlJJOpHQZh3xpnTLQA6IYEkCQQ>
    <xmx:tZrmZ7rVn9CLd8EGqS_ApUNIx0E7ljGOXKzIeMjsMHRfN5d_IYUNvTC_>
Feedback-ID: ie5e042df:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 28 Mar 2025 08:48:53 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <80010585-E209-4042-B6F6-5B7DC6675247@sprovoost.nl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
Date: Fri, 28 Mar 2025 13:48:41 +0100
In-Reply-To: <CAGL6+mE8JQGJErgJH03sz8Nzo+wkgx74jgFWp7hFT0MuHiPg_g@mail.gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
 jeremy <jeremy.l.rubin@gmail.com>
To: Chris Stewart <stewart.chris1234@gmail.com>
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>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
X-Original-Sender: sjors@sprovoost.nl
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@sprovoost.nl header.s=fm3 header.b=GY1dn866;       dkim=pass
 header.i=@messagingengine.com header.s=fm2 header.b=XBqFFdCt;       spf=pass
 (google.com: domain of sjors@sprovoost.nl designates 103.168.172.148 as
 permitted sender) smtp.mailfrom=sjors@sprovoost.nl;       dmarc=pass (p=NONE
 sp=NONE dis=NONE) header.from=sprovoost.nl
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.7 (/)


--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

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 ex=
ample uses SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, so as long as our hypothe=
tical smart contracting system uses those flags for its burn-all / giveaway=
-all clauses, then if it produces a 64 byte transaction by mistake, it's re=
coverable.

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 com=
mitted 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:
>=20
> Hi Sjors,
>=20
> 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 by=
te limit, the witness could be of arbitrary size. This was pointed out <htt=
ps://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/74?u=3Dchris_=
stewart_5> by garlonicon <https://delvingbitcoin.org/u/garlonicon> on delvi=
ngbitcoin. This type of witness program is used for pay-to-anchor outputs c=
urrently - although I don't believe anchor outputs make sense in a 1 input =
1 output transaction? The author of pay to anchor outputs is aware of this =
issue <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/78?=
u=3Dchris_stewart_5>, but I haven't heard of any further updates since his =
post on delving.
>=20
> -Chris
>=20
> On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM Sjors Provoost <sjors@sprovoost.n=
l <mailto:sjors@sprovoost.nl>> wrote:
>>=20
>> > Op 27 mrt 2025, om 21:45 heeft jeremy <jeremy.l.rubin@gmail.com <mailt=
o:jeremy.l.rubin@gmail.com>> het volgende geschreven:
>> >=20
>> > 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 cond=
ition.
>>=20
>> Do you have an example in mind where a 64-byte transaction could appear =
in such a system?
>>=20
>> Given the limited space, in particular no room for a public key or signa=
ture, I could imagine a burn or anyone-can-spend clause. Those don't have t=
o be exactly 64 bytes. Even if 64 byte transactions are generated by accide=
nt, I believe they can be tweaked after the fact (though that claim could u=
se more scrutiny):
>>=20
>> https://bitcoin.stackexchange.com/q/125971/4948
>>=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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl.

--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; -webkit-nbsp-mod=
e: space; line-break: after-white-space;">Hi Chris,<div><br></div><div>Than=
ks for that example.</div><div><br></div><div>I also realised that there in=
deed can exist 64 byte transactions that can't be malleated into a differen=
t size (see Stack Exchange link below). The example uses&nbsp;SIGHASH_SINGL=
E | 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 mistake, it's recoverable.</div><div><br=
></div><div>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_ANYONECANP=
AY, once committed inside a CTV tree, can't be modified.</div><div><br></di=
v><div>- Sjors</div><div><div><br><blockquote type=3D"cite"><div>Op 28 mrt =
2025, om 12:02 heeft Chris Stewart &lt;stewart.chris1234@gmail.com&gt; het =
volgende geschreven:</div><br class=3D"Apple-interchange-newline"><div><div=
 dir=3D"ltr"><div>Hi Sjors,</div><div><br></div><div>An example is any segw=
it 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 co=
uld be of arbitrary size. This was <a href=3D"https://delvingbitcoin.org/t/=
great-consensus-cleanup-revival/710/74?u=3Dchris_stewart_5">pointed out</a>=
 by <span class=3D"gmail-first gmail-username"><a href=3D"https://delvingbi=
tcoin.org/u/garlonicon" class=3D"gmail-">garlonicon</a> 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 tr=
ansaction? The author of pay to anchor outputs is <a href=3D"https://delvin=
gbitcoin.org/t/great-consensus-cleanup-revival/710/78?u=3Dchris_stewart_5">=
aware of this issue</a>, but I haven't heard of any further updates since h=
is post on delving.</span></div><div><span class=3D"gmail-first gmail-usern=
ame"><br></span></div><div><span class=3D"gmail-first gmail-username">-Chri=
s</span></div></div><br><div class=3D"gmail_quote gmail_quote_container"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 28, 2025 at 4:25=E2=80=AFAM=
 Sjors Provoost &lt;<a href=3D"mailto:sjors@sprovoost.nl">sjors@sprovoost.n=
l</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'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 cond=
ition.<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't have to b=
e exactly 64 bytes. Even if 64 byte transactions are generated by accident,=
 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></body></html>

<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/80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
80010585-E209-4042-B6F6-5B7DC6675247%40sprovoost.nl</a>.<br />

--Apple-Mail=_F7C3566E-7D82-43C9-9278-33927ADD801E--