Lightning Network: asymmetry in the information tracked by each participant?












4














In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.



eltoo: A Simple Layer2 Protocol for Bitcoin




"The central idea of Lightning is to invalidate an old state by
punishing the participant publishing it, and claiming all the funds in
the channel. This however introduces an intrinsic asymmetry in the
information tracked by each participant. The replaced states turn into
toxic information
as soon as they are replaced, and leaking that
information may result in funds being stolen. The asymmetry also
limits Lightning to two participants."




There are following points that are not clear to me:



(1) Does asymmetry mean the information tracked by each participant (payer and recipient) are NOT the same (or are NOT equal)?



(2) What is the reason of this asymmetry?



(3) What does "turn into toxic information" mean?



(4) The last sentence: "asymmetry also limits Lightning to two participants", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.










share|improve this question





























    4














    In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.



    eltoo: A Simple Layer2 Protocol for Bitcoin




    "The central idea of Lightning is to invalidate an old state by
    punishing the participant publishing it, and claiming all the funds in
    the channel. This however introduces an intrinsic asymmetry in the
    information tracked by each participant. The replaced states turn into
    toxic information
    as soon as they are replaced, and leaking that
    information may result in funds being stolen. The asymmetry also
    limits Lightning to two participants."




    There are following points that are not clear to me:



    (1) Does asymmetry mean the information tracked by each participant (payer and recipient) are NOT the same (or are NOT equal)?



    (2) What is the reason of this asymmetry?



    (3) What does "turn into toxic information" mean?



    (4) The last sentence: "asymmetry also limits Lightning to two participants", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.










    share|improve this question



























      4












      4








      4







      In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.



      eltoo: A Simple Layer2 Protocol for Bitcoin




      "The central idea of Lightning is to invalidate an old state by
      punishing the participant publishing it, and claiming all the funds in
      the channel. This however introduces an intrinsic asymmetry in the
      information tracked by each participant. The replaced states turn into
      toxic information
      as soon as they are replaced, and leaking that
      information may result in funds being stolen. The asymmetry also
      limits Lightning to two participants."




      There are following points that are not clear to me:



      (1) Does asymmetry mean the information tracked by each participant (payer and recipient) are NOT the same (or are NOT equal)?



      (2) What is the reason of this asymmetry?



      (3) What does "turn into toxic information" mean?



      (4) The last sentence: "asymmetry also limits Lightning to two participants", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.










      share|improve this question















      In following paper, written by Christian Decker et al., there is a paragraph that is not clear to me.



      eltoo: A Simple Layer2 Protocol for Bitcoin




      "The central idea of Lightning is to invalidate an old state by
      punishing the participant publishing it, and claiming all the funds in
      the channel. This however introduces an intrinsic asymmetry in the
      information tracked by each participant. The replaced states turn into
      toxic information
      as soon as they are replaced, and leaking that
      information may result in funds being stolen. The asymmetry also
      limits Lightning to two participants."




      There are following points that are not clear to me:



      (1) Does asymmetry mean the information tracked by each participant (payer and recipient) are NOT the same (or are NOT equal)?



      (2) What is the reason of this asymmetry?



      (3) What does "turn into toxic information" mean?



      (4) The last sentence: "asymmetry also limits Lightning to two participants", Does it mean that we can expect a payment transaction can have more than two participants? since a payment logically has only two participants: a payer and a recipient.







      security lightning-network terminology ln-commitment-transaction eltoo






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 2 days ago









      Murch

      34.6k27112324




      34.6k27112324










      asked Jan 2 at 13:17









      sas

      338213




      338213






















          1 Answer
          1






          active

          oldest

          votes


















          4














          When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel.



          The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds gives the counterparty time to impound the closing party's funds if an outdated state was broadcast.



          Once a channel is updated, the outdated channel state is "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the user all their funds in the channel.



          Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this on a multiparty setup, it would be extremely complex. In Eltoo broadcasting an outdated state is dealt with by updating to the latest state. Since channel state can thusly be symmetric, it is trivial to have channels with more than two parties. This could take the form of e.g. four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to the other participants, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for channel factories among large players that can guarantee continuous availability.






          share|improve this answer























          • Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
            – sas
            Jan 2 at 16:39






          • 3




            with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
            – Rene Pickhardt
            2 days ago










          • And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
            – sas
            2 days ago






          • 1




            I've amended my answer to give more details on some potential applications for Eltoo.
            – Murch
            2 days ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "308"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83312%2flightning-network-asymmetry-in-the-information-tracked-by-each-participant%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4














          When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel.



          The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds gives the counterparty time to impound the closing party's funds if an outdated state was broadcast.



          Once a channel is updated, the outdated channel state is "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the user all their funds in the channel.



          Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this on a multiparty setup, it would be extremely complex. In Eltoo broadcasting an outdated state is dealt with by updating to the latest state. Since channel state can thusly be symmetric, it is trivial to have channels with more than two parties. This could take the form of e.g. four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to the other participants, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for channel factories among large players that can guarantee continuous availability.






          share|improve this answer























          • Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
            – sas
            Jan 2 at 16:39






          • 3




            with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
            – Rene Pickhardt
            2 days ago










          • And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
            – sas
            2 days ago






          • 1




            I've amended my answer to give more details on some potential applications for Eltoo.
            – Murch
            2 days ago
















          4














          When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel.



          The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds gives the counterparty time to impound the closing party's funds if an outdated state was broadcast.



          Once a channel is updated, the outdated channel state is "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the user all their funds in the channel.



          Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this on a multiparty setup, it would be extremely complex. In Eltoo broadcasting an outdated state is dealt with by updating to the latest state. Since channel state can thusly be symmetric, it is trivial to have channels with more than two parties. This could take the form of e.g. four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to the other participants, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for channel factories among large players that can guarantee continuous availability.






          share|improve this answer























          • Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
            – sas
            Jan 2 at 16:39






          • 3




            with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
            – Rene Pickhardt
            2 days ago










          • And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
            – sas
            2 days ago






          • 1




            I've amended my answer to give more details on some potential applications for Eltoo.
            – Murch
            2 days ago














          4












          4








          4






          When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel.



          The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds gives the counterparty time to impound the closing party's funds if an outdated state was broadcast.



          Once a channel is updated, the outdated channel state is "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the user all their funds in the channel.



          Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this on a multiparty setup, it would be extremely complex. In Eltoo broadcasting an outdated state is dealt with by updating to the latest state. Since channel state can thusly be symmetric, it is trivial to have channels with more than two parties. This could take the form of e.g. four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to the other participants, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for channel factories among large players that can guarantee continuous availability.






          share|improve this answer














          When two channel participants open a channel or update it, they exchange commitment transactions. Each of these commitment transactions allows one party to unilaterally close the channel.



          The commitment transactions are asymmetric in that they lock the closing party's funds when broadcast, i.e. Alice's commitment transaction locks Alice's funds, Bob's commitment transaction locks Bob's funds. The counterparty's funds are immediately available for spending. The lock on the closing party's funds gives the counterparty time to impound the closing party's funds if an outdated state was broadcast.



          Once a channel is updated, the outdated channel state is "toxic" in the sense that (accidentally) using the outdated commitment transaction to close the channel will cost the user all their funds in the channel.



          Updating a channel to make a payment in the punishment-based channel setup requires a procedure with multiple roundtrips in a specific order to ensure that there is no disadvantageous intermittent state for either party. If it were possible to map this on a multiparty setup, it would be extremely complex. In Eltoo broadcasting an outdated state is dealt with by updating to the latest state. Since channel state can thusly be symmetric, it is trivial to have channels with more than two parties. This could take the form of e.g. four parties creating a four-of-four multisig output to anchor a channel. Each party would have a balance in the channel which they could use to send funds to the other participants, or other network participants. With Schnorr signatures and key aggregation, such channels would be extremely efficient as they could still fit in the size of a singlesig output. Practically, the number of participants would still be limited as any channel update would have to be agreed upon by every participant, and any one participant wanting to close the channel would close it for all. Possibly, this could be used as a liquidity pool or for channel factories among large players that can guarantee continuous availability.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 2 days ago

























          answered Jan 2 at 15:51









          Murch

          34.6k27112324




          34.6k27112324












          • Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
            – sas
            Jan 2 at 16:39






          • 3




            with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
            – Rene Pickhardt
            2 days ago










          • And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
            – sas
            2 days ago






          • 1




            I've amended my answer to give more details on some potential applications for Eltoo.
            – Murch
            2 days ago


















          • Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
            – sas
            Jan 2 at 16:39






          • 3




            with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
            – Rene Pickhardt
            2 days ago










          • And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
            – sas
            2 days ago






          • 1




            I've amended my answer to give more details on some potential applications for Eltoo.
            – Murch
            2 days ago
















          Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
          – sas
          Jan 2 at 16:39




          Thank you. Just when you say we can have channels with more than two parties, do you mean that we can have a bidirectional payment channel between e.g. 4 participants (payer/recipient) like this figure? ( imgur.com/5KVLP6G ) Or do you mean something else? And does eltoo such a capability? Thanks
          – sas
          Jan 2 at 16:39




          3




          3




          with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
          – Rene Pickhardt
          2 days ago




          with the current lightning network multiparty channels are theoretically possible but not implemented. in eltoo these channels are much easier to implement because all parties share the same state and update / settlement transactions. Therefor if we switch to eltoo channels one day we will most likely get multiparty channels implemented
          – Rene Pickhardt
          2 days ago












          And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
          – sas
          2 days ago




          And in that case (having multiparty channels), we can establish a large channel between participants, such that they do not need to do multi hop payments since a direct link exists between them and therefore we do not need to do a routing process, isn't it? Do you agree? Thank you.
          – sas
          2 days ago




          1




          1




          I've amended my answer to give more details on some potential applications for Eltoo.
          – Murch
          2 days ago




          I've amended my answer to give more details on some potential applications for Eltoo.
          – Murch
          2 days ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Bitcoin Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f83312%2flightning-network-asymmetry-in-the-information-tracked-by-each-participant%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

          Alcedinidae

          RAC Tourist Trophy