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

Reply via email to