What happens to data after netsplit

Question

Let's say there are 10 private nodes and there is a netsplit so there are 2 x 5 nodes connected.

Is it correct that after some blocks the consensus stops, because there are nodes missing?

Or do the nodes now do a consensus / round robin with the remaining 5 nodes?

 

What happens to the data that was put in a stream and is located in the shorter fork after reconnecting?

Since only the longer chain is the active chain, is the data that was put into the stream lost or is not shown anymore when using liststreamitems?

Answer 1

First, the behavior in this situation depends on the mining-diversity parameter in the blockchain. If it is over 0.5 (which we recommend in any production deployment) then any network split will cause one side of the split to stop mining blocks, while the other side of the split continues to do so.

Once the network becomes reconnected, any nodes which finds themselves on the shorter fork will switch across to the other fork. Any transactions which were in the shorter fork, but not in the longer fork, will reenter the "memory pool" of those nodes, and be transmitted to the other nodes in the network, just like any new transaction. The transactions will then be confirmed in the blockchain in due course, in the usual way.

Comments

Hi. First thanks for these quick and helpful replies.

Some follow up questions to understand the consensus a bit better:
1. Do I get it right: Even if I set the minig-diversity high enough, it takes some blocks to realize for the network that there are nodes missing. Exactly at this point of time when one of these missing nodes would be the next node to mine another block.So the consensus stop right here?

2. The network needs the number of all participating miner nodes to calculate the fraction of nodes needed to continue. But the number of active nodes can change over time. So when does the network stop and when (if at all) does it adapt to the new number of nodes and continue mining? Or is my understanding wrong here?

3. The transactions that reenter the network will get new timestamps? This is interesting for all kind of proofs where block timestamp is important.

---

1. Kind of. The point of mining diversity is to set the strictness of the round robin scheme, so that if only a small number of nodes drop off, the blockchain proceeds. The higher you set mining diversity, the more strict the round robin scheme, and the fewer failed miners it will take for the blockchain to stop growing.

2. For now the calculation is based on the number of permissioned miners (i.e. assigned the 'mine' permission with 'grant' transactions), not on the number of miners active on the network, so only explicit permission changes will affect the number of miners required to be active.

3. The native timestamping of the blockchain is based on the timestamps in block headers, and there is no per-transaction timestamping. So indeed the transactions will get new timestamps. Of course there is nothing to prevent you timestamping every transaction at the application level, using metadata, but the application level would then also need to verify that these timestamps make sense.

---

The topic just came up again in a discussion.

So the point is: You can not be 100% sure that the timestamp of a transaction you send to the blockchain cannot change afterwards, even if the block was mined successfully?

Of course we are talking of a really edge case here.

Some more questions on that:
1. If the transaction is resend to the network, what happens to the "old" transaction that is already in the "wrong" fork? Does it stay there?

2. Does the new transaction get a complete new transaction id?
If yes you are not able to find it. If no questions 1 seems to be clear, otherwise you would have to transactions with the same id in the network.

3. The transaction that is resend to the network after the split can be rejected because of preconditions that are not met anymore (e.g. I do not own the asset anymore in the chain I want to merge into?)

4. Is there any way to discover a netsplit? At least after the mining stop in the smaller network of both, but in the meantime there could be (depending on how big the whole network is) a bunch of transactions that are invalid.

5. Is there an easy way to get the number of miners in a network (the node must have this information anyway, doesn't it?) Then you could at least check if the transaction is likely to be in the bigger group of a netsplit when you consider the number of blocks that were mined after this transaction.

What would help here is a dynamic version of mine-empty-blocks that is always the number of mining nodes. The if a network consists of 20 mining nodes, the number of mine empty blocks should be 20. And if 5 mining nodes join, the empty rounds should increase to 25.
Then you could always be sure that always every miner gets the chance to tell that it is still here. Then you also have the information of how many miners are in my part of the network and therefore you could conclude if your block is very likely to be in the "correct" fork while in a netsplit.

---

1+2. The transaction ID does not change.

3. Yes, it is possible. The scenario you mention would only happen if there is a deliberate double spend by whoever built the transaction. (This is the value of the UTXO model, where transactions spend specific prior outputs.) But also a permissions change could make the transaction no longer valid.

4. If a network has split and a node is on a fork that has stopped mining, you can detect this by the block count remaining static (getblockchaininfo), and the memory pool growing larger (getmempoolinfo).

5. Yes, use "listpermissions mine".

Lastly, the mine-empty-rounds parameter already works (more or less) like you suggest, and is not called mine-empty-blocks :) A "round" is defined as the number of permitted miners, multiplied by the mining-diversity, rounded up.

---

Very cool, thanks.
I should have looked at the params.dat parameter name lately. :-)