Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-10 📝 Original message: I really think the number ...
📅 Original date posted:2015-08-10
📝 Original message:
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
>
📝 Original message:
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
>