Delivery-date: Mon, 31 Mar 2025 13:41:27 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Date: Mon, 31 Mar 2025 21:00:09 +1000
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
Message-ID: <Z-p1uWpMV4cZul36@erisian.com.au>
References: <uDAujRxk4oWnEGYX9lBD3e0V7a4V4Pd-c4-2QVybSZNcfJj5a6IbO6fCM_xEQEpBvQeOT8eIi1r91iKFIveeLIxfNMzDys77HUcbl7Zne4g=@protonmail.com>
 <CAGL6+mFQqTS21cQZ_aU=hXtMaKkw5ygAk2PT9hQpdB4THz9X_A@mail.gmail.com>
 <TD8gP8PKw3th-0DrZznBXrXFILRkwr66wVRoiPC2di_e-NivCRKVjooVZIh7JJSV_C9rJEkKTvudWSG8CJsq16jPhQBjM0eVmPe8rir50Y4=@protonmail.com>
 <afedbc69-8042-4fe8-99c2-279173a440f3n@googlegroups.com>
 <065901dba01b$2164fff0$642effd0$@voskuil.org>
 <19f6a854-674a-4e4d-9497-363af306e3a0@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <19f6a854-674a-4e4d-9497-363af306e3a0@app.fastmail.com>
X-Spam_score: -0.0
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
 permitted sender) smtp.mailfrom=aj@erisian.com.au
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)

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 o=
f 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 usi=
ng any of the proposed covenant op codes, and shows the difference in compl=
exity 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

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
Z-p1uWpMV4cZul36%40erisian.com.au.