From jr at mit.edu Mon Aug 10 18:09:33 2015 From: jr at mit.edu (Jeremy Rubin) Date: Mon, 10 Aug 2015 14:09:33 -0400 Subject: [Lightning-dev] A couple questions about sequence number: In-Reply-To: References: Message-ID: 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: