<div dir="ltr"><div class="gmail_extra">nack -- not secure. <br><br>OP_PRANDOM also adds extra validation overhead on a block potentially composed of transactions all spending an OP_PRANDOM output from all different blocks.<br><br>I do agree that random numbers are highly desirable though.<br><br>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.<br><br>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. <br><br>(sorry to those of you seeing this twice, my first email bounced the list)</div><div><br><div><div><div><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div>
</div>
<br><div class="gmail_quote">On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Matthew,<div><br></div><div>You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements Project. It aims to achieve a similar goal.<br><br>Code is in the `alpha` branch [2].</div><div><br></div><div>[1]: <a href="https://www.elementsproject.org/elements/opcodes/" target="_blank">https://www.elementsproject.org/elements/opcodes/</a><br>[2]: <a href="https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305" target="_blank">https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305</a></div></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>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. <br><br></div><div>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.<br><br></div><div>I need to sleep on this for now but let me know if anyone has any better ideas.<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <span dir="ltr"><<a href="mailto:jl2012@xbt.hk" target="_blank">jl2012@xbt.hk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div><span><div><br></div><div><blockquote type="cite"><div dir="ltr"><p style="margin-bottom:0in;line-height:100%"><br>
</p><p style="margin-bottom:0in;line-height:100%">== Security</p><p style="margin-bottom:0in;line-height:100%">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.</p></div></blockquote></div><br></span></div></blockquote></div><br></div></div></div><span>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</span></blockquote></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>