Validation Rules

Question

Hi Multichain team

I understand that proof of work is only used as a formality in Multichain to create a hashing, however it does not add to the security. Therefore I have a few questions to understand the mining process a little bit better.

1) Where is the protocol to see what validation (protocol) rules nodes use when they verify correctness transactions and blocks? Is it the same rules as bitcoin?   E.g. Verifying that the transaction does not exceed the configured transaction size

2) If I have mining diversity set to 0.5 or even to 0, how does the system know who will be the next miner? In proof of work we would have a competition, how does it work for multichain?

3) if 51% of mining  node’s would try reverse the blocks that have already been added to the chain. What is the protection mechanism (from a regulatory perspective it would create a lack of data integrity) that this does not happen?

 

Thanks in adavance

Answer 1

1) Yes, MultiChain applies the bitcoin transaction rules, but a whole lot more on top. For example, to check that issued assets (represented using metadata in transaction outputs) balance across transaction inputs and outputs. You can start by looking at AcceptMultiChainTransaction()

2) Based on the mining-diversity value, the next miner can be any of those who are permitted. Each possible miner chooses a random time delay close to the target block time, and whoever generates the block first wins. If there's a fork, it's resolved in exactly the same way as bitcoin – whichever fork is extended first wins. Note that in addition there's a mining-turnover parameter which allows forks to be minimized, by allowing the set of active miners to automatically self-select and stay consistent, unless/until one fails at which point it's random again. But this is not a consensus rule – just a request from nodes about how to behave.

3) First, depend on the mining-diversity parameter, it could be more than 51% required to reverse the chain. Second, if you want to perform finalization, you can use the lockblock parameter (also available via setruntimeparam) to lock down a particular history. For now you need to manage this yourself at the application level, but we're working on improving that. Nonetheless, you should also consider the fact that, in any consensus system, you run this kind of risk. No matter what consensus algorithm you use, a majority of nodes can decide that a different history is the "truth", and therefore rewrite history, and there is no objective way to contradict them.