Post
Topic
Board Development & Technical Discussion
Re: Block size increase proposal: Consensus based on the mempool
by
Schnibble
on 02/04/2017, 16:36:29 UTC
Your proposal requires that all nodes receive and store transactions in order to verify that a block contains "desireable" transactions
Actually, node requires to be connected at least with one node that relays all desireable transactions.

Yet blocksonly nodes do not receive and store transactions, thus they cannot receive, verify, and relay blocks
They would not be able to temporarily reject undesirable (possibly orphan) block but still can receive, validate and relay it.

Even if you don't call blocksonly nodes full nodes, you are still preventing people who want to have the security of a full node (and they are still getting that with a blocksonly node) but don't have enough bandwidth for a normal full node from being able to use their wallets.
They still can use their wallets in blocksonly mode. But what's the point if it doesn't receive transactions?

Then you run into other issues like people paying too low of a transaction fee and thus getting their transaction evicted after the hour is up.
It's not a problem. Miners could keep and rebroadcast these transactions shortly before including them into the block.

What if I just restarted my node (so it's mempool is now empty) and then I receive a block? Do I reject it?
The chain becomes valid anyway, when it receives two or three valid blocks. Also we can simply bypass this rule for some time after the launch. Also we can add a new type of message for the purpose of mempool synchronization between the nodes.

miners can't just "adjust their delay" to accommodate every node
Yes. But it is not a miners' problem. Actually, I doubt whether node even without additional delay can receive full block before small transaction. Furthermore, given that transactions are relayed before.

Given that a majority of the hashrate does this (because mining pools) combined with the malicious miner, they could, with some luck, find the 3 blocks necessary in order to make this invalid block accepted.
Malicious miner will generate a lot of orphan blocks before that happens.

The blocks would be found before the SPV miners have finished verifying that the invalid block is in fact invalid, and once the three blocks are found, that invalid block is now valid
Anyway, the worst possible thing that could occur is acceptance the undesirable block consisting of spam. The best chain is selected only when it meets the consensus rules.