< bitcoin-git> [bitcoin] achow101 opened pull request #13289: [Qt] Re-setup args after translator setup to translate help text (master...qt-help-translations) https://github.com/bitcoin/bitcoin/pull/13289
< bitcoin-git> [bitcoin] Empact opened pull request #13291: [moveonly] Extract tor_reply.h from tor_control.cpp (master...tor-reply) https://github.com/bitcoin/bitcoin/pull/13291
< provoostenator> IIRC someone recently suggested that too much of a dbcache is not a good thing. Why would that be? Is that only the case for n < dbcache < max_historical_utxo_size ?
< provoostenator> Reason I ask is because in my benchmarking for #12404 my impression is that luke-jr's 10% pruning approach is faster than my aggresive prune approach. That effect appears more pronounced as I increase dbache. Pruning 10% should lead to more prune events, which in turn would keep dbcache smaller as a side effect.
< gribble> https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
< provoostenator> If that doesn't make any sense at all, then maybe I'm just seeing random noise, so thoughts welcome.
< luke-jr> provoostenator: I imagine the 10% pruning is most of the advantage
< provoostenator> That could well be, which is why I'm testing it, but I'm surprised if it's actively harmful to prune more. That suggests something else is going on.
< luke-jr> yes, I wouldn't expect pruning more to be harmful
< luke-jr> except in terms of wallet syncing perhaps
< luke-jr> or similar
< provoostenator> This one is configured with --disable-wallet.
< bitcoin-git> [bitcoin] jonasschnelli pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/d792e47421fc...6738813bcbb7
< bitcoin-git> bitcoin/master 131d445 John Newbery: scripted-diff: Rename master key to seed...
< bitcoin-git> bitcoin/master c75c351 John Newbery: [refactor] manually change remaining instances of master key to seed.
< bitcoin-git> bitcoin/master 79053a5 John Newbery: [rpc] [wallet] Add 'hdmasterkeyid' alias return values....
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12924: Fix hdmaster-key / seed-key confusion (scripted diff) (master...master_key_to_seed) https://github.com/bitcoin/bitcoin/pull/12924
< provoostenator> (I think that "someone" was eklitzke)
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #13292: Re-add bench_bitcoin to gitian binaries (master...2018/05/bench_gitian) https://github.com/bitcoin/bitcoin/pull/13292
< bitcoin-git> [bitcoin] KaneoHunter opened pull request #13293: Fixed grammar issue. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13293
< bitcoin-git> [bitcoin] fanquake closed pull request #13293: Fixed grammar issue. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13293
< mmgen> question for the devs: to get a complete wallet backup with all historical transactions is it enough to back up wallet.dat, or must the database dir be backed up too?
< luke-jr> mmgen: the recommended way is to use the backupwallet RPC (or GUI equivalent)
< luke-jr> but if you must copy the data manually, you need both
< luke-jr> and from the same instant.. which may not be easy to get reliably
< mmgen> luke-jr: however, backupwallet just makes a copy of wallet.dat, nothing more
< mmgen> luke-jr: it doesn't copy the database directory, as far as I know
< luke-jr> mmgen: it closes the database first, and makes a copy with it closed
< mmgen> luke-jr: so the wallet.dat it produces is a complete backup that contains all the history?
< luke-jr> right
< mmgen> luke-jr: ok, that's what I neede to know. Thanks!
< mmgen> Just something I noticed: I'm running bitcoind with --connect=0, yet I'm getting error messages "Potential stale tip detected, will try using extra outbound peer". Sort of silly, considering the daemon is running offline.
< bitcoin-git> [bitcoin] practicalswift opened pull request #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 (master...openbsd-warnings) https://github.com/bitcoin/bitcoin/pull/13294
< Emzy> Moin
< jamesob> cfields: is there a good place for me to undef HAVE_THREAD_LOCAL based on our findings that it's unsuitable for use on __APPLE__ and (apparently) __WIN32__? Can do it in threadutil.cpp as before, but it seems like there'd be a better place
< bitcoin-git> [bitcoin] practicalswift opened pull request #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3 (master...openbsd-6.3) https://github.com/bitcoin/bitcoin/pull/13295
< Chris_Stewart_5> Does the protocol allow for different hash types for each signature in a multisig script?
< ryanofsky> jamesob, maybe just modify the autoconf test program to check for the behavior you need: https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L712-L729. or you could disable for known bad compiler versions
< jamesob> ryanofsky: I think for the time being we want to undef HAVE_THREAD_LOCAL for certain platforms even after that autoconf check - any idea of the appropriate place to do that?
< jimpo> kallewoof: You around by any chance?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6738813bcbb7...092b36688142
< bitcoin-git> bitcoin/master 4138f42 Ben Woosley: Revert "Merge #12870: make clean removes src/qt/moc_ files"...
< bitcoin-git> bitcoin/master 092b366 MarcoFalke: Merge #13254: Remove improper qt/moc_* cleaning glob from the general Makefile...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13254: Remove improper qt/moc_* cleaning glob from the general Makefile (master...make-clean-qt-moc) https://github.com/bitcoin/bitcoin/pull/13254
< bitcoin-git> [bitcoin] jnewbery opened pull request #13297: [wallet] Fix incorrect comment for DeriveNewSeed. (master...derive_hd_seed_comment) https://github.com/bitcoin/bitcoin/pull/13297
< cfields> jamesob: maybe just exclude those OSs from the configure check?
< cfields> heh yes, what ryanofsky said :)
< cfields> jamesob: do you have a link to the busted mingw results? I'm curious to see the details
< cfields> thanks, looking
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/092b36688142...d82c5d15c504
< bitcoin-git> bitcoin/master be87c6f John Newbery: [wallet] Fix incorrect comment for DeriveNewSeed.
< bitcoin-git> bitcoin/master d82c5d1 MarcoFalke: Merge #13297: [wallet] Fix incorrect comment for DeriveNewSeed....
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13297: [wallet] Fix incorrect comment for DeriveNewSeed. (master...derive_hd_seed_comment) https://github.com/bitcoin/bitcoin/pull/13297
< cfields> jamesob: confirmed, but i'm not sure if it's a mingw problem or a Wine one
< jamesob> cfields: yeah, good point. we'd need a native Windows platform to figure that one out, right?
< cfields> I guess realistically, those are the same thing for us, as a Wine bug would keep us from testing entirely
< cfields> jamesob: right
< cfields> bug was reported here, don't know if it was ever fixed: https://sourceforge.net/p/mingw-w64/bugs/445/
< cfields> jamesob: for platforms where we're enabling thread_local, we should add a runtime sanity check for sure
< jamesob> cfields: what specifically are you thinking there?
< jamesob> something more in the AC_LINK_IFELSE program?
< cfields> jamesob: see compat/glibc_sanity.cpp as an example. Imo we need compat/thread_local_sanity.cpp too
< cfields> jamesob: no, something that's actually executed by bitcoind as a quick runtime check
< jamesob> the testcase I wrote results in a stackoverflow though - is there a way to safely include something like that at runtime?
< cfields> basically, if it compiles and links ok, there's still a chance something's busted. We need to be able to catch the mingw failure and refuse to run, even if we didn't know that it was busted
< cfields> jamesob: see the link above. seems to give predictable-ish results
< ken2812221> jamesob: I test your code on Ubuntu 18.04, it seems not an issue anymore.
< ken2812221> I test it on native Windows and wine3.0
< pierre_rochard> I’ve written a blog post for the 1.0 release of BitcoinACKs.com and would really appreciate any and all feedback before I publish it: https://gist.github.com/PierreRochard/dad65528025cfac21bc5521ef7e629ac
< jamesob> ken2812221: interesting. thanks for testing.
< pierre_rochard> Additionally, if you would like to provide a short blurb quote explaining why you find the site useful, that would be appreciated!
< Chris_Stewart_5> pierre_rochard: Very cool
< Chris_Stewart_5> pierre_rochard: Are you going to add that blurb to a help menu on the site?
< pierre_rochard> @chris_stewart_5 thanks! I was going to append blurbs to the blog post itself, and publish it as an "About" tab on the acks website, as well as on medium / my own website
< jamesob> cfields: you're pretty confident that the bug described in that issue is the same one affecting us in the gist?
< cfields> jamesob: not sure, no. An issue either way, though
< bitcoin-git> [bitcoin] naumenkogs opened pull request #13298: Net: Random delays *per network group* to obfuscate transaction time (master...delay_per_net_group) https://github.com/bitcoin/bitcoin/pull/13298
< skeees> anyone here looking at / spending time reviewing the latest dandelion proposal (either bip or code)?
< sipa> skeees: yup
< bitcoin-git> [bitcoin] jamesob closed pull request #13200: Process logs in a separate thread (master...2018-05-asynclog) https://github.com/bitcoin/bitcoin/pull/13200
< sipa> i was planning to go through it
< Varunram> Is anyone else having this bug on macOS? bitcoind starts fine but I can't seem to query it using bitcoin-cli
< Varunram> I'm on regtest and on commit d792e47421fcb9ce3b381c1e6d8902777ae3f9f3 for ref.
< sipa> define "can't seem to query it" ?
< sipa> what do you do, what do you see, what do you expect to see
< Varunram> sorry, should've been clearer: `Could not connect to the server`
< sipa> are you sure bitcoind is running?
< Varunram> yep
< Varunram> btw, why is it trying to connect on that port?
< Varunram> it should be 18443 right?
< sipa> ah
< sipa> are you passing -regtest to bitcoin-cli?
< Varunram> oh my
< sipa> :)
< Varunram> was this added in 0.16? I can pretty much be sure I didn't do this in 0.15
< sipa> there is no way bitcoin-cli can know you're trying to connect to regtest without it
< sipa> ever
< Varunram> oh, ok. I guess i'd have had it in the conf then
< Varunram> thanks!
< sipa> that's possible
< satwo_> Hello all. Is the "witness_unknown" script type in Bitcoin Core essentially in place for backward compatibility in the event of a future soft fork adding a new witness script type (or increasing the version of an existing one)?
< sipa> yes
< sipa> because BIP173 defines an address type for future segwit versions, we need a way to parse and represent those
< satwo> Ok, thanks sipa. Would it be possible for someone to manually construct such an address type right now that the parser represents as "witness_unknown"?
< satwo> Not asking because I plan on doing so, but just want to make sure I understand things properly.
< luke-jr> satwo: yes, but it would be basically an anyone-can-spend and rejected by network policies
< sipa> satwo: creating such an address would be trivial, yes
< sipa> BIP173 even contains an example: bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj
< Chris_Stewart_5> Does anyone know how to compile bitcoin core when there is a name conflict for threading libraries on windows?
< satwo> Ah, that's what I was getting at, whether a tx with such an output could be relayed/mined at the present time. Thanks for the clarification gents.
< Chris_Stewart_5> what is the flag that needs to be set on ./configure ?
< luke-jr> Chris_Stewart_5: why would there be?
< Chris_Stewart_5> link to output: https://pastebin.com/ksnLcu3V
< Chris_Stewart_5> luke-jr: It's talked about in this foot note, but I'm not sure what flag needs to be set: https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md#footnotes
< luke-jr> odd
< sipa> Chris_Stewart_5: are you compiling _on_ windows or _for_ windows?
< Chris_Stewart_5> sipa: Using the "Windows subsystem for Linux" which I beleive is the former?
< sipa> the two footnotes there are specifically about issues when building on ubuntu for windows
< sipa> i doubt they apply to WSL
< sipa> ah, but WSL is derived from ubuntu?
< Chris_Stewart_5> sipa: Possibly? I'm not 100% sure. Today is the first day of learning of this :-)
< Chris_Stewart_5> "The Windows Subsystem for Linux lets developers run Linux environments -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a virtual machine. "
< sipa> i don't know either
< kallewoof> jimpo: Now I am :)