4 ms·

Doesn't the Bitcoin blockchain serve as a strong, independent, difficult to manipulate source of entropy that gets published every 10 minutes on average? Why n

by tfha 7y ago

Doesn't the Bitcoin blockchain serve as a strong, independent, difficult to manipulate source of entropy that gets published every 10 minutes on average? Why not just use that?

ben509 7y ago
Having many sources makes it even more difficult to manipulate.
nemo1618 7y ago
Bitcoin block hashes are expensive to manipulate, but not fundamentally difficult to manipulate. All you need to do is bribe the miners. Let's say you strike a deal with AntPool, which mines about 10% of Bitcoin blocks. If they find a block with favorable entropy, they broadcast it; otherwise, they withhold it, and you compensate them for the missed coinbase. So if you only need to control 1 bit of entropy, you can expect this bit to be available within ~20 blocks, at a cost of one coinbase. Very expensive -- but not difficult. In essence, the difference between Bitcoin and an aggregate scheme is that in Bitcoin, your control over the entropy is probabilistic and directly proportional to the number of bribed parties, whereas in an aggregate scheme, you have no control whatsoever until you manage to bribe every party, at which point you gain full control.
- tfha 7y ago
  The effect of this can be minimized by pre-comitting to which block will be used for entropy. Then antpool has a 10% chance of mining the relevant block, a (.1*.5=0.05) 5% chance of mining an unwanted bit and discarding it, and then from there the chance that another unwanted bit is found will be close to 50%. All considered that means antpool has a 2.5-3% chance of flipping an wanted result into a wanted result. At $125,000 per block, that's $4 million of cost per bit manipulated favorably, getting exponentially worse as you need to manipulate more bits.
  - gus_massa 7y ago
    I think that the problem is that if you pick the first block mined after April 1st midnight, and there are two competing blocks, it will be a problem. In the blockchain one of the blocks will win sooner or later and it will be extended with a long enough chain to kill the other block. But the people that would have won the lottery with the other block will be angry. And remember that the timestamp of the block is oply an approximation. You can use any time you want. I'm not sure if the net reject the block when the time is too off, but you can use a fake delayed time of a few minutes and wait to broadcast it (perhaps mining secretly the next block), or perhaps you can use a fake previous time of a few minutes and blame the delay of the broadcast to a bad connection. (It's mode difficult to do this secretly in a pool.) The newspaper here make a big fuzz about the first baby of the year, and I always suspected the exact born time in that moment is not reliable.
    - tfha 7y ago
      You can solve this problem by picking a specific block height, and not confirming the result until it has at least 6 confirmations.
voxl 7y ago
I think this claim is ought to be very controversial, I seriously doubt anyone would consider Blockchain a viable source of true-randomness.
- tfha 7y ago
  Why? Please provide a meaningful reason why Bitcoin cannot be used for secure randomness.
  - GuthL 7y ago
    Secure randomness requires unpredictability, unstoppability and unbiasable. If you are flipping coin based on bitcoin randomness, the block proposer has an advantage over you. It is not technical secure randomness. That's why Ethereum 2.0 is planning on using a RANDAO + VDF to ensure it. More info on vdfresearch.org
    - tfha 7y ago
      A block proposer has a small probability of being able to re-roll the random number a single time, and an exponentially lower probability of getting a second or third chance. And each attempted manipulation costs a lot of money. Can easily put secure bounds on this and use it for most applications.
      - petertodd 7y ago
        Additionally you can use iterated hashing: take the block hash b and hash it n times as in H(H(H(H(b)))) etc. Since hashing is a serial operation, and each hash is a random mapping of input to output, with enough iterations (hundreds of billions) you make it completely infeasible for the miner to even know what the result was by the time they have to make the block public. Zcash actually did this for their second trusted setup; IIRC the delay was set to be about a week's worth of computation. It's a much better scheme for many use-cases than anything else I've seen in this conversation. The main downside is exactly when which participate actually finds out what the final result is isn't well defined. But for cases where you can commit to the result in advance that's fine.

by tfha 7y ago

Doesn't the Bitcoin blockchain serve as a strong, independent, difficult to manipulate source of entropy that gets published every 10 minutes on average? Why not just use that?

ben509 7y ago

Having many sources makes it even more difficult to manipulate.

nemo1618 7y ago

Bitcoin block hashes are expensive to manipulate, but not fundamentally difficult to manipulate. All you need to do is bribe the miners. Let's say you strike a deal with AntPool, which mines about 10% of Bitcoin blocks. If they find a block with favorable entropy, they broadcast it; otherwise, they withhold it, and you compensate them for the missed coinbase. So if you only need to control 1 bit of entropy, you can expect this bit to be available within ~20 blocks, at a cost of one coinbase. Very expensive -- but not difficult. In essence, the difference between Bitcoin and an aggregate scheme is that in Bitcoin, your control over the entropy is probabilistic and directly proportional to the number of bribed parties, whereas in an aggregate scheme, you have no control whatsoever until you manage to bribe every party, at which point you gain full control.

tfha 7y ago
The effect of this can be minimized by pre-comitting to which block will be used for entropy. Then antpool has a 10% chance of mining the relevant block, a (.1*.5=0.05) 5% chance of mining an unwanted bit and discarding it, and then from there the chance that another unwanted bit is found will be close to 50%. All considered that means antpool has a 2.5-3% chance of flipping an wanted result into a wanted result. At $125,000 per block, that's $4 million of cost per bit manipulated favorably, getting exponentially worse as you need to manipulate more bits.
- gus_massa 7y ago
  I think that the problem is that if you pick the first block mined after April 1st midnight, and there are two competing blocks, it will be a problem. In the blockchain one of the blocks will win sooner or later and it will be extended with a long enough chain to kill the other block. But the people that would have won the lottery with the other block will be angry. And remember that the timestamp of the block is oply an approximation. You can use any time you want. I'm not sure if the net reject the block when the time is too off, but you can use a fake delayed time of a few minutes and wait to broadcast it (perhaps mining secretly the next block), or perhaps you can use a fake previous time of a few minutes and blame the delay of the broadcast to a bad connection. (It's mode difficult to do this secretly in a pool.) The newspaper here make a big fuzz about the first baby of the year, and I always suspected the exact born time in that moment is not reliable.
  - tfha 7y ago
    You can solve this problem by picking a specific block height, and not confirming the result until it has at least 6 confirmations.

voxl 7y ago

I think this claim is ought to be very controversial, I seriously doubt anyone would consider Blockchain a viable source of true-randomness.

tfha 7y ago
Why? Please provide a meaningful reason why Bitcoin cannot be used for secure randomness.
- GuthL 7y ago
  Secure randomness requires unpredictability, unstoppability and unbiasable. If you are flipping coin based on bitcoin randomness, the block proposer has an advantage over you. It is not technical secure randomness. That's why Ethereum 2.0 is planning on using a RANDAO + VDF to ensure it. More info on vdfresearch.org
  - tfha 7y ago
    A block proposer has a small probability of being able to re-roll the random number a single time, and an exponentially lower probability of getting a second or third chance. And each attempted manipulation costs a lot of money. Can easily put secure bounds on this and use it for most applications.
    - petertodd 7y ago
      Additionally you can use iterated hashing: take the block hash b and hash it n times as in H(H(H(H(b)))) etc. Since hashing is a serial operation, and each hash is a random mapping of input to output, with enough iterations (hundreds of billions) you make it completely infeasible for the miner to even know what the result was by the time they have to make the block public. Zcash actually did this for their second trusted setup; IIRC the delay was set to be about a week's worth of computation. It's a much better scheme for many use-cases than anything else I've seen in this conversation. The main downside is exactly when which participate actually finds out what the final result is isn't well defined. But for cases where you can commit to the result in advance that's fine.