Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-01 📝 Original message: Christopher Jamthagen ...

📅 Original date posted:2015-08-01
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>> Sent: Friday, July 31, 2015 at 1:48 AM
>> From: "Rusty Russell" <rusty at rustcorp.com.au>
>> To: "Christopher Jamthagen" <cjamthagen at gmx.com>
>> Cc: "lightning-dev at lists.linuxfoundation.org" <lightning-dev at lists.linuxfoundation.org>
>> Subject: Re: [Lightning-dev] Stealing money from a hub?
>> Christopher Jamthagen <cjamthagen at gmx.com> writes:
>>> Would it be desirable/possible to implement the timestop feature for
>>> CLTV as well? That would make the difference between the number of
>>> blocks until either expiration the same in case of a block-filling
>>> attack. If I'm not mistaken Peter Todds BIP is already merged, but
>>> this feature could be implemented with another soft fork.
>
>> Yes, timestop would logically be a softfork add, and it should apply to
>> both (same logic applies).
>
> If the timestop feature would activate only when the CLTV transaction
> is included in a block, it would allow for a pretty serious DoS attack
> vector where hubs can be forced to close channels with other hubs by
> having the attacker, as the receiver, never reveal R and create a
> block-filling attack.

I don't think so. Let's say the rule is "time doesn't pass if a block
is full".

> This would force the hub connected to the receiver to broadcast the
> commitment transaction

Why? The HTLC wouldn't expire, which would be a pain, but there's no
reason to panic and dump transactions. By definition, during a block
filling attack you've got all the time in the world.

Now, preventing HTLCs from expiring is a DoS, but a lesser one.

What am I missing?

> CLTV transactions would need to include the current block-height
> immediately when a commitment transaction is signed, so that miners
> can know where to start counting full blocks from as soon as it is
> broadcast. So my question is: Is such an upgrade for CLTV, as it is
> now, soft-forkable as it requires additional arguments? I am not
> totally clear on when upgrades are soft-forkable vs. hard-forkable.

Anything which is a furthur restriction (as in "this used to be valid,
and no longer is") is soft-forkable. So delaying timeouts is a soft-fork.

>>> Speaking of being online all the time, checking the blockchain is
>>> outsourceable, right? So it seems that miners would be the perfect
>>> third party to check for cheaters in LN. By offering them a nice chunk
>>> of our counterparty's funds as fees, they should be incentiviced
>>> enough to keep an extra eye for us on the blockchain.
>
>> Outsourcability scales really well; once you're full-time monitoring the
>> blockchain, might as well get as many clients as possible. You can also
>> automate the outsourcee's fee, by including it in the "steal" tx.
>
> Does it scale that well? I guess looking up pre-images in the shachain is fast, but what about R values in HTLCs? Would the third party have to store all those values or is there a nice optimization I have missed?

Indeed, there's a separate thread where Anthony Towns points out that
remembering R values and timeouts is an issue.

I was referring to the part where you watch the chain for spends on the
anchor outputs. You only need to do work to check what happened when
one of them gets spent, should almost never happen (since the client
should tell you they're going to close the channel cooperatively).

Cheers,
Rusty.