Jeremy Rubin [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-10 📝 Original message: No I think it's a valid ...
📅 Original date posted:2015-08-10
📝 Original message:
No I think it's a valid place to talk about it, and it helps clarify the
functional goals.
I need to dive in a little bit deeper into the implementation to really see
what is going on, I didn't pick up on the sequence being only for direction
flipping. Where should I look to observe this?
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Mon, Aug 10, 2015 at 2:04 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I really think the number inversion to "preserve the old nSequence
> semantics" is not worth it. It's less usable and harder to understand.
> Renaming nSequence to nMaturity and "check sequence verify" to "verify
> input maturity" (or something of the sort) may seem just
> bike-shedding, but I believe could greatly simplify the documentation.
> Maybe not the right thread to repeat this...
>
> On Mon, Aug 10, 2015 at 5:58 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
> > I believe there may be a misconception in your understanding. Lightning
> as
> > implemented by Rusty uses the sequence number field of the transaction
> > format, but not as an increment-on-each-transaction sequence number in
> the
> > traditional sense. Rather, BIP 68
> > (https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)
> specifies a
> > new consensus rule by which the sequence number field can mandate a
> required
> > minimum age for each input, thereby achieving a relative lock-time.
> > Lightning uses these relative lock-times.
> >
> > A sequence number of MAX_INT is allowed to confirm on the block chain in
> the
> > same block or later as its parent. A sequence number one less than that
> > cannot confirm any earlier than one block AFTER its parent. A sequence
> > number two less than MAX_INT requires two blocks to elapse, etc.
> >
> > So let's say that you want a certain script pathway to only take effect
> 30
> > days after confirmation of the parent. You achieve this by checking in
> the
> > script that the sequence number of the spending transaction (the child)
> is
> > equal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional
> payment
> > channel, this is a value that is ratcheted up (bringing the confirmation
> > delay down) each time the payment channel switches direction. So for
> > example, you might increment sequence number / decrement the time to
> > confirmation by 144 blocks (1 day) each time the payment channel switches
> > direction, regardless of the number of off-chain transactions that have
> > elapsed in-between.
> >
> > On Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin <jr at mit.edu> wrote:
> >>
> >> Hi! A couple questions about the use of sequence numbers in lightning.
> >> Please forgive me if these are somewhat rudimentary.
> >>
> >> 1) Can someone better outline what the race conditions are? It seems
> >> certain things time out w.r.t. the bitcoin blockchain height, which
> seems
> >> negative with respect to censorship vulnerability. How is this
> addressed?
> >> Section 9.5 of the paper seems unsatisfactory.
> >>
> >> 2) Using sequence numbers to select the right transaction to include is
> >> good, but it would seem to leak information about how many LN
> transactions
> >> took place, which could then make it meterable by external parties.
> (eg, a
> >> miner could make the fee for settling proportional to it). Perhaps
> >> incrementing by a random amount would alleviate the ability to reliably
> >> meter. Maybe it is good that this can be metered?
> >>
> >> Cheers,
> >>
> >> Jeremy
> >> --
> >> @JeremyRubin
> >>
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/09f4bb9d/attachment-0001.html>;
📝 Original message:
No I think it's a valid place to talk about it, and it helps clarify the
functional goals.
I need to dive in a little bit deeper into the implementation to really see
what is going on, I didn't pick up on the sequence being only for direction
flipping. Where should I look to observe this?
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Mon, Aug 10, 2015 at 2:04 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I really think the number inversion to "preserve the old nSequence
> semantics" is not worth it. It's less usable and harder to understand.
> Renaming nSequence to nMaturity and "check sequence verify" to "verify
> input maturity" (or something of the sort) may seem just
> bike-shedding, but I believe could greatly simplify the documentation.
> Maybe not the right thread to repeat this...
>
> On Mon, Aug 10, 2015 at 5:58 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
> > I believe there may be a misconception in your understanding. Lightning
> as
> > implemented by Rusty uses the sequence number field of the transaction
> > format, but not as an increment-on-each-transaction sequence number in
> the
> > traditional sense. Rather, BIP 68
> > (https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)
> specifies a
> > new consensus rule by which the sequence number field can mandate a
> required
> > minimum age for each input, thereby achieving a relative lock-time.
> > Lightning uses these relative lock-times.
> >
> > A sequence number of MAX_INT is allowed to confirm on the block chain in
> the
> > same block or later as its parent. A sequence number one less than that
> > cannot confirm any earlier than one block AFTER its parent. A sequence
> > number two less than MAX_INT requires two blocks to elapse, etc.
> >
> > So let's say that you want a certain script pathway to only take effect
> 30
> > days after confirmation of the parent. You achieve this by checking in
> the
> > script that the sequence number of the spending transaction (the child)
> is
> > equal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional
> payment
> > channel, this is a value that is ratcheted up (bringing the confirmation
> > delay down) each time the payment channel switches direction. So for
> > example, you might increment sequence number / decrement the time to
> > confirmation by 144 blocks (1 day) each time the payment channel switches
> > direction, regardless of the number of off-chain transactions that have
> > elapsed in-between.
> >
> > On Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin <jr at mit.edu> wrote:
> >>
> >> Hi! A couple questions about the use of sequence numbers in lightning.
> >> Please forgive me if these are somewhat rudimentary.
> >>
> >> 1) Can someone better outline what the race conditions are? It seems
> >> certain things time out w.r.t. the bitcoin blockchain height, which
> seems
> >> negative with respect to censorship vulnerability. How is this
> addressed?
> >> Section 9.5 of the paper seems unsatisfactory.
> >>
> >> 2) Using sequence numbers to select the right transaction to include is
> >> good, but it would seem to leak information about how many LN
> transactions
> >> took place, which could then make it meterable by external parties.
> (eg, a
> >> miner could make the fee for settling proportional to it). Perhaps
> >> incrementing by a random amount would alleviate the ability to reliably
> >> meter. Maybe it is good that this can be metered?
> >>
> >> Cheers,
> >>
> >> Jeremy
> >> --
> >> @JeremyRubin
> >>
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/09f4bb9d/attachment-0001.html>;