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.
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.
Words...
Selling 10,000 BTCD at market price: please PM me
You can read all about the ongoing development from here: 
