<blockquote>
  <p>Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain</p>
</blockquote>

<p>This is incorrect. A block that contains an invalid transaction is invalid, period.</p>

<p>The network's rule is that the longest(*) <strong>valid</strong> chain is the one to be treated as correct. A chain with any invalid blocks in it is ignored by full nodes on the network.</p>

<p>Now, lightweight nodes on the network do not perform full validation, and thus cannot tell whether the longest chain is in fact valid or not, and thus they'll accept any chain. However, generally lightweight clients are only used by individuals that don't participate in much economic activity. A store that sells real world items for BTC is very much incentivized to use a full node that will never be fooled by this. </p>

<p>Furthermore, since creating a block is expensive, few miners will be willing to produce a block that contains invalid transactions, as such blocks will eventually not be considered acceptable to the network, and thus not result in any income for the miner. This long-term effect that economically-relevant full nodes have on miners through incentives in fact conveys security to lightweight nodes.</p>

<blockquote>
  <p>If so, doesn't it make bitcoin transactions slow to process ? I already know that a transaction can be validated by a full node client and that you don't need to wait 10 minutes for the block to be in the blockchain, but if you need 30 minutes to be able to spend the money, doesn't it make transactions slow ?</p>
</blockquote>

<p>Unless you trust the sender, you always need to wait for a number of confirmations, as there is always a chance that a (short) non-malicious reorganization of the chain happens, which confirms a conflicting transaction to the one that pays you.</p>

<p>This makes Bitcoin, in adversarial settings, much more appropriate as a settlement layer than as a payment system. And at that, it excels. Compared to say a credit card payment, the receiver knows the transaction is final within hours, compared to maybe months for a credit card payment.</p>

<p>This is an inherent restriction of a public consensus systems: it is inherently hard and slow to get the entire world to agree on an exact state of the ledger. For payment solutions people are building layers on top, which take advantage of the guaranteed settlement, but permit payments in a direct fashion with just knowledge of the involved parties. The Lightning Network is a good example of this.</p>

<p>(*) Technically it is not the longest chain that matters, but the chain with the most work. These definitions are almost always identical, but in the few edge cases where they differ, the difference is important.</p>

CC BY-SA 4.0
2019-12-08T21:37:21.030Z
Ok, that make sense, thanks. While i'm here, i was reading about the double spending issue and i read about Finney attack (https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack) is there still no way to prevent this attack ?
lairv
CC BY-SA 4.0
2019-12-08T21:46:12.777Z
I expanded my answer a bit. A Finney attack is inherent weakness of this sort of system, it is not solvable at the blockchain layer.
Pieter Wuille
CC BY-SA 4.0
2019-12-08T21:26:19.050Z
2019-12-08T21:55:31.343Z
2019-12-08T21:55:31.343Z
Pieter Wuille
<p>I'm currently reading "Mastering Bitcoin" (i haven't finished it tho, but i don't see my answer and it bother me so I prefer asking it here) and there's something i don't understand. So from what I understand the "valid" blockchain is the one which has the most blocks in it. But what happens if :</p>

<ul>
<li>a "hacker" is lucky with the hash function and manage to add a "wrong" block to the blockchain, in which, let's say that someone gives him 1BTC (even if there is no way to make a false transaction to receive 1BTC, he will at least have the bitcoins from mining a block)</li>
<li>Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain</li>
</ul>

<p>But what happens if he buy something with this 1BTC during those few minutes ? If for example, he buys a coffee, or some real items ? What prevents him from doing that ?</p>

<p>Is there a rule that makes that you can spend bitcoins from a transaction output only if the transaction is "old enough" (which mean that 3 or 4 blocks has been added after the block that contains the transaction) ?</p>

<p>If so, doesn't it make bitcoin transactions slow to process ? I already know that a transaction can be validated by a full node client and that you don't need to wait 10 minutes for the block to be in the blockchain, but if you need 30 minutes to be able to spend the money, doesn't it make transactions slow ?</p>

<p>Thank you in advance</p>

<p>PS : By the way i'm sorry if the term "short fork" is not the right expression but i didn't know how to call it</p>

<transactions><doublespend><fraud>
How does the blockchain prevent spending money during a "short fork"?
lairv
# How does the blockchain prevent spending money during a "short fork"?

(Asked by: username_0 on 2019-12-08)

I'm currently reading "Mastering Bitcoin" (i haven't finished it tho, but i don't see my answer and it bother me so I prefer asking it here) and there's something i don't understand. So from what I understand the "valid" blockchain is the one which has the most blocks in it. But what happens if :

* a "hacker" is lucky with the hash function and manage to add a "wrong" block to the blockchain, in which, let's say that someone gives him 1BTC (even if there is no way to make a false transaction to receive 1BTC, he will at least have the bitcoins from mining a block)
* Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain

But what happens if he buy something with this 1BTC during those few minutes ? If for example, he buys a coffee, or some real items ? What prevents him from doing that ?

Is there a rule that makes that you can spend bitcoins from a transaction output only if the transaction is "old enough" (which mean that 3 or 4 blocks has been added after the block that contains the transaction) ?

If so, doesn't it make bitcoin transactions slow to process ? I already know that a transaction can be validated by a full node client and that you don't need to wait 10 minutes for the block to be in the blockchain, but if you need 30 minutes to be able to spend the money, doesn't it make transactions slow ?

Thank you in advance

PS : By the way i'm sorry if the term "short fork" is not the right expression but i didn't know how to call it

**Tags:** transactions, doublespend, fraud


---

## 1 answers

### Answer by username_1 on 2019-12-08. Score: 5 | Accepted answer

> Then the blochain of the "hacker" will have 1 block more than the others, thus it should be, at least for a few minutes, the "valid" blockchain

This is incorrect. A block that contains an invalid transaction is invalid, period.

The network's rule is that the longest(\*) **valid** chain is the one to be treated as correct. A chain with any invalid blocks in it is ignored by full nodes on the network.

Now, lightweight nodes on the network do not perform full validation, and thus cannot tell whether the longest chain is in fact valid or not, and thus they'll accept any chain. However, generally lightweight clients are only used by individuals that don't participate in much economic activity. A store that sells real world items for BTC is very much incentivized to use a full node that will never be fooled by this.

Furthermore, since creating a block is expensive, few miners will be willing to produce a block that contains invalid transactions, as such blocks will eventually not be considered acceptable to the network, and thus not result in any income for the miner. This long-term effect that economically-relevant full nodes have on miners through incentives in fact conveys security to lightweight nodes.

> If so, doesn't it make bitcoin transactions slow to process ? I already know that a transaction can be validated by a full node client and that you don't need to wait 10 minutes for the block to be in the blockchain, but if you need 30 minutes to be able to spend the money, doesn't it make transactions slow ?

Unless you trust the sender, you always need to wait for a number of confirmations, as there is always a chance that a (short) non-malicious reorganization of the chain happens, which confirms a conflicting transaction to the one that pays you.

This makes Bitcoin, in adversarial settings, much more appropriate as a settlement layer than as a payment system. And at that, it excels. Compared to say a credit card payment, the receiver knows the transaction is final within hours, compared to maybe months for a credit card payment.

This is an inherent restriction of a public consensus systems: it is inherently hard and slow to get the entire world to agree on an exact state of the ledger. For payment solutions people are building layers on top, which take advantage of the guaranteed settlement, but permit payments in a direct fashion with just knowledge of the involved parties. The Lightning Network is a good example of this.

(\*) Technically it is not the longest chain that matters, but the chain with the most work. These definitions are almost always identical, but in the few edge cases where they differ, the difference is important.

> **Comments:**
> **username_0**: Ok, that make sense, thanks. While i'm here, i was reading about the double spending issue and i read about Finney attack (https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack) is there still no way to prevent this attack ?  
> **username_1**: I expanded my answer a bit. A Finney attack is inherent weakness of this sort of system, it is not solvable at the blockchain layer.  

---

