From: Antoine Riard <antoine.riard@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, 2 Jun 2026 18:05:30 -0700 (PDT) [thread overview]
Message-ID: <8c49d0d1-7f87-4e4c-9636-1e631562bc8dn@googlegroups.com> (raw)
In-Reply-To: <e0fa7417-ffef-492f-93d6-6c7ae6dbad6en@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 3573 bytes --]
Hi Jeremy,
If I'm getting correctly your idea, this is not a removal of the "seam" in
the
validity space of transaction, more a reduction of the "seam" to a specific
structure. That means a second-layer client would still have to implement
this
check to rule out tx input that might infringe it. Not sure, if it's a real
design win compared to the current proposal...
By the way, as a side note if we can be spared with chat-gpt generate bips,
thanks
you. I did (naively) believe bitcoin development philosophy was about on
delivering
on a trust-minmized security model. Not in fact some novel trust-sama
philosopy.
Best,
Antoine
OTS hash: e0faa568d4eef3b250b193f01c7134129abe225f7b10f345825610738c5ea1a2
Le Tuesday, June 2, 2026 à 7:20:05 PM UTC+1, jeremy a écrit :
>
> They aren't really doing "additional checks" in the way you're framing it.
> There's just a new rule applied to existing proofs, no additional data
> compared to before. That new rule is *something* like given proof :
> ([(Hash, LEFT | RIGHT) | ODDNODE ], Transaction)
>
> then as you hash you just forbid that any LEFT | RIGHT or LEFT | LEFT is
> allowed to be parseable as a transaction.
>
> This forces that if a 64-byte transaction is present, it must be a leaf.
>
> This prevents the other 64 byte transaction issue because you can't embed
> a txid sub-tree inside the 64-byte transaction to lie to an SPV user.
>
> My estimate is that this case happens naturally like 1 in 2 million
> blocks.
> On Tuesday, June 2, 2026 at 8:40:05 AM UTC-4 Greg Sanders wrote:
>
>> Hi Jeremy,
>>
>> Why does the SPV verifier need to do additional checks? SPV implies it's
>> simply trusting the heaviest chain. Clearly they could validate it, but I'm
>> not seeing necessity in the security model.
>>
>> Greg
>>
>> On Monday, June 1, 2026 at 4:22:28 PM UTC-4 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
>>>
>>
--
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/8c49d0d1-7f87-4e4c-9636-1e631562bc8dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4698 bytes --]
next prev parent reply other threads:[~2026-06-03 1:16 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 [this message]
2026-06-03 15:07 ` jeremy
2026-06-05 21:34 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-09 16:28 ` jeremy
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=8c49d0d1-7f87-4e4c-9636-1e631562bc8dn@googlegroups.com \
--to=antoine.riard@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