Editing Timechain (section)

= Solving complex trust problems with the timechain =

So … ah this is the section where we show you how to build unhackable Bitcoin services. It’s been quite a ride to get here but so far I’ve showed you how time-lock encryption works; How to generate keys in parallel; And how to use game theory principles to incentivise cooperation by creating the first DAC based on time-lock encryption.

Now let me show you why this is important.

'''Example 1: unhackable cryptocurrency exchange'''

There’s several excellent ways to build an unhackable exchange using the timechain but probably the best way is to adapt [http://www.uptrenda.com/uptrenda.pdf Uptrenda style p2p smart contracts] to reduce the need for an active dispute system.

In practice the exchange would use the timechain to build a chain of ECDSA private keys locked at 5 minute intervals and then publish the public keys without holding on to the original private keys. The public keys could then be used by [https://en.wikipedia.org/wiki/Smart_contract smart contracts] to ensure the owner would eventually gain back full control over their coins if the contract was interrupted.

<blockquote>3, Owner, Owner, Recipient, Timelock, 4, OP_CHECKMULTISIG
</blockquote>
In the multi-sig example we used a single timechain to demonstrate the concept but the possibilities here are endless. You could increase the owner’s leverage to 3 keys and change the multi-sig to 4 of 6 which would leave room for an extra time-locked key on a different timechain and since the owner’s leverage is disproportionate: gaining access to the other keys doesn’t give an attacker enough leverage to steal coins.

What about [http://tinyurl.com/pnkrv9l threshold ECDSA] If a company were to act as a trusted dealer for ECDSA secret shares - the shares could be distributed to multiple timechains. This would allow for representing extremely complex trust relationships that could easily scale to an arbitrary number of participants. The advantage of this approach is you wouldn’t have to use multiple keys for the multi-signature construction which in Bitcoin is quite limited.

'''Example 2: more reliable escrow services'''

Most escrow services rely on primitive trust relationships. A good example of this is the common 2 of 3 scheme where 2 keys are required to sign a transaction. The multi-signature address typically looks like this:

<blockquote>2, Owner, Recipient, Company, 3, OP_CHECKMULTISIG
</blockquote>
The idea is that if the company disappears the owner can collaborate with the recipient to negotiate a refund. Unfortunately, this relies on the assumption that the recipient will cooperate and a reliable financial system based on smart contracts needs to assume the presence of irrational actors (because people like to mess shit up just because they can.)

A simple fix is to time-lock the company key so the extortion scenario doesn’t occur. To make the process slightly more secure you could use a distributed network of oracles in a 9 of 15 scheme together with a [https://en.wikipedia.org/wiki/Reputation_system reputation system] and encrypt the signing keys with the timechain.

'''Example 3: unhackable smart contracts'''

Smart contracts can pay a small fee to the timechain to help incentivise participants to provide a reliable time-locking service and then use the resulting service to time-lock a chain of ECDSA private keys.

The ECDSA private keys can then be used in place of [https://en.bitcoin.it/wiki/NLockTime nLockTimed] refund transactions used by [https://bitcoin.org/en/developer-guide#micropayment-channel micro-payment channels] and [https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki atomic cross-chain transfers] by allowing time-released leverage to return back to the owner.

<blockquote>3, Owner, Owner, Recipient, Timelock, 4, OP_CHECKMULTISIG
</blockquote>
This would solve the transaction malleability problem in refund protocols which enables an attacker to invalidate the refund by changing the TXID of the transaction that the refund spends from before its confirmed in the blockchain - a flaw leading to a possible extortion scenario.

'''Example 4: more reliable multi-signature wallets'''

If the owner stores their coins in a multi-signature wallet and stores some of the keys offline, it is much more difficult for an attacker to steal coins but the problem is in keeping a reliable backup in the event of failure.

One possible solution is to use the timechain. If the owner encrypts a portion of their keys on the timechain the resulting ciphertext can be given to a third-party to hold (or stored on a decentralized database) without the third-party having access to the keys.

'''Example 5: Unhackable timed matrix wallets'''

Timed matrix wallets (TMWs) adapt the idea behind the timechain to improve the security of coin storage by storing coins over time. The idea is that the leverage required to spend a subset of coins is released over time, thereby giving the owner the opportunity to deal with any intrusions before the attacker has a chance to spend the coins.

TMWs are based on the following assumptions: - Payments don’t need to be made straight away. - Coins don’t need to be available all of the time. - Users don’t need access to all of their coins for any given payment. - And: attackers need to be able to move coins quickly.

To take advantage of these properties, TMWs split funds up into a number of multi-sig accounts where a portion of the keys are made to be published in the future via the timechain. The user then deletes their copy of the ECDSA private key but before they do: they also create a new transaction (stored offline) which can be used to shuffle the coins into a future time slot in the event of an intrusion.

Now, if an attacker gains access to the user’s private keys the entire portion of their funds is never at risk and the attacker has to wait to spend coins which can be easily cancelled and moved to a new set of private keys by using the refund transaction. Payments under this scheme must therefore be scheduled into an appropriate time slot, with any unused coins sliding into a future time slot over an infinite period.

This process is kind of analogous to being able to thaw out a cold wallet when its needed and putting it back into deep freeze automatically when it’s not - a process that would explicitly bias the average attacker who needs to be able to move coins out quickly or risk being discovered.

'''Example 6: all the usual stuff time-locked crypto allows'''

The timechain would act as an excellent [https://en.wikipedia.org/wiki/Dead_man%27s_switch dead man’s switch] for journalists or politically exposed individuals; It could be used for voting or auctions; Or simply for reliable data decryption / backups.

<span id="conclusion"></span>