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.

daemon, compile it, and start daemon and issue the coin connection API command for to connect it to all the RPC API of cryptocurrency daemons running on local machine/server. This step makes 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.

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:



curl --url #commandcurl --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.

position in the array, that would have resulted in always selecting only the first 13 from the array in the 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.

was 0, it will in this new round be counted as 63, and the position 0 will move to . 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 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.00010000 vouts:

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.

addresses, but if verified they show 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 ).

(transaction fee) to one well-known address (for simplicity, let’s assume ). 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.

you will get a similar transaction like a notarization transaction (except the 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": 1544696732 satinder@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.

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.