nack -- not secure.
OP_PRANDOM also adds extra validation overhead on a block potentially composed of transactions all spending an OP_PRANDOM output from all different blocks.
I do agree that random numbers are highly desirable though.
I think it would be much better for these use cases to add OP_XOR back and then use something like Blum's fair coin-flipping over the phone. OP_XOR may have other uses too.
I have a write-up from a while back which does Blum's without OP_XOR using OP_SIZE for off-chain probabilistic payments if anyone is interested. No fork needed, but of course it is more limited and broken in a number of ways.
(sorry to those of you seeing this twice, my first email bounced the list)On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:Matthew,You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements Project. It aims to achieve a similar goal.
Code is in the `alpha` branch [2].On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:_______________________________________________Good point, to be honest. Maybe there's a better way to combine the block hashes like taking the first N bits from each block hash to produce a single number but the direction that this is going in doesn't seem ideal.I just asked a friend about this problem and he mentioned using the hash of the proof of work hash as part of the number so you have to throw away a valid POW if it doesn't give you the hash you want. I suppose its possible to make it infinitely expensive to manipulate the number but I can't think of anything better than that for now.I need to sleep on this for now but let me know if anyone has any better ideas.On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012@xbt.hk> wrote:Using the hash of multiple blocks does not make it any safer. The miner of the last block always determines the results, by knowing the hashes of all previous blocks.
== Security
Pay-to-script-hash can be used to protect the details of contracts that use OP_PRANDOM from the prying eyes of miners. However, since there is also a non-zero risk that a participant in a contract may attempt to bribe a miner the inclusion of multiple block hashes as a source of randomness is a must. Every miner would effectively need to be bribed to ensure control over the results of the random numbers, which is already very unlikely. The risk approaches zero as N goes up.
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev