Re: [Lightning-dev] Escrow Over Lightning?
> On Feb 11, 2021, at 6:31 AM, ZmnSCPxj wrote: > > Good morning Pedro, > >> Hi Nadav, >> >> You are right that the intermediary (i.e., Ingrid) needs to hold a certain >> amount of coins to allow the virtual channel between Alice and Bob. Some >> comments here: >> - The protocol makes sure that Ingrid will get paid whatever fee she >> decides to charge for the service of creating a virtual channel. Note that >> Ingrid does not have the guarantee that enough payments would be routed >> through her node to gain the same fee in the same amount of time. > > Have not examined this deeply, but what happens if any of the *actual* > Alice-Ingrid or Ingrid-Bob channels are forced unilaterally onchain before > the purported lifetime of the virtual channel? As a safe fallback, the protocol gives time to Ingrid (or Bob depending on the case) to put the other channel onchain before the punishment can be triggered. > > Regards, > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Hi Nadav, You are right that the intermediary (i.e., Ingrid) needs to hold a certain amount of coins to allow the virtual channel between Alice and Bob. Some comments here: - The protocol makes sure that Ingrid will get paid whatever fee she decides to charge for the service of creating a virtual channel. Note that Ingrid does not have the guarantee that enough payments would be routed through her node to gain the same fee in the same amount of time. - If Ingrid is afraid that her coins will hold too long, one of the two modes in our construction for virtual channels offers the possibility for Ingrid to close the virtual channel at any time and get the locked coins back (plus the fee). - On the other hand, imagine that Ingrid charges “x” as fee. Alice and Bob would be interested in opening a virtual channel if they plan to do a number of payments between them such that the total fee they would pay would be higher than “x”. (We have a more elaborated fee analysis at the end of the performance evaluation section in the paper). We envision some use cases where virtual channels would be beneficial: - Imagine Bob is a new provider of a web service (e.g., premium news or a premium music player) that charges for each new/song that is downloaded. Alice, who has previously created all the channels that she is willing/able to manage, still wants to try this new service. Alice could open a virtual channel with Bob to try out this service. - Same situation as before, but Bob (a router) now offers wifi connection in exchange for micropayments. - In general, any two-party computation between Alice and Bob that can be expressed in Bitcoin scripting language in a scenario where Alice and Bob do not share a payment channel yet. And of course could be other use cases that we have not thought about yet. I am looking forward to hearing any proposal that people in this list might have. Cheers, Pedro. > On 8 Feb 2021, at 20:49, Nadav Kohen wrote: > > Hi Pedro, > > I actually did have a question for you about Virtual Channels: The first time > I read the paper it struck me that while on the surface things look pretty > nice for the virtual channel participants, the intermediary has to lock up a > lot of collateral (in total, the size of the channel) in order to enable this > and subsequently this channel could stay open for a very long time. As such, > to the intermediary this seems very similar to having to route a (potentially > very large) hodl HTLC which means they will be charging a very large fee for > both the setup and the duration of the channel. Because of this, I'm having > trouble thinking of almost any use cases where this is preferable to just > routing payments the normal way other than if the in-between node is not > reliable and there are no other cheap routes (in which case it might be worth > it to pay a premium). Did you or your colleagues have other use cases in > mind? And have you done any fee analysis for this scheme? > > Best, > Nadav ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Hello, While reading this thread I realized that my colleagues and I have been working on a construction called “Bitcoin-compatible Virtual Channels” [1] that, at a first glance, highly resembles the use case and requirements that you put forward in this thread. In a nutshell, a Virtual Channel is built on top of two payment channels and use them to construct its own “funding transaction”. Imagine that Buyer and Seller do not have a payment channel between them, but they both have a payment channel with a common node (e.g., Escrow in your example). Alice and Bob can create a Virtual Channel between them using fundings from both: channel Alice-Escrow and channel Escrow-Bob. After created, the Virtual Channel offers the same functionality as a direct payment channel between Alice and Bob (i.e., Escrow is no longer involved for payments). Our construction makes sure that no party losses funds when the Virtual Channel needs to be closed (either when Alice and Bob collaborate or any of the 3 parties cheat). This construction is compatible with the current Bitcoin script (e.g., taproot is not required although perhaps useful when available) and with the Lightning Network. In the paper, we describe our construction assuming that a payment-channel follows the design in “Generalized Bitcoin-Compatible Channels” [2], however the Virtual Channel construction can seamlessly work using the current Lightning payment channels. I would be glad to hear any feedback that you may have. Cheers, Pedro Moreno-Sanchez == [1] https://eprint.iacr.org/2020/554 [2] https://eprint.iacr.org/2020/476.pdf > On Feb 8, 2021, at 9:09 AM, Andrés G. Aragoneses wrote: > > Hey ZmnSCPxj, > > Am I correct in understanding that this is a proposal to change the spec > (maybe add a new BOLT) so that all lightning implementations can try to > support this feature. > > If the above is true, then I'm wondering: could a Lightning-based escrow > system be implemented that doesn't require to modify the existing > implementations? Maybe if we simplify the requirements a bit? Like, removing > the "Escrow only learns of dispute cases, never learns non-dispute case" > aspect? That is, the third-party S always knows about an escrow between A and > B taking place. > > I understand that the above requirement is a good to have, but if removing it > allows a simpler version of escrow be implemented, then at least there could > be an interim solution for non-custodial exchanges to start adopting this > (otherwise they have to resort to custodial-based escrows, which is worse > than lacking the escrow privacy brought by the requirement above). > > Thanks > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] General question on routing difficulties
Hi Laolu, Thanks for your detailed and interesting reply. Please see below some points I would like to make in some of your comments and the answers to your questions in the last email. And of course, I would be happy to further discuss with you. On 11/25/17 2:16 PM, Olaoluwa Osuntokun wrote: > (final try as the prior mail hit the size limit, sorry for the spam!) > > Hi Pedro, > > I came across this paper a few weeks ago, skimmed it lightly, and noted a > few interesting aspects I wanted to dig into later. Your email reminded me > to re-read the paper, so thanks for that! Before reading the paper, I > wasn't aware of the concept of coordinate embedding, nor how that could be > leveraged in order to provide sender+receiver privacy in a payment network > using a distance-vector-like routing system. Very cool technique! > > > After reading the paper again, my current conclusion is that while the > protocol presents some novel traits in the design a routing system for > payment channel based networks, it lends much better to a > closed-membership, credit network, such as Ripple (which is the focus of > the paper). > I personally do not agree with this conclusion. The Ripple network uses a global ledger that contains all the nodes, all the credit links among them and the weight of each credit link at all points in time. Therefore, as such, every user can simply check such public information and decide a route with enough credit on its own. There is no need for a decentralized routing algorithm on Ripple as all the information is being continuously updated in the ledger. In the work we present in this paper, we focus instead on a decentralized payment network, where the links’ states (e.g., bitcoin balances in the payment channels within LN) are not continuously logged in the blockchain but instead, every link is locally maintained by the corresponding pair of users. With such setting in mind, we have designed our routing algorithm (SpeedyMurmurs) and we believe it has potential to be used in the Lightning network as well. > > In Ripple, there are only a handful of gateways, and clients that seek to > interact with the network must chose their gateways *very* carefully, > otherwise consensus faults can occur, violating safety properties of the > network. It would appear that this gateway model nicely translates well to > the concept of landmarks that the protocol is strongly dependant on. > Ideally, each gateway would be a landmark, and as there are a very small > number of gateways within Ripple (as you must be admitted to be a verified > gateway in the network), then parameter L (the total number of landmarks) > is kept small which minimizes routing overhead, the average path-length, > etc. > I think this description confuses the terms: gateway, validator and landmark. A gateway is an online exchange service that is trusted to correctly create a credit link with a new user in the Ripple network. If Alice has a Ripple wallet but no credit link yet in the Ripple network, she can get her first issued credits on a link with a gateway. Similarly, Alice can use such online exchange service to get her first bitcoins by paying fiat currency, for instance. Importantly, a gateway does not take part in the Ripple Consensus Algorithm, and therefore a gateway cannot provoke consensus failures and violate safety properties. The Ripple consensus algorithm is run among a set of validators. A validator is the one that can provoke consensus failures. Note that a validator is a participant in the consensus protocol that might not even have a wallet in the Ripple network and therefore might not even be a gateway. For example, MIT and Microsoft have run a validator and are not gateways in the Ripple network. Finally, a landmark as used in SpeedyMurmurs, the routing algorithm we propose in this paper, is simply a node in the network that it is *only* used to bootstrap the routing algorithm, and any node in the network can do so. In the very specific case of a decentralized version of the Ripple network such as SilentWhispers (https://eprint.iacr.org/2016/1054), gateways become good candidates to be such landmarks. However, the routing algorithm that we propose in SpeedyMurmurs is by no means tied to gateways and in particular, landmarks can be simply nodes chosen at random from the complete set of nodes in the network, as we show in the paper. Therefore, we believe that SpeedyMurmurs might be suitable for different payment networks, and in particular for the LN. > > When we compare Ripple to LN, we find that the two networks are nearly > polar opposites of each other. LN is an open-membership network that > requires zero initial configuration by central administrators(s). It more > closely resembles *debit* network (a series of tubes of money), as the > funds within channels must be pre-committed in order to establish a link > between two nodes, and cannot be increased without an additional on-chain > control
Re: [Lightning-dev] General question on routing difficulties
Hello Giovanni, thanks for you interest in our work. The onion-like packets used for *payments* in the current LN implementations inevitably assume that the sender knows the complete path from the sender to the intended receiver. The question/challenge that we are solving in this work is: how does the sender gets to know such path in the first place? One approach is that each user in the LN locally stores the complete set of opened channels either by looking at open channel transactions in the blockchain or by a gossip protocol. However, this approach has trivial privacy issues and it is not scalable for a growing number of users and channels between them. Moreover, this approach is no longer possible if open channel transactions can be modified such that they are indistinguishable from other Bitcoin transactions. Instead, we assume a decentralized setting where each user only needs to know her own open channels and a small set of well connected users (that we called landmarks). In this decentralized setting, our approach still allows a user to route a payment to the intended receiver while preserving scalability and privacy. Cheers, Pedro. On 11/22/17 9:11 AM, Giovanni Di Stasi wrote: > Hello, > > I am in the process of studying your routing approach and a doubt arised > related to the privacy of payments. > The current LN accomplishes payments thorugh onion-like packets which do > not reveil the path, but just previous and next hops. > Your approach also aims at obfuscating the path. What is that your > approach provides more that is not currently provided in the current LN > implementations? > > Thanks, > Giovanni > > On Tue, Nov 21, 2017 at 4:37 PM, Pedro Moreno Sanchez > <pmore...@purdue.edu <mailto:pmore...@purdue.edu>> wrote: > > Hello, > > my name is Pedro Moreno-Sanchez and I am a PhD student at the computer > science department at Purdue. I would like to bring to your attention a > novel routing algorithm suitable for the Lightning Network (LN) that I > have been working on with my supervisor Prof. Aniket Kate (Purdue > University) and my co-workers Stefanie Roos and Prof. Ian Goldberg > (University of Waterloo). > > Our approach is called SpeedyMurmurs, a routing algorithm for > decentralized payment networks such as the LN. SpeedyMurmurs uses an > embedding-based approach, meaning that the algorithm assigns meaningful > coordinates to nodes that enable efficient and effective discovery of > payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by > means of a Breadth-First Search and then associates a coordinate to each > node depending on its position in the tree. A path from the sender to > the receiver is then calculated in a flexible manner, with each > intermediate node choosing the next node in the path as a function of > its neighbors' coordinates, available funds and closeness to the > receiver. To account for topology changes (e.g., a new channel is > created), the routing information is locally updated by only those > affected nodes in the network. > > We have simulated several configurations of SpeedyMurmurs using real > data from the Ripple network and compared it with other routing > algorithms available in the literature. Our simulation results show that > SpeedyMurmurs is able to find paths at about twice faster, reduces the > communication overhead by at least a factor of 2 and maintains a similar > or higher payment success ratio. Our simulation framework is open source > and we believe that it might be of independent interest for this > community to test this and any other alternative protocols that you > might have in mind. If you are interested, we are happy to extend on > this. > > Finally, we also show that SpeedyMurmurs achieves the privacy notions of > interest in the LN. In particular, SpeedyMurmurs achieves value privacy, > i.e., the total value of a transaction remains hidden, as well as sender > and receiver privacy, i.e., the identities of the two transacting nodes > remain hidden from the adversary. > > > You can find all the details in the draft of our paper [1]. The final > version of this work will appear at NDSS 2018 conference [2]. We would > be glad to hear any question and feedback from you and are open to carry > out further collaborations if this line of work is of interest for you. > > Best regards, > Pedro, Stef, Aniket and Ian. > > [1] https://arxiv.org/abs/1709.05748 > > <https://secure-web.cisco.com/1hKUYOfcuq4S8a9TIKcLHGL9DClggwCNIawUq93hdeDE96Iwqy58ZYdtuXM7Gdlsa7Jrf2O
Re: [Lightning-dev] General question on routing difficulties
Hello, my name is Pedro Moreno-Sanchez and I am a PhD student at the computer science department at Purdue. I would like to bring to your attention a novel routing algorithm suitable for the Lightning Network (LN) that I have been working on with my supervisor Prof. Aniket Kate (Purdue University) and my co-workers Stefanie Roos and Prof. Ian Goldberg (University of Waterloo). Our approach is called SpeedyMurmurs, a routing algorithm for decentralized payment networks such as the LN. SpeedyMurmurs uses an embedding-based approach, meaning that the algorithm assigns meaningful coordinates to nodes that enable efficient and effective discovery of payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by means of a Breadth-First Search and then associates a coordinate to each node depending on its position in the tree. A path from the sender to the receiver is then calculated in a flexible manner, with each intermediate node choosing the next node in the path as a function of its neighbors' coordinates, available funds and closeness to the receiver. To account for topology changes (e.g., a new channel is created), the routing information is locally updated by only those affected nodes in the network. We have simulated several configurations of SpeedyMurmurs using real data from the Ripple network and compared it with other routing algorithms available in the literature. Our simulation results show that SpeedyMurmurs is able to find paths at about twice faster, reduces the communication overhead by at least a factor of 2 and maintains a similar or higher payment success ratio. Our simulation framework is open source and we believe that it might be of independent interest for this community to test this and any other alternative protocols that you might have in mind. If you are interested, we are happy to extend on this. Finally, we also show that SpeedyMurmurs achieves the privacy notions of interest in the LN. In particular, SpeedyMurmurs achieves value privacy, i.e., the total value of a transaction remains hidden, as well as sender and receiver privacy, i.e., the identities of the two transacting nodes remain hidden from the adversary. You can find all the details in the draft of our paper [1]. The final version of this work will appear at NDSS 2018 conference [2]. We would be glad to hear any question and feedback from you and are open to carry out further collaborations if this line of work is of interest for you. Best regards, Pedro, Stef, Aniket and Ian. [1] https://arxiv.org/abs/1709.05748 [2] https://www.ndss-symposium.org/ On 11/17/17 8:09 PM, Saravanan Vijayakumaran wrote: > Hi Christian, > > Are there any open source simulators available for trying different > routing strategies? Or even a simulator for the Lightning network as a > whole? > > Regards > sarva > > > On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker > <decker.christ...@gmail.com <mailto:decker.christ...@gmail.com>> wrote: > > Oh yeah, my mail tool destroyed that mail quite expertly :-) > > The footnotes were > [1] > > https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md > > <https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md> > [2] > > https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad > > <https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad> > [3] > > https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf > > <https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igo
