I would also point out that not all nodes' clocks are on the exact same time (when converted to GMT), so it would be difficult to determine if a transaction has in fact been in a miner's mempool for at least 15 seconds prior to broadcasting a block that confirmed said transaction
Actually, we don't need to determine how long it has been in a miner's mempool.
The idea is that transaction must get into the most nodes' mempools and stay there for some time before it can be included into the block. Thus miners are unable to include their own transactions for free and have to broadcast them over the network as all do.
So nodes should simply reject blocks that include these undesirable transactions:
- full nodes should temporarily reject blocks that consists more than 5% of transactions considered as undesirable (received less than 15 seconds ago | with a fee below 20 satoshies/byte)
- miners should follow the same rules, but in addition they need to hold transactions at least for 15-20 seconds before including them into the block
Nodes check that every transaction in a new received block presents in their mempool at least for 15 seconds. If the block contains too much undesirable transactions, most of nodes simply reject it. Thus miners have to relay transactions(their own too) and then hold them at least 15-20 seconds before including into the block. That's all.
Another problem is that if someone broadcasts a transaction that gets to miner "A" located in China, and a conflicting transaction that gets to miner "B" located in New York, US, then exactly one of those transactions will get rejected by nodes
It is a very good question.
I propose to reject all transactions that conflicting any other transaction in node's mempool. But we have to keep original transaction and reset time when it was received. So it cannot be included into the block another 15 seconds. In addition we need to keep the transaction's size and update it every time when we are rejecting a conflicting transaction that larger then all previous such transactions.
For example. If node receives a transaction "A" which size is 400 bytes, it should keep this transaction and two additional values: { tx_A, 400, time }. If then after 10 seconds it receives a conflicting transaction "B" which size is 500 bytes, it should update these values as follows: { tx_A, 500, time+10 }. If it receives another conflicting transaction "C" after another 5 seconds which size is 550 bytes, it should update the values: { tx_A, 550, time+15 }.
When node is validating the block and found some transaction that conflicts with a transaction in it's mempool, it should check that size of this transaction is not more then stored size. If it is so, the transaction shouldn't be considered as spam. Thus miners cannot include their own transactions into the block for free and cannot spam nodes' mempools with conflicting transactions.
The miners who engage in "SPV" mining will only mine on top of an unvalidated block for as long as it takes them to validate the block. These miners are relying on the valid economic assumption that it is not economical to build/broadcast an invalid block, and it will cost a troll miner much more to broadcast an invalid block than it would cost the rest of the network to build upon an invalid block for only as long as it takes to determine that said block is invalid. It would cost a troll miner roughly 13.5-14BTC to broadcast an invalid block, while it would cost 90% of the network collectively between ~.6BTC-~.62BTC to build on top of that block for the amount of time it takes to figure out it is invalid.
I was speaking strictly in terms of how SPV mining works today, under today's rules.
Your thoughts have meaning under my proposal as well.
I think that EC would probably be better for things like long term changes to demand for block space, and the potential for a one-time large block to account for a temporary increase in the need to confirm many transactions
I have another similar idea but only in Russian so far:
https://bitcointalk.org/index.php?topic=1840975.msg18325913#msg18325913