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