Current web protocols powered by cryptography provide satisfactory means to pass a secret message from one person (the sender) to another (the recipient) without exposing it to anyone else, such as end-to-end encrypted communications tools like Signal. But to shift the time of passing an encrypted message to the future — we have to trust a third party to do it for us.
Our system attempts to limit the the exposure of a secret to a third party and achieve a secure and trustless delivery of encrypted messages which could not be read by the recipient before a trigger event. To make this happen, system relies on the network of third-party agents — the keepers. Keepers don't have any access to the original message, they merely hold parts of a key required to decrypt the message and are motivated to keep it secret until a trigger event in the future.
The trigger event is continuously postponed by the sender, and only occurs when the sender stops actively checking in. In other words, the encrypted message is published when the sender stops preventing it from publishing.
Such system can be useful for releasing a password to encrypted files to relatives or friends in case of amnesia, for releasing sensitive data about rival party in case of imprisonment or other restraint, for leaving inheritance, for anonymity-preserving key escrow, for locking away data from oneself, for blackmailing, and for many other cases.
We want to deliver encrypted message at some future moment of time. By means of asymmetric encryption one could pass a message so only it's recipient could read it. But to achieve time-locking one should postpone the very delivery of the message. If sender must send message now and not later, they must refrain to trusting some third party to deliver the message, with nothing but the trust and contract forcing that third party to do the delivery job. There's no easy way to eliminate the trust, but there are solutions for different use cases.
There are time-locked encryption techniques 1. The main idea is to seal original message with resource- and time-consuming encryption, designed to be decrypted not faster than some timeout. While being solution to some of the use-cases, this way requires big amount of resources from the recipient and doesn't ensure exact timeout.
The simple and centuries-tested solution is to trust attorney to check the event and pass the message then required. Drawbacks are quite obvious: in case something happens with attorney before event, they wouldn't be able to perform their part of the contract.
For more specific use cases there could be automated trustless solutions. For instance, if we want to transfer Ethereum funds or smart contract ownership, we could build smart contract which transfers funds or ownership if the first owner fails to check in during predefined time period.
Bitcannery is a secure trustless deferred free-form message relay. Bitcannery system leans on secret sharing techniques and the network of third-party actors keeping parts of secrets and incentivised to reveal them only in time of future event — be it timeout or passing canary checkin.
The main idea is to store message in the blockchain, but encrypt it so neither Bob nor anyone else could read it before trigger event and only Bob could after that event. As all the data in blockchain is open to read for anyone, we need to encrypt message at least two times: first to prevent anyone but Bob to read it (use asymmetric crypto), second — to prevent Bob from accessing his message before trigger event. To open the message after trigger event, Bitcannery uses a network of "keepers" — agents with access to parts of the decryption key. The key is divided with Shamir's secret sharing method 3, so we don't need every single key part to be able to decrypt Bob's message. After saving encrypted key partsand twice-encrypted message to blockchain smart contract, Alice performs canary checkins within predefined time interval. After missed Alice's checkin keepers decrypt their key parts and send them to smart contract. Once enough keepers had revealed their key parts, Bob restores decryption key from keepers' shards, and then decrypts message from smart contract twice, receiving the Alice's message.
Note that Bitcannery could be used for both timed-out message delivery and dead-man-switch-like mechanics. The main difference would be trigger event for keepers to reveal their parts of the secret. Some parts of current Bitcannery implementation are dependent on specific blockchain features. For reference implementation we've used Ethereum Smart contracts. 1) Smart contract couldn't call its own methods; 2) There's no timeouts for Ethereum Smart contracts; 3) There's no private data store for Ethereum Smart contracts.
1)+2) yields we need someone to call Smart contract to check whether Alice has missed her canary checkin or not; 3) yields the very impossibility to store only once-encrypted message and reveal it after timeout without any extra devices or actors. That being said, one should note that Bitcannery protocol could be implemented on top of any blockchain with Smart contracts with comparable to Ethereum's properties.
There are finer details:
If we could get on by trusting some third-party like using attorney's service — we could be good without any complicated blockchain setup. This way the message could be kept secret, but we need to rely on the third-party to deliver the message. One could use asymmetric encryption to make the message unreadable for the third-party, but the very delivery still depends on it.
If we want to pass ownership of assets which could be put in the blockchain and don't need to make them hidden — for instance, that's the case for passing some quantity of ether — we could store this assets in smart contract and seal ownership with canary checkin scheme. If original owner hadn't checked in (sent transaction to method in smart contract) in predefined timeout, ownership could be claimed by 'successor' (reference implementation could be found in OpenZeppelin framework's Heritable Smart contract 2).
Bitcannery is designed to combine blockchain trustlessness and unstoppability with the message being free-form and unreadable to anyone before trigger event (and readable only to recipient after this event). This use-case suits well for passing personal notes or access keys for any real-world assets.
We need keepers to 1) keep their parts of the secret encrypted and unreachable before trigger event; 2) disclose their parts of the secret after trigger event.
Basic motivation for being a keeper is keeping fee. It's the ether (or any other value transmittable through blockchain) keeper gets for a promise to disclose his part of the secret after a trigger event. As we need some actor to check whether Alice has missed her canary checkin or not, we motivate keepers to check up a Smart contract during Alice's canary checkin period. On every keeper checkin keeper receives part of his keeping fee proportional to time from last checkin. If a keeper hadn't checked in for two consequent periods, he wouldn't get any further keeping fees.
As Bitcannery has all the history of operations for every keeper stored on blockchain, in later point of time it could incorporate reputation tracking in some form. Keepers with best reliability would get better chances to be accepted to new contracts or would be able to set bigger keeping fee.
Another technique under consideration is stakes-based incentive balancing. In order to function properly, Bitcannery should demotivate keepers from selling their key parts to Bob. One of the ways to prevent this from happening is to ask keepers to put some amount of assets to the stake before being accepted as keeper in any contract. In case it becomes known that keeper has revealed their part of the key to anyone before trigger event, one holding the decrypted key claims the stake. Using system-specific token gives another edge of motivation, as keeper wouldn't want to decrease the value of his stake by his bad actions.
Bob wants to get his message before trigger event
Keeper wants to sell his decrypted key part to Bob before trigger event
Sybil attack by keeper
Keepers become inactive and miss their checkins
We have: barebone implementation on top of Ethereum We want in nearest future: 1) explore options of building stakes system; 2) explore options of bringing our own token into the system; 3) explore other blockchains for possible use. Our next steps: 1) deploy to Rinkeby; 2) mass-test there; 3) go for mainnet deployment
Gwern Branwen, Time-lock encryption. https://www.gwern.net/Self-decrypting-files ↩ ↩
OpenZeppelin, Heritable contract. https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/ownership/Heritable.sol ↩ ↩
Shamir, Adi (1979), "How to share a secret", Communications of the ACM, 22 (11): 612–613, doi:10.1145/359168.359176. ↩