SuperNET Weekly No. 11

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!

Iguana Update

Iguanacore’s bitcoin RPC is testing out pretty well and I am porting Instantdex to use it. I got a significant part of litenode support added. By having the fastest and smallest bitcoin implementation, it will allow it to gain many use cases, i will personally make the Instantdex, PangeaPAX and Jumblr. All of these are monetized and the fees will flow through to SuperNET.” – JL777

Say I grab Iguana, run it and start BTC with RELAY:0 and VALIDATE:0.

1) What data is locally created for BTC?

2) How do explorer level calls (ie, getblockhash) work for that node if no DB is present? The other day you described rawtx method which is needed to send money, but I’m not clear about how the request is sent to a relay node.

“1) No data local other than wallet files.

2) Low level block explorer calls wont be supported. Rawtx is automatically routed remotely for sendtoaddress and other send calls. For custom raw tx, rawtx is directly called and automatically routes to a full relay node.

I realized that for a lite node, all it really needs is the account balance and ability to create a valid unsigned tx, so there is the iguana balances and iguana rawtx API for that. Given the balance, the user can see what balance they have to spend and given a cloud that creates rawtx, a node can sign it locally and broadcast it. Not sure what block explorer calls are needed for a lite node, if they need a block explorer they would just go to a website or run a fullnode. If they just want to send/recv crypto, I think rawtx and getbalances does most of what is needed. The existing bitcoin tx message handles checking the status of pending tx.

That is what surprised me. That with 2 remote calls, a fully functional lite client is enabled. Of course I probably will find some loose ends, but so far a lite node is able to do the instantdex atomic swap protocol, at least halfway. After I get it fully working and know exactly what calls are needed and which ones arent, I will disable the ones that cant work in a lite client. The ones that need remote will just automatically make a remote request, so the RPC is unchanged. That is the beauty of this approach. No changes needed to client software as long as the unsupported RPC is not used.

I dont see any security issues at all other than getting garbage data, which is solved by comparing multiple returns. The rawtx can be verified to pay to the requested address and if the inputs are incorrect, it wont lose money, but would be an annoyance level thing. I realized I need a bit more data returned for rawtx to allow successful signing all the time, for now only normal outputs can be signed properly” – JL777

Cassius asks – What kind of network protocol does bitcoin/BTCD use? I’m assuming it’s not Kademlia (yet)?

“I changed to use a method similar to bitcoin, alongside a broadcast to all peers with a hops limit. The latter for best privacy, the former just to get things synced relatively efficiently.” – JL777

Will SuperNET be getting a stake in WAVES?

“SuperNET will be getting a modest stake in Waves. Considering the amount that it will raise, I doubt the share will be in the “large” percentage range.” – JL777

NXT NRS v1.8.3

NXT NRS v1.8.3 containing a number of improvements and bugfixes released. 

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.