<p>Each node on the network is connected to one or (hopefully) many more nodes. Anytime activity happens (a transaction is added, a new block is found, etc.), the node that it initiating that activity sends it to all of the nodes that it is connected to, and they do the same. Each node will run the transaction through validations to verify that it considers it to be a valid transaction. Most of those validations are hard and fast rules, but some of them are more flexible. For example the logic that a node uses to decide whether or not to add a transaction onto the current working block might depend on whether a transaction fee was included or not. For validations like that, a person could modify their code to change the rules as to whether or not they accept a transaction without causing their node to be considered a "bad" node that's breaking the rules.</p>

<p>Because of all this activity, and nodes sending to nodes sending to nodes, at any given time one node might not have exactly the same info that another node has, so your next question is probably how that is handled, and the answer is that it depends on what is different between the nodes, but here are a few examples:</p>

<p>Let's say that you found a new block (congrats!), and your node has 100 pending transactions on it. But there are 5 other transactions that other nodes have that have never made it to you (or that you rejected because they didn't pay a fee or whatever). In that case, what happens is simple: The 100 transactions that you did have would be recorded and become part of the chain, and the 5 that you didn't have would not (and will probably show up on the <em>next</em> block).</p>

<p>What about something more tricky, such as two nodes, A and B, solving a block at the same time? In that case, both A and B will send their solution out to their nodes, and for a (hopefully brief) period, there will be a split in the chain, with some nodes working on A+1 and some nodes working on B+1. Ultimately the network handles this just fine. One of the nodes is going to win, and the other is going to be lost. The winning node will become part of the permanent chain, and the losing node will be lost to eternity. This is exactly the reason that most sites don't consider a transaction to be complete until it is X levels deep in the block. As a transaction becomes older and older, it is less and less likely to be part of a chain that ends up getting dropped.</p>

<p>There's probably another dozen things that have different rules as to what happens as they move along the nodes, but I hope that gives you an idea of how it works for two of the primary types of activity that happen on the network.</p>

CC BY-SA 3.0
2017-11-06T15:29:35.573Z
2017-11-06T15:29:35.573Z
Cory Benjamin
<p>I want to understand better the paths taken by a bitcoin transaction. Whereas familiar with the general setup (submitting a payment, validation using your private key, everyone in the network can verify that your transaction is correct using your public key, mining starts, someone finds a nonce, your transaction is included in the blockchain,...)
However, there are blocks missing: 
Is it possible (ex-post) to back out the journey of my transaction through the network (node where it arrives and subsequent propagation among other nodes)? I am wondering just for some illustrative reasons to learn what has to happen until my transaction pops up in the raw mempool of, say, <a href="https://chainquery.com/bitcoin-api/getrawmempool" rel="nofollow noreferrer">chainquery</a>.</p>

<network><transaction-verification>
(Detailed) journey of a transaction
Stefan Voigt
# (Detailed) journey of a transaction

(Asked by: username_0 on 2017-11-06)

I want to understand better the paths taken by a bitcoin transaction. Whereas familiar with the general setup (submitting a payment, validation using your private key, everyone in the network can verify that your transaction is correct using your public key, mining starts, someone finds a nonce, your transaction is included in the blockchain,...)
However, there are blocks missing:
Is it possible (ex-post) to back out the journey of my transaction through the network (node where it arrives and subsequent propagation among other nodes)? I am wondering just for some illustrative reasons to learn what has to happen until my transaction pops up in the raw mempool of, say, [chainquery](https://chainquery.com/bitcoin-api/getrawmempool).

**Tags:** network, transaction-verification


---

## 1 answers

### Answer by username_1 on 2017-11-06. Score: 2 | Accepted answer

Each node on the network is connected to one or (hopefully) many more nodes. Anytime activity happens (a transaction is added, a new block is found, etc.), the node that it initiating that activity sends it to all of the nodes that it is connected to, and they do the same. Each node will run the transaction through validations to verify that it considers it to be a valid transaction. Most of those validations are hard and fast rules, but some of them are more flexible. For example the logic that a node uses to decide whether or not to add a transaction onto the current working block might depend on whether a transaction fee was included or not. For validations like that, a person could modify their code to change the rules as to whether or not they accept a transaction without causing their node to be considered a "bad" node that's breaking the rules.

Because of all this activity, and nodes sending to nodes sending to nodes, at any given time one node might not have exactly the same info that another node has, so your next question is probably how that is handled, and the answer is that it depends on what is different between the nodes, but here are a few examples:

Let's say that you found a new block (congrats!), and your node has 100 pending transactions on it. But there are 5 other transactions that other nodes have that have never made it to you (or that you rejected because they didn't pay a fee or whatever). In that case, what happens is simple: The 100 transactions that you did have would be recorded and become part of the chain, and the 5 that you didn't have would not (and will probably show up on the *next* block).

What about something more tricky, such as two nodes, A and B, solving a block at the same time? In that case, both A and B will send their solution out to their nodes, and for a (hopefully brief) period, there will be a split in the chain, with some nodes working on A+1 and some nodes working on B+1. Ultimately the network handles this just fine. One of the nodes is going to win, and the other is going to be lost. The winning node will become part of the permanent chain, and the losing node will be lost to eternity. This is exactly the reason that most sites don't consider a transaction to be complete until it is X levels deep in the block. As a transaction becomes older and older, it is less and less likely to be part of a chain that ends up getting dropped.

There's probably another dozen things that have different rules as to what happens as they move along the nodes, but I hope that gives you an idea of how it works for two of the primary types of activity that happen on the network.


---

