19 ms·

But won't each continent adjust its difficulty to account for its local hashrate? And would a high difficulty fork accept that a low difficulty longer fork is

by Imnimo 6y ago

But won't each continent adjust its difficulty to account for its local hashrate? And would a high difficulty fork accept that a low difficulty longer fork is valid? Or would it reject it for having invalid blocks?

ashtonkem 6y ago
The algorithm is tuned so that a block is mined about every 10min no matter what the hashing power available is. In the case of a serious and persistent network partition, both “sides” would continue to mine blocks at roughly the same rate as before, minus the first blocks that would take a while as the algorithm tried to catch up to the drastically reduced local hashing power. The real issue is what happens once the partition is healed, and it’s not a technical problem. The technical solution is straightforward: longest chain wins. The real issue is a social one: how do you deal with finding out that the last N months worth of transactions are just gone?
- Imnimo 6y ago
  If I'm stranded in Antarctica, and decide to compute hashes with my pocket calculator to pass the time, and drop the difficulty to zero (because I can do one hash every 10 min, so they all have to be winners), does the bitcoin protocol say that my chain of empty blocks is a valid contender for longest chain? Or does "longest chain" also take into account difficulty? (Setting aside the obvious fact that in reality everyone would obviously just ignore me)
  - ashtonkem 6y ago
    This isn’t quite how the algorithm works. To make a valid block, you have to start with another valid block. The difficulty is set (edit: I was wrong, and I fixed this) every 2016 blocks based on how long they took to mine. This works out to about 2 weeks at the expected rate of mining. The average time of those 2016 blocks is then used to calculate the difficulty of the next 2016 blocks, and the difficulty is marked down in the chain itself. So in your hypothetical you’d have to solve around two weeks worth of blocks at the current difficulty level, which isn’t possible in a human lifespan. After that the difficulty for your chain would rapidly fall, but your sub-chain would already be very far behind and would never catch up.
    - Imnimo 6y ago
      That makes sense, I remembered that it adjusted every 2 weeks, but I forgot that the 2 weeks was actually measured in blocks, not wall time.
  - benchaney 6y ago
    In practice you wouldn’t be able to mine at all, because the difficulty updates infrequently, so you would have to mine several blocks at the old difficulty. Obviously this is impossible on a pocket calculator. I’ve always assumed that the notion of longest chain takes difficulty into account, although I haven’t really been able to find confirmation of this.
- nybble41 6y ago
  > The technical solution is straightforward: longest chain wins. One caveat here is that "longest chain" is measured not in blocks but rather in cumulative difficulty. So the fork with more hashing power, having a higher difficulty per block, will mine a "longer" chain over the same time period. > The real issue is a social one: how do you deal with finding out that the last N months worth of transactions are just gone? If the transactions are still valid (i.e. the inputs haven't been spent in diverging transactions on both chains) then they can be reintegrated into new blocks on the winning fork after the partition heals. The real problems come from double-spends, whether deliberate or accidental; if funds were moved from TxA to InB in one chain and from TxA to InC in the other then only one of these can be retained, and all transactions downstream from the losing version will be nullified. In general, to create such a situation a client would need to be aware of both forks and sign conflicting transactions for the same unspent output. There is one major exception, however, which is that the coinbase transactions introducing new block rewards on the losing fork can never be valid inputs for transactions on the winning fork. Ergo, any transaction which depends on recently mined coins is ineligible for reintegration.

by Imnimo 6y ago

ashtonkem 6y ago

The algorithm is tuned so that a block is mined about every 10min no matter what the hashing power available is. In the case of a serious and persistent network partition, both “sides” would continue to mine blocks at roughly the same rate as before, minus the first blocks that would take a while as the algorithm tried to catch up to the drastically reduced local hashing power. The real issue is what happens once the partition is healed, and it’s not a technical problem. The technical solution is straightforward: longest chain wins. The real issue is a social one: how do you deal with finding out that the last N months worth of transactions are just gone?

Imnimo 6y ago
If I'm stranded in Antarctica, and decide to compute hashes with my pocket calculator to pass the time, and drop the difficulty to zero (because I can do one hash every 10 min, so they all have to be winners), does the bitcoin protocol say that my chain of empty blocks is a valid contender for longest chain? Or does "longest chain" also take into account difficulty? (Setting aside the obvious fact that in reality everyone would obviously just ignore me)
- ashtonkem 6y ago
  This isn’t quite how the algorithm works. To make a valid block, you have to start with another valid block. The difficulty is set (edit: I was wrong, and I fixed this) every 2016 blocks based on how long they took to mine. This works out to about 2 weeks at the expected rate of mining. The average time of those 2016 blocks is then used to calculate the difficulty of the next 2016 blocks, and the difficulty is marked down in the chain itself. So in your hypothetical you’d have to solve around two weeks worth of blocks at the current difficulty level, which isn’t possible in a human lifespan. After that the difficulty for your chain would rapidly fall, but your sub-chain would already be very far behind and would never catch up.
  - Imnimo 6y ago
    That makes sense, I remembered that it adjusted every 2 weeks, but I forgot that the 2 weeks was actually measured in blocks, not wall time.
- benchaney 6y ago
  In practice you wouldn’t be able to mine at all, because the difficulty updates infrequently, so you would have to mine several blocks at the old difficulty. Obviously this is impossible on a pocket calculator. I’ve always assumed that the notion of longest chain takes difficulty into account, although I haven’t really been able to find confirmation of this.
nybble41 6y ago
> The technical solution is straightforward: longest chain wins. One caveat here is that "longest chain" is measured not in blocks but rather in cumulative difficulty. So the fork with more hashing power, having a higher difficulty per block, will mine a "longer" chain over the same time period. > The real issue is a social one: how do you deal with finding out that the last N months worth of transactions are just gone? If the transactions are still valid (i.e. the inputs haven't been spent in diverging transactions on both chains) then they can be reintegrated into new blocks on the winning fork after the partition heals. The real problems come from double-spends, whether deliberate or accidental; if funds were moved from TxA to InB in one chain and from TxA to InC in the other then only one of these can be retained, and all transactions downstream from the losing version will be nullified. In general, to create such a situation a client would need to be aware of both forks and sign conflicting transactions for the same unspent output. There is one major exception, however, which is that the coinbase transactions introducing new block rewards on the losing fork can never be valid inputs for transactions on the winning fork. Ergo, any transaction which depends on recently mined coins is ineligible for reintegration.