Feedback-ID: i525146e8:Fastmail
Date: Mon, 23 Oct 2023 15:45:44 +0000
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ZTaVKB1wdsLL7XiK@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <o2Dp_FkSCCwB6Mo9dePXgvxwQeKcmDwK_fNK6bhHPrsYIC6KaoeTtfHh8kv2NGHqkJhppNmEvRZGTly1Zs3Of1gIfl76iNQgCZaNJ-bJqgE=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="J6SITKTbT5gUF8FZ"
Content-Disposition: inline
In-Reply-To: <o2Dp_FkSCCwB6Mo9dePXgvxwQeKcmDwK_fNK6bhHPrsYIC6KaoeTtfHh8kv2NGHqkJhppNmEvRZGTly1Zs3Of1gIfl76iNQgCZaNJ-bJqgE=@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me, "lightning-dev\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like
 Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Precedence: list


--J6SITKTbT5gUF8FZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 23, 2023 at 11:10:56AM +0000, ZmnSCPxj wrote:
> Hi all,
>=20
> This was discussed partially on the platform formerly known as twitter, b=
ut an alternate design goes like this:
>=20
> * Add an `nExpiryTime` field in taproot annex.

I would strongly suggest making it nExpiryHeight, and only offering the opt=
ion
of expiration at a given height.

Time-based anything is sketchy, as it could give miners incentives to lie a=
bout
the current time in the nTime field. If anything, the fact that nLockTime c=
an
in fact be time-based was a design mistake.

>   * This indicates that the transaction MUST NOT exist in a block at or a=
bove the height specified.
>   * Mempool should put txes buckets based on `nExpiryTime`, and if the bl=
ock is reached, drop all the buckets with `nExpiryTime` less than that bloc=
k height.
> * Add an `OP_CHECKEXPIRYTIMEVERIFY` opcode, mostly similar in behavior to=
 `OP_EXPIRE` proposed by Peter Todd:

Note that if we redefine an OP_SuccessX opcode, we do not need _Verify
behavior.  We can produce a true/false stack element, making either OP_Expi=
re
or OP_CheckExpiryTime better names for the opcode.

>   * Check if `nExpiryTime` exists and has value equal or less than the st=
ack top.
>=20
> The primary difference is simply that while Peter proposes an implicit fi=
eld for the value that `OP_EXPIRE` will put in `CTransaction`, I propose an=
 explicit field for it in the taproot annex.

To be clear, I also proposed an explicit field too. But I had a brainfart a=
nd
forgot that we'd added the taproot annex. So I proposed re-using part of
nVersion.

> The hope is that "explicit is better than implicit" and that the design w=
ill be better implemented as well by non-Bitcoin-core implementations, as t=
he use of tx buckets is now explicit in treating the `nExpiryTime` field.

Also, having a nExpiryHeight may be useful in cases where a signature cover=
ing
the field is sufficient.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--J6SITKTbT5gUF8FZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmU2lSUACgkQLly11TVR
LzeuYA//VXMPcCNN835JobBNhk0hbufUVxRlrNQrXqdgQzXPzbVjkiLd6AdaODps
WBN7GXFBGpVn9o5N4FEODDOgdp5p5D6UZd+dz1245D14DifH4SyQVw3+qzj09wiZ
FqMOKR0DoQXL9gzRGC9dHJZhRuINsJq6EMWawaLnY+g42XIUjKtgdKZ+2aRtiRhT
6f6WdAmn4m3eEKaAIrT2lSZ4IJupSDv4VzIkeNpNYEX6Fwo6VGEangyg/SiwcDG0
HAeLhVwVeaS0a5Q+gjzSXPPHeBKyxl6MU5PlWqqi2ryralxyGmrIyBlGfB7U52Xi
OohxIexV9NhKNuVmEYnPNL+0rnKrZ9SSrPDaa+1z+jfJkFlBh23WMoPmupunUC2H
4n1jUrwV9bxcbk4zjO/lUFPlbKgDToHf8mzp9a4qZFvqNsCElcT+q8srhCZWBsIb
YoyVs4J1RMHCADchc5JqPN0HDnMAhRG7tpf6EzdMVIPX1uUOnjKSBrfziwLSqeJ6
UyQ5MEiMCCJuRRdC6MlrNuGWhUeppECtoN5uG4e/lWGHMgf/YJ9yofNprZJgBf5U
50yH/Zmt6Mlv2NYrfs9JnslgZoPYXsV57Z4Ut1H4PFeX+feKVvZfAOZQA0NsDO83
aPkOjXykauPX5HVXOSMJmbdQekm0P5bjdnzD7Vgx3EUmqgjHvos=
=7Oab
-----END PGP SIGNATURE-----

--J6SITKTbT5gUF8FZ--