1 2017-07-11T00:21:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  2 2017-07-11T00:36:00  *** Ylbam has quit IRC
  3 2017-07-11T00:49:48  *** chjj has quit IRC
  4 2017-07-11T01:01:55  *** chjj has joined #bitcoin-core-dev
  5 2017-07-11T01:12:39  *** AaronvanW has joined #bitcoin-core-dev
  6 2017-07-11T01:13:47  *** BashCo has quit IRC
  7 2017-07-11T01:13:52  *** AaronvanW has quit IRC
  8 2017-07-11T01:14:22  *** BashCo has joined #bitcoin-core-dev
  9 2017-07-11T01:15:35  *** Aaronva__ has quit IRC
 10 2017-07-11T01:29:15  *** Murch has quit IRC
 11 2017-07-11T01:35:15  <bitcoin-git> [bitcoin] achow101 opened pull request #10788: Replace ismine with producesignature check in witnessifier (master...fix-addwitnessaddress) https://github.com/bitcoin/bitcoin/pull/10788
 12 2017-07-11T01:40:05  *** str4d has joined #bitcoin-core-dev
 13 2017-07-11T01:40:10  *** chjj has quit IRC
 14 2017-07-11T01:40:37  *** dabura667 has joined #bitcoin-core-dev
 15 2017-07-11T01:50:31  *** Chris_Stewart_5 has quit IRC
 16 2017-07-11T01:51:39  *** Murch has joined #bitcoin-core-dev
 17 2017-07-11T02:03:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 18 2017-07-11T02:05:56  <bitcoin-git> [bitcoin] stevendlander opened pull request #10789: Punctuation/grammer fixes in rpcwallet.cpp (master...cli-punctuation-standardization) https://github.com/bitcoin/bitcoin/pull/10789
 19 2017-07-11T02:26:07  *** Murch has quit IRC
 20 2017-07-11T02:37:07  *** joelsbeard has quit IRC
 21 2017-07-11T02:42:15  <jtimon> mhm, can't I use something I have in /etc/host with -rpcallowip ? only hardcoded ips ?
 22 2017-07-11T02:42:24  <jtimon> not even localhost it seems :(
 23 2017-07-11T02:45:24  *** dermoth has quit IRC
 24 2017-07-11T02:46:41  *** dermoth has joined #bitcoin-core-dev
 25 2017-07-11T02:49:17  <sipa> jtimon: it has to be a netmask, i think
 26 2017-07-11T02:49:19  <sipa> so no
 27 2017-07-11T02:51:34  <jtimon> found getent hosts myhostname | awk '{ print $1 }', hope it solves my issue
 28 2017-07-11T02:52:03  <jtimon> thanks for confirming
 29 2017-07-11T03:08:05  *** Chris_Stewart_5 has quit IRC
 30 2017-07-11T03:24:11  <bitcoin-git> [bitcoin] MeshCollider opened pull request #10790: Use vector::data() instead of &vch[0] in base58.cpp (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10790
 31 2017-07-11T03:35:02  *** d9b4bef9 has quit IRC
 32 2017-07-11T03:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
 33 2017-07-11T03:38:11  *** CubicEarth has joined #bitcoin-core-dev
 34 2017-07-11T03:39:48  *** kvp has joined #bitcoin-core-dev
 35 2017-07-11T03:44:04  *** chjj has joined #bitcoin-core-dev
 36 2017-07-11T04:11:59  *** jamesob has joined #bitcoin-core-dev
 37 2017-07-11T04:23:50  *** str4d has quit IRC
 38 2017-07-11T04:36:40  *** chjj has quit IRC
 39 2017-07-11T04:47:45  *** dermoth has quit IRC
 40 2017-07-11T05:17:49  <gmaxwell> hurray for protocol improvements, you can see the inv rate on this chart approve as people upgrade to 0.13+ https://statoshi.info/dashboard/db/p2p-messages?from=1453110746831&to=1499750141000
 41 2017-07-11T05:20:53  *** jcorgan has quit IRC
 42 2017-07-11T05:24:08  *** BashCo has quit IRC
 43 2017-07-11T05:24:53  *** BashCo has joined #bitcoin-core-dev
 44 2017-07-11T06:06:42  *** CubicEarth has quit IRC
 45 2017-07-11T06:23:02  *** ula has joined #bitcoin-core-dev
 46 2017-07-11T06:35:41  *** Ylbam has joined #bitcoin-core-dev
 47 2017-07-11T06:52:17  *** shadders has joined #bitcoin-core-dev
 48 2017-07-11T06:54:02  *** chjj has joined #bitcoin-core-dev
 49 2017-07-11T07:03:51  *** Murch has joined #bitcoin-core-dev
 50 2017-07-11T07:06:09  *** chjj has quit IRC
 51 2017-07-11T07:11:35  *** Dyaheon has quit IRC
 52 2017-07-11T07:13:08  *** Dyaheon has joined #bitcoin-core-dev
 53 2017-07-11T07:16:00  *** Meghan has quit IRC
 54 2017-07-11T07:23:23  <wumpus> right, some of the options support host lookup as of master, but rpcallowip certainly doesn't
 55 2017-07-11T07:24:04  <wumpus> (e.g. #9774)
 56 2017-07-11T07:24:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9774 | Enable host lookups for -proxy and -onion parameters by jmcorgan · Pull Request #9774 · bitcoin/bitcoin · GitHub
 57 2017-07-11T07:24:12  *** dermoth has joined #bitcoin-core-dev
 58 2017-07-11T07:26:44  <wumpus> oh yes, inv rate looks a lot more calm recently
 59 2017-07-11T07:28:50  <gmaxwell> the changes for inv batching and timing make it basically constant.
 60 2017-07-11T07:35:01  *** d9b4bef9 has quit IRC
 61 2017-07-11T07:38:08  *** d9b4bef9 has joined #bitcoin-core-dev
 62 2017-07-11T07:39:18  <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/9edda0c5f5f2...21ed30a314cf
 63 2017-07-11T07:39:19  <bitcoin-git> bitcoin/master ff6a834 Matt Corallo: Use TestingSetup to DRY qt rpcnestedtests
 64 2017-07-11T07:39:19  <bitcoin-git> bitcoin/master 3a19fed Matt Corallo: Make ValidationInterface signals-type-agnostic...
 65 2017-07-11T07:39:20  <bitcoin-git> bitcoin/master cda1429 Matt Corallo: Give CMainSignals a reference to the global scheduler...
 66 2017-07-11T07:39:33  <bitcoin-git> [bitcoin] laanwj closed pull request #10179: Give CValidationInterface Support for calling notifications on the CScheduler Thread (master...2017-01-wallet-cache-inmempool-3) https://github.com/bitcoin/bitcoin/pull/10179
 67 2017-07-11T07:46:40  <bitcoin-git> [bitcoin] maaku opened pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792
 68 2017-07-11T07:50:48  *** coredump_ has quit IRC
 69 2017-07-11T07:54:13  <gmaxwell> you mean it doesn't compute the max of the last two stack variables!?!?
 70 2017-07-11T07:54:16  <gmaxwell> :P
 71 2017-07-11T07:55:41  *** promag has joined #bitcoin-core-dev
 72 2017-07-11T07:56:45  <gmaxwell> [OT-ish] https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf  < the ictp described here is neat. I wish pax stuff was open.
 73 2017-07-11T07:57:05  <sipa> gmaxwell: ???
 74 2017-07-11T07:57:13  <sipa> (re: last two stack variables)
 75 2017-07-11T07:58:28  *** arowser has quit IRC
 76 2017-07-11T08:00:24  *** Murch has quit IRC
 77 2017-07-11T08:00:55  <gmaxwell> sipa: joke on mark's MAX_OPCODE
 78 2017-07-11T08:01:11  <gmaxwell> that it doesn't compute max()
 79 2017-07-11T08:01:32  *** paveljanik has quit IRC
 80 2017-07-11T08:01:44  *** Murch has joined #bitcoin-core-dev
 81 2017-07-11T08:02:07  <sipa> ah
 82 2017-07-11T08:04:14  *** Murch has quit IRC
 83 2017-07-11T08:04:39  *** arowser has joined #bitcoin-core-dev
 84 2017-07-11T08:07:46  *** promag has quit IRC
 85 2017-07-11T08:16:34  <bitcoin-git> [bitcoin] MeshCollider closed pull request #10790: Use vector::data() instead of &vch[0] in base58.cpp (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10790
 86 2017-07-11T08:39:33  *** Murch has joined #bitcoin-core-dev
 87 2017-07-11T08:44:07  *** vicenteH has joined #bitcoin-core-dev
 88 2017-07-11T08:45:08  *** Aaronvan_ has joined #bitcoin-core-dev
 89 2017-07-11T08:50:42  *** timothy has joined #bitcoin-core-dev
 90 2017-07-11T08:52:00  *** pyface has joined #bitcoin-core-dev
 91 2017-07-11T09:11:42  *** promag has joined #bitcoin-core-dev
 92 2017-07-11T09:26:12  *** Murch has quit IRC
 93 2017-07-11T09:33:48  *** riemann has joined #bitcoin-core-dev
 94 2017-07-11T09:37:39  *** jtimon has quit IRC
 95 2017-07-11T09:44:05  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21ed30a314cf...379aed0e53a6
 96 2017-07-11T09:44:05  <bitcoin-git> bitcoin/master f2f1d0a Gregory Sanders: document script-based return fields for validateaddress
 97 2017-07-11T09:44:06  <bitcoin-git> bitcoin/master 379aed0 Wladimir J. van der Laan: Merge #10676: document script-based return fields for validateaddress...
 98 2017-07-11T09:44:31  <bitcoin-git> [bitcoin] laanwj closed pull request #10676: document script-based return fields for validateaddress (master...validatata) https://github.com/bitcoin/bitcoin/pull/10676
 99 2017-07-11T09:45:44  <bitcoin-git> [bitcoin] MeshCollider opened pull request #10793: Changing &var[0] to var.data() (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10793
100 2017-07-11T09:48:27  *** goatpig has joined #bitcoin-core-dev
101 2017-07-11T09:58:26  <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/379aed0e53a6...104f5f21dc24
102 2017-07-11T09:58:27  <bitcoin-git> bitcoin/master cfaef69 Alex Morcos: remove default argument from GetMinimumFee
103 2017-07-11T09:58:27  <bitcoin-git> bitcoin/master d507c30 Alex Morcos: Introduce a fee estimate mode....
104 2017-07-11T09:58:28  <bitcoin-git> bitcoin/master e0738e3 Alex Morcos: remove default argument from estimateSmartFee
105 2017-07-11T09:58:46  <bitcoin-git> [bitcoin] laanwj closed pull request #10589: More economical fee estimates for RBF and RPC options to control (master...rpcestimatechoice) https://github.com/bitcoin/bitcoin/pull/10589
106 2017-07-11T10:20:45  *** coredump_ has joined #bitcoin-core-dev
107 2017-07-11T10:36:27  *** coredump_ has quit IRC
108 2017-07-11T10:36:45  *** pyface has quit IRC
109 2017-07-11T10:42:29  *** coredump_ has joined #bitcoin-core-dev
110 2017-07-11T10:46:07  *** Aaronvan_ has quit IRC
111 2017-07-11T10:50:01  *** promag has quit IRC
112 2017-07-11T10:54:26  *** Victorsueca has quit IRC
113 2017-07-11T10:58:57  *** Victorsueca has joined #bitcoin-core-dev
114 2017-07-11T11:00:05  *** Dyaheon has quit IRC
115 2017-07-11T11:02:29  *** Dyaheon has joined #bitcoin-core-dev
116 2017-07-11T11:13:15  *** coredump_ has quit IRC
117 2017-07-11T11:36:47  *** coredump_ has joined #bitcoin-core-dev
118 2017-07-11T11:40:01  *** laurentmt has joined #bitcoin-core-dev
119 2017-07-11T11:41:35  *** laurentmt has quit IRC
120 2017-07-11T11:51:23  *** coredump_ has quit IRC
121 2017-07-11T12:14:37  *** JackH has joined #bitcoin-core-dev
122 2017-07-11T12:31:29  *** PlaneteNamek has joined #bitcoin-core-dev
123 2017-07-11T12:31:58  <PlaneteNamek> Hello world 😊
124 2017-07-11T12:34:07  <jonasschnelli> Beg for review on: https://github.com/bitcoin/bitcoin/pull/9502
125 2017-07-11T12:48:20  *** PlaneteNamek has quit IRC
126 2017-07-11T12:53:32  *** robotpoop has joined #bitcoin-core-dev
127 2017-07-11T12:57:51  *** CubicEarth has joined #bitcoin-core-dev
128 2017-07-11T13:01:56  *** ula has quit IRC
129 2017-07-11T13:05:14  *** ProfMac has quit IRC
130 2017-07-11T13:08:05  *** robotpoop has quit IRC
131 2017-07-11T13:10:10  *** jrayhawk has quit IRC
132 2017-07-11T13:11:33  *** jrayhawk has joined #bitcoin-core-dev
133 2017-07-11T13:11:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
134 2017-07-11T13:12:42  <wumpus> #9502
135 2017-07-11T13:12:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub
136 2017-07-11T13:13:54  *** AaronvanW has joined #bitcoin-core-dev
137 2017-07-11T13:21:52  <bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/104f5f21dc24...e4f226a133d0
138 2017-07-11T13:21:53  <bitcoin-git> bitcoin/master 32cffe6 John Newbery: [tests] Fix import order in getblocktemplate test
139 2017-07-11T13:21:53  <bitcoin-git> bitcoin/master 0a3a5ff John Newbery: [tests] Fix flake8 warnings in getblocktemplate tests
140 2017-07-11T13:21:54  <bitcoin-git> bitcoin/master 38b38cd John Newbery: [tests] getblocktemplate_proposals.py: add logging
141 2017-07-11T13:21:59  *** Guyver2 has joined #bitcoin-core-dev
142 2017-07-11T13:22:14  <bitcoin-git> [bitcoin] laanwj closed pull request #10190: [tests] mining functional tests (including regression test for submitblock) (master...mining_functional_test) https://github.com/bitcoin/bitcoin/pull/10190
143 2017-07-11T13:24:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4f226a133d0...badd81bd3185
144 2017-07-11T13:24:34  <bitcoin-git> bitcoin/master c8e29d7 Mark Friedenbach: Replace MAX_OPCODE for OP_NOP10....
145 2017-07-11T13:24:35  <bitcoin-git> bitcoin/master badd81b Wladimir J. van der Laan: Merge #10792: Replace MAX_OPCODE for OP_NOP10....
146 2017-07-11T13:25:07  <bitcoin-git> [bitcoin] laanwj closed pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792
147 2017-07-11T13:25:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/badd81bd3185...cef4b5ccaa37
148 2017-07-11T13:25:34  <bitcoin-git> bitcoin/master 6270d62 Matt Corallo: Verify binaries from bitcoincore.org and bitcoin.org
149 2017-07-11T13:25:35  <bitcoin-git> bitcoin/master cef4b5c Wladimir J. van der Laan: Merge #10651: Verify binaries from bitcoincore.org and bitcoin.org...
150 2017-07-11T13:25:58  <bitcoin-git> [bitcoin] laanwj closed pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651
151 2017-07-11T13:26:53  *** dabura667 has quit IRC
152 2017-07-11T13:30:36  *** CubicEarth has quit IRC
153 2017-07-11T13:32:47  *** AaronvanW has quit IRC
154 2017-07-11T13:33:23  *** AaronvanW has joined #bitcoin-core-dev
155 2017-07-11T13:37:20  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cef4b5ccaa37...b27b004532db
156 2017-07-11T13:37:21  <bitcoin-git> bitcoin/master 9c85b91 Alex Morcos: Change API to estimaterawfee...
157 2017-07-11T13:37:22  <bitcoin-git> bitcoin/master 1fafd70 Alex Morcos: Add function to report highest estimate target tracked per horizon
158 2017-07-11T13:37:22  <bitcoin-git> bitcoin/master 5e3b7b5 Alex Morcos: Improve error reporting for estimaterawfee
159 2017-07-11T13:37:40  <bitcoin-git> [bitcoin] laanwj closed pull request #10543: Change API to estimaterawfee (master...estimaterawapi) https://github.com/bitcoin/bitcoin/pull/10543
160 2017-07-11T13:37:52  *** AaronvanW has quit IRC
161 2017-07-11T13:40:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b27b004532db...ca4c545cc7e8
162 2017-07-11T13:40:35  <bitcoin-git> bitcoin/master 475c08c Pieter Wuille: Add PR description to merge commit in github-merge.py
163 2017-07-11T13:40:36  <bitcoin-git> bitcoin/master ca4c545 Wladimir J. van der Laan: Merge #10786: Add PR description to merge commit in github-merge.py...
164 2017-07-11T13:41:12  <bitcoin-git> [bitcoin] laanwj closed pull request #10786: Add PR description to merge commit in github-merge.py (master...20170710_prbody) https://github.com/bitcoin/bitcoin/pull/10786
165 2017-07-11T14:06:15  *** cheese_ has joined #bitcoin-core-dev
166 2017-07-11T14:12:07  <ryanofsky> can #10235 be merged?
167 2017-07-11T14:12:09  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
168 2017-07-11T14:31:11  *** RoyceX has joined #bitcoin-core-dev
169 2017-07-11T14:34:08  *** cheese_ has quit IRC
170 2017-07-11T14:53:34  <morcos> I think #10712 can also be merged.  sipa: you left just a nit, were you still reviewing?  I'll skip the nit since the current commit has 3 ack's
171 2017-07-11T14:53:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
172 2017-07-11T14:59:44  *** riemann has quit IRC
173 2017-07-11T15:01:44  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10794: Add simple light-client mode (RPC only) (master...2017/07/spv) https://github.com/bitcoin/bitcoin/pull/10794
174 2017-07-11T15:02:25  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9171: Introduce auxiliary block requests (master...2016/11/spv_step_1) https://github.com/bitcoin/bitcoin/pull/9171
175 2017-07-11T15:02:50  *** Herta has joined #bitcoin-core-dev
176 2017-07-11T15:05:05  *** JackH has quit IRC
177 2017-07-11T15:09:25  *** JackH has joined #bitcoin-core-dev
178 2017-07-11T15:12:28  <BlueMatt> wumpus: would be nice to get a quick glance and merge on #10235
179 2017-07-11T15:12:30  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
180 2017-07-11T15:14:52  *** Dizzle has joined #bitcoin-core-dev
181 2017-07-11T15:34:01  *** Herta has quit IRC
182 2017-07-11T15:35:06  <morcos> BlueMatt: How does it know what index to create key at if the keypool is empty? (same question before your PR)
183 2017-07-11T15:36:26  <BlueMatt> hmm?
184 2017-07-11T15:36:41  <BlueMatt> it doesnt matter if the pool is empty, use index 0?
185 2017-07-11T15:37:08  <BlueMatt> the indexes dont really have a purpose, its more of a set
186 2017-07-11T15:37:13  <wumpus> looking at 10235
187 2017-07-11T15:37:25  <morcos> yeah i just figured that out, that the indices are only for keypool management
188 2017-07-11T15:37:30  <BlueMatt> yea
189 2017-07-11T15:37:58  <morcos> but are you sure there is not a bug now that you have two keypools
190 2017-07-11T15:38:27  <BlueMatt> well afterwards you should still make sure they keyids are unique, ie creating at the max of both sets
191 2017-07-11T15:38:27  <morcos> if external runs out, couldn't you create a new key in the external pool with the same index as one in the internal pool
192 2017-07-11T15:38:38  <BlueMatt> i hope that pr doesnt do that
193 2017-07-11T15:39:58  <morcos> i'm not sure if there is a bug, i'm making my way through all this logic for the first time, but i think it would be a lot clearer if you figured out nInternalEnd and nExternalEnd and maxed them for nEnd
194 2017-07-11T15:40:51  <morcos> actually it seems even worse than that
195 2017-07-11T15:40:58  <morcos> i just don't think this logic works with two pools
196 2017-07-11T15:41:14  <morcos> imagine internal = {1,3} and external = {2,4}
197 2017-07-11T15:41:14  <BlueMatt> hmm?
198 2017-07-11T15:41:18  <morcos> then external runs out
199 2017-07-11T15:41:29  <BlueMatt> you can reuse indexes
200 2017-07-11T15:41:32  <morcos> you'll now generate 4 as the next internal key or external key
201 2017-07-11T15:41:32  <BlueMatt> thats no problem
202 2017-07-11T15:41:35  <morcos> oh yeah, i guess thats ok
203 2017-07-11T15:42:19  <morcos> ok, so ignore me
204 2017-07-11T15:42:28  <morcos> maybe it's pretty clear.
205 2017-07-11T15:43:43  <morcos> what about the pool on disk though?  it seems like you shouldn't start reusining indices until you're sure they aren't in there?
206 2017-07-11T15:44:29  <BlueMatt> hmmmmmm, yea, there is a bug there, but I didnt introduce it
207 2017-07-11T15:44:42  <morcos> yeah, but made it much more likely to get hit i think
208 2017-07-11T15:44:50  <BlueMatt> dont think so?
209 2017-07-11T15:45:02  <BlueMatt> ReserveKeyFromKeyPool, (keypool now empty), TopUpKeyPool, fucked
210 2017-07-11T15:45:14  <BlueMatt> I dont think i made a real difference to the likelyhood there
211 2017-07-11T15:45:24  <morcos> well before you start over again at 1, so it's unlikely the initial indices are still in disk pool
212 2017-07-11T15:45:40  <morcos> but with yours you could easily reuse a recent one as per my {1,3} {2,4} example above
213 2017-07-11T15:45:43  <BlueMatt> depends on your keypool size
214 2017-07-11T15:45:51  <BlueMatt> true
215 2017-07-11T15:45:52  <morcos> sure, seems like a bug either way
216 2017-07-11T15:46:03  <BlueMatt> anyway, its only really likely if you have a small pool, but still not good
217 2017-07-11T15:46:16  <BlueMatt> unless you object I'll fix it in a separate pr?
218 2017-07-11T15:47:31  <wumpus> what is the worst that can happen if an index is inadvertently reused?
219 2017-07-11T15:47:35  <morcos> so what happens, do you overwrite the old keypool entry with the new one on disk?  and seems like you could either return the reserved key or use it, and either case might cause problems
220 2017-07-11T15:47:42  <BlueMatt> jonasschnelli: where are you on #10650? We
221 2017-07-11T15:47:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
222 2017-07-11T15:47:47  <morcos> wumpus: not clear to me
223 2017-07-11T15:47:50  <BlueMatt> re dangerously close to having multiwallet slip to 16
224 2017-07-11T15:48:27  <BlueMatt> wumpus: yea, not clear to me either, intuitively it should be rather minimal, not like we're clearing private keys or anything, but I could see it hitting an assert somewhere
225 2017-07-11T15:48:34  <morcos> BlueMatt: I suppose I have a slight preference for you adding another commit to that PR to fix it.
226 2017-07-11T15:48:36  <wumpus> is everything necessary for multiwallet tagged as 0.15?
227 2017-07-11T15:48:49  <BlueMatt> i think its just 10650 at this point, no?
228 2017-07-11T15:49:02  *** kvp has quit IRC
229 2017-07-11T15:49:13  <wumpus> yes, I think so, and that one is tagged, good
230 2017-07-11T15:50:06  <BlueMatt> morcos: heh, ok, I was trying to avoid polluting the bugfix-vs-not distinction, but I suppose the performance regression is somewhat bugfix-y anyway
231 2017-07-11T15:50:50  <morcos> 64-bits is a big number.. seems pretty safe to just have an in-memory nextIndex that is initialized by taking max of the on-disk last entry in the set?
232 2017-07-11T15:50:58  <morcos> sets
233 2017-07-11T15:51:26  <wumpus> if you do that, please do make it per-wallet, not global
234 2017-07-11T15:51:44  <BlueMatt> yes, that was my preferred fix
235 2017-07-11T15:51:53  <wumpus> but if it's 64-bit I don't think we have to be worried about reusing
236 2017-07-11T15:52:15  <wumpus> unless small numbers are preferable because they are more efficient for some reason
237 2017-07-11T15:52:21  <wumpus> but I don't think so in this case
238 2017-07-11T15:52:36  <BlueMatt> ugh, no, bigger numbers better
239 2017-07-11T15:53:23  <wumpus> ok, so hold off on merging #10235?
240 2017-07-11T15:53:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
241 2017-07-11T15:53:31  <BlueMatt> i guess
242 2017-07-11T15:53:46  <wumpus> I'm not sure that's the right thing to do if that bug was not introduced here
243 2017-07-11T15:53:55  * BlueMatt does care
244 2017-07-11T15:54:02  <morcos> wumpus: don't hold off for my sake
245 2017-07-11T15:54:16  <morcos> i trust we'll merge the fix before 0.15
246 2017-07-11T15:54:30  <BlueMatt> heh, ok, how bout i just open a pr right now to fix it
247 2017-07-11T15:54:34  <BlueMatt> and take 10235
248 2017-07-11T15:54:48  <morcos> BlueMatt: stop talking and start coding
249 2017-07-11T15:55:58  <wumpus> std::max(nEnd, *(--setExternalKeyPool.end()) + 1);
250 2017-07-11T15:56:05  <wumpus> whaaaa
251 2017-07-11T15:56:19  <BlueMatt> lol, i didnt introduce that
252 2017-07-11T15:56:22  <wumpus> what is *that*
253 2017-07-11T15:56:57  <BlueMatt> there's no back() in set :(
254 2017-07-11T15:57:10  <wumpus> I'm not blaming you, but that's not acceptable, certainly not without a comment
255 2017-07-11T15:57:25  <wumpus> then add a back(set) helper function maybe
256 2017-07-11T15:57:30  <BlueMatt> lol, ok, sec
257 2017-07-11T15:57:33  <wumpus> factor this out to a sensible something
258 2017-07-11T15:58:00  <BlueMatt> fwiw, I find that pretty readable, but ok
259 2017-07-11T15:58:07  <wumpus> no, that's not readable
260 2017-07-11T15:58:08  <wumpus> not at all
261 2017-07-11T15:58:24  <wumpus> why would you want to infix-decrease end()?
262 2017-07-11T15:58:30  <wumpus> what does that even do?
263 2017-07-11T15:58:39  <wumpus> does it move the end of the set?
264 2017-07-11T15:59:46  <BlueMatt> but, then, i write iterator garbage that looks like https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/blockencodings.cpp#L281
265 2017-07-11T16:00:20  <wumpus> people have to be able to maintain that code, also people that are not you
266 2017-07-11T16:00:34  <BlueMatt> i didnt write it
267 2017-07-11T16:00:44  <BlueMatt> I'm fixing...
268 2017-07-11T16:01:59  <wumpus> that function in fibre looks more understandable
269 2017-07-11T16:02:11  <wumpus> it doesn't do anything really crazy and it does it step by step
270 2017-07-11T16:03:02  <BlueMatt> ok, fixed on 10235
271 2017-07-11T16:03:31  <BlueMatt> lol, clearly I need to try harder to write garbage iterator code in fibre then
272 2017-07-11T16:04:04  <wumpus> well as long as you don't inadvertently add UB
273 2017-07-11T16:04:33  <wumpus> but if you really want to, make sure it's all in one expression and the order of operations, as well as what applies to what isn't clear
274 2017-07-11T16:05:12  *** jtimon has joined #bitcoin-core-dev
275 2017-07-11T16:05:16  <wumpus> yes, this is much better, thanks
276 2017-07-11T16:05:24  <BlueMatt> heh, I was joking, that stuff is hard enough to maintain when I go back once every three months and rewrite big chunks to get another 2 milliseconds out of it :p
277 2017-07-11T16:05:41  <BlueMatt> without remembering the threading model that will cause a segfault-in-a-million if you break it
278 2017-07-11T16:07:36  <wumpus> I can imagine
279 2017-07-11T16:07:38  <cfields> BlueMatt: fwiw, you can use *.rend() if !empty()
280 2017-07-11T16:07:49  <cfields> er, rbegin
281 2017-07-11T16:07:57  <BlueMatt> yea, that too
282 2017-07-11T16:13:00  <BlueMatt> wumpus: err, nvm, easier to just fix the first bug than bother with simplifying that code
283 2017-07-11T16:13:29  <wumpus> I'm afraid #10712 doesn't build on top of current master
284 2017-07-11T16:13:31  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
285 2017-07-11T16:13:36  <wumpus> BlueMatt: well you had simplified that code just fine imo
286 2017-07-11T16:13:42  *** Murch has joined #bitcoin-core-dev
287 2017-07-11T16:13:45  <BlueMatt> yes, but the next pr is to remove it :p
288 2017-07-11T16:13:47  * morcos loves it when someone elses code gets made fun of  (ha ha, wow poor timeing to say that)
289 2017-07-11T16:13:58  <morcos> ok will look
290 2017-07-11T16:14:01  <BlueMatt> lol
291 2017-07-11T16:14:03  <wumpus> BlueMatt: lol, oops, that happens to me all the time
292 2017-07-11T16:14:16  <wumpus> spend optimizing or improving some part of the code, then it's no longer necessary :p
293 2017-07-11T16:15:31  <wumpus> re: #10712: src/wallet/wallet.cpp:2763:151: error: too few arguments to function call, expected 7, have 5
294 2017-07-11T16:15:31  <wumpus> CAmount fee_needed_for_change = GetMinimumFee(change_prototype_size, currentConfirmationTarget, ::mempool, ::feeEstimator, nullptr);
295 2017-07-11T16:15:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
296 2017-07-11T16:15:55  <BlueMatt> well, I'll lave 10235 with the fix for now, since it should be an easy merge
297 2017-07-11T16:16:06  <BlueMatt> and then it'll get removed in the next pr, which will need a whole review cycle
298 2017-07-11T16:17:11  <morcos> yeah conflict with my other PR you just merged but in a newly added line, will fix 10712
299 2017-07-11T16:18:38  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10795: No longer ever reuse keypool indexes (master...2017-07-wallet-keypool-overwrite) https://github.com/bitcoin/bitcoin/pull/10795
300 2017-07-11T16:41:48  *** vicenteH has quit IRC
301 2017-07-11T16:47:14  *** JackH has quit IRC
302 2017-07-11T16:50:54  *** vicenteH has joined #bitcoin-core-dev
303 2017-07-11T16:51:36  *** JackH has joined #bitcoin-core-dev
304 2017-07-11T16:57:27  *** JackH has quit IRC
305 2017-07-11T17:02:59  <sipa> these are some preliminary benchmarks for a reindex-chainstate up to height 450000 (before assumevalid, so no signature checking), with infinity dbcache, for various sha256 implementations:
306 2017-07-11T17:03:03  <sipa> bitcoind-rorx: 4835
307 2017-07-11T17:03:06  <sipa> bitcoind-shani: 4297
308 2017-07-11T17:03:08  <sipa> bitcoind-basic: 5134
309 2017-07-11T17:03:11  <sipa> bitcoind-sse: 4875
310 2017-07-11T17:04:00  <sipa> basic is master
311 2017-07-11T17:04:10  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca4c545cc7e8...e8b95239eeb0
312 2017-07-11T17:04:11  <bitcoin-git> bitcoin/master 253cd7e Alex Morcos: Only reserve key for scriptChange once in CreateTransaction...
313 2017-07-11T17:04:11  <bitcoin-git> bitcoin/master 0f402b9 Alex Morcos: Fix rare edge case of paying too many fees when transaction has no change....
314 2017-07-11T17:04:12  <bitcoin-git> bitcoin/master e8b9523 Wladimir J. van der Laan: Merge #10712: Add change output if necessary to reduce excess fee...
315 2017-07-11T17:04:22  <sipa> rorx and sse are from wumpus' work to include some asm optimized versions
316 2017-07-11T17:04:40  <bitcoin-git> [bitcoin] laanwj closed pull request #10712: Add change output if necessary to reduce excess fee (master...addchangehwenoverpaying) https://github.com/bitcoin/bitcoin/pull/10712
317 2017-07-11T17:04:47  <sipa> the shani version is using code from cryptopp
318 2017-07-11T17:06:00  *** chjj has joined #bitcoin-core-dev
319 2017-07-11T17:07:34  <BlueMatt> lol, Make Bitcoin CryptoPP Again
320 2017-07-11T17:08:14  <BlueMatt> thats a pretty impressive gain
321 2017-07-11T17:08:33  <sipa> unfortunately, very few systems right now have sha-ni instructions
322 2017-07-11T17:09:03  <BlueMatt> yes, but that should change over time
323 2017-07-11T17:09:10  <BlueMatt> the sha-ni in intel and amd are identical, no?
324 2017-07-11T17:09:34  <sipa> afaik, there is exists no "sha-ni in intel" yet :)
325 2017-07-11T17:10:34  <wumpus> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :)
326 2017-07-11T17:10:44  *** JackH has joined #bitcoin-core-dev
327 2017-07-11T17:11:07  <sipa> sse is present in nearly every x86_64 cpu, i think
328 2017-07-11T17:12:00  <wumpus> yes, sse is present in all of them
329 2017-07-11T17:12:41  <wumpus> even sse2 should be in all of them
330 2017-07-11T17:13:29  <BlueMatt> sipa: hmm? I was under the impression they had announced something like the next arch will get it
331 2017-07-11T17:13:31  <gmaxwell> sse2 is required by x86_64.
332 2017-07-11T17:13:34  <BlueMatt> no shipping ones, obviously
333 2017-07-11T17:14:14  <wumpus> those are not exactly new instructions though :) anyhow supporting shani as well is nice, just takes time and it will be in near everything...
334 2017-07-11T17:14:54  <gmaxwell> here is something funny: compilng bitcoin with -march=native makes the sha2 in C most of the speed of the sse one. (compiler manages to use rorx)
335 2017-07-11T17:15:32  <gmaxwell> Also the x86 simd support will make it easier to plug in arm versions; which will be more important for speed.
336 2017-07-11T17:15:56  <BlueMatt> wow, yay compiler smarts
337 2017-07-11T17:16:02  <gmaxwell> sipa: there is an intel chip with sha-ni, but it's some crappy atom processor.
338 2017-07-11T17:16:24  <BlueMatt> <wumpus> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :)
339 2017-07-11T17:16:27  <BlueMatt> heh, guess not, then
340 2017-07-11T17:17:23  <sipa> gmaxwell: compiling all of bitcoind with -march=native actually makes it overall another 100s faster to sync
341 2017-07-11T17:17:29  <gmaxwell> well aformentioned atom is some server atom that isn't very widely deployed from what I can tell.
342 2017-07-11T17:17:46  <BlueMatt> do you have lto benchmarks?
343 2017-07-11T17:17:52  <sipa> not yet, but i can create
344 2017-07-11T17:18:05  <wumpus> yes, march=native is nice, everyone compiling bitcoind locally should use it
345 2017-07-11T17:18:25  <gmaxwell> #9804 looks like a good change that is getting forgotten. (I say that as someone whos only concept acked so far...)
346 2017-07-11T17:18:27  <gribble> https://github.com/bitcoin/bitcoin/issues/9804 | Fixes subscript 0 ([0]) where should use (var.data()) instead. by JeremyRubin · Pull Request #9804 · bitcoin/bitcoin · GitHub
347 2017-07-11T17:18:56  <wumpus> with so many open PRs it's unavoidable that some things get forgotten, unfortunately
348 2017-07-11T17:19:08  <wumpus> but no, that one isn't
349 2017-07-11T17:19:49  <wumpus> I just referred people to review it today (because they opened a PR that was a strict subset of it)
350 2017-07-11T17:20:43  <sipa> wumpus: thanks for that, i had almost forgotten about jeremy's version
351 2017-07-11T17:30:31  <BlueMatt> lolwut
352 2017-07-11T17:30:39  <BlueMatt> ehh, wrong window
353 2017-07-11T17:31:44  <sipa> seems totally appropriate here
354 2017-07-11T17:32:05  <BlueMatt> ok, then I'll pretend I meant to
355 2017-07-11T17:33:09  *** vicenteH` has joined #bitcoin-core-dev
356 2017-07-11T17:34:57  *** vicenteH has quit IRC
357 2017-07-11T17:36:35  *** Dyaheon has quit IRC
358 2017-07-11T17:37:54  *** timothy has quit IRC
359 2017-07-11T17:38:26  *** Dyaheon has joined #bitcoin-core-dev
360 2017-07-11T17:46:08  *** vicenteH` has quit IRC
361 2017-07-11T17:47:57  *** RoyceX has quit IRC
362 2017-07-11T17:58:27  <sipa> running benchmarks for lto and shani+lto as well now
363 2017-07-11T17:58:39  <sipa> will have numbers in a day...
364 2017-07-11T17:59:22  *** riemann has joined #bitcoin-core-dev
365 2017-07-11T17:59:33  <sipa> interestingly, the shani+lto does not even contain any non-shani sha code, even though it's dispatched to a modifiable pointer
366 2017-07-11T17:59:39  <BlueMatt> heh
367 2017-07-11T17:59:43  <BlueMatt> oh nice
368 2017-07-11T17:59:48  <sipa> the compiler must notice there are no assignments to that pointer, and treats it as a constant
369 2017-07-11T18:00:05  <BlueMatt> yea, lto can be clever sometimes
370 2017-07-11T18:01:57  *** chjj has quit IRC
371 2017-07-11T18:08:36  <gmaxwell> if compiler versions are still keeping up from ltoing by default perhaps we could add a --gofast configure flag to do -march=native -O3 -lto
372 2017-07-11T18:09:05  <BlueMatt> is O3 a win in bitcoin?
373 2017-07-11T18:09:39  <sipa> i guess i'll benchmark that too :)
374 2017-07-11T18:09:54  <BlueMatt> heh
375 2017-07-11T18:13:50  <wumpus> I don't see why something as basic as that would need a configure fla
376 2017-07-11T18:14:00  <wumpus> people that want to supply their own CXXFLAGS can do so already
377 2017-07-11T18:14:30  <wumpus> could just mention it in the build document
378 2017-07-11T18:14:55  <wumpus> a dedicated configure flag only makes sense if we use something for the gitian build, so people can do their own build with the same settings
379 2017-07-11T18:15:08  <gmaxwell> wumpus: fair enough
380 2017-07-11T18:15:23  <wumpus> but using -march=native would be a bad idea there, -flto might be a good one
381 2017-07-11T18:15:51  <BlueMatt> yea, flto could use its own configure flat...doing it manually is like 6 variables long
382 2017-07-11T18:17:39  <gmaxwell> well I think we should lto by default, but there was still some question of compiler support. (which I think was mooted by C++11, but perhaps I'm wrong, since we still haven't done it.)
383 2017-07-11T18:18:42  <wumpus> I'm not convinced anything but -O2 optimization should be default
384 2017-07-11T18:19:13  <gmaxwell> wumpus: why shouldn't it be lto-ing by default?
385 2017-07-11T18:19:16  <wumpus> cfields might have more of an opinion, but in my experience buildling open source software for lots of platforms, I've had lots of annoyances with software that tried to forcibly injects certain sets of optimizations flags
386 2017-07-11T18:19:33  <wumpus> it should be left up to the distribution ideally to set optimization flags
387 2017-07-11T18:19:36  <BlueMatt> gmaxwell: lto does not work on moderately-recent compilers
388 2017-07-11T18:19:43  <wumpus> well even if it did
389 2017-07-11T18:19:48  <BlueMatt> eg debian jessie
390 2017-07-11T18:19:57  <sipa> works fine here, and for release builds we control the environment entirely anyway
391 2017-07-11T18:20:05  <BlueMatt> well, i guess 4.9 isnt moderately-recent
392 2017-07-11T18:20:06  <wumpus> yes, for release builds flto would be good
393 2017-07-11T18:20:11  <BlueMatt> anyway, we support it, and lto doesnt work on it
394 2017-07-11T18:20:13  <cfields> wumpus: agreed. "-02 -g" is expected to be the default, I get really irritated when that's not the case
395 2017-07-11T18:20:20  <wumpus> cfields: exactly
396 2017-07-11T18:20:35  <sipa> benchmarking reindex with "-O2", "-O3", "-flto -O2",  and "-flto -O3"
397 2017-07-11T18:20:39  <BlueMatt> nice
398 2017-07-11T18:21:12  <wumpus> don't get me wrong, flto would be great for gitian builds, and we could have a configure option for that, but adding non-standard optimization flags by default on configure tends to be really annoying in edge cases
399 2017-07-11T18:21:50  <sipa> cfields was concerned about having release builds deviate too much from developers-tested builds
400 2017-07-11T18:21:52  <cfields> I get the impression i should go ahead and wire up --enable-lto before someone sneaks in something unexpected :)
401 2017-07-11T18:22:05  <gmaxwell> BlueMatt: I do not believe that LTO fails to work on anything that can compile Bitcoin Core.   It's been supported since GCC 4.7
402 2017-07-11T18:22:19  <wumpus> if you want to encourage people to build with optimization flags then just document it in e.g. build-unix.md
403 2017-07-11T18:22:24  <wumpus> don't do anything sneaky
404 2017-07-11T18:22:35  <gmaxwell> Our cflags are far from -O2 -g, though, we add about two dozen warning flags.
405 2017-07-11T18:22:46  <wumpus> warning flags don't do aything funny to the code
406 2017-07-11T18:22:56  <cfields> sipa: i think an --enable-lto alleviates that somewhat, since it makes it easy for devs to get the same results
407 2017-07-11T18:23:04  <BlueMatt> gmaxwell: I dunno, I've been building on lto for a long time and every debian jessie server I've ever installed has always failed to build lto
408 2017-07-11T18:23:17  <sipa> BlueMatt: due to some boost interaction, right?
409 2017-07-11T18:23:19  <BlueMatt> its an easy fix - just recompile util.cpp without lto and then it works, but its broken
410 2017-07-11T18:23:27  <BlueMatt> sipa: its not boost-specific, but thats where it fails
411 2017-07-11T18:23:37  <BlueMatt> it appears to be some general issue with destructors defined in headers
412 2017-07-11T18:23:40  <cfields> sipa: iirc i hit a boost::filesystem problem last i tried
413 2017-07-11T18:23:48  <gmaxwell> BlueMatt: good datapoint then.
414 2017-07-11T18:23:52  <BlueMatt> I've seen it fail on other things, but normally the thing you see is ~boost::filesystem()
415 2017-07-11T18:23:59  <cfields> but i assumed it was local
416 2017-07-11T18:24:01  <BlueMatt> ehh, sorry, not filesystem
417 2017-07-11T18:24:06  <BlueMatt> some boost::filesystem path ~ thing
418 2017-07-11T18:25:19  <cfields> sipa: ooh i know, we can wire it up with depends builds
419 2017-07-11T18:25:40  <BlueMatt> cfields: didnt you tell me you were gonna wire up a "trusting-trust" gcc build in depends for 15? :P
420 2017-07-11T18:25:44  <BlueMatt> I still dont see a PR
421 2017-07-11T18:26:11  <cfields> that way anyone using depends gets lto by default, and we also know what dep versions we're dealing with
422 2017-07-11T18:26:20  <wumpus> our good friend ubuntu trusty has gcc 4.8.4, hopefully that can do flto without probems (especially worried about windows! but we'll see)
423 2017-07-11T18:26:34  <cfields> BlueMatt: i don't think it's going to make it :(
424 2017-07-11T18:26:37  <BlueMatt> wumpus: I'd be kinda surprised if it did
425 2017-07-11T18:26:51  <BlueMatt> cfields: what? by this coming sunday? yea, somehow i doubt it
426 2017-07-11T18:27:11  <wumpus> can someone please just try instead of guess :-)
427 2017-07-11T18:27:25  <BlueMatt> +1
428 2017-07-11T18:27:28  <BlueMatt> go cfields, go
429 2017-07-11T18:27:39  <wumpus> I can do it, np, but thought cfields was going to
430 2017-07-11T18:28:33  <cfields> add lto to configure (and see if it works) ?
431 2017-07-11T18:28:58  <wumpus> cfields: yes, doing a gitian build with lto (for all platforms)
432 2017-07-11T18:29:11  <BlueMatt> oh, i thought we were talking about a "trusting trust" copy of gcc
433 2017-07-11T18:29:11  <wumpus> then seeing where/if the result crashes
434 2017-07-11T18:29:12  <cfields> sure, i can do that
435 2017-07-11T18:29:18  <BlueMatt> yea, ok, adding lto is much easier, that could make it
436 2017-07-11T18:29:47  <wumpus> BlueMatt: I thoughtwe were talking about optimizations
437 2017-07-11T18:29:59  * wumpus confused
438 2017-07-11T18:30:09  *** dermoth has quit IRC
439 2017-07-11T18:30:26  <cfields> adding lto to configure now, then seeing where it works.
440 2017-07-11T18:32:06  *** dermoth has joined #bitcoin-core-dev
441 2017-07-11T18:32:47  <wumpus> cool
442 2017-07-11T18:34:24  *** cluelessperson has joined #bitcoin-core-dev
443 2017-07-11T18:34:54  <cluelessperson> Hey guys, I'm looking at buying some new server hardware.
444 2017-07-11T18:34:56  <cluelessperson> https://www.asus.com/us/Commercial-Servers-Workstations/RS100-E9-PI2/specifications/
445 2017-07-11T18:35:18  <cluelessperson> is currently on my plate, but I was wondering if you might suggest something else that might be more beneficial towards bitcoin development, testing/QA?
446 2017-07-11T18:38:10  <wumpus> this really isn't the channel for server hw suggestions
447 2017-07-11T18:38:16  <midnightmagic> I sent him here.
448 2017-07-11T18:39:08  <BlueMatt> cluelessperson: anything with fast disk and lots of memory
449 2017-07-11T18:39:12  <BlueMatt> otherwise, O/T
450 2017-07-11T18:40:02  <cluelessperson> BlueMatt: I could do PCI-SSD, but what type of ram requirements are we talking?
451 2017-07-11T18:40:13  <midnightmagic> -- since he was hoping to help in some capacity with the development itself, and I know occasionally guidance in terms of e.g. differing hardware or stuff that would be more helpful than generic hardware is sometimes in demand.
452 2017-07-11T18:40:24  <BlueMatt> ok, no big deal, lets move to #bitcoin
453 2017-07-11T18:43:20  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #8369: [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" (master...2016/07/wallet_features) https://github.com/bitcoin/bitcoin/pull/8369
454 2017-07-11T18:48:05  *** Guest23212 has quit IRC
455 2017-07-11T18:51:34  *** Guest89066 has joined #bitcoin-core-dev
456 2017-07-11T18:55:37  *** chjj has joined #bitcoin-core-dev
457 2017-07-11T19:00:06  <morcos> ryanofsky: #10244 is marked high-priority, but seems to me from reading the conversation that although it is now concept acked it's targeted for post-0.15?
458 2017-07-11T19:00:08  <gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
459 2017-07-11T19:00:30  <morcos> just want to direct my review appropriately with 0.15 coming up
460 2017-07-11T19:00:56  *** Chris_Stewart_5 has quit IRC
461 2017-07-11T19:01:54  <jonasschnelli> morcos: Yes. Agree. 10244 should probably removed until there is conceptual consensus (not cleat to me if we have that or not, which probably means we have not :) )
462 2017-07-11T19:02:19  <ryanofsky> i thought i had two concept acks
463 2017-07-11T19:02:28  <jonasschnelli> Oh. Yes. Right..
464 2017-07-11T19:02:47  <ryanofsky> but it's not intended for 15. maybe search for milestone:0.15.0
465 2017-07-11T19:02:53  <jonasschnelli> I take back my last comment then...
466 2017-07-11T19:04:21  <jonasschnelli> I think for 10244, it makes sense to rebase it after 0.15 has been split off and concentrate review (and hope for a merge)
467 2017-07-11T19:04:35  <jonasschnelli> It's a large PR though
468 2017-07-11T19:04:43  <jonasschnelli> +2,262 −1,152
469 2017-07-11T19:04:59  <ryanofsky> it's pretty much a mechanical change
470 2017-07-11T19:06:36  <wumpus> agreed
471 2017-07-11T19:06:50  <wumpus> it's not an end-user visible change, we should prioritize those for 0.15
472 2017-07-11T19:07:11  <wumpus> all the code cleanups pure refactorings can wait for 0.16
473 2017-07-11T19:11:11  <morcos> ok, i was viewing high priority as a subset of milestone:0.15, but perhaps that isn't correct
474 2017-07-11T19:12:37  <jonasschnelli> wumpus, ryanofsky: Argee about it beeing mechanical, though it still require line by line review by at least 2-3 guys.
475 2017-07-11T19:12:42  <wumpus> well maybe it is now, but in general it's just something that people can request review if it blocks future PRs from themselves
476 2017-07-11T19:12:58  <wumpus> but I agree ahving something high-prio that won't make 0.15 anyway is a bad idea
477 2017-07-11T19:13:05  <wumpus> right now
478 2017-07-11T19:13:21  <jonasschnelli> Yes. I had the same feeling. High-Prio in context of holding back the individual developer / focus of the individual developer.
479 2017-07-11T19:14:46  <jonasschnelli> About sipa's ser. changes (#10785), is it worth to benchmark the differences or do we expect non to little impact on performance?
480 2017-07-11T19:14:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa · Pull Request #10785 · bitcoin/bitcoin · GitHub
481 2017-07-11T19:15:11  <jonasschnelli> (otherwise I can add a bench-package for the serialization code
482 2017-07-11T19:15:13  <jonasschnelli> )
483 2017-07-11T19:17:58  <jonasschnelli> ryanofsky about the CAuxiliaryRequest, where do you think we have duplicated code? Also, what do you think about the points I wrote (https://github.com/bitcoin/bitcoin/pull/10794#issuecomment-314534086)?
484 2017-07-11T19:18:49  <jonasschnelli> (maybe its better to discuss some thing here instead of have to much discussion on the PR before we actually get reviews)
485 2017-07-11T19:18:54  <jonasschnelli> things*
486 2017-07-11T19:19:10  <sipa> jonasschnelli: i expect 0 impact on performance
487 2017-07-11T19:19:28  <jonasschnelli> sipa: Okay. Then it's probably not worth...
488 2017-07-11T19:19:29  <ryanofsky> it's been months since i've looked at it but, i remember duplicated logic in the aux request class & normal network download code
489 2017-07-11T19:20:37  <jonasschnelli> ryanofsky: I can't see any real duplication, maybe some lines that take care of passing to the instance and for the callback approach...
490 2017-07-11T19:20:53  <ryanofsky> i'm looking up my old comments
491 2017-07-11T19:21:42  <jonasschnelli> Great. Thanks..
492 2017-07-11T19:22:23  <sipa> jonasschnelli: it could be considered a bugfix though (but almost certainly not one that matters)
493 2017-07-11T19:22:53  <ryanofsky> here is the comment where i point out the duplication: https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677
494 2017-07-11T19:22:57  <jonasschnelli> sipa: you mean the "cast ways the const"?
495 2017-07-11T19:23:05  <jonasschnelli> "cast away"
496 2017-07-11T19:24:06  <ryanofsky> jonasschnelli, my broader point is that i would like you to get some concept ack on your networking design from some other developers who know more about the networking code than me, before i spend more time reviewing it
497 2017-07-11T19:24:30  <jonasschnelli> ryanofsky: Yes. Sure. That makes sense.
498 2017-07-11T19:25:04  *** chjj has quit IRC
499 2017-07-11T19:25:36  <jonasschnelli> About your comment, I saw that and I think its then not about duplication, it's a slightly different approach (which seems also to make sense).
500 2017-07-11T19:26:04  <jonasschnelli> I just like the have-its-own file approach for the reasons I wrote.. but lets get other opinions
501 2017-07-11T19:26:32  <ryanofsky> fillInNextBlocks is duplicative of FindNextBlocksToDownload, processWithPossibleBlock is duplicative of ProcessNewBlock was my point
502 2017-07-11T19:27:25  <ryanofsky> i don't think you are going to convince me that having two different control flows for regular downloads vs priority downloads is the way to go, but you don't have to convince me. i'm happy to accept that if others think it is a good idea
503 2017-07-11T19:27:43  <jonasschnelli> ryanofsky: I don't think its duplicative, if we would eliminate the class, that logic has just to move into net_processing.cpp/validation.cpp
504 2017-07-11T19:28:01  *** AaronvanW has joined #bitcoin-core-dev
505 2017-07-11T19:28:09  <gmaxwell> ryanofsky: I think others do not think it's a good idea, and already raised the concern.
506 2017-07-11T19:28:17  <ryanofsky> iirc, more logic could be shared if they were in the same place
507 2017-07-11T19:28:31  <gmaxwell> When that code was first implemented; ... made sense to do for a demo or whatnot.
508 2017-07-11T19:28:45  *** ivan_ has joined #bitcoin-core-dev
509 2017-07-11T19:28:47  <sipa> just have a means to tell the network layer "i need block X, and here is callback for when you have it"
510 2017-07-11T19:29:37  <jonasschnelli> Okay. But the network layer hasn't to be stuffed into a single file/class?
511 2017-07-11T19:29:38  <ryanofsky> sipa, yes that is what i requested. i think the auxilliary class is too low level
512 2017-07-11T19:30:22  <jonasschnelli> But if the general opinion goes direction of having the logic in net_processing.cpp directly, then I'm fine with moving it there...
513 2017-07-11T19:30:23  <sipa> jonasschnelli: net_processing is already a single file
514 2017-07-11T19:30:26  <ryanofsky> jonasschnelli, i think agree networking code is monolithic. but that you have to find the right way to break it up and this does not seem like the right way
515 2017-07-11T19:31:09  <jonasschnelli> sipa: Yes. And I think having specialized functions (like the light client block rquests) in dedicated files makes sense.. rebasing, patches, code-overview
516 2017-07-11T19:32:15  <sipa> jonasschnelli: i really don't think block fetching code should be in more than 1 place
517 2017-07-11T19:32:35  <gmaxwell> we have a hard enough time keeping the two existing block requesting state machine functioning and maintained... really pretty ugly to add another seperate one for the wallet in another place.
518 2017-07-11T19:32:43  <sipa> it's arguably already too spread out in net_processing (dealing with invs, direct fetching, headers fetching, async fetching ...)
519 2017-07-11T19:32:53  <jonasschnelli> sipa: it's not fetching,.. is an object that hold information about what it should fetch and if it's done or not and eventuall the process flow
520 2017-07-11T19:33:10  <sipa> jonasschnelli: yes, that's probably how all the fetching code should work
521 2017-07-11T19:33:32  <sipa> keep information on what blocks are to be downloaded
522 2017-07-11T19:34:08  <jonasschnelli> ryanofsky gmaxwell: I think the out-of-band (auxiliary) requests need state, and therefore a class makes sense (when was the request initiated, how much is done, etc.) would you add that class into net_processing rathern then creating a new file?
523 2017-07-11T19:34:23  <ryanofsky> i think if you wanted to move code *out* of net_processing into your new download implementation, that would be nice. but just adding the new download implementation alongside does not seem seem so nice
524 2017-07-11T19:34:32  <gmaxwell> jonasschnelli: all block requests need state.
525 2017-07-11T19:34:51  <gmaxwell> jonasschnelli: we have to track what we've asked for, what we need, whats been recieved... and so on.
526 2017-07-11T19:34:55  <jonasschnelli> gmaxwell: yes. But here it is a user-requested range
527 2017-07-11T19:35:10  <sipa> jonasschnelli: in the current case, the user is the block validation logic
528 2017-07-11T19:35:19  <sipa> you just want to add another user
529 2017-07-11T19:35:26  <gmaxwell> ^
530 2017-07-11T19:35:41  <jonasschnelli> sipa: can't follow the "user is the block validation logic" :/
531 2017-07-11T19:35:42  <ryanofsky> to make discussion more concrete, what do you think of my blocksToDownloadFirst suggestion?
532 2017-07-11T19:36:38  <jonasschnelli> ryanofsky: Yes. Make sense. But still, the requester (assume wallet) will need to blocks in a clear sequence (assume A, B, C, D and not C, D, A, B).
533 2017-07-11T19:37:20  <jonasschnelli> Therefore there must be something that takes care of the state of a wallet/user initiated out-of-band block request and make sure, it will be passed in in sequence
534 2017-07-11T19:38:22  <jonasschnelli> IMO its about "requesting n amount of "range of blocks" rather then just requesting blocks
535 2017-07-11T19:40:12  <gmaxwell> jonasschnelli: right now the consensus logic requests the block download machinery to download blocks, keep track of the requests and what not.
536 2017-07-11T19:40:16  <ryanofsky> i'm not sure i see the problem. that state could be tracked inside the wallet. wallet just needs to request blocks, get notifications when they come in, then request more blocks
537 2017-07-11T19:40:29  <gmaxwell> jonasschnelli: sipa is pointing out that what you're doing is just adding an addition set of callers.
538 2017-07-11T19:40:59  <gmaxwell> jonasschnelli: why does the wallet need blocks in order?
539 2017-07-11T19:42:02  <jonasschnelli> gmaxwell: if we assume the wallet does show to the user what it had processed it would probably look strange if the wallet would update the balance, tx-list of block that come in out of order
540 2017-07-11T19:42:38  <jonasschnelli> Also, detecting re-orgs would be difficult?
541 2017-07-11T19:42:40  <ryanofsky> can't wallet keep track of it's own requests and ignore anything it wants to ignore?
542 2017-07-11T19:43:13  <gmaxwell> if the wallet is just saying how far it had processed, couldn't it just show the minimum height processed so far?  showing things out of order would certantly allow things faster.
543 2017-07-11T19:43:16  <jonasschnelli> ryanofsky: Yes. If we assume only wallets want that. What about the other user cases, ZMQ, light-client "middleware" (Oh I had this term)
544 2017-07-11T19:44:53  <ryanofsky> jonasschnelli, that's why i was asking for some kind of design doc, going into the what specifically you envision there
545 2017-07-11T19:45:17  <jonasschnelli> gmaxwell: hmm.. I guess the user would look at the transaction list and see a possible incoming transaction while a older expected incoming transaction is missing, regardless of how the wallet communicates "minimum process height"
546 2017-07-11T19:45:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
547 2017-07-11T19:45:49  <sipa> jonasschnelli: right now, the only thing that "needs" blocks is the block validation
548 2017-07-11T19:45:59  <sipa> you're adding something else that needs blocks
549 2017-07-11T19:46:05  <jonasschnelli> ryanofsky: Not only, #10794 is purely RPC/ZMQ
550 2017-07-11T19:46:06  <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
551 2017-07-11T19:46:12  <sipa> both of them should be seen as users of the block fetching logic
552 2017-07-11T19:46:24  <jonasschnelli> sipa: Ah. I understand now
553 2017-07-11T19:48:02  *** chjj has joined #bitcoin-core-dev
554 2017-07-11T19:48:24  <jonasschnelli> sipa, ryanofsky: The idea in 10794 is to have the validation triggered download logic in tact (minimal impact) while preferring out-of-band requests. And I tried to keep the logic, state-machine outside of net_processing.cpp to allow later code splits
555 2017-07-11T19:49:11  <sipa> i think that's the wrong approach (though admittedly i haven't reviewed the code)
556 2017-07-11T19:49:28  <jonasschnelli> (It's good you haven't so I can change it before you do. :) )
557 2017-07-11T19:49:49  <jonasschnelli> sipa: what would you prefer then?
558 2017-07-11T19:49:54  <sipa> jonasschnelli: as i explained
559 2017-07-11T19:50:13  <sipa> refactor the current block downloading logic to support multiple users
560 2017-07-11T19:50:24  <sipa> make it keep track of what blocks to download
561 2017-07-11T19:50:43  <sipa> and what to do when they arrive
562 2017-07-11T19:50:44  <jonasschnelli> sipa: I thought you are going to say that... I just think this is way larger but probably cleaner
563 2017-07-11T19:50:56  <sipa> it's much more refactoring, yes
564 2017-07-11T19:51:05  <sipa> but it'll be tiny to add light client fetching on top :)
565 2017-07-11T19:51:28  <jonasschnelli> heh.. Yes. After that one or two year for the block download refactoring.. :)
566 2017-07-11T19:52:47  <ryanofsky> am i missing something? https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677 seems pretty straightforward and not a large amount of refactoring
567 2017-07-11T19:53:02  <jonasschnelli> I guess I focus to much on the minimal.impact solution rather then on the clean solution because I'm too much feature driven
568 2017-07-11T19:53:54  *** vicenteH has joined #bitcoin-core-dev
569 2017-07-11T19:54:22  <jonasschnelli> ryanofsky: Not sure if the idea in that comment fulfils sipa idea of having "multiple users for the download logic"
570 2017-07-11T19:55:30  <morcos> sipa: i also like that idea, but i wonder if there is a priority difference there...  like how quickly you time out, or find someone else to deliver or penalize for bad behavior or etc...
571 2017-07-11T19:55:45  <ryanofsky> because blocksToDownloadFirst is not sufficient for multiple users?
572 2017-07-11T19:55:55  <morcos> who me?
573 2017-07-11T19:56:03  <morcos> oh him
574 2017-07-11T19:58:06  <jonasschnelli> ryanofsky: No I think because we would only partially (out of band request) allow multiple users for the block download. But not exactly sure to what extend sipas solution should go to
575 2017-07-11T19:58:23  <ryanofsky> oh i think i see the difference. sipa's idea is to keep track of blocks to download and "what to do when they arrive". my idea would just do the first and let client figure out what to do when blocks come
576 2017-07-11T19:58:25  <sipa> what do you mean with 'out of band' ?
577 2017-07-11T19:59:19  <jonasschnelli> sipa: out-of-band is a poor multi-user approach for block download (the in-band is validation, the rest is out-of-band)
578 2017-07-11T19:59:46  <sipa> i don't understand what you mean with 'out of band' in this context
579 2017-07-11T19:59:55  <jonasschnelli> sipa: i guess what you meant is that the validation part uses the same block download interface then the light-client wallet? right?
580 2017-07-11T20:00:16  <sipa> yes
581 2017-07-11T20:01:03  <jonasschnelli> sipa: the validation requests block after it's own logic (not to far away, etc.), out-of-band requests can request a range of blocks that make no sense for the validation (in terms of time prioritation)
582 2017-07-11T20:01:51  <jonasschnelli> sipa: I guess ryanofsky terms `blocksToDownloadFirst` is much better
583 2017-07-11T20:01:52  <sipa> i still don't understand what you mean with out of band
584 2017-07-11T20:02:31  <sipa> there are blocks to download, there is logic to determine which ones to download in what order, they're processed when they arrive
585 2017-07-11T20:02:40  <jonasschnelli> I think i should call it "priorizedBlockRequests"
586 2017-07-11T20:03:38  <jonasschnelli> sipa: Yes. But the light client (wallet) wants to break that oder by a) preferring other blocks first, b) pass them through BlockConnected() before they are connected to the tip
587 2017-07-11T20:04:05  <jonasschnelli> (connected to the tip == validated, not connected == spv)
588 2017-07-11T20:05:43  <sipa> sure
589 2017-07-11T20:05:45  <jonasschnelli> ryanofsky: I think sipa's idea makes sense in the long run (don't distinct between wallet spv block requests and the validation triggered block request), ideally the validation would then use the same interface then the (light-client) wallet would use
590 2017-07-11T20:06:09  <jonasschnelli> but this would be a lot of work
591 2017-07-11T20:06:41  <sipa> sure, not everything has to happen in one go
592 2017-07-11T20:06:47  <ryanofsky> yeah, i get that now. i think that refactoring is basically orthogonal though
593 2017-07-11T20:07:06  <jonasschnelli> I agree...
594 2017-07-11T20:07:07  <ryanofsky> you could do that refactoring with or without prioritized downloads, or vice versa
595 2017-07-11T20:07:24  <sipa> ryanofsky: agree
596 2017-07-11T20:07:36  <jonasschnelli> I even think implementing the prioritized downloads gives a better feeling on how-to-refactor
597 2017-07-11T20:07:53  <jonasschnelli> because you refactor with a clear interface use-case
598 2017-07-11T20:08:08  <sipa> yes, fair enough
599 2017-07-11T20:08:53  <jonasschnelli> But I'm still not sure if it makes then sense to implement it within net_processing or leave it in a designated file (not very different IMO)
600 2017-07-11T20:09:13  <jonasschnelli> Probably most devs things within net_processing.cpp makes more sense...
601 2017-07-11T20:09:17  <jonasschnelli> *think
602 2017-07-11T20:09:44  <jonasschnelli> Then let me do that and let me rename it from auxiliary (out-of-band) to prioritizedBlockRequests
603 2017-07-11T20:14:26  *** AaronvanW has quit IRC
604 2017-07-11T20:15:01  *** AaronvanW has joined #bitcoin-core-dev
605 2017-07-11T20:19:06  *** jamesob_ has joined #bitcoin-core-dev
606 2017-07-11T20:19:19  *** AaronvanW has quit IRC
607 2017-07-11T20:21:28  *** jamesob has quit IRC
608 2017-07-11T20:25:17  *** abpa has joined #bitcoin-core-dev
609 2017-07-11T20:25:42  *** ybit2 is now known as ybit
610 2017-07-11T20:31:55  <cfields> ok, i managed to patch boost and fix the lto linking error...
611 2017-07-11T20:32:23  <cfields> anyone feel like looking at a head-scratcher?
612 2017-07-11T20:32:38  <BlueMatt> really? I failed to do so previously
613 2017-07-11T20:32:41  * BlueMatt is curious
614 2017-07-11T20:33:24  <cfields> BlueMatt: was this your problem as well? https://pastebin.com/raw/kmqJVmfq
615 2017-07-11T20:33:45  <BlueMatt> oh, no
616 2017-07-11T20:34:01  <cfields> oh. what's yours?
617 2017-07-11T20:34:03  <BlueMatt> i always got a link-time "~boost::filesystem::path() undefined" error
618 2017-07-11T20:34:23  <BlueMatt> and occasionally for other destructors that were implicitly-defined in headers or explicitly defined in headers
619 2017-07-11T20:34:31  <cfields> oh, same thing
620 2017-07-11T20:34:40  <cfields> ZN5boost10filesystem4pathD1Ev is mangled destructor
621 2017-07-11T20:35:14  <cfields> right, so the fix was to give it an explicit destructor in the .cpp
622 2017-07-11T20:35:18  <BlueMatt> heh, your linker has garbage error messages
623 2017-07-11T20:35:30  <BlueMatt> yes, but boost::filesystem::path has no .cpp
624 2017-07-11T20:35:31  <cfields> but i'm not understanding why
625 2017-07-11T20:35:33  <BlueMatt> or, i dont recall one
626 2017-07-11T20:35:36  <BlueMatt> oh, i have no idea why
627 2017-07-11T20:35:38  <cfields> it does
628 2017-07-11T20:35:42  <BlueMatt> oh, ok
629 2017-07-11T20:35:44  <sipa> BlueMatt: go test cfields's fix :p
630 2017-07-11T20:36:03  <cfields> heh, I'll PR as soon as I can understand why it's a fix :)
631 2017-07-11T20:36:16  <BlueMatt> and it mostly only happens to that one place, not on other destructors-defined-in-headers
632 2017-07-11T20:36:25  <BlueMatt> but i have seen it on others before
633 2017-07-11T20:36:30  <cfields> BlueMatt: right, there's a particular reason for these, sec
634 2017-07-11T20:36:54  <sipa> there are fairly complicated rules in C++ about which object the implementation of some implicit methods goes into
635 2017-07-11T20:37:11  <cfields> https://github.com/boostorg/filesystem/blob/develop/src/path.cpp#L703
636 2017-07-11T20:37:33  <cfields> they're static vars there
637 2017-07-11T20:38:20  <cfields> (and statics for each of the failures in the link)
638 2017-07-11T20:38:27  <BlueMatt> ah, is that why? static objects with implicitly-defined destructors?
639 2017-07-11T20:39:18  <cfields> so my best guess is... the static vars are created there when the lib is built, so an entry for the dtor is added. But we never use those functions...
640 2017-07-11T20:39:56  <cfields> so i think it's either: a gcc/lto bug, or some crazy ODR-like issue
641 2017-07-11T20:40:37  <cfields> oh, also, we build with fvisibility=hidden. when that's off for boost _and_ our build, it links fine
642 2017-07-11T20:41:08  *** Dyaheon has quit IRC
643 2017-07-11T20:41:55  <BlueMatt> lol
644 2017-07-11T20:43:35  *** Dyaheon has joined #bitcoin-core-dev
645 2017-07-11T20:56:16  *** AaronvanW has joined #bitcoin-core-dev
646 2017-07-11T20:56:17  *** dermoth has quit IRC
647 2017-07-11T20:58:38  *** dermoth has joined #bitcoin-core-dev
648 2017-07-11T21:01:21  *** jamesob has joined #bitcoin-core-dev
649 2017-07-11T21:03:17  *** jamesob_ has quit IRC
650 2017-07-11T21:04:39  *** cheese_ has joined #bitcoin-core-dev
651 2017-07-11T21:16:34  <gmaxwell> Did Paul Sztorc talk to anyone here before publishing his thing? (except luke-jr) I want to remark on his "
652 2017-07-11T21:16:58  <gmaxwell> I wrote the roadmap to try to be representative of a Core / developer position." -- that if so he might have wanted to talk to some of the more frequent ones, it doesn't appear that he did.
653 2017-07-11T21:17:09  <gmaxwell> But I want a fact-check before saying htat.
654 2017-07-11T21:17:14  <gmaxwell> s/htat/that/
655 2017-07-11T21:17:22  <BlueMatt> i havent heard from him
656 2017-07-11T21:17:37  <BlueMatt> (nor speak to him specifically about that issue at any point i can recall)
657 2017-07-11T21:21:33  *** abpa has quit IRC
658 2017-07-11T21:26:48  *** Chris_Stewart_5 has quit IRC
659 2017-07-11T21:32:59  *** JackH has quit IRC
660 2017-07-11T21:33:05  *** dermoth has quit IRC
661 2017-07-11T21:34:07  *** dermoth has joined #bitcoin-core-dev
662 2017-07-11T21:43:57  *** timothy has joined #bitcoin-core-dev
663 2017-07-11T21:48:34  *** PRab has quit IRC
664 2017-07-11T21:49:37  *** dermoth has quit IRC
665 2017-07-11T21:50:16  <jtimon> images... https://github.com/bitcoin/bitcoin/pull/10757#issuecomment-314581913
666 2017-07-11T21:51:11  *** dermoth has joined #bitcoin-core-dev
667 2017-07-11T21:53:12  <luke-jr> wumpus: https://github.com/UASF/bitcoin/releases/tag/v0.14.2-uasfsegwit1.0
668 2017-07-11T22:11:31  *** cheese_ has quit IRC
669 2017-07-11T22:15:10  *** cheese_ has joined #bitcoin-core-dev
670 2017-07-11T22:16:59  *** Victor_sueca has joined #bitcoin-core-dev
671 2017-07-11T22:20:06  *** Victorsueca has quit IRC
672 2017-07-11T22:20:58  *** jouke has quit IRC
673 2017-07-11T22:22:37  *** jouke has joined #bitcoin-core-dev
674 2017-07-11T22:22:37  *** jouke has quit IRC
675 2017-07-11T22:22:37  *** jouke has joined #bitcoin-core-dev
676 2017-07-11T22:25:28  <cfields> sipa: aha, you were right
677 2017-07-11T22:27:03  <cfields> i traced the symbol references in linker dumps. as-is, with lto, the destructor gets stuffed into util.o (because it's one of the files where there's a static reference)
678 2017-07-11T22:27:50  <cfields> but when i comment out the static references in util.cpp, it links fine, and the destructor goes into a boost object (operations.o)
679 2017-07-11T22:28:40  <cfields> IIRC when it's ambiguous, the linker is free to choose where to put the symbol, as long as it's just added to one object
680 2017-07-11T22:29:38  <cfields> but with lto, it gets put into util.o. then, the link-order causes boost_filesystem to be unable to find it
681 2017-07-11T22:29:47  <sipa> cfields: so, you fixed it?
682 2017-07-11T22:30:06  <cfields> i believe so
683 2017-07-11T22:30:43  *** promag has joined #bitcoin-core-dev
684 2017-07-11T22:30:53  <cfields> 2 fixes: 1 quick hack to use a static string rather than a fs::path, to avoid the issue entirely. 2. the upstream boost fix
685 2017-07-11T22:31:26  <promag> jtimon: please rename #10757
686 2017-07-11T22:31:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
687 2017-07-11T22:35:58  <jtimon> oh, right, I did s/getperblockstats/getblockstats/ as you suggested...thanks!
688 2017-07-11T22:36:16  <bitcoin-git> [bitcoin] jnewbery opened pull request #10798: test bitcoin-cli (master...cli_tests) https://github.com/bitcoin/bitcoin/pull/10798
689 2017-07-11T22:43:40  *** Dizzle has quit IRC
690 2017-07-11T22:47:38  *** Dyaheon has quit IRC
691 2017-07-11T22:47:38  *** riemann has quit IRC
692 2017-07-11T22:49:13  *** Dyaheon has joined #bitcoin-core-dev
693 2017-07-11T22:55:10  <cluelessperson> BlueMatt: So I'm looking at a 3.8ghz Xeon Quad Core,  256 GB PCI SSD 3200MBps Read, 1500MBps Write,   64 GB RAM DDR4, thoughts?
694 2017-07-11T22:55:17  <cluelessperson> $1400
695 2017-07-11T22:55:22  <cluelessperson> (rounded up)
696 2017-07-11T22:55:43  <BlueMatt> -> #bitcoin
697 2017-07-11T22:59:18  *** Aaronvan_ has joined #bitcoin-core-dev
698 2017-07-11T23:00:08  *** spinza has quit IRC
699 2017-07-11T23:00:20  *** Guyver2 has quit IRC
700 2017-07-11T23:01:16  *** AaronvanW has quit IRC
701 2017-07-11T23:03:22  *** ivan_ is now known as ivan
702 2017-07-11T23:06:09  *** spinza has joined #bitcoin-core-dev
703 2017-07-11T23:34:10  *** coredump_ has joined #bitcoin-core-dev
704 2017-07-11T23:35:34  *** Aaronvan_ is now known as AaronvanW
705 2017-07-11T23:37:13  *** cheese_ has quit IRC
706 2017-07-11T23:50:10  *** goatpig has quit IRC
707 2017-07-11T23:55:46  *** ivan has quit IRC