Subject: Re: [bitcoindev] Consensus Cleanup BIP draft

From: Anthony Towns <[email-masked]>
Date: Mon, 31 Mar 2025 21:00:09 +1000

On Sat, Mar 29, 2025 at 12:02:32PM +0100, Sjors Provoost wrote:
> On Fri, Mar 28, 2025, at 20:53, [email-masked] wrote:
> > But more to the point, it does not solve any of the problems that were
> > originally provided as justification, apart from making it slightly
> > simpler to implement an SPV wallet (no need to get the coinbase tx).
> It's important to keep in mind that "SPV wallet" also includes any kind of automated bridge that requires knowledge of Bitcoin transaction inclusion. What's simple to implement in a rust-bitcoin wallet may be extremely hard in a smart contract. Or maybe it's indeed trivial.
>
> It could be a useful illustration if someone implements such a bridge using any of the proposed covenant op codes, and shows the difference in complexity between having the 64 byte limit and not having it.

I think it's almost certainly easy to just avoid being concerned with 64
byte transactions for a bridge:

 * for txs moving value off of bitcoin, the bridge will certainly want
   the funds secured in some output, so that will naturally be more than
   4 bytes;

 * for txs moving value back to bitcoin, there'll usually be two outputs
   (one for amount being moved, one for change), and almost always, the
   recipient of the funds will want them secured; either of which gives
   a more than 64 byte tx.  it's only if the bridge explicitly supports
   burning funds (entirely, or to fees) and is precisely burning a full
   utxo with no change; but in that case the bridge can just require
   the output be an op_return that pushes three or more bytes of data.

 * additionally, if the bridge doesn't manage fees in-band (with bridged
   funds), but does it out of band via a p2a output, that also ensures
   that none of its txs will be 64 bytes.

Similar consideraions mostly apply to SPV wallets as well -- if you're
trying to trick someone into believing they've received some funds, you'll
need to supply a tx that includes an output that matches their wallet,
which will be more than 4 bytes, so won't match a 64-byte tx; and if
you're trying to trick them into thinking they've burnt some of their
funds, you'll need to get a "64-bit tx" that includes a txid/vout pair
that matches one of their utxos, which is roughly a 256-bit collision,
so should be cryptographically hard...

Cheers,
aj

-- 
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-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z-p1uWpMV4cZul36%40erisian.com.au.