7 ms·

It's too bad it's not possible to store a secret in a contract (as far as I know). It would be interesting to store a private key that would be revealed only af

It's too bad it's not possible to store a secret in a contract (as far as I know). It would be interesting to store a private key that would be revealed only after a certain block number (let's say calculated to be 10 years in the future) as a sort of time capsule for files.

hodl 9y ago
You could with an oracle. Without an oracle I think this would be impossible. How will the chain know the key in 10 years but not Bob now?
- gwern 9y ago
  Time-locks: https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files You can implement them trapdoor/proof-of-work style using squaring or hashing with a reward that can be claimed only by publicly revealing the secret. Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc.
  - AlexCoventry 9y ago
    > Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc. How do you prevent abusing that by running it in a simulation in which the difficulty crashes?
    - gwern 9y ago
      The difficulty resets only every ~2 weeks of blocks, so tanking the difficulty still requires the investment of a vast amount of hash power in order to create a parallel chain. Secondly, as I understand witness encryption, if you're able to encode the hash rules as the condition, it would be easy to throw in an additional condition like 'all hash difficulties (# of leading zeros) must be >= difficulty XYZ', and simply ban large difficulty reductions. Which works as long as Bitcoin remains popular and justifying high-difficulty blocks, and if it crashes, your timelock is no longer secure so you don't want it to open and to failsafe.
      - Flenser 9y ago
        Would this still be possible if the consensus algorithm was changed to proof of stake?
        gwern 9y ago
        I'm not sure. Maybe you could change the condition to 'n successive stake signatures' but you would also have to model the stake-selection procedure in it... A property over a hash is fairly simple, but rerunning the whole PoS, essentially, is probably going to blow the witness encryption out into astronomical sizes unless someone can think of clever tricks?
- 0wing 9y ago
  What's the point of using the network then? Why not do everything more efficiently via the "oracle" server?
  - sova 9y ago
    Yes, exactly -- how does having some sort of external intervention into the protocol make the protocol more robust?
    - 0wing 9y ago
      You misunderstand. If a smart contract relies on an external data source from a normal server (oracle), then why even take the risk of deploying the smart contract? If you're using an oracle for a data source you might as well do everything on a normal database.
      - nileshtrivedi 9y ago
        By minimizing the role of the oracle, instead of relying on one entity, you can rely on the market. Anybody could be the oracle, they'd put their reputation/offer/price on sale and the stakeholders would select one as they wish. You're still trusting the selected oracle to behave honestly, but they will be operating in a very competitive market which hopefully would lead to better behaviour. They might cheat once, but it would be trivial to switch to a better oracle next time.
  - chrischen 9y ago
    This is the question that applies to about 99% of Dapps (at least the one that don't simply exist to serve other Dapps) so far.
simonebrunozzi 9y ago
You might be able to do this by having an Oracle as the intermediary - e.g. you write an Oracle that will reveal a private key at a certain point in the future, and the smart contract will be "activated" by the Oracle response. Problem is, where do you run an Oracle reliably?
rocqua 9y ago
Considering that the entirety of the blockchain is public, its impossible to actually put secrets into a smart-contract. You have to make the data available to all nodes that are actually running the smart contract data. An interesting approach to solving this is homomorphic encryption. This allows for alice to give Bob to encrypted numbers A and B. Bob can then compute an encrypted version of A + B using only the encrypted versions of A and B. This could be used by putting an encrypted secret on the blockchain, after which everyone can compute using that secret, but cannot see the actual outcome. This still won't help with random number generation though, because it remains deterministic.
- baby 9y ago
  I don't see how HE helps, but I've heard of VRF (verifiable random functions) and I think there is something there to do.
  - shadowfiend 9y ago
    The Dfinity team (https://dfinity.org https://dfinity.org) is using something like this to underly their blockchain implementation: they use threshold BLS signatures with groups of nodes to sign previous chain states and still be resilient against misbehavior and network intermittence. The signatures are random, but their correctness can be verified once they have been published. To support our secure key storage work, we'll be bringing a random beacon built on similar core concepts to the Ethereum chain for Keep.
- ozmbie 9y ago
  I think proposals such as MAST allow secret contracts, up until that part of the contract is executed (if it ever needs to be executed). https://medium.com/novamining/mast-smart-contracts-on-bitcoin-34b61ba67e19 https://medium.com/novamining/mast-smart-contracts-on-bitcoi...
Coxa 9y ago
temporal signatures http://www.cs.ox.ac.uk/files/9435/tempsig.pdf http://www.cs.ox.ac.uk/files/9435/tempsig.pdf
saalweachter 9y ago
You can imagine how this would work trivially with lawyers (acting as executors/trustees, as they often do). Take your secret key, split it into N pieces, create M parity pieces, RAID-style, for redundancy, distribute to M+N lawyers with instructions to reveal in 10 years. Lawyers put them into safe-deposit boxes for the duration, reveal in 10 years. A mildly eccentric person could even do this at scale: create a public/private keypair for every year for the next, say, century, publish the public keys, distribute the private key pieces with instructions to a wide range of lawyers. Members of the public can encrypt and publish data with the appropriate public key, assuming they trust the system.
- osteele 9y ago
  Shamir's Secret Sharing (SSS)[1] is a technique for doing this. SSS solves a harder problem than (my understanding of) RAID parity: that it requires not just k out of i pieces (your N and M+N) to assemble a secret, but also that no fewer than k pieces is sufficient, for arbitrary 0 < k < i. These days, SSS is commonly recommended (I don't know whether it's also commonly used) for storing cryptocurrency wallet backups. [1]: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
sova 9y ago
The only solution I can think of is evolving contracts that rewrite along the blockchain as they evolve, the most current write being the ~state of the "secret". Each evolving contract could, composing a variety of hashing functions, write frequently enough to the blockchain that it would be impossible to predict where it was going, but verify it along the way, historically. Call it an evolving hash function
- AgentME 9y ago
  You couldn't do that and have it evolve towards a predetermined value though (unless you make it predictable in a way that any viewer could also predict it).
  - sova 9y ago
    Yes you can, you have a hash that is not public and only segments are revealed and verified along the chain. Revealing the whole secret no longer makes it secret
    - AgentME 9y ago
      How would that work? Everything in the blockchain is public. You can't automatically have something be revealed in the blockchain; if that worked, what stops someone from simulating blocks being added to the blockchain and seeing what your contract does? Unless the decryption was somehow linked to the set of the proof-of-works involved, but I don't think anyone yet has an idea of how that could be done. You could later publish a decryption key into the blockchain that the contract uses, but I don't think that's "automatic" in the sense the earlier posts were hoping for.
      - sova 9y ago
        Right, you would need a secret that is never revealed on the blockchain itself, but you could verify that someone had it and posted hashes derived from it periodically on the blockchain.
shadowfiend 9y ago
We are working on this, in a sense, with Keep (https://keep.network https://keep.network). The actual storage is done off-chain, with an interaction on-chain, by incentivized nodes. The idea is to also support (initially limited) secure computation, like allowing a Keep to store a private key that can be used to cryptographically sign data via smart contract. Revealing the key, for dead-man-switch-type operations for example, is also a possibility.
tlrobinson 9y ago
Some sort of scheme using Shamir's Secret Sharing with a set of oracles, as long as it's not possible for the oracles to easily discover each other to collude to decrypt the secret on their own.
zvrba 9y ago
White-box cryptography. AFAIK, all attempted implementations got broken, but it's still an active research area.
- tuxxy 9y ago
  There are no provably secure white box crypto implementations. It's actually debated within the community _if_ one can even exist.

hodl 9y ago

You could with an oracle. Without an oracle I think this would be impossible. How will the chain know the key in 10 years but not Bob now?

gwern 9y ago
Time-locks: https://www.gwern.net/Self-decrypting-files https://www.gwern.net/Self-decrypting-files You can implement them trapdoor/proof-of-work style using squaring or hashing with a reward that can be claimed only by publicly revealing the secret. Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc.
- AlexCoventry 9y ago
  > Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc. How do you prevent abusing that by running it in a simulation in which the difficulty crashes?
  - gwern 9y ago
    The difficulty resets only every ~2 weeks of blocks, so tanking the difficulty still requires the investment of a vast amount of hash power in order to create a parallel chain. Secondly, as I understand witness encryption, if you're able to encode the hash rules as the condition, it would be easy to throw in an additional condition like 'all hash difficulties (# of leading zeros) must be >= difficulty XYZ', and simply ban large difficulty reductions. Which works as long as Bitcoin remains popular and justifying high-difficulty blocks, and if it crashes, your timelock is no longer secure so you don't want it to open and to failsafe.
    - Flenser 9y ago
      Would this still be possible if the consensus algorithm was changed to proof of stake?
      - gwern 9y ago
        I'm not sure. Maybe you could change the condition to 'n successive stake signatures' but you would also have to model the stake-selection procedure in it... A property over a hash is fairly simple, but rerunning the whole PoS, essentially, is probably going to blow the witness encryption out into astronomical sizes unless someone can think of clever tricks?
0wing 9y ago
What's the point of using the network then? Why not do everything more efficiently via the "oracle" server?
- sova 9y ago
  Yes, exactly -- how does having some sort of external intervention into the protocol make the protocol more robust?
  - 0wing 9y ago
    You misunderstand. If a smart contract relies on an external data source from a normal server (oracle), then why even take the risk of deploying the smart contract? If you're using an oracle for a data source you might as well do everything on a normal database.
    - nileshtrivedi 9y ago
      By minimizing the role of the oracle, instead of relying on one entity, you can rely on the market. Anybody could be the oracle, they'd put their reputation/offer/price on sale and the stakeholders would select one as they wish. You're still trusting the selected oracle to behave honestly, but they will be operating in a very competitive market which hopefully would lead to better behaviour. They might cheat once, but it would be trivial to switch to a better oracle next time.
- chrischen 9y ago
  This is the question that applies to about 99% of Dapps (at least the one that don't simply exist to serve other Dapps) so far.

simonebrunozzi 9y ago

You might be able to do this by having an Oracle as the intermediary - e.g. you write an Oracle that will reveal a private key at a certain point in the future, and the smart contract will be "activated" by the Oracle response. Problem is, where do you run an Oracle reliably?

rocqua 9y ago

Considering that the entirety of the blockchain is public, its impossible to actually put secrets into a smart-contract. You have to make the data available to all nodes that are actually running the smart contract data. An interesting approach to solving this is homomorphic encryption. This allows for alice to give Bob to encrypted numbers A and B. Bob can then compute an encrypted version of A + B using only the encrypted versions of A and B. This could be used by putting an encrypted secret on the blockchain, after which everyone can compute using that secret, but cannot see the actual outcome. This still won't help with random number generation though, because it remains deterministic.

baby 9y ago
I don't see how HE helps, but I've heard of VRF (verifiable random functions) and I think there is something there to do.
- shadowfiend 9y ago
  The Dfinity team (https://dfinity.org https://dfinity.org) is using something like this to underly their blockchain implementation: they use threshold BLS signatures with groups of nodes to sign previous chain states and still be resilient against misbehavior and network intermittence. The signatures are random, but their correctness can be verified once they have been published. To support our secure key storage work, we'll be bringing a random beacon built on similar core concepts to the Ethereum chain for Keep.
ozmbie 9y ago
I think proposals such as MAST allow secret contracts, up until that part of the contract is executed (if it ever needs to be executed). https://medium.com/novamining/mast-smart-contracts-on-bitcoin-34b61ba67e19 https://medium.com/novamining/mast-smart-contracts-on-bitcoi...

Coxa 9y ago

temporal signatures http://www.cs.ox.ac.uk/files/9435/tempsig.pdf http://www.cs.ox.ac.uk/files/9435/tempsig.pdf

saalweachter 9y ago

You can imagine how this would work trivially with lawyers (acting as executors/trustees, as they often do). Take your secret key, split it into N pieces, create M parity pieces, RAID-style, for redundancy, distribute to M+N lawyers with instructions to reveal in 10 years. Lawyers put them into safe-deposit boxes for the duration, reveal in 10 years. A mildly eccentric person could even do this at scale: create a public/private keypair for every year for the next, say, century, publish the public keys, distribute the private key pieces with instructions to a wide range of lawyers. Members of the public can encrypt and publish data with the appropriate public key, assuming they trust the system.

osteele 9y ago
Shamir's Secret Sharing (SSS)[1] is a technique for doing this. SSS solves a harder problem than (my understanding of) RAID parity: that it requires not just k out of i pieces (your N and M+N) to assemble a secret, but also that no fewer than k pieces is sufficient, for arbitrary 0 < k < i. These days, SSS is commonly recommended (I don't know whether it's also commonly used) for storing cryptocurrency wallet backups. [1]: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

sova 9y ago

The only solution I can think of is evolving contracts that rewrite along the blockchain as they evolve, the most current write being the ~state of the "secret". Each evolving contract could, composing a variety of hashing functions, write frequently enough to the blockchain that it would be impossible to predict where it was going, but verify it along the way, historically. Call it an evolving hash function

AgentME 9y ago
You couldn't do that and have it evolve towards a predetermined value though (unless you make it predictable in a way that any viewer could also predict it).
- sova 9y ago
  Yes you can, you have a hash that is not public and only segments are revealed and verified along the chain. Revealing the whole secret no longer makes it secret
  - AgentME 9y ago
    How would that work? Everything in the blockchain is public. You can't automatically have something be revealed in the blockchain; if that worked, what stops someone from simulating blocks being added to the blockchain and seeing what your contract does? Unless the decryption was somehow linked to the set of the proof-of-works involved, but I don't think anyone yet has an idea of how that could be done. You could later publish a decryption key into the blockchain that the contract uses, but I don't think that's "automatic" in the sense the earlier posts were hoping for.
    - sova 9y ago
      Right, you would need a secret that is never revealed on the blockchain itself, but you could verify that someone had it and posted hashes derived from it periodically on the blockchain.

shadowfiend 9y ago

We are working on this, in a sense, with Keep (https://keep.network https://keep.network). The actual storage is done off-chain, with an interaction on-chain, by incentivized nodes. The idea is to also support (initially limited) secure computation, like allowing a Keep to store a private key that can be used to cryptographically sign data via smart contract. Revealing the key, for dead-man-switch-type operations for example, is also a possibility.

tlrobinson 9y ago

Some sort of scheme using Shamir's Secret Sharing with a set of oracles, as long as it's not possible for the oracles to easily discover each other to collude to decrypt the secret on their own.

zvrba 9y ago

White-box cryptography. AFAIK, all attempted implementations got broken, but it's still an active research area.

tuxxy 9y ago
There are no provably secure white box crypto implementations. It's actually debated within the community _if_ one can even exist.