<p>Regarding your update:</p>

<p>It's true that when a node receives a transaction, there is nothing forcing them to relay it.  They can just sit on it if they want.</p>

<p>But the network won't look like the picture you drew.  If Node1 actually wants his transaction to be confirmed, he wants to distribute it to as many other nodes as possible.  In particular, if Node2 is the only miner that knows about the transaction, then it can't be confirmed until Node2 successfully mines a block.  Assuming that Node2 only controls some fraction of the network's total mining power, this may take a (very) long time.  Node1 would prefer for his transaction to be included in the next block to be miner, no matter who mines it.</p>

<p>So for that reason, Node1 won't send the transaction only to Node2, but to many different nodes.  Bitcoin Core, for instance, will by default try to connect to at least 8 different nodes. If at least a few of those nodes are honest, they will relay the transaction to many more nodes, and so on. This also means that Node2 has less incentive to be greedy; it only helps to be greedy if no other miners know about the transaction (or very few), and Node2 knows this is not likely to be the case.  On the other hand, if Node2 is a miner, then she has a slight incentive not to be greedy: having invested in Bitcoin mining equipment, Node2 has an interest in having Bitcoin keep a high value, which will only happen if people continue to use it, and having their transactions confirmed fast would tend to encourage that.  So at some point, the incentives fall on the side of not being greedy.</p>

<p>(Keep in mind, too, that not all nodes are miners.  Many nodes on the Bitcoin network are run by people who don't do any mining, and just run a full node for fun, or to support the network altruistically, or because they installed Bitcoin Core with default settings and don't really know or care what it's actually doing.)</p>

<p>As for your second scenario, if Node1 is a miner himself, he can certainly keep its own transactions to include in his own blocks, rather than transmitting them on the network.  This also means that he won't have to pay fees for that transaction (or, equivalently, that he pays the fees back to himself).  There are two tradeoffs: (1) as mentioned above, the transaction will take longer to be confirmed; (2) if there is a high volume of transactions on the network, enough to keep all blocks filled, then by including his own transaction in his block, Node2 is giving up the ability to include someone else's transaction which would pay him a fee.  So it's up to Node1 to decide what is best for him. But this has no impact on anyone else, so it isn't really a problem for the network either way.</p>

CC BY-SA 3.0
2017-08-26T16:21:36.590Z
Great thank you for your explanation that's great and make things clear for me :)
rmonjo
CC BY-SA 3.0
2017-09-23T04:52:58.640Z
Regarding your final sentence, won't it be possible for the miner to fill up the blockchain with their own nonsense transactions? Sure they miss fees but they don't have to share their made-up transactions and risk wasting computing time.
jiggunjer
CC BY-SA 3.0
2017-09-23T13:23:37.267Z
@jiggunjer: A miner can put any valid transactions they want into their own blocks, and sure, they could fill their blocks with their own transactions.  I can't see how this would benefit them.  I don't understand what you mean about wasting computing time; can you explain what you have in mind?
Nate Eldredge
CC BY-SA 3.0
2017-09-23T13:37:50.287Z
The way I see it completing a block doesn't mean it gets into the blockchain if another block includes a transaction it used. By just mining your own you can 1) avoid long waiting times for a low fee transaction. 2) Your blocks won't ever be rejected by the blockchain.
jiggunjer
CC BY-SA 3.0
2017-09-23T13:42:17.790Z
Oh, I see what you're saying.  But that's not a real concern.  Blocks are strictly ordered in the blockchain since each contains the hash of the previous block. So when you go to mine a block, you know exactly what blocks, and hence what transactions, are in the chain up to that point, and you can avoid with certainty including any transactions that are already there.  If another block, later in the chain, tries to include a transaction already in your block, they get rejected, not you.
Nate Eldredge
CC BY-SA 3.0
2017-09-23T13:44:28.740Z
It could be that two blocks mined simultaneously (both with the same block as their previous) contain the same transaction.  But in such a case, only one block can become part of the chain, simply because of the strict ordering requirement, and this would be true even if they didn't contain any of the same transactions.  So avoiding other people's transactions doesn't give any benefit here.
Nate Eldredge
CC BY-SA 3.0
2017-08-26T14:12:46.290Z
2017-08-26T14:12:46.290Z
Nate Eldredge
<blockquote>
  <p>how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ?</p>
</blockquote>

<p>yes, the P2P protocol has for one of its role to ensure the transmission of new transactions and blocks amongst the participant in it.</p>

<blockquote>
  <p>does miner check the transaction (digital signature, available inputs etc ...) ?</p>
</blockquote>

<p>yes, should a miner mine an invalid transaction, the block itself would be invalid and all the work expanded by the miner would have been useless and costly.</p>

<blockquote>
  <p>does miner directly submit blocks to the blockchain ?</p>
</blockquote>

<p>miners submit blocks to their P2P protocol peers (but nowadays, specialized networks such as FIBRE exist between miners to speed it up). Once a node receives a valid new block from a peer, it is stored locally on disk and extends the existing blockchain, it is also forwarded to peers that didn't receive it yet.</p>

CC BY-SA 3.0
2017-08-26T12:05:43.563Z
Thx for your answer :) I updated my question with more details
rmonjo
CC BY-SA 3.0
2017-08-25T23:24:09.977Z
2017-08-25T23:24:09.977Z
alcio
<p>I'm trying to understand how bitcoin works technically. I understand the blockchain, digital signatures etc ... I'm more interested in what happens to a transaction once it's "created".</p>

<p>Suppose Bitcoin only contains one transaction per block (to simplify). Basically: </p>

<ol>
<li>someone create a transaction using its wallet</li>
<li>this transaction must be validated (check inputs, digital signature etc ... </li>
<li>a proof of work must be computed on the block hash</li>
<li>the the block is added to the blockchain</li>
</ol>

<p>So I know miners are responsible to come with the proof of work. My questions are:</p>

<ul>
<li>how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ? </li>
<li>does miner check the transaction (digital signature, available inputs etc ...) ?</li>
<li>does miner directly submit blocks to the blockchain ?</li>
</ul>

<p>This part is still confusing to me any help pointers to article would be great :)</p>

<h3>Update:</h3>

<p>In a P2P network, nodes are not connected to every other nodes. So let's say the network looks like this:</p>

<p><code>node1 &lt;-&gt; node2 &lt;-&gt; node3</code> (1 and 2 are directly connected and 2 and 3 are directly connected. 1 and 3 are connected through 2)</p>

<p>When <code>node1</code> wants to broadcast a transaction for validation, it will only broadcast it to <code>node2</code>. Then <code>node2</code> can eventually broadcast it to <code>node3</code> to give him the chance to validate <code>node1</code>'s transaction. </p>

<p>But, because we are in an untrusted network, nothing prevent <code>node2</code> to validate the transaction without never transmitting it to <code>node3</code> and thus, keeping mining fees for himself. </p>

<p>We could also imagine that <code>node1</code> never broadcast it's unconfirmed transaction, do the mining work himself and only broadcast the validated block so it get "merged" into the blockchain. </p>

<p>How does Bitcoin deal with this situation ?</p>

<transactions><mining-pools><protocol>
What happens to a transaction once generated?
rmonjo
# What happens to a transaction once generated?

(Asked by: username_0 on 2017-08-25)

I'm trying to understand how bitcoin works technically. I understand the blockchain, digital signatures etc ... I'm more interested in what happens to a transaction once it's "created".

Suppose Bitcoin only contains one transaction per block (to simplify). Basically:

1. someone create a transaction using its wallet
2. this transaction must be validated (check inputs, digital signature etc ...
3. a proof of work must be computed on the block hash
4. the the block is added to the blockchain

So I know miners are responsible to come with the proof of work. My questions are:

* how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ?
* does miner check the transaction (digital signature, available inputs etc ...) ?
* does miner directly submit blocks to the blockchain ?

This part is still confusing to me any help pointers to article would be great :)

### Update:

In a P2P network, nodes are not connected to every other nodes. So let's say the network looks like this:

`node1 <-> node2 <-> node3` (1 and 2 are directly connected and 2 and 3 are directly connected. 1 and 3 are connected through 2)

When `node1` wants to broadcast a transaction for validation, it will only broadcast it to `node2`. Then `node2` can eventually broadcast it to `node3` to give him the chance to validate `node1`'s transaction.

But, because we are in an untrusted network, nothing prevent `node2` to validate the transaction without never transmitting it to `node3` and thus, keeping mining fees for himself.

We could also imagine that `node1` never broadcast it's unconfirmed transaction, do the mining work himself and only broadcast the validated block so it get "merged" into the blockchain.

How does Bitcoin deal with this situation ?

**Tags:** transactions, mining-pools, protocol


---

## 2 answers

### Answer by username_1 on 2017-08-26. Score: 3 | Accepted answer

Regarding your update:

It's true that when a node receives a transaction, there is nothing forcing them to relay it. They can just sit on it if they want.

But the network won't look like the picture you drew. If Node1 actually wants his transaction to be confirmed, he wants to distribute it to as many other nodes as possible. In particular, if Node2 is the only miner that knows about the transaction, then it can't be confirmed until Node2 successfully mines a block. Assuming that Node2 only controls some fraction of the network's total mining power, this may take a (very) long time. Node1 would prefer for his transaction to be included in the next block to be miner, no matter who mines it.

So for that reason, Node1 won't send the transaction only to Node2, but to many different nodes. Bitcoin Core, for instance, will by default try to connect to at least 8 different nodes. If at least a few of those nodes are honest, they will relay the transaction to many more nodes, and so on. This also means that Node2 has less incentive to be greedy; it only helps to be greedy if no other miners know about the transaction (or very few), and Node2 knows this is not likely to be the case. On the other hand, if Node2 is a miner, then she has a slight incentive not to be greedy: having invested in Bitcoin mining equipment, Node2 has an interest in having Bitcoin keep a high value, which will only happen if people continue to use it, and having their transactions confirmed fast would tend to encourage that. So at some point, the incentives fall on the side of not being greedy.

(Keep in mind, too, that not all nodes are miners. Many nodes on the Bitcoin network are run by people who don't do any mining, and just run a full node for fun, or to support the network altruistically, or because they installed Bitcoin Core with default settings and don't really know or care what it's actually doing.)

As for your second scenario, if Node1 is a miner himself, he can certainly keep its own transactions to include in his own blocks, rather than transmitting them on the network. This also means that he won't have to pay fees for that transaction (or, equivalently, that he pays the fees back to himself). There are two tradeoffs: (1) as mentioned above, the transaction will take longer to be confirmed; (2) if there is a high volume of transactions on the network, enough to keep all blocks filled, then by including his own transaction in his block, Node2 is giving up the ability to include someone else's transaction which would pay him a fee. So it's up to Node1 to decide what is best for him. But this has no impact on anyone else, so it isn't really a problem for the network either way.

> **Comments:**
> **username_0**: Great thank you for your explanation that's great and make things clear for me :)  
> **username_2**: Regarding your final sentence, won't it be possible for the miner to fill up the blockchain with their own nonsense transactions? Sure they miss fees but they don't have to share their made-up transactions and risk wasting computing time.  
> **username_1**: @username_2: A miner can put any valid transactions they want into their own blocks, and sure, they could fill their blocks with their own transactions.  I can't see how this would benefit them.  I don't understand what you mean about wasting computing time; can you explain what you have in mind?  
> **username_2**: The way I see it completing a block doesn't mean it gets into the blockchain if another block includes a transaction it used. By just mining your own you can 1) avoid long waiting times for a low fee transaction. 2) Your blocks won't ever be rejected by the blockchain.  
> **username_1**: Oh, I see what you're saying.  But that's not a real concern.  Blocks are strictly ordered in the blockchain since each contains the hash of the previous block. So when you go to mine a block, you know exactly what blocks, and hence what transactions, are in the chain up to that point, and you can avoid with certainty including any transactions that are already there.  If another block, later in the chain, tries to include a transaction already in your block, they get rejected, not you.  
> **username_1**: It could be that two blocks mined simultaneously (both with the same block as their previous) contain the same transaction.  But in such a case, only one block can become part of the chain, simply because of the strict ordering requirement, and this would be true even if they didn't contain any of the same transactions.  So avoiding other people's transactions doesn't give any benefit here.  

---

### Answer by username_3 on 2017-08-25. Score: 2

> how does one node broadcast a transaction to miners ? Is it part of the P2P protocol ?

yes, the P2P protocol has for one of its role to ensure the transmission of new transactions and blocks amongst the participant in it.

> does miner check the transaction (digital signature, available inputs etc ...) ?

yes, should a miner mine an invalid transaction, the block itself would be invalid and all the work expanded by the miner would have been useless and costly.

> does miner directly submit blocks to the blockchain ?

miners submit blocks to their P2P protocol peers (but nowadays, specialized networks such as FIBRE exist between miners to speed it up). Once a node receives a valid new block from a peer, it is stored locally on disk and extends the existing blockchain, it is also forwarded to peers that didn't receive it yet.

> **Comments:**
> **username_0**: Thx for your answer :) I updated my question with more details  

---

