📅 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?
Christopher Jamthagen [ARCHIVE] /
npub145…cvvwf
2023-06-09 12:43:53
in reply to nevent1q…dlrf
Author Public Key
npub145gyety0mxgecedzm70fzqtx72s4zwz9lhar0lgs7yrravf02f2qvcvvwfPublished at
2023-06-09 12:43:53Event JSON
{
"id": "10f2dc03ebabb201853a11381999c4dc74d7eef613019d8887a0499b9c8f4538",
"pubkey": "ad104cac8fd9919c65a2df9e910166f2a1513845fdfa37fd10f1063eb12f5254",
"created_at": 1686314633,
"kind": 1,
"tags": [
[
"e",
"bd7e3601ad88d218940ec74c685433092458d0efc616b43a30f14fda82e7310e",
"",
"root"
],
[
"e",
"697ed76362f2f4fb23b808842804e0e853a334b0fb20e777852fee3a18b2b505",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-08-02\n📝 Original message:\n\u003e\u003e If the timestop feature would activate only when the CLTV transaction\n\u003e\u003e is included in a block, it would allow for a pretty serious DoS attack\n\u003e\u003e vector where hubs can be forced to close channels with other hubs by\n\u003e\u003e having the attacker, as the receiver, never reveal R and create a\n\u003e\u003e block-filling attack.\n\n\u003e I don't think so. Let's say the rule is \"time doesn't pass if a block\n\u003e is full\".\n\nBut 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.\n\n\u003e\u003e This would force the hub connected to the receiver to broadcast the\n\u003e\u003e commitment transaction\n\n\u003e Why? The HTLC wouldn't expire, which would be a pain, but there's no\n\u003e reason to panic and dump transactions. By definition, during a block\n\u003e filling attack you've got all the time in the world.\n\nRight, 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. \n\n\u003e Now, preventing HTLCs from expiring is a DoS, but a lesser one.\n\n\u003e What am I missing?\n\nProbably me who is missing something :)\n\n\u003e\u003e CLTV transactions would need to include the current block-height\n\u003e\u003e immediately when a commitment transaction is signed, so that miners\n\u003e\u003e can know where to start counting full blocks from as soon as it is\n\u003e\u003e broadcast. So my question is: Is such an upgrade for CLTV, as it is\n\u003e\u003e now, soft-forkable as it requires additional arguments? I am not\n\u003e\u003e totally clear on when upgrades are soft-forkable vs. hard-forkable.\n\n\u003e Anything which is a furthur restriction (as in \"this used to be valid,\n\u003e and no longer is\") is soft-forkable. So delaying timeouts is a soft-fork.\n\nGot it. Thanks.\n\n\u003e\u003e\u003e Outsourcability scales really well; once you're full-time monitoring the\n\u003e\u003e\u003e blockchain, might as well get as many clients as possible. You can also\n\u003e\u003e\u003e automate the outsourcee's fee, by including it in the \"steal\" tx.\n\u003e\u003e\n\u003e\u003e 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?\n\n\u003e Indeed, there's a separate thread where Anthony Towns points out that\n\u003e remembering R values and timeouts is an issue.\n\nOk, will have to find time to plow through the mailing list.\n\n\u003e I was referring to the part where you watch the chain for spends on the\n\u003e anchor outputs. You only need to do work to check what happened when\n\u003e one of them gets spent, should almost never happen (since the client\n\u003e should tell you they're going to close the channel cooperatively).\n\n\u003e Cheers,\n\u003e Rusty.\n\n\n\nAm I missing something when I claim that another input is necessary for the CLTV to make timestop work properly?",
"sig": "1f8fd75731bf40b78398566139a84536cf09cd798d844ca39f69a7353f1d45af32f983978df349a1ed97b3319cc48a2c6639abb0df17e2778891ed64429bc704"
}