From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 05 Jun 2026 14:39:56 -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 1wVcGh-0005D9-Pv for bitcoindev@gnusha.org; Fri, 05 Jun 2026 14:39:56 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-4412c255fd4sf2195720fac.3 for ; Fri, 05 Jun 2026 14:39:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780695590; cv=pass; d=google.com; s=arc-20240605; b=kKAOESiloQ/NYW35yj/X9fcFop92xOlOLtlvo+4GWSwZmhijkUeZTD6BO96LDAJ9sh RpztJFRvTUK2yCRX0pSeQCWX0OJ4R/qjjpA1bwLhI7AueezSZOUPj/KyFE1uF1Qme/0h ceNH+s68EZtK1ApLAj7Gd55o0UlAmkdWPQJbOIBdiSWgm1cNfrZnmcdR3MTgl6Ce1z2O uu+9rB7ncMiNTNBlEBEu0X/sAmstECZHpKM+W/Bnu/cq6wdCS/P5HJfY0kKjECX1j/eg sICVN+JcDeq956xngTfydaB1zrrsu7ZdkkbXw/7p4B9XcSCOTE33AHtUidYUVlGl9+pw zrtw== 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=UeTNXG69sC/5p+cWzDnsQ7j1Rgs9TtEyB0aEeNCfgXA=; fh=6Y78o2yuEujqG9shzrTdjc9XmGYc/YqdCaAXGgXHZZo=; b=KirKAnhvNFbbsE55MSN4JWH5cWtvhi52BvlzS4VLivZnY4n2aIp1cNBcgkX4H7m6ue DyehRizqZRSgXuetrpA5cKSrQ09EPKUtiJD6614QJz7SyEO5zpQ4EGT2yKPKbKwLSV+K GL2fiSn08FYpqoikJVz/1wMZ+lFPgyf70l9mybvOSeakXCU5diF1Z2sglGfzYa6+onlp YGB6EbvpYp13ByL25v4IZBulAsmI99iWbi1LeG9MO5ncJ95JTKBeyq3B+Od9vfdu6WWr UYsLnWc0GmAKSPN43ONEjmJijxGldlHf30x1Tt1fD7SV0QJYbOwT+hijc3bAce145UtX 6OeA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=AT6GzQa0; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 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=1780695590; x=1781300390; 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=UeTNXG69sC/5p+cWzDnsQ7j1Rgs9TtEyB0aEeNCfgXA=; b=d1BDYVUcp4Fr/ornCx2aDKU0n3NqBhRFnPW//q8+gdKfyJd2u5l+QL3sxDwGdouRdb Ml54+iBuLeoPm+rRm1y+b9v8pWwebjJwTb2LG66P9mf5k+EWbML/qtXOMyhY/+g0ZZhA Z0qXJuqPODU5ZdmZIpVwpfV3aKqMWVvApAf0lLigxkWOWnssd76HSofh2wGPo9RrGWLo 7VFx0tHYE41HmayuCwYQxEIgIovLKrv6QkV1SQud/aJlWJt6em9CxhxGMc+ISUaXIK65 RtfE5AMwDWziJnAjcJ8hLE26WQrGdSawaRExV6BVB1R6i+FlzOi18uCpdT9qT9efCnd0 eDKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780695590; x=1781300390; 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=UeTNXG69sC/5p+cWzDnsQ7j1Rgs9TtEyB0aEeNCfgXA=; b=ElbpWXbz6wsid9GTeJXiSgOfDlKBPLPjyVSevTG6XPL+76OtyOcrGTY4Pbmdxnh7IF 1kqTM+h8XZzrSIYqR4aRGytSqgsThhvEvkHcqn/Jnoo63D9+ciEe525CeeK9KOMdYs/k g/pZD/Z2OocARZSJQkN+lb40sdoFbSuN88Xbhywu8CtNF9+iNHx8VCttsNMPNVNNymvD D2cbWncchOtNzZut/VoFbZgvp+lhCxXg0wA0TjFpkVxO2mm1wLtyonQwIx/5c/XSH81c OyQH1zQTdo+IEBXbIGmrfFW6P44GAzBoFZC02PExnxt+wIbHm/mR5CXLfIGP6nBNNns5 6bgw== X-Forwarded-Encrypted: i=2; AFNElJ8p6dQJN91RI9QM+Nc3oFtINKmXZdV5HQokkpZffzzI4EiKS8HtffWshqvHRxBggSZKpQaTx0gNhWNV@gnusha.org X-Gm-Message-State: AOJu0YwOIA0WjI8x9F0fGAqm1KQWXjAmtRALkMs6ZYGpsQGqHRfv1rh1 rojiRnxActUo+8IRrw5Re8WARwmwi/yNIWb5ob71+Crz23Hapjj5ObFM X-Received: by 2002:a05:6871:7b0e:b0:43b:722c:d2a with SMTP id 586e51a60fabf-4413db707f2mr3325016fac.19.1780695589792; Fri, 05 Jun 2026 14:39:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNS2Ynly9pyx+3F219/wIQ9TG3BEaxePvp3rlGgbsX2Xw==" Received: by 2002:a05:6870:e60b:b0:441:4757:d51e with SMTP id 586e51a60fabf-44147581107ls649183fac.0.-pod-prod-02-us; Fri, 05 Jun 2026 14:39:45 -0700 (PDT) X-Received: by 2002:a05:6808:c227:b0:485:41fc:71dd with SMTP id 5614622812f47-4868dbf89dbmr3725579b6e.13.1780695585770; Fri, 05 Jun 2026 14:39:45 -0700 (PDT) Received: by 2002:a7b:ce06:0:b0:488:963a:630a with SMTP id 5b1f17b1804b1-490c25f2483ms5e9; Fri, 5 Jun 2026 14:34:13 -0700 (PDT) X-Received: by 2002:a05:600c:8a1b:10b0:490:be1e:6ce6 with SMTP id 5b1f17b1804b1-490c265c075mr65083245e9.9.1780695251565; Fri, 05 Jun 2026 14:34:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780695251; cv=none; d=google.com; s=arc-20240605; b=QCNukpPqTt/Sd/1HZI1GCbeqJ9Zh3FL6I64IZpr+V4Yjyk6I61egKo7O3eEGFt6GIN GUi0KKwnRkRj7y6wLeohZ1WrkwZFkDIq1klZjlnEjgA7Q2JgdYK9Fvbq7sltRhDJYg8r S1D+7ykXzDSxu5SvQg0REZRqDUA+Xyn7ZT6eZm+kZ/M5uOI4EgaxKFQb9dOwIUIJWw31 P2dwBg5RPt/W5orY4OPR5TkSIa2+JTcvVpicTnTSIXqdIVE6XzYrziapWq8MHiiOi9u8 ppQOluDqAuZYGpxNxiV2w4HTeWPErjQFauqFIQyHwJDffdmNX/D0xjj92NXqkNVPjIji ZBWA== 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=IOaWXWg9OduwhpEZ/0APazgIGq45uU8J2bABnIaKayw=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=fXBv74YFcipdS7xa2PhKPKr6w1Y5XwRUu3Sf/T7a/ipAZvvwtmxbtUBARs5tBU5We3 gG6UWJAONTgn9XOXm/MBL6buHwddin18vLzfyWHX4CV4eVoTlN+6pUP/De8cIPKCN9Lu M0MD3/ZIWwDy8D3aqRUngcjH0GP5V0mARlfhSmdP46vZzGSXmaJnXIUXHRImAexJEf7C PWQrPkbR/LC+ko88+eYo75gNaeQEg1DZcgBxbR7nBgXFIRpA4C7iABLUG31AB58FU44a u6b8+aoEmjCPuJhRIt2NVQcMPgZ2XBGFoxL34fDbYaRgmQLpYAqq5nxsz7la/jOq4wRW 93ew==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=AT6GzQa0; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4601f322e86si188800f8f.4.2026.06.05.14.34.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 14:34:11 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Fri, 05 Jun 2026 21:34:03 +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: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 84dde3c2f895bfe7d999c8b28d88e641a27e9258 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_Yx7XIqj2gytZinI29NJ9S88Nh5xShabC6cinyikKj0" 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=AT6GzQa0; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.16 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=_Yx7XIqj2gytZinI29NJ9S88Nh5xShabC6cinyikKj0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeremy, Good point. I think this could be more straightforwardly restated like so. = "Invalidating 64-byte transactions 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 th= at accepts proofs for 64-byte transactions." So you are correct that BIP 54 should only claim that invalidating 64-byte = transactions addresses the issue with no change to SPV verifiers for those = SPV verifiers that expect proofs for transactions that cannot be 64-byte (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 tran= sactions which could be 64-byte, as long as it is computationally infeasibl= e to grind those transactions. 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 connecto= r 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 ab= le to fake a proof for a 64-byte transaction that anybody else would be abl= e to create anyways. So i think the point stands that preventing malleability only in one direct= ion (by invalidating 64-byte transactions) is sufficient, and does not requ= ire 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 problema= tic, because it _can_ be possible for an attacking miner to engineer that s= cenario by grinding one TXID leaf to mask a subtree, which could have major= consequences. Third party malleability vulnerability to deposit / withdraw= al masking is a serious bug. Worth thinking that through very carefully bef= ore recommending these mitigations. Do you have an end-to-end working examp= le of such a mitigation that doesn't have these issues? > >> This is incorrect for any bridge, wallet, or deposit system that does no= t 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 pro= tocols, you actually do want to be able to simply close out a UTXO and prov= e a UTXO is spent. > > In the current L2 protocol design space, value doesn't always flow direct= ly along the output, the UTXO may be being used as a connector input, and t= he 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 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/45558bbd-762c-45a4-a4a1-6105d7462a8en%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/= zsUBtB2e_nQ-rup8cdIacq139Y1FznGRLQfq8XQ2lM-6SZNk3Kfucj2pxvX0YQ0QW1G2liAhenj= 8xYBFGqvzGLvtwZYFE5r1Xo2Y91O_Mz8%3D%40protonmail.com. --b1=_Yx7XIqj2gytZinI29NJ9S88Nh5xShabC6cinyikKj0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeremy,

Good point= . I think this could be more straightforwardly restated like so. "Invalidating= 64-byte transactions only fixes malleability in one direction: confusing a= leaf for a node. However malleability in the other direction may also be e= xploited by grinding an inner node to trick an SPV verifier that accepts pr= oofs for 64-byte transactions."

So you are correct that BIP 54 should only claim tha= t invalidating 64-byte transactions addresses the issue with no change to S= PV verifiers for those SPV verifiers that expect proofs for transactions th= at cannot be 64-byte (i.e. checking for deposits to any interesting scripts= , or more generally any transaction through which value actually flows).
<= span style=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight:= 400; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
In fact thi= s is also true for any SPV verifier that expects proofs for transactions wh= ich could be 64-byte, as long as it is computationally infeasible to grind = those transactions. Interestingly, this is true of the connector output exa= mple you gave! If 64-byte transactions were invalid and a miner wanted to a= ttack a protocol by faking an SPV proof that a specific connector output wa= s spent, it would need to grind over 256 bits for any inner node to match t= hat prevout. So really 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.

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

Antoine
On Monday, June 1st, 2026 at 4:22 PM, jeremy <jeremy.l.rubin@gma= il.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 a= ny bridge, wallet, or deposit system that does not receive funds to a scrip= t 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 an= d prove a UTXO is spent.

In the current L2 protocol desig= n 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 ma= king a different output available after a timeout and excluding an alternat= ive spend.

Best,

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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/45558bbd-762c-45a4-a4= a1-6105d7462a8en%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/= zsUBtB2e_nQ-rup8cdIacq139Y1FznGRLQfq8XQ2lM-6SZNk3Kfucj2pxvX0YQ0QW1G2liAhenj= 8xYBFGqvzGLvtwZYFE5r1Xo2Y91O_Mz8%3D%40protonmail.com.
--b1=_Yx7XIqj2gytZinI29NJ9S88Nh5xShabC6cinyikKj0--