Mining question about conflicting transactions

[BlackHatCoiner]

So here it talks about how bitcoin solved the double-spend problem: https://learnmeabitcoin.com/guide/mining

To abstract, if you could make 1 transaction spending 5BTC and 1 other spending 3BTC while having only 6BTC would be possible if you could make both transactions at the same time. Some nodes will get the first transaction first, and some others the second. You would have accomplished the fact that every computer would only had 1 transaction from your address.

Now what I'm trying to understand here is the removal of any conflicting transactions. How exactly do computers remove the conflicting transactions? How 2 conflicting transactions look like?

Is it like summing all the bitcoins this address has received/sent and then checking if he/she is able to spend 8BTC?

[hosseinimr93]

It's possible that some nodes receive transaction A and some nodes receive transaction B. Nodes that received transaction A first, will reject transaction B and nodes that received transaction B first will reject transaction A.
In the unlikely event that both transactions are mined by two different miners, we will have two chains. Each of chains will have one confirmation. Once one of chains receives the second confirmation, that becomes the valid chain and the transaction in that chain becomes the valid transaction.
This is one of the reasons that exchanges require 6 confirmations for deposits.  

[Rath_]

To abstract, if you could make 1 transaction spending 5BTC and 1 other spending 3BTC while having only 6BTC would be possible if you could make both transactions at the same time. [...] How 2 conflicting transactions look like?

Your example would require someone to use the same inputs in both of these transactions. Transactions are conflicted if they attempt to spend the same inputs.

Some nodes will get the first transaction first, and some others the second [...] Now what I'm trying to understand here is the removal of any conflicting transactions. How exactly do computers remove the conflicting transactions?

Most nodes should reject the second transaction if they have the first one in their mempool even if it offers a lower fee. That is why using RBF is recommended in case the fee is set too low. Still, this does not make 0-conf transactions completely safe because of the race attack.

[BlackHatCoiner]

Your example would require someone to use the same inputs in both of these transactions. Transactions are conflicted if they attempt to spend the same inputs.

Are my thoughts of summing from the blockchain correct? It calculates from the blockchain how many bitcoins does that address have so he/she cannot spend 10BTC (5BTC twice) when he/she has only 5BTC. The person that will mine the transaction will see that this guy doesn't have 10BTC and will deny the second transaction.

How can you create conflicting transactions? I don't think bitcoin core lets you try.

[odolvlobo]

Your example would require someone to use the same inputs in both of these transactions. Transactions are conflicted if they attempt to spend the same inputs.

Are my thoughts of summing from the blockchain correct? It calculates from the blockchain how many bitcoins does that address have so he/she cannot spend 10BTC (5BTC twice) when he/she has only 5BTC. The person that will mine the transaction will see that this guy doesn't have 10BTC and will deny the second transaction.

How can you create conflicting transactions? I don't think bitcoin core lets you try.

No summing is necessary. Bitcoin doesn't track addresses. It tracks outputs. When a transaction spends from an address, it spends an entire output, and the excess is sent to a "change" address. If a node sees two transactions spending the same output, it will reject one of them.

One way to create two conflicting transactions might be to create the transactions using two separate copies of the same wallet.

[Rath_]

Are my thoughts of summing from the blockchain correct? It calculates from the blockchain how many bitcoins does that address have so he/she cannot spend 10BTC (5BTC twice) when he/she has only 5BTC.

No, the nodes do not even know what the balance is; they track UXTOs. Transaction outputs become UXTOs which can be later used as inputs in a new transaction. If a node receives a transaction which spends the same UXTOs as some other transaction, the new one is rejected.

How can you create conflicting transactions? I don't think bitcoin core lets you try.

There is abandontransaction RPC command but it won't work unless the transaction drops from the mempool. You could try playing with the '-zapwallettxes' parameter and delete the transaction manually but you are also very likely to fail due to transaction being already well-propagated. The same goes for Electrum. You can edit the wallet file and remove the transaction locally, but it is very likely that every server you connect to will reject your another transaction due to mempool conflict error.

[hosseinimr93]

No summing is necessary. Bitcoin doesn't track addresses. It tracks outputs. When a transaction spends from an address, it spends an entire output, and the excess is sent to a "change" address. If a node sees two transactions spending the same output, it will reject one of them.

Yes, no node will approve both of transactions. But the unlikely event OP is talking about is that both transactions are made at a same time. In this case, we don't know which node will receive transaction A first and which node will receive transaction B first. So some nodes have approved transaction A and some nodes have approved transaction B.
Now both transactions have the chance of being included in the next block.

A miner may mine a block including transaction A and another miner may mine a block including transaction B.
Now we have two different blocks. Both of them are valid if they are taken into account independently. So, we have two different chains.
Next blocks will determine that which of those transactions was the valid transaction.

Miners A will try to mine the next block considering the hash of block A (The block including transaction A) and miners B will try to mine the next block considering the hash of block B (The block including transaction B).

If miners A become successful, block A will be the valid block.
If miners B become successful, block B will be the valid block.

[hatshepsut93]

Now what I'm trying to understand here is the removal of any conflicting transactions. How exactly do computers remove the conflicting transactions? How 2 conflicting transactions look like?

The nodes will remove the second transaction that tries to spend the same input, but it's by no means a guarantee that the first transaction will be included in a block. When it comes to new transaction, full node's task is to propagate them through the network with a goal of eventually reaching all miners, and miners are the ones who actually decide which transaction to include in blocks. Generally they will choose the one with the highest fee. So, in your scenario when you try to get conflicting transaction to propagate through the network, you might have a scenario when when part of the miners know about transaction A and the other part knows about transaction B, but even if some miner knew about both transaction, they would never include both of them in a block, because such block would be invalid and rejected by network.