Christopher Jamthagen [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-01 📝 Original message: > Sent: Friday, July 31, ...

📅 Original date posted:2015-08-01
📝 Original message:
> 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. This would force the hub connected to the receiver to broadcast the commitment transaction, but since there is a block-filling attack going on, the hub can't settle with the next hub because the first hubs CSV and CLTV are being pushed beyond the second hubs CLTV (which isn't broadcasted or included in a block yet, so the timestop feature doesn't apply) and so it goes on forcing every hub along the payment path back to the sender to broadcast their commitment transactions and closing the channels. It would be cheap to amplify this attack since the attacker only need to make enough HTLC transactions including as many hubs in LN as possible to take out a large portion of the network for a while.

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.

>> 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?

> But I realized yesterday, outsourcing needs a new sighash op mode (or
> normalized txids), so it's not really something to design a deployable
> system around today.

So it is. What a shame.

> Cheers,
> Rusty.