Editing Timechain (section)

= Frequently asked questions &amp; answers =

<blockquote>'''How do you avoid biasing the reward for the first participant?'''
</blockquote>
The first person who starts breaking the timechain will have an unnatural lead on everyone else making it extremely improbable that anyone else will be able to claim the reward. To solve this problem we borrow an idea from [https://en.bitcoin.it/wiki/Mining Bitcoin mining] called a [https://en.bitcoin.it/wiki/Nonce nonce].

Instead of using a full compressed ECDSA public key for the IVs, we remove some of the bits and replace them with random data and use the modified ECDSA public key as the IV. How much information to remove depends on how early in the chain the link occurs. If the link occurs at the start then only a few bits are removed but if the link occurs late in the chain, then many more bits may be removed to account for hardware getting faster and more computing power being used to find the correct IV.

The new non-deterministic IV is then hashed with [https://en.wikipedia.org/wiki/Scrypt Scrypt] and encrypted with the RSA public key of the previous link. Now, when a solution is found it also publishes a hash of the next IV in the chain which tells participants what the first IV should hash to (which they don’t yet have.)

Therefore, the first person to break a link has no further advantage in breaking the next link as the next IV must be brute forced using a simple nonce-based puzzle before the link can be broken.

<blockquote>'''What if there is no reward? Why bother?'''
</blockquote>
We propose adding a blockchain and cryptocurrency to the system, but with slightly modified coinbase. Every time a link is broken, the entity that broke it can add a new block to the blockchain and give themself a fixed amount of the timechain’s currency (Time.)

To be able to claim Time a proof of broken link is required which is simply a receiving address and public key of the next IV signed with the ECDSA private key of a previously unbroken link plus any pending Time transactions. When nodes in the network receive this information they issue Time to the receiving address and confirm any pending transactions.

Transactions are handled the same for this as they are with Bitcoin: with new blocks on the blockchain being used to process transactions and assign any fees to the miner. The only fundamental difference is in mining process where hash rate is used to secure the overall integrity of the blockchain by miners in exchange for a small amount of Time.

<blockquote>'''What about improvements to SHA256 hash speed?'''
</blockquote>
In practice the rate at which the timechain is broken will differ from the exact time needed to produce it. If there is a significant advance in hardware that allows for faster serial generation of SHA256 hashes the timechain will be broken faster. On the other hand: if there is a lack of participation in the cracking or solutions to the IV puzzle aren’t found fast enough - the timechain will be broken slower than expected.

The solution is to adjust the way we use the timechain based on the cracking time for the previous link (clockskew.) That way, the timechain itself does not need to be adjusted and the structure stays secure even in the face of hardware advances.

Clockskew over time can be used to further inform the construction of future yearly timechains allowing the difficulty of the IV puzzle to increase based on the time increases seen in cracking the previous year’s timechain.

<blockquote>'''But … you have to trust the timechain, right?'''
</blockquote>
Yes, but if you’re worried about the integrity of the timechain you can always use multiple timechains. One way to go about this is to use the “threshold time-lock encryption” technique described in the [http://www.uptrenda.com/uptrenda.pdf Uptrenda white paper].

If you’re using smart contracts multi-sig also allows you to make some of the keys redundant so if there’s multiple timechains protecting your contract, some of the timechains can fail without loss of funds.

'''And well … you can always generate your own timechain.'''

The most important thing to remember is that the timechain provides a passive function with no intervention necessary so even if companies only use this technology to remove the need to hold private keys in some cases - that is still a huge improvement in security for the services that use this - in particular services based on smart contracts and DACs.

<blockquote>'''How will you handle consensus?'''
</blockquote>
Participants in the timechain will download software compiled with the timechain precomputed. The timechain will allow them to verify whether peers have found a solution allowing nodes to advance further along the chain. It will probably be necessary to use a peer-to-peer network to share solutions and add fault tolerance so that nodes can easily broadcast solutions to see current progress made in breaking the chain.

This open style of participation would also make it harder for a centralized service to lie about the progress made in breaking the chain thereby improving the reliability of time-locking.

Users of the timechain will therefore have accurate information on where in the chain to encrypt data in order to achieve a desired time-lock taking into account the time field includes in blocks and the ''clockskew'' - which is a measure of the current rate of cracking against the expected time to break the chain.

<blockquote>'''Towards a prototype for the first timechain'''
</blockquote>
A prototype / test version of the timechain can be created on a single GPU so long as the generation of the chain can outpace the rate of cracking. Furthermore, if the RSA keys are generated in advance then the keys can be used to time-lock information before the timechain has been generated up to that point. This would be analogous to laying tracks for a railway leading up to new terminals while a very slow train was not far behind you.

Obviously this structure would not be used for a production system since it means keeping the computer responsible for generating the timechain online and requiring it to keep RSA keys around which would opens it up to the very same problems the timechain is suppose to solve - but … the concept can still be used to show people how the timechain works for a relatively low cost without having to rent out a GPU cluster to do it.

Thoughts?