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

[Christian Decker]

ZmnSCPxj via Lightning-dev 
writes:

> Good morning Alejandro,
>
> I was about to ask Christian this myself.
>
> There is another technique:
>
> Use a sequence of `nSequence`d transactions off-chain.  For example,
> to get an 2-bit counter, you would have:
>
> funding -> kickoff -> bit1 -> bit0
>
> Only funding is onchain.  kickoff, bit1, and bit0 transactions are all
> kept offchain.  We start a unilateral close by broadcasting kickoff,
> then wait for bit1 to become valid and broadcast then, then wait for
> bit0 to become valid and broadcast then.

Yes, this is exactly the way we would create a shared output that has an
indefinite lifetime, but would still be protected against the
counterparty becoming unresponsive. I usually call the `kickoff`
transaction the `trigger` transaction because it triggers the countdown
on the CSV encumbered scripts.

> There are two versions of the bit1 and bit0 transactions.  Each bit
> position, you have a high `nSequence` to represent the binary 0, and a
> low `nSequence` value to represent the binary 1.
>
> Then to increment your counter, you replace bit0.  If it has a high
> `nSequence` you replace it with a new bit0 transaction with the low
> `nSequence` (equivalent to flipping the bit).  If it is already the
> low `nSequence` (i.e. logically it is value 1) then we "carry" it by
> replacing the next higher bit, then replacing the current bit with the
> high `nSequence` (equivalent to propagating the carry and flipping the
> bit).  Thus it is equivalent to binary incrementation.
>
> It is safe to re-use the high `nSequence` on a lower bit if some
> higher bit in the offchain transactions uses the low `nSequence`
> value, since that higher bit dominates over the rest of the chain.
>
> This is basically just the "invalidation tree" concept brought to its
> logical conclusion.  We could use trinary or quaternary or more, but
> that limits the `nSequence` we can use (we do not want to use too
> large a high `nSequence` value as that increases wait times), so there
> is some balancing involved in the various parameters (number of
> digits, radix of counter).

Well, what you just described is a branching factor of 2, while in the
paper we usually used a branching factor of 48 (1 hour deltas, for 2
days total wait time). Unlike the Locktime based timeouts the deltas
along a branch in the tree are now cumulative so you'd probably want to
make sure that they sum up to a reasonable max timeout, i.e., all sum of
timeouts along a branch <= 2 days total.

> To get a 32-bit counter for a maximum of 4,294,967,296 updates
> transactions in sequence, we need 33 transactions in sequence kept
> off-chain.  When one party disappears, we are forced to feed the 33
> transactions one-by-one into the blockchain.  If we use 4 blocks for
> high `nSequence` (bit 0) and 0 blocks for low `nSequence` (bit 1) then
> at worst case lockup time for unilateral close is 128 blocks.

That is mostly due to the selection of 1 bit sequence diffs, the
branching gives us a huge increase in the number of invalidations. The
paper has the example of branching factor of 46, and a tree depth of 11,
which results in 1.48e11 updates.

> Note that all transactions are kept offchain: we never re-point a
> refund transaction as you describe in your "(b)".  Thus we only waste
> blockchain space if we are forced into a unilateral close.  Normal
> operation, we simply keep all transactions offchain and only touch the
> chain on unilateral or bilateral close.
>
> The big drawback is the large number of transactions in sequence in a
> unilateral close.  In a bilateral close we collapse all transactions
> into a single bilateral refund.  I suppose it is hopeful to consider
> that unilateral closes should be very rare.
>
> So, Christian, it still seems that techniques that reduce total wait
> times in a unilateral close have the drawback of increasing the number
> of transactions in sequence in a unilateral close.  It still seems
> Poon-Dryja, is superior in that total wait time is easily
> user-selectable and unilateral closes only have two transactions in
> sequence.  For low number of updates, we can consider having a tiny
> "counter" (possibly a quaternary counter) that itself terminates in
> multiple Poon-Dryja channels, which I believe is what the
> Burchert-Decker-Wattenhofer channel factories do.

Yes, I agree that DMCs have a much wider on-chain footprint for the
non-cooperative close scenario. I do prefer DMC style updates for some
use-cases though, since they do not have the issue with more than 2
parties, they have no toxic material that can result in your funds being
grabbed, just because you were out of date, and because it means that we
can totally forget old HTLCs since there is no way for them to ever
become relevant again (in LN, if an old commitment gets confirmed we
need to scramble to recover the preimage so the rightful owner can claim
it).

I guess it's another 

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

[ZmnSCPxj via Lightning-dev]

Good morning Alejandro,

I was about to ask Christian this myself.

There is another technique:

Use a sequence of `nSequence`d transactions off-chain.  For example, to get an 
2-bit counter, you would have:

funding -> kickoff -> bit1 -> bit0

Only funding is onchain.  kickoff, bit1, and bit0 transactions are all kept 
offchain.  We start a unilateral close by broadcasting kickoff, then wait for 
bit1 to become valid and broadcast then, then wait for bit0 to become valid and 
broadcast then.

There are two versions of the bit1 and bit0 transactions.  Each bit position, 
you have a high `nSequence` to represent the binary 0, and a low `nSequence` 
value to represent the binary 1.

Then to increment your counter, you replace bit0.  If it has a high `nSequence` 
you replace it with a new bit0 transaction with the low `nSequence` (equivalent 
to flipping the bit).  If it is already the low `nSequence` (i.e. logically it 
is value 1) then we "carry" it by replacing the next higher bit, then replacing 
the current bit with the high `nSequence` (equivalent to propagating the carry 
and flipping the bit).  Thus it is equivalent to binary incrementation.

It is safe to re-use the high `nSequence` on a lower bit if some higher bit in 
the offchain transactions uses the low `nSequence` value, since that higher bit 
dominates over the rest of the chain.

This is basically just the "invalidation tree" concept brought to its logical 
conclusion.  We could use trinary or quaternary or more, but that limits the 
`nSequence` we can use (we do not want to use too large a high `nSequence` 
value as that increases wait times), so there is some balancing involved in the 
various parameters (number of digits, radix of counter).

To get a 32-bit counter for a maximum of 4,294,967,296 updates transactions in 
sequence, we need 33 transactions in sequence kept off-chain.  When one party 
disappears, we are forced to feed the 33 transactions one-by-one into the 
blockchain.  If we use 4 blocks for high `nSequence` (bit 0) and 0 blocks for 
low `nSequence` (bit 1) then at worst case lockup time for unilateral close is 
128 blocks.

Note that all transactions are kept offchain: we never re-point a refund 
transaction as you describe in your "(b)".  Thus we only waste blockchain space 
if we are forced into a unilateral close.  Normal operation, we simply keep all 
transactions offchain and only touch the chain on unilateral or bilateral close.

The big drawback is the large number of transactions in sequence in a 
unilateral close.  In a bilateral close we collapse all transactions into a 
single bilateral refund.  I suppose it is hopeful to consider that unilateral 
closes should be very rare.

So, Christian, it still seems that techniques that reduce total wait times in a 
unilateral close have the drawback of increasing the number of transactions in 
sequence in a unilateral close.  It still seems Poon-Dryja, is superior in that 
total wait time is easily user-selectable and unilateral closes only have two 
transactions in sequence.  For low number of updates, we can consider having a 
tiny "counter" (possibly a quaternary counter) that itself terminates in 
multiple Poon-Dryja channels, which I believe is what the 
Burchert-Decker-Wattenhofer channel factories do.

Regards,
ZmnSCPxj


​Sent with ProtonMail Secure Email.​

‐‐‐ Original Message ‐‐‐

On April 11, 2018 4:43 PM, Alejandro Ranchal Pedrosa 
 wrote:

> Hi Christian,
> 
> > That's not as bad a tradeoff as people usually interpret, the DMC
> > 
> > construction has parameters that allow tweaking the number of
> > 
> > invalidations, and with parameters similar to LN we can have 1.4 billion
> > 
> > updates. Which is years of operation without need to
> > 
> > re-anchor. In addition penaltyless invalidation has a number of
> > 
> > advantages,
> 
> As far as I understand, long-lasting DMCs require either:
> 
>     (a) an initial Refund transaction with a very distant relative
> 
> locktime
> 
>     (b) periodic updates in the form of a Refund transaction pointing
> 
> to a new Refund transaction resetting initial the locktime, instead of
> 
> actually refunding.
> 
>     For an extreme case of (a), if one party goes unresponsive and
> 
> decides not to sign new commitments then the counterparty in the DMC
> 
> will have its funds locked for a significant amount of time, without
> 
> penalising the unresponsive party. In the extreme case of (b), either if
> 
> as a result of a malicious, unresponsive, or honest participant, each
> 
> new refund transaction that resets the refunds may end up hitting the
> 
> blockchain, which means the worst-case utility of the channel itself
> 
> decreasing due to accumulative blockchain fees. Is this the trade-off
> 
> you speak of? if so, can you point at any resource where this trade-off
> 
> is tackled to get worst-case utility similar to that of LN channels?
> 
> Best,
> 
> Alejandro.
> 

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

[Christian Decker]

ZmnSCPxj via Lightning-dev 
writes:
> In a retaliation construction, if a party misbehaves, the other party gets 
> the entire amount they are working on together, as disincentive for any party 
> to cheat.
>
> That works for the two-party case A and B.  If A cheats, B gets money.
>
> How do you extend that to the three-party case A B C?  If A cheats, what 
> happens?
>
> Suppose the correct current state is A=2, B=99, C=3.  Suppose A cheats
> and attempts to publish A=102, B=1, C=1.  C detects it because B is
> asleep at that time.  Does C get to claim the money that A claimed for
> itself, basically 101+1 and thus 102?  But the correct state has
> almost all of the money assigned to B instead.  Obviously that is
> unjust.  Instead C should get to claim only 3 from A (its 3 in the
> final state) in addition to its 1 in the published state, and should
> give the 99 to B.  So now B also needs another retaliatory
> construction for the case "A cheated first and C found out and and
> also cheated me", and a separate construction for "A cheated but C was
> honest".  And that is separate construction for the case "C cheated
> first and A found out and also cheated me" and a separate construction
> for "C cheated but A was honest".
>
> As should be obvious, it does not scale well with number of
> participants on a single offchain "purse"; it quickly becomes complex
> fast.

The need to identify the misbehaving party and punish just that one
party could be addressed by having pre-committed retaliation
transactions. However this results in a large number of pre-committed
transactions that need to be carried around just for the case that
someone really misbehaves. In addition colluding parties may be able to
punish each other when an cheat attempt seems doomed to fail, which
reduces the cost of the attack. This could also be partially fixed by
pre-committing retaliation transactions that split the misbehaving
party's funds. Overall a very unsatisfactory solution.

> Retaliatory constructions however have the major advantage of not
> imposing limits on the number of updates that are allowed to the
> offchain "purse".  Prior to Rusty shachains it was thought to require
> storage linear in the number of updates (which could be pruned once
> the channel/"purse" is brought onchain), but Rusty shachains also
> require O(1) storage on number of updates.  Thus retaliatory
> constructions are used for channels.
>
> Note that channel factories, to my understanding, can have the Duplex
> construction near the root of the initial onchain anchor transaction,
> but be terminated in Poon-Dryja retaliatory channels, so that a good
> part of the current LN technology has a good chance of working even
> after channel factories are implemented.  This strikes me as a good
> balance: restructuring channels is expected to be much rarer compared
> to updating them normally for normal usage, so each construction plays
> its own strengths: the Decker-Wattenhofer construction which imposes a
> limit on the number of updates, but has no limit on number of
> participants, is used for the rarer. massive "channel restructuring"
> operations, while the Poon-Dryja construction which imposes a
> practical limit on number of particiapnts, but has no limit on number
> of updates, is used for "day-to-day" normal operation.

That's not as bad a tradeoff as people usually interpret, the DMC
construction has parameters that allow tweaking the number of
invalidations, and with parameters similar to LN we can have 1.4 billion
updates. Which is years of operation without need to
re-anchor. In addition penaltyless invalidation has a number of
advantages, for example it doesn't have the state asymmetry inherent in
LN and there is no toxic state information that, when leaked, results in
your funds being claimed through a retaliation. This happened to me btw
last month when I accidentally restored a wallet from backup and
attempted to reconnect.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

Good morning Alejandro,

There is no assumption involved, merely a large number of questions.

In a retaliation construction, if a party misbehaves, the other party gets the 
entire amount they are working on together, as disincentive for any party to 
cheat.

That works for the two-party case A and B.  If A cheats, B gets money.

How do you extend that to the three-party case A B C?  If A cheats, what 
happens?

Suppose the correct current state is A=2, B=99, C=3.  Suppose A cheats and 
attempts to publish A=102, B=1, C=1.  C detects it because B is asleep at that 
time.  Does C get to claim the money that A claimed for itself, basically 101+1 
and thus 102?  But the correct state has almost all of the money assigned to B 
instead.  Obviously that is unjust.  Instead C should get to claim only 3 from 
A (its 3 in the final state) in addition to its 1 in the published state, and 
should give the 99 to B.  So now B also needs another retaliatory construction 
for the case "A cheated first and C found out and and also cheated me", and a 
separate construction for "A cheated but C was honest".  And that is separate 
construction for the case "C cheated first and A found out and also cheated me" 
and a separate construction for "C cheated but A was honest".

As should be obvious, it does not scale well with number of participants on a 
single offchain "purse"; it quickly becomes complex fast.

Retaliatory constructions however have the major advantage of not imposing 
limits on the number of updates that are allowed to the offchain "purse".  
Prior to Rusty shachains it was thought to require storage linear in the number 
of updates (which could be pruned once the channel/"purse" is brought onchain), 
but Rusty shachains also require O(1) storage on number of updates.  Thus 
retaliatory constructions are used for channels.

Note that channel factories, to my understanding, can have the Duplex 
construction near the root of the initial onchain anchor transaction, but be 
terminated in Poon-Dryja retaliatory channels, so that a good part of the 
current LN technology has a good chance of working even after channel factories 
are implemented.  This strikes me as a good balance: restructuring channels is 
expected to be much rarer compared to updating them normally for normal usage, 
so each construction plays its own strengths: the Decker-Wattenhofer 
construction which imposes a limit on the number of updates, but has no limit 
on number of participants, is used for the rarer. massive "channel 
restructuring" operations, while the Poon-Dryja construction which imposes a 
practical limit on number of particiapnts, but has no limit on number of 
updates, is used for "day-to-day" normal operation.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Alejandro Ranchal Pedrosa]

Hello all,

Christian Decker pointed the following out
(source:https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000991.html):

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

Can somebody ellaborate on this assumption?

Best,

Alejandro.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Christian Decker]

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

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

[ZmnSCPxj via Lightning-dev]

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  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] An Idea to Improve Connectivity of the Graph

[Abhishek Sharma]

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