< phantomcircuit>
sipa, gmaxwell anywhere in particular i should start poking around?
< wumpus>
well the most straightforward place to start is all kinds of parsing/deserialization functions, from json to base58 to consensus deserialization...
< wumpus>
that's why I gave you the univalue example
< most>
hi everyone. i'm currently playing around with the watch-only-feature to archive the balance of adresses. therefore i've used: importadress 1CC6eBM579riyXRVkrBtPtRcmy8C4mpqw2 "test" true
< most>
after successfully rescanning the blockchain, i had look into the balance by using >>getbalance "test" 0 true<< and the balance differs to the one i've actually expected
< most>
as >>listtransactions "test" 1000 0 true<< just show up all the received transactions, but not the send-related ones
< sipa>
most: accounts are virtual bean counters that all share the same wallet coins... they don't have any relation to the blockchain
< sipa>
most: the wallet does not have a way to give you a so-called address balance
< most>
hmm, ok, so i have to get summarize the debits and credits by myself?
< sipa>
it will show you sends and receives by using listtransactions
< sipa>
if you specify an account name to listtransactions, it will only list transactions associated with that account
< wumpus>
listunspent, with filter by address, can give you the unspent outputs, you can sum them up and get an 'address balance'. For whatever that's worth.
< most>
yeah, i saw the sends in listtransactions, but the account-field equals to ""
< most>
whereas in a received transaction the account-field states "test", which was the account i imported the address into
< wumpus>
it usually indicates you're doing something wrong, like reusing addresses
< sipa>
most: that's correct; sends are always associated with "" unless you use the sendfrom command
< sipa>
most: again, accounts have nothing to do with the actual coins
< wumpus>
better forget about using accounts, except as a convenient label for a group of addresses
< most>
yeah, even as the "accounting-feature" is been dropped somewhere in the future
< wumpus>
the account balance feature, apart from being deprecated, is not useful for what you're trying to do
< wumpus>
right
< most>
ok, so i will have a look into listunspend. thank you very much
< sipa>
listunspent only gives you the remaining coins and their value
< sipa>
not any history
< most>
i guess for my purpose it should be fine
< wumpus>
which is enough if you just want to compute the balance
< most>
i'm just looking for current balance of an address
< wumpus>
if you want the history per address you can look at listtranscations, and bucket per receiving address
< most>
no, just the balance is fine. i'm regulary checking the balance. and if drops compared to the last one (which is stored in a db or somewhere else) i'll send a notice
< most>
anyway, thanks for the help
< sipa>
MarcoFalke: i'm not going to rebase until there has been more review, but i'll modify the last commit with your binascii/hex/bytes changes
< GitHub82>
[bitcoin] MarcoFalke closed pull request #7918: [qa] mininode: Use hexlify wrapper from util (master...Mf1604-qaMininodeHexlify) https://github.com/bitcoin/bitcoin/pull/7918
< wumpus>
jonasschnelli: Q: in your lmdb benchmarks, were you using a VM or otherwise a filesystem mounted from a file instead of block device? I'm seeing some very slow behavior, hanging for ages in fdatasync when I benchmark in a VM
< jonasschnelli>
wumpus: No. I was testing on a non-VM system with physical wired SSD.
< wumpus>
ok
< jonasschnelli>
Though I can give it a testrun on a VM on the same system.
< jonasschnelli>
s/can/could
< sipa>
wumpus: was your benchmark on an ssd?
< wumpus>
jonasschnelli: not necessary, just trying to figure out what is different between your and gmaxwell's benchmark
< wumpus>
sipa: I didn't time any full syncs with it
< sipa>
here is a theory: lmdb uses mmap, and we use bulk writes often. this means that the OS can do a better job of scheduling the necessary writes to disk than the single-threaded, linear, synchronous approach used by leveldb
< sipa>
if your latency for disk writes is low, that perhaps means that the benefit from lmdb is smaller
< wumpus>
jonasschnelli: it would be interesting to see if in your case most time is also spent in fdatasync
< sipa>
as on an ssd a random write isnas fast as a linear
< jonasschnelli>
wumpus: how did you measure the time-spent-in-what-function? Did you add some benchmark logs or ran with a time profiler?
< wumpus>
jonasschnelli: no, worse, just break into the debugger when I see it hangin the log
< wumpus>
you can find out the same with a profiler, ofc :)
< jonasschnelli>
hah. Okay. Yes.
< jonasschnelli>
I think we should add a debug=lmbd in your branch.
< jonasschnelli>
Otherwise this will be a myst forever
< wumpus>
sipa: yes that sounds convincing
< jonasschnelli>
sipa: btw: the basic reindex with you new PR took ~24min. (2016-04-20 14:25:30 Reindexing block file blk00000.dat... 2016-04-20 14:49:28 Reindexing finished)
< jonasschnelli>
But then I got "UpdateTips" untill 2016-04-20 19:05:21 (~4h15').
< wumpus>
yes, that's the idea, it splits the reindex into two phases, which in total should be faster than the whole process was before
< sipa>
jonasschnelli: yes, that's expected... how long was a reindex beforehand?
< jonasschnelli>
sipa: not sure. But somewhere around 5h IIRC (need to check the IRC logs).
< * jonasschnelli>
checking logs...
< jonasschnelli>
can find it anymore.
< * jonasschnelli>
checking the log
< sipa>
cfields: any problems getting the flag from travis?
< GitHub6>
[bitcoin] instagibbs opened pull request #7926: [RPC] push back getaddednodeinfo dead value (master...getaddedpushbackmaster) https://github.com/bitcoin/bitcoin/pull/7926
< cfields>
sipa: I never heard back this time. It was going too smoothly...
< gmaxwell>
sdaftuar: I have a patch that removes the feerate, and also takes it out of acceptmempool, but sipa would have killed me if I expanded the scope of that PR any further.
< gmaxwell>
but as soon as that goes in I will PR it.