Consensus Question

[CaptainFlam]

Hi everyone,

I have looked everywhere on the internet and beyond, I still cannot find a proper answer regarding consensus so I am turning to you experts. When does consensus happen between the moment a transaction is requested to the moment the block is confirmed and added to the chain?

Let me explain in more details.

As far as I understand it, from a high-level point of view, here's the chain of event:

1- Transaction request between A and B created

2- Transaction broadcast to full nodes for verification

3- If transaction confirmed, it is added to the pool of pending transactions to be added to the next block

4- Miners work on finding a suitable hash for the block candidate

5- First miner to find proper combination broadcasts it to other miners for verification and approval

6- Miner who found the block's hash is awarded, block gets added.

If this scenario is correct, when is the 51% consensus required? during point 2, by 51% of full nodes (regardless of whether they are miners)? during point 5, by miners especially? Both? Or am I missing something?

I have found every answer and its opposite on many different white papers from major consulting firms, so I am turning to you for insights. Please note that I am specifically talking about Bitcoin (I'm aware that papers about "Blockchain" could be referring to many different blockchains with different rules).

 

[DannyHamilton]

As far as I understand it, from a high-level point of view, here's the chain of event:

1- Transaction request between A and B created

2- Transaction broadcast to full nodes for verification

3- If transaction confirmed, it is added to the pool of pending transactions to be added to the next block

4- Miners work on finding a suitable hash for the block candidate

5- First miner to find proper combination broadcasts it to other miners for verification and approval

6- Miner who found the block's hash is awarded, block gets added.

Your understanding is not correct.

If this scenario is correct, when is the 51% consensus required? during point 2, by 51% of full nodes (regardless of whether they are miners)? during point 5, by miners especially? Both? Or am I missing something?

Your question doesn't make sense.

If you asking where the 51% attack can be performed, it would be at step 4.  I you control more than 50% of the global hash rate (More that the entire rest of the world's hashing combined), then you are able to orphan blocks created by other miners and can therefore have full control over which transaction get into the blockchain and which ones don't.

I have found every answer and its opposite on many different white papers from major consulting firms, so I am turning to you for insights. Please note that I am specifically talking about Bitcoin

Since you have misunderstood the technical details of how Bitcoin works, you are probably misunderstanding the answers that you have found (or else you are getting answers from unreliable sources).

[CaptainFlam]

Thank you for your answer,

If my understanding is not correct, would you mind correcting it?

If transactions are approved at the mining level, how does finding the proper hash combination verify that Person A indeed has 50 bitcoin on his account?

[DannyHamilton]

If my understanding is not correct, would you mind correcting it?

Yes.  It was just going to take a while to get it typed up, so I submitted my initial response while I was typing the following:

As far as I understand it, from a high-level point of view, here's the chain of event:

1- Transaction request between A and B created

2- Transaction broadcast to full nodes for verification

3- If transaction confirmed, it is added to the pool of pending transactions to be added to the next block

4- Miners work on finding a suitable hash for the block candidate

5- First miner to find proper combination broadcasts it to other miners for verification and approval

6- Miner who found the block's hash is awarded, block gets added.

The transaction sender (A) creates the transaction and sends it to the nodes he is connected to.  Those nodes validate the transaction. If it is invalid, they ignore it and it doesn't get any farther. If it is valid, then they add it to their own mempool, and then relay it to the nodes that they are connected to.  Those then validate the transaction. If it is invalid, they ignore it and it doesn't get any farther. If it is valid, then they add it to their own mempool, and then relay it to the nodes that they are connected to.  And so on.

Eventually, nearly all the nodes on the network will have heard about the transaction from one or more of the peers they are connected to.

Some of the connected nodes that hear about the transaction are solo-miners or mining pools. They also validate the transaction. If it is invalid, they ignore it and it doesn't get any farther. If it is valid, then they add it to their own mempool, and then relay it to the nodes that they are connected to. Just like any other node.

At that time the transaction is "unconfirmed" because it is not yet in the blockchain.

Meanwhile, Solo-miners and mining pools select unconfirmed transactions from their own mempool for the blocks that they are building. After choosing the set of transactions that will maximize their revenue (choosing the transactions with the highest fee per weight unit), they create the coinbase transaction (also called the generation transaction).  This is the special transaction that pays them their block reward, and is included with the list of transactions in their block.

Next, they build a block header for the block of transactions.

If they are a solo-miner, then they begin hashing that block header looking for the nonce that will satisfy the difficulty target.  If they are a mining pool, then they send the block headers out to the pool participants so that they can begin hashing that block header looking for the nonce that will satisfy the difficulty target.

When a suitable block nonce is found that satisfies the target, then the miner adds the block to their own copy of the blockchain and sends it to all the peers that they are connected to. Each of those nodes will validate the block, and if it is invalid they will ignore it and it won't get any farther.  If it is valid, then they will add it to their own blockchain and will relay it the nodes that they are connected to.  Each of those nodes will validate the block, and if it is invalid they will ignore it and it won't get any farther.  If it is valid, then they will add it to their own blockchain and will relay it the nodes that they are connected to. And so on.

If the transaction that A sent is one of the transactions that are included in the block, then as each node on the network adds the block to their own copy of the blockchain, they will see that the transaction has 1 confirmation.  That's what "1 confirmation" means, it means that the transaction IS IN the block most recently added to the chain.

Each new block added to the chain after that is another confirmation of the transaction.  So, if two more blocks of transactions have been added to the blockchain AFTER the block that contains the transaction, then the transaction has "3 confirmations".

Since the block reward transaction was included by the miner when he built his block, his reward immediately has 1 confirmation as soon as the block is completed and shared.  Since there is a possibility that the block could become orphaned, the block reward is not allowed to be spent until it has more than 100 confirmations.

None of this requires 51% of anything, but if you control more hash power than the combined rest of the world (meaning you control more than 50% of the hash power), then you will be able to find the nonce that satisfies the difficulty target faster than the combined rest of the world.  This means that you will always be able to create a longer chain than the rest of the world, so you can orphan any block you want to. This gives you full control over which valid transactions are and are not included in the blockchain.

If transactions are approved at the mining level,

They are not.

Every transaction is checked for validity by EVERY node on the system (even nodes that are NOT mining).  An invalid transaction won't be relayed at all, and therefore won't even show up as "unconfirmed".

Transactions are "confirmed" at the mining level.  Confirmed is an indication that the transaction is now in the blockchain.  Because of the proof-of-work, as more blocks are added to the chain, the user can feel more confident that everyone in the system is using the same set of blocks.

how does finding the proper hash combination verify that Person A indeed has 50 bitcoin on his account?

It does not.  There are no accounts.  A transaction refers to specific previously received payments.  Those previously received payments are called "unspent transaction outputs" (UTXO). By referencing them, the transaction "Spends" those outputs, and then creates new outputs.  If the sum of the value of the new outputs is greater than the sum of the value of the outputs being spent, then the transaction is invalid.

Finding the proper hash just provides a proof-of-work to build confidence that everyone is using the same set of blocks in their chain.

[CaptainFlam]

Thank you very much for spending the time to provide this thorough answer, I really appreciate it. Moreover it is spot on, and it sheds much needed light on the way the system works.

I see three elements here that I'd like to highlight:

1- It seems to me that, referring back to my initial question and from your explanation, the transaction is verified/validated (from previous transactions) by full nodes before being added top the pool of transactions to be used to mine the next block, correct?

2- Thus, mining is not about verifying transactions per say, but about "building" a valid block that, once done and validated by other nodes, "confirms" the transaction through immutable recording, would that be a fair statement?

3- In my original high-level overview, what triggered your attention as something clearly "wrong"?

Again, your feedback is very much appreciated.


 

[DannyHamilton]

1- It seems to me that, referring back to my initial question and from your explanation, the transaction is verified/validated (from previous transactions) by full nodes before being added to the pool of transactions to be used to mine the next block, correct?

There is NO "the pool of transactions".

Each node (miners AND non-miners) maintains their own personal list of VALID unconfirmed transactions that they have received from peers which are they have not yet seen in the blockchain. This list is often called a "mempool", but there isn't a SINGLE mempool that everyone is accessing.  It is a completely separate mempool per node.

Each miner (or pool operator) chooses unconfirmed transactions for their own block from their own mempool, without knowing if any other node has seen that transaction yet, and without knowing if that transaction is in the mempool of any other node.

The node validates the transaction before adding it to it's own pool, and before relaying it to any other peer. A node does not add an invalid transaction to their own pool, and they do not relay an invalid transaction to any peers that they are connected to.  However, it is possible that any given node on the system may have a different set of transactions in its own mempool than any other given node on the system.  The only way to be certain that a transaction you've seen has also been seen by the rest of the system is to wait for it to show up in a block, and then wait for enough more blocks to be certain that the block with the transaction won't be orphaned.

When a node receives a new block, it is possible for a transaction in that block to create a situation where a different transaction which is in the node's mempool becomes invalid.  In that case, the block wins, and the node removes the invalid transaction from its own mempool.  Additionally, any transaction in the block which is also in the node's mempool is removed from the node's mempool (since the transaction is no longer unconfirmed).

2- Thus, mining is not about verifying transactions per say, but about "building" a valid block that, once done and validated by other nodes, "confirms" the transaction through immutable recording, would that be a fair statement?

Correct.  Mining is about reaching an agreement among all participant about the order of transactions, and recording that ordering in a permanent immutable way.

3- In my original high-level overview, what triggered your attention as something clearly "wrong"?

"If transaction confirmed, it is added to the pool of pending transactions to be added to the next block"

Not true.  A transaction is not confirmed BEFORE it is in a block.  When a transaction is confirmed, it is REMOVED from the pool, not added.

"First miner to find proper combination broadcasts it to other miners for verification and approval"

The block is broadcast to ALL connected nodes, NOT just the other miners.  ALL nodes (not just the miners) verify the block before adding it to their own blockchain and before relaying it to any other nodes.

"Miner who found the block's hash is awarded, block gets added"

The reward is created by the miner himself (or the pool operator) BEFORE they begin the hashing.  The reward is just another transaction in the block.  If that block is never broadcast, because some other miner solves their block first, then the reward isn't part of the blockchain, and isn't available to the miner to spend, but they do NOT have an additional step of being awarded AFTER broadcasting.

Here's a great video that does a good job of explaining the high level concepts.  It generalizes some of the details, so it isn't a 100% accurate depiction of exactly how Bitcoin works, but it gets most of the major concepts across in an easy to understand way:
https://www.youtube.com/watch?v=bBC-nXj3Ng4

[CaptainFlam]

Thank you again for taking the time to answer, this is very useful to me and truly appreciated.

Thanks
CaptainFlam.

[DannyHamilton]

Thank you again for taking the time to answer, this is very useful to me and truly appreciated.

I made a couple of edits to my most recent comment.  In particular look for the YouTube link at the bottom.

[CaptainFlam]

Thank you again for taking the time to answer, this is very useful to me and truly appreciated.

I made a couple of edits to my most recent comment.  In particular look for the YouTube link at the bottom.

I just watched the video and came back to your post for refreshers on the process used by Bitcoin.

Thanks again