public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Mon, 1 Jun 2026 13:17:45 -0700 (PDT)	[thread overview]
Message-ID: <45558bbd-762c-45a4-a4a1-6105d7462a8en@googlegroups.com> (raw)
In-Reply-To: <MuaBBWyHNVBd2i0ppWeXGlhAx8C_UqdUZctkuQ7stQeo8CudqJSWfeJHsmJLYLgXz_XZgRw5i1nTJ4wAZCsdCyQccR1Xh4IzA4QjBMVUJpU=@protonmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1515 bytes --]

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/45558bbd-762c-45a4-a4a1-6105d7462a8en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2019 bytes --]

  reply	other threads:[~2026-06-01 20:22 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 [this message]
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
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=45558bbd-762c-45a4-a4a1-6105d7462a8en@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