From adam at cypherspace.org Mon Aug 10 19:08:38 2015 From: adam at cypherspace.org (Adam Back) Date: Mon, 10 Aug 2015 20:08:38 +0100 Subject: [Lightning-dev] A couple questions about sequence number: In-Reply-To: References: Message-ID: 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 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 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 >> 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 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 >