From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Jun 2026 18:16:23 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wUaDX-0003Uh-3V for bitcoindev@gnusha.org; Tue, 02 Jun 2026 18:16:23 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-69e365a9d0esf1904888eaf.2 for ; Tue, 02 Jun 2026 18:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780449377; x=1781054177; 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=at2Y/Z//7u6vijtFI5+cMohRGqbRDKRH8SFABgCQc6k=; b=Prz0UWqfmsyMG5IOefVcwuTj5ZVJq1EFM9oeko72cct4dSdrORUNd4TY0Czfzum/+d V50PgTAXOiREOJ9wBghz9PjEnxQv/1WLsgJvfBpIjsRgl48hS9mDer7zRmEGY9BlOuqk PmYHCyovsMDBvw/jZlElQetz6UTqZFKy/X17XiSZB2Xn2mIuahy88kRjn7msNpvan1o5 yp23IZDplKbxWFnw2T1AtfKGC6pkSO2kYQhU7Vt7X4TCKTK0Urgfns748lSwMLMiPJat 3F2aT6sf1nRA+Z2YlUihW4zxr7aC4Sm0+yuvoPyl4GCn02HcOdZ61mc1QS1h40hhoinu m5gQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780449377; x=1781054177; 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=at2Y/Z//7u6vijtFI5+cMohRGqbRDKRH8SFABgCQc6k=; b=XA91sRF6JQslTyQD4jN2iCpcUzU+V6gGnZlSEN3v9fuLWVs5jq6gcTKJA6dergRNeC roUZLhH4P7zoRbxzYIpiW02Fim6eYfGYnYqVlILTa0jppRNSR04Wl8SwSWJHq6mODt74 Pz5lchd3z/2zMP7vanV0aK+usyu26HeFrvqIn1Fte/6jWpUFQKNY+QzMZQskU0G8h1BL ed7F0S6g1DC5DPeGhmPnb5xrCU4nQGQlekiQrCUfbG4U/glladLrVSrLMd416NUs5bCI GSkJdHT27u3wwxiREY9zOX9QaVS9oYHjGFAiEhe2lf4/7jeuGPT2Nq2olUCWXOnVvuD7 Et5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780449377; x=1781054177; 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=at2Y/Z//7u6vijtFI5+cMohRGqbRDKRH8SFABgCQc6k=; b=nTt9Z3owJfLy0xk3Supsa5pkMDR/EuTeoMyLKHSWrv/AhPQy0SRAqdQfodcnzKrnLQ 3i8nbzRZ6HlDETU+PcgZLxQ3UBHPfW0swgGuH7CMtUwHurVI3QcZT+7oaGoQskB0bd4G ++FlxR4wGO6FAbPxwNP0EuAuVRX3++03Yca4i/CghORqpM0+q/fxYXqmu0sEsk/euX/+ 8p8D0eod/3Jju6C+bOePR34ER2+r6nMkq0FDLlN2TZOdBJFKLyIWoIEHQrn8lGwTgWko kB+/8i6wMV/EzrHYz+kvWg0SPWnP4jz++JXX1qhe9EvMXGjRFJyRcSxqgJop2Oq1YZ9J L5jQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9xy6tkBFh7NkKpcDUd0Xema48rpr3v5wR9JsJlfLWfnQBgXD7yGZFOdE4JEHC4bT+uf0DLKDMXzEm1@gnusha.org X-Gm-Message-State: AOJu0Yxw5cHEHgmb14Gp1QN900H5gmIW22/OPjskuw8tV8gy3ektyUAw QnxNCAA0imhxbcyDBXRPU0Fn+9iR5VmBKGit9kTjt6pGxwXlKYJbf0Gj X-Received: by 2002:a05:6820:82a:b0:69e:3dde:869d with SMTP id 006d021491bc7-69e47e6bc75mr947276eaf.23.1780449376679; Tue, 02 Jun 2026 18:16:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOTneIWhImme8vHhKB+/KGZDa3IHlh53Ivj0OvGbpP1dg==" Received: by 2002:a05:6820:168c:b0:696:77d2:4757 with SMTP id 006d021491bc7-69e2e4f0acels1536870eaf.1.-pod-prod-06-us; Tue, 02 Jun 2026 18:16:10 -0700 (PDT) X-Received: by 2002:a05:6808:192a:b0:46e:df55:23fa with SMTP id 5614622812f47-4865aa98ae6mr766198b6e.17.1780449370881; Tue, 02 Jun 2026 18:16:10 -0700 (PDT) Received: by 2002:a05:690c:6b0e:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7ea723ba335ms7b3; Tue, 2 Jun 2026 18:05:32 -0700 (PDT) X-Received: by 2002:a05:690c:6810:b0:7bd:9ce7:164c with SMTP id 00721157ae682-7ea4b207b8bmr12572387b3.43.1780448731142; Tue, 02 Jun 2026 18:05:31 -0700 (PDT) Date: Tue, 2 Jun 2026 18:05:30 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <8c49d0d1-7f87-4e4c-9636-1e631562bc8dn@googlegroups.com> In-Reply-To: References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> <923b3d65-3472-4d7d-9b13-da44753fe5f8n@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_12094_1754524353.1780448730534" X-Original-Sender: antoine.riard@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_12094_1754524353.1780448730534 Content-Type: multipart/alternative; boundary="----=_Part_12095_724326152.1780448730534" ------=_Part_12095_724326152.1780448730534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, If I'm getting correctly your idea, this is not a removal of the "seam" in= =20 the validity space of transaction, more a reduction of the "seam" to a specific structure. That means a second-layer client would still have to implement= =20 this check to rule out tx input that might infringe it. Not sure, if it's a real design win compared to the current proposal... By the way, as a side note if we can be spared with chat-gpt generate bips,= =20 thanks you. I did (naively) believe bitcoin development philosophy was about on=20 delivering on a trust-minmized security model. Not in fact some novel trust-sama=20 philosopy. Best, Antoine OTS hash: e0faa568d4eef3b250b193f01c7134129abe225f7b10f345825610738c5ea1a2 Le Tuesday, June 2, 2026 =C3=A0 7:20:05=E2=80=AFPM UTC+1, jeremy a =C3=A9cr= it : > > They aren't really doing "additional checks" in the way you're framing it= .=20 > There's just a new rule applied to existing proofs, no additional data=20 > compared to before. That new rule is *something* like given proof :=20 > ([(Hash, LEFT | RIGHT) | ODDNODE ], Transaction) > > then as you hash you just forbid that any LEFT | RIGHT or LEFT | LEFT is= =20 > allowed to be parseable as a transaction. > > This forces that if a 64-byte transaction is present, it must be a leaf. > > This prevents the other 64 byte transaction issue because you can't embed= =20 > a txid sub-tree inside the 64-byte transaction to lie to an SPV user. > > My estimate is that this case happens naturally like 1 in 2 million=20 > blocks.=20 > On Tuesday, June 2, 2026 at 8:40:05=E2=80=AFAM UTC-4 Greg Sanders wrote: > >> Hi Jeremy, >> >> Why does the SPV verifier need to do additional checks? SPV implies it's= =20 >> simply trusting the heaviest chain. Clearly they could validate it, but = I'm=20 >> not seeing necessity in the security model. >> >> Greg >> >> On Monday, June 1, 2026 at 4:22:28=E2=80=AFPM UTC-4 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, whi= ch=20 >>> could have major consequences. Third party malleability vulnerability t= o=20 >>> deposit / withdrawal masking is a serious bug. Worth thinking that thro= ugh=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 anyon= e=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 a= nd=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= =20 >>> input, and the spend of that output may be making a different output=20 >>> available after a timeout and excluding an alternative spend. >>> >>> Best, >>> >>> Jeremy >>> >> --=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/= 8c49d0d1-7f87-4e4c-9636-1e631562bc8dn%40googlegroups.com. ------=_Part_12095_724326152.1780448730534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy,

If I'm getting correctly your idea, this is not a rem= oval of the "seam" in the
validity space of transaction, more a reduct= ion of the "seam" to a specific
structure. That means a second-layer c= lient would still have to implement this
check to rule out tx input th= at might infringe it. Not sure, if it's a real
design win compared to = the current proposal...

By the way, as a side note if we can be = spared with chat-gpt generate bips, thanks
you. I did (naively) believ= e bitcoin development philosophy was about on delivering
on a trust-mi= nmized security model. Not in fact some novel trust-sama philosopy.
Best,
Antoine
OTS hash: e0faa568d4eef3b250b193f01c7134129abe2= 25f7b10f345825610738c5ea1a2

Le Tuesday, June 2, 2026 =C3=A0 7:20:05=E2= =80=AFPM UTC+1, jeremy a =C3=A9crit=C2=A0:

They aren't really doing "additi= onal checks" in the way you're framing it. There's just a new = rule applied to existing proofs, no additional data compared to before. Tha= t new rule is something like=C2=A0 given proof : ([(Hash, LEFT | RIG= HT) | ODDNODE ], Transaction)

then as you hash you just = forbid that any LEFT | RIGHT or LEFT | LEFT is allowed to be parseable as a= transaction.

This forces that if a 64-byte tr= ansaction is present, it must be a leaf.

This prev= ents the other 64 byte transaction issue because you can't embed a txid= sub-tree inside the 64-byte transaction to lie to an SPV user.
<= br>
My estimate is that this case happens naturally like 1 in 2 m= illion blocks.=C2=A0
On Tuesday, June 2, 2026 at 8:40:05=E2=80=AFAM UTC-4 Greg = Sanders wrote:
Hi Jere= my,

Why does the SPV verifier need to do additional chec= ks? SPV implies it's simply trusting the heaviest chain. Clearly they c= ould validate it, but I'm not seeing necessity in the security model.

Greg

On Monday, June 1, 2026 at 4:22:28=E2=80= =AFPM UTC-4 jeremy wrote:
Antoine,

Rejecting nodes with any valid = tx in path, without this rule, is problematic, because it _can_ be possible= for an attacking miner to engineer that scenario by grinding one TXID leaf= to mask a subtree, which could have major consequences. Third party mallea= bility vulnerability to deposit / withdrawal masking is a serious bug. Wort= h thinking that through very carefully before recommending these mitigation= s. Do you have an end-to-end working example of such a mitigation that does= n't have these issues?

>=C2=A0This 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,=C2=A0 the = UTXO may be being used as a connector input, and the spend of that output m= ay 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 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/8c49d0d1-7f87-4e4c-9636-1e631562bc8dn%40googlegroups.com.
------=_Part_12095_724326152.1780448730534-- ------=_Part_12094_1754524353.1780448730534--