[Lightning-dev] Doubt regarding payment channel capacity

[ZmnSCPxj]

Good morning list,

Some hundred or so blocks ago, lightning-dev emails were being undelivered.
It seems okay now.

There was a long discussion I had with Subhra at the time, unfortunately it ended up being off-list due to the mailing list being down.
In any case, I believe it would be of interest, and thus below is the emails involved.

Regards.
ZmnSCPxj

> Good morning Subhra,
>
> > Hello,
> >         Thanks a lot for the detailed explanation. It justifies why this attack may not sustain quite long in the network. Another question regarding routing then. It is assumed that when channels are probed for routing, it will be checked whether there is enough balance in the channel to route the payment or not. But the only view which one has of the channel is the initial capacity of the channel and not the balance of the channel at that moment. What if the pair of nodes in a channel are byzantine and reports a wrong value of residual balance ? Consider the previous example where B and C may have locked some amount between them say 1 BTC but B and C are part of one collective controlled by an adversary. What if BC gets routing request for 20 transaction, each having payment value of 0.1 BTC ? Again the case may be that T_i channel with B (i \in [1,20]), each channel T_i,B having capacity of 0.3 BTC and C has channel with D_i (i \in 1 to 20), each having channel capacity of 0.3 BTC. So now in this case it doesn't matter what balance BC has, it just goes on reporting a balance of 0.1 BTC to accept all routing request till lifetime of the channel, but in reality it is not locking any fund at all. So is this possible where a wrong information of channel's balance is reported ?
>
> You strongly misunderstand.
>
> Neither B nor C can misreport the funds in the channel, for the following very simple reason:
>
> -   There is no facility to actually remotely report the channel balance.
>
>     Thus this is still not a problem.
>
>     Nobody else particularly cares what the exact balance is on the B<->C channel (because if they were econmically-separate entities and had a good amount of traffic with the network, then the exact balance would have changed by the time you receive the information anyway, so why bother asking?).
>
>
> Everybody else only cares whether it is possible to route via the B<->C channel or not.
> That is all that is reported: whether an HTLC of amount X can be routed right now, or not.
> In your case, it would mean that B and C would always report that it can be routed right now, but so?
> It just means increased payment reliability on the rest of the network (and reflects the truth as well: B and C are the same entity anyway, thus the reliability of the B<->C channel is equivalent to the reliability of the B C aggregate).
>
> There is no way for B and C to somehow promote this into an attack on the network.
>
> Fundamentally speaking, if B and C are the same economic entity, then the B<->C channel (which has to be backed by some UTXO, else it cannot be announced on Lightning) is no different from that single economic entity keeping some funds on a hot online wallets.
>
> If an entity keeping some funds in a hot wallet has no effect on the Lightning Network, then the existence of the B<->C channel also has no effect on the Lightning Network.
> Economically speaking, if you are going to put funds in a hot wallet anyway, on a computer you are obligated to keep online 144 blocks a day, 2016 blocks a difficulty adjustment, then you might as well put those funds in a real, externally-earning channel on the Lightning Network, but I made that argument already anyway.
>
> Regards,
> ZmnSCPxj
>
> > On Fri, Nov 15, 2019 at 12:46 PM ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> >
> > > Good morning Subhra,
> > >
> > > > So that means its not a problem if the cluster size increases from B->C to B->C->X->Y->Z ? I mean we still get a successful payment but is not at the cost of A locking greater processing fee for the intermediate node B,C,X,Y and Z even though they are one single entity ? Unnecessarily there is an increase in the path length, plus in this way B can spawn several such dummy nodes in order to gain processing fee. Sorry if I am not getting it correctly but as you have pointed out if there is a single node Q between A and D then obviously that will be preferred. But what if there is no alternate route available to A in order to reach D and A->B->C->D is the only option ?
> > >
> > > Yes, it is not a problem at all.
> > > It is helpful to remember that the channels B<->C, C<->X, X<->Y, and Y<->Z require being backed on the blockchain, and requires money to be allocated for it.
> > > This money could have been used elsewhere on the network to serve as shortcuts between other nodes, not just to artificially lengthen the path between A and D.
> > > Thus, this represents an opportunity cost on the aggregate B C X Y Z nodes.
> > > Let us compare between two universes:
> > >
> > > -   B C X Y Z make a path between A and D only.
> > > -   B makes a path between A and D.
> > >       C makes a path between a different pair of nodes.
> > >       X makes a path between yet another pair.
> > >       Y makes a path between yet another pair again.
> > >       Z makes a path between yet yet another pair again again.
> > >
> > >
> > > It is far more likely that the aggregate B C X Y Z will earn more, and more consistently, in the second universe, than in the first.
> > >
> > > -   The first universe will only net B C X Y Z some money if A and D pay each other.
> > >       The second universe will net B C X Y Z some money if any of the pairs pay each other.
> > >       This leads to a more consistent earnings overall (this is the same argument that pushes miners towards pools).
> > >
> > > -   The second universe has B C X Y Z be the shortest path between many pairs of nodes.
> > >       This makes it more likely that they will be selected in payments between them.
> > >       This leads to increased earnings overall in the second universe.
> > >
> > >
> > > Thus, anyone who is foolish enough to create such a chain of nodes would, in the long run, lose out on earnings than if they just had multiple nodes creating shortest paths between as many nodes as they can afford to make.
> > > In short, this is economically irrational behavior.
> > > Always remember that if the fees between A and D become too onerous, then A and D might decide that the onchain fee to open a direct channel between them would be amortized cheaper than paying the long chain of nodes between them, immediately destroying the ability of the B C X Y Z aggregate to earn funds.
> > > So this is not a problem.
> > > Economic rationality will lead to such behavior being selected against, and such attacks will be routed around.
> > > Indeed, my proposal for `getroutequick` bases the expected `O(log n)` routing behavior on the observation that such long chains must be made artificially and cannot survive for long, thus the shortest-path tree will be approximately balanced and the height of the tree will be `O(log n)` for all layouts of the network, even as the network size `n` grows..
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > On Fri, Nov 15, 2019 at 9:36 AM ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> > > >
> > > > > Good morning Subhra and fiatjaf,
> > > > > This is fine, and not in fact a problem.
> > > > > B and C might be separate entities "on paper", but econmically, they are still just a single entity.
> > > > > What matters is that the aggregate B and C cannot steal from someone who is not part of the collective.
> > > > > And that is maintained simply by other nodes requiring that the channels between B and them, and C and them, have the correct balance.
> > > > > In short, a network A <-> B <-> C <-> D and a network A <-> Q <-> D, where B and C are "really" the same entity (they are cooperating with each other very closely), are indistinguishable from each other.
> > > > > Now of course the B<->C option means that A and D will now have to pay more fees to traverse that subnetwork, but that also means greater scope for an independent Q to undercut B<->C by just running a single node and connecting between A and D directly.
> > > > > i.e. This is not a problem.
> > > > > The funds locked in channel B <-> C remain owned by the aggregate B and C, and onchain will just be exactly the capacity they put in there in aggregate.
> > > > > And this cannot be used to outright steal from other nodes.
> > > > > Even routing cannot be stolen, since payers will prefer a single node Q over the aggregate nodes B<->C, and Q does not need to maintain some funds locked in a B<->C channel, thus Q has the advantage here.
> > > > > Regards,
> > > > > ZmnSCPxj
> > > > >
> > > > > > Hello,
> > > > > > What happens between two peers is no business of others. They can do what you said if they're cooperating, and many other dirty tricks. And that's not a problem at all for other nodes.
> > > > > > The only thing they can't do for not is advertise a channel without telling others where it was funded on the chain, but that's just for antispam reasons (as other nodes must keep track of all announced channels) as far as I know.
> > > > > > On Thursday, November 14, 2019, Subhra Mazumdar subhra.mazumdar1993 at gmail.com wrote:
> > > > > >
> > > > > > > Hello everyone,
> > > > > > >        My doubt might be silly and apologies for the same. Suppose in a payment channel network say 2 parties B and C are malicious, controlled by same adversary. They had initially opened a channel of 1 BTC. But suppose they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2 transaction, B and C has capacity of 0.2 BTC. But  what if BC reports an incorrect residual balance thereby accepting the 3rd transaction. Who will keep track of this capacity violation since no one is keeping track of this residual value ? If this case is true, then parties might resort to such a strategy opening a low value channel but still accepting multiple transactions where the total payment value of all transaction exceeds channel capacity. Please correct me if I am wrong.
> > > > > > > --
> > > > > > > Yours sincerely,
> > > > > > > Subhra Mazumdar.
> > > >
> > > > --
> > > > Yours sincerely,
> > > > Subhra Mazumdar.
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.