5 ms·
Also, if they really want to make this as trust-free as possible, they could use ZKCP [0][1] to make the payment stage and the reveal stage atomic - the moment
by nadaviv 10y ago
Also, if they really want to make this as trust-free as possible, they could use ZKCP [0][1] to make the payment stage and the reveal stage atomic - the moment the payment is taken by the auctioneers, the decryption key is revealed (using hash-locked transactions and zero knowledge proofs).
This, however, won't work with their penny auction style bids.
[0] https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
[1] https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/ https://bitcoincore.org/en/2016/02/26/zero-knowledge-conting...
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- EthanHeilman 10y agoThey could even use the blockchain as a source of randomness to choose which chunks of the encrypted file they reveal for free.
- nadaviv 10y agoThat's exactly what my parent comment suggested :-)
- EthanHeilman 10y agoOpps didn't see that. =) Using hashes like you are suggesting you wouldn't even need ZK proofs. There is a simple trick you could do with the keys such that you post a single 128 value which is checkable with a tree of OP_HASH and OP_DUPs and would, with very high probability, reveal all the keys. As pointed out below the problem with this scheme is that you could hash the same files with a little randomness added and make it look like you have more data to sell than you do. I think with some GC-based ZK proofs you could show this isn't true and each file is legitimately different (for example demonstrating randomly selected bit relationships or word frequencies).