From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Jun 2026 09:30:38 -0700 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wWzLZ-0006QS-QX for bitcoindev@gnusha.org; Tue, 09 Jun 2026 09:30:38 -0700 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-48638069322sf7117421b6e.1 for ; Tue, 09 Jun 2026 09:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781022632; x=1781627432; 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=ioEnjyAv5QM3Et0mWUv24XGeayiNiF2X+DX6CMFlbDA=; b=ZipGX95K6CWAlnUnq7Jy4mQuuBYY8EGDUfTI+WeBnmRctBnm7MG1Y3Qr3ZbrNLiHcI OawSQp29BTVMwiCzYLLjt8hqAQWFW/o8R9GG6o5U6UvFFJfksER0/vqZxepFmr7hG64L NFLoOxo7G5dCQfrohYFyzHS2LECKzxwc6T1xAvvLqBGgs9lXPAESa/9wHQq36jLjfPmU Qe1llJuypPcZ4egcXHUjSGMsrfpUFEi98B2xgQ9RuOMDkyJf/IfYza27wthtPFvBqFd6 L6qkpsvpFkmq6WTHkTqdVZDPbKP84qntkWdGqMIK4FVduFEdAung0UsNk6DtvJcMz59/ oyfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781022632; x=1781627432; 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=ioEnjyAv5QM3Et0mWUv24XGeayiNiF2X+DX6CMFlbDA=; b=nfRQfmsi0qSUCfK905SBen0Moi+QGqMzCL8oNoHhs5eaTEgA7S1umSST3mZN3vm9JR 0D256xeW5nzNF4Ag+V6orqvvrPCJN9jzEqsl1VIlxJjsx7RRM/j1I9QsmC0wHxWgIdGn CBSkhnKtMCUlC7AIB1qQLBX36j9FBk+ciWLFUFPNDvUe/XzGgPi4HNJjnzqyOCnamfL/ U1xnsE+LuL9FYKbwV+PIPVCNDt8MQkIiZyDlwP+z6rjzy2Mj8fryDNkLrHx5nFjK7HdN euzWBWyfRRZLei1r5N2dvP/1n39cOCGbZxIe73egLWn4OJgTo4C5DmVlQINZ73NLsu9V t9yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781022632; x=1781627432; 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=ioEnjyAv5QM3Et0mWUv24XGeayiNiF2X+DX6CMFlbDA=; b=BYMxDUZmctxMWp8nZlrWkPSll9MRrMRTfgHLvwr1gso9NWc3P10LKy2vhLaiaCrHOJ AONWsQP/j4dQ5mAIRuLAO4WTJOp7QGTtbpNDg697UkZJlCFLOj38UoLpwH4IvofopDtU hSCIPJ5DYz+7K0pEw90xMhxuD2fQAiefNT/HMhmH+wN8MCpeaWrHCbBN8f8q/kFddz+N ijShcYPjmlk+s4DmWwdPBF/ObAUe83fzln7BrMHUPrzsAgDNEhNANSX0aaMLIymPtBN6 fCUtjGKyvRMdBxk6o6mzYMG4d7+GMl+qhRvr8WxZcolSjXrVCMghiHhgwYe6GIpDhWGt K5kw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9w6OOiLoYBr+xvdE11+0OdDFPAI+H490lSg9MX6/gFV5ncDG5LWTbtGuoK5lg1GGyjI6f43Y3G5sEJ@gnusha.org X-Gm-Message-State: AOJu0YxtuNeWCz2tCQvj93x1cm5QaweYUz0zbFqiRKataE6C1sSQsbJb XrVgCD32Ba8gJmSseRqDOV6eJbIMzXkyiR1kaQm+8vabxMrfcB5b1sLy X-Received: by 2002:a05:6820:2981:b0:69e:97da:285a with SMTP id 006d021491bc7-69e97da29fbmr5852997eaf.29.1781022631641; Tue, 09 Jun 2026 09:30:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUf2NRV0gs9q/5CSvcCGNXRzwKPF5MReKaaK5e2p57DtpQ==" Received: by 2002:a05:6870:7021:b0:441:3f5d:b6e6 with SMTP id 586e51a60fabf-4413f5dd232ls3585124fac.2.-pod-prod-01-us; Tue, 09 Jun 2026 09:30:26 -0700 (PDT) X-Received: by 2002:a05:6808:1310:b0:485:3a28:a83f with SMTP id 5614622812f47-486f01fa198mr2302706b6e.32.1781022626243; Tue, 09 Jun 2026 09:30:26 -0700 (PDT) Received: by 2002:a05:690c:e3ec:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7f48e96a4c5ms7b3; Tue, 9 Jun 2026 09:28:50 -0700 (PDT) X-Received: by 2002:a05:690c:9989:b0:7ba:fdc5:17a3 with SMTP id 00721157ae682-7f2b7c2caeemr36600097b3.43.1781022529681; Tue, 09 Jun 2026 09:28:49 -0700 (PDT) Date: Tue, 9 Jun 2026 09:28:49 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> In-Reply-To: References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@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_332830_1134844700.1781022529268" 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_332830_1134844700.1781022529268 Content-Type: multipart/alternative; boundary="----=_Part_332831_475190571.1781022529268" ------=_Part_332831_475190571.1781022529268 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, it's definitely possible to grind s.t. you have a higher up node that= =20 _looks_ like a transaction. It would be grinding an interior node that has= =20 the desired shape on the left (5 bytes) and on the right (depends what=20 you're grinding for, but it's mostly the length fields and script that need= =20 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 spendable= =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 locked= =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 so= . "Invalidating=20 > 64-byte transactions only fixes malleability in one direction: confusing = a=20 > leaf for a node. However malleability in the other direction may also be= =20 > exploited by grinding an inner node to trick an SPV verifier that accepts= =20 > proofs for 64-byte transactions." > > So you are correct that BIP 54 should only claim that invalidating 64-byt= e=20 > transactions addresses the issue with no change to SPV verifiers for thos= e=20 > SPV verifiers that expect proofs for transactions that cannot be 64-byte= =20 > (i.e. checking for deposits to any interesting scripts, or more generally= =20 > 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 th= e=20 > connector output example you gave! If 64-byte transactions were invalid a= nd=20 > a miner wanted to attack a protocol by faking an SPV proof that a specifi= c=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 onl= y=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 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, which= =20 > could have major consequences. Third party malleability vulnerability to= =20 > deposit / withdrawal masking is a serious bug. Worth thinking that throug= h=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 and= =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 inpu= t,=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 Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/45558bbd-762c-45a4-a4a1-6105= d7462a8en%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/= 75d0e9bd-3bdb-444b-9087-f8a082183253n%40googlegroups.com. ------=_Part_332831_475190571.1781022529268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, it's definitely possible to grind s.t. you have a higher up node that= _looks_ like a transaction.=C2=A0 It would be grinding an interior node th= at has the desired shape on the left (5 bytes) and on the right (depends wh= at you're grinding for, but it's mostly the length fields and script that n= eed to be specific).

You can then in theory have a proof sys= tem that is tricked into thinking a UTXO exists that does not actually exis= t, and it might think it's spendable in a given block.

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

And the SPV proof would= be admitted.


then you'd have p= roof 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 be offered to a miner condition= ed on them using a particular height locked UTXO to claim it.
Since they can only spend the utxo one way, they can only pic= k one of the offers and the others can expire. E.g.:

=
Faked Output X: H w/ <H> CLTV=C2=A0

T= R{Nums, {<H+1> CLTV <PK> CHECKSIG, <H> CLTV <MuSig Fed= eration> CHECKSIG}} + Presigned 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 exi= sted:
TR{Nums, {<H+1> CLTV <PK> CHECKSIG, <H> C= LTV 1 GETINPUT <X> EQUAL}}

----------

As you note, it won't be spending a known output, be= cause of the hash boundaries. But I can still think of protocol application= s where creating a false connector could be harmful.

=

------------


<= div>The rule I propose mitigates this issue because it would be disallowed = to 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 so.=C2=A0"In= validating 64-byte transactions only fixes malleability in one direction: c= onfusing a leaf for a node. However malleability in the other direction may= also be exploited by grinding an inner node to trick an SPV verifier that = accepts proofs for 64-byte transactions."

So= you are correct that BIP 54 should only claim that invalidating 64-byte tr= ansactions addresses the issue with no change to SPV verifiers for those SP= V verifiers that expect proofs for transactions that cannot be 64-byte (i.e= . checking for deposits to any interesting scripts, or more generally any t= ransaction through which value actually flows).

I= n fact this is also true for any SPV verifier that expects proofs for trans= actions which could be 64-byte, as long as it is computationally infeasible= to grind those transactions. Interestingly, this is true of the connector = output example you gave! If 64-byte transactions were invalid and a miner w= anted to attack a protocol by faking an SPV 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 attacking miner would only ever be abl= e to fake a proof for a 64-byte transaction that anybody else would be able= to create anyways.

So i think the point stands t= hat preventing malleability only in one direction (by invalidating 64-byte = transactions) is sufficient, and does not require SPV verifiers to do anyth= ing. 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/75d0e9bd-3bdb-444b-9087-f8a082183253n%40googlegroups.com.
------=_Part_332831_475190571.1781022529268-- ------=_Part_332830_1134844700.1781022529268--