Christopher Jamthagen [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-02 📝 Original message: >> If the timestop ...
📅 Original date posted:2015-08-02
📝 Original message:
>> 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".
But it would be necessary to explicitly supply the block-height at which the transaction that includes the CLTV was signed. Otherwise miners would have no other info but the block it is included in from which to count the number of full blocks to add to the expiration time of the CLTV.
>> 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.
Right, the HTLC in the broadcasted commitment transaction between receiver and closest hub wouldn't expire, but the HTLC between the closest and second-closest hub would expire in a block-filling attack. Just to clarify, my example was with the timestop feature, but a CLTV implementation without announcement of explicit block at which the transaction was signed.
> Now, preventing HTLCs from expiring is a DoS, but a lesser one.
> What am I missing?
Probably me who is missing something :)
>> 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.
Got it. Thanks.
>>> 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.
Ok, will have to find time to plow through the mailing list.
> 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.
Am I missing something when I claim that another input is necessary for the CLTV to make timestop work properly?
📝 Original message:
>> 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".
But it would be necessary to explicitly supply the block-height at which the transaction that includes the CLTV was signed. Otherwise miners would have no other info but the block it is included in from which to count the number of full blocks to add to the expiration time of the CLTV.
>> 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.
Right, the HTLC in the broadcasted commitment transaction between receiver and closest hub wouldn't expire, but the HTLC between the closest and second-closest hub would expire in a block-filling attack. Just to clarify, my example was with the timestop feature, but a CLTV implementation without announcement of explicit block at which the transaction was signed.
> Now, preventing HTLCs from expiring is a DoS, but a lesser one.
> What am I missing?
Probably me who is missing something :)
>> 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.
Got it. Thanks.
>>> 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.
Ok, will have to find time to plow through the mailing list.
> 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.
Am I missing something when I claim that another input is necessary for the CLTV to make timestop work properly?