8 ms·

The network split had nothing to do with transactions per hour. It was due to a very subtle difference between two versions of BerkeleyDB used in different ver

• makomk 13y ago
  Not really. The issue with BerkeleyDB was actually triggered by a new version of the Bitcoin client that didn't use BDB to store the blockchain and that simultaneously raised the number of transactions allowed in a block so that more could be processed. Older BDB-based versions of the Bitcoin client hit a previously unknown limit when attempting to process that many transactions, causing them to fork onto their own version of the network. The issue hadn't been noticed before because the number of transactions was previously restricted to a low enough level that it couldn't trigger the bug.
  • ewillbefull 13y ago
    > and that simultaneously raised the number of transactions allowed in a block so that more could be processed Source? I don't believe the hard limit in blocks has ever been changed; bitcoin's devs are currently struggling to convince people to let them do it. The soft limit will NOT cause hard forks. The only reason that fork happened was an unknown limit that existed with one database in one version and which didn't exist with an improved database in another version. It was a bug. Here's an evaluation of the chainfork: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...