# Do I need N confirmations if I'm only worried about the transfer getting invalidated by a different block?

Say I ask Bob a lot of bitcoins in exchange for an expensive product. Bob sends it to me and I wait 1 confirmation to send him the product, because I trust Bob. I am only worried about the transaction being invalidated by a block that doesn't contain it getting solved. How can I determine a "safe" number of confirmations as to make that risk negligible? When I read about the "6 confirmations" thing it's always about preventing double-spending, and some even say that if you trust the other part you don't even need confirmations. Wouldn't that (zero confirmations) put the receiver in great risk of having the transfer invalidated?

• Why should a transaction get invalidated? Because the winner miner hasn't added it to his block yet, doesnt mean that the transaction will be invalidated. Next miner will add it to his proposed block. Can you clarify more? Commented Mar 8, 2015 at 9:08
• @abeikverdi Can't the transaction be "lost" somehow, for instance if Bob does not pay a transaction fee? Or if, for some reason, it only reaches a few nodes? I remember reading something like that, though I might be mistaken, since I only grasp the basic concepts on Bitcoin. Thanks!
– Alex
Commented Mar 8, 2015 at 20:30
• Orphaned blocks, that's the word I was looking for. It seems the 6 confirmation rule applies to it too, though I don't understand while it is likely that a transaction will be added to one of the 6 blocks if it was in an orphaned block in the first place.
– Alex
Commented Mar 8, 2015 at 22:15
• If you trust the sender, why do you care if the transaction is invalidated? The sender will just make another transaction, right? Otherwise, what does it mean to say you trust him? Commented Mar 9, 2015 at 0:24
• @DavidSchwartz trust he is not double-spending.
– Alex
Commented Mar 9, 2015 at 6:14

A transaction can only be invalidated by an attempt to double-spend. That is, the same transaction can be in block X or block X+1 or block X+n as long as there is no double-spend associated with it.

If you want to make sure that a transaction goes into a block soon-ish, try to add a fee that's sufficient to make a miner want to add it to a block. In that case, you only need a couple confirmations as being an orphan block after that is exceedingly unlikely.

because I trust Bob. I am only worried about the transaction being invalidated by a block that doesn't contain it getting solved. How can I determine a "safe" number of confirmations as to make that risk negligible?

The naïve answer is that if you trust Bob and his transaction is valid and pays a reasonable transaction fee, you can accept it with zero confirmations.

However, your question hints at a situation where the naïve protocol can fail: by trusting Bob's transactions, you also trust everyone who has paid Bob. If they double spend the inputs they paid Bob, then Bob's payment to you becomes invalid.

If you really trust Bob, that's ok---you can just re-invoice him and he'll create a new transaction. But if you aren't sure that Bob will pay a second invoice, then it's always best to wait for as many confirmations as possible before accepting his payment.

The standard advice to wait for 6 confirmations---an average of one hour of proof of work---is sufficient to protect most transactions.

The probable combination of choices should equate to the desired expected value.

Almost certainty of the transaction can be approximated by the almost certainty of the work performed, in the case of Bitcoin and Proof-of-Work generally. There are a few papers with constructions of certainty relative to rates of work performed.

Ripple achieves almost certainty in 10 seconds on average. Considering how well if functions, long run certainty should be judged by the strength of the distributed model and some key theoreticians. They have managed cryptocurrency problems with high efficiency.

Proof-of-Stake coins still may have some key holes despite their performance promise. Some higher profile PoS coins had their primary exchanges hacked, and a potential vulnerability was emphasized, driving down their market values. They can be the fastest, but enforcing transaction order never seems to be conceptually complete.

Risk of failure should probably be bounded with conventional financial forms like the Kelly Criterion.