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

[lxgr]

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.

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