Rebroadcast transactions from minority forks

[crazybits]

will the transactions of blocks in shorter fork chain re-broadcast to network again after network switch from the shorter fork chain to the longer chain,if yes, please guide me to the handling code, thanks.

[dnotestein]

no, it doesn't do this currently. I plan to make this change soon (been on my list after my rewrite of forking code, but various problems keep interrupting me). Anyways, this will only help for short forks, as expiration time for transactions is fairly quick (IIRC, around 2 1/2 hours).

[crazybits]

thanks for clarification,if this feature implemented,we needn't to notify exchange to suspend the withdraw/deposit when fork chain is produced. i think this feature deserves a higher priority

[dnotestein]

it's got a pretty high priority, believe me. Just the problems of late have been higher yet. Fortunately I hope they're resolved after tonight.

[crazybits]

Regarding the fork switching, i am not understand why need to have the following loop, appreciate if could help to clarify. thanks in advance.

https://github.com/BitShares/bitshares/blob/develop/libraries/blockchain/chain_database.cpp#L1609-L1641

do { ....... --highest_unchecked_block_number } while(highest_unchecked_block_number > 0)

[emfrias]

This code is relevant when we get a block that links a chain of currently-unlinked blocks to our blockchain. Say we have the following blockchain except we've never seen block 'd'. Our head block will be block 'c', and blocks 'e' through 'i' are just sitting in the fork database marked as 'unlinked' because we don't have the block 'd' which completes the link to the genesis state. 'e' through 'i' also could be invalid (we don't know until we try to push them onto the blockchain, and we can't do that until we get the missing block)

         h-i
        /
a-b-c-[d]-e-f-g

When 'd' comes in, all of the blocks are now 'linked' and we can try to switch to the new longest fork (in this case, 'g'). We call switch_to_fork(g) to push blocks 'd', 'e', 'f', and 'g'. If these all succeed, the new head block will be 'g' and we'll return out of the loop. But say pushing block 'e' fails for some reason, maybe it has a duplicate transaction. When this happens, our head block will be 'd', the last block we successfully pushed. the e-f-g chain is now invalid, but the h-i is still longer than the chain we started with. That's the purpose of this loop -- if pushing e-f-g fails, it will try h-i next. It will keep trying the next longest chain that might be valid until it runs out of chains to try. If none of the new blocks are valid (including 'd'), the last call should be a switch_to_fork(c) which will return us to our original head block.

[crazybits]

it is quite clear, thank you very much.