Let’s unpack that. By “crypto” you probably mean cryptocurrency, but let’s not forget it’s the same crypto as in cryptography. You absolutely want cryptography involved in something like this for obvious reasons.
You’ve probably also heard the term blockchain and immediately think of speculative currency futures. So throw that to the wind for a second and imagine how useful a distributed list of records linked and verifiable with cryptographic hash functions would be for this project.
Then finally, run this all in a secure and autonomous way so that under certain conditions the action of releasing the key will happen. In other words: a smart contract.
This is an absolutely perfect use of Ethereum. If you think cryptocurrencies are useless, then consider that projects like this are what give them actual real world use cases.
How can a smart contract “keep a secret” in a trustless way?
Isn’t effectively all the trust still in the party releasing it at the right time, or not releasing it otherwise? If so, is the blockchain aspect anything other than decentralization theater?
I guess one thing you can do with a blockchain is keeping that trusted party honest and accountable for not releasing at the desired date and in the absence of a liveness signal, but I’m not sure that’s the biggest trust issue here (for me, them taking a look without my permission would be the bigger one).
A smart contract can still help. Use Shamir's secret sharing to split the decryption key. Each friend gets a key fragment, plus the address of the smart contract that combines them.
Now none of your friends have to know each other. No friend can peek on their own, they can't conspire with each other, and if one of them gets compromised, it doesn't put the others at risk. It's basically the same idea as "social recovery wallets," which some people use to protect large amounts of funds.
If you don't have any friends then as you suggest, a conceivable infrastructure would be to pay anonymous providers to deposit funds in the contract, which they would lose they don't provide their key fragment in a timely manner after the liveness signal fails. For verification, the contract would have to hold hashes of the key fragments. Each depositor would include a public key with the deposit, which the whistleblower can use to encrypt and post a key fragment. (Of course the vulnerability here is the whistleblower's own key.)
The contract should probably also hold a hash of the encrypted document, which would be posted somewhere public.
Ah, putting the key under shared control of (hopefully independent) entities does sound like a useful extension.
But still, while this solves the problem of availability (the shardholders could get their stake slashed if they don't publish their secrets after the failsafe condition is reached, because not publishing something on-chain is publicly observeable), does it help that much with secrecy, i.e. not leaking the secret unintentionally and possibly non-publicly?
I guess you could bet on the shardholders not having an easy way to coordinate collusion with somebody willing to pay for it, maybe by increasing the danger of defection (e.g. by allowing everyone that obtains a secret without the condition being met to claim the shardholder's stake?), but the game theory seems more complicated there.
I guess you should also slash the stake if they submit the key in spite of the liveness function getting called. If the contract doesn't require the depositor to be the one to submit the key, then there's an incentive to avoid revealing the secret anywhere.
A well-funded journalist could pay the bonds plus extra. I think the only defense would be to have a large number of such contracts, many of them without journalistic value.
Distributing the key among trusted friends who don't know each other seems like the best option.
Yeah, that's what I meant by allowing anyone to claim the stake upon premature/unjustified release.
That would incentivize some to pose as "collusion coordinators" ("let's all get together and see what's inside") and then just claim the stake of everybody agreeing. But if somebody could establish a reputation for not doing that and paying defectors well in an iterated game...
> Distributing the key among trusted friends who don't know each other seems like the best option.
Yeah, that also seems like the most realistic option to me. But then you don't need the blockchain :)
Well the blockchain still helps with friends, just because it's a convenient and very censorship-resistant public place to post the keys without having to know each other. But there are plenty of other ways to do it.
For the friendless option, don't return all the stake if secrets are submitted despite proof of life. Instead, return a small portion to incentivize reporting, and burn the rest.
Wouldn't you want the incentive for false coordinators to be as strong as possible?
Otherwise, the coordinator has more to gain by actually coordinating collusion (i.e. secretly pay off shardholders, reassemble the key, monetize what's in it, don't do anything on-chain) than by revealing the collusion in non-iterated games.
Ok to sum up what I'm thinking: As a stakeholder, I pay a large deposit. I get an immediate payment, and my deposit back after a year. Proof of life happens monthly. If nobody reveals my key after proof of life goes missing, I lose my deposit. If anyone reveals my key despite proof of life in the past month, then 99% of my deposit is burned, and the revealer gets 1% of the deposit.
If I understand right, your concern with this is that the coordinator could pay off shardholders to reveal their shards directly to the coordinator, avoid revealing shards to the contract, and then the shardholders can get their money back.
However, the shardholders do have to worry that the coordinator will go ahead and reveal, collecting that 1% and burning the rest. Or it could be 10%, or 50%, whatever seems sufficiently tempting to coordinators....given the burn risk, the coordinator has to pay >100% to shardholders regardless (assuming non-iterated).
Maximum theft temptation to coordinators is 100% return, but this removes the financial loss to shardholders who simply reveal prematurely on their own. But maybe even losing 10% is sufficient to dissuade that, and then you have to trust coordinators with access to 90% of your funds.
And all this, hopefully, is in the context of the general public having no idea how much economic value the document in question has to a coordinator. In fact, if coordinators routinely pay shardholders more than their deposits, it would pay people to put up lots of worthless documents and collect the payments.
You can create a timelock smart contract requiring a future state of the blockchain to have been reached. Once that time has been reached, you can freely execute the function on the contract to retrieve the information. Tested it years ago, to lock up 1 ETH in essentially a CD for a year.
The trust is held in your own code implementation of the contract and that ETH will continue to exist and not be hard-forked or Shor'd or something.
That's not how it works: You can fundamentally not store secrets in smart contracts, you do need off-chain agents for that. (How would a smart contract prevent me from reading anything published on a blockchain?)
> Tested it years ago, to lock up 1 ETH in essentially a CD for a year.
That's not locking up a secret, that's locking up value.
But it seems like there might be a game theoretic way to ensure that, as your sibling commenter has outlined.
Yeah, but I don't think you need proof of work for this. Something more akin to git with commit signing should work. The thing with cryptocurrencies is that there isn't anything of real value in the Blockchain. If you view git as Blockchain there is something of real value in it: the code. And here the encrypted data.
Although I don't know how you could make any kind of Blockchain containing data to be released at some condition and no way to release it before? If it's all public in the Blockchain it's all already public. You need atrusted authority that has a secret key to unlock the data. And if you have that all that Blockchain stuff is utterly redundant anyway.
