What happen when 2 miners confirm different versions of my transaction same tim?

[Comeacross]

Let’s assume I broadcast a transaction and Miner 1 puts it in block xxx and at the same time Miner 2 puts a different version of it in the same xxx block. What I mean by different version is either when I attempt to double send or Mempool had double conflicting transactions.

What really happen when something like this occurred?
Does it mean that both blocks get broadcast? And How do nodes decide which one is the “real” chain?
What happens to my transaction if the chain with my transaction gets dropped? Does it go back to the Mempool?

I’m trying to make sense out of this but I am getting hooked.

[Mia Chloe]

~snip

No to put it simply. Understand that a broadcasted transaction has just one identity. What happens after broadcasting is propagation because all the nodes are connected they continue to propagate the transaction across till it's eventually confirmed plus confirmation cannot happen simultaneously.

One will always confirm first. If two different miners add it to their block once one confirms it the other one will only be able to validate it but the reward goes to the one who confirmed it.

[mcdouglasx]

Let’s assume I broadcast a transaction and Miner 1 puts it in block xxx and at the same time Miner 2 puts a different version of it in the same xxx block. What I mean by different version is either when I attempt to double send or Mempool had double conflicting transactions.

What really happen when something like this occurred?
Does it mean that both blocks get broadcast? And How do nodes decide which one is the “real” chain?
What happens to my transaction if the chain with my transaction gets dropped? Does it go back to the Mempool?

I’m trying to make sense out of this but I am getting hooked.

If two mining groups generate two blocks that confirm your transaction, the phenomenon of an orphan block occurs. Almost simultaneously, a momentary fork happens, splitting the chain into two parallel realities. This is resolved by starting a race for the longest chain for the next block. It's not that the miners are aware of this; they simply continue with their normal mining process. Those from blocks A and B, for example, if block A is used to mine the next block first, block B is discarded because block A's chain is longer, and the transactions not included in block A are returned to the meempool. This is why it's recommended to wait for a certain number of confirmations before considering a transaction permanent. With only one confirmation, there's a risk of a reorg, which is the technical term for what happens in this situation. Therefore, it's recommended to wait for more confirmations.

edit:

A different case of reorg is when both blocks A and B spend the same utxos; this is double spending. Here, the Tx is definitely discarded and does not return to the mempool because it does not have such utxos used by the block of the longest chain.

[Cookdata]

What really happen when something like this occurred?
Does it mean that both blocks get broadcast? And How do nodes decide which one is the “real” chain?
What happens to my transaction if the chain with my transaction gets dropped? Does it go back to the Mempool?

I’m trying to make sense out of this but I am getting hooked.

Even if you have two transactions broadcasted with different transaction ID, the two can't exist on the same node. If perhaps they made it to different mining nodes, one with high fee likely get confirmed by a miner and include in a block, and as soon as the block is verified, the input no longer exists in utxo set, so the other transaction will be drop from other nodes mempool. You can't spend what does not exist.

If coincidentally two mining node both confirmed the two transaction at the same time on different blocks, the miner with the longest chain will win and the second chain will become stale and the transactions in that block will become invalid.

[coinlary]

What really happen when something like this occurred?
Does it mean that both blocks transaction get broadcast? And How do nodes decide which one is the “real” chain?

You broadcasted a single transaction not two, the mix up happens during the minning process which is fine if it does , it happens from time to time and gets  resolved.
Disregard above, I didn't read the second part of  your first paragraph,  that's on me. In that case, both txns will get confirmed if they are spending diferent UTXOs ,  any miner that wants to mine a doublespend  will include only the doublespend(rule attached),that will invalidate the first transaction spending same utxo .

What happens next dpends on the next block, one of the two ends up in the logest chain while the other gets dropped and since your question indicate both inclusion  then it won't ever go back to unconfirmed, you only need to worry if it ends up on one side  which could eventually becomes the stale block after a chain reorganisation.

Check my thread, I asked something similar: https://bitcointalk.org/index.php?topic=5569206

[BlackHatCoiner]

If you send TX_A and TX_B at the same time, and miners A and B mine blocks X and Y at the same height, at the same time, each containing different transactions (A's containing TX_A, B's containing TX_B) then both blocks are considered valid, your node keeps both of them (necessarily treats one as valid and the other as valid-but-fork, usually this depends on millisecond precision level timing), and the next block at height xxx + 1 will determine which chain is the one with the most work that everyone will follow. If miner C mines on top of miner A's chain, then TX_A will be the valid one.

[Zaguru12]

What really happen when something like this occurred?
Does it mean that both blocks get broadcast? And How do nodes decide which one is the “real” chain?

You broadcasted a single transaction not two, the mix up happens during the minning process which is fine if it does , it happens from time to time and gets  resolved.

I think what OP means is that he broadcasts a transaction and then when he later increases the fee of that transaction (RBF) which is a new transaction, with the nodes having either of the two transactions like nodes without Full RBF opt_in (which is rare today) having the original transaction while the another has the new transaction. 

If both nodes (miners) were able to mine block almost same time the one with the most work that’s longest chain is the valid block while other one will drop.

Now this your transaction OP will be invalidated and wouldn’t be dropping to the mempool like the other transactions in that block because the valid block has a transaction that has spent the input you intend to spend. This is how double spending of same transaction is not possible in bitcoin

[Comeacross]

No to put it simply. Understand that a broadcasted transaction has just one identity. What happens after broadcasting is propagation because all the nodes are connected they continue to propagate the transaction across till it's eventually confirmed plus confirmation cannot happen simultaneously.

One will always confirm first. If two different miners add it to their block once one confirms it the other one will only be able to validate it but the reward goes to the one who confirmed it.

I do get your point but I'm more concerned about the double spend case. I mean for instance, if I broadcast tx A spending UTXO x to address B and then tx B spending the same UTXO x to address C. Don't these have different transaction ID?

If you send TX_A and TX_B at the same time, and miners A and B mine blocks X and Y at the same height, at the same time, each containing different transactions (A's containing TX_A, B's containing TX_B) then both blocks are considered valid, your node keeps both of them (necessarily treats one as valid and the other as valid-but-fork, usually this depends on millisecond precision level timing), and the next block at height xxx + 1 will determine which chain is the one with the most work that everyone will follow. If miner C mines on top of miner A's chain, then TX_A will be the valid one.

Thank you for breaking it down but is there any scenario where both tx A and tx B could end up confirmed on different forks? If I get it correctly, until a tx gets at least 1 confirmation, it's technically possible it's on the fork that lose right? 

[Mia Chloe]

I do get your point but I'm more concerned about the double spend case. I mean for instance, if I broadcast tx A spending UTXO x to address B and then tx B spending the same UTXO x to address C. Don't these have different transaction ID?

Yes they do but once one gets confirmed the other will get abandoned eventually and will go back to the mempool if it's still a valid transaction and by valid I mean it's not a double spend case. Concerning if two nodes confirm on different blocks the fact is the network will mostly drop the lighter block.

By lighter block I mean the block with way less transactions added on it. I think that's what they usually refer to as orphaning a block. The network isn't actually built to accept double spending as valid because it will end up making duplicate coins.

[coinlary]

I think what OP means is that he broadcasts a transaction and then when he later increases the fee of that transaction (RBF) which is a new transaction, with the nodes having either of the two transactions like nodes without Full RBF opt_in (which is rare today) having the original transaction while the another has the new transaction.  

Yep, I ommitted the paragraph 1B . I crossed it already.

[Comeacross]

Yes they do but once one gets confirmed the other will get abandoned eventually and will go back to the mempool if it's still a valid transaction and by valid I mean it's not a double spend case. Concerning if two nodes confirm on different blocks the fact is the network will mostly drop the lighter block.

By lighter block I mean the block with way less transactions added on it. I think that's what they usually refer to as orphaning a block. The network isn't actually built to accept double spending as valid because it will end up making duplicate coins.

Lighter in the sense of total transactions or lighter in terms of total PoW? Because as far as I know, nodes don't usually pick the chain with more transactions but the chain with the most accumulated PoW which is usually the longest chain.

So technically, this make it possible for even a block with fewer txs to likely win if it is on the chain that get extended first.

[Zaguru12]

~

Thank you for breaking it down but is there any scenario where both tx A and tx B could end up confirmed on different forks? If I get it correctly, until a tx gets at least 1 confirmation, it's technically possible it's on the fork that lose right?  

I think you need to read about longest chain to understand this things better because there is nothing like a fork here. If both miners with different transactions actually mine a block same time then the one with most work (longest chain) is the accepted one.

Yes they do but once one gets confirmed the other will get abandoned eventually and will go back to the mempool if it's still a valid transaction and by valid I mean it's not a double spend case. Concerning if two nodes confirm on different blocks the fact is the network will mostly drop the lighter block.

In OP’s case the other transaction wouldn’t be droping to the mempool because once the longest chain is accepted by the nodes as the valid version on the blockchain they update their individual mempools with the transactions in this confirmed block and there they will see that the other transaction has an input that has already been spent already and there for it’s considered invalid even the node having it will drop it.

So technically, this make it possible for even a block with fewer txs to likely win if it is on the chain that get extended first.

You’re right even an empty block (a block with only the coinbase transaction) can still be the longest chain. Read the replies again.

[Mia Chloe]

I think you need to read about longest chain to understand this things better because there is nothing like a fork here. If both miners with different transactions actually mine a block same time then the one with most work (longest chain) is the accepted one.

There's a fork but it's temporary the reason it exists is because the both transactions can be valid based on the temporary fork but it's dissolved once the network is able to Identify which of the chain is longer.

Lighter in the sense of total transactions or lighter in terms of total PoW? Because as far as I know, nodes don't usually pick the chain with more transactions but the chain with the most accumulated PoW which is usually the longest chain.
So technically, this make it possible for even a block with fewer txs to likely win if it is on the chain that get extended first.

Yeah but I'd sometimes just refer to it as the one with the most transaction sometimes because in most cases it has the higher chances of being picked as the valid one because it has a high POW. I think it all revolves around trying to minimise wastage of hash rates.

[hosemary]

Thank you for breaking it down but is there any scenario where both tx A and tx B could end up confirmed on different forks? If I get it correctly, until a tx gets at least 1 confirmation, it's technically possible it's on the fork that lose right? 

In BlackHatCoiner's scenario, both transactions A and B have 1 confirmations. One will receive the second confirmation while the other one won't receive more confirmations.

So technically, this make it possible for even a block with fewer txs to likely win if it is on the chain that get extended first.

It doesn't matter which block has more transactions at all. What matters is that which block is on the winning chain.

[hmbdofficial]

If coincidentally two mining node both confirmed the two transaction at the same time on different blocks, the miner with the longest chain will win and the second chain will become stale and the transactions in that block will become invalid.

In reality two mining node can’t confirm transactions at the same time but only one node will be able to confirm, then it relay  it to other node  to validate. And I think OP issue is about chain recognition from the old block.

[Cookdata]

If coincidentally two mining node both confirmed the two transaction at the same time on different blocks, the miner with the longest chain will win and the second chain will become stale and the transactions in that block will become invalid.

In reality two mining node can’t confirm transactions at the same time but only one node will be able to confirm, then it relay  it to other node  to validate. And I think OP issue is about chain recognition and reorganization.

Read the replies before you jump into thread with spam.

Theoretically or Practically, anyone you call it, two miners can mine the same transaction on different blocks at the same height but one with more blocks confirmations as longest chain will be valid while the less will be invalid which after the nodes reorganize the chain.
Look at the recent stale block at height 945189, the block is not valid.

This is the valid block 985189, the same height but only one is valid.

OP question is possibilities of transactions conflict on Mempool and the odd of getting mine by different miners and everyone has made input to answer him.

[Comeacross]

In BlackHatCoiner's scenario, both transactions A and B have 1 confirmations. One will receive the second confirmation while the other one won't receive more confirmations.

So this means the tx on the winning fork get it's second and subsequent confirmations and then considered final while the tx on the orphan fork gets dropped from the chain and probably goes back to the Mempool if it inputs are not spent on the winning chain.

Thank you all for sharing your opinions. I have gotten enough explanation. I will lock this thread immediately.