From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 15 Jun 2026 08:35:22 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZ9LM-0005Gi-W1 for bitcoindev@gnusha.org; Mon, 15 Jun 2026 08:35:22 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-69d8e718acbsf5004267eaf.1 for ; Mon, 15 Jun 2026 08:35:20 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781537710; cv=pass; d=google.com; s=arc-20240605; b=E+KgNZ16LstU6nrhIXWaLbwQrGjQ7p+lMnOvoyAA3lbwbgn0Pcfz+8stUX8ZV5be77 WS1ybXcB/Vy18Vos3z51erFqFkKWfvNVZQ1s7FbV1Ap142Iio9kuU94sh/+sT6JkNy3Q RYOQQdro7eiYb5SUi8Gx0EBdiuBo/iRQEZCxgkoHngsdWniw3xOmjGQDkNxUauCJczoU PTqnMktxFCbNq8I3foNJAXbNUCyH6XBQD/RnZqIp3N/Mko1cznk0CxKEQjjE6oVqlvUL K84WxGXNvgALspupdXtnzqxEiAnLEf9lajrdTCG4DVDJBXT5og4wp8zrVCGQ45JhWQGH /4UA== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=t3cDGa85P83clurcBZD4HBMguyo+6iW6QODN7cOYKOU=; fh=v8zRWiFzlkDm8F7Pdisi8yMXCjPHWWl53sJwal0dWPY=; b=T2tvvYDp8aTQo/Uhozy7JKS4PSBr7Mfb30Sn7BYQKd93wDrU1SIsbtzvLB433a6DSf ABHMmvzT9k2+WkY6enx44/qzU9uNR/6PKwu8YMrDefvdHLmPa9srCW8dNCuAOUE5OTtF AmbtK/+KQe/leRNpN9U4eQbcpEuJpCGtuoSA5gXf4HrCQE79izuRVPt7lmbqMaMnlfXu 3WuRwRg8SThpK9z/BTPjuiEYJpGxmjm1M6m+6MC/tLM34G3Kq4+ayMYMA5LgOVKKi9MF BuGXHlu507YXUzr9nafdzIev7ZeAKJR6yVcgpUTmUAZzuf6yt+Od6Tk70AVhkG6YLqgr 0yLw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E12M5pn6; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781537710; x=1782142510; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=t3cDGa85P83clurcBZD4HBMguyo+6iW6QODN7cOYKOU=; b=g7MGSofSPPTlny3BG/mCJF0wmM1sCCDk2r0VcfLcxkin/evhTdNaDoZm+/7XYvCoVe u08r3nvim6wZTvUd9uS1xz+WF1qhaOQ97AKJgfsaHXfi3grRt19G55n9D3uZuNn4KWiP 2dTeB9bHG5Hj3nON/h5mmFuejHv1pQDBj9PFnH2vwh4VKQ/1yxIR0iOH3kQkrXLVtQbJ w+F6nAz5lsq24wCIBdIWS2KAyJT/XkM4cXBRrpfziqIble2KuYJK4aE0i1UbJmaRGBmM gVGQr1ApXF03NhA4T0NpjWpA3ALWgPO+9UdLr/jLREHTcMY9Aox8SFUmMaUMNW1c6MBO gFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781537710; x=1782142510; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=t3cDGa85P83clurcBZD4HBMguyo+6iW6QODN7cOYKOU=; b=OK1J2azTiG+mPssAMDPdvGpkIaHj0vfbZj13lY25ORZH0hP2uy5wQns4fEeVrDnZuQ RE4D/sORsrogJ/Up9GA0rZbJtCRFAg7y1Lt5m5SverHtIz9jVMo2Sr1ouhhD2+8W65sm mau+XcFgJeidoSRrmlQP6fJYCujrLTEn2QKGTSfe+a8oDzEg0TtkYeEQZuB2iCST+RrC O8e/uLDSAPtrnAPKm0YUNgoDrEeF5WzGifr3cC4z4dtfoeNRPJdcMDCRpiGPEZ+6hDvq YfbRY+iluMDzCdt7XIP2vJER68PY/2/o3jsvid6dxx0jkPEIFMAMaU3fYE9rRPSmHAJA TjRw== X-Forwarded-Encrypted: i=2; AFNElJ/oHnU+9SjOMA6JCN6aSdtQhEzNwx8mm6Y+gLodcQ9dJTK8FTASn93y125MY1qAhd+mFXfusO6KfcmY@gnusha.org X-Gm-Message-State: AOJu0YxM4Hp8j3cptKn5+ni1xpIcaca/iOJoG0CRKbHiQSGXyZzsp9Dp I5OGAJ8hGWcWC7FFXg8/Org0WPjIsyFi75joKP0EgMmkoMkvPZ+hwVJ3 X-Received: by 2002:a05:6820:180f:b0:69d:d871:d447 with SMTP id 006d021491bc7-69eec776a7cmr7591421eaf.4.1781537710107; Mon, 15 Jun 2026 08:35:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcQGGq2xu1DjGN/3CsnWqISgCQPLBufLa6lJIlSmfABng==" Received: by 2002:a05:6871:cfcf:20b0:435:a654:4449 with SMTP id 586e51a60fabf-44262395fe7ls1256491fac.1.-pod-prod-05-us; Mon, 15 Jun 2026 08:35:04 -0700 (PDT) X-Received: by 2002:a05:6808:508e:b0:46a:869c:b576 with SMTP id 5614622812f47-4874195f4e5mr9722146b6e.2.1781537704587; Mon, 15 Jun 2026 08:35:04 -0700 (PDT) Received: by 2002:a05:600d:8498:10b0:490:3d60:134 with SMTP id 5b1f17b1804b1-490ea95ddb5ms5e9; Mon, 15 Jun 2026 08:29:34 -0700 (PDT) X-Received: by 2002:a05:600c:5296:b0:492:1e7f:d426 with SMTP id 5b1f17b1804b1-4921e7fd54bmr153038665e9.2.1781537372383; Mon, 15 Jun 2026 08:29:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781537372; cv=none; d=google.com; s=arc-20240605; b=jhsVQS7Wpbc5qYUpVoNdJmhrVja56Qi3+M90vjxf9LbTm9cn7Fy+uHfLTKRvIGnIIJ 8YiFzlaD0CUD9s60pMAoWJd2yefBsBuhWJEN7JVbN2VWJ3hl/zhcYcj1+Qu/w4C8MzXV CRgsx7jrwkxI9I3/Af+UBx6hlKyyFx5W1cu0GUToqJlFgAi9dRtHmmI2A/ZouGjrtWHb 4llqO+UsILaolDrnPAL1M1eNxWzIU5ArgldjR8jyV3JgMY0AVHx16ZwEw3srvR4wT6tk UHFJY6Oz1BW4BK4qTnuvfWSDNXX8J8DddG87cx0AU6+Pxw4h3VN1+c9kHLxZ+qkNnj1o oXWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=JS02z5FzDmTy0v3MUWZxK+L7fergpBHqjoODOfqsJmo=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=KaBJ5jEeaFnVOK9bYYkJnjNNKp1TrKhNzH8xdGTdh/jA+HXx+vPW4xu0RGtsFKNQN6 UlzUeu4wFrb18/gTieInsBQQttvYcyStnHAmH98PxUxj1RJsha4i5YGwunFWpIVBzjEo KpAHLS0GINlCBiS+HUwuKHneHzXFVVSuIf8zlKNKCvR/WCWmcLD96jVXoMYkYneJD24b s0xW0wCTgbOtqvaJNfPb8SZudm2h23p6Mj01Ihi0oESJPc9eMCwXWt47RMRkgRhQIfx5 emdlA3Ty5TuqLvTf0T/kXCr17M8dJibjgv/TgeVYvfL/uFCiA8kdU4wJBg1KvFwhsrJt yQJA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E12M5pn6; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch. [79.135.106.118]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4606f2ec820si196408f8f.8.2026.06.15.08.29.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 08:29:32 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) client-ip=79.135.106.118; Date: Mon, 15 Jun 2026 15:29:26 +0000 To: jeremy From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions Message-ID: In-Reply-To: <178b550d-841f-43d6-8c4f-67e909cc17bfn@googlegroups.com> References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> <178b550d-841f-43d6-8c4f-67e909cc17bfn@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: c6b0d2a86623a01014f0aec0036344a6f8d0449c MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_1hxsXoSYNaiUgpdsmHlSW2LnboeQ1UhcWIxKrTH48" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E12M5pn6; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) --b1=_1hxsXoSYNaiUgpdsmHlSW2LnboeQ1UhcWIxKrTH48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd rather say we are at the edge of steeply diminishing returns, which is = how we end up with bad protocol designs. It's correct that if someone were to design an SPV protocol that builds cha= in(s) of transactions on top of an anyone-can-spend connector output, whose= expected script could fit into a 64-byte transaction, then a miner could c= reate a fake connector output that renders the chain(s) of transactions inv= alid before they risk being made invalid anyhow by double spending the anyo= ne-can-spend-yet-timelocked connector output. It's highly unclear to me how this design could ever be useful, but crucial= ly it's important to think on the margin here. We could simply invalidate 6= 4-byte transactions and make all well-known use cases secure, with no patch= ing required from those SPV verifiers. Going one step further and also requ= iring that no inner node of the Merkle tree is also a valid bitcoin tx seri= alization would introduce substantial complexity and attack surface in bloc= k template creation, for no benefit but making far-fetched constructions se= cure (without patching their SPV verifiers, which is always an option). Tha= t does not seem worth it. On Tuesday, June 9th, 2026 at 2:39 PM, jeremy wr= ote: > I also want to make an opinionated point here, separate from the technica= l message above: > > These are esoteric use cases. This is precisely why it's important to get= right. The edge of understanding is where future protocols end up with exp= loitable 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 t= hat _looks_ like a transaction. It would be grinding an interior node that = has the desired shape on the left (5 bytes) and on the right (depends what = you're grinding for, but it'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 thinking= a UTXO exists that does not actually exist, and it might think it's spenda= ble in a given block. >> >> E.g., if the script is CLTV, this would be provably not spent until = 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 ca= n be offered to a miner conditioned on them using a particular height locke= d UTXO to claim it. >> >> Since they can only spend the utxo one way, they can only pick one of th= e offers and the others can expire. E.g.: >> >> Faked Output X: H w/ CLTV >> >> TR{Nums, { CLTV CHECKSIG, CLTV CHECKSIG= }} + Presigned via MuSig spending X using SIGHASH_NONE to allow late bindin= g 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 bo= undaries. But I can still think of protocol applications where creating a f= alse connector could be harmful. >> >> ------------ >> >> The rule I propose mitigates this issue because it would be disallowed t= o have any deserializable txn as an interior node. >> On Friday, June 5, 2026 at 5:39:49=E2=80=AFPM UTC-4 Antoine Poinsot wrot= e: >> >>> Jeremy, >>> >>> Good point. I think this could be more straightforwardly restated like = so. "Invalidating 64-byte transactions only fixes malleability in one direc= tion: confusing a leaf for a node. However malleability in the other direct= ion may also be exploited by grinding an inner node to trick an SPV verifie= r that accepts proofs for 64-byte transactions." >>> >>> So you are correct that BIP 54 should only claim that invalidating 64-b= yte transactions addresses the issue with no change to SPV verifiers for th= ose SPV verifiers that expect proofs for transactions that cannot be 64-byt= e (i.e. checking for deposits to any interesting scripts, or more generally= any transaction through which value actually flows). >>> >>> In fact this is also true for any SPV verifier that expects proofs for = transactions which could be 64-byte, as long as it is computationally infea= sible to grind those transactions. Interestingly, this is true of the conne= ctor output example you gave! If 64-byte transactions were invalid and a mi= ner wanted to attack a protocol by faking an SPV proof that a specific conn= ector 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 b= e able to fake a proof for a 64-byte transaction 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 wro= te: >>> >>>> Antoine, >>>> >>>> Rejecting nodes with any valid tx in path, without this rule, is probl= ematic, because it _can_ be possible for an attacking miner to engineer tha= t scenario by grinding one TXID leaf to mask a subtree, which could have ma= jor consequences. Third party malleability vulnerability to deposit / withd= rawal masking is a serious bug. Worth thinking that through very carefully = before recommending these mitigations. Do you have an end-to-end working ex= ample of such a mitigation that doesn't have these issues? >>>> >>>>> This is incorrect for any bridge, wallet, or deposit system that does= not receive funds to a script that either burns the funds or that anyone c= an 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 p= rove a UTXO is spent. >>>> >>>> In the current L2 protocol design space, value doesn't always flow dir= ectly along the output, the UTXO may be being used as a connector input, an= d the spend of that output may be making a different output available after= a timeout and excluding an alternative spend. >>>> >>>> Best, >>>> >>>> Jeremy >>> >>>> -- >>> >>>> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+...@googlegroups.com. >>> >>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/45558bbd-762c-45a4-a4a1-6105d7462a8en%40googlegroups.com. > > -- > 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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/178b550d-841f-43d6-8c4f-67e909cc17bfn%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/= F2f03QBIWLTvWSGzL_Av1T_kJNNERIYWNY4CI7ap4l-47y09q3qLKoZBMCXbGDzC_ChSp1IAYat= 3eS_BkY3p5uhxRo0whpCP6NE7ZjVMH7s%3D%40protonmail.com. --b1=_1hxsXoSYNaiUgpdsmHlSW2LnboeQ1UhcWIxKrTH48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd rather = say we are at the edge of steeply diminishing returns, which is how we end = up with bad protocol designs.

It's correct that if someone were to design an SPV p= rotocol that builds chain(s) of transactions on top of an anyone-can-= spend connector output, whose expected script could fit into a= 64-byte transaction, then a miner could create a fake connector output tha= t renders the chain(s) of transactions invalid before they risk being made = invalid anyhow by double spending the anyone-can-spend-yet-timelocked conne= ctor output.

It's highly unclear to me how this design c= ould ever be useful, but crucially it's important to think on the margin he= re. We could simply invalidate 64-byte transactions and make all well-known= use cases secure, with no patching required from those SPV verifiers. Goin= g one step further and also requiring that no inner node of the Merkle tree= is also a valid bitcoin tx serialization would introduce substantial compl= exity and attack surface in block template creation, for no benefit but mak= ing far-fetched constructions secure (without patching their SPV verifiers,= which is always an option). That does not seem worth it.
On Tuesday, June 9th, 2026 at 2:39 PM, jeremy <jeremy.l.rubin@gm= ail.com> wrote:
I also want to make an opinionated point here, separate from th= e technical message above:

These are esoteric use cases.= This is precisely why it's important to get right. The edge of understandi= ng is where future protocols end up with exploitable vulnerabilities.
=
On Tuesda= y, 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 that _looks_ like a transaction. = 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's mo= stly the length fields and script that need to be specific).

Y= ou can then in theory have a proof system that is tricked into thinking a U= TXO exists that does not actually exist, 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 proof of tx + proof based on script of not unt= il H time.


What could someth= ing like this be used for?


Let's sa= y some sort of "proof of mutex of miner claim" -- many things can be offere= d to a miner conditioned on them using a particular height locked UTXO to c= laim it.

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

Faked Output X: H w/ <H> CLTV

<= /div>
TR{Nums, {<H+1> CLTV <PK> CHECKSIG, <H> CLTV &l= t;MuSig Federation> CHECKSIG}} + Presigned via MuSig spending X using SI= GHASH_NONE to allow late binding of the miner's preferred destination (or n= ot SIGHASH_NONE and an OP_TRUE) ;

or if GETINPUT o= pcode existed:
TR{Nums, {<H+1> CLTV <PK> CHECKSIG, &l= t;H> CLTV 1 GETINPUT <X> EQUAL}}

--------= --

As you note, it won't be spending a known outpu= t, because of the hash boundaries. But I can still think of protocol applic= ations where creating a false connector could be harmful.


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


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:3= 9:49=E2=80=AFPM UTC-4 Antoine Poinsot wrote:
Jeremy,

Go= od point. I think this could be more straightforwardly restated like so. "Invalidating 64-byte tra= nsactions only fixes malleability in one direction: confusing 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 5= 4 should only claim that invalidating 64-byte transactions addresses the is= sue with no change to SPV verifiers for those SPV verifiers that expect pro= ofs for transactions that cannot be 64-byte (i.e. checking for deposits to = any interesting scripts, or more generally any transaction through which va= lue actually flows).

In fact this is also true fo= r any SPV verifier that expects proofs for transactions which could be 64-b= yte, as long as it is computationally infeasible to grind those transaction= s. Interestingly, this is true of the connector output example you gave! If= 64-byte transactions were invalid and a miner wanted 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 r= eally the attacking miner would only ever be able to fake a proof for a 64-= byte transaction that anybody else would be able to create anyways.<= /div>

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

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">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 any br= idge, wallet, or deposit system that does not receive funds to a script tha= t either burns the funds or that anyone can spend.

The problem is that from the perspective of a wide variety of layer 2 pr= otocols, you actually do want to be able to simply close out a UTXO and pro= ve a UTXO is spent.

In the current L2 protocol design spa= ce, value doesn't always flow directly along the output, the UTXO may be b= eing used as a connector input, and the spend of that output may be making = a different output available after a timeout and excluding an alternative s= pend.

Best,

<= div>Jeremy

--
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+...@googlegroups.com.

--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/178b550d-841f-43d6-8c= 4f-67e909cc17bfn%40googlegroups.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/bitcoindev/= F2f03QBIWLTvWSGzL_Av1T_kJNNERIYWNY4CI7ap4l-47y09q3qLKoZBMCXbGDzC_ChSp1IAYat= 3eS_BkY3p5uhxRo0whpCP6NE7ZjVMH7s%3D%40protonmail.com.
--b1=_1hxsXoSYNaiUgpdsmHlSW2LnboeQ1UhcWIxKrTH48--