From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Jun 2026 05:40:12 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wUOPk-0005HG-5d for bitcoindev@gnusha.org; Tue, 02 Jun 2026 05:40:12 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-43b7d6f0d56sf12833129fac.1 for ; Tue, 02 Jun 2026 05:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780404005; x=1781008805; 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=TxtSs53TqMRrBrmUsTYs6grpxxzInZqhU2kfD23kACE=; b=JslUV21ZJvTkI879WfSTLAZbwbAGKQxQzX4y3jb7JyTEDH3X6/98Ba4RD2Mobg3ULO q/LhUA6wzF1SXXqSo8i+jJYJvUjcCp4guMmAjjA2kKBSDrMCK9C1+JN3kCPq0yorrruP BwkJ5Rczlq5+t1DcBUNGTS9q1aLM+zDOXByWqnU28SU4Xnca71Kn4lF745UE7otBwpkJ f1B93qNAl/u3ZXn8m9Chk/lhZxpzXN7JLsFO3vxgRBPa/tOcAF/y/AsmdQils6ODeoHV 6DkZKGS1drENOGEyJJrIAkZcn6Iuk/ESiwkDO0s1QHD4dpLKzRcgaZiszfKJrfTavDTK 5z/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780404005; x=1781008805; 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=TxtSs53TqMRrBrmUsTYs6grpxxzInZqhU2kfD23kACE=; b=MIxfyPpafqKkl5Ge3aIbGnZgCvyLvyyqjlxlONDSE3ct7XiLO5t+nJPzfD+/TVzaAQ ZK38rpWAHPrRm3woPTDUi4gKYwrj6goSwjk6+oPrxDxIJd/2Ka9LvWFLZUPqO5Q7+Kda 4oi4d1j+wzZSiiMmGIABmouPb1jGqBZA0YU1FAK805TqiPS+/0i38Xv9ygP7jtGX2uhL HW9sSmf8Sy7d9K0swlINcYtjE9tX/MUeF/6ypmbVjD95ym4nOQGefReewktZp7fmJnUV GOQXluoFilac8lTgZLyytDLnvBBY/G6cBZHKCTZ9hP91CIy73ZGMnEoCJHErTRfXguVY eZlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780404005; x=1781008805; 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=TxtSs53TqMRrBrmUsTYs6grpxxzInZqhU2kfD23kACE=; b=N4s7r0ZVor46IvZWI3eAVX9Ro6fD+XH5je04l6k7lNgJZm6xAMiYq7JMVE8OCsrNqJ ISSfhp0HKyO8mKlJiaBWCw5UZLe+u6n5i5qEfG8ynxL0JuYw8js819f7EDRv9ACKxCgX zIj60hxYdgPrDrRZ7iaKhE2FjhdH/YUmstjNhmEMA911GOiYRgmSZzFnAY9MYkB2JEcY 6t5BQuim4KqNKa+f/No+OdfZwSNNxdTR0TN3Pasg2JKDaSYyoo6m3+0+Jzbf6l0k1U9w 94GeqtCLtrfM62rw8HOZlxLAQvHEW1UJkT3mj++I1E7R3Z8WBb5zkW8ZmjR4rmSD9GVO O2UQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/DekaKQnrvXsAZqhUy3WJu94Git6C/YZUCvrfsojO0HRVCv8+GPhKvS0RlPHhScXDrNQrXNW2650s1@gnusha.org X-Gm-Message-State: AOJu0Yyfm34i5yTgsKKpELbGq8syzv5n9r+LuxKJdAWUdE+fCrfvTWxh iv2LB/u38IOjywwuREUDDchpju7HggzLUUmtlQhohNVXsFyW6q80ibLe X-Received: by 2002:a05:6870:1704:b0:43d:2ce6:4f64 with SMTP id 586e51a60fabf-43d2ce7def9mr1975555fac.9.1780404005524; Tue, 02 Jun 2026 05:40:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOmiKIaZuDyFxi6C5DGLwY0LBed5KDvcFs7edCDIeHbbg==" Received: by 2002:a05:6871:c5c8:b0:430:279e:462b with SMTP id 586e51a60fabf-43c5144b2f8ls1936965fac.0.-pod-prod-06-us; Tue, 02 Jun 2026 05:40:00 -0700 (PDT) X-Received: by 2002:a05:6808:5296:b0:47b:c8d0:512e with SMTP id 5614622812f47-485fb4bf079mr8256533b6e.34.1780403999930; Tue, 02 Jun 2026 05:39:59 -0700 (PDT) Received: by 2002:a05:690c:5688:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7dc2f3656ccms7b3; Tue, 2 Jun 2026 05:36:57 -0700 (PDT) X-Received: by 2002:a05:690c:22c7:b0:7b2:bf20:cdc3 with SMTP id 00721157ae682-7e05242d43fmr153996687b3.0.1780403816367; Tue, 02 Jun 2026 05:36:56 -0700 (PDT) Date: Tue, 2 Jun 2026 05:36:55 -0700 (PDT) From: Greg Sanders To: Bitcoin Development Mailing List Message-Id: <923b3d65-3472-4d7d-9b13-da44753fe5f8n@googlegroups.com> In-Reply-To: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@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_135662_545833406.1780403815933" X-Original-Sender: gsanders87@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_135662_545833406.1780403815933 Content-Type: multipart/alternative; boundary="----=_Part_135663_639561105.1780403815933" ------=_Part_135663_639561105.1780403815933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, which= =20 > could have major consequences. Third party malleability vulnerability to= =20 > deposit / withdrawal masking is a serious bug. Worth thinking that throug= h=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 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/= 923b3d65-3472-4d7d-9b13-da44753fe5f8n%40googlegroups.com. ------=_Part_135663_639561105.1780403815933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy,

Why does the SPV verifier need to do additi= onal checks? SPV implies it's simply trusting the heaviest chain. Clearly t= hey could validate it, but I'm not seeing necessity in the security model.<= /div>

Greg

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

Rejecting nodes w= ith any valid tx in path, without this rule, is problematic, because it _ca= n_ be possible for an attacking miner to engineer that scenario by grinding= one TXID leaf to mask a subtree, which could have major consequences. Thir= d party malleability vulnerability to deposit / withdrawal masking is a ser= ious bug. Worth thinking that through very carefully before recommending th= ese mitigations. Do you have an end-to-end working example of such a mitiga= tion that doesn't have these issues?

>=C2= =A0This is in= correct for any bridge, wallet, or deposit system that does not receive fun= ds to a script that either burns the funds or that anyone can spend.=

The problem is that from the perspective of a wide var= iety 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 p= rotocol design space, value doesn't always flow directly along the outp= ut,=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

--
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/923b3d65-3472-4d7d-9b13-da44753fe5f8n%40googlegroups.com.
------=_Part_135663_639561105.1780403815933-- ------=_Part_135662_545833406.1780403815933--