hillstreetlabs/kimono

👘 Opening the kimono one time-lock at a time

kimono's Issues

Update the indexOf implementation to for revealers that "advertise" frequently

@dmdque for updateEligibleRevealer

[Feature] WebAssembly Support for Shamir Secret Sharing

uPort recently bountied the shamir-secret-sharing for WebAssembly, and it's almost complete.

Might be a good addition for this project?

3box/sss-wasm#2

Pulling staked funds

Problem

Since revealers can participate in any number of secret revealing cycles, it's impossible to stake everything upfront.

Approach

Postpone the transferring of staked funds until the "propose" step, when a creator selects n nodes to participate in the scheme.

Unfortunately this will require the client to query all nodes to check that they have the correct balance and approved amount, or risk failure.

Look into the usage of "nonReentrant" across the contract

v0.1 spec

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.

Proposal and Creation

We want to ensure that the staked funds corresponds with the committed messages (which contain all the hashes of the fragments).

There are two approaches:

1. Make the "propose" and "create" steps atomic. Since createMessage consumes the hash of the IPFS location, the file must have already been uploaded (complete with all the fragments encrypted with revealers' public keys.) This requires the revealers to be "pre-selected" before performing the propose-create atomic action.

2. Do some internal accounting to keep track of which funds have been staked for a secret revealing scheme that is actually active.

We're going with the simpler approach (1.) for now.