4 ms·

No, the block count is the only thing that matters. If an attacker has X hashpower, the probability that they will succeed in a 51% attack after N confirmations

No, the block count is the only thing that matters. If an attacker has X hashpower, the probability that they will succeed in a 51% attack after N confirmations is (X / (1 - X))^N ; you can derive this formula yourself via generating functions. The block time appears nowhere in that analysis.

0x0 12y ago
But with a shorter block time, they can make more attempts in the same time span... Even if each attempt has a low probability of success on its own, wouldn't the higher number of attempts make it more likely to succeed at least once? I was led to believe the purpose of slow (long) confirmations was to reduce the risk of an attacker mining an alternative chain in secret (to be revealed later as a hijack and a double spend), by making it unlikely to be able to sustain a high hashrate (multiplied by "luck"?)
- Bubbles99 12y ago
  Above and beyond that, the effect of high block times is that centralized miners gain a significant advantage over decentralized ones. The current block latency of the Bitcoin network is in the order of a number of seconds. As we know that current mining pools are indicative of the best connected (many of them have private peering and significant numbers of edge router nodes), we can assume that the majority of the network will be even poorer than this. In some testing the difference between a Stratum socket on the top 4 pools announcing a block was often up to 3 seconds. For a 12 second block time in Bitcoin, the network would likely collapse down to just the biggest pool, as everybody else would have a disproportionately high number of orphan blocks. Sensible miners would need to move to the biggest pool in order to avoid a significant double-digit percentage losses. > I thought the risk of a split chain was tied mostly to the wall clock, not the block count? This is a correct statement to make. The number of blocks considered to be safe is completely irrelevant, and only has the effect of denoting the time on the wall. An hour for 6 confirmations in Bitcoin wasn't chosen so much because it was 6 blocks long, but because it is a reasonable tradeoff between convenience and security. If the block time had been 5 minutes you would need 12 to get the same level of confidence in a transaction. I don't understand why the Ethereum developers appear to think otherwise.

0x0 12y ago

But with a shorter block time, they can make more attempts in the same time span... Even if each attempt has a low probability of success on its own, wouldn't the higher number of attempts make it more likely to succeed at least once? I was led to believe the purpose of slow (long) confirmations was to reduce the risk of an attacker mining an alternative chain in secret (to be revealed later as a hijack and a double spend), by making it unlikely to be able to sustain a high hashrate (multiplied by "luck"?)

Bubbles99 12y ago
Above and beyond that, the effect of high block times is that centralized miners gain a significant advantage over decentralized ones. The current block latency of the Bitcoin network is in the order of a number of seconds. As we know that current mining pools are indicative of the best connected (many of them have private peering and significant numbers of edge router nodes), we can assume that the majority of the network will be even poorer than this. In some testing the difference between a Stratum socket on the top 4 pools announcing a block was often up to 3 seconds. For a 12 second block time in Bitcoin, the network would likely collapse down to just the biggest pool, as everybody else would have a disproportionately high number of orphan blocks. Sensible miners would need to move to the biggest pool in order to avoid a significant double-digit percentage losses. > I thought the risk of a split chain was tied mostly to the wall clock, not the block count? This is a correct statement to make. The number of blocks considered to be safe is completely irrelevant, and only has the effect of denoting the time on the wall. An hour for 6 confirmations in Bitcoin wasn't chosen so much because it was 6 blocks long, but because it is a reasonable tradeoff between convenience and security. If the block time had been 5 minutes you would need 12 to get the same level of confidence in a transaction. I don't understand why the Ethereum developers appear to think otherwise.