RNG Ledger-Proof, request to return RNG from a uint range instead of bytes range.

[Duncan-Brain]

Whether it be for voting, gambling, jury duty or random draws -- typically you have a set of 'tickets' and have to randomly choose one or multiple to 'win'. Returning a random number from a user specified max value (range) instead of _nRandomBytes would be more useful from my perspective as an Ethereum contract developer.

Problem
Right now (under the current N random bytes ledger proof) I have two basic options to control the randomness and fairness of who wins:

1. Use rejection sampling in the contract- which costs the contract user more $$ (for detection of rejection and re-sampling)
2. Use of a large N (up to 32) - which requires understanding that a small statistically insignificant inequality exists between tickets (not always easy to explain to contract users)

I have outlined an example problem in this Stack question: https://ethereum.stackexchange.com/questions/65908/how-to-limit-n-bytes-to-value-range-using-oraclize-ledger-proof-random-number

Solutions?
If some rejection sampling was added as a update to the existing random number data source or as a separate offering it would help, what I can only assume is, the majority of use cases. I would imagine changing the Oraclize API's to handle rejection sampling would be not good. But I wonder if the secure application on the ledger itself could handle the rejection? ... Much in the same way as how the nbytes is truncated in the query execution in the secure software. These contracts would be more generally understandable about fairness (Problem 2), cost efficient (Problem 1), and code efficient (Problem 1).

[gskapka]

Hi @Duncan-Brain - thanks for opening the issue per your discussion with @D-Nice and in our support channel, plus him & myself on your stack overflow question.

Like @D-Nice mentioned, we'll leave this open here and tag it appropriately so that when it comes round to the next update we can take this onboard.

We won't reiterate here any of what's already been discussed - interested observers may find the Stack question here and our Gitter channel here instead.