Precise threat model, mitigation, add sources

[ariard]

Note, I removed the "decentralisation" as property. It's too loosely defined and I would say it's more a "general" property of Lightning which improve the system on multiple dimensions : privacy, fault-tolerance, payment costs.

That said, I would be glad if we have a better map of centralization vectors.

[ariard]

Updated with corrections at c7310cc.

[ariard]

Updated following offline discussion.

About the bidirectional proposal :

• If C and B relay the settlement upstream quickly (before hold_grace_period_delta) their backwards
  1 > upfront payments are refunded

How do you learn about the HTLC being settled quickly upstream ? Alice -> Bob -> Caroll -> Dave, for Bob to not apply a backward payment on Caroll, he needs to know the state of the link Caroll-Dave ?

More fundamentally, I think that if the backward payment is function of its CLTV locktime you have a routing fee asymmetry profitable to an attacker.. If Bob routes a HTLC for Alice to Caroll, CLTV on the link Alice-Bob must be higher than on the link Bob-Caroll, thus backward fees paid by Bob to Alice will be higher than received from Caroll.

[t-bast]

I would remove these lines, and instead update the sentence below.

[ariard]

Updated with sentence below.

[t-bast]

Suggested change

	* use a reasonable value for `htlc_minimum_msat` (1 sat is **not** a reasonable value for channels
	with a big capacity; it may be ok for small channels though)
	* the attacker needs to lock at least `htlc_minimum_msat * max_accepted_htlcs` of his own funds to completely fill a channel, so you should use a reasonable value for `htlc_minimum_msat` (1 sat is **not** a reasonable value for channels with a big capacity; it may be ok for small channels though)

[ariard]

Adopted this sentence.

[t-bast]

How do you learn about the HTLC being settled quickly upstream ? Alice -> Bob -> Caroll -> Dave, for Bob to not apply a backward payment on Caroll, he needs to know the state of the link Caroll-Dave ?

No, that's why I think the proposal works nicely, you don't need to care about anything else than your local link.
Bob refunds Carol only if Carol settles before her grace_period else, and that's it.
Carol has a delta between her grace_period and the grace_period of the Carol <-> Dave link, so if Carol is honest and Dave settled before the C <-> D grace_period, Carol has ample time to settle the B <-> C link before its grace_period expires.

[ariard]

Carol has a delta between her grace_period and the grace_period of the Carol <-> Dave link, so if Carol is honest and Dave settled before the C <-> D grace_period, Carol has ample time to settle the B <-> C link before its grace_period expires.

Okay this part works if you have a grace_delta between each link. I assume this delta being also expressed in seconds, and its value should be long enough to cover node operation while claiming/failing backward.

More fundamentally, I think that if the backward payment is function of its CLTV locktime you have a routing fee asymmetry profitable to an attacker.. If Bob routes a HTLC for Alice to Caroll, CLTV on the link Alice-Bob must be higher than on the link Bob-Caroll, thus backward fees paid by Bob to Alice will be higher than received from Caroll.

Still this concern holds, if cost structure of routing fees account for lengths of CLTV across links, you should remember that CLTV are decreasing along a payment path. In a situation where grace_period isn't respected, how do you avoid backward fees paid by a routing node on the downstream link being higher than received on the upstream link ?

[t-bast]

Simply because I'm not scaling backwards payments with time held :)
They're a flat amount regardless of time held (and thus are potentially big)