Change Details

Was introduced in D2076. Passing check=true to AddCoins mainly just causes an extra HaveCoin lookup for each coin, which is a whole database lookup since it's basically always going to be a miss. That's a slowdown that we probably don't want to be doing. The comment is also confusing me: - CheckBlock does not check for duplicate transactions except the special case of the merkle tree vuln. - If we overwrite a coin from a previous blocks, this has nothing to do with double spends. These are transaction outputs. - BIP30 is not being currently enforced (again, because HaveCoin misses are slow), only BIP34 is enforced. -- see https://github.com/bitcoin/bitcoin/pull/6931 (We do have an in-block duplicate txid check in ContextualCheckBlock, which applies for CTOR blocks if the node had been upgraded CTOR rules when it downloaded the block. However that doesn't check against prior blocks.) For the most part we (and Core) really primarily rely on BIP34, i.e., we rely on the improbability of hash collisions. That said, our current code does require a certain backport and perhaps a new consensus rule sometime in the next 25 years, no rush. :D https://github.com/bitcoin/bitcoin/pull/12204 Did a quick test by doing -reindex-chainstate on testnet with a 300 MB dbcache, it took 20 mins with this patch compared to 29 minutes before.

Was introduced in D2076. Passing check=true to AddCoins mainly just causes an extra HaveCoin lookup for each coin, which is a whole database lookup since it's basically always going to be a miss. That's a slowdown that we probably don't want to be doing. The comment is also confusing me: - CheckBlock does not check for duplicate transactions except the special case of the merkle tree vuln. - If we overwrite a coin from a previous blocks, this has nothing to do with double spends. These are transaction outputs. - BIP30 is not being enforced on recent blocks (again, because HaveCoin misses are slow), only BIP34 is enforced. -- see https://github.com/bitcoin/bitcoin/pull/6931 (We do have an in-block duplicate txid check in ContextualCheckBlock, which applies for CTOR blocks if the node had been upgraded CTOR rules when it downloaded the block. However that doesn't check against prior blocks.) For the most part we (and Core) really primarily rely on BIP34, i.e., we rely on the improbability of hash collisions. That said, our current code does require a certain backport and perhaps a new consensus rule sometime in the next 25 years, no rush. :D https://github.com/bitcoin/bitcoin/pull/12204 Did a quick test by doing -reindex-chainstate on testnet with a 300 MB dbcache, it took 20 mins with this patch compared to 29 minutes before.

Was introduced in D2076. Passing check=true to AddCoins mainly just causes an extra HaveCoin lookup for each coin, which is a whole database lookup since it's basically always going to be a miss. That's a slowdown that we probably don't want to be doing. The comment is also confusing me: - CheckBlock does not check for duplicate transactions except the special case of the merkle tree vuln. - If we overwrite a coin from a previous blocks, this has nothing to do with double spends. These are transaction outputs. - BIP30 is not being currently enforcedenforced on recent blocks (again, because HaveCoin misses are slow), only BIP34 is enforced. -- see https://github.com/bitcoin/bitcoin/pull/6931 (We do have an in-block duplicate txid check in ContextualCheckBlock, which applies for CTOR blocks if the node had been upgraded CTOR rules when it downloaded the block. However that doesn't check against prior blocks.) For the most part we (and Core) really primarily rely on BIP34, i.e., we rely on the improbability of hash collisions. That said, our current code does require a certain backport and perhaps a new consensus rule sometime in the next 25 years, no rush. :D https://github.com/bitcoin/bitcoin/pull/12204 Did a quick test by doing -reindex-chainstate on testnet with a 300 MB dbcache, it took 20 mins with this patch compared to 29 minutes before.