Forking Q2 - unconfirmed transactions

[Jet Cash]

Following on from Q1, I'm not sure what happens in the case of an unconfirmed transaction that is subsequently found to be invalid. I gather that this invalidates the whole block, and therefore any subsequent blocks. Is this correct? I believe that some miners use unconfirmed transactions to get their blocks out faster. I guess this means that the chain backs up to the block before the invalid block. Now I'm starting to get lost.
Will miners still be using that block as a basis for their PoW, or will they have moved on to the later ( now discarded ) blocks?
Will careful miners who have been validating the transactions in the dodgy block, be at an advantage when they submit their next block if they use the earlier (valid) block?
What happens if the dodgy block was one that created an orphan - will that orphaned block be adopted by the careful miner who found the dodgy block?

[AliceWonderMiscreations]

If any of the transactions in a block are not valid then it doesn't matter how fast the block was solved, the block is invalid and will be rejected by full-node clients which verify every block is valid before accepting it themselves or relaying it.

No transactions are confirmed until they are in a block that has been accepted by the network.

And clients do not relay transactions that are not valid, so invalid transactions rarely get to the miners.

Given a block reward is worth about $10,000 I doubt very many miners would risk losing it by not verifying each tx themselves.

[Jet Cash]

I thought the SPV miners didn't bother to verify transactions.

[DannyHamilton]

I thought the SPV miners didn't bother to verify transactions.

I guess that depends on what you mean when you say SPV mining.

Generally when people talk about SPV mining, I think they're talking about mining where the miner (or pool) doesn't validate a block that it receives.  The miner/pool simply assumes that they wouldn't have heard about the block unless it was valid, and they use the hash from it to build the next block that they're about to start mining on. Personally, I think "SPV mining" is a horrible name for it since as far as I know it has nothing to do with Simplified Payment Verification at all.  With this sort of mining, the miner (or pool) is taking a risk that someone might send them an invalid block.  If the block they accept an invalid block, then they will be wasting all hash power that they spend mining until they realize their mistake and switch to a valid block.  The rest of the network (all full node peers, and all normal miners) will have rejected the block and will continue working on the most recent valid block in the block chain.

Note that this sort of SPV mining opens a miner (or pool) up to an attack.  Depending on the amount of hash power being spent on SPV mining, and the amount of hash power the attacker has, it might be profitable for an attacker to:

• Intentionally mine an invalid block
• Send a successfully mined invalid block directly to all SPV mining systems
• Switch back to mining valid blocks

This would temporarily knock all that SPV mining hashpower off the network.  As such, the attacker (and anyone else that isn't SPV mining) would improve their odds of solving the next few blocks until the the SPV miners realized their error and switched back to the correct chain.  It is a risky attack though.  If the SPV miners realize and switch to the correct chain quickly, then the attacker will have wasted hashpower solving an invalid block, meaning that they'll have lost out on a block reward that they otherwise would have had if they had been mining a valid block.

[Jet Cash]

I had to read your post two or three times, thanks for that.

One thing that I hadn't thought about is this - at any one time, there is always a latest block on the blockchain ( assuming no forks ). Am I correct in assuming that all miners are hitting on that to create the next block? When they find a block, it is then a race to get your new block hitched to that block. At this point, all the other miners give up on their current transactions, and start hitting on the new block. Are there multiple solutions to the calculations based on the same block?

Sorry about my limited knowledge of cryptology. I was a commercial programmer, and at that time, CRC was the advanced stuff.

[DannyHamilton]

I had to read your post two or three times, thanks for that.

One thing that I hadn't thought about is this - at any one time, there is always a latest block on the blockchain ( assuming no forks ). Am I correct in assuming that all miners are hitting on that to create the next block? When they find a block, it is then a race to get your new block hitched to that block. At this point, all the other miners give up on their current transactions, and start hitting on the new block. Are there multiple solutions to the calculations based on the same block?

Sorry about my limited knowledge of cryptology. I was a commercial programmer, and at that time, CRC was the advanced stuff.

The hash of the valid block most recently added to your own copy of the blockchain is included in the header of the new block that you are attempting to solve.  This is what assembles the blocks into a chain of blocks.  Each valid block has a hash in its header indicating what the previous block is.  That block then has a hash that indicates what its previous block is, and so on all the way back to the genesis block.

So, each and every miner stores, and validates their own chain of blocks.  When they receive a new "solved" block from a peer they:

• Check to make sure that the block header and ALL transactions in the block are valid
• Add the block to their own copy of the chain
• Update their UTXO
• Remove from their memory pool, all transactions that were included in that block
• Build a new block header using this new block's hash
• Build a new list of transactions that they intend to confirm
• Calculate the merkle root of the list of transactions, and include that merkle root in the block header that they are building
• Start hashing the new block header they've built in an attempt to find a hash value that is lower than the current difficulty target

The "race" is to find a hash value that is lower than the current difficulty target before anyone else does. Then you transmit your block to all the peers that you are connected to, and immediately build a new block header to start hashing.  As long as other miners hear about your valid solved block before they hear about anyone else's valid solved block, they will follow the process I've listed to add your block to their copy of the chain.

While there can be multiple nonce values that solve the same block, typically each miner is working on a slightly different block.  Therefore, a miner only needs to find the first nonce solution to their own unique block that they're working on before any other miner finds a valid nonce solution to any other valid unique block.

[Jet Cash]

Thanks for that clear description of transaction handling, and the UTXO pool. The pool handling was going to be Forking Q3, but I think I understand how transactions get accepted and rejected now. Also, I can see how transaction fees can influence the miner.