From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Jun 2026 11:39:28 -0700 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wX1MF-0007BN-K0 for bitcoindev@gnusha.org; Tue, 09 Jun 2026 11:39:28 -0700 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-48687e7f161sf3987953b6e.2 for ; Tue, 09 Jun 2026 11:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781030361; x=1781635161; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=mJV+We339lsPLUHDtlSHobElssVHQE1OYYIq/VzzSBI=; b=JK9U9YRUqk21tFWOnJdgB0Ycv2j167MHvubb8kVXF44ScvGWcBnAeItm4FweMewESY 8xd6qX4KAjTxsxNJPdhIqduFQIXoALblHXWSCGDWKdGM1WR5/xmLKO8cNsKngAS4qQg7 90rA6NsVk0zGzNpKC5tIw3md8eapaylT+LDX0CQvm/51UzjTSVZ/DXUI1dsQNtgeD12O 43DNFO95YozosVK73gKQs5hCMm1mSHfw4AasL2YvzgdCGFshSioOnrlcOGkeHRe8f621 ucsc74fD3NHnecncjrFJGi07gyoRVtBHZse+UnpXIWCWoLH3ONHSGNUq76aXXon+Y8Xp Ue2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781030361; x=1781635161; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=mJV+We339lsPLUHDtlSHobElssVHQE1OYYIq/VzzSBI=; b=kCP2hAVKMVe4lTulnyyAppmVS+fF7PV3KoQ00/NFHXaIfSAwNOOpEBRAIdFg7cZApq MCNlOevkgUgANLlAE4xFdmqaqYuJiHJfx6976BDSf+jlO9ppjcvUxfZngbSIbufU3K0g YaOO/uB4wxEyiCAGTPgNl7tTZwQX0oMcu3kgbS3ZN2iyKzGbAViVjgcXvEW6yU1hGhla tPU5vKM0HfHp00G5pv4CTvD33WzsG664Tc9OevRPlCq+ozdgoPqHbchiv1lp6Bx+dpa5 plBhLikB/YcYsAj3y0F/KyoiPEjBDCzXGBy2jioov4En+BAPB5o0W8u5EKrVN2bXgorz a4sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781030361; x=1781635161; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=mJV+We339lsPLUHDtlSHobElssVHQE1OYYIq/VzzSBI=; b=OpWpHySaKfd1YRr/UoJWaR9yOHciBNwLdOHaBC7w6vBZ8Rnnhi0kH0J7GVB/+50Lx+ Efxp0fF+J2sgGwa1qhxdqz45/kFD/Gah36YYO0LA00VNWyvlajqNG1F+7s+qVcN6czP3 CwppfCpsijI/IhowhlQ+N2/0Aw/8jmb8XCI5nD8hL6Rzq4Oc74qYbWUL3ndIDLN2p7cm M0cN+DAzRIvNqADz5CNjC+BTm8BhaN4jw5P9vQuisukuX8cv+f5SstVf4Jqm9OVQ3wvD OivfMQIr1AfGlPWx7Ra1IVlXa0j0CuBMKD2FCS9ZV+XiYuhT5Q56ULPk+exi3EObLtdF G8Kg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8GxLJvRe8mMci1/YvX1vEpqH8hZYNwEikYz3Umy7saYjRblzYr6sVhVwH152WA9xPEcw9oGDYRyASC@gnusha.org X-Gm-Message-State: AOJu0YzNLsAEf3tKJS1EZGYMEsEkfzI2f8hDeQozjqexKis7mkJoMFgv 63SekWQPzZfW4d3ojwhn2+d4R3LUX1iEQH5amfhKopqAvTn4BIotX2bS X-Received: by 2002:a05:6820:1f11:b0:69e:786b:50f2 with SMTP id 006d021491bc7-69e786b5997mr9388824eaf.40.1781030361383; Tue, 09 Jun 2026 11:39:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUf0tdzOX0+7kEbSMz3WIC780riZpmASIA6pj63e0jiO7w==" Received: by 2002:a05:6871:597:10b0:43b:781c:b5e with SMTP id 586e51a60fabf-44109e37250ls2945999fac.1.-pod-prod-03-us; Tue, 09 Jun 2026 11:39:15 -0700 (PDT) X-Received: by 2002:a05:6808:1a13:b0:45e:84e7:c20b with SMTP id 5614622812f47-4868e02c29amr12761570b6e.25.1781030355839; Tue, 09 Jun 2026 11:39:15 -0700 (PDT) Received: by 2002:a05:690c:4786:b0:7d0:63a3:69e7 with SMTP id 00721157ae682-7ed2a38519fms7b3; Tue, 9 Jun 2026 09:37:34 -0700 (PDT) X-Received: by 2002:a05:690c:c155:b0:7ef:d039:a334 with SMTP id 00721157ae682-7efd039ada5mr108122637b3.22.1781023052814; Tue, 09 Jun 2026 09:37:32 -0700 (PDT) Date: Tue, 9 Jun 2026 09:37:32 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <178b550d-841f-43d6-8c4f-67e909cc17bfn@googlegroups.com> In-Reply-To: <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> Subject: Re: [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_78654_846732067.1781023052389" X-Original-Sender: Jeremy.L.Rubin@gmail.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 (/) ------=_Part_78654_846732067.1781023052389 Content-Type: multipart/alternative; boundary="----=_Part_78655_598269822.1781023052389" ------=_Part_78655_598269822.1781023052389 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also want to make an opinionated point here, separate from the technical= =20 message above: These are esoteric use cases. This is precisely why it's important to get= =20 right. The edge of understanding is where future protocols end up with=20 exploitable vulnerabilities. On Tuesday, June 9, 2026 at 12:30:31=E2=80=AFPM UTC-4 jeremy wrote: > Well, it's definitely possible to grind s.t. you have a higher up node=20 > that _looks_ like a transaction. It would be grinding an interior node= =20 > that has the desired shape on the left (5 bytes) and on the right (depend= s=20 > what you're grinding for, but it's mostly the length fields and script th= at=20 > need to be specific). > > You can then in theory have a proof system that is tricked into thinking = a=20 > UTXO exists that does not actually exist, and it might think it's spendab= le=20 > in a given block. > > E.g., if the script is CLTV, this would be provably not spent until= =20 > block H. > > And the SPV proof would be admitted. > > > then you'd have proof of tx + proof based on script of not until H time. > > > What *could* something like this be used for? > > > Let's say some sort of "proof of mutex of miner claim" -- many things can= =20 > be offered to a miner conditioned on them using a particular height locke= d=20 > UTXO to claim it. > > Since they can only spend the utxo one way, they can only pick one of the= =20 > offers and the others can expire. E.g.: > > Faked Output X: H w/ CLTV=20 > > TR{Nums, { CLTV CHECKSIG, CLTV CHECKSIG}= }=20 > + Presigned via MuSig spending X using SIGHASH_NONE to allow late binding= =20 > of the miner's preferred destination (or not SIGHASH_NONE and an OP_TRUE)= ; > > or if GETINPUT opcode existed: > TR{Nums, { CLTV CHECKSIG, CLTV 1 GETINPUT EQUAL}} > > ---------- > > As you note, it won't be spending a known output, because of the hash=20 > boundaries. But I can still think of protocol applications where creating= a=20 > false connector could be harmful. > > > ------------ > > > The rule I propose mitigates this issue because it would be disallowed to= =20 > have any deserializable txn as an interior node. > On Friday, June 5, 2026 at 5:39:49=E2=80=AFPM UTC-4 Antoine Poinsot wrote= : > >> Jeremy, >> >> Good point. I think this could be more straightforwardly restated like= =20 >> so. "Invalidating 64-byte transactions only fixes malleability in one=20 >> direction: confusing a leaf for a node. However malleability in the othe= r=20 >> direction may also be exploited by grinding an inner node to trick an SP= V=20 >> verifier that accepts proofs for 64-byte transactions." >> >> So you are correct that BIP 54 should only claim that invalidating=20 >> 64-byte transactions addresses the issue with no change to SPV verifiers= =20 >> for those SPV verifiers that expect proofs for transactions that cannot = be=20 >> 64-byte (i.e. checking for deposits to any interesting scripts, or more= =20 >> generally any transaction through which value actually flows). >> >> In fact this is also true for any SPV verifier that expects proofs for= =20 >> transactions which could be 64-byte, as long as it is computationally=20 >> infeasible to grind those transactions. Interestingly, this is true of t= he=20 >> connector output example you gave! If 64-byte transactions were invalid = and=20 >> a miner wanted to attack a protocol by faking an SPV proof that a specif= ic=20 >> connector output was spent, it would need to grind over 256 bits for any= =20 >> inner node to match that prevout. So really the attacking miner would on= ly=20 >> ever be able to fake a proof for a 64-byte transaction that anybody else= =20 >> would be able to create anyways. >> >> So i think the point stands that preventing malleability only in one=20 >> direction (by invalidating 64-byte transactions) is sufficient, and does= =20 >> not require SPV verifiers to do anything. Do you have a counter-example? >> >> Antoine >> On Monday, June 1st, 2026 at 4:22 PM, jeremy =20 >> wrote: >> >> Antoine, >> >> Rejecting nodes with any valid tx in path, without this rule, is=20 >> problematic, because it _can_ be possible for an attacking miner to=20 >> engineer that scenario by grinding one TXID leaf to mask a subtree, whic= h=20 >> could have major consequences. Third party malleability vulnerability to= =20 >> deposit / withdrawal masking is a serious bug. Worth thinking that throu= gh=20 >> very carefully before recommending these mitigations. Do you have an=20 >> end-to-end working example of such a mitigation that doesn't have these= =20 >> issues? >> >> > This is incorrect for any bridge, wallet, or deposit system that does= =20 >> not receive funds to a script that either burns the funds or that anyone= =20 >> can spend. >> >> The problem is that from the perspective of a wide variety of layer 2=20 >> protocols, you actually do want to be able to simply close out a UTXO an= d=20 >> prove a UTXO is spent. >> >> In the current L2 protocol design space, value doesn't always flow=20 >> directly along the output, the UTXO may be being used as a connector inp= ut,=20 >> and the spend of that output may be making a different output available= =20 >> after a timeout and excluding an alternative spend. >> >> Best, >> >> Jeremy >> >> --=20 >> >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/45558bbd-762c-45a4-a4a1-610= 5d7462a8en%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/= 178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com. ------=_Part_78655_598269822.1781023052389 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also want to make an opinionated point here, separate from the technical = message above:

These are esoteric use cases. This is p= recisely why it's important to get right. The edge of understanding is wher= e future protocols end up with exploitable vulnerabilities.
On Tuesday, June 9,= 2026 at 12:30:31=E2=80=AFPM UTC-4 jeremy wrote:
Well, it's definitely possible to g= rind s.t. you have a higher up node that _looks_ like a transaction.=C2=A0 = It would be grinding an interior node that has the desired shape on the lef= t (5 bytes) and on the right (depends what you're grinding for, but it&= #39;s mostly the length fields and script that need to be specific).
You can then in theory have a proof system that is tricked into thin= king a UTXO exists that does not actually exist, and it might think it'= s spendable in a given block.

E.g., if the s= cript is <H> CLTV, this would be provably not spent until block H.

And the SPV proof would be admitted.

<= /div>

then you'd have proof of tx + proof based on s= cript of not until H time.


What = could something like this be used for?


Let's say some sort of "proof of mutex of miner claim"= ; -- many things can be offered to a miner conditioned on them using a part= icular height locked UTXO to claim it.

Since they = can only spend the utxo one way, they can only pick one of the offers and t= he others can expire. E.g.:

Faked Output X: H w/ &= lt;H> CLTV=C2=A0

TR{Nums, {<H+1> CLTV <= ;PK> CHECKSIG, <H> CLTV <MuSig Federation> CHECKSIG}} + Pres= igned via MuSig spending X using SIGHASH_NONE to allow late binding of the = miner's preferred destination (or not SIGHASH_NONE and an OP_TRUE) ;

or if GETINPUT opcode existed:
TR{Nums, {&= lt;H+1> CLTV <PK> CHECKSIG, <H> CLTV 1 GETINPUT <X> EQ= UAL}}

----------

As you n= ote, it won't be spending a known output, because of the hash boundarie= s. But I can still think of protocol applications where creating a false co= nnector could be harmful.


---------= ---


The rule I propose mitigates th= is issue because it would be disallowed to have any deserializable txn as a= n interior node.
On Friday, June 5, 2026 at 5:39:49=E2=80=AFPM UTC-4 Antoine Po= insot wrote:
Jeremy,

Good point. I think this could b= e more straightforwardly restated like so.=C2=A0"Invalidating 64-byte transactions only fixes= malleability in one direction: confusing a leaf for a node. However mallea= bility in the other direction may also be exploited by grinding an inner no= de to trick an SPV verifier that accepts proofs for 64-byte transactions.&q= uot;

So you are correct that BIP 54 should only c= laim that invalidating 64-byte transactions addresses the issue with no cha= nge to SPV verifiers for those SPV verifiers that expect proofs for transac= tions that cannot be 64-byte (i.e. checking for deposits to any interesting= scripts, or more generally any transaction through which value actually fl= ows).

In fact this is also true for any SPV verif= ier that expects proofs for transactions which could be 64-byte, as long as= it is computationally infeasible to grind those transactions. Interestingl= y, this is true of the connector output example you gave! If 64-byte transa= ctions were invalid and a miner wanted to attack a protocol by faking an SP= V proof that a specific connector output was spent, it would need to grind = over 256 bits for any inner node to match that prevout. So really the attac= king miner would only ever be able to fake a proof for a 64-byte transactio= n that anybody else would be able to create anyways.

So i think the point stands that preventing malleability only in one di= rection (by invalidating 64-byte transactions) is sufficient, and does not = require SPV verifiers to do anything. Do you have a counter-example?=

Antoine
On Monday, June 1st, 2026 at 4:22 PM, jeremy <jeremy....@gmail.com> wrote:
Antoine,

Rejecting nodes with any= valid tx in path, without this rule, is problematic, because it _can_ be p= ossible for an attacking miner to engineer that scenario by grinding one TX= ID leaf to mask a subtree, which could have major consequences. Third party= malleability vulnerability to deposit / withdrawal masking is a serious bu= g. Worth thinking that through very carefully before recommending these mit= igations. Do you have an end-to-end working example of such a mitigation th= at doesn't have these issues?

> This is incorrect for an= y bridge, wallet, or deposit system that does not receive funds to a script= that either burns the funds or that anyone can spend.
The problem is that from the perspective of a wide variety of layer = 2 protocols, you actually do want to be able to simply close out a UTXO and= prove a UTXO is spent.

In the current L2 protocol design= space, value doesn't always flow directly along the output, the UTXO = may be being used as a connector input, and the spend of that output may be= making a different output available after a timeout and excluding an alter= native spend.

Best,
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+...@googlegroups.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/bitcoind= ev/178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com.
------=_Part_78655_598269822.1781023052389-- ------=_Part_78654_846732067.1781023052389--