Notary nodes and notarization protection

In order to put the notarization protection at the validate block level, instead of the actual blockchain processing level, it will require the precise tagging of each notarization with a komodo timestamp.

Since there is a fair amount of tolerance for each node’s timestamps, even after I reduced it to compensate for faster blocktimes.

All komodo notary nodes must ntp to get their clocks synchronized, but it is possible for non-notary nodes to make blocks too. But 2hours just seems like way too much tolerance. I really want to reduce the tolerance of future timestamps to less than a blocktime. If anybody sees a problem with this, let me know.

In CheckBlockHeader, the timestamp is checked last, but since that is a very fast check I think it should be the first thing that is checked for.

So, now we get a stream of blocks that are no more than 60 seconds from the future, which allows us to use any notarization timestamp that is more than 60 (or 120?) seconds old to reject any incoming block. Now, regardless of when the notarized blockhashes are used, we can see that all chains will converge as they will have the same set of raw blocks input into the system.

Not sure there is a need for a formal math proof as the consensus logic of rejecting a block is based on the set of (notarized hashes+timestamps) and the timestamps of the incoming blocks. The local clock is not part of this other than rejecting blocks from the future, so if to look at only blocks from the past, given the same set of (notarized hashes + timestamps) we end up with the same set of blocks input into the consensus logic. And with the same set of blocks input into the consensus logic, we end up with the same consensus.

Now the problem reduces to generating and propagating the (notarized hashes + timestamps) in a timely fashion so we reduce the amount of small reorgs needed in all nodes to reach the same consensus. I will put the threshold at 120 seconds, so there is time enough to propagate the notarized hashes. Due to propagation delay, it is possible for some nodes to end up temporarily on a fork if they get a block that would have been blocked by the notarized just before they receive the updated notarization info. In that case, that node would reorg using the otherwise invalidated block, but globally the mainchain has rejected that block, so even if an attacker extends the invalid block, no other node would accept it. As soon as the invalid chain is shorter than the mainchain, even this node will converge back to the mainchain. Since it is a pretty unlikely case, I think this treatment is adequate. Not sure how an attacker would be able to force any node off onto its own chain at will if a nodes system clock is ntp’ed

In order to be safe you need to make sure to wait for the bitcoin confirm and your chaintip matches the overall mainchain’s. using a basilisk INF request, it is possible to quickly get the getinfo results from N random peers, so the GUI could have a display of this chaintip status

I dont think most people understand how volatile the blockchain state across all nodes actually is. To me it is like the surface of the ocean. From far away it all looks the same, but up close, it can be quite volatile.

Bitcointalk Topic Entry

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

five × 3 =