< gmaxwell>
Can someone remind me why we have a setting for turning on and off the standardness of bare multisig? it has no tests but seems kind of pointless to me..
< jnewbery>
< sipa>
< jnewbery>
gmaxwell : can you explain the tsan issue? The new keypool-rescan test checks that bitcoind will exit if the keypool drops below critical. bitcoind will also print to stderr if that happens. Without #10703, any output in stderr results in test failure
< jnewbery>
I'll work on it tomorrow to make it more targeted
< sipa>
jnewbery: tsan prints violations to stderr
< sipa>
i assume it's related to that; i haven't followed the discussion
< luke-jr>
gmaxwell: IIRC last time there was an effort to make it just policy-rejected always, some people didn't agree
< gmaxwell>
jnewbery: tsan and other dynamic analysis instrumention throws errors to stderr, so if we want to continue to use them for testing we can't just have their errors get eaten.
< gmaxwell>
jnewbery: for tests that are supposted to throw errors we sould probably actually test for that, rather than generally ignore stderr. I think.
< wumpus>
gmaxwell: seems to me too that if bitcoind is supposed to print to stderr, it should specifically check for that, instead of a general "succeeded with warnings"
< wumpus>
I also guess if that was the case, it'd need an assertion at *all* callsites of chainactive.tip, in which case why not check in the function itself?
< wumpus>
I don't see the point to randomly peppering around some assertions
< wumpus>
if there's an automated warning I'd like to know why it triggers just there
< bitcoin-git>
bitcoin/master 0be03c7 Brian McMichael: Qt: Use _putenv_s instead of setenv on Windows builds
< bitcoin-git>
bitcoin/master f29d5db Wladimir J. van der Laan: Merge #10899: [test] Qt: Use _putenv_s instead of setenv on Windows builds...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10899: [test] Qt: Use _putenv_s instead of setenv on Windows builds (master...testfix) https://github.com/bitcoin/bitcoin/pull/10899
< bitcoin-git>
bitcoin/master 095b917 Gregory Maxwell: Avoid using sizes on non-fixed-width types to derive protocol constants....
< bitcoin-git>
bitcoin/master 04d395e Wladimir J. van der Laan: Merge #10854: Avoid using sizes on non-fixed-width types to derive protocol constants....
< bitcoin-git>
[bitcoin] laanwj closed pull request #10854: Avoid using sizes on non-fixed-width types to derive protocol constants. (master...rbf-numlimit-fix) https://github.com/bitcoin/bitcoin/pull/10854
< jnewbery>
Redone #10882 with stderr capture/checking done within the individual test. Ready for review. (sipa, gmaxwell)
< luke-jr>
FWIW, master upgraded my testnet3 UTXO set and then crashed syncing due to LevelDB giving $6 = "Corruption: not an sstable (bad magic number)"
< luke-jr>
leveldb LOG file hasn't changed in a month
< luke-jr>
jonasschnelli: btw, I think prune-to might be a good novice contributor thing, so might make sense to let it sit as an issue :p
< luke-jr>
(eg, manual pruning and chainstate obfuscation seemed to work out nicely)
< wumpus>
luke-jr: I mean: bring back the typedef instead of declaring a function type in a function argument
< wumpus>
I dont' understand why the typedef is being removed
< wumpus>
or am I alone in finding "CDBEnv::VerifyResult CDBEnv::Verify(const std::string& strFile, bool (*recoverFunc)(const std::string& strFile))" terribly hard to read?
< sipa>
no.
< wumpus>
and as for not being sure what the state of that PR is, I read the other discussion and people don't seem to agree wheter it's considered an improvement or not
< wumpus>
in which case it'd be better to close it instead of review it further
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #10931: Fix misleading "Method not found" multiwallet errors (master...pr/multierr) https://github.com/bitcoin/bitcoin/pull/10931
< wumpus>
jnewbery: yes, testnode is nice
< * midnightmagic>
stabs
< midnightmagic>
argh, sorry, was behind on scrollback and that had nothing to do with anything current.
< wumpus>
I already wondered who and why you were stabbing :)
< wumpus>
jnewbery: thanks for adding explicit check for stderr, I think this is much cleaner
< luke-jr>
wumpus: ah, got the before/after reversed
< gmaxwell>
wumpus: I'm glad you commented on the alarmist titles.
< gmaxwell>
wumpus: someone should also point out to practicalswift that these titles will confuse further troubleshooting, e.g. someone encounters a real crash, then sees commits with titles like "avoid null dereference" they may think "oh thats been fixed" and not report it.
< gmaxwell>
"Appease static analysis tool by adding an assert in X" is a fine title.
< morcos>
If the next PR literally says "X" in the title, you are responsible
< gmaxwell>
hahah
< jtimon>
can I build bitcoind but only bitcoind without bitcoin-cli, bitcoin-tx, libbitcoinconsensus.la, test/test_bitcoin_fuzzy, bench/bench_bitcoin and test/test_bitcoin ?
< gmaxwell>
make bitcoind
< gmaxwell>
(or make src/bitcoind )
< jtimon>
oops, right, I forgot the src/, thanks
< bitcoin-git>
[bitcoin] laanwj reopened pull request #10301: Check if sys/random.h is required for getentropy. (master...getentropy-rand) https://github.com/bitcoin/bitcoin/pull/10301
< gmaxwell>
Interesting observation from the now-public infomation about the mtgox thefts. Non-HD walletness of MTGOX partially protected it from losses.
< gmaxwell>
They had a wallet.dat stolen in 2011... and the theif was limited to steal coins that landed on the addresses in it and the 100 after it.
< morcos>
Did you mean to say not having a bag of 10,000 keys protected them from losses
< * morcos>
runs for cover
< gmaxwell>
morcos: Yes. (though the keypool size is irrelevant for this now, because they're all determinstically derrived now)
< gmaxwell>
Not using HD protected them, though -- it's pretty remarkable how little it protected them.
< grubles>
the point was they only had access to the keys generated in that copy of the wallet.dat, and none generated afterwards
< kakobrekla>
aha, if only the keypool size would be smaller...
< gmaxwell>
kakobrekla: it no longer has anything to do with the keypool. Use of hdwallets means that there is no more leakage resistance.
< kakobrekla>
sure
< gmaxwell>
There has been a long discussion since 2011 if the 'unstealing' property is meaningfully protective or not. There have been some other examples where leakage resistance was useful, but this would be the largest yet.
< kakobrekla>
so you stance on this is that hd wallets are bad for your health?
< kakobrekla>
your*
< gmaxwell>
No, but there is a tradeoff.
< kakobrekla>
aha
< gmaxwell>
also, I introduced these things fwiw.
< gmaxwell>
personally I think the ideal functionality would be to rotate HD master keys on a timed basis, e.g. once a year, and only switch to a new one after a backup has happened.
< gmaxwell>
though I think patterns like mtgox show that lazy rotation might not have been much more protective than no rotation at all... they still lost most of their coins even with the 100 key keypool.
< phantomcircuit>
gmaxwell, exchange users insist on reusing very old addresses
< phantomcircuit>
even i they're not displayed anywhere on the site
< phantomcircuit>
it's quite a problem actually
< gmaxwell>
phantomcircuit: yea.... I wondered if we should have added an expiration time to bech32 addresses; to make that a bit harder.
< gmaxwell>
but it's such a mess.
< phantomcircuit>
gmaxwell, the easiest is for exchanges to charge a fee that increases overtime or older addresses
< phantomcircuit>
or at least make a big deal out of retiring addresses and then making it annoying to use old ones
< kakobrekla>
i just checked my db, 4.6% of deposits were made to previously used address
< Murch>
apparently BTCe owner was involved at least in laundering Mt.Gox heist loot, or perhaps even the culprit
< Murch>
were you in Tokyo after all?
< sipa>
i'm in tokyo now
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10939: Check that -blocknotify command is non-empty before executing (master...blocknotify-consistentcy) https://github.com/bitcoin/bitcoin/pull/10939