I'd also like to point out that the way we do state invalidations in Lightning is not really suited for multi-party negotiations beyond 2 parties. The number of potential reactions to a party cheating grows exponentially in the number of parties in the contract, which is the reason the Channel Factories paper relies on the Duplex Micropayment Channel construction instead of the retaliation construction in LN.
Furthermore I'm also not exactly clear how we could retaliate misbehavior on one channel in the other channel if they are logically independent. Without this you could potentially re-allocate your funds to another channel and then attempt to cheat, without it costing your funds. Cheers, Christian ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > Good morning Abhishek Sharma, > > While the goal of the idea is good, can you provide more details on the > Bitcoin transactions? Presumably the on-chain anchor is a 3-of-3 multisig > UTXO, what is the transaction that spends that? What do Lightning commitment > transactions spend? Can you draw a graph of transaction chains that ensure > correct operation of this idea? > > Have you seen Burchert-Decker-Wattenhofer Channel Factories? > https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf > What is the difference between your idea and the Burchert-Decker-Wattenhofer > Channel Factories? > > Regards, > ZmnSCPxj > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > -------- Original Message -------- > On February 4, 2018 6:21 PM, Abhishek Sharma <abhish...@gmail.com> wrote: > >> Hello all, >> I am not sure if this is the right place for this, but I have been thinking >> about the lightning network and how it could be modified so that fewer total >> channels would need to be open. I had the idea for a specific kind of >> transaction, in which three parties commit their funds all at once, and are >> able to move their funds between the three open channels between them. I >> will give a rough overview of my idea and give an example that I think >> illustrates how it could improve users' ability to route their transactions. >> >> Say that three parties, A, B, and C, create a special commitment transaction >> on the network that creates three open channels between each of them with a >> pre-specified balance in each channel. Now, these channels would be >> lightning network channels, and so the three of them could transact with >> each other and modify balances in their individual channels at will. >> However, this special agreement between the three of them also has the >> property than they can move their funds between channels, provided they have >> the permission of the counterparty to the channel they move their funds >> from, and then presents this to the other counterparty to show that funds >> have been moved. >> >> 1.) A, B, and C each create a commitment transaction, committing .5 BTC (3 >> BTC in total) on their end of each of their channels. >> 2.) A, B, and C transact normally using the lightning protocol. After some >> amount of time, the channel balances are as follows: >> channel AB: A - 0.75, B - 0.25 >> channel BC: B - 0.4, C - 0.6, >> channel AC: A - 0, C: 1.0 >> 3.) A would like to send .5 BTC to C, however she does not have enough funds >> in that channel to do so. It's also not possible for her to route her >> transaction through B, as B only has .4 in his channel with C. However, she >> does have those funds in her channel with B, and so asks for B's permission >> (in the form of a signed balance state that includes the hash of the >> previous balance), to move those funds over to her account with C. She gets >> this signed slip from B, and then presents it to C. >> 4.) A, B, and C continue trading on their update balances. >> 5.) When they wish to close out their channels, they all post the last >> signed balance statements each of them has. >> Say, for example, A and B were to collude and trade on their old balance (of >> .75 and .25) after Bsigning the statement that A was 'moving' funds to C. If >> A and C were trading on their new balances, C has proof of both A and B's >> collusion, and she can present the signed slip which said that A was moving >> funds to AC and so the total balance on A and B's channel should've summed >> to 0.5. In this event, All funds in all three channels are forfeited to C. >> >> I believe this works because, in virtue of being able to make inferences >> based on her own channel balances, C always knows (if she is following the >> protocol) exactly how much should be in channel AB. and can prove this. If >> there were 4 parties, C couldn't prove on her own that some set of parties >> colluded to trade on an old balance. >> >> Now, I'll show why such a mechanism can be useful. >> Now, assume that there are parties A, B, C, D, and E, and the following >> channels and balances exist (with the ones marked by a * part of the special >> three-way commitment): >> AB*: A - 1.0, B - 0 >> BC*: B - 0, C - 1.0 >> AC*: A - 0, C - 1.0 >> AD: D - 1.0, A - 0 >> CE: C - 1.0, E - 0 >> Now suppose D wishes to send E 1.0 BTC. With the current channel structure, >> this isn't possible in lightning without opening a new channel and waiting >> for the network to verify it. However, A can ask B to move her 1.0 in >> channel AB to channel AC (with maybe a very nominal fee to incentivise >> this), thereby enabling D to route 1.0 BTC from A to C and finally to E. >> >> I would appreciate your feedback on this idea and any questions you may have >> for further explanation. >> >> Best Regards, >> Abhishek Sharma >> Brown University >> Computer Science '18 > _______________________________________________ > 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
