Can you please elaborate about Iguana? Specifically
utilizing ramchains that allows gen 1 coins to be run as full nodes, even BTC.
What does this mean?
Week 26: 16 BTCD have been paid to
648 unique BitcoinDark addresses for successfully staking blocks
809403-820173A little bit lower payout this week due to E9 and BTCOR divs not being included in the MMBTCD dividend payment this week, however, those will be added to next weeks div payment so we can look forward to a nice one next week.
Thanks for staking and supporting the BitcoinDark network!
As for our current situation. Obviously, the NXT ordeal took the wind out of everyone's sails for a while, including James. Instead of wasting his time debating trolls in the forums, he has re-doubled his efforts and has been hard at work on Iguana, a BTCD chrome app (
http://wiki.supernet.org/wiki/Iguana), utilizing ramchains that allows gen 1 coins to be run as full nodes, even BTC. Iguana is not a new project folks, but is needed for other components to function, Pangea, PAX (Pegged Assets), InstantDex (without NXT dependency), etc.
Things are moving forward and I do not doubt James's resolve to bring this project to completion.
Development Update from JamesPeer management is 90% complete.
Raw block management is 90% complete.
Ramchains is 70% complete.
Transactions and balances are not yet, but that is all code already written and will port quickly, so call it 50% complete.
Multicoin support is complete, but untested.
Once the account balances/tx support is done, then I will be able to port the pangea/instantdex/peggy into the iguana codebase, and it can then do realmoney transactions direct to each coin network.
The API would be the SuperNET API JSON that can be submitted via JS postCall or via nanomsg to the port 7777.
I am not decided if I will make iguana7 able to instantdex/pangea without relays. It is a bit more work and will be somewhat slower, but simplifies the architecture a bit. I guess if the relays acted as a cache/booster and made things faster if they are able to, but not required, it is the best of both worlds. So things like bootstrapping a ramchain, could be a matter to download from the relays or to do a full sync via peers.
Yes, this is best, so that is what I will do, but it will add another week's work. Other tasks needed are to integrate each of the three major things into iguana. But still need to get a reliable ramchain restart as that still had some bugs and until that is working, the rest is blocked as cant get to a realtime ramchain from scratch each test.
Qs:
Will iguana be testable before the other major things are integrated?
Could you give a percentage of completion for the other major parts, (idex,pangea,peggy)?
A:
Iguana is currently a totally separate project, so yes it can be tested.
IDEX has been 90% complete for a long time as far as the core goes, my figures are only for the core and not the GUI, etc..
Pangea is 75% done for single table play, but needs real money support. Multitable is less than half done.
PAX (peggy) is 70% done, still needs tx support to be completed.
And those three also need the time to be ported into iguana, that is a separate thing, but about a week each.
In last 4 weeks, I have written from scratch a bitcoin protocol daemon that simultaneously talks to multiple coin networks and got blockhdr syncing and peer management generating a compressed cache of blocks that are read ahead while generating a native ramchain.
Keep in mind that this is catching up to the reference bitcoin client so I dont have all the bells and whistles and at first it wont be a fully validating node for all things, just for the tx that the user cares about.
I even wrote the networking from scratch to minimize system dependencies, so other than crypto libraries there are no external dependencies other than very basic system calls like pthreads, stdio and sockets - which means it will be very lightweight and can run on basically anything.
There is no C++ overhead, no boost, no giant libraries and no Java runtime
The usage of mmap files for all the DB means its ram usage is minimal, but it will utilize the available RAM as a low priority user. So if you have lots of RAM it will be nearly as fast as being fully RAM resident, but even if you have no RAM, it will still run. SSD is recommended for low mem use cases. If you have no RAM and slow HDD, not much I can do to make it be fast.