user4027: 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?
http://timothyblee.com/2011/04/19/bitcoins-collusion-problem/
http://spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg
Why is blockchain necessary?
Which is the relation between transactions and blocks?


user153: 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.

user4154: 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.

user1307: 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.

4027: <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>
 153: <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>
 4154: <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>
 1307: <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>
