<div dir="ltr">Bitcoin Beacon paper relevant here<br><br>Basically is suggest using deciding a random bit on the majority 1s or 0s of lsb bits taken from last block hashes.<br><br>Iddo Bentov∗ Technion, Ariel Gabizon,  David Zuckerman<br><br>We examine a protocol πbeacon that outputs unpredictable and publicly verifiable randomness, meaning that the output is unknown at the time that πbeacon starts, yet everyone can verify that the output is close to uniform after πbeacon terminates. We show that πbeacon can be instantiated via Bitcoin under sensible assumptions; in particular we consider an adversary with an arbitrarily large initial budget who may not operate at a loss indefinitely.<br>In case the adversary has an infinite budget, we provide an impossibility result that stems from the similarity between the Bitcoin model and Santha-Vazirani sources. We also give a hybrid protocol that combines trusted parties and a Bitcoin-based beacon.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 22, 2016 at 10:30 AM, Jeremy via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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&#39;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&#39;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><div><div class="h5">
<br><div class="gmail_quote">On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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 &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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&#39;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&#39;t give you the hash you want. I suppose its possible to make it infinitely expensive to manipulate the number but I can&#39;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">&lt;<a href="mailto:jl2012@xbt.hk" target="_blank">jl2012@xbt.hk</a>&gt;</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></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">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>