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

[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

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,