Hi Jeremy,
As AJ pointed out in "[BIP-0054] 64-Byte Transactions and Potential
Legitimate Uses", forbidding 64-byte stripped transactions would at most
incur that transaction creators have to pad a to-be-invented use for an
anyone-can-spend output script with an `OP_NOP` if they hit the 64-byte
case, or if the uncertainty whether the case will be hit is the issue,
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
for an "esoteric use case" is a bigger burden for the ecosystem than
saddling every node with checking thousands of hashes during block
validation on whether they match a valid transaction pattern?
As far as I’m following this conversation so far, this proposal’s
trade-offs don’t 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
technical message above:
These are esoteric use cases. This is precisely why it's important to
get right. The edge of understanding is where future protocols end up
with exploitable vulnerabilities.
On Tuesday, June 9, 2026 at 12:30:31 PM UTC-4 jeremy wrote:
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
<[email protected]> 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 [email protected].
To view this discussion visit https://groups.google.com/d/
msgid/bitcoindev/45558bbd-762c-45a4-
a4a1-6105d7462a8en%40googlegroups.com <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 [email protected]
<mailto:[email protected]>.
To view this discussion visit https://groups.google.com/d/msgid/
bitcoindev/178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com
<https://groups.google.com/d/msgid/
bitcoindev/178b550d-841f-43d6-8c4f-67e909cc17bfn%40googlegroups.com?
utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/7eef94c5-1c75-4ad4-8b04-b09a065d3797%40murch.one.
