Komodo’s Delayed Proof of Work (dPoW) Security, Explained

45 min readDec 18, 2018

It’s almost the end of 2018, and this year we have witnessed many 51% attacks (Double Spending attacks) on various Proof of Work (PoW) based blockchains.

I remember the days of 2015–2016 when jl777 (James Lee) was working on the SuperNET code, programmed in the C language, in which James was both creating a Decentralized Exchange solution as well as learning the core internals of Bitcoin blockchain architecture by re-coding it himself. As he was learning and coding, he usually was sharing much innovative knowledge with the SuperNET community and pointing out the many shortcomings of Bitcoin, places where the code could be improved a lot more.

Origins of delayed Proof of Work (dPoW)

Back then, jl777 predicted that the days were not far off when Proof of Work blockchains with small levels of hashing security would be attacked as the market value of those blockchain increase over time. As you can see in June 1st 2014, the total market cap of cryptocurrency was about $8+ billion dollars, and the value of many of the top cryptocurrencies at that time were just a few cents or even less than a cent. And as per December 2nd 2018, the total market cap of all cryptocurrencies is over 135+ billion dollars, and many of the top cryptocurrencies are now worth tens or hundreds of dollars per unit.

While many other cryptocurrency forums or social media platforms weren’t as appreciative of jl777’s work, the bitco.in forum was wise enough to give a dedicated space to jl777’s bitcoin code iguana on its forum, where for some time James posted his early research as he was progressing. One post/thread on this forum from James is about “Using BTC as time sequence server to allow cross chain atomic swap and increase security of altchain” (link), in which he explained his idea of how Bitcoin can be used to secure other alternative blockchains which aren’t secured with as much hashing power as Bitcoin is, regardless of which method of security that blockchain is using to secure itself on its base protocol consensus level.

The Bitcoin-as-timestamp-server solution for alternative blockchains later evolved to become “delayed Proof of Work” (dPoW) and was the first thing coded in the Komodo cryptocurrency project in late 2016, when Komodo was first forked from the Zcash code.

The Internals of delayed Proof of Work (dPoW)

I don’t need to cover things like hashing, peer-to-peer network, Proof of Work, vinand vout in bitcoin transactions, etc., as there are plenty of resources online (e.g. bitcoin whitepaper) which can help you understand what makes SHA-256 Proof of Work the most trusted strongest PoW algorithm among cryptocurrency advocates. If you’d like to dive into a more descriptive and easy-to-understand book, the best resource is Mastering Bitcoin by Andreas M. Antonopoulos.

So, if you have read about Proof of Work (PoW), I guess you have grasped the basic understanding of how difficult it is to double spend the transaction with Bitcoin because of it’s massive hash rate (over 35+ million TH/s at the point of writing). This makes it nearly impossible to do 51% attack on Bitcoin to double spend the same transaction. But, still I think it’s good idea to cover the double spending process a little bit, just to give some context to delayed Proof of Work (dPoW).

source: https://www.blockchain.com/charts/hash-rate

Some of the rules of Proof of Work consensus mechanism are:

The blockchain network will follow the longest chain in the network.
If two or more miners verifying a block solve the same block at the same time, the block which is most synchronized in the network will be treated as the winner and agreed upon by all the nodes in that network.

Quick overview of double spending attack

In case the attacker wants to double spend the transaction, he’ll need:

A computer node with full blockchain to make the transaction and broadcast it to the peer-to-peer network.
A second computer node with the full blockchain which is NOT connected to the rest of the peer-to-peer network, and is being privately mined from the block prior to where the attacker sent the transaction from first computer node.
Need 66.666% of hash-rate, but 51% is statistically enough to eventually get a longer chain. The more than 51% of the hash-rate the attacker has, the faster he can build the private chain. With more hash-rate, the attacker will be able to solve the blocks faster than the rest of the miners in the network combined. (To solve a block the Bitcoin’s expected time is 10 minutes, while Komodo’s expected time is 1 minute.)
Once the attacker sees that his count of blocks solved is more than the rest of the network, the attacker can create the same transaction again with a different destination address for the funds he spent in step 1.
Then, the attacker can open his mining node’s connection to the rest of the peer-to-peer network and broadcast this transaction.

The implication at step 5 is that any N number of blocks mined from the first sent transaction and the second sent transactions will be treated as invalid as the attacker over-performs in solving more blocks than the rest of the miners in the network. The expected result will be:

The transaction sent in step 1 is not included in the same blocked solved by attacker’s mining node. Since the attacker’s block replaces the old block that did contain the transaction, it’s as if that transaction never happened (even though the funds were sent to the receiving address).
Since the attacker mined the longest chain of blocks and then also spent his funds in later blocks to a different destination address, the “Longest chain” rule comes to the condition and rest of the peer-to-peer network invalidates the old blocks submitted by the other miners and they switch to this attacker’s longest chain.

This is the summary of expected 51% double spend Attack.

The obstacles to executing a 51% attack are:

Owning or renting the processing hardware necessary to achieve more hash rate than the rest of the network combined.
The mining difficulty of the targeted blockchain at the time of the attack.
The uncertainty of an increase in the network hash-rate increase caused by other miners joining the network, and their solved blocks propagating to the rest of the peer-to-peer network before that attacker.

The above conditions are near to impossible to do with Bitcoin, since it has more hash-rate securing network than any other blockchain. But it is most certainly not impossible for other Proof-of-Work blockchains since there are many processing chips manufacturers coming with new ASIC miners for various PoW algorithms and many of these ASIC mining hardware owners are renting their hash-rate on websites like https://www.nicehash.com/.

As 51% attacks can have a huge return on investment after double spending the same transaction, it is no wonder that some attackers take advantage of this situation. https://www.crypto51.app/ is a nice website which shows how much it might cost to attack some cryptocurrency projects and what percentage of hashing power is available for rent to do a 51% attack on that particular cryptocurrency.

The above shows how Proof of Work is the best security for projects like Bitcoin and Ethereum, since these are the projects with the highest hash-rate securing them. The amount of hash power needed to 51% attack Bitcoin or Ethereum is not available from any renting website. The above also shows how small cryptocurrency projects can use the same solid Proof-of-Work rules but yet be hugely vulnerable to 51% attacks.

Komodo’s dPoW Security: A Hero for the small cryptocurrency projects

Many consensus mechanisms have been built over the years by cryptocurrency developers and innovators, which use either a totally different algorithm from Bitcoin or a mix of different consensus methods, like Proof-of-Work and Proof-of-Stake. You can take a look at the What To Mine website, which shows which cryptocurrency is most profitable to mine using which algorithm as per the cost of investment of electricity you have to make.

Let’s clear up, in a few simple terms, what delayed Proof of Work (dPoW) can do and can NOT do:

dPoW security can NOT :

participate in mining or generating a block in any blockchain it is securing.

dPoW security can:

be added as a secondary layer of consensus to an existing consensus mechanism of any UTXO-based blockchain. For instance, whether a blockchain is using Proof-of-Work or Proof-of-Stake, it is possible to add dPoW as a secondary consensus on top of it.

To make dPoW security work, it needs:

Bitcoin, to create a custom multiple signature transactions and send it to the Bitcoin network like any other wallet does in Bitcoin.
Latest Blockhash of the blockchain which it is securing.
64 special nodes which can create a network of its own dPoW peer-to-peer network and communicate with each other exchanging the latest blocks and dPoW consensus information related to the blockchains it is securing. The nodes in this dPoW peer-to-peer network are called Notary Nodes (NN).
The native daemon of Bitcoin, as well as any other blockchains the Notary Nodes are securing. So, since the first implementation of dPoW was done on Komodo, the Notary nodes needed the full blockchains of both Bitcoin and Komodo. This rule is absolutely mandatory, but only Notary Nodes (not miners or ordinary nodes).
The blockchain that is being secured with dPoW by Notary Nodes does not require its client nodes to run any other blockchains. For example, if Komodo is being dPoW secured by notarizing it’s latest blockhash to Bitcoin, the users using Komodo do NOT need Bitcoin running alongside Komodo. The same applies to any runtime forks of Komodo, now called Assetchains. Normal assetchain nodes are not required to run Komodo alongside their assetchain daemon. The same applies to any 3rd party blockchains being secured with dPoW security.
Need 64 pubkey of addresses from each individual Notary Node participating in delayed Proof of Work (dPoW) consensus. (Note that it is possible to generate multiple addresses for different blockchain with the exact same pubkey.)
Since the 64 Notary Nodes need to run the full blockchains of Bitcoin, Komodo, as well as all other dPoW-protected blockchains, it is mandatory to have a high-quality server with a good Server-level CPU, at least of 64Gb or more RAM, a 100Mbit/s internet speed connection, and enough fast SSD storage space to store Bitcoin and all the other blockchains (about 1 Tb of storage is sufficient).
64 highly skilled Notary Node operators who are experts in managing the Linux operating system, with high skills in system admin and network security of the machines they are using for Notary Node.
A big community of blockchain holders with a good distribution of its coin supply. These are needed so that they can use the weight of their coin ownership and use that weight to vote for these Notary Node operators. The Notary Node operators who get the highest vote counts from the top are selected as official Notary Node operators.

Please note that the current 64 Notary Nodes are the second cohort of Notary Nodes. This means these nodes were elected in Komodo’s second annual Notary Node Elections.

Since dPoW was first created, there have been 4 Notary Nodes reserved for Komodo’s developers. This is still true today.
The other 60 Notary Nodes are elected based on the votes of KMD holders and how they vote for the Notary Node operators.
In the second year of Notary Nodes, the top 30 Notary Nodes that completed the most notarizations (of Komodo to Bitcoin or Assetchains to Komodo) are automatically re-elected. In other words, the best-performing notary nodes are automatically re-elected. This gives notary node operators incentive to do their job well, rewards diligent operators, and ensures a smooth transition from one cohort to the next.
The lowest 30 Notary Nodes positions are opened to the community.
The location of Notary Node servers must be diversified on all continents. That is why you see the existing Notary Nodes categorized in the following locations: Southern-Hemisphere (SH), Asia-Rusia (AR), North-America (NA), Europe (EU).

What it takes to be a Notary Node operator and be selected by the community:

A Notary Node operator must first perform in the test notary node network, which works as a separate network on real hardware and blockchain network. It does take some initial investment to get started with notarizations on the test network.
Notary Node candidates do NOT need to have a single unit of KMD or any other cryptocurrency to participate in becoming a Notary Node. Anyone skilled enough to manage multiple blockchains nodes and a server with ultra-strong security can stand for Notary Node election.
Deep knowledge of blockchain internals is not required but candidates should have basic knowledge of blockchain node management, as can help very much in case of maintenance issues.

All in all, it is neither overly difficult nor completely straight forward to become a Notary Node operator. It requires some time, skills, and a financial investment to get started with becoming a worthy enough Notary Node operator to be elected by the Komodo community.

Notary Node Elections are announced in advance and give ample time to the participants to advertise themselves (i.e. campaign) and prove to the community that they are skilled enough and can perform well in the test notary node network. From a marketing point of view, campaigning won’t do much unless a Notary Node candidate shows enough data to demonstrate they performed well in notarizations on the test network.

There are already a few, but I’d like to encourage even more Komodo Platform Ecosystem projects to stand in the next Komodo Notary Node Election. You all deserve to be a part of the Notary Nodes network since you are using dPoW mechanism and it is indeed giving the best security to your projects.

Fact check 1:

If you have read through this article so far, I thank you first for your patience. Let’s take a moment to review and lay out some of the facts that we’ve covered in this post so far:

The process of becoming a Notary Node is a community-driven event. It is very hard (and suicidal) for a notary node to be elected and then try to behave selfishly after becoming Notary Node operator.
dPoW does not mine/generate blocks, so Notary Nodes cannot act as attackers in a 51% attack.
Since holding any cryptocurrency (BTC, KMD, or otherwise) is not a requirement to become Notary Node operator, Notary Nodes are nowhere near the concept of Masternodes. Notary Nodes are NOT Masternodes. They have nothing in common.

Powers of Notary Node operators:

According to the architectural design of how delayed Proof of Work (dPoW) functions, the Notary Nodes are given literally no power over a blockchain, so even if they try they cannot disrupt any blockchain secured via dPoW.

dPoW related powers:

A Notary Node operator participates in the notarization of each blockchain running on their notary node machine. The worst thing an evil Notary Node could do is choose to stop participating in the Notarization process (for either an individual specific blockchain or for multiple blockchains).

Mining or Block generation related powers:
Notary nodes do not have the power to generate blocks. There is no set rule in delayed Proof of Work (dPoW) consensus code that gives them special mining abilities, except on the Komodo blockchain itself.

Notary Nodes can NOT “easy mine” Assetchains or any 3rd party blockchains they are running on their machine/server. If they wish to mine these blockchains, they can participate in mining like any other miner in that blockchains’ network by using the CPU/GPU/ASIC/Rented hash power like everyone else.
Notary Nodes do invest time, money, human resources/skills, hardware/software resources and infrastructure to run and manage the Notary Node they are operating. That is why the ONLY privilege given to Notary Node operators is periodic “easy mining” for blocks on the Komodo ($KMD) blockchain (and only the KMD chain). The Komodo blockchain source code includes the 64 pubkey of Komodo addresses which are of Notary Nodes. Each Notary Nodes elections these 64 pubkey are updated in the code. Any address which is mining $KMD from one of those pubkey is granted “easy mining” benefits.

Based on this mining power, all 64 Notary Nodes combined can mine roughly ~75% of the blocks mined in a day. The remaining 25% is mined by the other miners on the Komodo blockchain network. But I have also seen at some points the notary nodes and other miners with the ratio of about 65:35 and even more fluctuations in blocks mining. So, this mining rule is not so strict.

Let’s also count on how much a single Notary Node can earn from this approx. of ~75% mining rewards being a Notary Node.

KMD block time: 60 seconds
KMD block reward: 3 KMD
Possible blocks in a day: (60 seconds = 1 minute. 1 hour = 60 minutes. 24 hours = 24 x 60 = 1440 minutes) = 1440 blocks, (1440 x 3) = 4,320.0 KMD
Possible blocks and KMD in a month: (days in year / months = 365.25 / 12 = 30.4375 days a month. 30.4375 x 1440 = 43830 minutes) = 43830 blocks, (43830 x 3) = 131,490.0 KMD
75% of blocks in a day: 1440 x 0.75 = 1080 blocks, (3240 x 3) = 3,240.0 KMD
75% of blocks and KMD in a day by individual Notary Node: 1080 / 64 = 16.875 blocks, (16.875 x 3) = 50.625 KMD
75% of blocks and KMD in a month: 43830 x 0.75 = 32872.5 blocks, (32872.5 x 3) = 98,617.5 KMD
75% of blocks and KMD in a month by individual Notary Node: 32872.5 / 64 = 513.6328125 blocks, (513.6328125 x 3) = 1,540.8984375 KMD
Value of single KMD coin as per 9th December, 2018 snapshot: $0.606774 USD
Value of single KMD coin as per 24th December, 2017 snapshot (the snapshot showing highest ever KMD value): $10.49 USD

Based on the current lowest value of KMD a single notary node will most approximately earn:

Daily: 50.625 x 0.606774 = ~$30.717934 USD approx.
Monthly: 1540.8984375 x 0.606774 = ~$934.977109 USD approx.
Yearly: 1540.8984375 x 12 = 18490.78125 KMD x 0.606774 = ~$11,219.725302 USD approx.

Based on the highest value of KMD snapshot on CoinMarketCap.com a single notary node will most approximately earn:

Daily: 50.625 x 10.49 = ~$531.056250 USD approx.
Monthly: 1540.8984375 x 10.49 = ~$16,164.024609 USD approx.
Yearly: 1540.8984375 x 12 = 18490.78125 KMD x 10.49 = ~$193,968.295313 USD approx.

So, these are the worst case and best case scenarios for any single Notary Node. But these calculations are still not completely accurate, as the value of KMD can never be static, just like every other currency or asset in the global economy. So, I guess using an average is good for this calculation. Let’s just assume that the Notary Node operator never spends their KMD to pay for any expenses or bills to manage their Komodo Notary Node server. I’m just taking an average of $2.50 average price of KMD just by looking at the chart and without putting my mind to figure out the exact average cost of KMD in last 1 year.

source: https://coinmarketcap.com/currencies/komodo/

So, based on a rough average price of $2.50 per KMD, this is what a single notary node will most approximately earn:

Daily: 50.625 x 2.50 = ~$126.562500 USD approx.
Monthly: 1540.8984375 x 2.50 = ~$3,852.246094 USD approx.
Yearly: 1540.8984375 x 12 = 18490.78125 KMD x 2.50 = ~$46,226.953125 USD approx.

Of course, there is also a possibility of KMD will value increase in the future. But it is impossible to predict the future. Let’s just chose an optimistic value but still keep a conservative mindset while deciding of the value of KMD in 1 year, like any other cryptocurrency investor hopes I think. Since this is just a vague price, it doesn’t make sense at all, but just for fun and good hopes, let’s choose a price that’s a little bit more than an all-time high of about $13.78 by adding $5 to get $18.78 USD per KMD.

Based on this totally hypothetical future price this is how a total earning of a single Notary Node operator may look like:

Daily: 50.625 x 18.78 = ~$950.737500 USD approx.
Monthly: 1540.8984375 x 18.78 = ~$28,938.072656 USD approx.
Yearly: 1540.8984375 x 12 = 18490.78125 KMD x 18.78 = ~$347,256.871875 USD approx.

One might ask what is the whole point of calculating all these prices and hypothetical future figures, There are two important reasons for these calculations:

It makes sense to look at these figures when the suggestion is raised that a Notary Node can turn out to be evil and do some suicidal attack on itself and the KMD network (or one of the networks of a dPoW-protected chain). These figures are also relevant when doubters suggest some kind of mass suicidal attack where the hypothesis is that many or all 64 Notary Node operators can collude with each other can make some kind of group attack on a blockchain.
If a Notary Node performs its operations for a whole year and performs well enough to be one of the top 30 Notary Node, it gets automatically re-elected, thus it gives a very strong incentive for a notary to not be suicidal and performs its duties as assigned.

Excel view of the calculations performed in this section for estimated earnings that a Single Notary Node can earn

The above earnings calculations demonstrate how much money suicidal Notary Node operators would be giving up if they choose to abuse the one and only power they have, which is to notarize the dPoW-protected blockchains they run on their Notary Node server.

I call this hypothetical attack that one or more Notary Nodes can do a Suicidal Attack. Again, all that the node(s) can possibly do is refuse to participate in notarizations of a blockchain which it is tasked to notarize.

dPoW monitoring
Notary Nodes run blockchain daemons (i.e. a full node) for each of the 40+ different blockchains they are notarizing at the moment. This adds 64 new nodes to the network of each dPoW-protected, chain, increasing decentralization and security.

Notarizations are tracked and data is collected for each Notary Node. This allows anyone to publicly see how each Notary Node is performing for each dPoW-protected chain. Here are two websites, created by members of the Komodo community, that show the stats and activity of the Notary Nodes:

There are a few Notary Node operators who are also running private monitoring services to keep their blockchain nodes, servers, and network running at all times. Anytime either their own or someone else’s Notary Node misbehaves, they get instant notifications.

Notary Node operators are putting in extra efforts to ensure that their node is always in shape and performing well. Each node wants to get as many notarizations as possible by the end of the year, so that they can be one of the 30 automatically re-elected nodes.

Why it’s a lose-lose situation for a Notary Node to act against dPoW

Notary Node operators spend a significant amount of their time and money setting up and managing their Notary Node. All of that investment is at risk if the operator tries to go against the protocol. Attempting to act maliciously would almost certainly not be worth as much money as the compensation they receive for being an operator.
By the time a Notary Node operator builds a reputation as one of the most trusted and best-performing Notary Nodes, the incentive to act maliciously is reduced even further, as the operator is not only giving up financial losses for the current year but also for the future year.
The chance of being automatically re-elected in next year’s Notary Node Election is lost entirely if a Notary Node acts against dPoW.
Any Notary Nodes that are performing well are noticed quickly, as there are other Notary Node operators continuously monitoring the dPoW process and its efficiency. In the event of any funny business, some Notary Node operators would get notified and alert the whole network.

The Process of Notarizing Komodo blockchain to Bitcoin

By this point I assume:

you understand the basics of Proof of Work.
understand the overview of 51% attack and how double spending a transaction may happen.
the requirements for dPoW and Notary Node operators.

Independent peer-to-peer network of 64 Notary Nodes: Let’s clear up the history of when the first delayed Proof of Work network was created. There is an individual repository under jl777’s GitHub account, SuperNET. This is the repository which includes the source of daemon iguana which is responsible for creating a peer-to-peer network of Notary Nodes for dPoW operations. All 64 Notary Nodes compile and run this iguana daemon on their machines, along with full Bitcoin blockchain node, and full Komodo blockchain node.

This is a totally separate peer-to-peer network of Notary Nodes, where it’s the job of iguana to connect with each of the nodes in the network and broadcast messages with various dPoW related information.

Remember that this is not a cryptocurrency or any blockchain peer-to-peer network, it is specifically just for sharing the data related to dPoW processes between Notary Nodes.

One pubkey for all blockchains: As explained in the dPoW requirements, each Notary Node provides the pubkey of a Bitcoin or Komodo address. iguana has the code library which allows to calculate the address of all other blockchains which links to the same pubkey.

For example, if one Notary Node provides a pubkey of an address format from Komodo, it is possible to calculate a blockchain address for any other BTC-based blockchain, including Bitcoin, Litecoin, GameCredits, EMC2, Hush, Ethereum, any Komodo Assetchains, etc. The Komodo Assetchains, however, share the same address format with Komodo. The private keys of these different blockchain address formats are generated through iguana which provides an API and gives the Notary Node operators a list of the different coins’ address, private key, and public key information just by using a single passphrase.

The benefit of having the same pubkey for all different formats of blockchains is that in case a 3rd party blockchain needs to add dPoW consensus layer on top of its existing consensus layer, all they need to add is the same pubkey list of Notary Nodes which is being used by Komodo and other blockchains. The list doesn’t need to change from chain to chain.

This allows any 3rd party blockchains to rely less on Komodo developers and Notary Nodes. If the developers of a 3rd party blockchain — that is, any blockchain not created within the Komodo ecosystem — and they understand the process of implementing dPoW onto their blockchain project, they can just implement it without permission. Then, they can request that the Komodo team add their project to Notary Node servers.

Such 3rd party projects can also setup their own Notary Node networks, which can notarize their blockchain to Komodo. (There is already a project in Komodo Platform ecosystem that does exactly this, KMDLabs) But of course, they can save a lot of time, effort, and money just by having their chain added to Komodo’s existing Notary Node network (rather than creating their own).

Prior to connecting to the Notary Node peer-to-peer network, an individual node need to do the following tasks by using iguana API, which are all scripted in the code.

Start Bitcoin, Komodo, Assetchains, and any 3rd-party cryptocurrency daemons.
Make sure they are synchronized to the existing network and up to date with the full blockchain.
Fetch any updates of iguana daemon, compile it, and start iguana daemon and issue the coin connection API command for iguana to connect it to all the RPC API of cryptocurrency daemons running on local machine/server. This step makes iguana talk to the all the daemons running on local machine.
Login to iguana with the passphrase of that notary node.

At this point, iguana begins talking to all the local cryptocurrency daemons and getting the information such as:

Latest block height + blockhash, as shown in example below

[BTC].1131235 KMD 0b449e03e777d8fce1ab31d3fec6749804da85fd61f0044940b071bbf22d2071 height.1131236 vs last.1131236

And this is not just for Komodo blockchain, but for all dPoW-protected chains — all Komodo Assetchains as well as 3rd party blockchains — which looks like this:

[BTC].1131255 KMD 01f926f16b380f5b7353bbe388eda604fcb74dedaabf84e18d0608db85e24e86 height.1131256 vs last.1131256
[KMD].252711 HODL 0008cb2e4e793ce931d7de29f10f3a546b7a31dbbe21881db4042accd05b7c14 height.252712 vs last.252712
[KMD].2653660 CHIPS 0000000000001d41eba16c82811c53aa2bdbcaea946cb5b003064f65408fcddc height.2653661 vs last.2653661
[KMD].111594 SEC 0a97703662777e5e37161d784bab3f83098f8871d8e3b77d743b759805808d9c height.111595 vs last.111595
[KMD].2175145 EMC2 d670d53b9f2e32b046c5a9ef58344a841cec072e434c105e5b0970f4002e8b91 height.2175146 vs last.2175146
[KMD].235138 BET 004ef2c08c86401909057dd40d9382c4a43ab806a26b7df5f84d127408ac2063 height.235139 vs last.235139
[KMD].2653661 CHIPS 00000000000028e030686426e7e45bde2ed148d3a9b346fa0933075cce5ffc34 height.2653662 vs last.2653662
[KMD].143684 PIRATE 0000000187b1be1bc3495473bff0f380fcd03305b2461135009ac274017e8ded height.143685 vs last.143685
[KMD].446836 REVS 00fd735d00a241d9ce4d4fcfc51cf936a094a06f7ffc38d26f43715f83db1254 height.446837 vs last.446837  
[KMD].281221 VRSC af107c608daa3f9026cf0c239e611cdbf621fedcfa2fce376c3ef63c48da13cc height.281223 vs last.281222  
[KMD].281223 VRSC d0c7a3b5c1d9b1049fdfaf3a19d51c91955c3ceab191f4a952c60c025c2f6afa height.281224 vs last.281224  
[KMD].241375 RFOX 0025dfb07997890ca4bd7139a8cbe62470c494fa89086f116e63f983ef715123 height.241376 vs last.241376  
[KMD].130041 MGNX 09f93b3811cca54bb40a8f17357c4dcf8ba377dbe05d25e7cf69a672f0a2610a height.130042 vs last.130042  
[KMD].446837 REVS 00c360d6d52a2ce589d8854f168e97905908b2fa73f1dc752917dc8942e907f5 height.446838 vs last.446838  
[KMD].424349 BOTS 0001d471064478f971a99628c42411bc83b10eef1c5e0e501d09564b6d608a7a height.424350 vs last.424350  
[KMD].2232448 GAME 4e9ec27e13ea81512192d27d32d9e8e0b5dd324b447bd6aa63ef0f4d4ff9b2f7 height.2232449 vs last.2232449
[KMD].130042 MGNX 0cc47b5be512c215b7c1a285f36dd1b5cc5588f8f689aa3a9a4888972f4a261d height.130043 vs last.130043  
[KMD].75749 DION 0a71c7b911dd59438e479547e6e96749c7b36387a1a5168c9a4fdff755e45291 height.75750 vs last.75750
[KMD].235139 BET 00963ea39fb4f3a69af43d68115b6592db9886fe94ed89c2454632d9c6c9a51b height.235140 vs last.235140   
[KMD].181311 EQL 02664b3fd8c6719a4e397cdac412342c90a159df7718ab235ea1290ec38bfdca height.181312 vs last.181312   
[KMD].213609 MGW 00007b8416f876deecab3116b99636b9faad0ed78d3d19738f9001cc94ac2036 height.213610 vs last.213610   
[KMD].36763 ZEX 0000003428a03a46cc9f5ca0b5a896c91575194810e874ecf094993b4895c69d height.36764 vs last.36764

Soon enough, iguana initializes its connection to the rest of the 64 Notary Nodes in the network.
Then, the dpow command is executed for every single blockchain which starts the process of Notarizing that blockchain. The command includes the cryptocurrency ticker like CHIPS and the pubkey of that notary node, which looks like the following:

#command
curl --url http://127.0.0.1:7776 --data '{"agent":"iguana","method":"dpow","symbol":"CHIPS","pubkey":"02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c"}'#output
02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c DPOW with pubkey.(02957fd48ae6cb361b8a28cdb1b8ccf5067ff68eb1f90cba7df5f7934ed8eb4b2c) RV8Khq8SbYQALx9eMQ8meseWpFiZS8seL1.valid1 CHIPS -> KMD RV8Khq8SbYQALx9eMQ8meseWpFiZS8seL1.valid1, num.30 freq.100 minsigs.13 CCid.0

The dpow step verifies that the pubkey used for initializing the notarization process is valid, as it is compared with the list of 64 set pubkeys in the komodod daemon and in all those 3rd party blockchain daemons. It also verifies that that address linked to this pubkey is a valid address with ismine:true in local daemon.

First Basic Notary Nodes Consensus: As the Notary Node starts with all the cryptocurrency daemons up and fully synchronized, the process of the iguana daemon starts multiple parallel operations, which includes:

Checking the latest block height + blockhash of each connected cryptocurrency daemon.
Checking which was the last notarized blockhash in every blockchain.
Checking if Bitcoin, Komodo, Assetchains, and 3rd party cryptocurrency daemons’ address used by the local notary node is having sufficient UTXO set for notarization.

The first set of verification consensus for an individual blockchain for a valid notarization comes from its own blockchain consensus code (i.e. PoW/PoS). The blockchain code verifies this consensus in the same way that it secures the transactions from double spending. If the notarization transaction with valid set of OP_RETURN data is found in recent block height with valid blockhash, it doesn’t rely on the Notary Nodes to confirm that it is valid. It is the effect of the whole peer-to-peer network effect of that blockchain.

While iguana verifies the last known notarization height and the latest known block height + blockhash, it sends this collected data to all the rest of the known Notary Nodes in the network. Each node also receives the same set of data set from all other connected Notary Nodes.

It may happen that some Notary Nodes are receiving the latest blocks quicker than others, which is a common case with peer-to-peer blockchain networks. The iguana daemon keeps repeating this process of sending/receiving data between notary nodes, until enough notaries respond with the same information regarding block height + blockhash.

Selection of 13 notary signers with bitmask: For any given notarization, the notaries are numbered from 0 to 63. The one that is assigned 0 changes with each notarization to give each notary an equal chance over time to participate in notarization. Now all 64 nodes broadcast to each other their notarization data, along with the info they got from the other notary nodes. Based on this, all 64 notary nodes as a group propose the 13 signers for this round such that all of them are in agreement. At first, not so many nodes agree on all details but the proposal with the most support is switched to by notaries that are not already there, so after several rounds things converge so that we get 13 nodes all in agreement.

There are a LOT of possible set of 13 signers out of 64, which mathematically is 64 choose 13. A algorithm is used to reduce the selected 13 for each notarization round, but still, there are thousands of possible 13. A 64-bit number is used as a bitmask to denote the chose 13. The requirement is that it starts from the current iterations node 0, must have 13 bits set and each node in the bitmask must have the identical data.

So, if need to calculate that if 64 nodes choose a “set” of “13” signers what is the possible number of these sets which can be? And who will be these 13 selected nodes? We can use Combinatorics math to calculate that:

C(n,r) = n! / (r!(n−r)!) = ?C(n,r) = C(64,13)= 64! / (13!(64−13)!)= 1.313685881E+13= 13136858812224

So, according to this calculation there can possibly be 13,136,858,812,224 different set of 13 signers which can be chosen by 64 nodes. That is more than thirteen trillion possible sets of 13 signer nodes!

So this bitmask can’t be created until several iterations of communications between all the nodes, then nodes start proposing the mask to use. Every node broadcasts to all other nodes what it thinks should be the 13, while also broadcasting what the other nodes sent to it. So all the nodes can see what they get directly and also what the other nodes are seeing. This determines which set of 13 is most popular. Then, each node will switch if it is not already using the most popular mask. It’s critical that all 13 signers agree on the mask, since it’s the case that if the other nodes select a bitmask, but any of the 13 are not also in agreement, they won’t sign it and the notarization won’t work. It is somewhat similar to mining, randomized and hard to predict which 13 “win”. If a node doesn’t agree, and doesn’t shift to the winning 13 bitmask, it is just ignored. Over the years, the algorithm was improved to select the 13 that are all in agreement.

The 3 preceding paragraphs were copied (and edited slightly for clarity) from a description of bitmask written by jl777 (James Lee). Source: https://komodoworld.blog/2018/12/09/discussion-on-dpow-2/

Notary Nodes pubkey and their notarization chances: You can see the set of current notary nodes pubkey in komodo_notary.h file. In this array of 64 notary node pubkeys, and their assigned name, each set in programming terms starts from 0 to 63.

The Notary Node pubkey at position 0 is:

{"0dev1_jl777", "03b7621b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828" },

And on position 63:

{"xrobesx_NA", "03f0cc6d142d14a40937f12dbd99dbd9021328f45759e26f1877f2a838876709e1" },

In case I need to select for example a notary node 42 that would be:

{"meshbits_SH", "025c6e94877515dfd7b05682b9cc2fe4a49e076efe291e54fcec3add78183c1edb" },

NOTE that the position number in the pubkey array is just used for a variable myind. The logic of selecting the 13 node goes like this:

The logic of selecting the 13 nodes is by the position 0 to 63.
The position of 0 to 12 are selected as the 13 nodes.
In case the node in between these positions is somehow not available or not responding, the next position is used to cover its position and total the count to 13 notary nodes.
So, if this logic was kept by just using the myind position in the pubkey array, that would have resulted in always selecting only the first 13 from the pubkey array in the komodod code. To give a fair chance to each notary node in the network of 64, the position of the notary pubkey is shifted each notarization round.
That means in case the last notarization round the position of notary with 0dev1_jl777 was 0, it will in this new round be counted as 63, and the position 0 will move to 0dev2_kolo. So over 64 notarization rounds, all notaries hold the 0 position once. This way, it is a fair chance for all Notary Nodes and it doesn’t matter what the notary position is in pubkey array.
For the notarization round the position of each notary changes with this modular arithmetic calculation:

(myind + (block height/10)) % 64 = that round position of notary node

So, as per this calculation, for example, if the latest block height of the blockchain is 1000, and the current position of a notary node in this notarization round is, let’s say,myind=41, the calculation of that will end up like this:

myind = 41
blockheight = 1000
mod_number = 64
current_notarization_position = (41 + (1000/10)) % 64 = 13

The myind node with 41 value gets the position of 13 in this round of notarization. Since the selection of 13 notaries is from 0 to 12, this node will not be participating in this current notarization round. I hope this makes sense — it can be quite confusing.

Since each notarization round, the myind position of each notary changes, it is not possible to determine which notary node will be part of the 13 notary signers for a custom raw multisig bitcoin transaction.

Signing and broadcasting of notarization transaction: Remember the first requirement for dPoW, Bitcoin? This is where it becomes necessary for Notary Nodes to use Bitcoin in the notarization process. In case of an Assetchain or 3rd party blockchain notarization, the Notary Nodes first notarize that chain to Komodo, just as with Komodo’s block info getting notarized to Bitcoin. Now that there is a set of 13 notaries selected from the group of all 64, these 13 MUST have the same size Bitcoin and Komodo UTXO ready to create and sign a multisig bitcoin raw transaction.

The iguana daemon makes sure there are enough UTXO of the same size available in the Bitcoin address of every Notary Node. These funds are used for signing and sending a transaction to the bitcoin network along with notarization data in its OP_RETURN. This is a parallel process for iguana to always check if there are sufficient number of same-size UTXOs available in each BTC address. Currently, the BTC UTXO size used by notaries is 0.00010000 BTC, but there was also a time when this UTXO size was increased to 0.00050000 BTC because of the high transactions (spamming?) happening on Bitcoin network around the time of blocksize increase debates (2016–17). Then, as the network transactions started confirming smoothly again, the UTXO size decreased back to 10,000 satoshies again.

iguana code holds the condition for creating this custom multisig transaction as a template (unsigned raw transaction) which every notary node follows. The amount of BTC (0.00010000) in a signed transaction coming from other nodes is expected to use the same UTXO amount as specified in the template. If one of the Notary Nodes signs his own vin with an amount NOT equal to 0.0001 and broadcasts his signed txid to other Notary Nodes, the transaction will fail because other the Notary Nodes will think that it's signed for 0.0001 as all notaries have a predefined template of the transaction. Example:

vins:
1. address1 0.00010000
2. address2 0.00010000
...
13. address13 0.00010000vouts:
well_known_address 0.0013000

Each notary will insert the received signature in this template and the transaction will be valid ONLY if each signature corresponds to the template. It’s like createrawtransaction with given parameters. And each Notary Node signs only its own vin. They can not change transaction format, they can only sign it.

Each notarization transaction (except OP_RETURN notarization data part) is like a common transaction. It doesn’t use OP_CHECKMULTISIG like multisig transactions do.

To explain it in simpler terms, let’s just take the example of a local bitcoin wallet. Let’s assume you have a Bitcoin wallet on your local machine.

It has 13 different addresses, each having a set of 0.0001 UTXOs.
It’s presumed that you have the ownership of all these addresses, which means they are not watchonly addresses, but if verified they show ismine:true in result.
You need to send all of these funds + txfee (transaction fee) to one well-known address (for simplicity, let’s assume txfee=0).
If you send a transaction in the amount of, for example, 0.00130000 using sendtoaddress you will get a similar transaction like a notarization transaction (except the OP_RETURN data part). To compare, you can see a real notarization transaction on the Bitcoin blockchain here.
Transaction ID: 979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d
13 addresses showing as INPUT from which the UTXO of 0.0001 coins sent -> to one address.

The result would possibly be similar because your wallet has 13 different privkeys from these 13 different addresses, each having UTXO of 0.0001 and each vin signed separately with its own privkey. Exactly like in notarization transaction, but the process is totally distributed with the Notary Nodes for creating such transaction.

Each Notary Node has 1 privkey from their own address. So, each Notary Node signs only their own UTXO and broadcasts that signature to the other 13 chosen Notary Nodes. When notaries have received 13 signatures, a transaction is broadcast to the network.

In the case of 13 addresses in one wallet, this whole process is very simple as you have all 13 privkeys and all 13 signatures at the same time. In the distributed process of notaries exchange signatures, only after receiving all 13 signatures can the transaction be 100% complete. As you can see, this process is harder because, to complete a transaction, all 13 signatures MUST be correct, received, and 13 UTXOs must not be spent at the moment of broadcasting the transaction.

The main thing to understand here is that it’s not a kind of “custom raw bitcoin transaction.” It is just 13 UTXOs from 13 different addresses being spent, and notarization-specific data in OP_RETURN, nothing more. No hard locking or unlocking scripts, no OP_CHECKMULTISIG, no hard things. Just a common transaction, but the complexity is in making all this possible through a “distributed network.”

I’m very thankful of Decker, who gave such descriptive example, which I used in later part of this description with a few minor corrections.

As per the above description, it must be clear to the reader that it is the exact same blockchain conditions which any other blockchain wallet user might use to create a transaction on their machine and broadcast that transaction over the network. The only difference here is that this process is a bit harder due to the “distributed network” of Notary Nodes and it includes the notarization data in OP_RETURN on the blockchain it is sending coins on, along with that multiple-signature transaction.

There is nothing fancy, and the process follows the same bitcoin network rules as an ordinary transaction. The transaction will be rejected if it isn’t valid, since all the same rules that apply to other transactions apply to notarization transaction, too. It is not even possible for Bitcoin developers to try blacklisting or stopping such transactions from taking place on the bitcoin network. If, for some strange reason, someone wanted to stop Komodo from notarizing to the Bitcoin network, they would not be able to. The notarization transactions are simply sending a small amount of Bitcoin, which is the core process of the whole network’s protocol. So, suggesting that notarization transactions can be blocked by some network is similar to saying that that network would invalidate creating and sending transactions to that network. It just doesn’t make sense.

On Notary Nodes, the Komodo block notarizing to the Bitcoin network looks like this in iguana logs:

>>>>>>>>>>> BTC dpow_sendrawtransaction (979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d)complete statemachine.BTC ht.1131240 state.1000 (4000000 b8239d97)

Confirming the notarization on the blockchain secured by dPoW: iguana only waits for the txid to be accepted to the Bitcoin mempool before starting the process of writing this notarized block information back onto the Komodo blockchain. Note that Bitcoin block time does not prevent notarizations from happening, but while the transaction is still in the Bitcoin mempool, it is relatively less secure when compared to a confirmed Bitcoin transaction.

As soon as the txid is accepted to be in Bitcoin mempool, the Komodo side of confirming the notarized block height process is initiated. The iguana log in such an event looks like this:

[44] END isratify.0:0 bestk.29 2400a12021236000 sigs.2400a12021236000 state.ffffffff machine ht.1131240 completed state.ffffffff BTC.979d23b8d929ccefdb79aabffa2d632f09b292bea71fe1efa4ce467d808ce12d KMD.838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c recvmask.7fd4fbb7fb67645d paxwdcrc.6ab6b224 0x7fb6de811010 0x7fb6f4097010>>>>>>>>>>> KMD dpow_sendrawtransaction (838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c)complete statemachine.KMD ht.1131240 state.-1 (4000000 d0848b83)

Komodo txid link: https://kmdexplorer.io/tx/838b84d051308eeeb442bd0f2f2fdd85d758b4f3a8bb287a2ca2b4bff723161c

As the transaction is confirmed by the Komodo blockchain miners, and as it synchronizes with the rest of the peer-to-peer network, the validity of this notarized transaction is confirmed by the blockchain miners and the rest of the network nodes who have the full copy of the Komodo blockchain running on their machines. Here again, it is nothing fancy (except the hard “distributed network” process of creating this transaction). It’s exactly the same as any other transaction sent over a blockchain network, along with OP_RETURN data in that transaction, which is then validated by the network.

Notarized block height is irreversible: Once the notarized block is synchronized with the rest of the peer-to-peer network, it is not possible to reorg that block. This means it is irreversible. It is a rule of the dPoW consensus layer that the blocks prior to the point of the most recent notarized block height are now strictly incapable of being orphaned.

dpowconf and rule on confirmations count: In a dPoW-secured blockchain, the transaction confirmation rule (known as dpowconf) was updated to use the following logic after there was an attempt to carry out a double spending attack (by forkwitch and geocold51) on the EMC2 blockchain which is secured by dPoW notarization:

Once the transaction is broadcasted to the network it waits to be accepted in the blockchains mempool.
Once accepted to be in mempool, it waits for 1 confirmation, and does not go past the count of 1 confirmation until the next notarized block.

So, if a transaction is broadcast to the network at the time when the last block notarized was known to be, for example, 2 blocks ago, then the transaction waits for at least 1 notarization even after the block it is included in is confirmed. As the next block is confirmed, the count of this confirmations stays at 1.

There is another object in the JSON output of the raw transaction data called rawconfirmations which shows the actual confirmations as the block confirmations keep increasing by time.

Let’s assume that for the next 10 blocks there is no notarized block synchronized to the blockchain. In that case the output of txid raw transaction would show confirmations: 1 and rawconfirmations: 10. And in case the 11th block is notarized, the count would then update to confirmations: 11 and rawconfirmations: 11.

An example of a Komodo transaction would look like this in command line outputs:

satinder@linux:~$ komodo-cli getrawtransaction "002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1" 1 | tail
  ],
  "vjoinsplit": [
  ],
  "blockhash": "00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6",
  "height": 1138123,
  "confirmations": 1,
  "rawconfirmations": 1,
  "time": 1544696732,
  "blocktime": 1544696732satinder@linux:~$ komodo-cli getrawtransaction "002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1" 1 | tail
  ],
  "vjoinsplit": [
  ],
  "blockhash": "00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6",
  "height": 1138123,
  "confirmations": 1,
  "rawconfirmations": 11,
  "time": 1544696732,
  "blocktime": 1544696732
}satinder@linux:~$ komodo-cli getrawtransaction "002dc8d587b0ea34797c8f3ab87ee8d3377443672b8d5d0fafcf826592c921f1" 1 | tail
  ],
  "vjoinsplit": [
  ],
  "blockhash": "00000003063189fef9623f920cc4c9444af857004fed8a21361351aee8690fe6",
  "height": 1138123,
  "confirmations": 23,
  "rawconfirmations": 23,
  "time": 1544696732,
  "blocktime": 1544696732
}
satinder@linux:~$

The effect of this updated rule is pretty simple and straightforward: to secure the blockchain from any double spending 51% attacks. It is a known fact that centralized crypto exchanges don’t make wallet deposits available to their customers until there are N number of confirmation counts available on some transaction id. So, this dpowconfs rule is the most secure way for any centralized exchange to stay safe from any kind of double spending 51% attacks for any blockchains that have adopted dPoW security.

Myths and Facts about delayed Proof of Work

Myth 1. Notary Nodes is a Centralized Solution

There are 64 Notary Nodes
All 64 Notary Nodes are community elected.
* 4 Notary Nodes are developer nodes. They get re-elected every year.
* 30 Notary Nodes get re-elected based on their performance of notarizations to BTC (and to KMD from Assetchains).
* 30 Notary Node positions are open for election every year
* The transaction creation process is like any other regular network node, and broadcasting that transaction from any node with the notarization data doesn’t make that process a centralized process.

Myth 2. Notary Nodes are equals to Masternodes

Unlike Masternodes, to become a Komodo Notary Node Operator you need precisely 0.00000000 KMD. You DON’T need KMD to become a Notary Node Operator. Just get elected by KMD community and start performing the notarization process.
Prior to the public Notary Node network launch, a testnet is operated to evaluate the reliability and skill set of Notary Node candidates. This helps the Komodo community and team-members to ensure that the most efficient and skilled Notary Node operators get elected for the decentralized Notary Node network.

dPoW Attacks Analysis

The original, unedited version of dPoW whitepaper written by jl777 (James Lee) includes all the possible attack analysis and gives a brief overview of why those attacks are not possible in the presence of notarized blocks on a blockchain:

Link: https://github.com/KomodoPlatform/komodo/wiki/Delayed-Proof-of-Work-(dPoW)-Whitepaper#attacks

Double Spending Attack:

At the time of the writing of jl777’s iteration of whitepaper the dpowconf consensus rule wasn’t present in the working code base. After dpowconf feature was added, a 51% attack is even more difficult. In the example of a double spending attack, an attacker can try mining blocks with a greater hash rate than the network that is securing the blockchain under attack, but such attacks are only possible until the next notarization takes place.

For example, if a chain gets a new block roughly every 60 seconds (like KMD and Assetchains), and the frequency of notarization is approximately every 10 minutes, the maximum amount of time an attacker has to do an attack in between notarizations is about 10 minutes. That’s about 10 blocks (or 12 at the very most) that an attacker can possibly try to reorg, as they cannot reorg back past a previous notarization.

Further, just as all exchanges follow the rule of needing more than 1 confirmations for deposits, the dpowconf rule on confirmations keeps both the notarized blockchain users and it exchanges secure from such attacks, as the confirmation counts only increase if the blockchain sees a notarized block.

I’ll not cover all possible attack vectors in this post, as it has already has grown too long. If the need arises, I think it’d be better to just write a dedicated post to dPoW attack analysis.

Let’s just move on to the latest hypothetical attack vector proposed by Justin Ehrenhofer in this chat log of a discussion between jl777 and Justin on the Komodo Discord server.

Notary Node Suicidal Attack

I chose to call the proposed attack a suicidal attack, as this name fits the hypothesis. As I understand it, the discussion came to this point because none of the other possible attack vectors made sense. It would be immensely difficult to attempt any such attack on a dPoW-protected chain, and mostly just a waste of time, energy, and money.

It was suggested that if external parties cannot harm a dPoW-secured blockchain, then perhaps the Notary Nodes themselves could do harm. The suicidal attack assumes that either single or half or possibly ALL Notary Nodes act against the delayed Proof of Work consensus by disagreeing on the consensus protocol communications transmitted between Notary Nodes.

Single Notary Node disagreement: Every node connected in the network of 64 notary node sends every other connected notary node the information of the latest block height along with its blockhash. This information along with the bitmaskinformation is also broadcasted throughout the network by every single Notary Node to all others. They all communicate with all other nodes which 13 Notary Nodes should be selected as signers for the selected block height, and they all see the info that all other Notary Nodes sent to them. So all the nodes can see what they get directly and also what the other nodes are seeing. Given that, they are able to select the 13 who are in agreement and converge to the 13. If a node doesn’t agree and doesn’t shift to the winning 13 bitmask, it is just ignored.

The bitmask is a result of a combination of information from latest block height + blockhash + bitmask calculation + the agreement of other Notary Nodes in the network. A single notary node cannot disrupt the notarization process.

The block height and blockhash information is agreed upon by the Notary Nodes in exactly the same way a transaction is agreed upon by all of the full nodes on any blockchain network.

This kind of situation can also happen unintentionally by 1 or more notary nodes. If a notary node operator’s blockchain daemons are not running properly and that results in not having the full synchronized blockchain, they must wait to synced 100% with the network before participating in the notarization process. In such cases, the above rules apply and they get skipped from participating in the notarization while they are syncing since the information known to them is not matched with the information available with fully synchronized blockchains on the other nodes.

More than single Notary Node disagreement: Let’s assume that more than one Notary Nodes are either not 100% synchronized on the chain or they are intentionally disrupting the network by giving false information to create disagreement on the notarization communication between Notary Nodes. This probably won’t be much of an issue, depending on what ratio of the Notary Nodes are in disagreement with other.

Recall that there needs to be at least 13 Notary Nodes required to sign a notarization transaction. If there are at least 13 Notary Nodes not agreeing on the network with block height + blockhash + bitmask + what other notary nodes think which nodes must be the 13 nodes for signing next notarization blocks, just like the single Notary Node all 13 disagreeing nodes will also be ignored.
In case there are more than 13 Notary Nodes, like almost half of the Notary Nodes, disagree on the network, the same case will happen with those, too, as 13 nodes can still communicate and reach consensus.
If more than half of the Notary Nodes disagree with the others, then there come the last 13 nodes who actually agrees to the information of “block height + blockhash + bitmask + what other notary nodes think which nodes must be the 13 nodes”.

The point is that the information of the block height + blockhash coming from the network is the first truth to the Notary Nodes. It is not the decision of Notary Nodes to decide which block is supposed to be accepted or not on any political basis, etc. It is like any other blockchain’s first layer consensus rule.

Notary Nodes hold a full copy of the blockchain on their machines and verify the validity of a block by checking the proofs available in the history of the local blockchain and by agreeing with the rest of the peer-to-peer connected network nodes which are not even miners or notary nodes, but just other regular nodes. Agreeing on the latest block height + blockhash is just agreement on a network-wide, peer-to-peer consensus rule.

The group of Notary Nodes who are operating by the consensus always select 13 nodes that are in agreement, using what is basically a decentralized process, even if only 64 nodes. And having such trusted Notary Nodes results in the notarization of blocks secured by dPoW consensus.

The only condition where Notary Nodes can genuinely conflict with others and not agree on the information shared with others is in the event of chain-split. Events like the one between Bitcoin Core and Bitcoin Cash several years ago, where the blockchain shares the same blocks and transaction history to a point but splits into two different competing blockchains, resulting in a divergence of rules used by the miners and network nodes agreeing on that rule-set for each split of that blockchain.

I find it really hard to believe that a blockchain which is being notarized could be split. There are many variables to disagree on for any blockchain but the consensus is almost always reached and notarizations ensure that the chain cannot be altered every ten minutes!

If an attacker (doesn’t matter that miner is notary node or external attacker) or external miner are mining in private, then none of the notaries would have that chain, so it needs to be broadcast. But if it is broadcast then it is subject to the notarization rules. So, if an attacker starts mining from the last notarization and propagates it to many nodes — well if they do that, then it becomes the main-chain and gets notarized. I think that will solve the chain-split event, as the chain which is notarized is, in fact, the main-chain. So, even in the case of an ideological chain split, there will be one split of the blockchain which is actually being notarized and receiving dPoW security and the other which is not.

Basically, everything needs to be working properly for notarization to happen. The Notary Node operators can attest to this. So the absence of notarization on a dPoW-protected chain is a strong signal that some sort of abnormal event is happening.

Mass Notary Node disagreement: Let’s suppose that the whole Notary Node network is disagreeing with the rest of the peer-to-peer full blockchain nodes network and the miners. And the target of their attack is to reorg the block which is already notarized. Since the protocol of dPoW doesn’t allow a reorg of the blockchain beyond the notarized block, it is not possible.

Let’s say that some Notary Nodes are agreeing on some other part of the blockchain which has already been notarized to a different blockchain, and other Notary Nodes are trying to notarize some other split part of the blockchain. This is exactly the same as the situation explained above (a chain-split event). And if all the notaries are disagreeing to the rest of the network, and the network wants to switch beyond the notarized block, there needs agreement in multiple parties, like:

Miners, who are mining the blockchain.
Network nodes holding the full copy of that blockchain.
All Notary Nodes, who agree on reversing the blockchain to some height beyond the notarized block height.

Such scenario a looks a lot more like a blockchain hard fork event, which is already public and they already agree on this blockchain event. But, this is only possible on 2 conditions:

Notary Nodes re-sync the blockchain to the blockchain copy of the nodes/miners which is mining a copy of their blockchain at first point disconnected from the rest of the network, and then only connected to the network which agrees that their copy of the chain is the accurate copy (the mainchain).
A node can invalidate the notarized block and avoid re-sync blockchain, but that is up to each node. So any attempt to switch the main chain from A to B via notarizing B, this is a very noticeable process.

My claim is that dPoW isn’t perfect, but, for a chain without a large hash-rate, it sure is better than not having dPoW. — jl777, Komodo Platform core developer

Paraphrasing Jame’s chat text here (source):

Usually a re-sync won’t be needed, just to invalidate the chain A notarization, but that is up to each node. So any attempt to switch the main chain from A to B via notarizing B, this is a very noticeable process.
And there would need to be overall consensus on which chain it is the correct chain, trying to get a double spend through via this mechanism is not very practical. It would be much easier to 51% attack a non-notarized chain. My claim is that dPoW isn’t perfect, but it sure is better than without having dPoW for a chain without a large hash-rate.
You can convince a node that didn’t see the notarized chain that there is chain B. Once it is notarized, it can’t be double spent. If they re-sync, chain A wins as it has the notarization. Chain B would never get above 1 “confirmations” as it never got a notarization. So anybody on chain B wouldn’t honor any payment.

The collusion of Notary Nodes and some attacker who’s trying to double spend, this method is not so practical, as this process is very noticeable for the rest of the network.

Points about the virtual impossibility of notary nodes colluding to conduct attacks

First off, any dPoW-protected blockchain receives an immense security boost from the dPow mechanism. This is true for Notary Nodes, ordinary full nodes, and miners alike. While Notary Nodes have a very slight advantage over ordinary full nodes and miners in executing an attack on a dPoW-protected chain, it is still magnitudes more difficult for Notary Nodes to attack a chain if it has dPoW than if it does not have dPoW.
Any specialized Notary Node attack immediately incriminates the operators, i.e. everyone will know who did it. So, even in the unlikely event that there was some attempt at malicious collusion, the Notary Node operators involved would immediately be identified and blacklisted. But any attempt at malicious collusion would almost certainly not produce financial gain, so it’s highly unlikely any Notary Node operators would even try it in the first place.
The other point is that even collusion itself is unlikely because the dishonest Notary Node operators would have no reason to trust one another. We can call this the “Honor Among Thieves” dilemma. In the extremely unlikely event of a double spend attack, the double spend would be for some specific address, i.e. controlled by one (and only one) of the renegade notaries. What assurances do the other colluding notaries have that this renegade notary will share the proceeds? The risk is very high that they will ruin their reputation and get absolutely nothing for it, thus reducing the incentive to collude even further.
Lastly, it’s worth emphasizing that it’s easier to just 51% attack chains without dPoW. For Notary Nodes to decide to attack a dPoW-protected chain is uneconomical on so many levels, their slight advantage isn’t enough to make attacking a notarized chain easier than just attacking a chain without dPoW. This is true for everyone, including the Notary Node operators themselves. Basically adding dPoW makes the attacking harder for everyone, even the notaries. If the Notary Node operators were, in fact, malicious, they would just attack some other, non-dPoW protected chain.

Notary Nodes scaling

Another concern raised is that the Notary Nodes, since they hold all a full copy of all dPoW-protected blockchains on their machines, cannot keep up with the issue of scaling as more projects opt for dPoW security. For instance, if there are 100s or 1000s of different Assetchains and 3rd party blockchains adopting dPoW, how can each Notary Node possibly run some many full blockchains at once?

The assumption is that the Notary Nodes will increase the capacity of their Notary Nodes and use different levels of server management ideas to keep their Notary Nodes working as per protocol.

Being one of the current Komodo Notary Node operators, and having a decade of experience in both server administration & management, along with some programming experience, I can attest that each single Notary Node operator has turned out to be a huge asset to the Komodo Platform ecosystem. The new set of 30 Notary Node operators and their teams have come up with all sorts of different methods to manage, setup, and build their own scripts and tools and server infrastructure to manage a heavy load of blockchain management infrastructure.

The concern, as I understand it, has nothing to do with the dPoW consensus rules. There are plenty of resources and mechanisms in server management to make a cluster of nodes and services, which rules a simple application and manages a complex server architecture in their back-end. The notary node dApp inside iguana needs to connect to all those full blockchain running daemon’s port and should be able to communicate the same information to all other rest of the Notary Nodes connected in this peer-to-peer network. How they manage to make this server architecture setup is all a creative process, left to the skills of the node operators who will make their server architecture and infrastructure setup function as optimally as possible.

Alternative Notary Node network for dPoW

The dPoW process is not strictly tied to the Komodo Platform Notary Nodes. For a project to have its chain notarized to a different blockchain, it is not really mandatory to use the official set of Komodo Notary Nodes.

If any Assetchain or 3rd party blockchain project does not trust the official set of Komodo Notary Nodes, for any reason, and they want to have even more governance control over their blockchain’s notarization process, they can setup their own Notary Node network.

In this case, the notarization of their blockchain will only go to the Komodo blockchain. So, they will not need to have a full copy of Bitcoin blockchain, but only the full copy of Komodo blockchain + the full copy of their own blockchain on just their own set of Notary Node.

The copy of the Komodo code will need some modifications, the main change will be adding the set of Notary Nodes pubkey for the designated nodes.

In my view, this will be very practical for corporations that want to have full control on their own infrastructure setup, or some projects who want more control over their notarization process. They can setup their own process of selecting a set of Notary Nodes, and the rest of the notarization process is pretty similar to how it is described for Komodo’ notarization to Bitcoin network.

In fact, there is already an alternative Notary Node network by project KMDLabs. They have also made some custom improvements to more automation and management tools for this independent Notary Node network of their own. For more information on the KMDLabs project, you can visit https://kmdlabs.io/

Conclusion

The dPoW process might look confusing, but once you get the understanding of its internal working, you will find it the best solution against 51% attacks. I still could have tried giving more details, with the help of and explanations from Komodo Platform core developers of the whole process of delayed Proof of Work, but this article is not entirely targeted towards developers. This post is meant to be useful for amixed crowd of technical and everyday tech users. I myself also learned things which were not clear to me before while writing this article. I received a lot of help from James Lee (jl777) and other core developers in the project, like Decker.

I did not think this article would become so long when I first started typing it. But it kept growing since I felt the need to clear many things up. Plus, I couldn’t find much of this information in outer sources, so I just wrote the parts that I think need to be made publicly available.

I hope this article has been helpful for the developers being introduced to Komodo’s delayed Proof of Work security, as well as some skilled technical individuals or teams who wish to be a Notary Node candidate next election. I encourage you all to join the Komodo Discord community and ask more on the process if you need more clarity on this topic. Thanks again for reading.