Quote from: -ck on February 18, 2017, 10:58:23 PM

Quote from: jbreher on February 18, 2017, 10:42:07 PM

Riddle me this: built off a parent of the same block height, a miner is presented -- at roughly the same time:
1) an aberrant block that takes an inordinate amount of time (e.g., 10 minutes) to verify but is otherwise valid;
2) a 'normal' valid block that does not take an inordinate amount of time to verify; and
3) an invalid block.

By the way, as far as I can understand the bitcoind code as I read it (and no doubt I will be corrected if I'm wrong which is fine), this is an attack vector that "choosing between them" is the least of your problems because it cannot process them both concurrently and then decide that (2) has finished long before it has finished processing (1). This means that if a (1) block hits even 1us before the (2), bitcoind will sit there processing it until it has finished before it can process (2). While this is purely a limitation of the software as it currently stands that it cannot process multiple blocks concurrently in a multithreaded fashion due to the coarse grained locking in the software, it doesn't change the fact there is no way to deal with this at present. It would require a drastic rewrite of the existing code to make the locking fine grained enough to do this, or a new piece of software written from the ground up; both of which carry their own risks.

I guess the bitcoind devs have never worked with multithreading then*? Such a pity. And such a cutting-edge 1990's technology. If inordinately large signature transactions ever become A Thing, miners employing bitcoind will be bankrupted by smarter miners.

C'est la guerre. To the wiser go the spoils.

*Yes, unnecessarily provocative. But it certainly points out just one more instance where devs are working on the wrong things.