Post
Topic
Board Development & Technical Discussion
Re: Block size increase proposal: Consensus based on the mempool
by
achow101
on 01/04/2017, 19:16:26 UTC
Obviously, miners as well as other full nodes must relay all standard transactions before including them into the block. Do you think that small transaction can propagate over the network 5 seconds slower than full block does? Not a problem - miners can adjust this delay as much as needed.
But then how do you know that a transaction in a block was actually relayed beforehand? There is no universal mempool, the mempool varies from node to node. Furthermore, you are assuming that every node has a mempool, but people can run nodes that are blocks only. They would not be able to validate a block under this rule. You are also assuming that all nodes will keep all transactions and receive them at roughly the same time. However you cannot assume that. Many nodes will evict transactions or not accept them if they violate local node policy (which does not have to match the node policies of anyone else). For example, there could be a race condition where a bunch of low fee transactions are evicted just before a block is received by the node so this evicted transactions are no longer in the mempool and the block considered invalid. Furthermore, a newly started node will fail to properly sync because it would consider all blocks invalid (after all, it still has to validate consensus rules) because it has none of the transactions in those blocks in its mempool. A block that is found very shortly after a node starts up would also be rejected as that node's mempool has not filled up with transactions yet.

Reject invalid block "A", and therefore reject valid block "B". But if afterwards it also receives valid block "C" which builds on block "B", the chain becomes valid. But this situation is possible only in case of 51% attack because honest miners will do their work on block preceding "A".
Suppose the miner who found A is super lucky, and found B, then C very quickly. Now all miners will be using the chain including the invalid block, and that invalid block could be maliciously crafted to create transactions which allows the miner who found the block to spend the Bitcoin.

You are also assuming that all miners are fully validating every single block before they build on top of it. Unfortunately, we know for a fact that this is absolutely not the case. Many miners are SPV mining; they will begin mining on top of a block before it is fully validated. With SPV mining, it is very possible that miners will end up mining on top of an invalid block and thus extending the chain for that block and find enough blocks so that its is valid.

I suggest to define which transactions should be considered as standard and tighten the protocol rules to make nodes required to relay all these transactions.
That does nothing to help with figuring out what transactions are in nodes' mempools. Standardness  rules are not consensus rules, they are local node policy rules. Anyone can change their local node policy. Even so, there are transactions which are standard, but still rejected by other node policies. Relying on standardness rules is not enough to say that you know what transactions are in everyone's mempools.

Ok. You just misunderstood me. I've changed "rejected blocks potentially could be included" to "temporary rejected blocks ..." in my first post.
Actually my solution doesn't solve the 51% attack problem. But of course the best chain is selected only when it meets the consensus rules.
The miners are then redefining the consensus rules still. They can do so every 3 blocks; every 3 blocks can basically have whatever consensus rules it wants then so long as everyone mines a block on top of the invalid one, which is entirely possible given that many miners do SPV mining.

I don't think that full nodes have any significant power. But they can try to continue to reject undesirable blocks more than after 2-3 following blocks.
But miners shouldn't have full and absolute power over everything. Full nodes prevent miners from changing the consensus rules willy-nilly. They provide an incentive for miners to not produce invalid blocks. With your proposal, they now have an incentive to produce invalid blocks because in that invalid block they can make a ton of money and have a fairly high likelihood of making that invalid block a valid accepted block.