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 Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev