< GitHub184>
[bitcoin] theuni opened pull request #8631: Nuke boost::thread and boost::thread_group (master...no-interrupt-threads) https://github.com/bitcoin/bitcoin/pull/8631
< GitHub111>
[bitcoin] JeremyRubin opened pull request #8632: Speed up prevector tests by parallelization (master...faster_prevector_tests) https://github.com/bitcoin/bitcoin/pull/8632
< achow101>
how do i use the cookie based auth
< GitHub112>
[bitcoin] JeremyRubin opened pull request #8633: Ugly hack to print out tests as they are run to mitigate travis timeouts (master...test-driver-hack) https://github.com/bitcoin/bitcoin/pull/8633
< achow101>
how do I force bitcoind to have a cookie even if an rpcpassword and rpcuser are set?
< gmaxwell>
achow101: use rpcauth instead.
< gmaxwell>
strUsage += HelpMessageOpt("-rpcauth=<userpw>", _("Username and hashed password for JSON-RPC connections. The field <userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A canonical python script is included in share/rpcuser. This option can be specified multiple times"));
< achow101>
I don't think that really fits what I am trying to do
< achow101>
the idea is that the user should be able to just start Bitcoin Core with no options (except server=1 I guess) and the software (Armory) would be able to automatically know how to connect to the server without any user input
< achow101>
it seems that cookie auth is best for this since the cookie is automatically generated
< gmaxwell>
thats what the cookie auth is for.
< gmaxwell>
achow101: what I'm telling you is to stop setting rpcuser/rpcpassword, they're depricated and will be removed.
< achow101>
I know. I'm working on that, hence cookie auth
< gmaxwell>
Currently it lodges a complaint in the debug.log.
< gmaxwell>
And rpcauth does not disable cookie auth.
< achow101>
I was primarily trying to figure out a way to not completely wreck backwards compatibility
< jeremyrubin>
gmaxwell: if you have a moment could you look at the build settings for the bench code? Reproducably (by cfields and I) it doesn't run under wine.
< murch>
sipa: I had read part of the discussion on the BIP status updates on the dev list. There was a bit about the gap limit there and I assumed that Bitcoin Core also implements BIP44.
< murch>
Maybe I assumed incorrectly
< sipa>
bitcoin core does not implement bip44
< murch>
sipa: okay, thanks, I'll correct
< murch>
So, it fills up the regular keypool of 100 instead?
< sipa>
yes
< sipa>
the bip32 support is very very basic
< sipa>
it won't automatically recover addresses or anything
< sipa>
it just makes sure that a backup contains enough to not lose money
< murch>
sipa: so to recover money, you could just increase the keypool parameter?
< instagibbs>
murch, or createnewaddress a bunch of times
< murch>
sipa: I didn't get a ticket for Scaling Bitcoin unfortunately. :( I'm now hoping that my proposal will be accepted, otherwise it looks like I might not be able to go. (I'm on the waiting list.)
< GitHub127>
bitcoin/master 887919c Pieter Wuille: Check for compatibility with download in FindNextBlocksToDownload
< GitHub127>
bitcoin/master 84decb5 Wladimir J. van der Laan: Merge #8612: Check for compatibility with download in FindNextBlocksToDownload...
< GitHub53>
[bitcoin] laanwj closed pull request #8612: Check for compatibility with download in FindNextBlocksToDownload (master...fixwitban) https://github.com/bitcoin/bitcoin/pull/8612
< gmaxwell>
needs backport ^
< instagibbs>
who normally takes charge of backports?
< instagibbs>
the original author?
< sipa>
the release manager for the backport
< sipa>
unless the patches are very nontrivial to backport
< gmaxwell>
in that case, the patch just applies.
< warren>
I'm surprised to find that the gitian documentation in the bitcoin repo no longer explains the gitian default qemu-kvm (non-LXC) method of using make-base-vm.