Topic: Multi-client verification for miners (Read 631 times)
This is a service pools should provide, and I am sure they will since it is a differentiator in their otherwise commodity service.
To prevent forks, miners need to produce blocks that are accepted by all (or as many as possible) clients.
This means that clients don't need quite the same level of consistency as miners.
Miners should be able to have multiple versions of the client check their block before they start mining it.
As long as the majority of the hash power produces blocks that are accepted by most clients, then incompatibilities wouldn't be a big problem. Miners might aim to check against clients which represent > 95% of the nodes on the network, before they start mining.
There could be a sliding scale. Blocks that it mines itself should be compatible with most clients but blocks that it receives should be less strict.
If clients supported a "checkblock" message that includes the new block and the client replies saying that the block is ok or not, then miners could submit their new block to local instances of a selection of clients. They wouldn't mine the block unless all clients give it the ok. This message would be the same as the block message, so maybe, a new field could be added.
The reply message could say which transactions are invalid. This would allow them to be excluded for the next attempt.
This wouldn't have helped with the recent difficulties. The node could reply with "unknown failure" and the response could be to just try with smaller blocks and/or a different set of transactions from the memory pool.
This means that clients don't need quite the same level of consistency as miners.
Miners should be able to have multiple versions of the client check their block before they start mining it.
As long as the majority of the hash power produces blocks that are accepted by most clients, then incompatibilities wouldn't be a big problem. Miners might aim to check against clients which represent > 95% of the nodes on the network, before they start mining.
There could be a sliding scale. Blocks that it mines itself should be compatible with most clients but blocks that it receives should be less strict.
If clients supported a "checkblock" message that includes the new block and the client replies saying that the block is ok or not, then miners could submit their new block to local instances of a selection of clients. They wouldn't mine the block unless all clients give it the ok. This message would be the same as the block message, so maybe, a new field could be added.
The reply message could say which transactions are invalid. This would allow them to be excluded for the next attempt.
This wouldn't have helped with the recent difficulties. The node could reply with "unknown failure" and the response could be to just try with smaller blocks and/or a different set of transactions from the memory pool.
Jump to: