Turning back the clock on timechains - a follow-up

Notice: I removed subscribers and disabled subscriptions because I don’t like the idea of Subtle spamming people every time I make a post.

In 2015 I introduced the concept of a timechain as a solution to certain trust problems in smart contracts to mixed reviews. People like Greg Maxwell pointed out the uncertainty in the design which is something that would have made the timechain unsuitable for complex contracts whereby the timing of the clock needs to be within a certain range of accuracy [0].

But thinking about this some more I think there’s some very obvious solutions to this problem. There’s two main issues with my proposal:

  1. Serial hashing can be sped up on processors with faster clock speeds so the timechain will be broken faster than expected and
  2. The initial trust required in generating the chain.

Problem number 1 really needs to be considered in the context of two very different attackers. Attacker number 1 is economically motivated. He wants to break the timechain as fast as possible to recover the reward. Whereas attacker number 2 has unknown motivations. It may be some kind of intelligence agency that wants to undermine the security of the timechain to be able to instantly decrypt messages or someone who wishes to undermine confidence in the chain to discourage users.

Economically motivated attackers are in a race against each other to decrypt the chain. So initially these actors are going to be investing as much as they can justify in increasing their serial hashing capabilities to outpace other economically motivated actors - a process which will ultimately reveal how fast the timechain can be broken. But consider the motivations of attacker 2 who doesn’t directly care about the reward and hence won’t end up revealing how fast they can crack the chain… [1]

 Bootstrapping a timechain

If you think about it in the beginning there is not going to be much information available to the market on how fast serial hashing can be made which undermines the security of contracts that depend on accurate short term performance (i.e. contracts that use the timechain over a few hours instead of a few years.) Then there is the case that over time as clock speed increases the timechain will be broken faster than predicted so long term contracts could be seriously at risk.

What I propose is a measure to secure short term contracts and another to secure long term ones. In the short term, links for a chain could be distributed among a group of people who choose to publish the next link at the correct time regardless of how soon the previous link was broken [2][3].

For contracts that use the timechain long term, a solution is to generate a series of additional timechains that are used to wrap the message with. So say that the first timechain is live. You still generate another set of key pairs for the additional timechains and provide them for use to messages like timechain1_1hour(timechain2_1hour(…(message))).

The benefit of this is that since the actual serial hashing for the other timechains hasn’t been done yet it becomes possible at some point in the future to create a timechain in response to how fast and how far previous timechains have already been broken. So this allows the clock to be turned back on a timechain that is being broken faster than expected. Reliability++;

So with both these approaches there is still minimal trust involved and additional timechains still benefit from the security of the first underlying timechain that a message was encrypted with so even if their key pairs are compromised the message cannot be hacked. However, if these additional timechains are generated correctly then it also becomes possible to provide an even greater guarantee of long-term decryption of a timechain since the difficulty can be adjusted as needed.

These solutions should be enough to build a self-correcting timechain for short-term and long-term contracts in the presence of initial that uncertainty. And with the timechain, the longer it runs the more secure it becomes since more information becomes available on exactly how fast serial hashing can be made, and hence it is easier to predict exactly how fast the chain can be broken to provide accurate decryption times.

This would also mean that potentially long-term you don’t need to rely on thresholds at all as a safe-guard for short-term security - but rather more as a hedge against unknown factors (like quantum computing break-through [4].) So with that said I am confident this should be enough to use a timechain in production (if you trust the competency of the generator which obviously isn’t an issue if the generator is using their own timechain.)

 But what about that second issue – the toxic sludge of having keys around while you generate a chain?

Well, there may be a way to consign creating the initial chain to multiple parties much like how Z Cash did their trusted setup phase. So at least if one person is completely adversarial (DoS or key compromise) then the timechain is still protected if someone is hacked.

Remember that the main problem to solve is having to manage keys to release information over time. We achieve this guarantee in theory but in practice it is hard to prove that a timechain has been constructed correctly. Hence, if a person is paranoid they can always construct their own chain or use multiple combinations of public timechains.

Or use a smart contract…

Another idea is to base a smart contract on the performance of a timechain and have the owner back this performance up with real money so that if keys ever get leaked before a certain point he loses money.

This would not prove that messages weren’t being selectively read but it would mean that financial companies who are using their own timechains to protect their own products are kind of standing behind their security which is more or less what I had in mind for the initial use-case anyway.

Tl; dr: Splitting up the chain links and using multiple timechains to do timechain1(timechain2(…(msg))) is actually perfectly acceptable to stop clock skew and becomes more acceptable over time.


[0] Like a real clock, really.
[1] Or perhaps an even more sophisticated attacker who has calculated some other scheme whereby concealing exactly how fast they can break links is in their best interest.
[2] These people can only choose to release the next link when the previous one is broken. Their links will be encrypted. Hence no cheating.
[3] At first thought this might seem like its trusted but if any of these participants are hacked you can still adjust the timechain from the other remaining honest actors and the underlying probabilistic security for the timechain still remains in tact even if every last node is hacked. Reliability++.
[4] And the fact that wrapped timechain encryption allows for adjusting chains means that migration schemes are possible.


Now read this

Building a decentralized cryptocurrency exchange using zero-knowledge proofs

7/12/2017: The protocol is flawed and contains a black mail risk. The other side cannot claim a refund without knowledge of the secret so even if the TXIDs can be validated with ZK-proofs the scheme still doesn’t work. I guess its back... Continue →