>
> 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
Hi all,
Nicolas Dorier was requesting additional hooks in c-lightning for a simple
WatchTower system: https://github.com/ElementsProject/lightning/issues/1353
Unfortunately I was only able to provide an interface which requires a
*trusted* WatchTower. Trust is of course a five-letter word 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 Christian,
> That is a very good observation. Indeed the absolute timelocks need to
>
> be far enough in the future so that we can commit the latest branch of
>
> the invalidation tree on-chain and then commit the HTLC resolution
>
> before the HTLC timeout expires. That means that
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
