Topic: Mempool clearity (Read 295 times)

Just a correction;
It doesn't matter how many honest nodes there are. The majority of the computational power that is used should come from honest nodes. That's all. A dishonest node who owns 51% of the hash rate can attack successfully.

Be aware, that although we often use the term "the mempool" to refer to all unconfirmed transactions waiting for their first confirmation, there is no such thing as "the mempool". It is not one single mempool that every node connects to. Rather, every node keeps a record of its own local mempool, and updates it based on what transactions it receives and what blocks it receives. In the example given, no node would keep both transaction A and transaction B in its mempool since these transaction conflict with each other. Some nodes would keep transaction A in their mempool, and other nodes would keep transaction B in their mempool.

So although we say both transaction A and B are in "the mempool", they are only present in different mempools. Which one ends up confirming first depends on which one is in the individual mempool of the node connected to the miner who finds the next block.

My question was centered more on the confirmation of the verified transactions but i have gotten the full explanation to the question from DannyHamilton explanation using the two transaction instances. He explained sighting an instance of not spending a coin you dont own(ECDSA) that assuming a bitcoin user has 1.0 BTC in a wallet and decides to spend 0.7BTC in one transaction and also spends another 0.6 BTC in a different transaction from the same available coin now a node verifies the first transaction not been aware of the second transaction and it gets added to the mempool and a different node verifies the second transaction and adds it to the mempool not been aware of the first transaction both transactions now exists in the mempool awaiting verification. and since both transaction are been relayed to the mempool by different miners the get verified.
Since both transaction is within the same network of nodes a miner who was in consensus to the first transaction confirmation will eventually notice the second transaction which would automatically make the second transaction invalid this a very reliable network as long as genuie nodes are more than the attacking node as the integrity of the network depend on them thank you all i keep learning daily

Adding to the block (which you'll also see as part of OP) is mining. That's why in the same post I've replied to you, I've also asked OP to re-write his questions in a clearer manner, because his question looks like an odd mix (and possibly mix up) of mining and validation.

However, Danny was nice to write a super detailed explanation, so I have high hopes that all is clear now.

From what I have gathered about  bitcoin protocol it follows that nothing can be changed in  the previously  hashed block (providing it is not orphan one). The only option for newly verified transaction    is to find itself in the new candidate block should the miner decide he is satisfied  with trx's fee. If that candidate block is mined and added to blockchain then newly verified transaction will find itself in the new hashed block.


OP's question was about validation rather than of confirmation.

Verification and confirmation solve 2 different problems in a decentralized distributed system.

Problem 1: What if someone tries to create a transaction that doesn't follow the rules? (Rules such as "You can't spend bitcoins that you don't own").  VERIFICATION solves this problem. As o_e_l_e_o explained, EVERY node on the network will refuse to accept and/or relay any transaction that does not follow the rules. ALL nodes refuse to trust ANY transaction they receive no matter who has verified it or how many times it has been verified.  It's a quick and simple process to verify that a transaction hasn't broken rules, so when ANY node receives ANY transaction, it verifies. In this way, transactions that are obviously invalid never go anywhere and the majority of the network never even sees them. Problem 1 solved.

Problem 2:  What if someone creates 2 different transactions that are each valid by themselves, but are not valid together?  For example, let's imagine that I have exactly 1.0 BTC.  Now let's imagine that I create a transaction that spends 0.7 of that bitcoin (and I don't share it with anyone yet), and I ALSO create a different transaction that spends 0.6 of that exact same bitcoin.  Then I connect to 2 different miners and I simultaneously send one of them the first transaction, and send the other the second transaction.  The first miner will "verify" the transaction that he receives, and it will be valid (because he doesn't know about the second transaction yet). He'll add it to his "mempool".  The second miner will "verify" the transaction that he receives, and it will be valid (because he doesn't know about the first transaction yet). He'll add it to his "mempool".  You can see that this is a problem, becuase I've now "spent" more than the 1.0 bitcoin that I control!  How will these two miners (or ANYONE else in the entire system) determine which transaction is the "real" transaction?  CONFIRMATION solves this problem.

The first miner will relay the first transaction to the nodes he is connected to. Some of the network will start to hear about that transaction and add it to their mempools.  The second miner will relay the second transaction to the nodes he is connected to. Some of the network will start to hear about that transaction and add it to their mempools. Eventually, someone that already has the first transaction in their mempool will receive the second transaction from a node they are connected to.  Since they already have the first transaction, the second transaction will appear invalid to them and they will reject it.  Eventually, someone that already has the second transaction in their mempool will hear about the first transaction from a node they are connected to.  Since they already have the second transaction, the first transaction will appear invalid to them and they will reject it. We now have a situation where some portion of the entire bitcoin network believes that I sent 0.7 BTC, and the remainder of the bitcoin network believes that I only sent 0.6 BTC.

Those miners that received the 0.7 BTC transaction first will eventually attempt to add that to the block that they are working on. Those miners that received the 0.6 BTC transaction first will eventually attempt to add that to the block they are working on. Once a block is solved with one of the two transactions, that block will be relayed throughout the entire bitcoin network.

Anyone that had previously received and accepted into their mempool the same transaction that was also included in the block will simply see that the transaction in their mempool is now confirmed.  They'll verify that the block is valid then they'll accept the block into their copy of the blockchain. After that, they'll remove the transaction from their mempool. They'll also search their entire mempool and determine if any of the remaining transactions in their mempool are no longer valid since (according to the rules of bitcoin) transactions in a block "happen" before transactions in a mempool.

Anyone that had previously received and accepted into their mempool the competing transaction that was not included in the block will see that the transaction in their mempool is no longer valid confirmed.  They'll verify that the block is valid then they'll accept the block into their copy of the blockchain. After that, they'll remove all transactions from their mempool that are identical to transactions in the block. Then they'll also search their entire mempool and determine if any of the remaining transactions in their mempool are no longer valid since (according to the rules of bitcoin) transactions in a block "happen" before transactions in a mempool. They'll see that they have a transaction that can't be valid anymore since it spends bitcoins that are no longer available to the person trying to spend them.  They'll then reject that transaction from their mempool.

Once the block has propogated throughout the entire bitcoin network, everyone will be in agreement on which of the two transactions actually happened (the one in the block). Problem 2 solved.

Miner's nodes do validate the transactions before including them into their mempool, but that's not mining.
Then the miner has found a block, will get the (valid, obviously) transactions with the higher fees they can fit into this new block and broadcast that. At that point the transaction has its first confirmation.

You are not clear about what bit you don't understand. Did you confuse verification with confirmation (mining)?
Maybe you would try explain in more details either how you think the things work, either what part you don't understand (or both? ) so we don't have to guess?

Confirmation and verification are two different procedures.

The former is when the miners have already verified the transactions they've received. Those are inserted into their candidate block which they then try to mine it, and it make it official; the miner broadcasts their success and the transactions get 1 confirmation. The latter is when the nodes check to see if the transactions they've received comply with the consensus rules.

• You broadcast a transaction.
• The node which receives this transaction attempts to verify it. If the verification fails because your transaction is invalid, then the node deletes the transaction and that's the end of it. If the verification is successful, then the node adds that transaction to its local database of unconfirmed transactions waiting to be mined, known as the mempool. The node also broadcasts your transaction to other nodes it is connected to.
• Other nodes receive the transaction, also verify it, and also add it their own local mempools.
• At this point, your transaction is verified but unconfirmed. You will see it appear in block explorers with the status "unconfirmed" or "0 confirmations".
• Next time a block is mined, it is generally filled with unconfirmed transactions from the mempool. Whether or not your transaction is included in this block will depend on the fees your transaction pays and how they compare with the fees every other transaction in the mempool pays. Block space is limited, so higher paying transactions are prioritized.
• If your transaction is included in this block, it moves from unconfirmed to having 1 confirmation. If it is not included in this block, it remains unconfirmed and you'll have to wait to see if you are included in the next block instead.

My understanding is that miners validate transaction before putting it into mempools of their nodes. Being in the mempool the  validated transaction  faces a few options. It can be included into candidate block, stay in the mempool or be pushed out of there, all depends the capacity of mempool,   transaction's fee and  competing trxs in the mempool.

A transaction is only confirmed when it's included into a block, by the miners (actually usually the mining pools).
Now, since block size is limited and also the mining difficulty is implemented in a way that should usually get to one block every ~10 minutes. If there are too many transactions in the mempool and won't fit into a block, usually the decision is made based on the fee is paid for the transaction (counted as satoshi/vByte).

Is this what you were looking for?

I just need a little clarity on the mempool transactions. If a transaction is already verified wouldn't it be automatically added to the previously hashed block what other confirmation is actually needed if the nodes on the network has already verified the transaction I got confused with the concept so I decided to do a share here to get more clearity. Who else is responsible for the confirmation since the nodes has done the verification already?