From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 15 Jun 2026 19:39:38 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZJiD-0004nu-PY for bitcoindev@gnusha.org; Mon, 15 Jun 2026 19:39:38 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-44100eba7fbsf6743641fac.1 for ; Mon, 15 Jun 2026 19:39:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781577571; cv=pass; d=google.com; s=arc-20240605; b=En2+0K9EkDYYKhQ5mNtu28Lnn2rASZdkzavZjg3dLi+BKhFbPl5cJKYHOeHMCMAqht 9lGFGx7/aNRjS9Psp9LPIep+evYy+5wPDtH3I38DN9lxYZDp2iHAmNDAsjfkzTznKTrW +BL1WfMyEf7ctG6P6Q44fWWJ3tJcXgcu0AePYqsGk4N6D0f0phMxTcHdrlmwEpjkIKid 4kLOgMD1UQ7PR+vmbRTGV41iHcYMk/Eg3LYMc5Hy23AR3sCz0qmiZtJ2AP5slIFPRaLY p9TWmE9BUTQ33VnaVRTiDVxDI4JVtUwaDzNcm5Y7cqYvJ7NpeDBGVGGZWwTTtWgwpABi fFZw== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=/FW+9xX6A6Apje9BIEOVKjGy0OZc0uOlvkInSLfsJyk=; fh=gywNTk212uGvfx6s9gxiTxedju+TY4qZmGvjdJHOVrI=; b=Wzr9cER6ijhZP225vI1UzQ+4MkTTfw3yTtIcS2/9RbVAsiUi80Z5X0lPHKIOT1kZdO velPh0uqjINKWkcIbcoH7eXwYhGlfotaT9neL6ygywUr+ca8JERU8+F6uUKGjFhRj4v6 mCCUCR+3dCFECplcpptD8N9hSvi7mne81FF4iaZxsfKakvM94nMUkpzP4ryVjF0noqAw RTWBY5R5q7uWtUlVPdO7qB/+gIaj78eEA4ziXnthmr4NJkpT4ICSQoweTGfh7DENqXcg 49Jp6NttJM6oiQKHiJxni0Dph4zApDiiEuU/sanS9w2sdNwefosV9VH5fne85CRx0px3 DY+Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="YZLFp+t/"; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781577571; x=1782182371; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=/FW+9xX6A6Apje9BIEOVKjGy0OZc0uOlvkInSLfsJyk=; b=o4E+ePry756tIn5khUkiM1oJnfiaeEaZ39ykrzQlHlAP9XPbgtlk6c9cBxNQjXz3lD 7srvkkXqOwpPjVQX+HRCULF+4Qei5C3S8d0Bkfyi8b+8RhBv4iDc0XEhIY72+lZItKr5 wZdWAVPZWkrRVajLrHQaAp43Z/m9zAOF9JQ0N1PdgJffJFlf/pMBlgLmMc6mTzStVWk5 JOKLz51gRT7ngOOEM7VQLyvTA6GgxAJpOCERmlKC6sMFJf/nytY5BdycpVuYR2AIlYaP ZfvFAlAzYJHblXLi7LA7bit+x6bHcLzh7dr/+ewRfHIp4Wi69rOEEo1GgZyYjqV9D2c2 V11A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781577571; x=1782182371; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=/FW+9xX6A6Apje9BIEOVKjGy0OZc0uOlvkInSLfsJyk=; b=pBsG3kRwTAKmjV70iat7MJxfnCFIPyJCRrqE8ikBEUAlZdSy55aMAwVjzG4YbFYm54 BAx8GeR2B2Tx2V709c0z8F2xi/yaj5MiKqq4k44VKQi4gksg1hqJue7XHYZQyarGc7+C Bod2Jc+sJ8evuU0wDzdvGeHD0oKybFT4ZdBKhVWEq1P6NsgalNqJong2j59TQF7E412A IS94zg6bqWs+O5cCc0K+Uuo1iZf1vJ7oLttR+xkJwLJaIzJwegpGHam0f4BFRlauVQFF jxZAKMPaU9jM36YnCteMwbd+uOH+Z0Vd51210OMl41MXuBY4c2+s6ZovuLLU0Ofa/4se 1pZw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/Eu33xYPKuyfo/w9T9KeHlS9TkHDkVNOYCk7kd729aMMbutxLdu8EyoBeHb7cSXEGTn9MiBmA/n4vt@gnusha.org X-Gm-Message-State: AOJu0YzC9Y6IzT3WJVizdKvw3A6Nv96NRLfYdTPE0z/zwHQMrzm6sc4Y vlKBMwjCW05NTkqPV9Cc3cUOZB4upyQNS8vlVApj3u/3twxmsd7l95T9 X-Received: by 2002:a05:6870:21e5:b0:442:e783:8b2d with SMTP id 586e51a60fabf-4430ac812cfmr1534659fac.17.1781577571067; Mon, 15 Jun 2026 19:39:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdp0TpwIsdRPLBT98mo3udyM/UHMad0+1lLVfVdQK/puA==" Received: by 2002:a05:6871:a810:20b0:43d:1d34:8bbb with SMTP id 586e51a60fabf-442617c538cls1536417fac.0.-pod-prod-01-us; Mon, 15 Jun 2026 19:39:26 -0700 (PDT) X-Received: by 2002:a05:6808:4f25:b0:46a:7ab9:c339 with SMTP id 5614622812f47-4880c3fea00mr1857863b6e.14.1781577566122; Mon, 15 Jun 2026 19:39:26 -0700 (PDT) Received: by 2002:a05:600d:8498:10b0:490:3d60:134 with SMTP id 5b1f17b1804b1-490ea95ddb5ms5e9; Mon, 15 Jun 2026 19:36:03 -0700 (PDT) X-Received: by 2002:a05:600c:45d5:b0:490:b65f:8b1 with SMTP id 5b1f17b1804b1-4922ff728cbmr24745455e9.5.1781577361955; Mon, 15 Jun 2026 19:36:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781577361; cv=none; d=google.com; s=arc-20240605; b=dpd79wDbmepGD7iSobTB1XmgN2nSC/k4IZb42k7GJwyDz7PUiEVOgUhIvyq4nNIBEP b4kj/clWUIRoDC1sYfZTNVaWkpuU/bCPvhATSqP3X5QDBSusoLG6Vsy190fisHqLzXhm QPVh23a/4VftNQWvceV9qVD5WkumSBAIY3+UwiofJV2pPnoPACvPVmDmPCj1ShwDL6FR D3Te/8EtaS1h9xoEuzZztx9tuHnJQBznhgotYCSYN09f/4u83kMPJzI4JE4umeJY0nnq 1RS8Q0fDx42G2+VVwIT8vj2Pizc7TEHrtLqd4OFMHzoiRCf+Esd/uRX7b9LOMlPYtwVO aUvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=R5zhc27dvErRTYTWDsJYSJVcSLLSt52EzQjYAlQlJjE=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=akxmYcC3Wywz9fIk4AnaFqE1mn+S7D2LObqM50agN96Nd2+2Nb2wnziEn/wmhTmvJR oDhhobB+xO60/otamA3yS9e+GVQqBLIy3nMIs0WVdDE0jECCYt0C+a46Jilnj2lnPvCd 8zXzw6EPlNJM4kwFS/LzjBm3qWPfulcDZgXQNWtYrXMovhRMp6nr1mUqzFhA9mRzgxLK f+aRwhiP0ZnBirPgw65hhd74APKBJFTfmuq4MCT6lA50s+9L4ibjZ8ZBOUzM5EqX+hjp QJ9WLh89sEvlb9DOkf+tVuDziZ0mpbw8mU3VB/IK3SbM6CsyvpKhlTQ3ntxPI787JrtD 4qYg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="YZLFp+t/"; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate02.uberspace.is (mailgate02.uberspace.is. [2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-490ead28108si987975e9.1.2026.06.15.19.36.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 19:36:01 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) client-ip=2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate02.uberspace.is (Postfix) with ESMTPS id 8363B17FC75 for ; Tue, 16 Jun 2026 04:36:01 +0200 (CEST) Received: (qmail 26729 invoked by uid 989); 16 Jun 2026 02:36:01 -0000 Received: from unknown (HELO unknown) (::1) by farbauti.uberspace.de (Haraka/3.1.1) with ESMTPSA; Tue, 16 Jun 2026 04:36:00 +0200 Message-ID: <7eef94c5-1c75-4ad4-8b04-b09a065d3797@murch.one> Date: Mon, 15 Jun 2026 19:35:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions To: bitcoindev@googlegroups.com References: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> <178b550d-841f-43d6-8c4f-67e909cc17bfn@googlegroups.com> Content-Language: en-US From: Murch In-Reply-To: <178b550d-841f-43d6-8c4f-67e909cc17bfn@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-3) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.09 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b="YZLFp+t/"; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) Hi Jeremy, As AJ pointed out in "[BIP-0054] 64-Byte Transactions and Potential=20 Legitimate Uses", forbidding 64-byte stripped transactions would at most=20 incur that transaction creators have to pad a to-be-invented use for an=20 anyone-can-spend output script with an `OP_NOP` if they hit the 64-byte=20 case, or if the uncertainty whether the case will be hit is the issue,=20 to circumvent it per paying for one extra byte by always padding. Could you please explain why potentially needing to add a 1-byte padding=20 for an "esoteric use case" is a bigger burden for the ecosystem than=20 saddling every node with checking thousands of hashes during block=20 validation on whether they match a valid transaction pattern? As far as I=E2=80=99m following this conversation so far, this proposal=E2= =80=99s=20 trade-offs don=E2=80=99t feel convincing to me. Cheers, Murch On 2026-06-09 09:37, jeremy wrote: > I also want to make an opinionated point here, separate from the=20 > technical message above: >=20 > These are esoteric use cases. This is precisely why it's important to=20 > get right. The edge of understanding is where future protocols end up=20 > with exploitable vulnerabilities. > On Tuesday, June 9, 2026 at 12:30:31=E2=80=AFPM UTC-4 jeremy wrote: >=20 > Well, it's definitely possible to grind s.t. you have a higher up > node that _looks_ like a transaction.=C2=A0 It would be grinding an > interior node that has the desired shape on the left (5 bytes) and > on the right (depends what you're grinding for, but it's mostly the > length fields and script that need to be specific). >=20 > You can then in theory have a proof system that is tricked into > thinking a UTXO exists that does not actually exist, and it might > think it's spendable in a given block. >=20 > E.g., if the script is CLTV, this would be provably not spent > until block H. >=20 > And the SPV proof would be admitted. >=20 >=20 > then you'd have proof of tx + proof based on script of not until H ti= me. >=20 >=20 > What /could/ something like this be used for? >=20 >=20 > Let's say some sort of "proof of mutex of miner claim" -- many > things can be offered to a miner conditioned on them using a > particular height locked UTXO to claim it. >=20 > Since they can only spend the utxo one way, they can only pick one > of the offers and the others can expire. E.g.: >=20 > Faked Output X: H w/ CLTV >=20 > TR{Nums, { CLTV CHECKSIG, CLTV > CHECKSIG}} + Presigned via MuSig spending X using SIGHASH_NONE to > allow late binding of the miner's preferred destination (or not > SIGHASH_NONE and an OP_TRUE) ; >=20 > or if GETINPUT opcode existed: > TR{Nums, { CLTV CHECKSIG, CLTV 1 GETINPUT EQUAL}} >=20 > ---------- >=20 > As you note, it won't be spending a known output, because of the > hash boundaries. But I can still think of protocol applications > where creating a false connector could be harmful. >=20 >=20 > ------------ >=20 >=20 > The rule I propose mitigates this issue because it would be > disallowed to have any deserializable txn as an interior node. > On Friday, June 5, 2026 at 5:39:49=E2=80=AFPM UTC-4 Antoine Poinsot w= rote: >=20 > Jeremy, >=20 > 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 > that accepts proofs for 64-byte transactions." >=20 > 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). >=20 > In fact this is also true for any SPV verifier that expects > proofs for transactions which could be 64-byte, as long as it is > computationally infeasible 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 > connector 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 able to fake a proof for a > 64-byte transaction that anybody else would be able to create > anyways. >=20 > So i think the point stands that preventing malleability only in > one direction (by invalidating 64-byte transactions) is > sufficient, and does not require SPV verifiers to do anything. > Do you have a counter-example? >=20 > Antoine > On Monday, June 1st, 2026 at 4:22 PM, jeremy > wrote: >> 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 >> >> --=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 email to bitcoindev+...@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/ >> msgid/bitcoindev/45558bbd-762c-45a4- >> a4a1-6105d7462a8en%40googlegroups.com > groups.google.com/d/msgid/bitcoindev/45558bbd-762c-45a4- >> a4a1-6105d7462a8en%40googlegroups.com>. >=20 > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com=20 > . > To view this discussion visit https://groups.google.com/d/msgid/=20 > bitcoindev/178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com=20 > bitcoindev/178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com?=20 > utm_medium=3Demail&utm_source=3Dfooter>. --=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/= 7eef94c5-1c75-4ad4-8b04-b09a065d3797%40murch.one.