SuperNET Weekly No. 8

CORE and CORE Media were birthed out of the community which formed around the SuperNET project launched by jl777 in 2014. Now that many aspects of the project are finally coming together in fantastic form and usable products are just around the bend, we couldn’t be more pleased to help spread the word and keep our audience up to date on the latest happenings with this revolutionary project and its technology. Welcome to SuperNET Weekly!


An element of SuperNET that has remained in the shadows until now is information regarding it’s NAV (Net Asset Value). In the case of SuperNET, NAV is the total value of crypto currency coins and digital assets that SuperNET owns. While it hasn’t been something deliberately hidden by the SuperNET devs, this is the first time the information is now in an easy to access format.

Here is a picture of six cryptocurrency coins backing SuperNET. SuperNET stakes all six and uses those funds to pay developers.


Also, just below that on the website we have the NXT assets that SuperNET holds and the value behind those assets.


Mx asks “What features won`t be accessible in “Iguana” lite app, the one without the need of blockchain download above ramchains (assuming 10GB limit is still there)”.

“You wont be able to verify locally the blockchain. Maybe there will be other limitations but I want to make it so we can get a node up and running as quickly as possible as a lite node. Then in the background it can download optimized datasets. Then it can do the verification incrementally over time, but normal operations would be able to be done before this.

The chrome app is having some issues with the storage, so I decided to finish up the native version first. I have some ideas on how to exceed the 10GB limit which also would solve the issues with the storage. But that is a miniproject off on a tangent. Having balances match up to the satoshi for the MGW address, which has been quite active was very good news. The fact that the balance hashes are always matching was a good sign, but to verify that balance calcs are precise is of course the critical thing. Also, the balance as of any height is available, something I don’t think even block explorers have. But I want to run BTC with BTCD on my ancient laptop! That was one of the key requirements.” – JL777

Pondsea asks “James what needs to be tested currently?”

RPC calls. You need to do a full sync, either BTC or BTCD and then all the above RPC should be functional to some degree. The question is how complete they are. I got the realtime bootup on the 1Ghz/4GB RAM laptop to 15 minutes. Not the result I was hoping for, but the laptop simply cant move data around very fast at all. There is a lot of data. On desktops, it takes about a minute, so seems fast enough. I am now working on signing the raw transactions and once that works there are all the accounts based RPC to debug. They are mostly coded but I need to select a permanent storage mechanism. At that point the final RPC needed for sending funds will be able to be done.

I estimate that by next Tuesday iguanacore will be able to parallel sync, calculate proper balances and send funds and will go into pure debug mode, ie waiting for bugs to be found with RPC. I am pretty fast at fixing bugs, so my guess is that testing becomes the limiting factor. I seem to have destabilized the parallel sync a bit, it takes a few restarts to get it to the finish line, so I will be debugging that for now.” – JL777

Bcdev asks “30ms… You’re talking about a spinning rust disk, right? On SSD you should get < 1ms access times.”

“Should…but I think I have the very low end SSD. Power saving version that is slow, so it is better than normal HDD, but nowhere near 1ms per access. The 4GB RAM is an issue when running dozens of programs at the same time, so it is spending a lot of time swapping to the SSD. Due to the swapping caused by accessing far greater than the 4GB of max RAM, it was taking a lot longer than 30ms. So i need to do a bit of optimizing to get it to do a million spend updates in a couple minutes.” – JL777

Waves and InstantDEX

InstantDEX and Waves will in some way play together. InstantDEX is a peer-to-peer protocol which aims to connect several blockchains, Waves will be one of them. It itself will be a blockchain saving the data for the users in the decentralized network, this is different than InstantDEX which will rely mostly on data from other blockchains (like NXT, BTCD, BTC, Waves, etc). On Waves we cannot access BTC blockchain but via InstantDEX you could access both.” – Tosch

Extra JL777 Notes

“I had to change the format of the bundle files, this means you need to:

rm -rf DB tmp from the SuperNET/iguana directory to get rid of all the old format files. The bug was if you had some peer that was a lot faster than others and it created over 4GB of vindata, just from that peer. There is also the bundle boundary bug for realtime mode, which is fixed for BTCD but with the recent BTC changing to new bundle, it got stuck. That is the only bug I know of with the parallel sync, but I can only test so many different cases. I have synced on over a dozen different nodes, but there are probably a few more bugs left, especially with realtime mode.

I had to slow down the chrome sync as there appear to be a lot of limitations regarding parallel io with pnacl, still it is nearing a full sync in 10 hrs, which is actually faster than the existing typical sync time of a few days.

The iguana balance API can have a height parameter and it will return the balance as of that height. This is something I dont think anything else can do, so to verify it you need to pick an address and manually verify it is correct by adjusting. The balance api uses the same internals as listunspent RPC, but I added a fromheight to all the spends so it is possible to calculate balance as of any height. If you have a full parallel sync in realtime mode, then you can do the balance API with any address as essentially all addresses are being “watched” and you can also get tx data for any tx. Basically it is a super block explorer. Now I just fixed bugs and this is the first time it worked with the test addresses, so it would be nice if people can test against various addresses to make sure it matches the balance of or your existing wallet.

Assuming this level is stable, the next step is the transactions and various other RPC needed for the GUI, but listunspent is basically the hardest (by far) one to get working as that requires all the data to be valid and to be properly processed, double spend detection, etc. Still need to debug relay node networking, but it is already coded and active, so at least it isnt causing the nodes to be blacklisted, but I haven’t verified it can bootstrap a network among itself.”

For more information on SuperNET and the work of jl777 and his team, please refer to previous SuperNET Weekly articles and our monthly CORE Magazine and be sure to follow the progress via SuperNET Slack or the SuperNET website.