<p>Your scenario is not completely clear, because you don't tell us whether the attacker is producing valid blocks or invalid blocks. You have also not defined whether your own wallet is a full-node or a thin client.</p>

<p>Let's first talk about how blocks are relayed through the network:<br>
When a new block is discovered, a node will announce via an <code>inv</code> (inventory) message that it has this new block. Other full nodes will send a <code>getdata</code> message, requesting the whole block. After receiving and validating the data, they will send an <code>inv</code> message to their peers to announce the new block to them.<br>
SPV nodes do not request the full block. They'll just get the block header, and if there are any transactions of interest, they'll specifically request proof for those to be sent via a <code>merkleblock</code> message. SPV nodes cannot fully verify the validity of new blocks, because they don't store the blockchain.</p>

<p>Now there is three different possible scenarios, and two types of wallets to consider:</p>

<p><strong>Attacker is producing invalid blocks</strong><br>
A SPV wallet may be fooled, because it can't verify the validity of a block. They still check that the block header's are well-formed. Some SPV wallets require multiple peers to tell them about the same block. Therefore, this attack may require additionally a <strong>Sybil attack</strong> or control of the SPV wallet's internet connection.<br>
Full nodes are not affected, because they'll reject invalid blocks.</p>

<p><strong>Attacker is producing valid blocks at low speed</strong><br>
A SPV wallet will reorganize to a longer chain when it hears about it from a different peer. So, again, the SPV wallet needs to be isolated from other information for this to work. As the information is valid, this attack may also work against full nodes. The attacked may notice the suspiciously slow update rate.</p>

<p><strong>Attacker is producing valid blocks with 51% of mining power</strong><br>
The attacker is faster than the whole rest of the network. By choosing to only build upon his own blocks, he can mine 100% of the blocks and still outpace the remaining network. The blocks are valid and therefore accepted by all nodes (until some sort of intervention). The attacker can censor transactions and even rollback a small number of blocks by starting from an earlier block but eventually overtaking the natural block chain tip. This is called a majority attack and breaks the axiomatic security assumption of Bitcoin that more than half the mining power is honest.</p>

<p><strong>How secure are six confirmations in an attacker's fork?</strong><br>
If you're caught in a Sybil attack, this will fool you. In every other case, you'll not be fooled, or the whole network is the target.</p>

CC BY-SA 3.0
2016-06-19T12:24:00.437Z
2016-06-19T12:24:00.437Z
Murch
<p>The valid Trxid lost in the orphaned block is queued into the next available block with delayed confirmation on the system.</p>

<p>The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place.</p>

<p>Digital Transactions with faster Block rate or lower Hashing power have a greater vulnerability to such an event </p>

CC BY-SA 3.0
2015-12-21T19:15:11.997Z
"The valid Trxid lost in the orphaned block is queued into the next available block with delayed confirmation on the system." That doesn't seem to answer the question. OP is asking about the situation where a client is cut off from the network and only sees blocks by the attacker. I think.
Jannes
CC BY-SA 3.0
2015-12-21T19:15:22.857Z
"The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place." That doesn't make sense. You can put 100 consecutive transactions even in 1 block if you want. 10 minutes doesn't have anything to do with that.
Jannes
CC BY-SA 3.0
2015-12-22T02:27:34.063Z
"The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place." this doesn't make any sense to me. This has nothing to do with 10 minute blocks. This answer doesn't seem to answer the OP questions.
abeikverdi
CC BY-SA 3.0
2015-12-21T16:37:42.760Z
2015-12-21T16:37:42.760Z
gooseling
<p>Once you send a transaction you broadcast it to the network. All full nodes receive that and will verify the transaction thus full nodes ignore the false blocks when submitted by miners and wait for the the correct block in future and assuming more than 50% of the miners are honest that false block will be orphaned.<br/>
However SPV clients only check for the longest chain and in that case will get fooled by the wrong block. <br/>
The attack you described is a 51% attack in which attacker has 50% and more of the whole hashing power and therefore is able to create fake blocks on top of each other which can result in a really devastating situation and is definitely a problem.</p>

CC BY-SA 3.0
2015-12-21T19:21:20.290Z
"assuming more than 50% of the miners are honest that false block will be orphaned." They don't need to assume more than 50% is honest. Even if only one miner is honest the valid chain will continue. The invalid blocks are just completely ignored, so that chain won't grow at all. This is when talking about *invalid* blocks (wrong signatures, block reward too high, etc.). Note that double-spends are NOT invalid transactions. Both transactions ARE valid, but only one of them ends up in whatever will be the final blockchain.
Jannes
CC BY-SA 3.0
2015-12-22T02:25:40.970Z
Yea its important to distinguish double spends and invalid transactions and I think the question didnt make that clear. "Even if only one miner is honest the valid chain will continue." but the valid chain is not accepted by the network since it doesn't have the valid proof of work. Its like you maintain a valid blockchain on your own but no cares about you! The valid chain is not valid until it gets the proof of work done. It is also gonna be an issue for SPVs since they only follow the longest chain that has put work in it.
abeikverdi
CC BY-SA 3.0
2015-12-21T08:34:23.060Z
2015-12-21T08:34:23.060Z
abeikverdi
<p>From what I understand, transactions are agglomerated into a block, proof of work is done by computing a hash value for the block, then added to the block chain. When a block is added to the block chain, then the transaction included in the block is considered to be confirmed. </p>

<p>How is the full node from which the block chain is queried decided? Or how many full node's block chain is a transaction checked against?</p>

<p>Suppose an attacker has a forked chain, and let us assume nothing about other full nodes' rejection or confirmation about this fork, can my transaction be checked against this forked chain of the attacker and not against other valid block chains maintained by honest full nodes? </p>

<p>Suppose I succeeded in 6 confirmations, but all these blocks are an attacker's fork. Is this a problem?</p>

CC BY-SA 3.0
2015-12-21T19:22:45.900Z
I think you're asking about the situation where you as a non-full-node (i.e. an SPV wallet on a phone for example) are connected only to nodes run by the attacker? And then you're fooled into believing the attacker's chain.
Jannes
<transactions><doublespend><blockchain-fork><full-node>
Will an attacker's forked branch of block chain be used in bitcoin confirmation?
user45979
# Will an attacker's forked branch of block chain be used in bitcoin confirmation?

(Asked by: username_0 on 2015-12-21)

From what I understand, transactions are agglomerated into a block, proof of work is done by computing a hash value for the block, then added to the block chain. When a block is added to the block chain, then the transaction included in the block is considered to be confirmed.

How is the full node from which the block chain is queried decided? Or how many full node's block chain is a transaction checked against?

Suppose an attacker has a forked chain, and let us assume nothing about other full nodes' rejection or confirmation about this fork, can my transaction be checked against this forked chain of the attacker and not against other valid block chains maintained by honest full nodes?

Suppose I succeeded in 6 confirmations, but all these blocks are an attacker's fork. Is this a problem?

**Tags:** transactions, doublespend, blockchain-fork, full-node

> **Comments:**
> **username_1**: I think you're asking about the situation where you as a non-full-node (i.e. an SPV wallet on a phone for example) are connected only to nodes run by the attacker? And then you're fooled into believing the attacker's chain.  

---

## 3 answers

### Answer by username_2 on 2016-06-19. Score: 1

Your scenario is not completely clear, because you don't tell us whether the attacker is producing valid blocks or invalid blocks. You have also not defined whether your own wallet is a full-node or a thin client.

Let's first talk about how blocks are relayed through the network:  
When a new block is discovered, a node will announce via an `inv` (inventory) message that it has this new block. Other full nodes will send a `getdata` message, requesting the whole block. After receiving and validating the data, they will send an `inv` message to their peers to announce the new block to them.  
SPV nodes do not request the full block. They'll just get the block header, and if there are any transactions of interest, they'll specifically request proof for those to be sent via a `merkleblock` message. SPV nodes cannot fully verify the validity of new blocks, because they don't store the blockchain.

Now there is three different possible scenarios, and two types of wallets to consider:

**Attacker is producing invalid blocks**  
A SPV wallet may be fooled, because it can't verify the validity of a block. They still check that the block header's are well-formed. Some SPV wallets require multiple peers to tell them about the same block. Therefore, this attack may require additionally a **Sybil attack** or control of the SPV wallet's internet connection.  
Full nodes are not affected, because they'll reject invalid blocks.

**Attacker is producing valid blocks at low speed**  
A SPV wallet will reorganize to a longer chain when it hears about it from a different peer. So, again, the SPV wallet needs to be isolated from other information for this to work. As the information is valid, this attack may also work against full nodes. The attacked may notice the suspiciously slow update rate.

**Attacker is producing valid blocks with 51% of mining power**  
The attacker is faster than the whole rest of the network. By choosing to only build upon his own blocks, he can mine 100% of the blocks and still outpace the remaining network. The blocks are valid and therefore accepted by all nodes (until some sort of intervention). The attacker can censor transactions and even rollback a small number of blocks by starting from an earlier block but eventually overtaking the natural block chain tip. This is called a majority attack and breaks the axiomatic security assumption of Bitcoin that more than half the mining power is honest.

**How secure are six confirmations in an attacker's fork?**  
If you're caught in a Sybil attack, this will fool you. In every other case, you'll not be fooled, or the whole network is the target.


---

### Answer by username_3 on 2015-12-21. Score: 0

The valid Trxid lost in the orphaned block is queued into the next available block with delayed confirmation on the system.

The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place.

Digital Transactions with faster Block rate or lower Hashing power have a greater vulnerability to such an event

> **Comments:**
> **username_1**: "The valid Trxid lost in the orphaned block is queued into the next available block with delayed confirmation on the system." That doesn't seem to answer the question. OP is asking about the situation where a client is cut off from the network and only sees blocks by the attacker. I think.  
> **username_1**: "The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place." That doesn't make sense. You can put 100 consecutive transactions even in 1 block if you want. 10 minutes doesn't have anything to do with that.  
> **username_4**: "The reason for maintaining ten minute gaps in each block is to reduce the possibility of 6 consecutive transactions taking place." this doesn't make any sense to me. This has nothing to do with 10 minute blocks. This answer doesn't seem to answer the OP questions.  

---

### Answer by username_4 on 2015-12-21. Score: 0

Once you send a transaction you broadcast it to the network. All full nodes receive that and will verify the transaction thus full nodes ignore the false blocks when submitted by miners and wait for the the correct block in future and assuming more than 50% of the miners are honest that false block will be orphaned.  
However SPV clients only check for the longest chain and in that case will get fooled by the wrong block.   
The attack you described is a 51% attack in which attacker has 50% and more of the whole hashing power and therefore is able to create fake blocks on top of each other which can result in a really devastating situation and is definitely a problem.

> **Comments:**
> **username_1**: "assuming more than 50% of the miners are honest that false block will be orphaned." They don't need to assume more than 50% is honest. Even if only one miner is honest the valid chain will continue. The invalid blocks are just completely ignored, so that chain won't grow at all. This is when talking about *invalid* blocks (wrong signatures, block reward too high, etc.). Note that double-spends are NOT invalid transactions. Both transactions ARE valid, but only one of them ends up in whatever will be the final blockchain.  
> **username_4**: Yea its important to distinguish double spends and invalid transactions and I think the question didnt make that clear. "Even if only one miner is honest the valid chain will continue." but the valid chain is not accepted by the network since it doesn't have the valid proof of work. Its like you maintain a valid blockchain on your own but no cares about you! The valid chain is not valid until it gets the proof of work done. It is also gonna be an issue for SPVs since they only follow the longest chain that has put work in it.  

---

