Re: [bitcoin-dev] BIP: OP_PRANDOM

[Matthew Roberts via bitcoin-dev]

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  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] BIP: OP_PRANDOM

[Matthew Roberts via bitcoin-dev]

== 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 encumbered output.
When a transaction containing the op code is redeemed, the transaction
receives a pseudo-random number based on the next N block hashes after
confirmation of the redeeming input. This means that transactions are also
effectively locked until at least N new blocks have been found.


== Rational

Making deterministic, verifiable, and trustless pseudo-random numbers
available for use in the Script language makes it possible to support a
number of new smart contracts. OP_PRANDOM would allow for the simplistic
creation of purely decentralized lotteries without the need for complicated
multi-party computation protocols. Gambling is also another possibility as
contracts can be written based on hashed commitments, with the winner
chosen if a given commitment is closest to the pseudo-random number.
OP_PRANDOM could also be used for cryptographically secure virtual asset
management such as rewards in video games and in other applications.


== 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.

There is however another issue: since the random numbers are based on a
changing blockchain, its problematic to use the next immediate block hashes
before the state is “final.” A safe default for accepting the blockchain
state as final would need to be agreed upon beforehand, otherwise you could
have multiple random outputs becoming valid simultaneously on different
forks.

A simple solution is not to reveal any commitments before the chain height
surpasses a certain point but this might not be an issue since only one
version will eventually make it into the final chain anyway -- though it is
something to think about.


== Outro

I'm not sure how secure this is or whether its a good idea so posting it
here for feedback

Thoughts?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Johnson Lau via bitcoin-dev]

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 required for mining. But it is probably more difficult for people to spend 
an archived output. They need to know the status of other archived outputs from 
the same block. A full re-scan of the blockchain may be needed to generate the 
proof but this could be done by a third party archival node.

> 
> 
> 
> ## Implementation
> 
> Our proposed high-performance/low-latency delayed commitment full-node
> implementation needs to store the following data:
> 
> 1) UTXO set
> 
>Low-latency K:V map of txouts definitely known to be unspent. Similar to
>existing UTXO implementation, but with the key difference that old,
>unspent, outputs may be pruned from the UTXO set.
> 
> 
> 2) STXO set
> 
>Low-latency set of transaction outputs known to have been spent by
>transactions after the most recent TXO commitment, but created prior to the
>TXO commitment.
> 
> 
> 3) TXO journal
> 
>FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
>must be low-latency; removals can be high-latency.
> 
> 
> 4) TXO MMR list
> 
>Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,
>backed by a reference counted, cryptographically hashed object store
>indexed by digest (similar to how git repos work). High-latency ok. We'll
>cover this in more in detail later.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev