Author Topic: Blockchain RNG with DPOS  (Read 14436 times)

0 Members and 1 Guest are viewing this topic.

Offline amencon

  • Sr. Member
  • ****
  • Posts: 227
    • View Profile
Excellent, thanks Toast and Byte.

Offline bytemaster

So if I understand correctly, assuming one delegate is honest out of 100, this should give us a steady stream of random numbers to use every 15-30 seconds?

What would this random number look like (depends on hash function used?) and how would it be applied to various games?

For instance in a simple lotto how would you correlate a winning ticket with the random number hash streamed by the delegates?

Looks promising, thanks.

RANDOM_NUMBER would be a SHA256 hash (32 bytes)

HASH(RANDOM_NUMBER+TICKET_NUMBER) % (TOTAL_TICKET_SALES/YOUR_TICKET_PRICE)  would produce a range from 0 to your probability of winning.   If you purchased 1% of the tickets then it would be from 0 to 100

If the number produced is 0 then you win... otherwise you lose.

« Last Edit: April 16, 2014, 01:07:00 am by bytemaster »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
So if I understand correctly, assuming one delegate is honest out of 100, this should give us a steady stream of random numbers to use every 15-30 seconds?

What would this random number look like (depends on hash function used?) and how would it be applied to various games?

For instance in a simple lotto how would you correlate a winning ticket with the random number hash streamed by the delegates?

Looks promising, thanks.

The most basic version has the RNG give you, say, 128 random bits, but you can always use it to seed a pre-determined PRNG to get as many bits as you need.
For a basic lottery ticket: To get a ticket that is valid for one block and has probability p of winning you just define a winner to be any ticket with (block_hash XOR ticket_purchase_tx_hash < p*(2^128)).

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline amencon

  • Sr. Member
  • ****
  • Posts: 227
    • View Profile
So if I understand correctly, assuming one delegate is honest out of 100, this should give us a steady stream of random numbers to use every 15-30 seconds?

What would this random number look like (depends on hash function used?) and how would it be applied to various games?

For instance in a simple lotto how would you correlate a winning ticket with the random number hash streamed by the delegates?

Looks promising, thanks.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
 +5%, simple and beautiful...

So, if we require the least security level of "even one of the 100 delegates is honest then the resulting R is truly random", I think we should draw the jackpots using 100th block's R when there are 100 blocks following since ticket purchase transactions are accepted, right?

Is "Block[HEAD].revealed_secret" the S[n-1] generated by HEAD's delegate in last round (each round 100 delegates' blocks)? Brilliant!

Thanks.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

With DPOS we have 100 nodes that should have near 99.9% uptime which means we can reliably produce a secure random number assuming just 1 out 100 is honest.

Code: [Select]
struct Block
{
   hash  secret;  // HASH( S[n] ) where n is the index in the array of secrets generated by this delegate
   hash  revealed_secret; // S[n-1]
};

For each block add a header field containing   HASH(S[n]) where S[n] is a secret to be revealed next time this delegate produces a block.   Also include in the header S[n-1].

We now have a stream of secrets being revealed once per block (15 to 30 seconds)... from this stream of secrets we can generate the random number R for the block as:
Code: [Select]
if( first_block_produced_by_delegate ) then Block[HEAD].revealed_secret = 0
ASSERT( HASH( Block[HEAD].revealed_secret) == GetLastBlockProducedByDelegate(Block[HEAD].delegate_id).secret )
R = HASH( Block[HEAD].revealed_secret )
for( uint32_t i = 1; i < 100; ++i )
{
     R = HASH( Block[HEAD-i].revealed_secret + R) // where + is concat
}

R = random number generated this block...

Every R is calculated from secrets introduced by all 100 delegates that were revealed after they committed to them.  If even one of the 100 delegates is honest then the resulting R is truly random.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.