Found and fixed a few bugs that was destabilizing the GUI. basically the GUI should reflect the state of the iguanacore, but it was able to get out of sync, so commands to a locked wallet were being sent, and other such things. Now the GUI and iguanacore are synchronized and apparently it is much happier.
We also have gotten the liquidus block explorer to work on top of iguana, though still a few quirks, nice to see system level things working on top of iguanacore. The big test is if MGW can use iguanacore.
So, while I wait for more bugs, I started on the basilisk side, which is the part dealing with having remote nodes doing things on behalf of the local node, but in a way that is transparent to the higher level code, yet to make sure it is secure.
Yes, its not as easy as it sounds...
Anyway, I was deep in the realtime sync space and I had to swap out that code so there was room for the networking code. I write so much code, cant keep it all in my head at once. I decided to strip things down into mutually exclusive feature sets, so there will be special relay nodes that just do the special relay function, full iguana relay nodes would relay coin info to basilisk nodes, notary nodes do just notary functions, etc.
Had to setup 4 servers to act as the special relays and finished stripping out just the relay functions, which turn out to be a couple mailbox functions and three DEX related ones. I had planned to add some mixer at this stage, but for now I will just make a simple layer of indirection on both sides, so two nodes can transact via pubkeys without having any direct IP contact with each other. This is quite useful as it also avoids all the firewall type of issues as we can make sure the relays are accessible to all the other nodes, including each other, so they can create a decentralized but fully interconnect set of special purpose nodes.
It is quite possible same physical nodes will run several different functions, but I want to setup the code so they could be put onto separate nodes.
The level of indirection will cause a slight drop in performance, but with 2 hops distance between any two nodes, it shouldnt be too slow. Yes, I know once we get to 10,000+ nodes we will need to add more layers, but using 64 relay servers and having each node connect to sqrt(64) = 8 relays, if each relay can handle 2000 connections, that is 16,000 end nodes. I think that is plenty for now and each node gets 8 way redundancy, and each packet is sent to 8 neighbor relays, so with one hop we get any packet to all 64 relay servers. Now any node making a request to any relay would be able to get the information and if requesting from sqrt(64) = 8 relays, will get it confirmed 7 times. Maybe this is overkill, but we dont have 64 servers setup yet, for now it is just 4 of my test servers.
end user node -> requests to relays (sqrt N) -> incoming relay processes it and sends to sqrt N neighbors <- end user node requests from sqrt N relays
One way to think of this is to view the relays as squares on a chessboard, which is 8x8. To send a request, you send it to all the squares in a row (doesnt matter which row), now each server (square) sends the packet onto all the squares in the column. Now after one hop all 64 servers have the packet and it is ready for access, so any random access of multiple relays will get the same data, not sure the best pattern to access, maybe just randomly squares are best.
I got this mostly coded, but not quite debugged as I still need to work out the protocol functions the relays do. I have the older functionality which is pretty close, but I like to incrementally improve things whenever it needs to be recoded anyway. The basic idea is to have quick and efficient pubkey based mailboxes and some realtime auction primitives, maybe specialized for trading, but maybe I can make a generalized realtime auction protocol while I am at it.
Oh, a bit on the IP privacy. Since each packet is automatically replicated as long as I make the retrieval process use an indirection, then only the second server would even know what the receiving node requested. The other relays would just know that someone asked the other relay to obtain the data. So I could add an onion routing mechanism to add pretty good privacy when the time comes. As it is the two end user nodes wont have any idea about the other node, even if there isnt this additional indirection step. And for now, this is sufficient as it is much more privacy than any other method of trading.
James