[KMnO4]

> Needlessly tied to crypto

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.

[lxgr]

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).

[DennisP]

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.

[lxgr]

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.

[DennisP]

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.

[lxgr]

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 :)

[DennisP]

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.

[insapio]

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.

[lxgr]

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.

[jrflowers]

>This is an absolutely perfect use of Ethereum.

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

https://proton.me/support/schedule-email-send

[Saavedro]

there's literally no way to implement this on ethereum, smart contracts can't store secrets, all of their state is public.

[DennisP]

But they can store hashes of SSS shards, and coordinate the revealing of secrets by individuals who don't have access to those secrets on their own.

[panzi]

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.