From: Anthony Towns <aj@erisian•com.au>
To: Sjors Provoost <sjors@sprovoost•nl>
Cc: eric@voskuil•org, 'jeremy' <jeremy.l.rubin@gmail•com>,
'Bitcoin Development Mailing List' <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Consensus Cleanup BIP draft
Date: Mon, 31 Mar 2025 21:00:09 +1000 [thread overview]
Message-ID: <Z-p1uWpMV4cZul36@erisian.com.au> (raw)
In-Reply-To: <19f6a854-674a-4e4d-9497-363af306e3a0@app.fastmail.com>
On Sat, Mar 29, 2025 at 12:02:32PM +0100, Sjors Provoost wrote:
> On Fri, Mar 28, 2025, at 20:53, eric@voskuil•org 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z-p1uWpMV4cZul36%40erisian.com.au.
next prev parent reply other threads:[~2025-03-31 20:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 17:14 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 10:46 ` Chris Stewart
2025-03-27 17:54 ` /dev /fd0
2025-03-27 19:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-27 20:45 ` jeremy
2025-03-27 21:38 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-28 9:23 ` Sjors Provoost
2025-03-28 11:02 ` Chris Stewart
2025-03-28 12:48 ` Sjors Provoost
2025-03-28 13:54 ` Chris Stewart
2025-03-28 14:07 ` Sjors Provoost
2025-03-28 19:53 ` eric
2025-03-29 11:02 ` Sjors Provoost
2025-03-31 11:00 ` Anthony Towns [this message]
2025-03-31 15:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-31 20:09 ` eric
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=Z-p1uWpMV4cZul36@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil$(echo .)org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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