Extending proof deadlines during chain congestion


#21

No, because there are combination attacks. Even if system A had an invariant that said “an attack that prevents challenges has a cost of at least X, and the possible gain is X, so there’s no incentive to attack”, and system B had an invariant that said “an attack that prevents challenges has a cost of at least Y, and the possible gain is Y, so there’s no incentive to attack”, because congestion attacks congest the entire chain, you can pay max(X, Y) cost to get X + Y revenue from the attack.


#22

Are you pointing out that congestion, regardless it’s cause, affects all channels which have a participant who is awaiting a challenge? In this case wont a deposit be lost in each of these channels? I guess what I’m asking is how can attacker get away with max(X, Y) cost?


#23

Ah, I see, I didn’t read your “closing deposit” proposal above. The problem with that kind of scheme is that you’re imposing a 1:2 griefing factor; I can lose $1 by blocking you from the chain, causing you to lose your $1 as well as the $1 you have in the channel.


#24

Understood. The griefing factor approaches 1:1 for large closing deposits, but that comes with it’s own problems. And in the end ‘approaches’ may not be good enough.


#25

And even 1:1 is quite undesirable; most existing systems don’t let random people delete your money at a 1:1 ratio.