reworked internals for basilisk/history api by using iguana/balance api
and sendtoaddress uses this data. tested finding and using utxo in
completed bundles, and also in the RT bundle. Left to test are
detecting a spend of RT bundle in the RT bundle. also amounts and
txfees are a bit off, but basic sendtoaddress should work in all cases
other than bugs
left to do is to lock utxo after being used so multiple tx per block
can be sent, otherwise the same utxo could be selected and that is
invalid
https://github.com/jl777/SuperNET/issues/59 required retrieving
additional details from transaction info RPC. both getrawtransaction
and get transaction use the same code path and list transactions also
uses the get transaction path, so all paths should now have the
txdetails fields:
"category": "receive",
"amount": 0.50000000,
"confirmations": 24466,
"blockhash":
"00000000000000000517ce625737579f91162c46ad9eaccad0f52ca13715b156",
"blocktime": 1448045745,
"blockindex": 78,
"label": "",
the block index and label fields are currently not supported. Also
since iguana has data for all addresses, not just wallet addresses and
including ‘push’ addresses, the ‘category’ field has additional return
possibilities:
‘isp2sh’ is returned for any ‘p2sh’ address, regardless of whether some
or all of the required privkeys to spend the ‘p2sh’ address are in the
wallet. to determine partial or full signature capability would require
interpreting the script in place, and the returned information would
need to indicate conditional states, i.e. cltv, multisig, if/else, etc.
so this part is a won’t fix
for non-p2sh addresses, if it is in the wallet it will return “receive”
or “send” depending on whether the txid/vout outpoint has been spent or
not. for addresses no in the wallet, it will return “unspent” or
“spent”.
Note that a locked wallet might or might not get as far as calling this
txdetails, but if it did, it would return “unspent”/“spent” even for an
address in the wallet as it has no way to know if it is indeed a wallet
address
using a mutex to serialize all API requests causes unacceptable latency
in some cases. Not serialized can lead to queries into a dataset with
unstable state.
To fix this, all JSON requests are split into coin specific queues
whenever possible and the global queue is only used when the coin can’t
be determined from the JSON request.
Each coin’s main thread calls the iguana_jsonQ to process that coin’s
queue of requests only after all the dataset updates are complete to
assure only valid data is returned. Since any previous large latencies
were when a specific coin was updating its dataset and the dataset
can’t be safely accessed during that time, the delay in processing that
coin’s request doesn’t create any additional latency
this bug fix is in response to @pbca26 report of “iguana_pkhashbalance:
unexpected non-ptr lastpt” which is an error that is most likely caused
by accessing the dataset at the wrong time.