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

Reply via email to