Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-12 📝 Original message: On Sun, Jul 11, 2021 at ...
📅 Original date posted:2021-07-12
📝 Original message:
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns <aj at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/d6b5a929/attachment.html>;
📝 Original message:
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns <aj at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/d6b5a929/attachment.html>;