relationship between bitcoin miner and verification of transactions

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:

Sida Zhou

Posted 2013-04-09T03:40:41.553

Reputation: 339

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 – 2013-04-10T10:20:42.090

Answers

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.

Steven Roose

Posted 2013-04-09T03:40:41.553

Reputation: 10 855

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.

fbrereto

Posted 2013-04-09T03:40:41.553

Reputation: 621

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 – 2016-02-23T19:57:14.117

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.

Stephen Gornick

Posted 2013-04-09T03:40:41.553

Reputation: 26 118

Yes, this is a new knowledge to me. That each peer (non-mining) node also does some "work" (verification) – Sida Zhou – 2013-04-12T03:29:50.207

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 – 2013-04-12T03:42:14.407

The verification is sufficient to ensure that one cannot be harmed by transactions that pass this verification. – David Schwartz – 2016-06-12T08:51:51.043

@SidaZhou it needs to be verified that the transaction is signed by the person sending the funds, and that they have enough money, primarily. – user253751 – 2016-10-31T02:17:21.460

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

Highly Irregular

Posted 2013-04-09T03:40:41.553

Reputation: 10 514

1Wrong, 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 – 2013-04-09T11:49:31.450

@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 – 2013-04-09T21:10:08.367