From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Jun 2026 11:20:11 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wUTil-0000Jm-6M for bitcoindev@gnusha.org; Tue, 02 Jun 2026 11:20:11 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43d1fa463d0sf2149921fac.0 for ; Tue, 02 Jun 2026 11:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780424405; x=1781029205; 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=6FIl1GoaQB+RjYboIxxEFjdTzq+r2d2juQXrGHOVOjU=; b=dWytpdZ1x3YyrZb3Hc5madpwOzHGLJHN/iRTS+aEJKE0JM8WjbZDzyVdvxsikqYQXs Mrk03ZmBvWgkZ0zqGWWke7owlxVes5Cbhrclo4d4qGzVEdw+UBX1uoztSukk3HZ/SfAn 4gX2/kkbH5l6emKavh1gg828AZa2Ug7L1BN8tVl4z1cm/NAqcPIgvxyGeUJq4FDPlyRV cFfGb/ZmU1wbQr0NSQbgKWwtqCaeFKWlH05FUhF8gTHEJwsjJpDQ3e7tDY0xenVtwzWP qJxD8cE6IRTyeWDykGaq9QlpyZnxmOgAUoOMneu3reNoEV8rGe1CYq7LzlfP1+oAdksM Bhag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780424405; x=1781029205; 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=6FIl1GoaQB+RjYboIxxEFjdTzq+r2d2juQXrGHOVOjU=; b=BHO6VOaBBsrwLZe/pYiqrifvUCePIaeBLqTr57wdAHYIdeyRvxpjCoe3Act6mXJ/Mi mv3w1liwSE4wfWNleIHPukXjcrfmHwRsDoncIVOnxdIr9mEuxL27QIYIker0Kbc3TxKs ffjuXqJHotw1yC64cEHV0JtcLHaFYXTuTsKyaim57NzGiVGJNW88IwkLGBIQXWmrb0iA 5jomcu5m1TnLZa6eBsbfYsPKpEyDKizpfG7UFiL4mZcm/ULEG4jHJvZtMADKCU35xW99 tJb+S3zJpE+SQx7aezNbwrpeqeiYVZq3a91WCGk4/ZbkwzXS/8Vq6/NhoNMgdw9d0xwc RJRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780424405; x=1781029205; 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=6FIl1GoaQB+RjYboIxxEFjdTzq+r2d2juQXrGHOVOjU=; b=O9/T6jXi8egmdrk64Xfro29qlD0EQyS+YmGEfNvyMAExY+gKbo8rqbOoP4u6GTCxQ/ zrMFMm7Sq/Am0TJwe1ZD2KPpbK4vEhUXQceCgYOdKoV2EJMkenfcbf/XEDLwPo08CK9r XYgKBrX2ysA17cRqC5xVUuOsb4YQOfbdIE5MOcO5k8iFgRJYQHdIBVygLcnQtwivH0h7 aG4ikcjKQtPghdZWdohi4pgjJkQil57819QTIqI/J43GEC2EhW/aBE/FXp/844QB/CQ2 D2YPfrHJD9mHqqX0jKw9tQ/lr1pR1cSN4OOrNQPdWbQrbw9VWsZ3bjHcmuN+YD7EEWV7 OfGg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/6Ei3WmN4abwPWJZD8/LocKThV/gOHl3Etnzu/X0L8PYIYUfzVPadRkgXkxuarPvasYX6kR48x+60Y@gnusha.org X-Gm-Message-State: AOJu0Yyj1E0aTDpW/9eJ0Xg8O9n+o2OW285xH7ovn8K11i2gFO1V3Glf nif8lUXcft6poJMFT9mLxzqYHvmrTYFfyF3qBE/kczwBxHz8tHryP0qW X-Received: by 2002:a05:6820:c3c6:10b0:69e:4403:330a with SMTP id 006d021491bc7-69e47ed4164mr115271eaf.21.1780424405063; Tue, 02 Jun 2026 11:20:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMM1GP4QT19ebqtzfr7hvNZ5vi9yZBftJKEhM2slma1YUg==" Received: by 2002:a05:6820:1689:b0:69d:a6ef:f02a with SMTP id 006d021491bc7-69e0dd8028fls3308033eaf.1.-pod-prod-05-us; Tue, 02 Jun 2026 11:20:01 -0700 (PDT) X-Received: by 2002:a05:6808:1b0a:b0:47a:ae7:b604 with SMTP id 5614622812f47-48657115520mr561737b6e.21.1780424400876; Tue, 02 Jun 2026 11:20:00 -0700 (PDT) Received: by 2002:a05:690c:a71a:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7dc3470a1b0ms7b3; Tue, 2 Jun 2026 11:15:19 -0700 (PDT) X-Received: by 2002:a05:690c:6d87:b0:7db:b027:6161 with SMTP id 00721157ae682-7ea4c98b837mr47197b3.42.1780424118404; Tue, 02 Jun 2026 11:15:18 -0700 (PDT) Date: Tue, 2 Jun 2026 11:15:17 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <923b3d65-3472-4d7d-9b13-da44753fe5f8n@googlegroups.com> 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_211006_1737528734.1780424117906" 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_211006_1737528734.1780424117906 Content-Type: multipart/alternative; boundary="----=_Part_211007_920893510.1780424117906" ------=_Part_211007_920893510.1780424117906 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 a= =20 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.= =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, 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=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/= e0fa7417-ffef-492f-93d6-6c7ae6dbad6en%40googlegroups.com. ------=_Part_211007_920893510.1780424117906 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
They aren't really doing "additional checks" in the way you're framin= g it. There's just a new rule applied to existing proofs, no additional dat= a compared to before. That new rule is something like=C2=A0 given pr= oof : ([(Hash, LEFT | RIGHT) | ODDNODE ], Transaction)

then as you hash you just forbid that any LEFT | RIGHT or LEFT | LEFT is a= llowed 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 b= ecause you can't embed a txid sub-tree inside the 64-byte transaction to li= e 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 t= he SPV verifier need to do additional checks? SPV implies it's simply t= rusting the heaviest chain. Clearly they could validate it, but I'm not= seeing necessity in the security model.

Greg
<= br>
= 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 pr= oblematic, 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 malleability vulnerability to deposit / wi= thdrawal masking is a serious bug. Worth thinking that through very careful= ly before recommending 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 th= at does not receive funds to a script that either burns the funds or that a= nyone can spend.

The problem is that from the pe= rspective of a wide variety of layer 2 protocols, you actually do want to b= e able to simply close out a UTXO and prove a UTXO is spent.

<= div>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 may be making a different output availa= ble 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/e0fa7417-ffef-492f-93d6-6c7ae6dbad6en%40googlegroups.com.
------=_Part_211007_920893510.1780424117906-- ------=_Part_211006_1737528734.1780424117906--