2

I've been trying to make a random number generator that doesn't need to be outsourced like Oraclize or break down at scale like RanDAO where n deposits gives 2^n possible manipulations for the random number.

What I was thinking is that you could use the same concept that gives the blockchain value to generate a random number.

So if you take amount of block confirmations needed for a transaction to be secure and use that many blocks to create a portion of a random number (based on the blockhash), you could effectively create a random number equal to that of even odds with enough sets.

As an example, let's say it's 6 confirmations for a transaction to be secure. This means that a miner can't mine 6 blocks in succession (otherwise there would be double spend attacks and no assurance in the blockchain, right?)

For example:

6 confirmation length 
Base of 2
Targeted random number range of >1000

With 6 consecutive blocks, a miner would be able to manipulate the hash of the first 5 but not the 6th, giving them a 1/2 chance of getting their desire output.

Block 1: 0 (Manipulated by Miner)
Block 2: 0 (Manipulated by Miner)
Block 3: 0 (Manipulated by Miner)
Block 4: 0 (Manipulated by Miner)
Block 5: 0 (Manipulated by Miner)
Block 6: 1/2 Chance of the Miner's desired output

So for a random number range of >1000, you would need 10 6-blockhash sets (60 total hashes) to give a miner trying to manipulate the block a 1 / (2 ^ 10) or 1/1024 chance.

What I'm trying to achieve is to have a random number in a certain range, and using the number of block confirmations considered secure to give the same or better odds to a miner trying to manipulate said number.

Is my rationale right here or am I missing something critical?

Sorry if my explanation isn't great, but here's an example in solidity I've made called the Blockchain Assured Random Number Generator (BARN Generator) where you basically have to give it the base, ending block, confirmation length, and number of sets (base^number of sets should be >= the desired random number range).

contract BARNGenerator {

    function BARNGenerator() {

    }

    function getRandomNumber(
        uint _base, 
        uint _endBlock, 
        uint _confirmationLength,
        uint _blockSets) returns(uint) {

        uint[] numberArray;        
        uint totalBlocks = _blockSets * _confirmationLength;
        if (_endBlock - totalBlocks < block.number) {revert();}
        for (uint i; i < totalBlocks; i++) {
            numberArray.push(uint(block.blockhash(_endBlock - i)) % _base);
        }
        return convertToDecimal(numberArray, _base);
    }

    function convertToDecimal(uint[] bitArray, uint _base) returns(uint) {
        uint decimalSum = 0;
        for (uint i=0; i< bitArray.length; i++) {
            decimalSum += bitArray[i] * _base ** (i + 1);
        }
        return decimalSum;
    }

}
Kaizen Bran
  • 51
  • 1
  • 4
  • Look at this question https://ethereum.stackexchange.com/questions/419/when-can-blockhash-be-safely-used-for-a-random-number-when-would-it-be-unsafe. Adding more block hashes do not increase the safety of the random number generator, if a miner can manipulate only one it should be enough. – Ismael Jul 15 '17 at 02:19
  • But isn't that just for a hash where the one change can manipulate to a specified value, whereas if you are using a series of successive hashes, having the ability to manipulate one block doesn't guarantee a specific value? – Kaizen Bran Jul 15 '17 at 02:27
  • The blocks hashes are already know at the time a miner is processing a transaction, so they are not random at all. – Ismael Jul 15 '17 at 02:41
  • Yeah, that's the assumption I'm making. A miner can manipulate the hash of up to n - 1 consecutive blocks, but not n blocks where n is the number of blocks for a secure transaction (6 blocks I believe for ethereum). So they have 1/base chance of getting that desired value given n consecutive blocks. – Kaizen Bran Jul 15 '17 at 02:46
  • If you are mining block n then you know all block up to n - 1. In a blockchain every block has its parent block hash included as part of the header. – Ismael Jul 15 '17 at 02:50
  • Yeah, but the miner of block n doesn't have control over n0 to n - 1. So they only have the base degrees of freedom. It's not true randomness, but its randomness to a degree where a miner can only have odds equal to or less than that of a random guess. If you mined just the last block of each 6-block set you would have 1 in 2^5^10 chance of getting some predefined number. – Kaizen Bran Jul 15 '17 at 03:01
  • If you are mining block n, then you know for sure blocks 0 to n-1. The previous blocks are not random. The only uncertainity is block n, everything else is know. – Ismael Jul 15 '17 at 03:37
  • The idea is that if you can't manipulate it enough to get some predefined value as a whole, then there is no reason to manipulate it, and therefore it's essentially pseudorandomness. This isn't meant to be used 1 block ahead hence the: if (_endBlock - totalBlocks < block.number) {revert();}. So if you have to define a number at the current block, the number generated by _endblock can't be manipulated enough to get the number you defined at the start. – Kaizen Bran Jul 15 '17 at 03:57
  • It is not that your algorithm can't be manipulated enough.It is your algorithm is not random at all. – Ismael Jul 15 '17 at 04:51
  • So if a miner isn't manipulating the hash to get a certain outcome then uint(block.blockhash(x)) % y still isn't random? – Kaizen Bran Jul 15 '17 at 05:24

0 Answers0