Re: [bitcoin-dev] BIP: OP_PRANDOM

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]. [1]: https://www.elementsproject.org/elements/opcodes/ [2]: https://github.com/ElementsProject/elements/blob/alpha/src/script/interprete

Re: [bitcoin-dev] BIP: OP_PRANDOM

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

Re: [bitcoin-dev] BIP: OP_PRANDOM

Matthew, Other than gambling, do you have any specific examples of how this could be useful? On Fri, May 20, 2016, 20:34 Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Using the hash of multiple blocks does not make it any safer. The miner of > the last block alway

Re: [bitcoin-dev] BIP: OP_PRANDOM

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

[bitcoin-dev] BIP: OP_PRANDOM

== Background OP_PRANDOM is a new op code for Bitcoin that pushes a pseudo-random number to the top of the stack based on the next N block hashes. The source of the pseudo-random number is defined as the XOR of the next N block hashes after confirmation of a transaction containing the OP_PRANDOM e

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

How is this compared to my earlier proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html ? In my proposal, only the (pruned) UTXO set, and 32 bytes per archived block, are

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

On Thu, May 19, 2016 at 04:23:28PM -0600, Nick ODell wrote: > What if two people create transactions from oupoints within the same MMR > tree tip, at the same time? > > For example, I create transaction A plus an MMR proof that MMR tip X will > become Y. > > On the other side of the planet, some