2 nodes with the network disconnected.

Question

I want to ask a question about transactions when the network is not stable.

The block chain is setup with 2 nodes, and import private key for the same address.

If the network  between the 2 nodes is disconnected, and I　run sendwithdata command with identical parameters, will the two transactions work ?

if the balance for the sent address is 100, then I sent 60 to received address on the both nodes, will the two transactions work ?

Answer 1

If two transactions are completely identical in terms of their content, then this means they will have the same transaction ID (txid). In that case both transactions will work on the separate nodes, and everything will be fine when the nodes become reconnected to each other, since they are already in consensus in terms of the transactions that have taken place.

However just sending the same quantity from the same source to the same recipient doesn't guarantee identical transactions, because there is the issue of coin selection – which previous unspent transaction outputs are used as inputs for the new transaction. Three things can happen here:

• Identical inputs -> identical transactions -> no problem (one payment under consensus)
• Completely different inputs -> two different transactions -> both will happen (duplicate payment)
• Partially overlapping inputs -> transaction conflict -> only one will be accepted (one node will see its transaction rejected by the blockchain as a double spend)

In practice you should find that two MultiChain nodes which were in sync then became disconnected will make the same choice of previous unspent transaction outputs. However this is not guaranteed in terms of what we document in the APIs, so you shouldn't rely on it in the long term.

 

Instead, we would recommend using manual coin selection to build the transaction, using your own rules regarding which unspent transaction outputs are used as inputs. That gives you full control and a guarantee that the same coin selection process is being applied on both nodes.

 

The relevant APIs for this are listunspent + createrawtransaction + appendrawchange + signrawtransaction + sendrawtransaction.

Comments

maybe i confused you. the transactions on the 2 nodes are not identical (or the same txid). for example, the address A has asset0 100.
 If I run senddata from A to B 60 on node 1, and run senddata from A to C 70 on node 2 in the case that node 1 and 2 are disconnected(means they can not synchronize transaction info at that time).  
The two transactions need 60+70=130 >  100(the balance of address A).
In this case, will the two transaction be accepted both ?
if they are both accepted, when the network recover, what will happen?  One of the trasaction accepted with another rejected?

---

OK, I understand. The answer is that, if the nodes become disconnected, both transactions will take place and at first be "unconfirmed" (i.e. not in the blockchain). Assuming you set up your mining diversity to require both nodes to be connected, one transaction will remain unconfirmed, while the other will get confirmed. Once the nodes become connected again, the unconfirmed one will be rejected/reversed and will no longer even appear as unconfirmed.

---

thanks for reply. Basically I understand. transactions on both nodes will be accepted, but it is not guaranteed that both transactions will be finally proved to be valid or written into blocks.  
Our application's scenario is like this:  when the customer client calls PRC to fire a transaction,  it will not wait for the transaction being validated. As long as multichain return the txid, we immediately tell the customer client that the transaction is Done. But in fact, the transaction is not guaranteed to be valid in the chain.
So do you some solution to handle this case ?
Or can you provide a pre-check mechanism that under which condition the transaction on one node is unsafe. So we can keep monitoring all the nodes in the blockchain network. Transactions will not be sent to one node unless the node is definitely safe.
Thanks!