v0.1 spec

[pfletcherhill]

Best-case behavior:

1. Revealer B adds itself to contract (public key, minimum reward, stake) by staking S ERASE tokens.
2. Repeat step (1) for N revealers B, C, ...
3. User A creates a message, including IPFS link to encrypted data, block to be revealed, time lock reveal period (in number of blocks), time lock reward (in ERASE), hash of secret, K (number of secret shares needed to reconstruct), list of N secret shares (hash of secret share, encrypted secret share using revealer's public key, address of revealer).
4. Revealers running kimono client see new message on contract and parse list of secret shares. If they see a secret share that is their own, they note the block to be revealed.
5. When the block to be revealed happens, all N revealers with secret shares included in the original list decrypt the encrypted secret share and post the decrypted version to the contract.
6. Anyone watching the contract waits until K revealers have posted their decrypted secret share and try to reconstruct the original secret. When they reconstruct a secret that hashes to the hash on the contract, they post the secret (allowing anyone to decrypt the data in IPFS) and record themselves as the reconstructor (if no one else has reconstructed it yet).
7. Since every revealer posted their decrypted secret share, the time lock reward is split into N + 1 pieces and distributed to each revealer and the third party reconstructor.

Notes:

• If only M (M >= K) of N revealers have revealed their secret shares by the time a valid secret is reconstructed (and written back to the contract), the reward is split M + 1 ways between the M revealers who added valid secret shares to the contract and the reconstructor. Nothing happens to the revealers that add their secrets after the secret has been reconstructed and before the time lock period ends—they are not rewarded and their stakes are kept as is. Revealers that do not reveal their secrets before the time lock period ends have their stakes made available for the creator to withdraw.
• If at any time before the time lock block, someone gets access to one of the revealers decrypted secret shares, they can submit that to the contract to steal the stake of that revealer (to incentivize revealers to keep their secret shares secure until the time lock).
• Minimum reward represented as reward / (N + 1), where N is the number of secret fragments (i.e. the reward the revealer would get if every revealer reveals their fragments and they are not the reconstructor).
• If a revealer wants to withdraw their stake, if they have already been assigned a job, they have to keep their ETH around for 2 weeks before withdrawing. If they haven't been assigned any jobs, they can withdraw immediately.

[mertcelebi]

Point 3 could probably also take the N Ethereum addresses, so for point 4, users of the kimono client can just watch for events which have their own addresses

[mertcelebi]

Another point is that we should have some form of buffer (ie +/- 5 blocks) for the block to reveal

[pfletcherhill]

kimono-js spec

const kimono = new Kimono(<web3 provider>);
const receipt = await kimono.createMessage({
  secretKey: <signed message>,
  revealAtBlock: <block number to be revealed>,
  reward: <reward in native token (in "wei")>,
  minFragments: <Shamir's k>,
  totalFragments: <Shamir's n>
});

[pfletcherhill]

kimono-cli spec

> PRIVATE_KEY=0x000... kimono reveal
> PRIVATE_KEY=0x000... kimono combine

[gkaemmer]

Or:

export PRIVATE_KEY=0xblah...
kimono reveal
kimono combine
kimono reveal:test -N 10

[mertcelebi]

kimono-cli spec will probably have a kimono signup or something like that to set the initial parameters of the user.

Maybe we can have a --malicious option for demo purposes