# Re: [Lightning-dev] Doubt regarding payment channel capacity

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
>
> Regards,
> ZmnSCPxj
>
> > On Fri, Nov 15, 2019 at 12:46 PM ZmnSCPxj zmnsc...@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 zmnsc...@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.mazumdar1...@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.

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