2

Blockchain

[m1]-> [m2] -> [m3] -> [m4]

         |  -> [f1] -> [f2] -> [new]
  • m - mainchain blocks
  • f - fork blocks
  • new - tip of the fork that is at greater height than the previous mainchain

In this case we must switch from the mainchain to the fork, due to the height of forkchain being greater than the mainchain.

My question is about transactions in blocks [m3], [m4]. In the case a transaction was in [m3] but not included in either the blocks [f1],[f2]. Since that transaction is not confirmed in the new mainchain (the forkchain) after the switch, would this tx be available for miners again to include for next block? Would this transactions be returned to the rawmempool?

And what if this transaction was added without isStandard check (in case adding in block), should we process isStandard check for this transaction?

  • This question appears to be based on a misunderstanding of what sidechains are. Possibly, the author confuses it with blockchain forks, but it is hard to tell, because the text of the question is hard to follow. Please improve the phrasing of your question, correct spelling, and then flag for reopening. – Murch Sep 17 '15 at 7:19
  • Much better, but sidechains are not the product of a blockchain fork: Sidechains are separate blockchains that are pegged to the Bitcoin chain. – Murch Sep 17 '15 at 8:51
  • what is the correct name of bitcoin chain fork? – bitaps.com Sep 17 '15 at 9:02
2

Each of the blockchain forks assumes itself to be the only valid blockchain. They do not change their behavior due to a competing chain. They will require checks and confirm transactions completely independently from each other. It is likely that the same transactions are confirmed in both competing chains, just in different order and perhaps also at different heights. If a chain reorganization happens, and some transactions were not confirmed in the new best chain yet, they are still in the pool of unconfirmed transactions for that chain.

So, if you actually switch from [m4] to [new], and a transaction was not confirmed in the [new] chain that had been confirmed in the chain containing [m4], yes of course it would be in pool of unconfirmed transactions for that chain.

isStandard() is performed by every node when it learns about a transaction. Each miner decides whether to confirm transactions that don't pass isStandard() by themselves. It is irrelevant whether a competitor would include it or not for this process. If the forkchain is extended by a miner that doesn't confirm non-standard transactions, it will only be confirmed later when someone else chooses to do so.

  • What about transactions that was in block and skip isStandart check? – bitaps.com Sep 17 '15 at 9:01
  • I've extended my answer to address that part of your question more explicitly. I hope that it is clear now. – Murch Sep 17 '15 at 9:11
  • miner add nonstandard transaction X to block A, we have reveived this block and add to mainchain. After we receive blocks B, C block A no longer in mainchain. We should add all transaction that not exist in mainchain back to txmempool, should we add transaction X to mempool? or we need reject this transaction? – bitaps.com Sep 17 '15 at 9:18
  • Essentially, nodes treat all unconfirmed transactions just like any unconfirmed transaction they just learned about for the first time. Those nodes that relay non-standard transactions will relay it, just like last time they saw it. Those that reject non-standard transactions will not. Why should it be treated any different, just because some orphaned chain had previously confirmed it? – Murch Sep 17 '15 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.