03:03 < bitcoin-git> [bitcoin] AkioNak opened pull request #15233: Prevent mutex lock fail even if --enable-debug (master...fix_mutex_lock_fail) https://github.com/bitcoin/bitcoin/pull/15233

05:55 < jonasschnelli> <achow101>jonasschnelli: should a wallet with disabled private keys be able to import a private key?

05:56 < jonasschnelli> no

05:56 < jonasschnelli> The idea is that you have a sane option where you can be 100% sure its watch only

05:56 < jonasschnelli> Ideal for combination with cold storage

05:57 < jonasschnelli> You can use fundrawtransaction and can not shoot in your own foot with – as example – create a new change address because you wrote "changeaddress" instead of "changeAddress".

05:58 < gmaxwell> I think they shouldn't be able to import a key.

05:59 < gmaxwell> and if thats a problem we should make more RPCs accept key arguments.

05:59 < gmaxwell> importing a private key in a key disabled wallet should convert the private key to pubkeys and import that, perhaps.

05:59 < bitcoin-git> [bitcoin] jonasschnelli pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/94167e2b5b7b...82cf6813a4ef

05:59 < bitcoin-git> bitcoin/master eb9ef04 Jonas Schnelli: REST: add "blockhashbyheight" call, fetch blockhash by height

05:59 < bitcoin-git> bitcoin/master 579d418 Jonas Schnelli: [QA] add rest tests for /rest/blockhashbyheight/<HEIGHT>.<FORMAT>

05:59 < bitcoin-git> bitcoin/master 42ff30e Jonas Schnelli: [Docs] add short documentation for /rest/blockhashbyheight

06:00 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #14353: REST: add blockhash call, fetch blockhash by height (master...2018/09/rest_blockhash) https://github.com/bitcoin/bitcoin/pull/14353

06:02 < achow101> well it's currently possible to import a privkey to a private keys disabled wallet. it wasn't clear from the pr discussion whether this was intended

06:06 < sipa> i don't think it should convert to pubkey

06:06 < sipa> that could be very unexpected behaviour if someone thought they'd have access to that key

06:06 < sipa> failing sounds reasonable

06:42 < bitcoin-git> [bitcoin] achow101 opened pull request #15235: Do not import private keys to wallets with private keys disabled (master...fix-noprivs-import) https://github.com/bitcoin/bitcoin/pull/15235

08:15 < kallewoof> late, but agree that failing is better than converting to pubkey

08:23 < bitcoin-git> [bitcoin] ken2812221 reopened pull request #14922: [WIP] windows: Set _WIN32_WINNT to 0x0601 (Windows 7) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/14922

09:34 < bitcoin-git> [bitcoin] hebasto opened pull request #15236: scripts and tools: Make --setup command independent (master...20190123-gitian-build-setup) https://github.com/bitcoin/bitcoin/pull/15236

11:18 < provoostenator> MarcoFalke: Drahtbot seems to be a bit out of control on #14053

11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/14053 | Add address-based index (attempt 4?) by marcinja · Pull Request #14053 · bitcoin/bitcoin · GitHub

11:18 < provoostenator> (it's not consolidating)

13:16 < aj> provoostenator: fyi, in #14671 you reference deriveaddress as 14476 when it's actually #14667 (just a cut&paste typo)

13:16 < gribble> https://github.com/bitcoin/bitcoin/issues/14671 | Utility to replace RPC calls that dont need wallet or chain context · Issue #14671 · bitcoin/bitcoin · GitHub

13:16 < gribble> https://github.com/bitcoin/bitcoin/issues/14667 | Add deriveaddresses RPC util method by Sjors · Pull Request #14667 · bitcoin/bitcoin · GitHub

14:50 < provoostenator> aj: fixed, thanks

14:51 < provoostenator> ^ might as well shameless plug my deriveaddress PR, which has a bunch of (out-dated) utACKs and concept ACKs an no actionable objections for to deal with...

14:51 < provoostenator> * for me

16:09 < bitcoin-git> [bitcoin] instagibbs opened pull request #15238: remove some magic mining constants in functional tests (master...magic_miner) https://github.com/bitcoin/bitcoin/pull/15238

18:03 < sipa> sdaftuar, gmaxwell, BlueMatt: those power9 systems you have are little endian, right?

18:14 < sdaftuar> yeah, mine is at least. i think matt said that it could run in either mode?

18:19 < gmaxwell> sipa: They can be run in either, I have one thats LE and one thats BE (though the BE one isn't plugged in ATM)

18:20 < gmaxwell> (also apparently the LE can run BE efficiently in QEMU)

18:41 < cjd> I noticed some recent amd64 processors have a movbe instruction, I wonder if a university student could be persuaded to write an amd64be arch for qemu, just for testing purposes

18:42 < cjd> It seems like it would make an interesting paper

18:46 < sipa> gmaxwell: so it seems that the feerate data doesn't just write a few easily-enumerable constants

18:46 < sipa> so we can't easily drop the float serialization code

18:46 < sipa> ideally the file format is changed to use some fixed precision encoding, but that's a bigger change

18:47 < sipa> so i'm still unclear how BE systems actually serialize floating point values in memory... apart from knowing there aren't really any guarantees

18:48 < gmaxwell> make a test program and I'll run it or get it run?

18:48 < sipa> will do

19:32 < midnightmagic> Or if gmax isn't around I can run such programs as well.

19:34 < sipa> cool, good to know

20:35 < dongcarl> Can someone add https://github.com/bitcoin/bitcoin/pull/14856 to the P2P board?

20:35 < dongcarl> And also remove #11387 from the P2P board?

20:35 < gribble> https://github.com/bitcoin/bitcoin/issues/11387 | net: remove more CConnman globals by theuni · Pull Request #11387 · bitcoin/bitcoin · GitHub

20:36 < sipa> p2p board?

20:37 < dongcarl> https://github.com/bitcoin/bitcoin/projects/4

20:37 < dongcarl> P2P refactor haha

20:55 < bitcoin-git> [bitcoin] hebasto opened pull request #15239: scripts and tools: Move non-linux build source tarballs to "bitcoin-binaries/version" directory (master...20190123-gitian-source-tarballs) https://github.com/bitcoin/bitcoin/pull/15239

21:10 < IzooooOOO> Hello !

21:51 < instagibbs> what's the min assumed version of python3 on functional tests

22:06 < dongcarl> instagibbs: 3.4? https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md

22:06 < instagibbs> d'oh! ok thanks

22:07 < instagibbs> 3.5 has .hex(), sad!

22:07 < dongcarl> instagibbs: I know... RIP

22:10 < dongcarl> Question for people more knowledgeable about depends: in depends/README.md, it says that the way to use the results of calling `make` in depends for bitcoin is to do ./configure --prefix=`pwd`/depends/x86_64-w64-mingw32, but in our gitian descriptor we seem to use it like so: CONFIG_SITE=`pwd`/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/. Is there a difference between the two?

22:10 < dongcarl> Also why `--prefix=/`? Seems very odd to me

22:20 < sipa> paging cfields_ ^

23:19 < ryanofsky> i know specifying --prefix lets bitcoin autoconf find the "config.site" file generated by depends

23:20 < ryanofsky> i didn't know about the CONFIG_SITE variable. it's probably not 100% identical but it seems more direct to use that if it works