Good morning Jim,
>> It seems to me that adding an entire new attack vector in order to only
>> *mitigate* (not eliminate!) another attack vector is not a good enough
>> trade-off. In particular the new attack seems *easier* to perform. The
>> current attack where I annoy the other side until
>
> It seems to me that adding an entire new attack vector in order to only
> *mitigate* (not eliminate!) another attack vector is not a good enough
> trade-off. In particular the new attack seems *easier* to perform. The
> current attack where I annoy the other side until it closes has the risk
> Since there is no delay involved in my branch, I can get the money
> immediately without Daniel being able to revoke it. So I get 1.0BTC and
> 0.99BTC worth of Daniel products.
Perhaps I should have clarified, the side unilaterally closing the
channel would always have to wait for the full dela
Good morning all,
It seems to me the below two worlds are possible:
1. Symmetric delays.
1.1. I can attack passively: I force a condition where most funds are in the
other side (e.g. forwarding to another node I control, or exchanging BTC for
material goods), then stop forwarding payments and
Letting the attacker have immediate access to their funds is a null point
because the attacker always has the preparation time to unbalance the channel
to the honest node's favor. The attacker's 'funds' in this case is trivially
reduced to 'reserve balance'. It's hard to argue that forcing the m
Thanks ZmnSCPxj and Jim,
> Indeed, in the situation where you are funding a new channel to me, I have 0
> satoshi on the channel and can perform this attack costlessly.
My thinking here is that an attacker would have a hard time getting
others to open new channels with them, and that even when o
I believe that anyone attempting a DOS by forcing on-chain settlement can
do it just as easily with asymmetric delays than with symmetric delays.
If my goal is to waste the time-value of your money in a channel, in a
world with symmetric delays, I could just publish the commitment
transaction and
Good morning Daniel,
> This makes a lot of sense to me as a way to correct the incentives for
> closing channels. I figure that honest nodes that have truly gone offline
> will not require (or be able to take advantage of) immediate access to their
> balance, such that this change shouldn't cau
This makes a lot of sense to me as a way to correct the incentives for
closing channels. I figure that honest nodes that have truly gone offline
will not require (or be able to take advantage of) immediate access to
their balance, such that this change shouldn't cause too much inconvenience.
I was
> By extension, perhaps both sides should use the maximum delay either one
> asks for?
>
I'm not sure that is necessary. As long as both parties have to wait the
same amount of time regardless of whether they publish the commitment or
the other side does, that would resolve the issue.
> I don't
Jim Posen writes:
> I find it easier to analyze the game theory of these situations if the
> to_remote output is also time-locked by the to_remote_delay. Making the
> consequence of an on-chain settlement symmetric changes the game from
> chicken [1] to a tragedy of the commons [2]. I'm curious ho
11 matches
Mail list logo
