[148188] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] NIST Randomness Beacon

daemon@ATHENA.MIT.EDU (Adam Back)
Sat Nov 16 15:50:12 2013

X-Original-To: cryptography@metzdowd.com
Date: Tue, 12 Nov 2013 10:10:13 +0100
From: Adam Back <adam@cypherspace.org>
To: CodesInChaos <codesinchaos@gmail.com>
In-Reply-To: <CAK9dnSws6a9zeQLJbVzhjE=dsspdr8dNYgG3_H2MTA2DOX9-QA@mail.gmail.com>
Cc: cpunks <cypherpunks@cpunks.org>, Adam Back <adam@cypherspace.org>,
	Cryptography Mailing List <cryptography@metzdowd.com>,
	"cryptography@randombit.net" <cryptography@randombit.net>,
	Andy Isaacson <adi@hexapodia.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

(Top posted, so sue me, my text explains itself without the history).

Thats a big cc list.  I think you could create a beacon with bitcoin hash
chain by having miners reveal a preimage for 6 old, consecutive blocks where
the newest of the 6 old blocks is itself 6-blocks confirmed.  (ie reveal
preimage on blocks 7-12.  The xor of those preimages defines a rolling
beacon (new output every block, just with reference to blocks 7-12 relative
to the current block depth).

The security against insider foreknowledge is not fantastic, as its relating
to the trustworthiness of the 6 random miners (which have probabilty of
winning relating to hashpower, which doesnt always relate to
trustworthiness).

Adam

On Mon, Nov 11, 2013 at 05:42:54PM +0100, CodesInChaos wrote:
>On Sun, Nov 10, 2013 at 9:54 AM, Andy Isaacson <adi@hexapodia.org> wrote:
>> For example, suppose you use the low bits of the bitcoin blockchain
>> hash.  An attacker with 10% of the hash power could probabilistically
>> attack such a system by chosing blocks with a specific value in those
>> bits;
>
>This can be avoided by running a sequential computation based on that hash. 
>For example by hashing it 2^40 times.  Obvious downside is that verifying
>that the computation was performed correctly is just as expensive (but
>parallelizable).
>
>Perhaps there is a function that's sequential and slow in one
>direction and fast in the reverse direction.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post