<p>The lifetime of a transaction would be something like this:</p>

<ol>
<li>You start with a client, a wallet that contains your keypairs, and some unspent transactions (you get those from other people or through mining).</li>
<li>You create a new transaction spending some of your unspent Bitcoins, sign it with your private keys. Your client will store a copy of it.</li>
<li>Your client starts to broadcast the new transaction through the Bitcoin Network. As far as I remember it doesn't broadcast it to every peer, but to every 8th peer in order to protect your anonymity. Every minute the client will also broadcast all transactions it knows about to one of its peers, which would also include your new transaction.</li>
<li>Every client that receives your transaction scrutinizes it - they check whether the signature is okay, whether there are any errors, and whether you are trying to perform a double-spend. If your transaction fails any of the criteria, it is ignored by the client entirely. Otherwise the client keeps a note of the transaction in temporary memory.</li>
<li>All the clients that know about your transaction follow a similar route of broadcasting as you did - send it to 1/8 peers, and then to one peer every minute. They will also not broadcast your transaction if its fee is too small at a given time (which varies on the amount of transactions to be included in a block and so forth). Generally, if you don't pay fees, you get punished with slow transaction broadcast rate right here.</li>
<li>Eventually your transaction reaches some mining pools and the recipients of the transactions. The latter will see the new transaction in their wallets and store a copy of it indefinitely, but it will appear as 0 confirmations. The mining pools will see it as a new transaction and (most likely) will include it in every block they try to create. They will store a local copy of the temporary blocks and give out the corresponding work to solve to their miners.</li>
<li>The miners don't know anything about your transaction, other than with one or more transaction it hashes to a given merkle root. Their job is to crunch numbers, not to check for block validity, as that's a task for the pool.</li>
<li>Eventually your transaction is included in a block that gets solved. It gets broadcasted proudly through the Bitcoin network and everyone keeps a note of it from now on (to know if some new transaction conflicts with it in a double-spend attempt). Now your transaction has 1 confirmations.</li>
<li>The block creation process continues, and as more and more blocks build atop the block your transaction gets included, it gains more confirmations. Eventually reaching 6 and more confirmations, it is considered fully confirmed.</li>
<li>The transaction finishes its live cycle once it is spent by another transaction, meaning that its outputs can be forgotten from the "unspent" memory and disregarded for any other attempts to spend them. It will, however, remain in the blockchain for as long as people will keep track of the full chain.</li>
</ol>

<p>There are a few complications during 51% attacks and so forth, but this is the main flow of a standard transaction.</p>

CC BY-SA 3.0
2012-09-17T04:19:20.670Z
In bullet #3, that means it connects to every "wallet" peer on an inbound port?  (excluding all ToR and firewalled clients?)
makerofthings7
CC BY-SA 3.0
2012-09-17T04:36:46.613Z
In #5, could [Bitcoin Days Destroyed](http://bitcoin.stackexchange.com/a/4726/1878) be another reason for a slow transaction?
makerofthings7
CC BY-SA 3.0
2012-09-17T04:40:18.887Z
In #9 if a `confirmation` == a block, and a block [takes an average of 30 min to generate](http://blockexplorer.com), does that mean that 6 transactions take 6 hours?
makerofthings7
CC BY-SA 3.0
2012-09-17T15:33:59.503Z
@makerofthings7 Clients establish inbound and outbound connections. You can have 8 outbound connections and 3 inbound and so forth. All the inbound connections go to port 8333, and the outbound use various ports.
I don't think Bitcoin Days Destroyed would be a reason for slow transactions, just low fees and high number of them being created.
ThePiachu
CC BY-SA 3.0
2012-09-17T15:34:49.580Z
@makerofthings7 A block should take an average of 10 minutes to create if the network hashrate is stable. So it should take 1 hour to get 6 confirmations.
ThePiachu
CC BY-SA 3.0
2012-09-17T04:16:51.993Z
2012-09-17T04:16:51.993Z
ThePiachu
<p><strong>I'm trying to understand a transaction's lifetime and haven't yet found a technical, linear "timeline" of events that occur when a P2P transaction occurs.</strong></p>

<p>This is my understanding so far; please correct it as needed: </p>

<ol>
<li><p>A person uses their RSA private key to sign a message saying "deduct X amount from my account and send it to YYY address(s)".  In this message they also reference the current Block number.</p></li>
<li><p>The client application (wallet) sends this transaction to 6 nodes for "confirmation". (is the destination a miner or a wallet?)</p></li>
<li><p>?? What does confirmation actually do??</p></li>
<li><p>The mining nodes add those transactions to single message called a block (<a href="https://bitcoin.stackexchange.com/q/3870/1878">and save them in almost any order</a>)</p></li>
<li><p>The mining nodes compete to find a SHA256(SHA256(x)) hash of the the block that starts with a predetermined number of zeros.</p></li>
<li><p>The first mining node (or node pool) to generate the winning hash collects a prize and increments the block count.  (note this currently appears to take 30 minutes, and the block size is limited to 1MB)</p></li>
<li><p>The miners notify a wallet who then replicates the new block to anyone who requests it, and pushes the updates to a certain number of peers.  Any block with a date difference greater than 120 minutes of system time is discarded.</p></li>
<li><p>Any in-flight transactions that reference the solved block have to be resubmitted by the original client and refer to the current block.</p></li>
<li><p>Conflicting transactions (double spends) are <a href="https://bitcoin.stackexchange.com/q/730/1878">detected in the Bitcoin client and discarded.</a></p></li>
<li><p>The wallet will keep track of any forked chains and the chain with the most computational power backing it wins.  This fork may occur due to netsplits or malicious activity).   In addition no single wallet or central authority currently knows of all the invalid transactions, or forks that have occurred in the network.</p></li>
<li><p>Once 100 (or 120) confirms have been sent, the BTC generated with the block may be spent. <a href="https://bitcoin.stackexchange.com/q/3464/1878">source</a></p></li>
</ol>

CC BY-SA 3.0
2016-03-16T10:05:20.013Z
To anyone stumbling on this question: Please note that it is generally **preferred to ask specific questions** instead of asking in a "check my answer" style as seen here. If you feel confident that your understanding is correct, rather post the question and put your own understanding into an answer where it will compete with other answers. If there are mistakes in it, people will tell you.
Murch
CC BY-SA 3.0
2016-03-16T13:33:36.433Z
I'm the OP and totally agree with @Murch I wrote this long long ago, and would be deleted if not for the +4 voted answer(s) below.  TP has a lot of great answers here... check his history out
makerofthings7
<transactions><blockchain><confirmations><transaction-propagation>
What is a transaction's step-by-step life cycle?
makerofthings7
# What is a transaction's step-by-step life cycle?

(Asked by: username_0 on 2012-09-17)

**I'm trying to understand a transaction's lifetime and haven't yet found a technical, linear "timeline" of events that occur when a P2P transaction occurs.**

This is my understanding so far; please correct it as needed:

1. A person uses their RSA private key to sign a message saying "deduct X amount from my account and send it to YYY address(s)". In this message they also reference the current Block number.
2. The client application (wallet) sends this transaction to 6 nodes for "confirmation". (is the destination a miner or a wallet?)
3. ?? What does confirmation actually do??
4. The mining nodes add those transactions to single message called a block ([and save them in almost any order](https://bitcoin.stackexchange.com/q/3870/1878))
5. The mining nodes compete to find a SHA256(SHA256(x)) hash of the the block that starts with a predetermined number of zeros.
6. The first mining node (or node pool) to generate the winning hash collects a prize and increments the block count. (note this currently appears to take 30 minutes, and the block size is limited to 1MB)
7. The miners notify a wallet who then replicates the new block to anyone who requests it, and pushes the updates to a certain number of peers. Any block with a date difference greater than 120 minutes of system time is discarded.
8. Any in-flight transactions that reference the solved block have to be resubmitted by the original client and refer to the current block.
9. Conflicting transactions (double spends) are [detected in the Bitcoin client and discarded.](https://bitcoin.stackexchange.com/q/730/1878)
10. The wallet will keep track of any forked chains and the chain with the most computational power backing it wins. This fork may occur due to netsplits or malicious activity). In addition no single wallet or central authority currently knows of all the invalid transactions, or forks that have occurred in the network.
11. Once 100 (or 120) confirms have been sent, the BTC generated with the block may be spent. [source](https://bitcoin.stackexchange.com/q/3464/1878)

**Tags:** transactions, blockchain, confirmations, transaction-propagation

> **Comments:**
> **username_1**: To anyone stumbling on this question: Please note that it is generally **preferred to ask specific questions** instead of asking in a "check my answer" style as seen here. If you feel confident that your understanding is correct, rather post the question and put your own understanding into an answer where it will compete with other answers. If there are mistakes in it, people will tell you.  
> **username_0**: I'm the OP and totally agree with @username_1 I wrote this long long ago, and would be deleted if not for the +4 voted answer(s) below.  TP has a lot of great answers here... check his history out  

---

## 1 answers

### Answer by username_2 on 2012-09-17. Score: 10 | Accepted answer

The lifetime of a transaction would be something like this:

1. You start with a client, a wallet that contains your keypairs, and some unspent transactions (you get those from other people or through mining).
2. You create a new transaction spending some of your unspent Bitcoins, sign it with your private keys. Your client will store a copy of it.
3. Your client starts to broadcast the new transaction through the Bitcoin Network. As far as I remember it doesn't broadcast it to every peer, but to every 8th peer in order to protect your anonymity. Every minute the client will also broadcast all transactions it knows about to one of its peers, which would also include your new transaction.
4. Every client that receives your transaction scrutinizes it - they check whether the signature is okay, whether there are any errors, and whether you are trying to perform a double-spend. If your transaction fails any of the criteria, it is ignored by the client entirely. Otherwise the client keeps a note of the transaction in temporary memory.
5. All the clients that know about your transaction follow a similar route of broadcasting as you did - send it to 1/8 peers, and then to one peer every minute. They will also not broadcast your transaction if its fee is too small at a given time (which varies on the amount of transactions to be included in a block and so forth). Generally, if you don't pay fees, you get punished with slow transaction broadcast rate right here.
6. Eventually your transaction reaches some mining pools and the recipients of the transactions. The latter will see the new transaction in their wallets and store a copy of it indefinitely, but it will appear as 0 confirmations. The mining pools will see it as a new transaction and (most likely) will include it in every block they try to create. They will store a local copy of the temporary blocks and give out the corresponding work to solve to their miners.
7. The miners don't know anything about your transaction, other than with one or more transaction it hashes to a given merkle root. Their job is to crunch numbers, not to check for block validity, as that's a task for the pool.
8. Eventually your transaction is included in a block that gets solved. It gets broadcasted proudly through the Bitcoin network and everyone keeps a note of it from now on (to know if some new transaction conflicts with it in a double-spend attempt). Now your transaction has 1 confirmations.
9. The block creation process continues, and as more and more blocks build atop the block your transaction gets included, it gains more confirmations. Eventually reaching 6 and more confirmations, it is considered fully confirmed.
10. The transaction finishes its live cycle once it is spent by another transaction, meaning that its outputs can be forgotten from the "unspent" memory and disregarded for any other attempts to spend them. It will, however, remain in the blockchain for as long as people will keep track of the full chain.

There are a few complications during 51% attacks and so forth, but this is the main flow of a standard transaction.

> **Comments:**
> **username_0**: In bullet #3, that means it connects to every "wallet" peer on an inbound port?  (excluding all ToR and firewalled clients?)  
> **username_0**: In #5, could [Bitcoin Days Destroyed](http://bitcoin.stackexchange.com/a/4726/1878) be another reason for a slow transaction?  
> **username_0**: In #9 if a `confirmation` == a block, and a block [takes an average of 30 min to generate](http://blockexplorer.com), does that mean that 6 transactions take 6 hours?  
> **username_2**: @username_0 Clients establish inbound and outbound connections. You can have 8 outbound connections and 3 inbound and so forth. All the inbound connections go to port 8333, and the outbound use various ports. I don't think Bitcoin Days Destroyed would be a reason for slow transactions, just low fees and high number of them being created.  
> **username_2**: @username_0 A block should take an average of 10 minutes to create if the network hashrate is stable. So it should take 1 hour to get 6 confirmations.  

---

