Then what about Zero-knowledge proofs? They take long to compute but are mostly fast to verify. Use it with any algorithm behind the scenes that you want, maybe with a KDF or something.
Even with a few hundred iterations only organizations that already can afford to do a 51% attack can pull it off, and that's assuming you let them pick which block themselves to base this on, and get to make that choice after they mined the block. In practice you really just need to specify the full hash of the latest block in the blockchain, as you can't really know it more than 10 minutes in advance anyway. It is a chain after all, forks in the chain are rejected unless their proof-of-work represents more computational power than the current one, so that there only are one canonical chain at any point in time. - Sent from my phone Den 11 nov 2013 21:45 skrev "CodesInChaos" <[email protected]>: > On Mon, Nov 11, 2013 at 8:14 PM, Natanael <[email protected]> wrote: > > Proof-of-work, just like Bitcoin itself uses for hashing? > No this idea isn't about proof of work. The idea is delaying the > computation result, preventing a miner from picking a value. > If the computation takes an hour on the fastest available computer and > isn't parallelizable, then a miner can't influence > the unpredictable value (unless they have 51%). > > With slightly weaker security requirements iterating only a few > million times would be decent as well, since attempting to > influence the value would result in a performance hit a competitive > miner can't afford. >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
