[Lightning-dev] A couple questions about sequence number:

[Adam Back]

The relative lock time is used so that channels do not automatically
expire.  With out RCLTV then new channels need to be established
periodically as they expire because expiry is a specific point in
time.

With RCLTV then the channel can stay running until a need arises to
reclaim funds due from a hub that goes permanently offline.  Subject
to rebalancing of funds that is achievable via users having mulitple
channels and being paid negative fees to move funds back to a channel
that is running low on liquidity then channels could potentially stay
up indefinitely.

Adam


On 10 August 2015 at 19:09, Jeremy Rubin <jr at mit.edu> wrote:
> 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
>
> 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
>> >
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>