<p>A miner can either verify transactions itself or assume that a transaction is valid as some nodes let him know they verified it.</p>

<p>In either case, the miner can enter the transaction in the block he is working on. Note that in pool mining the pool decides what transactions are included, while in solo mining your own bitcoind client does so.</p>

<p>An important thing to know is that miners only try to make a successor block for a block they think is valid. This means that when a miner generates a block with an invalid transaction on top of a valid block, other miners will not accept the new block. They will ignore it and continue trying to build a block on top of the last block they think is valid.</p>

<p>This way of working results a situation in which accepting invalid transactions and broadcasting invalid blocks is a waste of resources because your blocks will be orphaned and you will have to start all over.</p>

CC BY-SA 3.0
2013-04-09T11:16:33.370Z
2013-04-09T11:16:33.370Z
Steven Roose
<p>The miner looks into the transactions insofar as they have been digitally signed. This is a public key / private key cryptography pairing that performs the role of your signature on a check. Without this digital signature, a transaction is not considered valid and will not be included in the block calculation.</p>

<p>The miner's job is then to amass transactions that have happened since the last block was calculated and generate a new block. There are several elements that tie the old block and the new block together, ensuring that the new block's transactions stand on the shoulders of the previous transactions, guaranteeing the integrity of the entire block chain.</p>

CC BY-SA 3.0
2016-02-23T19:57:14.117Z
thank you for the answer here. So does the miner gather all the transactions, verify that they are true (running Alice's public key against her transaction to Bob to see that she actually signed it), then begin solving for the nonce? Wouldn't that incentivize the miner to include as few transactions as possible since it will take longer to do that process?
streetlight
CC BY-SA 3.0
2013-04-10T04:08:28.443Z
2013-04-10T05:22:24.717Z
2013-04-10T05:22:24.717Z
fbrereto
<p>When a mining pool or solo miner releases a block to peers, each peer running Bitcoin-Qt/bitcoind will verify the transactions in the block before relaying the block.  </p>

<p>The SHA256 block hash is the first thing verified. The SHA256 hash that identifies each block is calculated from the fields of a structure including version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding.  If that block hash is invalid or below the minimum difficulty level then the block is rejected and not relayed.</p>

<p>Then if there is any transaction that couldn't be verified the block is rejected and not relayed for that reason as well.</p>

<p>So there are multiple rules that must be followed for a block to get accepted and then relayed.</p>

CC BY-SA 3.0
2013-04-12T03:29:50.207Z
Yes, this is a new knowledge to me. That each peer (non-mining) node also does some "work" (verification)
Sida Zhou
CC BY-SA 3.0
2013-04-12T03:42:14.407Z
However I want to ask in more detail, what thing do we want to verify about a transaction? What I can imagine at the moment is: public keys and signatures of the sender and receiver? Do the node verify anything about the balance of the account? So, in short, is this verification of technical in nature, or is it exercise of accounting? Or both. (A not too simple, yet not too difficult answer is appriciated.)
Sida Zhou
CC BY-SA 3.0
2016-06-12T08:51:51.043Z
The verification is sufficient to ensure that one cannot be harmed by transactions that pass this verification.
David Schwartz
CC BY-SA 3.0
2016-10-31T02:17:21.460Z
@SidaZhou it needs to be verified that the transaction is signed by the person sending the funds, and that they have enough money, primarily.
Criticize SE actions means ban
CC BY-SA 3.0
2013-04-10T10:30:50.747Z
2013-04-10T10:30:50.747Z
Stephen Gornick
<p>This is how I understand it:</p>

<p>The mining application (eg Phoenix miner, poclbm) requires data to be passed to it by a Bitcoin node. The node's role is to verify the unconfirmed transactions against the blockchain and, if valid, provide a hash of them to the miner. </p>

<p>ie It's not the miner's role to verify transactions; it's the node's.</p>

<p>If you're pool mining, the node is run by the pool. When solo mining, bitcoind is generally used.</p>

CC BY-SA 3.0
2013-04-09T11:49:31.450Z
Wrong, it is everyone's job job to verify transactions.  If the miner mines a block that includes a double-spend, for instance, no one should accept the block and he will not get his reward.  In a pool, the pool operator can be trusted to do the verifying properly and the miner's might not check.
Eyal
CC BY-SA 3.0
2013-04-09T21:10:08.367Z
@eyal, you've misinterpreted my answer. I'm talking about the mining software itself (Eg phoenix miner, cgminer), which unless you're running the generate option on an old version of the client, does not also perform the tasks of a node. I'll try to clarify my answer shortly anyway.
Highly Irregular
CC BY-SA 3.0
2013-04-09T04:34:32.953Z
2013-04-09T21:13:03.283Z
2013-04-09T21:13:03.283Z
Highly Irregular
<p>Bitcoin miner mines a block, which can't be submitted to the network without proof of work. And the new block contains all of the new transactions. Hence the new block acts as a security measure, and authority. </p>

<p><strong>My puzzle is following:</strong>
In the scenario I just described, the miner of the new block, in some sense, authorized the new transactions to be true. Yet the miner has never looked into the new transaction he just authorized.</p>

<p>This somehow relates to orphaned blocks, and longest chain(?)</p>

<p>Links I found useful to help me understand:</p>

<ul>
<li><a href="https://bitcoin.stackexchange.com/questions/9248/how-do-nodes-verify-bitcoin-transactions">How do nodes verify Bitcoin Transactions?</a></li>
<li><a href="http://timothyblee.com/2011/04/19/bitcoins-collusion-problem/" rel="noreferrer">http://timothyblee.com/2011/04/19/bitcoins-collusion-problem/</a></li>
<li><a href="http://spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg" rel="noreferrer">http://spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg</a></li>
<li><a href="https://bitcoin.stackexchange.com/questions/9293/why-is-blockchain-necessary">Why is blockchain necessary?</a></li>
<li><a href="https://bitcoin.stackexchange.com/questions/8918/which-is-the-relation-between-transactions-and-blocks">Which is the relation between transactions and blocks?</a></li>
</ul>

CC BY-SA 3.0
2013-04-10T10:20:42.090Z
Each peer node for a miner running Bitcoin-Qt/bitcoind will verify the transactions in a block before relaying a block.  If there is any reason a transaction couldn't be verified the block is rejected and not relayed.  Does that knowledge help you in rephrasing your question to be a bit more clear?
Stephen Gornick
<transaction-verification><mining-technical-details><transaction-selection>
relationship between bitcoin miner and verification of transactions
Sida Zhou
# relationship between bitcoin miner and verification of transactions

(Asked by: username_0 on 2013-04-09)

Bitcoin miner mines a block, which can't be submitted to the network without proof of work. And the new block contains all of the new transactions. Hence the new block acts as a security measure, and authority.

**My puzzle is following:**
In the scenario I just described, the miner of the new block, in some sense, authorized the new transactions to be true. Yet the miner has never looked into the new transaction he just authorized.

This somehow relates to orphaned blocks, and longest chain(?)

Links I found useful to help me understand:

* [How do nodes verify Bitcoin Transactions?](https://bitcoin.stackexchange.com/questions/9248/how-do-nodes-verify-bitcoin-transactions)
* <http://timothyblee.com/2011/04/19/bitcoins-collusion-problem/>
* <http://spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg>
* [Why is blockchain necessary?](https://bitcoin.stackexchange.com/questions/9293/why-is-blockchain-necessary)
* [Which is the relation between transactions and blocks?](https://bitcoin.stackexchange.com/questions/8918/which-is-the-relation-between-transactions-and-blocks)

**Tags:** transaction-verification, mining-technical-details, transaction-selection

> **Comments:**
> **username_1**: Each peer node for a miner running Bitcoin-Qt/bitcoind will verify the transactions in a block before relaying a block.  If there is any reason a transaction couldn't be verified the block is rejected and not relayed.  Does that knowledge help you in rephrasing your question to be a bit more clear?  

---

## 4 answers

### Answer by username_2 on 2013-04-09. Score: 10

A miner can either verify transactions itself or assume that a transaction is valid as some nodes let him know they verified it.

In either case, the miner can enter the transaction in the block he is working on. Note that in pool mining the pool decides what transactions are included, while in solo mining your own bitcoind client does so.

An important thing to know is that miners only try to make a successor block for a block they think is valid. This means that when a miner generates a block with an invalid transaction on top of a valid block, other miners will not accept the new block. They will ignore it and continue trying to build a block on top of the last block they think is valid.

This way of working results a situation in which accepting invalid transactions and broadcasting invalid blocks is a waste of resources because your blocks will be orphaned and you will have to start all over.


---

### Answer by username_3 on 2013-04-10. Score: 6

The miner looks into the transactions insofar as they have been digitally signed. This is a public key / private key cryptography pairing that performs the role of your signature on a check. Without this digital signature, a transaction is not considered valid and will not be included in the block calculation.

The miner's job is then to amass transactions that have happened since the last block was calculated and generate a new block. There are several elements that tie the old block and the new block together, ensuring that the new block's transactions stand on the shoulders of the previous transactions, guaranteeing the integrity of the entire block chain.

> **Comments:**
> **username_4**: thank you for the answer here. So does the miner gather all the transactions, verify that they are true (running Alice's public key against her transaction to Bob to see that she actually signed it), then begin solving for the nonce? Wouldn't that incentivize the miner to include as few transactions as possible since it will take longer to do that process?  

---

### Answer by username_1 on 2013-04-10. Score: 2

When a mining pool or solo miner releases a block to peers, each peer running Bitcoin-Qt/bitcoind will verify the transactions in the block before relaying the block.

The SHA256 block hash is the first thing verified. The SHA256 hash that identifies each block is calculated from the fields of a structure including version, prev\_block, merkle\_root, timestamp, bits, nonce, and standard SHA256 padding. If that block hash is invalid or below the minimum difficulty level then the block is rejected and not relayed.

Then if there is any transaction that couldn't be verified the block is rejected and not relayed for that reason as well.

So there are multiple rules that must be followed for a block to get accepted and then relayed.

> **Comments:**
> **username_0**: Yes, this is a new knowledge to me. That each peer (non-mining) node also does some "work" (verification)  
> **username_0**: However I want to ask in more detail, what thing do we want to verify about a transaction? What I can imagine at the moment is: public keys and signatures of the sender and receiver? Do the node verify anything about the balance of the account? So, in short, is this verification of technical in nature, or is it exercise of accounting? Or both. (A not too simple, yet not too difficult answer is appriciated.)  
> **username_5**: The verification is sufficient to ensure that one cannot be harmed by transactions that pass this verification.  
> **username_6**: @username_0 it needs to be verified that the transaction is signed by the person sending the funds, and that they have enough money, primarily.  

---

### Answer by username_7 on 2013-04-09. Score: -1

This is how I understand it:

The mining application (eg Phoenix miner, poclbm) requires data to be passed to it by a Bitcoin node. The node's role is to verify the unconfirmed transactions against the blockchain and, if valid, provide a hash of them to the miner.

ie It's not the miner's role to verify transactions; it's the node's.

If you're pool mining, the node is run by the pool. When solo mining, bitcoind is generally used.

> **Comments:**
> **username_8**: Wrong, it is everyone's job job to verify transactions.  If the miner mines a block that includes a double-spend, for instance, no one should accept the block and he will not get his reward.  In a pool, the pool operator can be trusted to do the verifying properly and the miner's might not check.  
> **username_7**: @username_8, you've misinterpreted my answer. I'm talking about the mining software itself (Eg phoenix miner, cgminer), which unless you're running the generate option on an old version of the client, does not also perform the tasks of a node. I'll try to clarify my answer shortly anyway.  

---

