What happens to non-standard transactions in the case of a blockchain reorg?

2

1

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?

bitaps.com

Posted 2015-09-16T22:09:35.840

Reputation: 563

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 – 2015-09-17T07:19:07.007

Much better, but sidechains are not the product of a blockchain fork: Sidechains are separate blockchains that are pegged to the Bitcoin chain. – Murch – 2015-09-17T08:51:55.240

related: Transaction fees when a block chain is discarded

– Murch – 2015-09-17T08:58:37.350

what is the correct name of bitcoin chain fork? – bitaps.com – 2015-09-17T09:02:33.100

Answers

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.

Murch

Posted 2015-09-16T22:09:35.840

Reputation: 41 609

What about transactions that was in block and skip isStandart check? – bitaps.com – 2015-09-17T09:01:18.703

I've extended my answer to address that part of your question more explicitly. I hope that it is clear now. – Murch – 2015-09-17T09:11:59.083

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 – 2015-09-17T09:18:10.170

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 – 2015-09-17T09:25:07.567

Asked: 2015-09-16T22:09:35.840

Viewed: 290 times

Active: 2015-09-17T09:11:22.460