From: Jeremy <jlrubin@mit•edu>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences
Date: Mon, 12 Jul 2021 15:07:29 -0700 [thread overview]
Message-ID: <CAD5xwhitb0g3-JPsn2tQF-KqgSp+goLnVbSmRX0LUh-818tSVw@mail.gmail.com> (raw)
In-Reply-To: <20210712050115.GA6250@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns <aj@erisian•com.au> wrote:
> On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote:
> > This would disallow using a relative locktime and an absolute
> locktime
> > for the same input. I don't think I've seen a use case for that so
> far,
> > but ruling it out seems suboptimal.
> > I think you meant disallowing a relative locktime and a sequence
> locktime? I
> > agree it is suboptimal.
>
> No? If you overload the nSequence for a per-input absolute locktime
> (well in the past for eltoo), then you can't reuse the same input's
> nSequence for a per-input relative locktime (ie CSV).
>
> Apparently I have thought of a use for it now -- cut-through of PTLC
> refunds when the timeout expires well after the channel settlement delay
> has passed. (You want a signature that's valid after a relative locktime
> of the delay and after the absolute timeout)
>
Ah -- I didn't mean a per input abs locktime, I mean the tx global
locktime.
I agree that at some point we should just separate all locktime types per
input so we get rid of all weirdness/overlap.
>
> > What do you make of sequence tagged keys?
>
> I think we want sequencing restrictions to be obvious from some (simple)
> combination of nlocktime/nsequence/annex so that you don't have to
> evaluate scripts/signatures in order to determine if a transaction
> is final.
>
> Perhaps there's a more general principle -- evaluating a script should
> only return one bit of info: "bool tx_is_invalid_script_failed"; every
> other bit of information -- how much is paid in fees (cf ethereum gas
> calculations), when the tx is final, if the tx is only valid in some
> chain fork, if other txs have to have already been mined / can't have
> been mined, who loses funds and who gets funds, etc... -- should already
> be obvious from a "simple" parsing of the tx.
>
> Cheers,
> aj
>
>
I don't think we have this property as is.
E.g. consider the transaction:
TX:
locktime: None
sequence: 100
scriptpubkey: 101 CSV
How will you tell it is able to be included without running the script?
I agree this is a useful property, but I don't think we can do it
practically.
What's nice is the transaction in this form cannot go from invalid to valid
-- once invalid it is always invalid for a given UTXO.
sequence tagged keys have this property -- a txn is either valid or invalid
and that never changes w/o any external information needing to be passed up.
[-- Attachment #2: Type: text/html, Size: 5556 bytes --]
next prev parent reply other threads:[~2021-07-12 22:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 1:00 [bitcoin-dev] " Jeremy
2021-07-08 8:44 ` Anthony Towns
2021-07-08 15:48 ` Jeremy
2021-07-12 5:01 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2021-07-12 22:07 ` Jeremy [this message]
2021-07-14 3:32 ` Anthony Towns
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=CAD5xwhitb0g3-JPsn2tQF-KqgSp+goLnVbSmRX0LUh-818tSVw@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/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