The problem with this approach is that you need 100% exact behaviour for
every node on the network in their decision to reject a particular block.
So we need a 100% mempool synchronization across all nodes - otherwise just
an attempted double spend could result in a fork in the network because
some nodes saw it and some didn't. And actually, if we had 100% mempool
synchronization, we wouldn't need a blockchain in the first place, because
we could just use "first to enter mempool" as validity criterion.

On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <peter@grigor.ws> wrote:

> The block size debate centers around one concern it seems. To wit: if
> block size is increased malicious miners may publish unreasonably large
> "bloated" blocks. The way a miner would do this is to generate a plethora
> of private, non-propagated transactions and include these in the block they
> solve.
>
> It seems to me that these bloated blocks could easily be detected by other
> miners and full nodes: they will contain a very high percentage of
> transactions that aren't found in the nodes' own memory pools. This
> signature can be exploited to allow nodes to reject these bloated blocks.
> The key here is that any malicious miner that publishes a block that is
> bloated with his own transactions would contain a ridiculous number of
> transactions that *absolutely no other full node has in its mempool*.
>
> Simply put, a threshold would be set by nodes on the allowable number of
> non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
> really don't know what it should be). If a block is published which
> contains more that this threshold of non-mempool transactions then it is
> rejected.
>
> If this idea works the block size limitation could be completely removed.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>