<blockquote>
<p><strong>what other protections are in place to ... Prevent this happening in the first place ...</strong>*</p>
</blockquote>
<p>None other than the one you identified. If a vendor of goods and services provides those before a payment transaction has been sufficiently confirmed, there is a risk that the payment will not occur. There is a longstanding convention that six confirmations provide a good level of certainty.</p>
<blockquote>
<p><strong>... Unwind in the event that there are multiple block confirmations subsequently</strong></p>
</blockquote>
<p>There is no provision for this for individual allegations of fraud. There is no Bitcoin body capable of determining which party is telling the truth. This is the same with other forms of cash. If you hand over your car for a handful of US Dollars in cash that turns out to be forgeries, you go to the police and courts, not to the Bureau of Engraving and Printing in the US Treasury department.</p>
<blockquote>
<p><strong>&quot;fraudulent block&quot;</strong></p>
</blockquote>
<p>That block contains thousands of valid honest transactions, so labelling it a &quot;fraudulent block&quot; seems a bit tendentious. Consider the old system of paper checks (cheques): After a vendor receives a check they take it to their bank who temporarily credit the vendors account pending clearance. The vendors bank send the check to the payer's bank, the payer's bank may reply saying the payer has insufficient funds. The vendors bank will then debit the vendors account the amount of the bounced check.</p>
<p>Describing the truck that delivers the check, along with thousands of others, as a &quot;fraudulent truck&quot; would be a bit strange and potentially misleading.</p>
<hr />
<ul>
<li>Bitcoin is cash, not a bank account.</li>
<li>Well-confirmed Bitcoin transactions are not reversible.</li>
<li>A payment system does not adjudicate disputes.</li>
</ul>

CC BY-SA 4.0
2024-06-02T11:43:19.577Z
I am aligned that Bitcoin is cash, akin to real dollars in that there are no inherent protections in the exchange of cash itself. Fraudulent block is incorrect, yes. The problem refers to a fraudulent transaction by a bad actor within a valid block, but I'm not disputing the real world implication. I'm interested in learning if the protocol has other methods to verify integrity of unspent transactions. I don't like the explanation that this type of attack is impossible without 51% of compute, in reality its easier to achieve than that. You answer this in the first part of your response - None
M.White
CC BY-SA 4.0
2024-06-03T14:29:22.810Z
@M.White: An unconfirmed transaction is a _payment promise_. A confirmed transaction is a payment.
Murch
CC BY-SA 4.0
2024-06-02T09:08:12.180Z
2024-06-02T09:20:46.700Z
2024-06-02T09:20:46.700Z
RedGrittyBrick
<p>Each source of information I look at that tackles this problem states that this type of fraud is essentially impossible at best and highly infeasible at worst. By my (very limited) understanding, the success of this attack is actually down to timing and luck rather than it needing a 51% control of hashing compute. The scenario I've been thinking about:</p>
<p>Initial State and assumptions:</p>
<ol>
<li>All nodes are at block height </li>
<li>No forks exist; all nodes are in consensus</li>
<li>Each new block takes the full normally distributed 10 minutes to confirm</li>
<li>In the below case, the 'fraudulent block' contains a transaction signed by the bad actor to themselves or to a colluding partner to consume the unspent input - to prevent the 'real' transaction confirming for the 'real' recipient. Yes - advise the 'real' recipient to wait for enough block confirmations to take place so that the attack is pointless - but lets assume someone is scammed into handing over goods/services/digital assets on the basis that the 'real' transaction is submitted and pending. I want to focus more on how the technology accounts for the possibility of the problem, rather than human intuition and intervention.</li>
</ol>
<p>Fraudulent Block Submission:</p>
<ol>
<li>An attacker successfully mines a fraudulent block +1 and propagates it through the network. This block contains the double spend attack transaction, leaving the 'real' transaction in the mempool where it's rejected because its considered a spent transaction, therefore excluded from any new block</li>
<li>Within a minute or two, the majority of the network receives and validates this block.</li>
<li>Nodes recognize +1 as the longest chain and switch to mining on top of it.</li>
</ol>
<p>Mining Block +2:</p>
<ol>
<li>Assume the next block +2 takes the full (normally distributed) 10 minutes to mine after +1 has been accepted.</li>
<li>Within the first 5 minutes, almost all nodes would have received, validated, and started working on block +1, given the propagation time is typically less than a couple of minutes.</li>
</ol>
<p>Given these conditions, here's how the scenario unfolds:</p>
<p>Propagation of Block +1:</p>
<ol>
<li>Once block +1 is propagated and validated across the network, all honest nodes will switch to the chain ending in +1.</li>
</ol>
<p>Mining Block +2:</p>
<ol>
<li>With all nodes working on the new longest chain, they will mine block +2 on top of +1.</li>
<li>The network will be in consensus that block +1 is part of the main chain, and thus any new blocks (including +2) will be built on top of +1.</li>
</ol>
<p>In this scenario, assuming the fraudulent block +1 propagates and is accepted as the longest chain by the majority of the network, all subsequent blocks (like +2) will indeed be built on this chain. In Summary:</p>
<ol>
<li>Propagation and Validation: Block +1 propagates and is validated quickly (within a couple of minutes), leading all nodes to switch to this chain.</li>
<li>Network Consensus: By 5 minutes into the 10-minute block interval, all nodes will be mining on the +1 chain due to its acceptance as the longest chain.</li>
<li>Subsequent Blocks: The next block +2 is highly likely to be mined on top of +1 since the entire network considers +1 as part of the longest chain.</li>
</ol>
<p>So, if we assume that the above case holds true it seems to me at least that a double spend attack IS quite feasible under the right conditions, so what other protections are in place to</p>
<ol>
<li>Prevent this happening in the first place</li>
<li>Unwind in the event that there are multiple block confirmations subsequently</li>
</ol>

CC BY-SA 4.0
2024-06-01T21:14:36.027Z
Can you describe *exactly* what way is your fraudulent block fraudulent? For example does it contain a transaction created by the same person as created the "real transaction" which spends the same inputs but has different outputs?
RedGrittyBrick
CC BY-SA 4.0
2024-06-01T21:23:49.113Z
Yes - this is the scenario exactly, i.e., payment is instead sent from the bad actor to themselves or to a colluding partner instead of the 'real' recipient. I will update the post - thanks
M.White
CC BY-SA 4.0
2024-06-01T21:38:17.383Z
See updated assumption, 4
M.White
<protocol><proof-of-work><nodes><doublespend><fraud>
How feasible is a double spend attack?
M.White
# How feasible is a double spend attack?

(Asked by: username_0 on 2024-06-01)

Each source of information I look at that tackles this problem states that this type of fraud is essentially impossible at best and highly infeasible at worst. By my (very limited) understanding, the success of this attack is actually down to timing and luck rather than it needing a 51% control of hashing compute. The scenario I've been thinking about:

Initial State and assumptions:

1. All nodes are at block height
2. No forks exist; all nodes are in consensus
3. Each new block takes the full normally distributed 10 minutes to confirm
4. In the below case, the 'fraudulent block' contains a transaction signed by the bad actor to themselves or to a colluding partner to consume the unspent input - to prevent the 'real' transaction confirming for the 'real' recipient. Yes - advise the 'real' recipient to wait for enough block confirmations to take place so that the attack is pointless - but lets assume someone is scammed into handing over goods/services/digital assets on the basis that the 'real' transaction is submitted and pending. I want to focus more on how the technology accounts for the possibility of the problem, rather than human intuition and intervention.

Fraudulent Block Submission:

1. An attacker successfully mines a fraudulent block +1 and propagates it through the network. This block contains the double spend attack transaction, leaving the 'real' transaction in the mempool where it's rejected because its considered a spent transaction, therefore excluded from any new block
2. Within a minute or two, the majority of the network receives and validates this block.
3. Nodes recognize +1 as the longest chain and switch to mining on top of it.

Mining Block +2:

1. Assume the next block +2 takes the full (normally distributed) 10 minutes to mine after +1 has been accepted.
2. Within the first 5 minutes, almost all nodes would have received, validated, and started working on block +1, given the propagation time is typically less than a couple of minutes.

Given these conditions, here's how the scenario unfolds:

Propagation of Block +1:

1. Once block +1 is propagated and validated across the network, all honest nodes will switch to the chain ending in +1.

Mining Block +2:

1. With all nodes working on the new longest chain, they will mine block +2 on top of +1.
2. The network will be in consensus that block +1 is part of the main chain, and thus any new blocks (including +2) will be built on top of +1.

In this scenario, assuming the fraudulent block +1 propagates and is accepted as the longest chain by the majority of the network, all subsequent blocks (like +2) will indeed be built on this chain. In Summary:

1. Propagation and Validation: Block +1 propagates and is validated quickly (within a couple of minutes), leading all nodes to switch to this chain.
2. Network Consensus: By 5 minutes into the 10-minute block interval, all nodes will be mining on the +1 chain due to its acceptance as the longest chain.
3. Subsequent Blocks: The next block +2 is highly likely to be mined on top of +1 since the entire network considers +1 as part of the longest chain.

So, if we assume that the above case holds true it seems to me at least that a double spend attack IS quite feasible under the right conditions, so what other protections are in place to

1. Prevent this happening in the first place
2. Unwind in the event that there are multiple block confirmations subsequently

**Tags:** protocol, proof-of-work, nodes, doublespend, fraud

> **Comments:**
> **username_1**: Can you describe *exactly* what way is your fraudulent block fraudulent? For example does it contain a transaction created by the same person as created the "real transaction" which spends the same inputs but has different outputs?  
> **username_0**: Yes - this is the scenario exactly, i.e., payment is instead sent from the bad actor to themselves or to a colluding partner instead of the 'real' recipient. I will update the post - thanks  
> **username_0**: See updated assumption, 4  

---

## 1 answers

### Answer by username_1 on 2024-06-02. Score: 2 | Accepted answer

> **what other protections are in place to ... Prevent this happening in the first place ...**\*

None other than the one you identified. If a vendor of goods and services provides those before a payment transaction has been sufficiently confirmed, there is a risk that the payment will not occur. There is a longstanding convention that six confirmations provide a good level of certainty.

> **... Unwind in the event that there are multiple block confirmations subsequently**

There is no provision for this for individual allegations of fraud. There is no Bitcoin body capable of determining which party is telling the truth. This is the same with other forms of cash. If you hand over your car for a handful of US Dollars in cash that turns out to be forgeries, you go to the police and courts, not to the Bureau of Engraving and Printing in the US Treasury department.

> **"fraudulent block"**

That block contains thousands of valid honest transactions, so labelling it a "fraudulent block" seems a bit tendentious. Consider the old system of paper checks (cheques): After a vendor receives a check they take it to their bank who temporarily credit the vendors account pending clearance. The vendors bank send the check to the payer's bank, the payer's bank may reply saying the payer has insufficient funds. The vendors bank will then debit the vendors account the amount of the bounced check.

Describing the truck that delivers the check, along with thousands of others, as a "fraudulent truck" would be a bit strange and potentially misleading.

---

* Bitcoin is cash, not a bank account.
* Well-confirmed Bitcoin transactions are not reversible.
* A payment system does not adjudicate disputes.

> **Comments:**
> **username_0**: I am aligned that Bitcoin is cash, akin to real dollars in that there are no inherent protections in the exchange of cash itself. Fraudulent block is incorrect, yes. The problem refers to a fraudulent transaction by a bad actor within a valid block, but I'm not disputing the real world implication. I'm interested in learning if the protocol has other methods to verify integrity of unspent transactions. I don't like the explanation that this type of attack is impossible without 51% of compute, in reality its easier to achieve than that. You answer this in the first part of your response - None  
> **username_2**: @username_0: An unconfirmed transaction is a _payment promise_. A confirmed transaction is a payment.  

---

