From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions
Date: Tue, 9 Jun 2026 09:28:49 -0700 (PDT) [thread overview]
Message-ID: <75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com> (raw)
In-Reply-To: <zsUBtB2e_nQ-rup8cdIacq139Y1FznGRLQfq8XQ2lM-6SZNk3Kfucj2pxvX0YQ0QW1G2liAhenj8xYBFGqvzGLvtwZYFE5r1Xo2Y91O_Mz8=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5583 bytes --]
Well, it's definitely possible to grind s.t. you have a higher up node that
_looks_ like a transaction. 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).
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.
E.g., if the script is <H> CLTV, this would be provably not spent until
block H.
And the SPV proof would be admitted.
then you'd have proof of tx + proof based on script of not until H time.
What *could* something like this be used for?
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.
Since they can only spend the utxo one way, they can only pick one of the
offers and the others can expire. E.g.:
Faked Output X: H w/ <H> CLTV
TR{Nums, {<H+1> CLTV <PK> CHECKSIG, <H> CLTV <MuSig Federation> 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) ;
or if GETINPUT opcode existed:
TR{Nums, {<H+1> CLTV <PK> CHECKSIG, <H> CLTV 1 GETINPUT <X> EQUAL}}
----------
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.
------------
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 PM UTC-4 Antoine Poinsot wrote:
> 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 that 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
> 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.
>
> 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?
>
> Antoine
> On Monday, June 1st, 2026 at 4:22 PM, jeremy <jeremy....@gmail.com> 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
>
> --
>
> 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
> .
>
>
>
--
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/75d0e9bd-3bdb-444b-9087-f8a082183253n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9182 bytes --]
next prev parent reply other threads:[~2026-06-09 16:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 17:46 [bitcoindev] Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions jeremy
2026-06-01 18:49 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-01 20:17 ` jeremy
2026-06-02 12:36 ` Greg Sanders
2026-06-02 18:15 ` jeremy
2026-06-03 1:05 ` Antoine Riard
2026-06-03 15:07 ` jeremy
2026-06-05 21:34 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-09 16:28 ` jeremy [this message]
2026-06-09 16:37 ` jeremy
2026-06-09 18:30 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75d0e9bd-3bdb-444b-9087-f8a082183253n@googlegroups.com \
--to=jeremy.l.rubin@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox