<p><a href="https://en.wikipedia.org/wiki/Double-spending">Double-spending</a> has nothing to do with double clicking the send button.</p>

<p>It involves a malicious user, who will not use the standard client. It will hack one to avoid any client-side limits, sending two transactions to a different side of a blockchain fork, so both sides don't know about the transaction sent to the counterpart and includes the transaction in their forked version.</p>

<p>If you manage to do so while using both transactions to pay for something and are accepted, after the reorganization (the process by which forks are resolved) only one side of the fork will be mantained, so the blockchain will be OK as only one transaction will be kept, but you got both payments effectively using the same coins to pay two different merchants and one of them will lose what you paid.</p>

<p>As you can see, it is not an usual scenario. Forks are more or less common but not really deep as they typically get resolved within a single block. That's why it is recommended to accept a transaction only after six confirmations, as a fork of six blocks is almost impossible to appear under normal circumstances. But do note that even this has happened, when a bug between software versions kept some miners from agreeing to mine on what would otherwise have been the consensus branch.</p>

CC BY-SA 3.0
2014-01-10T17:00:05.660Z
Thanks for your crystal clear answer frisco... It's probably not as simple and possible for the standard-client to refuse everything that is NOT the standard-client... I mean this from the perspective of a new coin, because what is already out there is out there..
AlCohol
CC BY-SA 3.0
2014-01-10T17:31:45.510Z
No, you never can control the other side of a connection, as long as it follows the stablished protocol you can not be sure if it is a standard client or one guy sending the bits one by one.
frisco
CC BY-SA 3.0
2014-01-10T16:05:50.723Z
2014-01-11T09:21:33.820Z
2014-01-11T09:21:33.820Z
frisco
<p>Let's say you have a 15 second block time, and after your first transaction, your wallet's send button is frozen, and you have to wait for 2.5 minutes before you can send another transaction.</p>

<p>Would this prevent somebody from <a href="https://en.wikipedia.org/wiki/Double-spending" rel="nofollow">doublespending</a>?</p>

<p>BTW: in case you want to ask how this could be enforced on the send button: Hmmmm maybe with something like <a href="https://en.wikipedia.org/wiki/Scrypt" rel="nofollow">scrypt</a> which is timebased.</p>

CC BY-SA 3.0
2014-01-10T12:41:31.743Z
Possible duplicate of http://bitcoin.stackexchange.com/q/4974/11862 and http://bitcoin.stackexchange.com/q/8563/11862
oleksii
CC BY-SA 3.0
2014-01-10T12:53:48.780Z
oleksii I admit that I'm asking the same questions, but is it correct that enforcing a 2,5 minute transaction limit could stop doublespending in this scenario?
AlCohol
<bitcoin-core><doublespend>
Could this stop double-spending?
AlCohol
# Could this stop double-spending?

(Asked by: username_0 on 2014-01-10)

Let's say you have a 15 second block time, and after your first transaction, your wallet's send button is frozen, and you have to wait for 2.5 minutes before you can send another transaction.

Would this prevent somebody from [doublespending](https://en.wikipedia.org/wiki/Double-spending)?

BTW: in case you want to ask how this could be enforced on the send button: Hmmmm maybe with something like [scrypt](https://en.wikipedia.org/wiki/Scrypt) which is timebased.

**Tags:** bitcoin-core, doublespend

> **Comments:**
> **username_1**: Possible duplicate of http://bitcoin.stackexchange.com/q/4974/11862 and http://bitcoin.stackexchange.com/q/8563/11862  
> **username_0**: username_1 I admit that I'm asking the same questions, but is it correct that enforcing a 2,5 minute transaction limit could stop doublespending in this scenario?  

---

## 1 answers

### Answer by username_2 on 2014-01-10. Score: 10

[Double-spending](https://en.wikipedia.org/wiki/Double-spending) has nothing to do with double clicking the send button.

It involves a malicious user, who will not use the standard client. It will hack one to avoid any client-side limits, sending two transactions to a different side of a blockchain fork, so both sides don't know about the transaction sent to the counterpart and includes the transaction in their forked version.

If you manage to do so while using both transactions to pay for something and are accepted, after the reorganization (the process by which forks are resolved) only one side of the fork will be mantained, so the blockchain will be OK as only one transaction will be kept, but you got both payments effectively using the same coins to pay two different merchants and one of them will lose what you paid.

As you can see, it is not an usual scenario. Forks are more or less common but not really deep as they typically get resolved within a single block. That's why it is recommended to accept a transaction only after six confirmations, as a fork of six blocks is almost impossible to appear under normal circumstances. But do note that even this has happened, when a bug between software versions kept some miners from agreeing to mine on what would otherwise have been the consensus branch.

> **Comments:**
> **username_0**: Thanks for your crystal clear answer username_2... It's probably not as simple and possible for the standard-client to refuse everything that is NOT the standard-client... I mean this from the perspective of a new coin, because what is already out there is out there..  
> **username_2**: No, you never can control the other side of a connection, as long as it follows the stablished protocol you can not be sure if it is a standard client or one guy sending the bits one by one.  

---

