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

2019-11-15 Thread ZmnSCPxj via Lightning-dev
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 


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

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

2019-11-14 Thread fiatjaf

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 <> 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.
Lightning-dev mailing list