How can we reuse 'Not chosen Blocks' in forking

[Superkidd]

As you know, Fork makes a 'Not chosen Blocks or Branches'
So, we think about transactions in 'Not chosen Blocks or Branches'
Assume that two miners collect transactions that have higher transaction fees and make a block with transactions in each block.
Fork is occurred.
each block made by miners ,Normally,  has almost same transactions.
But if it has different transactions in 'Not chosen Blocks', What happens?
Just delete that transactions in 'Not chosen Blocks' And then make the same transactions again?

I think that, if it is not,  After 6-confirmation, that transactions should be mined next block in main branch by another miner.

What is correct?

[nc50lc]

The "not chosen block" will just get orphaned (orphaned blocks) simply because bitcoin nodes didn't verified it to be "true".
It got there by "accident" due to some nodes have "seen" that block earlier than the valid one.

There aren't any deleted transactions because the other verified block contains the almost the same transactions it contained.
In other words, the "not chosen block" is a duplicate of the valid block so there will be no missing transactions once it become orphaned.

[Superkidd]

Thanks for answer.

so you mean that "not chosen block" and the other verified block have a same list of transaction?

Is there anything else in "not chosen block"?

[nc50lc]

Yes, with very little difference in the number of transactions.
Those transactions that got included or not included in the orphaned block were included to the valid and/or next valid block, so the difference in the number of tx is not an issue.

Check this site for reference: Orphaned Blocks (the ones marked with red "x" are the orphaned blocks)

Is there anything else in "not chosen block"?

Nothing, unless it was created by an attacker, but
As "they" mentioned, there's no record of an attack in the history since the start.

[ranochigo]

Blocks in a fork almost always not have the same transactions. When a node sees a block that is on another fork, they will validate the validity of it. If its valid, they will evaluate the difficulty of the entire chain. If the difficulty of the fork chain is longer than their current, the chain will be accepted as their 'main' chain and the transactions that were included in the previous blocks in their previous chain would go back into the mempool.

If the fork is such that the difficulty is the same, they will wait until one of the fork is longer than the other, difficulty wise. The same thing would happen to the transactions as above. Transactions cannot be lost. It will be included in the chain or simply forgotten by the nodes/miners.

[Superkidd]

Transactions cannot be lost. It will be included in the chain or simply forgotten by the nodes/miners.

Thanks for your good answer

I have more questions. You said that " the transactions that were included in the previous blocks in their previous chain would go back into the mempool ".
You mean, If transactions would go back into the mempool, that transactions didn't propagate in network. Right?
So if it is , transactions need to be reused in block to be chosen in blockchain  . because transactions have never used .

And, if transactions would be reused , How can node select that transactions? Just transaction fees? have any priority about "be reused transactions in mempool"? 

[DannyHamilton]

You mean, If transactions would go back into the mempool, that transactions didn't propagate in network. Right?

The transactions do propagate in the network.  That's how they get into the mempool the first time.  Then, when they are included in a block in the blockchain, they are removed from the mempool. Then if the block is orphaned, and the transaction is not in the replacement block, the transaction goes back into the mempool again.

So if it is , transactions need to be reused in block to be chosen in blockchain  . because transactions have never used .

If the transactions are back in the mempool, then they are "unconfirmed".  They are not in any valid block in the blockchain.  A solo-miner or mining pool can choose the transaction from their mempool to include in a block that they are solving if they want to.  When the transaction is eventually included in a new solved block later, it will be "confirmed".

And, if transactions would be reused , How can node select that transactions? Just transaction fees? have any priority about "be reused transactions in mempool"?

No priority.  It is the same as if it was never in a block before.  Same rules apply for miners choosing the transaction for confirmation.

[Superkidd]

Sorry to delay answer your comment.

After checking your answer, when I researching How to verify of Transactions and How to confirm a unconfirmed Txs , I have more questions

First, When transactions being in memory pool,  it was already valid by Independent verification of every full node.

and mining node should aggregate those transactions in candidate block. at this point, how to confirm a unconfirmed transactions?( I know that transactions in candidate block are confirmed,, So How?...)


Second, when transactions in "not chosen block" are comeback to memory pool, you mentioned that those transactions are comeback to memory pool with unconfirmed condition.

at this point, those transactions were already verified? if it is not, we would verify transactions again, and then put txs in memory pool?

What is correct,plz~?

+ I mean that verify and valid of transactions, not about block!

[DannyHamilton]

First, When transactions being in memory pool,  it was already valid by Independent verification of every full node.

Each node has its own memory pool.

A transaction in my node's memory pool might not be in your node's memory pool.
A transaction in your node's memory pool might not me in my node's memory pool.

If we are taking about CERTAINTY, then...
When a transaction is in your node's memory pool, you only know for certain that it is valid be independent verification of your node.  There is no way for you to know how many other nodes (if any) have also verified the transaction.

If we are talking more about general Bitcoin topics, then a properly running full node should not relay the transaction to any other nodes until the transaction has been verified. Therefore, unless you are connected directly to a malicious node, you should never receive any invalid transactions.

and mining node should aggregate those transactions in candidate block.

Yes, solo-miner or mining pool.  If you are a participant in a mining pool, then you receive the block header from the pool after the pool has already aggregated the transactions into the candidate block.

at this point, how to confirm a unconfirmed transactions?( I know that transactions in candidate block are confirmed,, So How?...)

Complete the proof-of-work on the candidate block.  If you succeed, then send that completed block to all peers that you are connected to.  As long as there isn't a competing block at that time which also has a valid proof-of-work, then everyone will add your block to their blockchain and relay the block to their peers.  Any node that has the block in their blockchain will see the transactions of that block as having 1 confirmation.

Second, when transactions in "not chosen block" are comeback to memory pool, you mentioned that those transactions are comeback to memory pool with unconfirmed condition.

Correct.  "Confirmed" means "included in a block in the blockchain"  That is the DEFINITION of the word CONFIRMED.  If the transaction is NOT in a block in the blockchain, then the transaction is NOT confirmed.  If the transaction IS in a block in the blockchain, then the transaction IS confirmed.

at this point, those transactions were already verified?  if it is not, we would verify transactions again, and then put txs in memory pool?

Nodes do not add unverified transactions to their memory pool.

[Superkidd]

Thank you very much

I exactly understand it.!!!!
so how about this ?
I think that transactions that comeback to mempool should have a priority for network efficiency.

[nc50lc]

so how about this ?
I think that transactions that comeback to mempool should have a priority for network efficiency.

It will just be added as any other transactions not as a returned tx, the ones that will be prioritized are always the tx with higher transaction fee.

The network as of now maybe not "that efficient" since the scaling solutions aren't exactly being used by the majority but,
using that method of prioritization can easily get abused by network spammers which can even lead to more stuck transactions.

[DannyHamilton]

I think that transactions that comeback to mempool should have a priority for network efficiency.

You only have control over your own node.  You do not have any control over the other nodes in the system.  Bitcoin is a decentralized system. This means that it is not possible for a centralized entity (yourself) to control how other entities behave.

How are you going to force the miners to give priority to transactions that they have never seen (remember that your mempool might be different than their mempool)?
How are you going to know if the miner has ever seen the transaction that you have in your mempool?
How will you prevent the miners from breaking your rule?
Miner wants to maximize his profit. He will not want to prioritize low fee transaction that comes back to mempool if a new higher fee transaction is available.

If YOU are a solo-miner or mining pool operator, then YOU can implement your own priority rule for transactions that go back into mempool if YOU want to make less money, but it isn't possible to force everyone else to do the same.