Quote from: -ck on February 20, 2017, 09:19:47 AM

Quote from: classicsucks on February 20, 2017, 08:29:00 AM

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

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.

Couldn't this issue be worked around by pre-filtering the traffic coming into the bitcoin daemon? "Bad" transaction detection would need to be at the protocol level. The simplest fix would be rejecting transactions over a certain size. Of course that's imperfect, but the filtering could become more fine-grained and accurate over time. It might even be possible to do this with firewall rules?

This is a block and the transactions it contains we're talking about, not a simply broadcast transaction, and we don't want to start filtering possibly valid blocks...

Gotcha. How about if spammy looking transactions were filtered by each node when they are first broadcast? I suppose ultimately we'd be working toward prioritizing transactions based on their merits... I also see that it's risky to start judging transactions and dropping them, but perhaps there should be an obligation for the transaction creator to be legitimate and respectful of the limited blockspace?

I understand that multi-ithreading could open up a can of worms... It still seems like raising the blocksize would be quite easy, and is the logical way forward. ( inb4 "OH MY GOD HARD FORK....") BTW Synthetic Fork seems like a decent proposal from the Chinese.