Iguana is BitcoinDark wallet, with multiple coins supported.
#iguana snippet from December 5:
jl777 [1:18 AM]
i had to slow down things a bit, but it looks like it is working much smoother
[1:18]
PARSED.332900 T.53166258 U.145635386+265 S.130373708+749 P.55869173 hwm.386760 longest.386760 | 1916083934.48368859 - 1902511419.68137693 13572514.80231166 [40.77054612] M 16645050.00000000 F -3072535.19768817 | 177.15 minutes 100.00% 99.99% 99.81% avail compR 1.000
[1:18]
and
[1:18]
PARSED.361700 T.72732978 U.206127096+5724 S.185528318+5035 P.81212997 hwm.386738 longest.386774 | 2123151527.35031271 - 2108859012.54800105 14292514.80231166 [39.51483219] M 18085050.00000000 F -3792535.19768817 | 418.12 minutes 14.40% 0.58% 0.57% avail compR 1.000
[1:19]
so on two servers it is getting past where it got stuck, but the total processing time will be around the original 8hours target, even though at max bandwidth it can be downloaded in 30 minutes
[1:19]
established network contact with btcd network and all looks pretty good, except it doesnt have the blockhdrs message in the protocol, so i will have to create that out of the blockhashes
[1:20]
i got the first part of the API handling done and a null json is getting from html into the pnacl code
[1:20]
oh, I also got it so that the ramchains start building within the chrome app
[1:21]
but, got an error 38... which is unimplemented function for syncing the mmap files
[1:21]
so I will need to do some major reworking of the ramchain management to use stdio
[1:22]
i got a basic inbound processing loop, but ran into some issues with getting the second packet
[1:23]
i will probably not be online until Sunday. in the meantime what would be useful is to verify that BTC blockchain is parsed till the end on more than my servers
[1:26]
once I get the inbound networking debugged, that will allow not only doing RPC, but to make generic SuperNET agent comms and even the dedicated pangea networking and also being a full node for bitcoin/btcd, so it is quite important
[1:27]
tl:dr almost done with the slow part of the iguana dev process. once I get an abstraction layer on top of the low level functionality, then the rest is just "normal" code, which has the advantage of not having strange slow down mysteries that takes days to fix
[1:29]
i think by next weekend a ramchain explorer version that supports blocks and txids and standard addresses is possible, though still these strange system level issues can slow things down. one thing that I worry about is the 10GB limit on total files allowed in a chrome app. this is a problem for BTC and would require partitioning iguana in an unnatural way
[1:31]
assuming I can get the ramchain explorer mostly working by next weekend, then the week after that would be for a basic wallet, though that requires HTML to also be ready
[1:32]
with the ramchain design a "wallet" is actually quite simple as you can just have a list of addresses and make a single ramchain request to get the total available
[1:32]
really the most work will be just formatting the json return for the API calls
[1:33]
now is the time to make requests for wallet functions that are desired
jl777 [1:39 AM]
i will support an iguana.conf file so we can do iguana conf just like SuperNET.conf iguana has hard coded support for BTC and BTCD
a "coins":[] array is used to specify the active coins
each coin would have its own json object inside the "coins" array
{"name":"BTC","description":"bitcoin"}
optional fields are: "maxrecvcache" "maxpeers" "initialheight" "services"
the first two are something the end user will want to be able to change, "maxrecvcache" specifies the number of gigabytes that will be used to readahead, maxpeers defines the maxpeers used
initialheight should be the approximate current height, but not really needed for normal use
also services is more an internal dev field, leaving it off is fine
not sure if we need to bother with password protecting the basic ramchain functions
so there are the active coins that are in the "coins":[] array and if to allow specifying which coins, we need to be able to start and stop the syncing of the blockchain
so an {"method":"start","coin":"BTC"} to start BTC sync and a "stop" to stop the sync
now it is also possible to add coins other than BTC/BTCD, but the specific chain parameters needs to be specified with the following fields: "name","description","pubval","scriptval","wipval","netmagic","genesishash","genesisblock","p2p","rpc","hastimestamp"
first three are all fields except last 3 are hexstrings, the last three are numbers for p2p port, rpc port
the byte sizes for pubval, scriptval and wipval is 1
netmagic is 4 bytes
genesishash is 32 bytes and genesisblock is variable
the hexstr will be double these sizes, so to add a coin that is not BTC or BTCD these parameters must be in the coin's json
once we can start the ramchains building then we can support the info API:
"status", "getblock", "gettxid", "getaddress" and whatever others you need to make a blockexplorer display
please ask any questions to clarify I now am generating and reloading ramchains with just an issue past block 250K, but enough works we can get the html certainly working with the data from the early blocks
[1:40]
the latest version does support command line JSON being passed in for the iguana.conf, use backslash to escape the " inside the json. this is totally untested
jl777 [1:50 AM]
PARSED.363500 T.74227637 U.211070171+4669 S.189829851+3701 P.83095838 hwm.386738 longest.386783 | 2138390887.18090487 - 2124053372.37859321 14337514.80231166 [39.44295682] M 18175050.00000000 F -3837535.19768817 | 448.73 minutes 5.30% 0.21% 0.23% avail compR 1.000
[1:50]
within 20k blocks
[1:50]
total 16G
-rw-r--r-- 1 dvb2 dvb2 52M Dec 5 07:48 blocks
-rw-r--r-- 1 dvb2 dvb2 313K Dec 5 07:46 iAddrs
-rw-r--r-- 1 dvb2 dvb2 543M Dec 5 01:19 ledger
-rw-r--r-- 1 dvb2 dvb2 2.2G Dec 5 07:49 pkhashes
-rw-r--r-- 1 dvb2 dvb2 1.8G Dec 5 07:49 pkhashes2
-rw-r--r-- 1 dvb2 dvb2 439M Dec 5 07:49 pkhashes3
-rw-r--r-- 1 dvb2 dvb2 764M Dec 5 07:49 spends
-rw-r--r-- 1 dvb2 dvb2 921M Dec 5 07:49 spends2
-rw-r--r-- 1 dvb2 dvb2 2.9G Dec 5 07:49 txids
-rw-r--r-- 1 dvb2 dvb2 3.7G Dec 5 07:49 unspents
-rw-r--r-- 1 dvb2 dvb2 2.3G Dec 5 07:49 unspents2
[1:54]
total size is 16GB here, so probably around 18GB to get to realtime. that is for fullnode. keeping just the unspents would probably fit in less than 100mb as there are ~17 million utxo and each can be encoded in ~8 bytes, but maybe easier to encode it in uncompressed 16 bytes for 250mb dataset
[1:56]
that requires full iguana nodes to convert the canonical 32bit indexes for the txids, so this will need to wait until a bit later. but since a full node can be made from scratch overnight, maybe there isnt much rush for this, its more for the fully mobile miniguana
infinitechaos [6:23 PM]
joined #iguana by invitation from @noashh
----- Yesterday December 6th, 2015 -----
jl777 [1:34 AM]
as expected i am partway through reworking the main processing loop. Now that I better understand the constraints, I aim to solve the remaining sticky issues for initial ramchain sync so resumes are reliable and also so high end computers can process things much closer to the 30 download time for the the full blockchain. but the biggest issue is the chrome app's 10GB limit and also that it is quite slow with the I/O, so maybe the tradeoff is that the chrome version will rely on full iguanas and become the miniguana
[1:35]
one approach is to have the chrome app be able to do a full sync on its own, but if a local full iguana is there, it would just do the front end and let the full native version do all the backend work. that would allow a single GUI (without any changes) to work for both iguana and miniguana
[1:37]
i forsee a long day today to finish coding the new control flow and get it to not crash with the debugging to complete in a day or two after that. i will skip the partitioning the chrome app into multiple ones to get around the 10GB limit as google says they will revisit this and much prefer to keep the architecture as simple as possible. As it is it is getting to the edge of complicated
