[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Lettin
From:       Peter Todd via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date:       2023-10-23 15:45:44
Message-ID: ZTaVKB1wdsLL7XiK () petertodd ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

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

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

> * This indicates that the transaction MUST NOT exist in a block at or above the \
>                 height specified.
> * Mempool should put txes buckets based on `nExpiryTime`, and if the block is \
>                 reached, drop all the buckets with `nExpiryTime` less than that \
>                 block 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_Expire
or OP_CheckExpiryTime better names for the opcode.

> * Check if `nExpiryTime` exists and has value equal or less than the stack top.
> 
> The primary difference is simply that while Peter proposes an implicit field 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 and
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 will be \
> better implemented as well by non-Bitcoin-core implementations, as the use of tx \
> buckets is now explicit in treating the `nExpiryTime` field.

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

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


["signature.asc" (application/pgp-signature)]

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[prev in list] [next in list] [prev in thread] [next in thread]