📅 Original date posted:2015-08-02
📝 Original message:
Christopher Jamthagen <cjamthagen at gmx.com> writes:
>>> 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.
No, it would increase over time. The CLTV block time and real block
time would diverge by 1 block / ~ 10 minutes every time a block is full.
It's the only sane way to do it, as you point out.
It doesn't help that we don't have a formal BIP to point at, but it's
probably a bit premature.
Hope that helps,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:43:53
in reply to nevent1q…86tz
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:43:53Event JSON
{
"id": "81d68898e7b2136af8ab63d9c743fd178b04d2c02eaae3703ab7c53ca81b6891",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314633,
"kind": 1,
"tags": [
[
"e",
"bd7e3601ad88d218940ec74c685433092458d0efc616b43a30f14fda82e7310e",
"",
"root"
],
[
"e",
"10f2dc03ebabb201853a11381999c4dc74d7eef613019d8887a0499b9c8f4538",
"",
"reply"
],
[
"p",
"ad104cac8fd9919c65a2df9e910166f2a1513845fdfa37fd10f1063eb12f5254"
]
],
"content": "📅 Original date posted:2015-08-02\n📝 Original message:\nChristopher Jamthagen \u003ccjamthagen at gmx.com\u003e writes:\n\u003e\u003e\u003e If the timestop feature would activate only when the CLTV transaction\n\u003e\u003e\u003e is included in a block, it would allow for a pretty serious DoS attack\n\u003e\u003e\u003e vector where hubs can be forced to close channels with other hubs by\n\u003e\u003e\u003e having the attacker, as the receiver, never reveal R and create a\n\u003e\u003e\u003e block-filling attack.\n\u003e\n\u003e\u003e I don't think so. Let's say the rule is \"time doesn't pass if a block\n\u003e\u003e is full\".\n\u003e\n\u003e 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.\n\nNo, it would increase over time. The CLTV block time and real block\ntime would diverge by 1 block / ~ 10 minutes every time a block is full.\n\nIt's the only sane way to do it, as you point out.\n\nIt doesn't help that we don't have a formal BIP to point at, but it's\nprobably a bit premature.\n\nHope that helps,\nRusty.",
"sig": "4363293a89fe2373ece69161129833834c61e861b3bc7e87ca4f619072ea3d492ec4050600e4341f9613dfec64ae6c63aa20355296ac1121fafdeec15dd88622"
}