[Lightning-dev] Analysis: alternative DoS prevention concept

[Rusty Russell]

"David A. Harding" <dave at dtrt.org> writes:
> On Fri, Nov 11, 2016 at 12:11:54AM +0100, CJP wrote:
>> [...] possible for the attacker by sending many large transactions to
>> himself, over a long route, and letting them time out [...] a lot of
>> funds get locked up, and the total cost of lost opportunity to
>> innocent nodes is a lot higher than that of the attacker.
>>
>> [...] a solution for this DoS mode [is] where nodes require either a
>> fast commit or roll-back within a short amount of time (say 30
>> seconds), or a proof that another channel was closed
>>
>> [...] This basically limits the freedom in channel design to a design
>> space that can be understood by all nodes in the network.
>
>> Instead of being an individual decision between two peers, channel
>> design now becomes a collective network decision.  This interferes
>> with my vision, presented in Montreal, of a heterogeneous network. 
>
> I'm trying to reason about this, and I may have made a mistake, but I
> don't think this DoS mitigation proposal requires a homogeneous network
> because the only person from which you need to receive a (1) commit, (2)
> roll-back, or (3) channel close proof is your direct peer---so as long
> as your direct peer knows how to read the channel close proofs you
> provide them, you can use any style channel close proofs you want.

Unfortunately, the proposal is to route the information back, to prove
somebody was punished for the delay.

That *is* fairly incompatible with crossing networks, since the risk is
now borne by the node doing the crossing (and its neighbor).  Alice will
always have to close with Bob in your example.

Perhaps Bob will simply charge an exchange premium for this risk, but
I feel sorry for Alice; it seems to increase risk overall to the
network since the attacker does not have to close her own channels now.

Cheers,
Rusty.