I pushed a new version with various bugfixes and support for a special NOTARY network. As described earlier, I used the iguana addcoin API to create a coin called NOTARY, but I added some special case code for it to handle several special basilisk commands.
Since with a single API call, iguana can spawn a thread that becomes a coin peer for a bitcoin compatible coin, using the same code to spawn the NOTARY network was the easiest way as all the peer management and basilisk support comes with it.
For those not familiar with basilisk, it is a lizard that can literally run on water. It is very lightweight and can zoom across the top of ponds. So, it made sense that the lite node support in the iguana/komodo universe is provided by basilisk.
By just changing a few fields in the addcoin request, it changes whether a full node or a basilisk node is created. Basilisk nodes query the randomly selected iguana full nodes for the publicly available blockchain info. Since all iguana full nodes have not only txindex=1 level dataset, they have a full block explorer dataset, the exact listunspent for any address as of any block is available to all the basilisk nodes. Using that data, the basilisk node can not only know its wallet balance, but can also create rawtransactions.
both are peers in the p2p coin network:
curl --url "
http://127.0.0.1:7776" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":1,\"VALIDATE\":1,\"portp2p\":7775,\"rpc\":0}"
vs.
curl --url "
http://127.0.0.1:7778" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":0,\"VALIDATE\":0,\"portp2p\":7775,\"rpc\":0}"
If NOTARY was a normal bitcoin compatible coin, the genesis block and some other fields need to be specified, ie for LTC:
curl --url "
http://127.0.0.1:7778" --data "{\"RELAY\":1,\"VALIDATE\":1,\"prefetchlag\":-1,\"poll\":10,\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"startpend\":68,\"endpend\":68,\"services\":129,\"maxpeers\":256,\"newcoin\":\"LTC\",\"name\":\"Litecoin\",\"hasheaders\":1,\"useaddmultisig\":0,\"netmagic\":\"fbc0b6db\",\"p2p\":9333,\"rpc\":9332,\"pubval\":48,\"p2shval\":5,\"wifval\":176,\"txfee_satoshis\":\"100000\",\"isPoS\":0,\"minoutput\":10000,\"minconfirms\":2,\"genesishash\":\"12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2\",\"genesis\":{\"version\":1,\"timestamp\":1317972665,\"nBits\":\"1e0ffff0\",\"nonce\":2084524493,\"merkle_root\":\"97ddfbbae6be97fd6cdf3e7ca13232a3afff2353e29badfab7f73011edd4ced9\"},\"alertpubkey\":\"040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08
dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9\",\"protover\":70002}"
Anyway, that was a bit of a tangent to explain how easy it is to spawn a new "coin" and with a bit of extra handling, it didnt take long to get a working NOTARY network. The actual notary nodes would be the full iguana nodes and all the others basilisk nodes on the NOTARY p2p network. The standard bitcoin messages are used to create the p2p network, ie version, verack, getaddr, addr, etc. and I have a special SuperNET network message that encapsulates iguana/basilisk commands. Currently only 5 commands are handled by the NOTARY iguana nodes: PIN, OUT, MSG, VOT, but it is very easy to add more as needed.
PIN -> special ping used to rapidly disseminate info to other full notary nodes
OUT -> nodes send messages to pubkey in channels with msgid
MSG -> nodes check messages using channels, msgid and pubkey
VOT -> handler for realtime voting, still in progress
The OUT/MSG pair are the low level method that can be used by any higher level protocol to establish pubkey <-> pubkey comms. all messages have a srchash and desthash, either can be all 0. So a send to desthash 0 is a broadcast, if srchash is 0, then it is without return address. In order to manage the traffic flow a 32bit channel is specified along with msgid. This allows an efficient way for any two nodes to establish a link with each other, without ever needing any direct IP contact.
The possibilities of what can be created using the simple OUT/MSG commands is nearly unlimited. Its initial use case will be for the DEX and while the initial version is divulging the IP address of the node to the notary nodes, it will be possible to add a layer of onion routing or even DCnet to add IP level privacy to the notary nodes. For now, this is not a high priority as the zcash privacy is unmatched and shielding IP from all but the notary nodes is a very good start.
Since I am so close to getting the full DEX protocol enabled using the NOTARY network, I will work on that next. Having a realworld use case for something is always a good way to get a systems level test. And with the OUT/MSG expected to be used by most all other protocols, it is important to get it fully working. The side benefit is that we will also get a working native (wallet to wallet) DEX for all support bitcoin compatibles. I will post more details after the basics are working
I have most of the voting protocol worked out, but it needs to percolate a bit more before I am ready to code up all the client side code.
I have also been fixing various iguana sync and RPC issues that come up as the first priority, so that is why the other parts sometimes make little progress on some days.
