I believe my that the answer to my question lies at this page: https://wiki.ripple.com/Consensus#What_happens_if_say_33.25_of_the_nodes_saw_transaction_A.2C_33.25_saw_transaction_B.2C_and_34.25_saw_transaction_C_first_where_all_3_conflict.3F
What happens if say 33% of the nodes saw transaction A, 33% saw transaction B, and 34% saw transaction C first where all 3 conflict?
Then no transaction will get voted in, and the deterministic algorithm will pick only one which will be a candidate for the next ledger.
Topic: What will happen in this case? (Read 269 times)
How can I handle this behaviour in case of non-blockchain coins? Do I need some validators which act like miners to fix this issue?
That would be a good question for the altcoin sub-forum.
Bitcoin is a blockchain coin.
How can I handle this behaviour in case of non-blockchain coins? Do I need some validators which act like miners to fix this issue?
Due to latency and the fact the servers are likely to be connected to different peers, the propagation of your two transactions will be different. Nodes that see Left Transaction first will likely reject Right Transaction as a "double spend"... conversely, Nodes that see Right Transaction first will reject Left Transaction as a "double spend".
You'll then end up with some nodes having Left... and some having Right... One of these Transactions (and it's pretty much impossible to predict which one) will then be confirmed by a miner by being placed into a block.
Once one of the transactions is confirmed, the other immediately becomes invalid (as it's inputs are already spent by the confirmed transaction) and will be dropped by any nodes that had it.
You'll then end up with some nodes having Left... and some having Right... One of these Transactions (and it's pretty much impossible to predict which one) will then be confirmed by a miner by being placed into a block.
Once one of the transactions is confirmed, the other immediately becomes invalid (as it's inputs are already spent by the confirmed transaction) and will be dropped by any nodes that had it.
Thank you for your helpful answer.
Due to latency and the fact the servers are likely to be connected to different peers, the propagation of your two transactions will be different. Nodes that see Left Transaction first will likely reject Right Transaction as a "double spend"... conversely, Nodes that see Right Transaction first will reject Left Transaction as a "double spend".
You'll then end up with some nodes having Left... and some having Right... One of these Transactions (and it's pretty much impossible to predict which one) will then be confirmed by a miner by being placed into a block.
Once one of the transactions is confirmed, the other immediately becomes invalid (as it's inputs are already spent by the confirmed transaction) and will be dropped by any nodes that had it.
You'll then end up with some nodes having Left... and some having Right... One of these Transactions (and it's pretty much impossible to predict which one) will then be confirmed by a miner by being placed into a block.
Once one of the transactions is confirmed, the other immediately becomes invalid (as it's inputs are already spent by the confirmed transaction) and will be dropped by any nodes that had it.
Let's assume I clone one of my wallets and place it in two servers totally unconnected with each other. Let's call it "left network" and "right network". I use same inputs and send a transaction of 10 BTC and from the other wallet I send the same transaction, but with a value of 5 BTC (same inputs, though). Note that I am sending both the transactions at the same time.
Now, the left side will believe that I sent 10 BTC and the right side will believe that I sent 5 BTC. How will this dispute be handled? Please take a look at the image for some understanding: https://ibb.co/cVBEAG
Now, the left side will believe that I sent 10 BTC and the right side will believe that I sent 5 BTC. How will this dispute be handled? Please take a look at the image for some understanding: https://ibb.co/cVBEAG
Jump to: