<p>Transactions are the same before and after confirmation. Each confirmation just means that it has been mined into a block. </p>

CC BY-SA 3.0
2016-01-16T00:27:33.027Z
2016-01-16T00:27:33.027Z
Richard
<p>There is no difference between a confirmed and unconfirmed transaction, which is why you need the full blockchain to verify exactly what you're seeing.</p>

<p>As for storage: A confirmed transaction will have affected the UTXO set by consuming/spending old UTXO's and creating some new ones. </p>

<p>If your node also maintains a mempool, it holds transactions in memory (not anywhere persistent), and transaction selection is based on (i) validation rules and (ii) the node's local policy. </p>

<p>An interesting case is if your broadcasting transactions with non-standard outputs: nodes might refuse to allow them into the mempool, and refuse to relay them. Should a miner hear about the transaction, he can still include it in a block however. So the block would override a node's policy of not accepting these transactions. </p>

<p>A transaction that can <em>never</em> confirm is due a rule violation, instead of local policy. An example would be spending outputs which don't exist, or a signature which is entirely invalid. </p>

CC BY-SA 3.0
2016-01-17T15:25:05.133Z
2016-01-17T15:25:05.133Z
karimkorun
<p>Technically speaking, the difference between a confirmed transaction and an unconfirmed transaction is that confirmed transactions have been hashed into a block, where the header of that block hashes to an extremely unlikely value. They are set in stone within the block and cannot be changed as long as that block remains part of the best chain. Unconfirmed transactions live by themselves, just a few kilobytes of data floating around the network, waiting to be hashed into a block. </p>

CC BY-SA 3.0
2016-01-15T23:43:09.873Z
I know all this about blocks and PoW, but what happens to THE ACTUAL TRANSACTION after a confirmation? Blocks "establish that a transaction is final" -- but is a flag bit set somewhere? Is data moved or copied or deleted from RAM or the file system? Does the client care at all whether or not a Tx is confirmed? Do confirmed Tx's have any special properties besides the USER feeling better about it?
pinhead
CC BY-SA 3.0
2016-01-15T23:44:48.343Z
Technically, no, the transaction data is exactly the same as the unconfirmed data before it was put into the block.
morsecoder
CC BY-SA 3.0
2016-01-15T23:38:09.733Z
2016-01-16T19:17:27.343Z
2016-01-16T19:17:27.343Z
morsecoder
<p>when we speak about specific transaction: no. The unconfirmed transaction looks exactly the same as the same transaction with 1,2.. confirmations.</p>

<p>yes. There are 3 types of transaction: confirmed, unconfirmed, and nonexistent</p>

<p>example of nonexistent are those 10BTC I'll give you tomorrow.</p>

<p>difference between unconfirmed and nonexistent is not "obvious"</p>

<p>When you see an Unconfirmed tx on your PC, this does not "guarantee" that everybody else sees it too. If internet connectivity fails, you may be precisely the only person who sees it.</p>

<p>Unconfirmed transactions can be very different from confirmed, in many ways:</p>

<p>Unconfirmed transaction can spend funds that already have been spend, or funds that never existed.</p>

<p>Unconfirmed transaction get lost in the Internet (never get confirmed).</p>

<p>Unconfirmed transaction can be reversed and be replaced by different Unconfirmed transaction sending the funds to somebody else.</p>

<p>Unconfirmed transaction can contain technical error that prevent it to be confirmed.</p>

<p>Unconfirmed transaction can have low fee (less than dust limit) and this can cause confirmation delay of 12 or more hours.</p>

<p>Unconfirmed transaction can be one of many abusive (spam) transaction (in an attack). Such Unconfirmed transactions will typically never get confirmed and most likely all miners will delete these abusive transactions.</p>

<p>Unconfirmed transaction can be censored by all miners. This can happen if some address belongs to a person who is anti-bitcoin or some large corporation that has a conflict of interest with bitcoin (like a large bank). If all miners agree that they do not wish such entity to transact on bitcoin, they may decide to censor the activity of such an entity or person. This transaction may never get confirmed.</p>

CC BY-SA 3.0
2016-05-15T13:40:49.060Z
"Unconfirmed transaction can contain technical error that prevent it to be confirmed" - Wouldn't such technical errors prevent an unconfirmed tx from being relayed as well? That is, a tx containing technical errors that would prevent it from being ever confirmed, would most likely not even be broadcasted throughout the network, right? Although this is up to each individual nodes, I'd say the vast majority of nodes are *not* configured to relay invalid or non-legit transactions?
RocketNuts
CC BY-SA 3.0
2016-01-17T18:04:16.103Z
2016-01-17T18:14:15.077Z
2016-01-17T18:14:15.077Z
Anlhord Smithson
<p>From a user perspective, each block confirmation reduces the probability that a transaction payment will be reversed.</p>

<p>However from the perspective of the software, what happens when a transaction is confirmed? For example, I know it is removed from the mempool. Is there any other technical difference between confirmed and unconfirmed transactions? Are both outputs stored in the same UTXO set? Does anything happen on any lower level (data storage, etc) inside a node or on the network or in the protocol once a Tx is included in a block?</p>

<p>Do confirmed transactions have any special properties besides the human perception of safety?</p>

<protocol><confirmations><unconfirmed-transactions><utxo>
What technical properties does a confirmed Tx have that an unconfirmed Tx does not?
pinhead
# What technical properties does a confirmed Tx have that an unconfirmed Tx does not?

(Asked by: username_0 on 2016-01-15)

From a user perspective, each block confirmation reduces the probability that a transaction payment will be reversed.

However from the perspective of the software, what happens when a transaction is confirmed? For example, I know it is removed from the mempool. Is there any other technical difference between confirmed and unconfirmed transactions? Are both outputs stored in the same UTXO set? Does anything happen on any lower level (data storage, etc) inside a node or on the network or in the protocol once a Tx is included in a block?

Do confirmed transactions have any special properties besides the human perception of safety?

**Tags:** protocol, confirmations, unconfirmed-transactions, utxo


---

## 4 answers

### Answer by username_4 on 2016-01-17. Score: 4 | Accepted answer

when we speak about specific transaction: no. The unconfirmed transaction looks exactly the same as the same transaction with 1,2.. confirmations.

yes. There are 3 types of transaction: confirmed, unconfirmed, and nonexistent

example of nonexistent are those 10BTC I'll give you tomorrow.

difference between unconfirmed and nonexistent is not "obvious"

When you see an Unconfirmed tx on your PC, this does not "guarantee" that everybody else sees it too. If internet connectivity fails, you may be precisely the only person who sees it.

Unconfirmed transactions can be very different from confirmed, in many ways:

Unconfirmed transaction can spend funds that already have been spend, or funds that never existed.

Unconfirmed transaction get lost in the Internet (never get confirmed).

Unconfirmed transaction can be reversed and be replaced by different Unconfirmed transaction sending the funds to somebody else.

Unconfirmed transaction can contain technical error that prevent it to be confirmed.

Unconfirmed transaction can have low fee (less than dust limit) and this can cause confirmation delay of 12 or more hours.

Unconfirmed transaction can be one of many abusive (spam) transaction (in an attack). Such Unconfirmed transactions will typically never get confirmed and most likely all miners will delete these abusive transactions.

Unconfirmed transaction can be censored by all miners. This can happen if some address belongs to a person who is anti-bitcoin or some large corporation that has a conflict of interest with bitcoin (like a large bank). If all miners agree that they do not wish such entity to transact on bitcoin, they may decide to censor the activity of such an entity or person. This transaction may never get confirmed.

> **Comments:**
> **username_5**: "Unconfirmed transaction can contain technical error that prevent it to be confirmed" - Wouldn't such technical errors prevent an unconfirmed tx from being relayed as well? That is, a tx containing technical errors that would prevent it from being ever confirmed, would most likely not even be broadcasted throughout the network, right? Although this is up to each individual nodes, I'd say the vast majority of nodes are *not* configured to relay invalid or non-legit transactions?  

---

### Answer by username_1 on 2016-01-16. Score: 1

Transactions are the same before and after confirmation. Each confirmation just means that it has been mined into a block.


---

### Answer by username_2 on 2016-01-17. Score: 1

There is no difference between a confirmed and unconfirmed transaction, which is why you need the full blockchain to verify exactly what you're seeing.

As for storage: A confirmed transaction will have affected the UTXO set by consuming/spending old UTXO's and creating some new ones.

If your node also maintains a mempool, it holds transactions in memory (not anywhere persistent), and transaction selection is based on (i) validation rules and (ii) the node's local policy.

An interesting case is if your broadcasting transactions with non-standard outputs: nodes might refuse to allow them into the mempool, and refuse to relay them. Should a miner hear about the transaction, he can still include it in a block however. So the block would override a node's policy of not accepting these transactions.

A transaction that can *never* confirm is due a rule violation, instead of local policy. An example would be spending outputs which don't exist, or a signature which is entirely invalid.


---

### Answer by username_3 on 2016-01-15. Score: -1

Technically speaking, the difference between a confirmed transaction and an unconfirmed transaction is that confirmed transactions have been hashed into a block, where the header of that block hashes to an extremely unlikely value. They are set in stone within the block and cannot be changed as long as that block remains part of the best chain. Unconfirmed transactions live by themselves, just a few kilobytes of data floating around the network, waiting to be hashed into a block.

> **Comments:**
> **username_0**: I know all this about blocks and PoW, but what happens to THE ACTUAL TRANSACTION after a confirmation? Blocks "establish that a transaction is final" -- but is a flag bit set somewhere? Is data moved or copied or deleted from RAM or the file system? Does the client care at all whether or not a Tx is confirmed? Do confirmed Tx's have any special properties besides the USER feeling better about it?  
> **username_3**: Technically, no, the transaction data is exactly the same as the unconfirmed data before it was put into the block.  

---

