On Sat, Mar 29, 2025 at 12:02:32PM +0100, Sjors Provoost wrote: > On Fri, Mar 28, 2025, at 20:53, [email protected] 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 protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z-p1uWpMV4cZul36%40erisian.com.au.
