5 ms·

> You would need to invest an enormous amount of hashpower to create so many blocks that the difficulty adjustment could ratchet down Thanks for the clarificat

> You would need to invest an enormous amount of hashpower to create so many blocks that the difficulty adjustment could ratchet down Thanks for the clarification. I don't know much about the difficulty adjustment algorithm of bitcoin so that's the point I was missing. So I guess there are some mechanisms like "the difficulty can only be adjusted every N blocks" and "the difficulty can only rise/sink by X%"? If that's it and the deadline for when the key should be released is far enough in the future (e.g. 50 years?), it might still be feasible for an attacker to implement such an attack? > simply by changing the witness proof to require blocks have a certain minimum hashpower on average This assumes, bitcoin is an ever growing network and will never loose miners below a certain point. Depending on how long the key should be secret, this assumption might not hold true and I wouldn't depend on it.

gwern 7y ago
> So I guess there are some mechanisms like "the difficulty can only be adjusted every N blocks" and "the difficulty can only rise/sink by X%"? Yes. So you can manufacture your own blockchain, but you can't simply mint 1 block, declare difficulty just dropped 99.999%, and mint a bazillion more blocks after that. I never worked it out but you'd need to invest like months of current blockchain hashpower to make a pseudo-chain which would do nothing but unlock some timelocks (you can't even try to double-spend anyone, because their clients will follow the heavier chain, which will be the public one). > If that's it and the deadline for when the key should be released is far enough in the future (e.g. 50 years?), it might still be feasible for an attacker to implement such an attack?...Depending on how long the key should be secret, this assumption might not hold true and I wouldn't depend on it. Yes. This is an inherent feature of all work-based timelocks: the further out you go, the more uncertain things are. Rivest's timelock contest is a good demonstration of the empirical difficulties - the squaring timelock looked like it wasn't going to be unlocked on schedule until, out of nowhere, two different groups unlocked it with different approaches. So, you decide what your tradeoff is. Do you want to make as sure as possible that it doesn't unlock early, because too early is catastrophic? Then you require a lot of hashpower and you set a very high minimum hash per block, at the risk of hashpower slowing down and your timelock taking much longer than you expected. Are you worried about it not being unlocked on time? Then you require relatively less hashpower and have looser constraints. It's like PoW: how many transactions do you wait before deciding a transaction is 'real'? If you're in a hurry, maybe you use 0-conf; if you're an exchange transacting $1b in a single block, perhaps you'd better wait a few hundred blocks just to be absolutely certain.

gwern 7y ago

> So I guess there are some mechanisms like "the difficulty can only be adjusted every N blocks" and "the difficulty can only rise/sink by X%"? Yes. So you can manufacture your own blockchain, but you can't simply mint 1 block, declare difficulty just dropped 99.999%, and mint a bazillion more blocks after that. I never worked it out but you'd need to invest like months of current blockchain hashpower to make a pseudo-chain which would do nothing but unlock some timelocks (you can't even try to double-spend anyone, because their clients will follow the heavier chain, which will be the public one). > If that's it and the deadline for when the key should be released is far enough in the future (e.g. 50 years?), it might still be feasible for an attacker to implement such an attack?...Depending on how long the key should be secret, this assumption might not hold true and I wouldn't depend on it. Yes. This is an inherent feature of all work-based timelocks: the further out you go, the more uncertain things are. Rivest's timelock contest is a good demonstration of the empirical difficulties - the squaring timelock looked like it wasn't going to be unlocked on schedule until, out of nowhere, two different groups unlocked it with different approaches. So, you decide what your tradeoff is. Do you want to make as sure as possible that it doesn't unlock early, because too early is catastrophic? Then you require a lot of hashpower and you set a very high minimum hash per block, at the risk of hashpower slowing down and your timelock taking much longer than you expected. Are you worried about it not being unlocked on time? Then you require relatively less hashpower and have looser constraints. It's like PoW: how many transactions do you wait before deciding a transaction is 'real'? If you're in a hurry, maybe you use 0-conf; if you're an exchange transacting $1b in a single block, perhaps you'd better wait a few hundred blocks just to be absolutely certain.