From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 03 Jun 2026 08:07:52 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.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 1wUnCC-0002Qj-2S for bitcoindev@gnusha.org; Wed, 03 Jun 2026 08:07:52 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-43d129461c9sf4510728fac.3 for ; Wed, 03 Jun 2026 08:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780499266; x=1781104066; 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=DCaD3+MUF8HGBqF+3lyHapzeXc/VUKM6kEwmoZnuwRM=; b=AMvQ9thrK+BYP9dRaDgh0s4Kbl8QyZnG5b0v4G6Yw3rDdIjfTbhxQmt7ULbsq6K8jS FyhN3D2R+Y6nUSXw5KMd2DKSiwCvIvIwWoQABZyJgcdFhOGflEtRYUnmybBFV5oXhUA/ XxsXiZRw56+p3woRNECbukoNZvyR8XFG8VfyOw/IS6ge6XxLuNt+g/sFbfI5HkkIwXi3 cpAIjeGgh4Hdd3VWHQVZM6axxZLcbHoTu2JQkbjxWtUE2W+Cmm+ials4FFcQYEdC4mO9 /m6TEWgI9Ew8/I1zIbEbt+008CygKK9lf38rFgXW6fTl5FYahmNtMHtjCN2sNaj7XslO sLVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780499266; x=1781104066; 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=DCaD3+MUF8HGBqF+3lyHapzeXc/VUKM6kEwmoZnuwRM=; b=ZSbvubVGDHBoRbNirdwMFZQd3vIVeKgkvqvyCRC9NyS99cdESvtK1noxKjfrGc28WH J5Ag6x13iM+lGt0cRf3TIMjms3ncioO0mZbJlfFsljgOTfdaexHqv3ozKxPe5HqdWG2K Zt0Q1sqwdERaiPNuwI4mJBAVvVOOzjSHtW10ePh3w6SNQB/00Ljs4WD4aPW6SsHyj/bu EzkIZ7q5Lnoj7GLhMc3ipe0XH6Vzp+TcDp3U/rsFz7aagwP0taK/kkJ+6VUR05IhjVfW C0PTbs9dmCo14VpDT4fhDCbv9MDCoMC8hHucbnTWCnzuAVzkpiBTTNXCNDULl/gbnyMO ZTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780499266; x=1781104066; 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=DCaD3+MUF8HGBqF+3lyHapzeXc/VUKM6kEwmoZnuwRM=; b=pfRqCrdB53vbg78/1Qt1TGuXWW40p+3GBopYeNu9ackRDaK0ONSreMjJKLB5nfUi2a iGbSBwUKgBiUiqvWU73h4bLuztySNILkSOLQKsImCuqWSLdc1Oet8PMaNzFssuuLtX2L qtGScLJ12d+QAjIYHPcvWo0GIKpqFEzU33o7eTkVpsUqCtKGFa5HoN1KJ1HnF6kn6dBL FHjnMAB8nXWEz3OsOQmr+YcUsmMwmX2VBK3DXIZVjiBF5zMHUwReJVtHjHzsJohSRXmw T2+p2BzQUyzNMD211lkOQrhld9fduTwE1iHsaBQqfohmRL7gHxc772kcY6z6HuqwM11S YCKQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9BHsE0wHr+M1J3nSRoxpuM2gMyM+BXxZ4dFdswHP3snQDGZhnW9Io1floOy2lAPBy1AuutRsTuJF/v@gnusha.org X-Gm-Message-State: AOJu0Yz3pmvmtwnBxcwXrPCipeLJlG/893VscYCO7UQIsh5ORGX74SPi d2ChF72dtP4ClFw/PmVVqcqsMHj7NBdedLyXHCkfJZz3Z0wkVWG3wrN+ X-Received: by 2002:a05:6870:b514:b0:43d:2452:c014 with SMTP id 586e51a60fabf-440db630bf5mr2266488fac.9.1780499265742; Wed, 03 Jun 2026 08:07:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMORni5xSxZo8/BnF2CKyi5pFZX9qBxpXHpX7FljQQs8qQ==" Received: by 2002:a05:6870:1156:b0:440:fd1e:ce26 with SMTP id 586e51a60fabf-440fd1ecf66ls165348fac.2.-pod-prod-04-us; Wed, 03 Jun 2026 08:07:39 -0700 (PDT) X-Received: by 2002:a05:6808:68d0:20b0:450:839a:557 with SMTP id 5614622812f47-4866321b02emr988691b6e.9.1780499259426; Wed, 03 Jun 2026 08:07:39 -0700 (PDT) Received: by 2002:a05:690c:6b0e:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7ea723ba335ms7b3; Wed, 3 Jun 2026 08:07:11 -0700 (PDT) X-Received: by 2002:a05:690c:698b:b0:7dc:6d08:f66d with SMTP id 00721157ae682-7ea4b207ba1mr33304537b3.43.1780499230470; Wed, 03 Jun 2026 08:07:10 -0700 (PDT) Date: Wed, 3 Jun 2026 08:07:09 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <619e6297-ffe9-4288-801a-53e115dc720en@googlegroups.com> In-Reply-To: <8c49d0d1-7f87-4e4c-9636-1e631562bc8dn@googlegroups.com> References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> <923b3d65-3472-4d7d-9b13-da44753fe5f8n@googlegroups.com> <8c49d0d1-7f87-4e4c-9636-1e631562bc8dn@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_159468_1971803614.1780499229984" 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_159468_1971803614.1780499229984 Content-Type: multipart/alternative; boundary="----=_Part_159469_301922713.1780499229984" ------=_Part_159469_301922713.1780499229984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct -- it doesn't alter the validity space of transactions, just the=20 validity space of merkle roots, which are the cause of the problem to begin= =20 with. A second layer client would implement this rule as well, and be "protected"= =20 from prefix attacks by the consensus enforced rule. ------------------------- I largely agree with your point on the use of AI... I can at least reassure= =20 you that I used AI here as a *drafting tool* and not to come up with the=20 idea or analysis. I noted the use of AI precisely to properly discount the value of the BIP= =20 at this point, which is surely superior to trying to pass it off as=20 acceptable for full evaluation. As a drafting tool it got several facets of the proposal incorrect, and so= =20 I edited it substantively before including... There isn't really a=20 trust-sama in this case... Regards, Jeremy On Tuesday, June 2, 2026 at 9:16:16=E2=80=AFPM UTC-4 Antoine Riard wrote: > Hi Jeremy, > > If I'm getting correctly your idea, this is not a removal of the "seam" i= n=20 > the > validity space of transaction, more a reduction of the "seam" to a specif= ic > 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 re= al > design win compared to the current proposal... > > By the way, as a side note if we can be spared with chat-gpt generate=20 > bips, 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: e0faa568d4eef3b250b193f01c7134129abe225f7b10f345825610738c5ea1a= 2 > > Le Tuesday, June 2, 2026 =C3=A0 7:20:05=E2=80=AFPM UTC+1, jeremy a =C3=A9= crit : > >> >> They aren't really doing "additional checks" in the way you're framing= =20 >> it. There's just a new rule applied to existing proofs, no additional da= ta=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 embe= d=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, wh= ich=20 >>>> could have major consequences. Third party malleability vulnerability = to=20 >>>> deposit / withdrawal masking is a serious bug. Worth thinking that thr= ough=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 thes= e=20 >>>> issues? >>>> >>>> > This is incorrect for any bridge, wallet, or deposit system that=20 >>>> does not receive funds to a script that either burns the funds or that= =20 >>>> anyone 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= =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/= 619e6297-ffe9-4288-801a-53e115dc720en%40googlegroups.com. ------=_Part_159469_301922713.1780499229984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct -- it doesn't alter the validity space of transactions, just the va= lidity space of merkle roots, which are the cause of the problem to begin w= ith.

A second layer client would implement this rule a= s well, and be "protected" from prefix attacks by the consensus enforced ru= le.

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

I largely agree with your point on the use of AI... I can at least= reassure you that I used AI here as a drafting tool=C2=A0and not to= come up with the idea or analysis.

I noted= the use of AI precisely to properly discount the value of the BIP at this = point, which is surely superior to trying to pass it off as acceptable for = full evaluation.

As a drafting tool it got= several facets of the proposal incorrect, and so I edited it substantively= before including... There isn't really a trust-sama in this case...
<= div>
Regards,

Jeremy
On Tuesday, Jun= e 2, 2026 at 9:16:16=E2=80=AFPM UTC-4 Antoine Riard wrote:
Hi Jeremy,

If I'm = getting correctly your idea, this is not a removal of the "seam" = in the
validity space of transaction, more a reduction of the "seam= " to a specific
structure. That means a second-layer client would s= till have to implement this
check to rule out tx input that might infrin= ge it. Not sure, if it's a real
design win compared to the current p= roposal...

By the way, as a side note if we can be spared with chat-= gpt generate bips, thanks
you. I did (naively) believe bitcoin developme= nt philosophy was about on delivering
on a trust-minmized security model= . Not in fact some novel trust-sama philosopy.

Best,
Antoine
O= TS hash: e0faa568d4eef3b250b193f01c7134129abe225f7b10f345825610738c5ea1a2
Le = Tuesday, June 2, 2026 =C3=A0 7:20:05=E2=80=AFPM UTC+1, jeremy a =C3=A9crit= =C2=A0:

They aren&= #39;t really doing "additional checks" in the way you're fram= ing it. There's just a new rule applied to existing proofs, no addition= al data compared to before. That new rule is something like=C2=A0 gi= ven proof : ([(Hash, LEFT | RIGHT) | ODDNODE ], Transaction)

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

T= his forces that if a 64-byte transaction is present, it must be a leaf.

This prevents the other 64 byte transaction issue bec= ause you can't embed 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 blocks.=C2=A0
On Tuesday, June 2, 2026 at= 8:40:05=E2=80=AFAM UTC-4 Greg Sanders wrote:
Hi Jeremy,

Why does the SPV veri= fier need to do additional checks? SPV implies it's simply trusting the= heaviest chain. Clearly they could validate it, but I'm not seeing nec= essity in the security model.

Greg

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

Rej= ecting nodes with any valid tx in path, without this rule, is problematic, = because it _can_ be possible for an attacking miner to engineer that scenar= io by grinding one TXID leaf to mask a subtree, which could have major cons= equences. Third party malleability vulnerability to deposit / withdrawal ma= sking is a serious bug. Worth thinking that through very carefully before r= ecommending these mitigations. Do you have an end-to-end working example of= such a mitigation that doesn't have these issues?

=
>=C2=A0This 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 can s= pend.

The problem is that from the perspective o= f a wide variety of layer 2 protocols, you actually do want to be able to s= imply close out a UTXO and prove a UTXO is spent.

In the = current L2 protocol design space, value doesn't always flow directly al= ong the output,=C2=A0 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 alternative spend.

Best,

Jeremy
<= /div>

--
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/619e6297-ffe9-4288-801a-53e115dc720en%40googlegroups.com.
------=_Part_159469_301922713.1780499229984-- ------=_Part_159468_1971803614.1780499229984--