< phantomcircuit>
there's no actual bug but it's kind of annoying
< phantomcircuit>
there's a warding about nLowestTimestamp in importmulti
< phantomcircuit>
potentially being used uninitalized
< sipa>
phantomcircuit: yeah, we should fix that
< jtimon>
I have understood and like some of the commits in the middle, just not enough to give an utACK in any of the PRs (note ven the merged ones yet)
< phantomcircuit>
im kind of confused
< phantomcircuit>
sipa: in 8831 you can see i moved IsKeyType
< phantomcircuit>
but im getting wallet/walletdb.h:45: multiple definition of `IsKeyType(std::string)'
< phantomcircuit>
it's protected by #ifndef BITCOIN_WALLET_WALLETDB_H
< phantomcircuit>
so it shouldn't be doing that
< phantomcircuit>
moving the definition to walletdb.cpp fixes this
< phantomcircuit>
sipa: nvm i see where i went wrong
< phantomcircuit>
derp
< bitcoin-git>
[bitcoin] dcousens opened pull request #9100: tx_valid: re-order inputs to how they are encoded (master...testorder) https://github.com/bitcoin/bitcoin/pull/9100
< phantomcircuit>
uh
< phantomcircuit>
CWalletDB::Recover has a dummyWallet which only prints a line in debug.log if LoadKeyValue fails to parse the key/value pair
< phantomcircuit>
this either should fail the recovery or just be removed
< bitcoin-git>
[bitcoin] pstratem opened pull request #9101: [Wallet] Do not parse ssValue in CWalletDB::Recover (master...2016-11-07-cwalletdb-recover) https://github.com/bitcoin/bitcoin/pull/9101
< MarcoFalke>
Heh, I hope it is a good thing because whenever there is a zombie there is a prob of about 0.0016 that you will step on them :P
< MarcoFalke>
Previously the prob was 1, so at least you knew there is a zombie
<@wumpus>
well the best way of deailng with zombies would be to no create them in the first place, make sure the test framework cleans up the dead properly
< bitcoin-git>
bitcoin/master 1adf82a Jorge Timón: RPC: Give more details when "generate" fails
< bitcoin-git>
bitcoin/master 924de0b MarcoFalke: Merge #9087: RPC: why not give more details when "generate" fails?...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9087: RPC: why not give more details when "generate" fails? (master...0.13-errors-rpc-mining) https://github.com/bitcoin/bitcoin/pull/9087
< gmaxwell>
sipa: so perhaps the mempool saving functionality should be saving the mempoolminfee... as it goes to zero after a restart.
< morcos>
sipa: i also thought mempool saving was going to be optional?
< morcos>
on a separately question, is it fine to leave a bunch of BOOST_TEST_MESSAGE(..) in unit_tests or will they slow them down...
< morcos>
coins_tests are so complicated, might be useful to not have to readd all this debugging information next time they are changed
< BlueMatt>
jtimon: cool, thanks
< jtimon>
wumpus: instagibbs I added the reindex rpc tests to #8994, to test #9102 (well, and #8994 in general), if you think of other rpc tests that would be interesting to duplicate for this or default values for the custom chain (ie maybe consensus.BIP34Height = 0 or whatever ) please let me know
< jtimon>
strangely enough locally walletbackup is failing, but only when I run all of them, not when I run it individually, there must be something I haven't cleanup up properly because travis seems to be happy
< sdaftuar>
jtimon: if you're seeing failures related to block sync failure in sync_blocks(), there's a good chance that
< jtimon>
I'm not really sure what's happening, it's not a very clear error and the fact that walletbackup passes individually makes it more weird, but I will take a look, thanks
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #9108: WIP: Use importmulti timestamp when importing watch only keys (master...watchtime) https://github.com/bitcoin/bitcoin/pull/9108
< gmaxwell>
morcos: it's optional, you can totally kill -9 the process instead of calling stop. :P
< gmaxwell>
(I suppose it would be reasonable to add an option to let people disable it, though I don't know why anyone would set it, except perhaps saving 150 mb of disk space.
< sipa>
morcos: i'm not opposed to making it optional, i just didn't think it was a requirement for the first PR
< sipa>
gmaxwell: i assume you're joking, but there are downsides to killing that may be worse, like not storing the latest blocks' effect to disk
< cfields>
sdaftuar: regarding #9026, did you consider adding fMayBanPeerIfInvalid to CState rather than passing it around? I realize it's merged, just curious after starting to review 9075