š
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>;
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-09 12:43:55
in reply to nevent1qā¦0v3e
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-09 12:43:55Event JSON
{
"id": "408d032874af92b86d6e318f2e81a471f0125f0133a9d2673063384bfdfc5618",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686314635,
"kind": 1,
"tags": [
[
"e",
"7fe67d93c8686c117176f80a59242c29b7ae6ec1e731a1135168e324fa2a1a57",
"",
"root"
],
[
"e",
"49fff195694bb47a22f157813f4c91e72f57aa70ade946959e9aad88ef30fe86",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "š
Original date posted:2015-08-10\nš Original message:\nI believe there may be a misconception in your understanding. Lightning as\nimplemented by Rusty uses the sequence number field of the transaction\nformat, but not as an increment-on-each-transaction sequence number in the\ntraditional sense. Rather, BIP 68 (\nhttps://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) specifies a\nnew consensus rule by which the sequence number field can mandate a\nrequired minimum age for each input, thereby achieving a relative\nlock-time. Lightning uses these relative lock-times.\n\nA sequence number of MAX_INT is allowed to confirm on the block chain in\nthe same block or later as its parent. A sequence number one less than that\ncannot confirm any earlier than one block AFTER its parent. A sequence\nnumber two less than MAX_INT requires two blocks to elapse, etc.\n\nSo let's say that you want a certain script pathway to only take effect 30\ndays after confirmation of the parent. You achieve this by checking in the\nscript that the sequence number of the spending transaction (the child) is\nequal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional\npayment channel, this is a value that is ratcheted up (bringing the\nconfirmation delay down) each time the payment channel switches direction.\nSo for example, you might increment sequence number / decrement the time to\nconfirmation by 144 blocks (1 day) each time the payment channel switches\ndirection, regardless of the number of off-chain transactions that have\nelapsed in-between.\n\nOn Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin \u003cjr at mit.edu\u003e wrote:\n\n\u003e Hi! A couple questions about the use of sequence numbers in lightning.\n\u003e Please forgive me if these are somewhat rudimentary.\n\u003e\n\u003e 1) Can someone better outline what the race conditions are? It seems\n\u003e certain things time out w.r.t. the bitcoin blockchain height, which seems\n\u003e negative with respect to censorship vulnerability. How is this addressed?\n\u003e Section 9.5 of the paper seems unsatisfactory.\n\u003e\n\u003e 2) Using sequence numbers to select the right transaction to include is\n\u003e good, but it would seem to leak information about how many LN transactions\n\u003e took place, which could then make it meterable by external parties. (eg, a\n\u003e miner could make the fee for settling proportional to it). Perhaps\n\u003e incrementing by a random amount would alleviate the ability to reliably\n\u003e meter. Maybe it is good that this can be metered?\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Jeremy\n\u003e --\n\u003e @JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e \u003chttps://twitter.com/JeremyRubin\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/6e33ee28/attachment.html\u003e",
"sig": "162c9f49924d32d4c2432d3827a4a04de5b9f97c8f684f087c230a69ba8e59605ea2ee2f9ba1cae18635b560e28df0c01ce59cf46d7e842104c2d63c4975e497"
}