0

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
3
  • 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? Commented Jun 1 at 21:14
  • 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
    Commented Jun 1 at 21:23
  • See updated assumption, 4
    – M.White
    Commented Jun 1 at 21:38

1 Answer 1

2

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.
2
  • 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
    Commented Jun 2 at 11:43
  • 1
    @M.White: An unconfirmed transaction is a payment promise. A confirmed transaction is a payment.
    – Murch
    Commented Jun 3 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.