Mark Friedenbach [ARCHIVE] on Nostr: š Original date posted:2015-08-10 š Original message: I believe there may be a ...
š
Original date posted:2015-08-10
š Original message:
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 <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
> _______________________________________________
> 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/6e33ee28/attachment.html>;
š Original message:
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 <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
> _______________________________________________
> 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/6e33ee28/attachment.html>;