I forgot to mention that I think I have the bitcoin backstop protection hooked in!
Just a stub and wont actually do anything until I get the messaging activated, but given a dataset of notarized blockhashes, any block that tries to replace any notarized block (or earlier), will simply get rejected as being an invalid block.
To my thinking, if it is rejected, then it wont ever be able to trigger a reorg of any depth and when the first non-notarized block along that reorging chain appears, then it would reorg to that point.
For dPoW the bulk of the work is in the voting process to elect the notary nodes and getting this election result properly ratified and onto the blockchain. Without a deterministic list of notaries at every blockheight, well, let’s just say that we need to have a list of notary addresses that can be precisely calculated as of any blockheight. Not just in realtime (that’s the easy part), but at any time.
Given such a list, then the data needed to verify that the notary seal is valid will be available.
I am fixing iguana bugs as the top priority to make sure we can get a stable release out sooner rather than later and only working on the dPoW coding after I am caught up. Sometimes the two overlap, ie iguana support for TAZ and KMD, as now I can integrate iguana into the notary nodes at the localhost layer. This means they dont need to be compiled or linked together and allows for a lot more flexibility. It also minimizes the chance of any bugs in the iguana codebase from directly affecting komodo. We have been testing iguana for a while, but it is a rather large codebase and it is better to design things to handle the iguana side dropping out.
With komodo relying on the equihash PoW to make blocks the old fashioned way, as long as the presence of notarized blocks can be made seamless, then we get the best of both worlds. Enhanced security when the notary nodes are up to date and current, normal security when they are not.