From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 01 Jun 2026 13:22:34 -0700 Received: from mail-oi1-f192.google.com ([209.85.167.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wU99e-0004be-A6 for bitcoindev@gnusha.org; Mon, 01 Jun 2026 13:22:34 -0700 Received: by mail-oi1-f192.google.com with SMTP id 5614622812f47-486417cc069sf160148b6e.0 for ; Mon, 01 Jun 2026 13:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780345348; x=1780950148; 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=JEgq59NJyWlcONI9smjMzHSFxbV6N4Nsok11wAhp0Y4=; b=hLDzePqGjAn4kRD8Wb3MUFDCHl3TYFD3Xpi7qCpzWUYnKl1gUmXigARffxJkWjrZ5g nY0b/a1Q8RICZivmBJjrFK0VvkqXo+VrwvkHos0qS1yV/2A6atfj4/5RZPF0ZmJlsWMh y7tPV2eRNhewi+kWvax0u4DY6KjREf6tLJwkkWalNcnMOcQQQrFAS0CqHx3RVyvvP5Ds ltYKKzacPYvGmq7fsGCWrHRA3xO1WRT6zHlHcyrejYf5dTuRhe+tmbu6oyshe6TeuouI m2sBq/E5a3xy+YMCuV93h0uNZxRNvwq05l3Lj3zZiSYmt7zZN8tIbiWmtFKgOBB0a+e2 wK/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780345348; x=1780950148; 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=JEgq59NJyWlcONI9smjMzHSFxbV6N4Nsok11wAhp0Y4=; b=BcOKupBIbWTN/DRDwGnTL+qiGQq3mmQYuvOoju7o3IP735ti2WWjq0prDO4sBEvD1V EZfz2X8V53X40ErwatGzeZx4zzKW1wnmCnpH+RzAmqMPldoPGAUwMmQtD0zmNcW6dfNV zocK/yZXWLK6MqxrAdH5PSPXSU5r/XQiwj3YgyMOI6sX456aEytDEWGOwDhVmUyMWmcL i6SqoopGArSYqMFkMpnRSp9YzdbC3Mxz7stkKviq6aaXE3bu2EbNBrFwHZWnsLx3NVh3 j/FWr8FVAgsYmRflpW/svDl3ppEGor+3LwBPMLE7l2QzBMXfWv76rSBt+e+uErZjbboP wQVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780345348; x=1780950148; 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=JEgq59NJyWlcONI9smjMzHSFxbV6N4Nsok11wAhp0Y4=; b=hk3OkAmUyoDIPfdUUYJoeamJiJyepCgTMz/BGFkbqmn18nQOHLGTRylCXT+spXcviQ P6QF3Y610/QPQdTEWSDA3MvDRe3xj7zyvndjdwKKgTUH/leHzp9D5CDCK1hnKBN/ke/C BjGEBGrVszMp8jRjsLD3cxueGPvZTZW1R8+4c7TVQJg8bpzqewOKbcQ8lIHdVo1d2hoo nuoEM/wOg89NU3BIfB8Vlx3S44624gPYgS7YFfzylg9rnVXo3cbXyV6kk8dX9no/wlqA 5CHWtvwupT6vQdAryc8fmLt0aAsu7PRCsWFdtuKa996JjcPFMOXPS0T3k0LhWxFXzSYM GnGQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/wdKmTkfD+t1a1OTcm0+XL2aYTk4jZ9t6/EpiNqE8X1r9+KewApImddQIQfQ1b7DWa2bwSfOCyGfxI@gnusha.org X-Gm-Message-State: AOJu0Yz39ewKmSFDkF7k/Zh6ftH9tFnuTWvCu8sjIpx+kkRnWW8RPlkX NkLQIE+JOgy9mZOJXRCmO+zAx4EHkgwtcMhMbnCIENiETL0zpZskQvLo X-Received: by 2002:a05:6808:1247:b0:47b:c8d0:514a with SMTP id 5614622812f47-485fbc95ad7mr6803057b6e.46.1780345348053; Mon, 01 Jun 2026 13:22:28 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMnlOQYAcGWtuGyl+wyfcEoqEOTJIzxXiMeqRTPYsRjeA==" Received: by 2002:a05:6870:e98f:b0:42b:ccd3:8890 with SMTP id 586e51a60fabf-43c51b3ef7dls2114603fac.1.-pod-prod-00-us; Mon, 01 Jun 2026 13:22:23 -0700 (PDT) X-Received: by 2002:a05:6808:e86:b0:46a:17b8:bd7f with SMTP id 5614622812f47-4863e7c2d94mr562446b6e.19.1780345342959; Mon, 01 Jun 2026 13:22:22 -0700 (PDT) Received: by 2002:a05:690c:a6c3:b0:7d0:63a3:69e7 with SMTP id 00721157ae682-7dc324939bfms7b3; Mon, 1 Jun 2026 13:17:47 -0700 (PDT) X-Received: by 2002:a05:690c:700d:b0:7b6:dada:4017 with SMTP id 00721157ae682-7e83e8ac2b8mr10487007b3.24.1780345066308; Mon, 01 Jun 2026 13:17:46 -0700 (PDT) Date: Mon, 1 Jun 2026 13:17:45 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_483138_1875171861.1780345065874" 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_483138_1875171861.1780345065874 Content-Type: multipart/alternative; boundary="----=_Part_483139_1325799705.1780345065874" ------=_Part_483139_1325799705.1780345065874 Content-Type: text/plain; charset="UTF-8" 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 malleability vulnerability to deposit / withdrawal masking is a serious bug. Worth thinking that through very carefully before recommending these mitigations. Do you have an end-to-end working example 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 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, 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 -- 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/bitcoindev/45558bbd-762c-45a4-a4a1-6105d7462a8en%40googlegroups.com. ------=_Part_483139_1325799705.1780345065874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Antoine,

Rejecting nodes with any valid tx = in path, without this rule, is problematic, because it _can_ be possible fo= r an attacking miner to engineer that scenario by grinding one TXID leaf to= mask a subtree, which could have major consequences. Third party malleabil= ity vulnerability to deposit / withdrawal masking is a serious bug. Worth t= hinking that through very carefully 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 that does not receive funds to a script t= hat 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 desi= gn space, value doesn't always flow directly along the output,=C2=A0 the UT= XO 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 al= ternative 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/45558bbd-762c-45a4-a4a1-6105d7462a8en%40googlegroups.com.
------=_Part_483139_1325799705.1780345065874-- ------=_Part_483138_1875171861.1780345065874--