Some commands abort on invalid command line.

[y]

$ printf "%s\n%s" 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm | bx fetch-balance
libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target
Abort trap: 6

[evoskuil]

There are several invalid command lines that can cause the boost::program_options to throw an exception other than that documented for invalid args. I'll leave this open to track that issue, but the immediate resolution for you is to not pass invalid arguments. Fetch balance must be called once for each address.

https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-balance

[thecodefactory]

@evoskuil Is this actually a bug? There's a big difference between the command supporting a list of addresses vs a single address. Either we recommend that a user script around the single address usage, or we support taking a list of addresses which I see as more of an enhancement.

@y

$ for address in $(echo "1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm"); do echo $address | bx fetch-balance; done
balance
{
    address 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
    received 18446744073709551615
    spent 18446744073709551615
}
balance
{
    address 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
    received 18446744073709551615
    spent 18446744073709551615
}

I stand corrected -- this output indicates another instance (such as #495) of an accounting bug via fetch-balance.

[thecodefactory]

@evoskuil I'm not aware of any store corruption on the mainnet1/mainnet2 servers, but I wonder if this is indicative of the fact that there may be some. I also recall in the past using master/v4 clients against v3 servers and getting odd results like this ... perhaps related?

[evoskuil]

The issue is the uncaught exception, not the fact that the parameter is not supported. I'm not sure what you are saying WRT an accounting bug. There was an older issue in the client that should be resolved in current code.

[thecodefactory]

@evoskuil Ok.

Re: the accounting bug -- I was showing @y how to loop the addresses, but take a look at the output. It does not match other block explorers, but that's what I got using v3 at the moment.

[evoskuil]

Can you confirm that it is a client error in (summarization) or is the history data incorrect? We had such an accounting error but it was fixed. Can you confirm it is a problem in current v3 client code?

[thecodefactory]

@evoskuil Confirmed as mostly working against v3 mainnet1 (history data was previously very incorrect):

$ for address in $(echo "1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm"); do echo $address | bx fetch-balance; done
balance
{
    address 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
    received 5893135964
    spent 5893135964
}
balance
{
    address 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
    received 780971316
    spent 780971316
}

The 2nd address does not contain the correct balance, and it's not clear where it diverges (though I checked the couple latest transactions manually and they appear to be correct).

[evoskuil]

The balance (0) matches BCI, it's the totals that differ, with BX showing 294440255 more satoshis transacted. There are only 1197 transactions to manually compare :).

[evoskuil]

I suspect that BS/BX is more accurate. It is very possible that BCI/others do not index p2pk (legacy) spends. I added this in v3.3 although it applies only above the last checkpoint, since indexing these inputs requires the previous output, which we do not look up when synchronizing under checkpoints. For a system that cannot index p2pk inputs I would expect them to not index the outputs either. This would result in fewer satoshis input and output, but assuming all was spent (inclusive of p2pk) then the balances would match (at zero). If you synchronized with no checkpoints then you would have more data. This is why I asked you to sync on server with checkpoints and one without. You should be able to easily detect this scenario by comparing the results across servers.

[thecodefactory]

Discussion moved to #515 since it's now unrelated to the original issue.