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?
What is the difference between your idea and the Burchert-Decker-Wattenhofer
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