CAmount GetDustThreshold(const CFeeRate &minRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::minRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend:
        // so dust is a txout less than 546 satoshis
        // with default minRelayTxFee.
        size_t nSize = GetSerializeSize(SER_DISK,0)+148u;
        return 3*minRelayTxFee.GetFee(nSize);
    }


It seems if you are too efficient in selecting utxo it will get hit by this restriction. iguana does an iterative bestfit algo to select the utxo to use, so it usually ends up spending rather small amounts for change, if at all possible. However, in this case that ends up getting the tx rejected due to the dust limit. I will try to make a maxvalue utxo selection to get around this

https://blockchain.info/tx/efe39e624d0907455a8bcb30b97a718ff375f7404ec8950d955eed841f84f790

It seems there is a limit of 20 small outputs and many nodes are rejecting the tx due to the many dust level outputs. it might be manually getting these splitfunds tx confirmed could be an ongoing task for notary nodes

The notary nodes will be making a custom transaction that is created by the group of notary nodes. In order to minimize the transaction size (it will be big enough as it is!) it needs to have exact amounts, ie no change from each participating notary node.

To do this, what is needed is a way to split funds into many of the same value outputs. Unfortunately, there is no standard way to do this, so a way to generate custom transactions of this form is needed. It sure is a good thing we have iguana!

In a few hours I created a new iguana API:
THREE_INTS(iguana,splitfunds,satoshis,duplicates,sendflag);

This creates and signs a transaction with the same amount duplicates number of times and optionally broadcasts it to the network.

To use it: curl --url "http://127.0.0.1:7778" --data "{\"coin\":\"BTC\",\"agent\":\"iguana\",\"method\":\"splitfunds\",\"satoshis\":\"1000\",\"sendflag\":0,\"duplicates\":5}"


It just defaults to using the wallet's default address as the destination:
{"result":"0100000002ae6e92f5c04ead73d5cae9f12183dbee776d0b35c7fdd99269e021d3a3fd4c6f00000 0006b483045022100fcbae1e6dc89188086beb9c664d7d7c174d97933a2cfdd4b24d60e26bd6257 0b022068c5f2d882a31c44e431614542a10a4ec92915ea6a92754d9ac9b6611d5741750121020e0 f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223a47c2fffffffffc534b16052 0da5b1a6811d2575fe685a609f1508a97cdb927db9250200c6679b000000006b483045022100f87 6996b471ee53bc303a9d5463e7e9c3aaf5ea173b2c034eb91b5d3a20ea6210220033f79a7d9217b 2d5f18445bda5784858cbe665275a5fbb80a9a41270ddf51390121020e0f6fe6e0fcdcac541eb72 8d6fe538a12adff20412b3c8a7fa892b223a47c2fffffffff06e8030000000000002321020e0f6f e6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223a47c2face803000000000000232 1020e0f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223a47c2face803000000 0000002321020e0f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223a47c2face 8030000000000002321020e0f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223 a47c2face8030000000000002321020e0f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7 fa892b223a47c2fac5e6c0000000000001976a914b7128d2ee837cf03e30a2c0e3e0181f7b9669b b688ac00000000","txid":"32b4940bcdacfcbd676898c985dfc10f7c47ae8a7e27bbd9429d9294ceb07e15","completed":true,"tag":"16872458888818271775"}

And sure enough, it confirmed just fine: https://blockchain.info/tx/32b4940bcdacfcbd676898c985dfc10f7c47ae8a7e27bbd9429d9294ceb07e15

You might notice the spend scripts for the duplicates are the form:
020e0f6fe6e0fcdcac541eb728d6fe538a12adff20412b3c8a7fa892b223a47c2f OP_CHECKSIG

This is an older way to do things, but it has the advantage of not needing the pubkey in the scriptsig when it is spent and it also makes it clear what pubkey can spend the funds. So it saves 21 bytes per input, which will addup.

This API is now working code and it is pushed to https://github.com/jl777/SuperNET
To the trolls, this probably doesnt count for anything as it has no GUI. The fact I was able to do it in a few hours, well I leave it to the ready to decide if it means anything or not

Now we are getting closer to ICO launch, we need to start preparing for election of notary nodes.

If you are interested in running one of the notary nodes and get the ~$500 per month, then you need to start "campaigning" to get the votes of the investors. I am not talking about the normal politics campaign, but this is about running the backbone of dPoW. So what will matter is your experience in running serious servers.

We can also use the testnet KMD as one metric in evaluating a notary node. Clearly if you are mining testnet KMD, you are running a node, which is a prerequisite.

So, post your handle, the geographic region of where your server will be hosted, how much testnet KMD you have mined, relevant experience and whatever other info you feel is helpful for the electorate to know. The vast majority of the 3KMD per block reward is expected to go to the notary nodes and if the market price of the 1/64th share is less than $500/mo, the BTC from ICO will be used to make up the difference.

Before voting begins, we will have a notary node certification results that will also be included on the ballot.

Server specs are a min. of 64GB RAM + 500GB SSD and 100mbps bandwidth

We have arbitrarily segregated the world into 4 regions: North America, Europe, Asia, Southern Hemisphere

I know this is not exact, but it is approx distribution of overall internet usage with some debate over eastern europe as to whether it should be in the Europe region or Asia region. I will let the electorate decide on such distinctions. A single notary node operator can run a max of 1 node per region, for a total of 4. However, each notary node needs to be elected in its region, eg be one of the top 16 vote getters per region.

One of the requirements to running a notary node is to monitor the #notarynode channel in the SuperNET slack. That is where realtime updates and issues will be communicated

If there is someone that can create a simple website for notary node candidates to post their info, I can probable get some sort of bounty for it. ANYBODY can be a notary node candidate, but all notary nodes must be elected with sufficient stakeholder power to win a spot. This is a crucial aspect and one of the reasons for a large ICO, so that we get as broad of an investor base as possible to make obtaining a 51% control as difficult as possible.

While nobody will get rich running even 4 notary nodes, it should be a nice bit of extra income to those that do run it as most of the work is to just make sure the server keeps running and to update to the latest versions.

Thanks!

Yes, we do need to help as we can. When the BTCforks project asked me to help, one of the first issues was how to avoid a replay attack like one that ETC fork enabled. My experience of writing an entire bitcoin protocol from scratch for iguana has educated me in all the arcane details of how bitcoin works.

Some bitcoin devs were saying it wasnt possible to avoid but I immediately saw a way to do it as I had just recently battled against creating properly signed bitcoin transactions:

https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes

Now a lot of weight is given to college degrees, in job interviews. The reason for this is that it is a shorthand for knowing the basics. But given the choice between someone with a degree and no experience versus one with highly relevant experience, most smart companies would hire the one with experience. Better to have someone who we know has solved the real world problems versus one that theoretically will be able to.

https://github.com/jl777/komodo

We need a bit more help to get the blocktimes on testnet down as low as possible. It is running in the "no notary node" mode right now and the best I have seen is ~2 minutes per block. Granted we dont expect to be running KMD in this mode, but it would be nice to verify that we can achieve the 1 minute time if there is any need to run in the "no notary mode" configuration for any extended period of time.

The readme has instructions on how to get it built. If you can build bitcoin and zcash, you will be able to get komodo built.

It is expected that right after genesis and prior to the slate of notary nodes being selected, KMD will be running in the "no notary node" condition as there wont be any officially elected notary nodes. We then hold the election, these results will be posted as a special transaction which then activates the notary nodes. Then things switchover to where the notary nodes are making most of the blocks.

I am eager to find out all the ICO I have done, other than SuperNET ICO.

Did you forget that I did not launch BTCD. That most of the NXT assets are either MGW coin assets, or assets that were given out for free as dividends to those that held SuperNET or NXTventure?

That a few of my assets are simple holding assets, that are there to hold other assets. One of my so-called failed assets "jl777hodl" has only quadrupled in value and currently has 200 siafund, worth over 500 BTC.

You make it sound like i have done dozens of ICO, each for millions of dollars and not delivered anything. Instead of the truth that the SuperNET ICO is the only real ICO that was done and most of its capital is locked up in holdings, so I dont have the right to spend large amount of funds to spend to develop things. I do have access to a few millions of dollars of funds that I havent stolen for all this time, rather I have worked to grow its value with shrewd investments. Compensating for an 80% drop in the value of NXT has not been easy task.

MGW has been developed, completed, delivered and deployed and was the first asset based DEX that finally the rest of the industry is making comparable things to. 2 years later.

I created iguana that uses an append only data structure for storing the blockchain and guess who is planning to do the same thing in a future bitcoin release? Yes, blockstream's bitcoin core group is now saying that using a database is not the way to go and it is better to use an append only dataset, which is what my ramchains has been doing.

It is true that I havent finished all the projects that I said I would finish, like pangea. However that wasnt even my project and when it ran into trouble I agreed to do the core work for it. total amount I raised in the pangea ICO is zero. In fact, I put my money into the pangea project.

I am involved in a lot of projects? Yes. I do help other projects, including but not limited to pure crypto projects as I have even contributed to nanomsg. Also to the zcash project, btcforks, heat, waves, SYS and many others I dont even remember. Do I do an ICO for all of these? Is it somehow a bad thing that I am able to help a broad spectrum of other projects? Usually I do it as a volunteer. Sometimes, I invest in a project and then have an incentive to help it out. Is that a bad thing?

External events created a delay and I had to develop iguana tech from scratch: https://bitco.in/forum/forums/iguana.23/

It has a dedicated section in the bitco.in forum with a lot of posts as to all the tech that I supposedly havent done.

Anyway, if you are going to troll me, maybe you are better off trying to find some sort of sex scandal? It seems you will have a better chance

zcash has a great team and has done an incredible job putting the zksnarks into bitcoin protocol and they will be continually improving the tech at that level. So it is more like an Apple and Intel "competitition". Does Apple compete with Intel?

i wouldnt say it does. Apple uses the intel processors, along with many others. And Intel does make their own computers, so the analogy is pretty close

I think what people get caught up in is the financial aspect, but when dealing with crypto currencies it isnt exactly like a consumer product. The network effect  is one of the most powerful things and the more the zcash protocol is used, the more valuable zcash is. it is not purely a cashflow thing when what your "product"  can be used as money.

Money is worth more when more people use it. Now we can split hairs and say if people are using KMD they are not using ZEC, but if you look at the protocol level, both are using zcash.

Looking at the big picture, think about what the effect on zcash would have been had KMD chosen cryptonote tech to use. I think we are in a stage where the industry standards are still not decided on privacy tech. The protocol that gets selected will allocate massive future valuations to the entities that are at the cutting edge of that protocol.

Using the Intel analogy, if you go back in time, once there was a battle between Intel and Motorola in the very early days of CPU. The "protocol" in this case is the CPU instruction set, little endian vs big endian, opcodes, etc. And Intel ended up with the winning protocol so over the decades, Intel grew massively while Motorola languished. When Apple switched to Intel CPU, that was basically the end of the Motorola CPU as far as any meaningful marketshare.

Mapping this to the crypto space, we are in a similar stage. Other than bitcoin, things are all potential and we dont have the mass market version yet. Without privacy, corporations wont use crypto for anything other than petty cash. Looking forward it will be hard to stop the proliferation of crypto based products, just as it wasnt possible to stop the proliferation of CPU based products. How many products have a CPU inside them now? That is a rough estimate to the number of blockchains we will have in the future.

This is why I am working hard to standardize on as much as possible. The bitcoin hashrate to secure all the blockchains. The zcash protocol for privacy. Atomic cross chain swaps for interop. But all this is "under the hood" tech that the fancy GUI will hide from the end user. In one sense it is invisible, but it is as important as the selection of CPU and protocol stack. There are no governing standards bodies, so the standardization needs to emerge from the adoption.

I hope you can better understand why I dont see komodo as competing with zcash.

With funds available for hiring people, things like that are definitely possible.

With the coming proliferation of blockchains, services that enhance/enable blockchains will become more and more in demand.

While a lot of people associate privacy with black activities, it is the corporations that need privacy most of all. Conducting business on a transparent blockchain is just, well, just silly for any company in a competitive environment.

Also, I am creating the tech so that there is no need for business contracts in order to do business with komodo. Just use komodo. After all, has any bitcoin company had to sign contracts with bitcoin to use bitcoin?

If komodo represents the most cost effective way to secure data via the bitcoin hashrate that also happens to have zcash tech, then wont companies that care about costs just start using it?

With the funded DEX LP nodes providing low spread conversions to and from KMD across a large range of other cryptos, I aim to enable 1% or less round trip costs in and out of KMD. This will allow otherwise transparent crypto holdings to be made private with minimal costs. In my experience, businesses like to get the best value for their money, so that is what I am working to create.

I just submitted the rawdraft for the easyDEX whitepaper, not to be confused with the dPoW whitepaper.

Looks like we will have at least two whitepapers, but dont ask me about the timing

komodo will use the same parameters as zcash. The dPoW is independent from all the zcash zero-knowledge proofs and parameters.

And the final transaction, which is alice claiming the deposit. this is not an expected occurance as the protocol both sides run will have spent the deposit before the CLTV tx can be confirmed, but it is possible for the side making the deposit to disconnect and not reclaim the deposit. In this unlikely case, the payment to the 2of2 multisig is in limbo until the deposit side spends it.


bobdeposit: txid af6521b99f56423bec946186b082f859b84bb0633c801dc416b8719cb386dc4d

 010000000151eb900538fdf46a978a1dd2d02ef86febd8eda959278e36d2fb8afd9207b5ef01000 0006a473044022011c3124d37dbe6fdad78b7994683741cc40f41624a6c48c0e660972dcc897af2 022035e896697cc50141d1af08806d680c21fc2e393b1dcfd23bfefc60abe312ad4e012103b7621 b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828ffffffff01b15c000000 00000017a914f8b3f11ae2a8910398e3979e755288774a635b19878dceec57



Alice claim of deposit: 6f4cfda3d321e06992d9fdc7350b6d77eedb8321f1e9cad573ad4ec0f5926eae

 01000000014ddc86b39c71b816c41d803c63b04bb859f882b0866194ec3b42569fb92165af00000 000b34830450221009411c26dcc047cd3e48511f75cbb385ceca1c2ace8c3b41d8c82fdb00ddbec 75022035fd1bd36b7974214783a0960632f8001dcf2d252fa89ab49ff108f300c4a5c801514c676 3048dceec57b1752102744c1dff0591d173b5d074c7e55084a1a03153c8cecfca0ed0fbc6979827 ec34ac67a9145cff11112071bc2f42a4d8b5017e1c7c2509c03c88210327b7810676e8ef2c5971b b5c2e5dfc13a2b32100c40f088c418b14dd069bafc8ac680000000001a1350000000000001976a9 14b7128d2ee837cf03e30a2c0e3e0181f7b9669bb688ac8eceec57

Now all the transactions that are required to protect both sides capital have been automatically created and verified to be properly signed and spendable. Getting all this code to work, especially the custom conditional p2sh signature, has been quite a chore, but finally it is done!

The side effect of long term (one week) testing of the notary pubkey messaging means I have a solid base to build the dPoW messaging on top.

For completeness: https://blockchain.info/tx/cb07398c1b03ef32432220998e18b07dd7fbb4a83d989dc424f43786c5f7d4f2

that is a CLTV spend of a conditional payment, which allows recovering funds in case the other party bails out. And with that, the final transaction type is properly signed and able to be spent, so now onto the more mundane things, like logging, resuming after reconnect, etc.

I have been working on getting atomic cross chain swaps fully working for quite a while. The protocol details are described in:  https://bitcointalk.org/index.php?topic=1364951

With help and inspiration from Tier Nolan, today was the first automated atomic swap including redeems via the following transactions triggered by:

curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"InstantDEX\",\"method\":\"request\",\"vals\":{\"source\":\"BTCD\",\"amount\":0.1,\"dest\":\"BTC\",\"minprice\":0.004}}"

alicefee: https://www.blockexperts.com/btcd/tx/867775f455c22930fa9bc0a48cd41d56fbdf043cd735f3d34a6f8dbdcfed200b

bobfee: https://blockchain.info/tx/b4d1d3eab856547209f950ca36ac5c0f3c6b8791036962200c784b9dcea660be

bobdeposit: https://blockchain.info/tx/f4aa6a34f07cb2bad90aca79f2fc8e51b55c23d78d53e3035f156de1a7faf2a3

alicepayment: https://www.blockexperts.com/btcd/tx/a7e27e540b19a1225796c89de75955279e06600c2cf04462c786d158fdc269c8

bobpayment(*): txid 87b6a1e9896c1da28c1e20f421cdac1ad5233f7925962bee107147ed621a12d2

alicespend of bobpayment(*): txid 69f690d5201e1d7dabf69ea6c1bc810df843bac3a5092738a60d0410d921c9e6

bobspend of alicepayment: https://www.blockexperts.com/btcd/tx/4575c92c93459738543918ecc1871f8c27348b2006354c699401304c08ec816b

bobrefund of bobdeposit: https://blockchain.info/tx/52a3bf49eca2b49346812458ee96b242e643ae2a59080fde4b52e06d110a97df

(*)The bobpayment and alicespend of it was from a different test run

Now there are still the timeout cases to get working, but the hardest part has been to get all the mainstream spends of the custom transactions working. Now it is ready for a GUI to be made for it so end users can submit conversion requests to the LP nodes from the browser.

On the Liquidity Provider side, there is more work to do but the framework is in place for any node to signup to be an LP node with a customizable profit margin for each coin.
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"amlp\"}"
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"liquidity\",\"targetcoin\":\"BTCD\",\"vals\":{\"profit\":0.005}}"

A cool thing is all during this "weekend's" testing of the atomic swaps, I didnt have to reset the notary nodes at all. They ran all the time and properly handled all the comms.

SuperNET has a significant position in BTCD, so there is a direct benefit.

Additionally, komodo is part of the overall SuperNET tech solution, so having that in place has the benefit of providing a strong base for the other SuperNET services

Since komodo is part of SuperNET, what is good for komodo is good for SuperNET.

When I used a lot of words, I was criticized for it, so I figured I would just post the txids created automatically by the iguana DEX process.

Words dont create txids, only working code does so it is my way to show that there is plenty of working code already.

I still have some issues I am working on with the robustness of the atomic swap state machine and the reclaiming of funds in the custom timelocked transactions, but the primary txcreation is automatic following a few API calls on the two test nodes. After connecting to the testnet notary nodes (8 of them) the following calls are done:

LP node:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"amlp\"}"
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"liquidity\",\"targetcoin\":\"BTCD\",\"vals\":{\"profit\":0.005}}"

Now the LP node is operating as a liquidity provider and it is making a market in BTCD <-> BTC swaps at a 0.5% profit margin. Any number of coins can be active on a specific LP node, but enough funds needs to be available for each supported coin.

Once this is setup, any end user node can do:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"InstantDEX\",\"method\":\"request\",\"vals\":{\"source\":\"BTCD\",\"amount\":0.1,\"dest\":\"BTC\",\"minprice\":0.004}}"

The above starts a realtime auction among all the BTCD LP nodes and the best price is selected. For the test there is only one LP node, so the minprice is set to make sure at least .004 BTC is obtained.

After the above, the atomic swap DEX statemachine is started on both sides and the 5 transactions were sent back and forth to effect the swap.

Words... indeed

bobfee: https://blockchain.info/tx/c744797a702f05f5af5bfead20f7539dacfd8d705337d027317bc7aefe514877

alicefee: http://explorebtcd.info/tx/f087dbfb61c1c1766e5e55239f3e3a456b9995694b25ecf245f5eeb49f090e98

bobdeposit: https://blockchain.info/tx/aae38c9e59edafda7823f2df5890195ae162491b627a483c09b2e5f77ff51c73

alicepayment: http://explorebtcd.info/tx/82ee2816ba4f7cd69bafeab5b218a1d41e23296f5738e9e9e7ddc71a60c1964a

bobpayment: https://blockchain.info/tx/e0fa2778d16b204b413611f2e96a2643168ecf3316e8d694cfff4dce7ce52506

It is not as big of an issue as it is made out to be. But since it appears to be the only possible weakness of zcash, a lot of noise is being made about it.

https://z.cash/blog/snark-parameters.html
http://diyhpl.us/~bryan/papers2/bitcoin/snarks/Secure%20sampling%20of%20public%20parameters%20for%20succinct%20zero%20knowledge%20proofs.pdf

The reality is that all of the people involved in creating the parameters have to collude with everyone else, ie. a total conspiracy. Knowing the zcash devs a bit, I do not believe this is anything to worry about.

The other theoretical attack against this is that ALL of the people involved in creating the parameters either collude with everyone else or they run compromised hardware/software that allows an attacker to reconstruct the entire dataset.

Now maybe some govt can run a mission impossible type of op to counteract all the countermeasures in place, but even if the parameters are compromised, the privacy wont be. And since the only entities that I can conceive of that can even think about running such an operation can already print all the money they want, they have no incentive to do such a low return project.

pushed changes for the notary mindiff exception

also a command line parameter -notary to be used by notary nodes, but unless it is on a valid notary node the blocks wont be valid

Only the hooks into the C++ code is in place, the actual code to implement what is needed is still in stub form:


So far, only three functions are needed to support the dPoW. Granted it is assumed that all the required functionality will be done by the above functions, so to fully implement it will take quite a few internal functions.

By collecting all the functionality needed into a single place and in the C form I am most comfortable with also has the side effect that lets other coins add dPoW using a very similar method.

Other coins wont have to have notary nodes or submit to the bitcoin blockchain, but I wanted to share as much code for dPoW between komodo and third party coins

Taking a short break from debugging. multithreaded networking code is always tricky. I did find and fix some deadlocks, but primarily drastically simplified the control flow. Simple is a lot simpler and much less can go wrong as compared to complex logic.

What is working now are several different types of nodes that are all coexisting in the same (super) network.

Each coin of course has its normal p2p network using the bitcoin protocol. Overlaid on top of that are the supernet nodes which use the same ports, but only do supernet comms to other supernet nodes as identified during the version handshake.

For a coin, a node is either a full relay node or a basilisk lite node that queries the full nodes for the blockchain/blockexplorer data. All wallet, tx construction, signing, is done locally as it is the same codebase with some toggles for basilisk mode where it does a basilisk request instead of scanning local ramchain files.

There is a special coin with no blockchain, called NOTARY and the notary nodes would be the full relay nodes and all the others basilisk nodes for this special coin. The NOTARY p2p is now working as a pubkey messaging server and also a way to find all the active notary nodes. I am adding a layer on top of the low level pubkey messaging so a node wont keep retransmitting if the data is already there. That will make the bandwidth usage much more efficient and allow a lot of DEX trading at the same time.

I also got LP nodes to work even as a basilisk node, though it is of course faster if it is a full iguana node. Still, not having to have a full bitcoin node locally is quite handy. And with the NOTARY pubkey messaging in between, there is no direct IP level interaction between the two parties doing the atomic swap.

In order to minimize the changes needed to be made to the zcash baseline and support dPoW, having a min-diff exception for notary node blocks but still using the same PoW seems the path of least resistance. This will make the seamless transition to fully decentralized block creation in the even all the notary nodes go away, or there is some problems in getting a majority of notaries to agree, much much simpler.

With notary nodes having the min-difficulty exception, it would not be feasible for some high hash rate attacker to do 51% attacks. And even if they can anybody that just waits for the bitcoin confirmation would be protected. That is the power of dPoW as even very weak chains become quite secure.

With this plan, the biggest remaining issue is how to get the election results propagated securely. Using komodo chain to record election results has the issue that if all blocks are created by notaries, then the existing majority could block the activation of the new slate. A natural idea is to use the BTC blockchain to record the election results, but again the issue of who writes that data arises.

My idea is to ratify election results via the majority of existing notaries OR a one third majority + special signature. The special signature would be held by the devteam. With this approach, even if there is a majority of notary nodes unwilling to give up their position, it can be overridden by one third minority and the devteam.

This ties into using the zcash PoW as the method for block generation. Even with a min-diff exception, with enough hash rate a block will be able to be mined by non-notary nodes and so the (one third + special sig) transaction will be able to get onto the blockchain in spite of a hostile notary majority.

I realize this is a bit of a change from using a NXT-style PoS, but the current testnet is working smoothly and I dont see the need to add a lot of complicated balance tracking that using a NXT-style PoS would require. Also, using a peercoin uxto based PoS has the problem that only one utxo per block is able to collect the staking revenues.

The other requirement is for people to be able to get 5% per year, without having to run their own node. at first I was going to rely on the notary nodes to do the staking, but I think an even more efficient way is to award all accrued interest whenever a utxo is spent. This approach might even allow interests to be earned by the protected funds, though in order to prevent abuse, the lower spectrum of the average age would need to be used. Still investigating this, but I am hopeful that something like this will work and it wont consume any measurable resources as it would only require to boost the satoshi total from the inputs based on a deterministic algo. I guess that could be one approach for the protected funds interest rates, the notaries can vote for the current applicable rate.

So you can see that while some details are changing from the original conception, the overall requirements and goals are held intact. By minimizing the changes, reliability is increased.