📅 Original date posted:2015-08-10
📝 Original message:
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 <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Mon, Aug 10, 2015 at 2:04 PM, Jorge Timón <jtimon at jtimon.cc> 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 <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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/09f4bb9d/attachment-0001.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-09 14:43:55
in reply to nevent1q…ea6d
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-09 14:43:55Event JSON
{
"id": "34b2e72e43c6ad5e4bec1e6726ceb762a28fda577ff1e533bd33af51c30139fe",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686314635,
"kind": 1,
"tags": [
[
"e",
"7fe67d93c8686c117176f80a59242c29b7ae6ec1e731a1135168e324fa2a1a57",
"",
"root"
],
[
"e",
"7788d2746001baab152ee13c7932d21ab1f6a20cba8f8340db2725b240fcfc06",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-10\n📝 Original message:\nNo I think it's a valid place to talk about it, and it helps clarify the\nfunctional goals.\n\nI need to dive in a little bit deeper into the implementation to really see\nwhat is going on, I didn't pick up on the sequence being only for direction\nflipping. Where should I look to observe this?\n\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Mon, Aug 10, 2015 at 2:04 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\n\u003e I really think the number inversion to \"preserve the old nSequence\n\u003e semantics\" is not worth it. It's less usable and harder to understand.\n\u003e Renaming nSequence to nMaturity and \"check sequence verify\" to \"verify\n\u003e input maturity\" (or something of the sort) may seem just\n\u003e bike-shedding, but I believe could greatly simplify the documentation.\n\u003e Maybe not the right thread to repeat this...\n\u003e\n\u003e On Mon, Aug 10, 2015 at 5:58 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e wrote:\n\u003e \u003e I believe there may be a misconception in your understanding. Lightning\n\u003e as\n\u003e \u003e implemented by Rusty uses the sequence number field of the transaction\n\u003e \u003e format, but not as an increment-on-each-transaction sequence number in\n\u003e the\n\u003e \u003e traditional sense. Rather, BIP 68\n\u003e \u003e (https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)\n\u003e specifies a\n\u003e \u003e new consensus rule by which the sequence number field can mandate a\n\u003e required\n\u003e \u003e minimum age for each input, thereby achieving a relative lock-time.\n\u003e \u003e Lightning uses these relative lock-times.\n\u003e \u003e\n\u003e \u003e A sequence number of MAX_INT is allowed to confirm on the block chain in\n\u003e the\n\u003e \u003e same block or later as its parent. A sequence number one less than that\n\u003e \u003e cannot confirm any earlier than one block AFTER its parent. A sequence\n\u003e \u003e number two less than MAX_INT requires two blocks to elapse, etc.\n\u003e \u003e\n\u003e \u003e So let's say that you want a certain script pathway to only take effect\n\u003e 30\n\u003e \u003e days after confirmation of the parent. You achieve this by checking in\n\u003e the\n\u003e \u003e script that the sequence number of the spending transaction (the child)\n\u003e is\n\u003e \u003e equal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional\n\u003e payment\n\u003e \u003e channel, this is a value that is ratcheted up (bringing the confirmation\n\u003e \u003e delay down) each time the payment channel switches direction. So for\n\u003e \u003e example, you might increment sequence number / decrement the time to\n\u003e \u003e confirmation by 144 blocks (1 day) each time the payment channel switches\n\u003e \u003e direction, regardless of the number of off-chain transactions that have\n\u003e \u003e elapsed in-between.\n\u003e \u003e\n\u003e \u003e On Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin \u003cjr at mit.edu\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Hi! A couple questions about the use of sequence numbers in lightning.\n\u003e \u003e\u003e Please forgive me if these are somewhat rudimentary.\n\u003e \u003e\u003e\n\u003e \u003e\u003e 1) Can someone better outline what the race conditions are? It seems\n\u003e \u003e\u003e certain things time out w.r.t. the bitcoin blockchain height, which\n\u003e seems\n\u003e \u003e\u003e negative with respect to censorship vulnerability. How is this\n\u003e addressed?\n\u003e \u003e\u003e Section 9.5 of the paper seems unsatisfactory.\n\u003e \u003e\u003e\n\u003e \u003e\u003e 2) Using sequence numbers to select the right transaction to include is\n\u003e \u003e\u003e good, but it would seem to leak information about how many LN\n\u003e transactions\n\u003e \u003e\u003e took place, which could then make it meterable by external parties.\n\u003e (eg, a\n\u003e \u003e\u003e miner could make the fee for settling proportional to it). Perhaps\n\u003e \u003e\u003e incrementing by a random amount would alleviate the ability to reliably\n\u003e \u003e\u003e meter. Maybe it is good that this can be metered?\n\u003e \u003e\u003e\n\u003e \u003e\u003e Cheers,\n\u003e \u003e\u003e\n\u003e \u003e\u003e Jeremy\n\u003e \u003e\u003e --\n\u003e \u003e\u003e @JeremyRubin\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Lightning-dev mailing list\n\u003e \u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150810/09f4bb9d/attachment-0001.html\u003e",
"sig": "34241e86e1b081d35bf772174e68c13231e1b4e4a47327a49fd9646b9d5fc17060663447e465d47600e121392ffec77ad05d52207aad4cac9bed4fc03d1a3dd0"
}