1 2018-05-21 02:27:09	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #13289: [Qt] Re-setup args after translator setup to translate help text (06master...06qt-help-translations) 02https://github.com/bitcoin/bitcoin/pull/13289
  2 2018-05-21 06:10:25	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13291: [moveonly] Extract tor_reply.h from tor_control.cpp (06master...06tor-reply) 02https://github.com/bitcoin/bitcoin/pull/13291
  3 2018-05-21 07:26:56	0|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 ?
  4 2018-05-21 07:36:16	0|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.
  5 2018-05-21 07:36:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
  6 2018-05-21 07:36:50	0|provoostenator|If that doesn't make any sense at all, then maybe I'm just seeing random noise, so thoughts welcome.
  7 2018-05-21 07:37:33	0|luke-jr|provoostenator: I imagine the 10% pruning is most of the advantage
  8 2018-05-21 07:38:23	0|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.
  9 2018-05-21 07:39:24	0|luke-jr|yes, I wouldn't expect pruning more to be harmful
 10 2018-05-21 07:39:37	0|luke-jr|except in terms of wallet syncing perhaps
 11 2018-05-21 07:39:42	0|luke-jr|or similar
 12 2018-05-21 07:40:24	0|provoostenator|This one is configured with --disable-wallet.
 13 2018-05-21 07:41:54	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d792e47421fc...6738813bcbb7
 14 2018-05-21 07:41:55	0|bitcoin-git|13bitcoin/06master 14131d445 15John Newbery: scripted-diff: Rename master key to seed...
 15 2018-05-21 07:41:55	0|bitcoin-git|13bitcoin/06master 14c75c351 15John Newbery: [refactor] manually change remaining instances of master key to seed.
 16 2018-05-21 07:41:56	0|bitcoin-git|13bitcoin/06master 1479053a5 15John Newbery: [rpc] [wallet] Add 'hdmasterkeyid' alias return values....
 17 2018-05-21 07:42:32	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #12924: Fix hdmaster-key / seed-key confusion (scripted diff) (06master...06master_key_to_seed) 02https://github.com/bitcoin/bitcoin/pull/12924
 18 2018-05-21 07:48:01	0|provoostenator|(I think that "someone" was eklitzke)
 19 2018-05-21 07:58:48	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #13292: Re-add bench_bitcoin to gitian binaries (06master...062018/05/bench_gitian) 02https://github.com/bitcoin/bitcoin/pull/13292
 20 2018-05-21 08:42:45	0|bitcoin-git|[13bitcoin] 15KaneoHunter opened pull request #13293: Fixed grammar issue. (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/13293
 21 2018-05-21 08:45:24	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #13293: Fixed grammar issue. (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/13293
 22 2018-05-21 09:48:54	0|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?
 23 2018-05-21 09:52:48	0|luke-jr|mmgen: the recommended way is to use the backupwallet RPC (or GUI equivalent)
 24 2018-05-21 09:52:55	0|luke-jr|but if you must copy the data manually, you need both
 25 2018-05-21 09:53:16	0|luke-jr|and from the same instant.. which may not be easy to get reliably
 26 2018-05-21 09:53:37	0|mmgen|luke-jr: however, backupwallet just makes a copy of wallet.dat, nothing more
 27 2018-05-21 09:54:05	0|mmgen|luke-jr: it doesn't copy the database directory, as far as I know
 28 2018-05-21 09:54:38	0|luke-jr|mmgen: it closes the database first, and makes a copy with it closed
 29 2018-05-21 09:54:59	0|mmgen|luke-jr: so the wallet.dat it produces is a complete backup that contains all the history?
 30 2018-05-21 09:55:16	0|luke-jr|right
 31 2018-05-21 09:55:32	0|mmgen|luke-jr: ok, that's what I neede to know.  Thanks!
 32 2018-05-21 10:03:17	0|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.
 33 2018-05-21 12:05:07	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 (06master...06openbsd-warnings) 02https://github.com/bitcoin/bitcoin/pull/13294
 34 2018-05-21 13:28:18	0|Emzy|Moin
 35 2018-05-21 14:37:28	0|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
 36 2018-05-21 14:44:07	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13295: docs: Update OpenBSD build instructions for OpenBSD 6.3 (06master...06openbsd-6.3) 02https://github.com/bitcoin/bitcoin/pull/13295
 37 2018-05-21 14:59:01	0|Chris_Stewart_5|Does the protocol allow for different hash types for each signature in a multisig script?
 38 2018-05-21 15:36:25	0|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
 39 2018-05-21 15:40:25	0|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?
 40 2018-05-21 15:41:55	0|jimpo|kallewoof: You around by any chance?
 41 2018-05-21 16:42:17	0|bitcoin-git|13bitcoin/06master 144138f42 15Ben Woosley: Revert "Merge #12870: make clean removes src/qt/moc_ files"...
 42 2018-05-21 16:42:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6738813bcbb7...092b36688142
 43 2018-05-21 16:42:18	0|bitcoin-git|13bitcoin/06master 14092b366 15MarcoFalke: Merge #13254: Remove improper qt/moc_* cleaning glob from the general Makefile...
 44 2018-05-21 16:43:04	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13254: Remove improper qt/moc_* cleaning glob from the general Makefile (06master...06make-clean-qt-moc) 02https://github.com/bitcoin/bitcoin/pull/13254
 45 2018-05-21 16:58:37	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13297: [wallet] Fix incorrect comment for DeriveNewSeed. (06master...06derive_hd_seed_comment) 02https://github.com/bitcoin/bitcoin/pull/13297
 46 2018-05-21 17:16:54	0|cfields|jamesob: maybe just exclude those OSs from the configure check?
 47 2018-05-21 17:17:11	0|cfields|heh yes, what ryanofsky said :)
 48 2018-05-21 17:17:58	0|cfields|jamesob: do you have a link to the busted mingw results? I'm curious to see the details
 49 2018-05-21 17:18:25	0|jamesob|cfields: https://gist.github.com/jamesob/fe9a872051a88b2025b1aa37bfa98605
 50 2018-05-21 17:19:41	0|cfields|thanks, looking
 51 2018-05-21 17:25:08	0|bitcoin-git|13bitcoin/06master 14be87c6f 15John Newbery: [wallet] Fix incorrect comment for DeriveNewSeed.
 52 2018-05-21 17:25:08	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/092b36688142...d82c5d15c504
 53 2018-05-21 17:25:09	0|bitcoin-git|13bitcoin/06master 14d82c5d1 15MarcoFalke: Merge #13297: [wallet] Fix incorrect comment for DeriveNewSeed....
 54 2018-05-21 17:25:59	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13297: [wallet] Fix incorrect comment for DeriveNewSeed. (06master...06derive_hd_seed_comment) 02https://github.com/bitcoin/bitcoin/pull/13297
 55 2018-05-21 17:41:52	0|cfields|jamesob: confirmed, but i'm not sure if it's a mingw problem or a Wine one
 56 2018-05-21 17:42:22	0|jamesob|cfields: yeah, good point. we'd need a native Windows platform to figure that one out, right?
 57 2018-05-21 17:42:25	0|cfields|I guess realistically, those are the same thing for us, as a Wine bug would keep us from testing entirely
 58 2018-05-21 17:42:38	0|cfields|jamesob: right
 59 2018-05-21 17:43:21	0|cfields|bug was reported here, don't know if it was ever fixed: https://sourceforge.net/p/mingw-w64/bugs/445/
 60 2018-05-21 17:45:40	0|cfields|jamesob: for platforms where we're enabling thread_local, we should add a runtime sanity check for sure
 61 2018-05-21 17:47:04	0|jamesob|cfields: what specifically are you thinking there?
 62 2018-05-21 17:47:30	0|jamesob|something more in the AC_LINK_IFELSE program?
 63 2018-05-21 17:47:37	0|cfields|jamesob: see compat/glibc_sanity.cpp as an example. Imo we need compat/thread_local_sanity.cpp too
 64 2018-05-21 17:47:59	0|cfields|jamesob: no, something that's actually executed by bitcoind as a quick runtime check
 65 2018-05-21 17:49:39	0|jamesob|the testcase I wrote results in a stackoverflow though - is there a way to safely include something like that at runtime?
 66 2018-05-21 17:49:52	0|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
 67 2018-05-21 17:50:11	0|cfields|jamesob: see the link above. seems to give predictable-ish results
 68 2018-05-21 17:50:47	0|ken2812221|jamesob: I test your code on Ubuntu 18.04, it seems not an issue anymore.
 69 2018-05-21 17:51:24	0|ken2812221|I test it on native Windows and wine3.0
 70 2018-05-21 17:54:56	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
 71 2018-05-21 17:55:12	0|jamesob|ken2812221: interesting. thanks for testing.
 72 2018-05-21 17:55:50	0|pierre_rochard|Additionally, if you would like to provide a short blurb quote explaining why you find the site useful, that would be appreciated!
 73 2018-05-21 18:00:24	0|Chris_Stewart_5|pierre_rochard: Very cool
 74 2018-05-21 18:01:46	0|Chris_Stewart_5|pierre_rochard: Are you going to add that blurb to a help menu on the site?
 75 2018-05-21 18:03:35	0|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
 76 2018-05-21 18:03:58	0|jamesob|cfields: you're pretty confident that the bug described in that issue is the same one affecting us in the gist?
 77 2018-05-21 18:09:27	0|cfields|jamesob: not sure, no. An issue either way, though
 78 2018-05-21 19:03:23	0|bitcoin-git|[13bitcoin] 15naumenkogs opened pull request #13298: Net: Random delays *per network group* to obfuscate transaction time (06master...06delay_per_net_group) 02https://github.com/bitcoin/bitcoin/pull/13298
 79 2018-05-21 20:14:42	0|skeees|anyone here looking at / spending time reviewing the latest dandelion proposal (either bip or code)?
 80 2018-05-21 20:30:56	0|sipa|skeees: yup
 81 2018-05-21 20:31:49	0|bitcoin-git|[13bitcoin] 15jamesob closed pull request #13200: Process logs in a separate thread (06master...062018-05-asynclog) 02https://github.com/bitcoin/bitcoin/pull/13200
 82 2018-05-21 20:32:54	0|sipa|i was planning to go through it
 83 2018-05-21 21:19:00	0|Varunram|Is anyone else having this bug on macOS? bitcoind starts fine but I can't seem to query it using bitcoin-cli
 84 2018-05-21 21:19:18	0|Varunram|I'm on regtest and on commit d792e47421fcb9ce3b381c1e6d8902777ae3f9f3 for ref.
 85 2018-05-21 21:21:19	0|sipa|define "can't seem to query it" ?
 86 2018-05-21 21:21:57	0|sipa|what do you do, what do you see, what do you expect to see
 87 2018-05-21 21:22:00	0|Varunram|sorry, should've been clearer: `Could not connect to the server 127.0.0.1:8332`
 88 2018-05-21 21:22:25	0|sipa|are you sure bitcoind is running?
 89 2018-05-21 21:22:40	0|Varunram|yep
 90 2018-05-21 21:22:52	0|Varunram|btw, why is it trying to connect on that port?
 91 2018-05-21 21:22:59	0|Varunram|it should be 18443 right?
 92 2018-05-21 21:23:10	0|sipa|ah
 93 2018-05-21 21:23:18	0|sipa|are you passing -regtest to bitcoin-cli?
 94 2018-05-21 21:23:42	0|Varunram|oh my
 95 2018-05-21 21:23:57	0|sipa|:)
 96 2018-05-21 21:24:05	0|Varunram|was this added in 0.16? I can pretty much be sure I didn't do this in 0.15
 97 2018-05-21 21:24:58	0|sipa|there is no way bitcoin-cli can know you're trying to connect to regtest without it
 98 2018-05-21 21:25:02	0|sipa|ever
 99 2018-05-21 21:25:19	0|Varunram|oh, ok. I guess i'd have had it in the conf then
100 2018-05-21 21:25:29	0|Varunram|thanks!
101 2018-05-21 21:25:30	0|sipa|that's possible
102 2018-05-21 22:45:09	0|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)?
103 2018-05-21 22:47:17	0|sipa|yes
104 2018-05-21 22:47:53	0|sipa|because BIP173 defines an address type for future segwit versions, we need a way to parse and represent those
105 2018-05-21 22:52:43	0|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"?
106 2018-05-21 23:00:16	0|satwo|Not asking because I plan on doing so, but just want to make sure I understand things properly.
107 2018-05-21 23:17:15	0|luke-jr|satwo: yes, but it would be basically an anyone-can-spend and rejected by network policies
108 2018-05-21 23:17:49	0|sipa|satwo: creating such an address would be trivial, yes
109 2018-05-21 23:18:27	0|sipa|BIP173 even contains an example: bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj
110 2018-05-21 23:23:09	0|Chris_Stewart_5|Does anyone know how to compile bitcoin core when there is a name conflict for threading libraries on windows?
111 2018-05-21 23:23:17	0|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.
112 2018-05-21 23:23:21	0|Chris_Stewart_5|what is the flag that needs to be set on ./configure ?
113 2018-05-21 23:24:43	0|luke-jr|Chris_Stewart_5: why would there be?
114 2018-05-21 23:25:18	0|Chris_Stewart_5|link to output: https://pastebin.com/ksnLcu3V
115 2018-05-21 23:25:50	0|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
116 2018-05-21 23:31:28	0|luke-jr|odd
117 2018-05-21 23:32:49	0|sipa|Chris_Stewart_5: are you compiling _on_ windows or _for_ windows?
118 2018-05-21 23:33:43	0|Chris_Stewart_5|sipa: Using the "Windows subsystem for Linux" which I beleive is the former?
119 2018-05-21 23:34:21	0|sipa|the two footnotes there are specifically about issues when building on ubuntu for windows
120 2018-05-21 23:34:26	0|sipa|i doubt they apply to WSL
121 2018-05-21 23:34:57	0|sipa|ah, but WSL is derived from ubuntu?
122 2018-05-21 23:35:47	0|Chris_Stewart_5|sipa: Possibly? I'm not 100% sure. Today is the first day of learning of this :-)
123 2018-05-21 23:36:19	0|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. "
124 2018-05-21 23:37:14	0|sipa|i don't know either
125 2018-05-21 23:39:53	0|kallewoof|jimpo: Now I am :)