OP_RAND an OP CODE for random numbers

Draft
1

Motivation

Sources of randomness in computation is an extremely subtle in complex art. In most OS implementations this starts with an entropy pool. Entropy pools typically gather peripheral device data, such as mouse movements, during a boot sequence or CPU usage etc and then use several mixing / stirring techniques to improve the quality of the randomness.

Windows entropy pools appear to be slightly stronger than Linux systems but remain largely closed source while Linux systems are transparent about how entropy pools are built, stored and measured as seen from this extract from Unix.stackexchange thread.

" The only time when /dev/urandom is problematic is when a system doesn’t have enough entropy yet, for example on the first boot of a fresh installation, after booting a live CD, or after cloning a virtual machine. In such situations, wait until /proc/sys/kernel/random/entropy_avail reaches 200 or so. After that, you can use /dev/urandom as much as you like."

Often times block header hash values offer a potentially good source of randomness for things like a two man lottery contract, there is no security level guarantee. More exciting is the potential of initialize ECC curves with trustworthy “nothing up my sleeve” numbers at some future point in time.

AIBlock block headers have exceptionally strong random seeds embedded in them. The AIBlock explorer shows them as UNiCORN seeds, referring the Prof Arjen Lenstra’s UNiCORN or UN< i >COntestible Random Numbers

The original Cryptology ePrint Archive paper details both the generation of a random number seed with measurable security levels and then goes on to detail how to use them in setting up trustworthy ECC services.

Thus in principle one can consider constructing an OP CODE that could retrieve a pre-existing block header and its associated UNiCORN seed. This is possible on AIBlock because of how the multi node type architecture processes blocks in such a way that we do not suffer from blockchain blindness

Next the OP CODE would allow for two different PARAMs, SEED and CIPHER. Both Cha-Cha 20 and FORTUNA should be considers for block and stream RNG schemes.

2

Is the intent of this for the op code to produce the same random number for everyone validating for a particular context (i.e. block height?). This is essential for consensus. An op code like this requires a very strict a definition of the context in which it operates that can be consistently understood by any peer in the network at any time.

1 Like
3

Precisely. Imagine a simple two man lottery contract. If the least significant bit (LSB) of some OP_RAND output is 1 then Mr. X wins 1 AIBCoin else Mrs. Y wins 1 AIBCoin.

With reference to block height and some CSPRNG, every miner should be able to validate the outcome.

The difficulty here is in dealing with forks or shifts in consensus resulting in a UNiCORN change to the block header meaning that an associated script containing OP_RAND which once passed as TRUE, now evaluates as FALSE.

As with the 100 block height lock on mined coins, OP_RAND should come with a default block-height lock to ensure that variations in consistence due to consensus are settled before the script unlocks and the resource is spendable.

It might be necessary to go as far as putting in a “second” height lock that measures onspends or children to a transaction containing an OP_RAND. Something like “IF this transaction has more than 3 on-spends then it is default TRUE, ELSE if LSB of UNiCORN in Block height 1123 == 1 AND more than 100 blocks have passed then Mr. X gets AIBCoin.”

The co-condition of 100 blocks lock time on its own is probably sufficient to handle forks or consensus shifts but the probabilistic nature of consistency eventually is the issue to mitigate for using time.

4

That implies that transactions should have some way of tagging their outputs as height locked. It could be as simple as the execution of an OP_RAND in an input requires that all outputs must begin with <future_height> OP_CLTV or the OP_RAND will fail.

Bear in mind that the equivilent of 100 blocks in Bitcoin would be 2000 blocks in AIBLock