Tech Tuesday Development Update - 2019 Week 4: Cryptocurrency Will, Inheritance & Blockchain Heirs

myloJanuary 22, 2019

Things move fast at Komodo Platform. That’s why the Komodo team has decided to release a weekly briefing to cover all of the progress the Dev Team is making. This series of posts is called the Tech Tuesday Updates.

In case you’ve missed a previous edition and want to catch up, you can find all the previous Tech Tuesday updates here.

Cryptocurrency Will, Inheritance & Blockchain Heirs

The prerequisites for any blockchain built with Komodo’s blockchain tech stack that wants to utilize a digital asset inheritance plan is:

One of the biggest problems with cryptocurrency estates is how to reliably & in a timely process, provide a trustless validation for cryptocurrency wills.

The current development cycle of Komodo's custom consensus framework provides a solution. It is usable for KMD, any token created on the KMD platform & any gateway/anchor coin that can be used on the KMD platform - BTC, LTC, ZEC etc.

Development of this solution has been stubbed out and supervised by komodo lead dev jl777 with the implementation details being carried out by @dimxy (whom parts of the following paragraphs are from). Where it says "1of2" refers to multi-signature address, and only limited to 1of2 during current development cycle.

A special 1of2 CC address is used, that is, one key of two is able to spend funds. This 1of2 address is funded and freely spendable by the funds creator (owner). The owner may add additional funds to the 1of2 address.

Also worth noting is that more keys/addresses can be used for multiple heirs, for now this iteration of development is concentrating on getting the workflow valid.

The heir is only allowed to spend after the specified by funds owner inactivity time has been passed. This means is that if the owner address doesn't spend any funds for some period, then it is time to allow the heir to spend fund from that 1of2 address. After the inactivity time has passed both the heir and owner may freely spend available funds. This is achieved after the first heir spending, a special flag is set depicting that spending is allowed for the heir from now on, whether the owner adds more funds or spends them.

Testing and questions can be asked in the discord #cc-heir or #cc-general channels.

Dynamic Loadable Library as Blockchain Consensus

A new development update to jl777 branch that supports -ac_cclib=<name> allows devs to make changes to a single file cclib.cpp and define a user defined CC that uses dynamic libraries so no need to even recompile komodod.

This enables a separation of a user defined CC from komodod, yet it is part of komodod at runtime.

For now, you need to go into src/cc dir and run ./makecclib to make the src/ file that will be searched for the -ac_cclib=<name>. Some conventions exist in the naming - and for direction on how to build, developers are encouraged to go to discord #cc-general or #cc-lib channels for latest information.

The name specified in -ac_cclib must match the name inside cclib.cpp

There is a CClib_Dispatch function that is called for evalcodes 0x10 to 0x7f (reserved for user defined CC) - enough space from id 16 (0x10) through to 127 (0x7f) for user-defined conditions to augment the blockchain consensus rules with any possible feature that can be considered in a transaction process (e.g. any computation) - something as simple as checking a website is up or as complex as a set of derivatives trades based on a price feed oracle.

cclib.cpp is compiled with same include files as main daemon, so has access to all the functions

CClib_methods[] =


   { (char *)"faucet2_fund", (char *)"amount", 1, 1, 'F' },

   { (char *)"faucet2_get", (char *)"<no args>", 0, 0, 'G' },



./komodo-cli -ac_name=CLIB cclibinfo


 "result": "success",

 "CClib": "faucet2",

 "methods": [


     "funcid": "F",

     "name": "faucet2_fund",

     "help": "amount",

     "params_required": 1,

     "params_max": 1



     "funcid": "G",

     "name": "faucet2_get",

     "help": "<no args>",

     "params_required": 0,

     "params_max": 0




Golang & Rust community libraries continue development

Progress continues on the following community developed libraries for Rust and Go languages.

Rust is only the second ever language that has been added to web browsers in 20 years and Go is a versatile system and full stack language offering speed and multi-platform use.

Other community projects are being worked on in javascript and python. Updates to come in following weeks.

Convert Pubkey to Komodo Address

Throughout the Komodo ecosystem there are times a devops person needs to use a transparent address, sometimes a pubkey for starting a chain and for various utility programs that exist or help with a workflow in any language.

If you haven’t ever looked at the versatility of a Komodo Paper Wallet Generator you will be pleasantly surprised how many coins it supplies addresses for. Much like the Iguana multi-coin wallet that started life as a bitcoin implementation in C and acts as the backend for BarterDEX, Komodo’s blockchain interoperability is part of the development culture.

A simple python script is available for a pubkey to komodo address conversion in the doc handbooks.

Note: The KMDLABS discord channel (#kmdlabs) is dedicated to testing innovations, upgrades, new features and is a great way to get the necessary skills and knowledge for being a competent Notary Node operator.

Interested in GUI dApps development? Discord's #cc_gui channel will be where most of the work will take place in the coming weeks.

Thank you Komodo (& ecosystem) developers, what an exciting week!

To get all the latest updates from Komodo, join the monthly email list. On the first Friday of every month, you'll receive a newsletter with information about all of the most important developments from the previous month. You can also join the Komodo Discord server to chat with other community members and the Komodo team.

Join us as we continue to develop and lead the blockchain industry into the future.