public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@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
Date: Mon, 23 Oct 2023 15:45:44 +0000	[thread overview]
Message-ID: <ZTaVKB1wdsLL7XiK@petertodd.org> (raw)
In-Reply-To: <o2Dp_FkSCCwB6Mo9dePXgvxwQeKcmDwK_fNK6bhHPrsYIC6KaoeTtfHh8kv2NGHqkJhppNmEvRZGTly1Zs3Of1gIfl76iNQgCZaNJ-bJqgE=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-10-23 15:45 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 16:57 [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10   ` Matt Morehouse
2023-10-17  1:11   ` Antoine Riard
2023-10-20 10:47     ` Peter Todd
2023-10-20 11:18       ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17  7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34   ` ZmnSCPxj
2023-10-17 18:34     ` Antoine Riard
2023-10-20 10:31     ` Peter Todd
2023-10-20 11:03       ` Peter Todd
2023-10-20 18:35         ` Matt Morehouse
2023-10-20 21:05           ` Matt Corallo
2023-10-21  0:15             ` Peter Todd
2023-10-21  1:03               ` Matt Corallo
2023-10-21  1:25                 ` Peter Todd
2023-10-21  1:55                   ` Matt Corallo
2023-10-21  2:43                     ` Peter Todd
2023-10-23 16:09                       ` Matt Corallo
2023-10-17 17:47   ` Antoine Riard
2023-10-17 18:47     ` Antoine Riard
2023-10-18  0:17 ` Matt Corallo
2023-10-18  2:57   ` Antoine Riard
2023-10-19  8:12     ` Bastien TEINTURIER
2023-10-19 16:23   ` Matt Morehouse
2023-10-19 17:22     ` Antoine Riard
2023-10-19 17:53       ` Matt Morehouse
2023-10-19 19:33         ` Antoine Riard
2023-10-21  0:18           ` Olaoluwa Osuntokun
2023-11-17 22:36             ` Antoine Riard
2023-10-19 18:02     ` Matt Corallo
2023-10-20  6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05   ` Antoine Riard
2023-10-27  0:43     ` Peter Todd
2023-11-02  4:46     ` Antoine Riard
2023-10-21  0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21  8:58   ` David A. Harding
2023-10-21 10:31     ` Peter Todd
2023-10-22  8:30   ` vjudeu
2023-10-23 11:10   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45     ` Peter Todd [this message]
2023-11-02  5:24   ` [bitcoin-dev] " Antoine Riard
2023-11-02  6:26     ` Peter Todd
2023-11-02 17:07       ` Matt Morehouse
2023-11-03  5:27         ` Antoine Riard
2023-11-03  5:25       ` Antoine Riard
2023-11-04  7:26         ` Peter Todd
2023-11-06 18:45           ` Antoine Riard
2023-11-07 11:11             ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44               ` Antoine Riard
2023-11-08  0:51             ` [bitcoin-dev] " Peter Todd
2023-11-08  2:06               ` Peter Todd
2023-11-13  2:18                 ` Antoine Riard
2023-11-14 19:50                   ` Peter Todd
     [not found]                     ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53                       ` [bitcoin-dev] Fwd: " Antoine Riard
2023-10-22  4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23  8:49   ` David A. Harding

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=ZTaVKB1wdsLL7XiK@petertodd.org \
    --to=pete@petertodd.org \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=security@ariard.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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