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.
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.
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).
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.
> 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.
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.
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.
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.
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 :)
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.
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.
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.
How to schedule an outgoing email through Gmail:
https://support.google.com/mail/answer/9214606?hl=en&co=GENI...
through Outlook
https://support.microsoft.com/en-us/office/delay-or-schedule...
through Apple Mail
https://www.igeeksblog.com/how-to-schedule-email-on-iphone-i...
through Proton Mail