# [Lightning-dev] An Idea to Improve Connectivity of the Graph

```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
```