<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-03-08T15:17:22.917Z
2015-03-08T15:17:22.917Z
Jimmy Song
<blockquote>
  <p>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?</p>
</blockquote>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2015-03-08T17:03:45.493Z
2015-03-08T17:03:45.493Z
David A. Harding
<p>The probable combination of choices should equate to the desired expected value.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2015-03-09T08:51:37.410Z
2015-03-09T08:51:37.410Z
Jim Bob
<p>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?</p>

CC BY-SA 3.0
2015-03-08T09:08:06.530Z
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?
abeikverdi
CC BY-SA 3.0
2015-03-08T20:30:58.650Z
@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
CC BY-SA 3.0
2015-03-08T22:15:30.753Z
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
CC BY-SA 3.0
2015-03-09T00:24:01.170Z
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?
David Schwartz
CC BY-SA 3.0
2015-03-09T06:14:12.110Z
@DavidSchwartz trust he is not double-spending.
Alex
<confirmations>
Do I need N confirmations if I'm only worried about the transfer getting invalidated by a different block?
Alex
# Do I need N confirmations if I'm only worried about the transfer getting invalidated by a different block?

(Asked by: username_0 on 2015-03-08)

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?

**Tags:** confirmations

> **Comments:**
> **username_1**: 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?  
> **username_0**: @username_1 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!  
> **username_0**: 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.  
> **username_2**: 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?  
> **username_0**: @username_2 trust he is not double-spending.  

---

## 3 answers

### Answer by username_3 on 2015-03-08. Score: 1

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.


---

### Answer by username_4 on 2015-03-08. Score: 1

> 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.


---

### Answer by username_5 on 2015-03-09. Score: 0

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.


---

