last i heard nexern was moving skynet to WAVES, Skynet is one of my investments not one of my assets

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

I coded up a low level broadcast service utilizing the notary nodes. Still need to debug it, but it shouldnt take too long. DEX will use this to propagate orderbooks.

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 havent 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 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.

I expect annual elections, unless there are special circumstances that require switching some specific nodes

Until the KMD price is over $1, I think annual elections are sufficient.

Of course, in the event that the price goes up dramatically, then there will need to be more frequent elections.

It is a balance and I am open to suggestions on the best election schedule. It just seems that monthly or even quarterly elections are just too frequent, so it goes to annual

Depending on the market price of KMD, a notary node is either a way to make a bit of money each month in exchange for a bit of time, or a money printing machine.

Based on the randomized round robin, each notary node (at 64) will get approx 2000 KMD per month. At 6 cents, this requires some BTC subsidy to cover the costs of the notary operators. At 25 cents, it is self-sufficient without any need for BTC subsidy. At $1, well it is a nice income in most parts of the world, etc.

So the election dynamics will definitely change as the KMD market price changes. However, KMD enabling people with money to make more money, well that is the golden rule and I dont see anything wrong with that. Especially as in order to protect their investment, they will need to ensure stable servers.

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: http://www.zpool.ca/explorer/1720

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

I am always looking at new technology and how to best utilize it. If SAFE gets established and provides a good value, then I would certainly consider integrating it.

However, it is not any high priority at this point as I want to get the current round of projects completed first

A lot of voting will be somewhat random and spread out across all candidates, so any node that gets a significant stake voting for it will get a very large chance to win.

It is like the swing states votes. A relatively small amount of voting power determines the winner.

I think it is good that a large stakeholder is actively campaigning and I would assume many others would too and so you should get votes from the rest of the voters.

The election site is still in progress. both the BTC and BTCD investors will use the election site to vote and receive the KMD.

specific details on the election site are not available until the election site is completed

the election process will ask you to vote for the notary in each of 4 regions. Once you submit your vote, your KMD will be sent out to the address you specify.

If you read about the lengths just Peter Todd went to for the parameters ceremony, and understand that he and all the others would need to be colluding, you should be able to rest easy.

zcash is working on a way to audit all coins in the aggregate to put such issues to rest, even though i really dont think it is any real issue.

All the swapped BTCD will be held till after the swap period is over. Its disposition at that point will be decided, but whatever happens to it, wont affect KMD in any way. Also the redemption rate will be reduced by 5% APR to compensate for any staking during the next year

Please dont be confused.
The ICO phase was for BTC investors and BTCD peoples didnt have to do anything.
The next phase is for BTCD peoples, BTC investors dont need to do anything.

When the BTCD is into the ICO site, then we can do the elections and distribute the KMD.

We are now waiting for the ICO site to accept BTCD. If you invested with BTC, nothing you need to do.

I see some flaws in your logic...

First off, if others can use KMD chain and get similar benefits, then it seems much more economical to use the KMD chain instead of BTC. It is rather expensive to write to BTC chain.

Most important mistake you are making is thinking that the BTC community needs to agree to accept transactions. Remember bitcoin is permissionless, nobody needs anybody else's permission to send a transaction to the blockchain.

Granted, they could break bitcoin so it is unable to accept transactions at all, then certainly the KMD transactions wont get to the BTC chain as BTC wont exist anymore.

You logic is basically concluding that KMD will force BTC to kill itself.
I disagree

It took while, but we finally got a 64 node ratify done.
also 5% APR is working without any reported issues

I also sped up assetchains by orders of magnitude and komodo now has equivalent to sidechains that it can use if the need arises. But with GUI needed for pax and assetchains, seems little sense to add a sidechains API for now.

What is left to do is restore some functionality I disabled while speed optimizing the assetchains and then all the hardforking changes are done.

Which means we are at 90%+ likelihood that the current testchain is actually the main net and that it has been running longer than any other zero knowledge chain. Cant be 100% sure yet, but the finish line is right around the corner for komodod itself.

After that I will port the DEX over to the notary nodes for the orderbook so we have a highly redundant set of high performance nodes that all the other nodes can get the orderbooks from.

If bitcoin decides to stop accepting transactions, then you are right we cant use it to notarize anymore. However, that means that bitcoin wont be doing transactions anymore and this seems highly improbable.

even in this unlikely event, we can always switch to another chain.

also keep in mind, only KMD has to use the BTC chain, other chains can use KMD and piggyback onto the KMD notarization

I have spent a lot of time to use totally standard transactions:

https://blockchain.info/address/1P3rU1Nk1pmc2BiWC8dEy9bZa1ZbMp5jfg

If these are made illegal, a large number of other transactions will become illegal and I really doubt dPoW represents any danger to BTC, in fact it leverages BTC and helps BTC.

snapshot is external
it just takes a snapshot of the blockchain at the to be specified height

then REVS coins in matching amounts will be sent to each address with a non-dust balance

a specific block height after the end of ICO will be selected. initially we planned it to be right after ICO ends, that is why the recommendation to do it before the ICO ends as they are adjacent in time.

some requests to be able to participate in snapshot without local wallet came in and we try to accomodate by allowing to use the ICO website to deposit BTCD and thus participate in the snapshot.

The snapshot will be automatic.
You will need to importprivkey for your designated redeem address, which is where the REVS will be sent to. The same address is where KMD will be sent to

So, if it have BTCD in a local wallet, you dont need to do anything, each funded address will get the same amount of REVS as of the snapshot height.
If you dont have a local BTCD wallet, then you need to wait for BTCD mode to be enabled.

exact block will be determined when the BTCD redeem site is working so please dont ask for the exact blockheight now

It would be  a hardfork and definitely delay launch to change parameters.

Also generating them is a highly technical process, so even if we have 10 trusted people they might not have the tech skills...

zcash team is planning on adding a total supply audit function next year. That at least allows detection of any foul play and since it is just a low probability event, being able to detect it will put an end to the fudding about it.

That being said, if you want to coordinate finding the trusted 10, then I can encourage that. We just have much higher priority things to do than deal with a fudvector against an infinitesimal probabilty unlikelihood

What you suggest is easier said than done.

Who would these highly trusted people be? Who will recruit them and get them to spend the day that it takes to conduct the parameter generation?

I dont see any issues with how zcash generated the parameters, but if there is a practical way to generate our own then I can consider that.

At this point, this is not any high concern. Next year, when protected supply auditing will be available, there will be proof that parameters arent being abused.

I do not believe that the toxic waste exists as I am confident that more than one of the zcash participants is not colluding with all the others. You do realize that ALL of the participants would need to be colluding for the toxic waste to even exist?

And that if there is any funny business with it, there are only the participants that can be the culprits. And since a lot of the participants are highly vested in ZEC, to game the parameters would just cost more than they could gain, ie. it isnt a smart thing to do