As I wrote in
https://bitcointalk.org/index.php?topic=1605144.msg17800081#msg17800081there is no bitcoin built in way to find out if a txid/vout has been spent or not. To do that you need to index the entire blockchain and mark the txids that have been spent, the ones not marked are still unspent. Of course bitcoin does this for addresses in the wallet, but it doesnt do it for addresses that are not in the wallet. Including watchonly addresses.
So over the last couple of days I wrote a full blockchain indexer that can be used to index any blockchain with standard RPC. for now it is only enabled for KMD via dexexplorer API:
curl --url "
http://127.0.0.1:7778" --data "{\"agent\":\"dex\",\"method\":\"explorer\",\"symbol\":\"KMD\"}"
it will take a while to scan the blockchain the first time, but after that it will initialize in under a minute when iguana is launched.
The following are the API bindings that are now available:
TWO_STRINGS(dex,listunspent2,symbol,address);
TWO_STRINGS_AND_TWO_DOUBLES(dex,listtransactions2,symbol,address,count,skip);
HASH_AND_STRING_AND_INT(dex,gettxin,txid,symbol,vout);
TWO_STRINGS(dex,listspent,symbol,address);
TWO_STRINGS(dex,getbalance,symbol,address);
I made listunspent2 and listtransactions2 so we can get them validated before using them in the main bitcoinrpc path. The above API bindings simply shows the JSON field names needed in the curl request, there are plenty of examples in SuperNET/iguana/tests
With dex explorer initialized, this means that (theoretically) the current balance of any address, the set of utxo, the list of spends, the spent status of any utxo, can all be queried. And it is all RAM based, so should be quite fast. I added a special handling in dex/getbalance for the address of '*', which will return the coin supply. This it does by bruteforce iterating through all the addresses and doing a getbalance on it. Not very efficient, but still it is completing in about 30 seconds.
To my knowledge this is the smallest code size for any explorer, coming in at 600 lines. And you can see the power of SuperNET as when the notary nodes run this, then all basilisk nodes will be able to access all these explorer functions remotely, without needing any blockchain locally.
The timeline is that this needs to be validated, probably will just do a bruteforce compare against a known good reference. Then it is deployed for the notary nodes. Once there, the GUI can rely on basilisk support of this and so the GUI can use this data for transaction listing. Then it needs to be packaged into the installers.
I am also not handling blockchain reorgs yet, it just has a setback of 3 blocks, which should cover the vast majority of small reorgs. For now, if we detect a larger reorg, it might be that we have to recreate the DB/TRANSACTIONS/KMD file
Quite a bit of work to do in order to get the GUI's transaction history sorted, but we do what we must. A nice side effect of this is now there is a publicly available gettxin and listspent support for the coins the notaries are running this for. Maybe someday, gettxin will become a standard RPC in bitcoin?
