New Feature: A Dividend API

In order to do the REVS snapshot, I decided to just implement a dividends API for iguana. There are now 2 new API calls “snapshot” and “dividends”. “snapshot” is passed in the symbol of the coin and the height for the snapshot, the height must be a multiple of bundle size and the utxoaddrs.<height> file must already exist in the DB/<symbol> folder. It will if you have been maintaining a coin in RT mode. The snapshot API just returns a complete set of { “address”, <amount> } in an array

The dividends API uses internally the snapshot API. it also specifies symbol and height, but there is also a “vals” object, which specifies how to process the snapshot array:

  • “exclude”:[] is an array of addresses to exclude from the dividends processing
  • “dust”:<float> is the smallest amount of dividend that will be sent,it is not the address balance, but rather the calculated dividend amount. Set “dust”:0 to send dividends for any non-zero value.
  • “dividend”:<float> is the total amount that is allocated across all the non-excluded addresses. Using this value and the total of address balances of non-excluded addresses allows a ratio to be calculated. This ratio is applied to the address balances to calculate the dividend amount for each address. If it is less than or equal to the dust amount, it wont be sent. If “dividend” is 0, then it means to use a 1:1 ratio
  • “prefix” and “suffix” are arbitrary strings that are used to construct the action line: <prefix> <address> <amount> <suffix>. prefix/suffix is just the simplest way I came up with to do the REVS snapshot, I can see a need for a more flexible template for the action line, but I prefer to do such things on an as needed basis.
  • “system”:1 will invoke the action line in a system call

Putting it all together:
curl –url “” –data “{\”agent\”:\”iguana\”,\”method\”:\”dividends\”,\”height\”:1486000,\”symbol\”:\”BTCD\”,\”vals\”:{\”exclude\”:[\”RXL3YXG2ceaB6C5hfJcN4fvmLH2C34knhA\”],\”dust\”:0,\”dividend\”:0,\”system\”:0,\”prefix\”:\”fiat/revs sendtoaddress\”,\”suffix\”:\”\”}}”

The above displays the sendtoaddress lines that would be invoked for the REVS snapshot.

What does this mean?
It means that iguana can now issue dividends in any currency (literally) that can run on your system and base the allocation on any iguana supported coin. With clever use of the prefix/suffix commands, maybe even non-dividend actions can be done based on stake of any iguana supported coin

Bitcointalk Topic Entry

Development History: From a Testnet to Mainnet

In a galaxy a long time ago (September)
komodo testnet was launched
dPow was added, testnet was able to survive
round robin mining was added, testnet exploded, but we were able to repair the damage.
PAX was added, after a furious battle against would be hardfork issues, testnet was able to survive with consensus intact
DEX functionality was then added, without any issues as it is really in a layer above the blockchain itself

Basically I have been able to evolve komodo during these months, adding all the features and avoiding any fatal hardfork that required a blockchain reset. A lot of blockchain resyncs by all the notary operators, but we have over 150,000 blocks in the KMD chain.

So the testnet becomes the mainnet with 99.99% probability at this point.

I believe this makes KMD the longest running zcash protocol coin. And the coins have been issued already but we dont know where to distribute them yet. There are also 44 assetchains that are also running. But since the GUI is only on github and not officially released, it seems that these facts are given little weight.

We are down to the last bugs…

The latest one found by karasugoi was an iguana compatibility error, where an iguana created tx didnt accrue interest. He also found what I think might be one of the last remaining PAX issues, which was doing multiple paxwithdraws in the same block.

This weekend I aim to get a successful DEX swap between two coins using only the basilisk mode, which means two nodes can DEX trade with each other, without even having either blockchain local.

Currently there are three modes for a coin: normal coind, iguana full node, basilisk node that uses notary nodes remotely.

This means there are 9 combinations of DEX trades. I have already gotten several of these combinations tested, but the most demanding is the basilisk <-> basilisk DEX trade, especially due to the potential of being spoofed. I just added spoof prevention and now the basilisk mode is responding virtually instantly.

you can see for yourself using any of the dex* tests scripts in SuperNET/iguana/tests from the repo.

what this means is that for the following coins, you can DEX against any of the others without having any blockchain locally:

[“KMD”, “BTC”, “USD”, “EUR”, “JPY”, “GBP”, “AUD”, “CAD”, “CHF”, “NZD”, “CNY”, “RUB”, “MXN”, “BRL”, “INR”, “HKD”, “TRY”, “ZAR”, “PLN”, “NOK”, “SEK”, “DKK”, “CZK”, “HUF”, “ILS”, “KRW”, “MYR”, “PHP”, “RON”, “SGD”, “THB”, “BGN”, “IDR”, “HRK”, “REVS”, “SUPERNET”, “DEX”, “PANGEA”, “JUMBLR”, “BET”, “CRYPTO”, “HODL”, “SHARK”, “BOTS”, “MGW”]

LP nodes can be configured with a standard bid/ask spread for any trading pair, or it can also be configured to automatically quote prices based on the current central exchange price plus profit margin. Just like komodo doesnt try to replace bitcoin, but uses bitcoin’s security, iguana native coin DEX doesnt try to replace central exchanges, but rather uses their liquidity.

add to the list above, all the coind coins that iguana supports and also add all the coins iguana directly supports. I think pretty much immediately, komodo/iguana native DEX will have one of the widest selection of coins

Bitcointalk Topic Entry 1, 2

Tradebots Update – Predicting the Future Price

Dev branch for iguana now has most of the initial LP node code active. It currently generates realtime raw features in the SVM folder and there is an API command to generate an SVM. The SVM will then make predictions as to the future price direction.

There are currently 8 SVM’s for different timeframes, from 10 minutes to 12 hours in the future. You can configure things to track a large number of trading pairs and it even detects arbitrages that are possible if two or more exchanges are active. See tests/arbinit script.

The realtime predictors are not yet active, but SVM generation is averaging 85%+ accuracy for today’s BTC price action. A very very small sample and as we get more and more different type of days this accuracy will reduce, however the more data there is the more accurate the overall realtime forward predictions will be. It calculates prices for all BTC pairs into USD and CNY. It also monitors the NXT blockchain for the various asset prices and maps them to BTC prices, so things are all setup for automated LP node quotes for all the assetchains, plus any supported BTC trading pair.

it really is quite a lot of new code and some pretty fancy AI level predictor generation as SVM have much better performance than neural networks for large scale datasets.

Update were written to #tradebots on SuperNET Slack.

Last Few Weeks of Development Until Launch

you might have heard about the xmr html GUI having a security flaw that allowed an attacker to do any RPC command if the user went to a site with some special code.

Since iguana GUI is html based, this concerned me and I started investigating. linked up with ca333 who knows a ton about this sort of thing. What I learned was that in html space things are quite dangerous. For the convenience you have a much much much bigger attack surface.

Needless to say we had to improve the security for iguana GUI (if you are using any HTML based GUI it is advisable to make sure it is as secure as required). We finally figured out how to make the iguana html GUI as secure as a QT wallet. It did require some major additions to the baseline, but when security of your money is at stake, then we do what we have to do.

I just released the enhancements needed to the iguana core, so shortly the GUI will be able to utilize it and we can get an html wallet that is both easy to install/use and secure.

Now if your computer is infected with a keylogger or something like that, there isnt much that anything can do, even though with our approach it is somewhat resistant to keylogger. however a keylogger would open a different attack vector which might or might not be prevented based on usage. So, your system must be clean of keyloggers and such malware. In that case even if you browse to an injection attack site you will be protected. Generally speaking, best to not be browing to random sites when using an html wallet. However, if a banner ad leads to a page with injection codes…

The komodod side is in the final stretch. I rebased to the zcash bugfix version that improves performance and fixes some important protected mode bugs.

lots of progress on the assetchains, with over 40 chains now part of the komodo family. just a few more things to validate and I am actually now coding the DEX layer which will be a layer on top of the komodod and iguana core, so it is a nice flexible layer that will be relatively smooth to deploy, ie. just run it as a dapp

I thank everybody for their patience and maturity as we make improvements to the ICO site to accomodate BTCD holders. I know BTC peoples dont really care about such things, but please know that the tech is in the finalization process and this time is needed to get rid of the final showstopper issues.

I would say that a potential security breach via injection websites is pretty important to fix!

Assuming we can get the final two pax functionalities validated, we can mainnet with pax enabled. A fallback release would disable pax for the initial release and we would need to hardfork to enable it. Since the GUI for pax is not yet, it might not be a big deal either way. Personally I prefer to get all the hardforks out of the way while it is in “testnet” status.

In the next weeks you will see a lot of campaigning from the notary nodes operators and this shows that komodo is unique with a community responsive set of notary operators, instead of miners that are just silently mining. The proactive notary operators can and will bring in marketing for komodo in addition to helping expand the overall reach of komodo. Few people really understand the full scope of what komodo can do and the notary node operators are most of this few.

Bitcointalk Topic Entry

Decentralized Broadcasting Service Powered By Notary Nodes

I coded up a low level broadcast service utilizing the notary nodes. Still need to debug it, but it shouldn’t take too long. DEX will use this to propagate order-books.

It uses a combination of scaling protocols to create a generalized broadcast, where from any node you can submit a packet and all the other nodes get a copy of it. It is load balanced so as not to overload any single point and with all the notary nodes having decent hardware and bandwidth, the max capacity would be limited only by available bandwidth.

This is pretty cool, but creates a problem because it is so easy to invoke. Namely spam, which must be prevented.

I am planning to use one of the assetchain coins as the currency needed to pay for such broadcasting. Since most all of the SuperNET services will be using this, I think it makes sense to denominate the broadcast fees in SuperNET assetchain coins. With a cost of 0.0001 coins, the cost is minimal, but still enough to prevent spam.

The way things are structured, the payments of the SuperNET assetchain coin would go to the crypto777 account so it is automatically marked as a special tx and the current codebase can add support for this with minimal extra work.

I am still open to feedback on this as I haven’t coded it yet. The downside is that we will probably need some sort of SuperNET faucet to onboard new users, but all the micropayments will be fully automated like I did with the notary nodes. That codebase can be reused for the micropayments.

I had a bit of spare time, I created 10 more assetchains:
./komodod -pubkey=$pubkey -ac_name=SUPERNET -ac_supply=816061
./komodod -pubkey=$pubkey -ac_name=DEX -ac_supply=1000000
./komodod -pubkey=$pubkey -ac_name=PANGEA -ac_supply=1000000
./komodod -pubkey=$pubkey -ac_name=JUMBLR -ac_supply=1000000
./komodod -pubkey=$pubkey -ac_name=BET -ac_supply=1000000
./komodod -pubkey=$pubkey -ac_name=CRYPTO -ac_supply=1000000
./komodod -pubkey=$pubkey -ac_name=HODL -ac_supply=10000000
./komodod -pubkey=$pubkey -ac_name=SHARK -ac_supply=1400
./komodod -pubkey=$pubkey -ac_name=BOTS -ac_supply=10000000
./komodod -pubkey=$pubkey -ac_name=MGW -ac_supply=10000000

These are 1:1 issued to match the corresponding NXT Assets:

SuperNET, InstantDEX, Pangea, NXTprivacy, Privatebet, crypto777, jl777hodl, sharkfund0, NXTcoinsco and MGW

These are all zcash forks with on-demand block generation and dPoW enabled. When we get the MGW setup to use assetchain coins, there will be an automated process to convert between the assetchain coins and the NXT assets using MGW

Bitcointalk Entries: 1, 2

PAX: the First Implementation Of A Decentralized Gateway

I just released a pre-release candidate version of komodod. All of the identified hardfork changes are active, including the assetchains decentralized gateway with pricefeed.

I added anti-tampering to the pricefeed, and extended the notarization data to include approvals for withdraws. Additionally, there are limits on the total amount of each fiat that can be created. For now it is set to 10000 to 40000 fiat units per fiat. This limits the total worst case exposure to the blockchain to a small enough level. with pax2, I will activate methods that allow increasing the total allowed while maintaining the max exposure, but first step is to get the fiat cryptos in active use.

I also use the implied KMD price from BTCD conversion in the paxprice calculation. I know there is a strictly limited amount of BTCD available at below ICO prices, but it is what it is and as long as it is trading, whatever price it calculates to is a least more tangible than random guesses. Of course, with the limited liquidity, we get the silly result that marketcap goes up 10% with each 30BTC, +40% with 90 BTC and 333% gained with 150BTC.

So dont take the implied price as any stable way to calculate marketcap, it is just a very rough estimate subject to limited liquidity

I have submitted a draft of the PAX technical description a while ago, but I didnt describe the details of the decentralized gateway, even in that document as there were some issues I had to solve during the implementation. Now that it is complete, I am able to accurately describe it.

I wont go into all the details about the price feed as I already wrote that in the initial document. For here, just assume that we have a reasonable stream of prices coming into the blockchain. By reasonable, I mean that more than 51% are valid prices.

In order to calculate the KMD fiat price conversion we need to know 3 prices: KMDBTC, BTCUSD, fiatUSD (for USD only 2 prices are needed). I use BTC and USD as reference currencies as they are the de facto reference currencies used in the markets.

For the KMDBTC and BTCUSD prices, a method similar to augur is used to get a deterministic but random majority correlated price for each height. This is then price smoothed over the prior day (with a pseudo-random starting point in a circular buffer). Then the same process is done with the derived fiatKMD price, so in order to game the system, the majority of pricefeed samples need to be controlled, which requires control of a majority of the notary nodes. Due to the four-way geographic split and wide voter base for the notary nodes, we dont expect that it is practical to get majority control of the notaries.

However, as a precaution there is a max limit for each fiat allowed, so in the worst case the damage is limited. Until the dynamic rebalancing of pax2 is active, this will be sufficient to prevent any runaway scenarios.

So we can assume that for each height, we have a deterministic price consensus that is not gameable for all 32 fiats. I believe Komodo is the first to achieve this. But this is just the start of PAX! In order for PAX to work, the pricefeed needs to be converted to blockchain enforced coins. The general concept of how to do this was introduced with the multigateway (MGW) that I did almost 3 years ago, but going from a distributed MGW to a decentralized gateway required some complex steps.

Namely 5 steps.
1) paxdeposit: this is the process of creating new fiat coins dynamically by converting the corresponding amount of KMD into the fiat coin. This is achieved by burning the KMD in an OP_RETURN, which includes the specifics on prices, fiat, etc.

The KMD side is straightforward, the trick is how to convert that OP_RETURN burn into an issue of the fiat coins in the fiat assetchain. Before we can even think about doing this, we need to solve how on earth can many blockchains know the state of the other blockchains!? It is not practical to use the RPC due to performance problems when dealing with dozens of chains.

I ended up having to create a special komodostate file that records each event in a file. This allows all instances to parse the komodostates of all the other chains and thereby reproduce the identical state in all 33 chains. It was a lot harder than it sounds to get it all working stable.

2) Issue: So, given that, the fiat chain can “see” the OP_RETURN burn and when it does, it tracks which ones have been issued. Things happens all out of order, so we also need to know when we are all caught up to realtime states in both chains as we dont want to do any duplicates. It is the miner that actually does the query for any deposits without the matching issue. All the miners on all the nodes see the same pending deposits (we are in consensus after all), so regardless of which node mines the next block, the pending deposit is issued.

The way I issue the fiat coin is to extend the coinbase transaction with extra outputs, along with a summary OP_RETURN. When this is seen (on all nodes for all chains), the deposit is marked as completed so it wont be duplicated.

Now the fiat coins are issued at the appropriate price, once and only once. Note that the same method can be used to create a sidechain, just remove the pricefeed and do it 1:1

Believe it or not, this is the easy side of the decentralized gateway. The reason is that all assetchains have to run komodod, so we can be assured that all nodes running EUR chain has access to the realtime komodod state. However, the reverse is not true. Not all komodod instances will have access to the current (or any) fiat chain instance, since a user can pick and choose which assetchains to run.

This assymmetry creates quite a lot of potential issues. Once approach is to use the segwit method of having two classes of nodes, the updated segwit ones that are able to validate transactions and the other nodes that just need to trust the segwit nodes to validate. With enough nodes running to verify things, it might be acceptable, but we have notary nodes, so I decided to enhance that level of security with a notarization of each withdraw. So there is a withdraw, approval, redeem on the conversion of fiat coin back to KMD.

3) paxwithdraw: nearly identical to the paxdeposit, just done on the fiat chain side to create the OP_RETURN burn of the fiat coins.

4) approval: notary nodes add paxwithdraw details to the notarized data. All nodes that run both komodod and the fiat chain are able to verify that the paxwithdraw details in the notarized data are valid. This means we get the segwit level validation enhanced with notary node consensus on the withdraw data. Now even a node that is only running komodod gets almost as reliable data as actually running all the fiat chains.

5) redeem: all nodes that are mining gets the pending withdraws (using paxpending RPC) so whichever node mines the next block, the redeem is issued properly. Once and only once. All the nodes are able to validate using the approval data or the data directly from the fiat chain.

One final thing which we shouldnt forget is to make sure that prior to 2) issue, that it is notarized. this way fiat coins are issued only after they are notarized in btc chain. On the return side, since we are piggy backing on a notarization, we get the benefit of notary node consensus for the redeem.

Hopefully the above answers all the questions you have had about how on earth can pax possibly work.

Next up is to verify the iguana notary dapp is updated to match the komodod. I think it already is, but need to verify it. iguana notary dapp changes can be made without a hardfork, so it is less priority than komodod changes that would create a hardfork.

The pre-release candidate isnt a release candidate as I am waiting for zcash to release 1.04 so I can rebase to it. That is expected next week, which is good timing as it will likely take a week or so to verify the assetchains.

With fixing any bugs in the above as priority, I will be shifting to porting the DEX to the notary nodes and getting it integrated into komodod so iguana and komodod can cooperatively DEX. This wont be hardfork changes to komodod, so it can happen even after the initial mainnet version is out, but I prefer to get it done prior to it.

I am ready to do REVS snapshot at any moment, but due to popular demand to allow people to participate in the snapshot without any local wallet, we are updating the ICO site to allow for this and this takes time. I am not personally working on it, so please dont ask me its status.

I believe the current PAX is the first implementation of a decentralized gateway, especially one with an external price feed. By using the notary nodes, it becomes possible to do things that otherwise would not be possible to do. Komodo is thus able to continue to be enhanced with what otherwise would require centralized servers, but instead of that, Komodo can use the notaries + decentralized methods.

PAX proves that it can be done, but it is just the first of such a hybrid functionality to be active.

Bitcointalk Topic Entry

Unexpected Difficulty Explosion Drill

Yesterday we dealt with a diff bomb!

It was a self-inflicted one due to a small problem with the mining algo, but that combined with a few missing notary nodes to almost stop the blocks.

Diff peaked at over 10 billion.

The good news is this was a nice fire fighting drill to see how well komodo responds to such an event. No matter how much you prepare, the unexpected will always arrive unexpectedly. So it is good to be able to respond.

And respond we did. I was already a bit nervous about the rapidly rising diff and had made a corrective release, but we needed a much more forceful way to reduce the diff. I also solved how to avoid such a diff explosion (and implosion) in the future and the good news for non-notary miners is that at least 1 block in 64 will be available for normal mining. Additionally any miner that is not online to mine their blocks will lose it to the non-notary miners. Though the notaries can also do non-notary mining.

I am not sure what percentage of notaries will be offline at any given moment, but now there is a specific financial penalty of the lost KMD to provide a direct feedback to incentivize being online 100% of the time.

By having at least 1 block in 65 go to external miners, the diff will be tied to the actual hashrate. It might sound easy to create a dual-diff mechanism that allows notary nodes to mine at easy diff, while still allowing non-notary nodes to mine at normal diff, with a seamless transition between the two.

Its actually quite tricky to avoid all the edge cases and I have had to evolve the algo to arrive at the current solution. Initially it was a literal round-robin where for a given block only one notary was able to mine it at low diff. This was not bad, but it affected the block production whenever a notary node is not online. Also, the lowdiff makes it trivial to find a block and without a delay, we would end up with a really fast block.

There is another issue that needs to be avoided and that is a mining war between notary nodes. While this is not the end of the world, the financial model is affected as the mined KMD is expected to be a significant part of the notary’s revenues and we are wanting to minimize the BTC subsidy needed. If real mining resources are needed on top of everything else, each notary’s financial equation changes, not to mention the reallocation of the precious KMD.

Ideally, we can rely on the notary nodes to not compete as they are a team, but considering the massive controversy over what region some border countries belong to, I would feel better if there was a technical enforcement of the round robin.

Now this timer is what created the diff explosion. I had it set to 45 seconds, figuring that it was close to 60 seconds and at the time it was before the ratification of the 64 notaries, so there was a lot of non-notary blocks, thus minimizing the faster block issue. Granted if all notaries changed their timer to 30 seconds or less for whatever reason, this would have been an issue.

Then the ratification of the 64 notaries got into the blockchain and activated.

At that point the vast majority of blocks came in at 45 seconds to 50 seconds, which triggers a diff increase to slow down the blocks. Of course, the notary exemption doesnt care what the actual diff is, so we ended up in a never ending increase of the diff. Which by itself is not such and issue as if a notary is going to mine a block at low diff, what does it matter? It matters when the designated notary node is not there and it would take 20 million CPUs to mine the next block!

I had enhanced the set of eligible notary nodes for low diff to be the chosen node plus any notary that didnt generate any of the previous 63 blocks. Which worked quite well until we got to where all active notaries had generated a block recently and the current chosen notary was missing.

After I released a few hotfixes, we ended up not able to tell which was the right mainchain as the blocks were so slow and you cant resolve a fork on the block it forks. Anyway, after a notary wide fire drill to update to the hotfix version, we got the blocks coming in regularly again and the diff is down over 1000x and is currently ~3 million. Another day and it should get down to a reasonable mineable level which is required for proper operation of the system.

The current post-82000 height solution to this is as follows:

A) At any given height, any notary that hasnt generated a block in the prior 65 blocks is eligible for low diff.

B) After a block is mined, a minimum of 59 seconds from start of mining is ensured before submitting to the network, with another 0 to 2 seconds randomly added.

I believe these two simple rules achieves all the desired properties, including avoiding a mining war between notary nodes and preventing artificial speeding up of blocks.

There is little to gain from reducing the 59 second delay as after a block is mined, a notary needs to wait for all the others to mine a block and also the one external. So all reducing the time would do is create one fast block. And if many notaries somehow all decide to do this, we have the diff explosion to disincentivize such fiddling. What point to generate blocks a bit faster if it just creates a diff explosion event. Also, it will be easily seen on the blockchain that a specific notary has adjusted the setting, so it is not anything that would go unnoticed.

Blocks will come in like clockwork, literally, as most all the blocks are based on the clock 59 seconds + random(2 seconds) for average of 60 seconds. Currently this is not active, but already it can be seen that blocks are quite regular:

This method is also very resilient from a missing notary condition as it does not matter which notary, just any notary that doesnt have a recent (within 65 blocks) mined block. which means if any such notary is available, a new block arrives. After the initial race as to who wins the intial blocks, we end up in a randomized round robin as at any given block, all notaries have already mined a recent block and have to wait for the single eligible node to mine its block.

And here is where the external (non-notary) mined block comes into play to calibrate the diff to reality. Whenever all notaries are waiting, which would be (1 + inactive notaries) blocks per 65, the block is up for grabs for external miners and ineligible notaries.

It is a good sign that by simplifying things it achieves more. If anybody sees any issues, please post! There might well be a way to improve it more, but at least the current solution guarantees blocks to online notaries, gets us clockwork blocks, calibrates diff to reality and penalizes offline notaries.

My assessment is that Komodo during pre-mainnet has responded to a blockchain event as well or better than most mainnet coins and kudos to all the notary operators!

On the coding side, I am down to a couple of final issues dealing with the fiat chains and once that is done the current mainchain can become the official mainchain. I estimate 95%+ chance that the current “testnet” chain will become the actual mainnet, which means all test coins mined are the real KMD

Bitcointalk Topic Entry

Komodo’s dPoW & fiat redeems are working

above is the first fiat chain redeem. it was triggered by the EUR tx

which redeemed 0.10 EUR via the paxwithdraw function.

it got a bit complicated, but there is essentially a decentralized gateway (generalized MGW) to achieve the bi-directional deposit/redeem across the different blockchains.

It has a lot of similarity to sidechains, but there is no need for waiting 1 day (or 2 days?) for the transactions to confirm. For now I am not waiting for the notarizations so the testing can go faster. Once we verify it is all happy, then I will require notarizations in both directions before the funds are released.

The above EUR redeem was indeed notarized the next block:

And that was echoed in the KMD chain, which on the next notarization to BTC also notarized the EUR redeem transaction.

Basically the dPoW is working as intended, but still we need to continue to verify things.

The todo list is down to a few final items:
1. error check fiat redeem amounts
2. net balance limiter, activate dPoW for all fiats
3. verify: interest payment, ratification, reorgs

non-komodod tasks
4. REVS and non-fiat chains done
5. automate notarization fee payouts
6. automated distribution of test REVS snapshot

Now assetchains are nearing completion, it would be good if there was someone working on a GUI to manage the creation of new chains. I havent yet added all the possible variants as getting the basics working with dPoW was the priority. And nothing better to make clear what all the options that are needed than having a GUI made for it. Plz post in #komodo if you are available to work on such a GUI, it would likely end up being a page in satinder’s iguana GUI.

The main function I see in the GUI is “create chain” and it needs at a minimum a name, pubkeys of notarizers, supply. Once a chain is started, then other nodes can use the generated iguana code to connect to it or run another mining node.

under the hood, what is needed is:
./komodod -ac_name=NAME -ac_supply=1000000

the above starts the chain and other nodes would connect to it via:
./komodod -ac_name=NAME -ac_supply=1000000 -addnode=<ipaddress>

at this point there is a fully working zcash clone called NAME, it deterministically generates a genesis block, port, netmagic and sends the supply coins to the wallet of the creator. Normal transactions can be done along with protected zcash transactions and even the DEX and LP nodes can be used with the NAME coin.

I just updated it so when you spawn a new assetchain, the matched genCOIN file to add it to iguana is automatically created. it even synced the first blocks

If you are able to do GUI and some systems work (ie. automate creation of explorers) contact me. This is a paid task, just not sure how much work it will be so the first step is to get a qualified person to assess the amount of work it is

Bitcointalk entries: 1, 2

We May Have A Mainnet

October 28th, 2016

rebased komodod to the zcash mainnet version
rebuilding now and testing

One of the risk factors was what happens if zcash delayed their mainnet release. That is not an issue anymore as it is already on block 300. Good thing about the “slow start” with tens of thousands of CPU/GPU mining, the first 20,000 blocks could well be mined in a few days.

Another risk factor was whether komodod would be ready within 2 weeks after the end of the ICO. It appears to be almost ready now. We still need to validate 5% APR interest issuance and election ratification, but considering that there is still 3 weeks+ of ICO left, it seems that we can even get some bonus features like PAX and maybe even DEX working before the mainnet.

October 29th, 2016

assetchains testing found some strange BDB incompatibility I fixed assetchains, but not in the way you would expect

instead of battling against strange DB errors invoked by code that isnt mine, I wanted a clear path to a solution. so I decided to merge assetchains into komodod

i also made komodo-cli understand -ac_name=USD

just build komodod and you get assetchains

./komodod -ac_name=NAMEOFCHAIN

that will make a new chain with a bit more than 10 coins
-ac_supply=1000000 will issue 1 million

I am still debugging the paxdeposit -> issuing via decentralized gateway, but it appears to work well enough (I hope) for multiple nodes to sync

The other benefit is that we can now get zcash protection on fiat as each fiat is now also a zcash fork. And anybody can create a zcash fork from the command line.

November 1st, 2016

Now that the assetchains appears to be working somewhat stably, we decided to do a ratify test.

We have had a dozen new testnet nodes that want to be notaries, but until there is a ratify in the blockchain, there is no change in the official list of notaries.

./komodo-cli notaries -> prints the notaries as of any height, but they only change at multiple of 1000 boundary.

It required 14 signatures to approve the 41 candidates:

(link to the referred tx)

and after we got the required ratify done by the 14+ notaries, the above tx was created. Unfortunately due to going from 14 to 41 there wasnt enough to pay for txfee as the same fixed size utxo was used.

So I need to tweak the process to include a bigger utxo and then we will get the ratified list into the blockchain. Since as of last week, I use the data from the blockchain for the official notary list, so once it gets to the blockchain, it should automatically switch to the new list.

While I was waiting for the ratification, I also got iguana to sync the KMD chain, at least with transparent tx.

November 4th, 2016

EUR and USD are explorers for the fiat assetchains

latest komodod appears to work properly with paxdeposit, ie. you can convert KMD into fiat equivalent automatically based on the current pricefeed.

a hardfork that enables 5% APR issuing early next week is released and after several iterations the ratification process is looking much better.

The interest awards are one of the last items remaining that could require a hardfork to the KMD test chain. Assuming we can get it enabled and debugged, what is left is the reverse withdraw of the pax fiat assetchains and consensus on maximum exposure.

I will try to finish the remaining komodod changes required by mid-Nov, along with third party chain dPoW functionality so there wont be distractions when I switch to porting the native DEX to the notary nodes.

At that point, we would be ready to declare the existing KMD test chain as the mainnet and we would have 33 dPoW secured assetchains (32 fiat equivalents and REVS)

Bitcointalk Topic Entries: 1, 234

New ‘Assetchains’ Version With Fiat Assetchains

Released a new version of assetchains. (

Make sure to install parallel to komodo so you end up with:


It was a bit tricky to get the bitcoin codebase to run multiple coins at once, but I managed to get it to autospawn a new coin based on just the name. Various things are configurable from the commandline, but only the ac_name parameter is actually needed:

./assetchaind -ac_name=USD

From that, it autogenerates a genesis deterministically so all nodes end up with the identical genesis, it also generates different network magics and ports. By convention the rpc port I made one more than the p2p port.

SuperNET/iguana/tests/assetchains spawns 32 fiat assetchains.

after args: +USD port.10078 magic.b6117643 timestamp.1475772963 supply.10
after args: +EUR port.14589 magic.08b9c7e4 timestamp.1475772963 supply.10
after args: +GBP port.10973 magic.e0b0f630 timestamp.1475772963 supply.10
after args: +CAD port.13695 magic.d64ed952 timestamp.1475772963 supply.10
after args: +AUD port.13873 magic.fb64da69 timestamp.1475772963 supply.10
after args: +CZK port.14981 magic.efc70f59 timestamp.1475772963 supply.10
after args: +JPY port.13756 magic.e940ad14 timestamp.1475772963 supply.10
after args: +NZD port.13030 magic.77a0819b timestamp.1475772963 supply.10
after args: +RBL port.9084 magic.ee5ccbe4 timestamp.1475772963 supply.10
after args: +HUF port.12005 magic.1abb80ca timestamp.1475772963 supply.10
after args: +CNY port.13326 magic.32d0a944 timestamp.1475772963 supply.10
after args: +ZAR port.12883 magic.316df4fc timestamp.1475772963 supply.10
after args: +NOK port.9206 magic.d0aa7a1e timestamp.1475772963 supply.10
after args: +IDR port.12170 magic.527a1d90 timestamp.1475772963 supply.10
after args: +THB port.13565 magic.f78672db timestamp.1475772963 supply.10
after args: +KRW port.8690 magic.3d0c88a6 timestamp.1475772963 supply.10
after args: +MXN port.14948 magic.a705b45e timestamp.1475772963 supply.10
after args: +RUB port.13039 magic.0c676275 timestamp.1475772963 supply.10
after args: +SEK port.15315 magic.3ebba2b7 timestamp.1475772963 supply.10
after args: +HRK port.14554 magic.2b4b6ab0 timestamp.1475772963 supply.10
after args: +PLN port.15636 magic.9d555328 timestamp.1475772963 supply.10
after args: +USD port.10078 magic.b6117643 timestamp.1475772963 supply.10
after args: +DKK port.11814 magic.b9513acc timestamp.1475772963 supply.10
after args: +BGN port.11251 magic.6103fdfd timestamp.1475772963 supply.10
after args: +INR port.14099 magic.a895f51a timestamp.1475772963 supply.10
after args: +HKD port.12993 magic.20f4de39 timestamp.1475772963 supply.10
after args: +PHP port.12283 magic.0336ab4f timestamp.1475772963 supply.10
after args: +MYR port.8529 magic.aa1fd950 timestamp.1475772963 supply.10
after args: +TRY port.14335 magic.cdce41ec timestamp.1475772963 supply.10
after args: +ILS port.10934 magic.eda4a70e timestamp.1475772963 supply.10
after args: +SGD port.10431 magic.9c32dda4 timestamp.1475772963 supply.10
after args: +CHF port.10520 magic.e9820337 timestamp.1475772963 supply.10
after args: +RON port.11150 magic.b5fcd485 timestamp.1475772963 supply.10

With 32 blockchains, it would be a lot of empty blocks, so I have it setup to only mine new blocks when there are transactions. You might notice that the supply for each chain is set to just 10, which is $10 USD for the USD assetchain. This is just to have some coins to test, but the idea is that KMD paxdeposit command is used to deposit coins into the fiat chain.

And so that is what I have working now. A KMD paxdeposit command is monitored by the fiat chain and when seen, it will create the corresponding amount of USD coins. But wait! you say, what is the corresponding amount of USD coins? The answer is in the paxprice command, which will show the KMD cost for each USD.

So a paxdeposit calculates the KMD required to match USD, this then is seen by the USD chain, which issues the USD. USD can then be transacted like bitcoin and even the DEX will work with it once I add the fiat chains into iguana.

Then the withdraw from the fiat chain will work with a paxwithdraw command that is already implemented in the assetchaind. There is still a bit more work needed to do on the komodod side (ie. monitor assetchains and process the withdraw, but it will keep on the blockchain) but for now I am finalizing assetchain changes

Also of note is that assetchaind already integrates dPoW with a relatively easy 5 step process as described in main.cpp:

// dPoW integration steps:
// 0. make sure komodo is installed parallel to this project so ../../komodo/src/komodo.h is right
// 1. include komodo.h with KOMODO_SOURCE being the string of coin symbol
// 2. add extra test to ContextualCheckBlockHeader()
// else if ( komodo_checkpoint(&notarized_height,nHeight,hash) < 0 )
// return state.DoS(100, error(“%s: forked chain %d older than last notarized (height %d) vs %d”, __func__,nHeight, notarized_height));
// 3. call komodo_connectblock(pindex,*(CBlock *)&block) at the end of ConnectBlock()
// 4. call komodo_disconnect(pindex,*(CBlock *)&block) at the start of DisconnectBlock()
// 5. Make sure notarized tx are being made by notaries running iguana notary dapp. replace the notaries.h and komodo_notary.h list if using your own notary nodes.

A lot of code is shared between komodo and assetchains as a lot of the dPoW process is very similar, just with different source/dest, and the processing of komodostate is also very similar.

Next I need to update the iguana notary dapp to do the dPoW for the assetchains to complete the third party chain support of dPoW. I figured it would be cool to have 32 meaningful fiat chains to have as the first dPoW chains. Also REVS can be spawned using the identical code. Currently I dont wait for N confirmations, just so we can test things faster, but of course it will be changed to wait for the transactions to be notarized. That way, we can transact fiat chains at BTC security level.

Before we can scale PAX usage up beyond testing amounts, I will need to add some portfolio balancing code, but all this can and will be done after iguana DEX is supporting the KMD and fiat chains, as that gets us quite a lot of nice functionality.

To do:
1. add third party chain support to iguana notary dapp
2. rebase to zcash mainchain release
3. verify election ratification
4. activate 5% APR
5. iguana DEX support of KMD (ZEC) and fiat chains
6. komodod paxwithdraw and portfolio balancing

Only 2, 3, and 4 are strictly required for komodo mainchain release, but I would like to get all 6 done to avoid any hardforks soon after mainchain release

Bitcointalk Topic Entry