<h2>Double spending</h2>
<p>Suppose Alice has a bitcoin, an unspent transaction output (UTXO) worth 1.001 BTC.</p>
<p>Using a computer in Chicago, Alice creates a transaction that uses that UTXO to pay 1 BTC to Bob.</p>
<p>Using remote access to a computer in Tokyo, Alice creates a transaction that uses that same UTXO to pay 1 BTC to Carol.</p>
<p>Alice is a bad person and is trying to cheat either Bob or Carol.</p>
<p>A Miner in Chicago sees the Chicago transaction and mines a new block containing the transaction which pays Bob.</p>
<p>A Miner in Tokyo sees the Tokyo transaction and mines a new block containing the transaction which pays Carol.</p>
<p>People in Chicago see the Chicago block which pays Bob</p>
<p>People in Tokyo see the Tokyo block which pays Carol</p>
<p>People in Chicago see the Tokyo block and reject it as a double spend because the UTXO has already been used to pay Bob not Carol</p>
<p>People in Tokyo see the Chicago block and reject it as a double spend because the UTXO has already been used to pay Carol not Bob</p>
<p>Now half the world thinks Bob was paid and half the world thinks Carol was paid. Unless we have some way to put these blocks, and the transactions in them, into the same order everywhere in the world, the bitcoin network will fall into chaos.</p>
<p>We need some way to sort the Tokyo and Chicago blocks into an order which does not depend on how near you are to Tokyo or Chicago. This way everyone can agree whether Bob has the 1 BTC or Carol does. Then Alice does not get to use her money twice.</p>
<hr />
<h2>Validation</h2>
<p>After creating a new block with a hash less than the target,  miners don't need to verify or validate the blocks they produce because they already validated everything before starting to mine.</p>
<p>All nodes, whether wallets, miners or other types, validate as much data as they can as soon as they receive it. No node cares whether other nodes validate anything because no full-node trusts any other node.</p>
<p>Validation is different from confirmation. Confirmation is simply a count of how many blocks have been mined since the block containing a transaction. The block that contains the transaction is included in the count.</p>

CC BY-SA 4.0
2022-04-08T08:49:44.277Z
Thank you. If Alice makes payment to Bob first and then another payment to Carol next (both of these transactions are now sitting in the mempool waiting to picked up by the miner), as soon as one of the transactions, say transaction to Carol is picked up, then the first payment to Bob will not go through right? 

To my second question, how does a miner validate a transaction in the mempool?
HeyDoeFarm
CC BY-SA 4.0
2022-04-08T09:57:06.583Z
@HeyDoeFarm: The point is different miners receive the  two draft-transactions in different orders at different times as explained above.
RedGrittyBrick
CC BY-SA 4.0
2022-04-11T21:23:20.297Z
Thank you. So does that mean that the transaction that gets included in the block is not based on time or order of the transactions but rather by which transaction gets picked up by the faster miner?
HeyDoeFarm
CC BY-SA 4.0
2022-04-05T09:14:41.147Z
2022-04-05T09:24:02.383Z
2022-04-05T09:24:02.383Z
RedGrittyBrick
<p>If there is double spending occuring, I don't understand why the longest chain rule would decrease the likelihood for only one transaction to be confirmed.</p>
<p>Can someone explain step by step why this makes sense logically? I've scoured through youtube videos but they do not explain the logic behind this. The videos only describes using the longest chain rule.</p>
<p>I also have one additional question. Are all the miners also verifying that the block that is solved is correct once it's solved?</p>

CC BY-SA 4.0
2022-04-06T09:00:23.410Z
"decrease the likelihood for only one transaction to be confirmed" - did you mean "decrease the likelihood for more than one transaction to be confirmed"? In each full node's own view, there's always only one transaction (among double-spending ones) to be confirmed. The problem is different nodes may have different views/decisions on which transaction to include, which then requires a mechanism to achieve a consensus among nodes.
Chris Chen
<doublespend><best-chain>
Why does the longest chain rule make the most sense to deter double spending?
HeyDoeFarm
# Why does the longest chain rule make the most sense to deter double spending?

(Asked by: username_0 on 2022-04-05)

If there is double spending occuring, I don't understand why the longest chain rule would decrease the likelihood for only one transaction to be confirmed.

Can someone explain step by step why this makes sense logically? I've scoured through youtube videos but they do not explain the logic behind this. The videos only describes using the longest chain rule.

I also have one additional question. Are all the miners also verifying that the block that is solved is correct once it's solved?

**Tags:** doublespend, best-chain

> **Comments:**
> **username_1**: "decrease the likelihood for only one transaction to be confirmed" - did you mean "decrease the likelihood for more than one transaction to be confirmed"? In each full node's own view, there's always only one transaction (among double-spending ones) to be confirmed. The problem is different nodes may have different views/decisions on which transaction to include, which then requires a mechanism to achieve a consensus among nodes.  

---

## 1 answers

### Answer by username_2 on 2022-04-05. Score: 1

## Double spending

Suppose Alice has a bitcoin, an unspent transaction output (UTXO) worth 1.001 BTC.

Using a computer in Chicago, Alice creates a transaction that uses that UTXO to pay 1 BTC to Bob.

Using remote access to a computer in Tokyo, Alice creates a transaction that uses that same UTXO to pay 1 BTC to Carol.

Alice is a bad person and is trying to cheat either Bob or Carol.

A Miner in Chicago sees the Chicago transaction and mines a new block containing the transaction which pays Bob.

A Miner in Tokyo sees the Tokyo transaction and mines a new block containing the transaction which pays Carol.

People in Chicago see the Chicago block which pays Bob

People in Tokyo see the Tokyo block which pays Carol

People in Chicago see the Tokyo block and reject it as a double spend because the UTXO has already been used to pay Bob not Carol

People in Tokyo see the Chicago block and reject it as a double spend because the UTXO has already been used to pay Carol not Bob

Now half the world thinks Bob was paid and half the world thinks Carol was paid. Unless we have some way to put these blocks, and the transactions in them, into the same order everywhere in the world, the bitcoin network will fall into chaos.

We need some way to sort the Tokyo and Chicago blocks into an order which does not depend on how near you are to Tokyo or Chicago. This way everyone can agree whether Bob has the 1 BTC or Carol does. Then Alice does not get to use her money twice.

---

## Validation

After creating a new block with a hash less than the target, miners don't need to verify or validate the blocks they produce because they already validated everything before starting to mine.

All nodes, whether wallets, miners or other types, validate as much data as they can as soon as they receive it. No node cares whether other nodes validate anything because no full-node trusts any other node.

Validation is different from confirmation. Confirmation is simply a count of how many blocks have been mined since the block containing a transaction. The block that contains the transaction is included in the count.

> **Comments:**
> **username_0**: Thank you. If Alice makes payment to Bob first and then another payment to Carol next (both of these transactions are now sitting in the mempool waiting to picked up by the miner), as soon as one of the transactions, say transaction to Carol is picked up, then the first payment to Bob will not go through right?   To my second question, how does a miner validate a transaction in the mempool?  
> **username_2**: @username_0: The point is different miners receive the  two draft-transactions in different orders at different times as explained above.  
> **username_0**: Thank you. So does that mean that the transaction that gets included in the block is not based on time or order of the transactions but rather by which transaction gets picked up by the faster miner?  

---

