Re: Block size increase proposal: Consensus based on the mempool
BTW, I have an alternative proposal. Just an idea:
In the future, size of block can reach several hundred megabytes, that imminently cause unacceptable large delays from the moment of block generation until it is completely propagated over the network. At the same time, everybody has a large part of transactions in mempool, so there is no need to transfer them again. It is sufficient to transmit only the header, missing transactions (usually it is coinbase TX) and to define a standard algorithm to construct the block from existing transactions. For example, miner could relay just an array of TxIds.
You're late to the party. "Your idea" has been discussed for years now, and already implemented and already in use. Look up BIP 152 Compact Blocks or BUIP 10 XThin blocks (both operate conceptually the same, but are wholly different from each other).In the future, size of block can reach several hundred megabytes, that imminently cause unacceptable large delays from the moment of block generation until it is completely propagated over the network. At the same time, everybody has a large part of transactions in mempool, so there is no need to transfer them again. It is sufficient to transmit only the header, missing transactions (usually it is coinbase TX) and to define a standard algorithm to construct the block from existing transactions. For example, miner could relay just an array of TxIds.
Why?
It does nothing about the fact that months after your proposal activates, when I restart my node, it will have either a completely empty mempool, or a mempool that is completely outdated. Either way, if a new block is found immediately after I start my node and I receive that block, the mempool on my node is not likely to have all of the transactions in that block. Even if it did, those transactions would not be there for more than 15 seconds if I received the block less than 15 seconds after starting my node. It will still consider that block invalid, and I will still have to wait for 3 more blocks to be found on top of it before I can actually use my node properly.This behavior for the case if nothing is done at start. What the problem? Just wait a few blocks and rejected chain becomes valid.
"A few blocks" can take anywhere from 30 minutes to a few hours. Do you realize how long you would have to wait in order for the wallet to actually become usable? That is a huge usability problem. Also, a lot of people may simply run their wallet for a few minutes a day to receive or send some Bitcoin. It takes a couple of seconds to sync the last day of blocks and then the wallet is immediately useable. They use it for a few minutes, and then shutdown. These people (and most people for that matter), don't have time to wait 30 minutes to a few hours for their wallet to actually become usable. There is a possibility that they would have to wait this long many times that they start their wallet, not just the one time wait for initially syncing a wallet.How often? Miners have to relay transactions before including them into the block.
No they don't. Miners don't have to relay transactions at all. They can just assume that a transaction has already been propagated. Even if they do attempt to relay a transaction, a node that already has a transaction isn't going to re-relay a transaction just because another node relayed the transaction again to them. If they did, that would be a huge DoS vector.Initially, I called it "temporarily rejected block that consists transactions considered as non-standard" 
No, initially you called it "invalid blocks" which encompasses more than just your "undesireable blocks"Sorry, if misled. Now changed this to "undesirable" or "block with spam". But I've never said that chain is selected only by amount of work in it.
Oh really?Anyway, the best chain is selected by amount of work in it.
You are not specifying that it is the best VALID chain, just the BEST CHAIN which can include invalid blocks.