1 2017-04-21T00:13:10  *** AaronvanW has quit IRC
  2 2017-04-21T00:16:24  *** AaronvanW has joined #bitcoin-core-dev
  3 2017-04-21T00:18:02  *** d_t has quit IRC
  4 2017-04-21T00:19:53  *** tw2006 has joined #bitcoin-core-dev
  5 2017-04-21T00:29:24  *** jannes has quit IRC
  6 2017-04-21T00:43:35  *** AaronvanW has quit IRC
  7 2017-04-21T00:51:14  *** abpa has quit IRC
  8 2017-04-21T01:00:58  *** Ylbam has quit IRC
  9 2017-04-21T01:14:01  *** AaronvanW has joined #bitcoin-core-dev
 10 2017-04-21T01:27:27  <michagogo> 23:13:32 <gmaxwell> I've mused about the idea about having some shred wallet feature that creates some long timelocked spend of any remaining coins and gives them over to fees... then sends them off somewhere.
 11 2017-04-21T01:27:27  <michagogo> 23:14:25 <gmaxwell> because I am somewhat pained by all the utxo bloat created by people who end up with 0.00001 BTC in a wallet, in 100 inputs, and then they just delete the file because its effectively worthless.
 12 2017-04-21T01:27:32  <michagogo> Isn't that already a thing?
 13 2017-04-21T01:28:02  *** d9b4bef9 has quit IRC
 14 2017-04-21T01:28:22  <michagogo> I mean, not built in to Core, but I could have sworn there was something that collects dust and bundles it into an ANYONECANPAY to a 0-value OP_RETURN
 15 2017-04-21T01:29:08  *** d9b4bef9 has joined #bitcoin-core-dev
 16 2017-04-21T01:30:14  *** AaronvanW has quit IRC
 17 2017-04-21T01:33:12  <gmaxwell> yea, peter todd's dustbgone
 18 2017-04-21T01:34:05  <michagogo> Yep, that's the one.
 19 2017-04-21T01:34:19  <michagogo> BTW, something occurred to me earlier.
 20 2017-04-21T01:34:46  <michagogo> In the latest update (Creators', I think it was called?) to Windows 10, they upgraded WSL
 21 2017-04-21T01:35:41  <michagogo> And I think one of the big things, besides the fact that it now uses Xenial, is that you can now call Windows binaries from within bash.
 22 2017-04-21T01:36:13  <michagogo> (Up until now, if you tried putting an exe into there it would try to execute it as a Linux binary and fail)
 23 2017-04-21T01:36:17  <achow101> oh, they updated to xenial? then you can't cross compile from wsl
 24 2017-04-21T01:36:32  <michagogo> achow101: yeah, for new installations
 25 2017-04-21T01:36:39  <michagogo> Wait, really?
 26 2017-04-21T01:36:56  <achow101> mingw on xenial does work IIRC
 27 2017-04-21T01:37:21  <michagogo> So why can't you cross-compile?
 28 2017-04-21T01:37:53  <achow101> well, not that it doesn't work, but rather that something (unknown) is different about it that makes it fail. there's an issue about it
 29 2017-04-21T01:38:25  <michagogo> Weird.
 30 2017-04-21T01:38:45  <achow101> michagogo: https://github.com/bitcoin/bitcoin/projects/1
 31 2017-04-21T01:39:01  <michagogo> I was just confused because you said mingw on xenial does work -- do you mean that there's something different about one of the other packages that does it?
 32 2017-04-21T01:39:23  <michagogo> Anyway, what occurred to me was this: Gitian supports virtualbox, right?
 33 2017-04-21T01:39:29  <achow101> yes
 34 2017-04-21T01:39:44  <achow101> I don't think it does it well though
 35 2017-04-21T01:39:51  <michagogo> And I assume vboxmanage works the same (in terms of parameters etc) on Windows and Linux?
 36 2017-04-21T01:40:27  <achow101> idk. I don't use virtualbox
 37 2017-04-21T01:40:47  <michagogo> If that is the case, it should (I think?) now be possible to run Gitian from within WSL
 38 2017-04-21T01:41:11  <achow101> couldn't you already do it with lxc?
 39 2017-04-21T01:41:59  <michagogo> Can you?
 40 2017-04-21T01:42:08  <michagogo> I would not expect LXC to work in WSL
 41 2017-04-21T01:42:59  <achow101> i thought someone did it a while ago and it worked, but I don't quite remember. I haven't tried it myself
 42 2017-04-21T01:44:05  *** jtimon has quit IRC
 43 2017-04-21T01:56:42  *** goksinen has joined #bitcoin-core-dev
 44 2017-04-21T01:58:03  <cfields> Any other gitian builders? Waiting for 1 more sig.
 45 2017-04-21T02:01:10  *** goksinen has quit IRC
 46 2017-04-21T02:04:09  <achow101> how many sigs do you need before doing the signed binaries?
 47 2017-04-21T02:10:26  <luke-jr> https://github.com/bitcoin/bitcoin/pull/7107 should probably be reopened
 48 2017-04-21T02:17:47  <cfields> achow101: usually 3. But usually wumpus is one of them. Since he uploads the tarballs, it's reassuring to know he's gotten the same result. So without his, I'd prefer to wait for another one/two before signing.
 49 2017-04-21T02:40:13  <michagogo> cfields: mine's building right now
 50 2017-04-21T02:41:05  <michagogo> dammit, accidentally hit ctrl-c
 51 2017-04-21T02:42:55  <michagogo> Anyway, managed to get this for Linux: https://www.irccloud.com/pastebin/NPg3fSPm/
 52 2017-04-21T02:43:12  <michagogo> Restarting the build for Windows and macOS now
 53 2017-04-21T02:49:35  *** justan0theruser has quit IRC
 54 2017-04-21T02:50:16  *** justanotheruser has joined #bitcoin-core-dev
 55 2017-04-21T02:56:53  <cfields> michagogo: thanks!
 56 2017-04-21T02:58:55  *** Giszmo has quit IRC
 57 2017-04-21T03:00:21  *** goksinen has joined #bitcoin-core-dev
 58 2017-04-21T03:03:15  *** gm2052 has joined #bitcoin-core-dev
 59 2017-04-21T03:03:32  *** PaulCape_ has joined #bitcoin-core-dev
 60 2017-04-21T03:03:58  *** gm2053 has quit IRC
 61 2017-04-21T03:03:58  *** PaulCapestany has quit IRC
 62 2017-04-21T03:05:05  *** goksinen has quit IRC
 63 2017-04-21T03:06:14  *** n1ce has quit IRC
 64 2017-04-21T03:07:03  *** n1ce has joined #bitcoin-core-dev
 65 2017-04-21T03:09:25  *** n1ce has quit IRC
 66 2017-04-21T03:10:16  *** n1ce has joined #bitcoin-core-dev
 67 2017-04-21T03:10:58  *** AaronvanW has joined #bitcoin-core-dev
 68 2017-04-21T03:15:23  *** AaronvanW has quit IRC
 69 2017-04-21T03:18:20  <michagogo> cfields: https://www.irccloud.com/pastebin/XrNoFzY5/
 70 2017-04-21T03:20:11  *** Giszmo has joined #bitcoin-core-dev
 71 2017-04-21T03:25:12  *** justan0theruser has joined #bitcoin-core-dev
 72 2017-04-21T03:25:39  *** n1ce has quit IRC
 73 2017-04-21T03:27:47  *** justanotheruser has quit IRC
 74 2017-04-21T03:35:00  *** waxwing has quit IRC
 75 2017-04-21T03:47:20  *** waxwing has joined #bitcoin-core-dev
 76 2017-04-21T03:49:00  *** tw2006 has quit IRC
 77 2017-04-21T04:20:49  <michagogo> cfields: PR up now
 78 2017-04-21T04:26:09  <cfields> michagogo: thanks!
 79 2017-04-21T04:27:27  *** harrymm has quit IRC
 80 2017-04-21T04:31:29  <cfields> gitian builders: detached sigs pushed for 0.14.1
 81 2017-04-21T04:32:46  *** harrymm has joined #bitcoin-core-dev
 82 2017-04-21T04:41:41  <michagogo> Oops.
 83 2017-04-21T04:42:15  <michagogo> I was running a while ! loop on the script to do the signed build
 84 2017-04-21T04:43:44  <michagogo> But the script was returning failure, because the last step is opening a PR, which fails when there's already a PR open for the same branch
 85 2017-04-21T04:49:57  *** tw2006 has joined #bitcoin-core-dev
 86 2017-04-21T04:54:48  *** tw2006 has quit IRC
 87 2017-04-21T04:57:23  *** d_t has joined #bitcoin-core-dev
 88 2017-04-21T05:11:39  *** AaronvanW has joined #bitcoin-core-dev
 89 2017-04-21T05:17:19  *** AaronvanW has quit IRC
 90 2017-04-21T05:29:01  *** d9b4bef9 has quit IRC
 91 2017-04-21T05:32:08  *** d9b4bef9 has joined #bitcoin-core-dev
 92 2017-04-21T05:39:54  *** arubi_ is now known as arubi
 93 2017-04-21T05:56:37  *** Ylbam has joined #bitcoin-core-dev
 94 2017-04-21T06:01:29  *** str4d has joined #bitcoin-core-dev
 95 2017-04-21T06:32:23  *** RubenSomsen has joined #bitcoin-core-dev
 96 2017-04-21T06:32:57  *** SopaXorzTaker has joined #bitcoin-core-dev
 97 2017-04-21T06:38:51  *** tw2006 has joined #bitcoin-core-dev
 98 2017-04-21T06:43:47  *** tw2006 has quit IRC
 99 2017-04-21T06:48:28  *** gm2053 has joined #bitcoin-core-dev
100 2017-04-21T06:49:52  *** gm2051 has joined #bitcoin-core-dev
101 2017-04-21T06:52:24  *** gm2052 has quit IRC
102 2017-04-21T06:53:19  *** gm2053 has quit IRC
103 2017-04-21T06:58:58  *** BashCo has quit IRC
104 2017-04-21T07:08:02  *** goksinen has joined #bitcoin-core-dev
105 2017-04-21T07:12:57  *** goksinen has quit IRC
106 2017-04-21T07:17:16  *** BashCo has joined #bitcoin-core-dev
107 2017-04-21T07:34:40  *** chatter29 has joined #bitcoin-core-dev
108 2017-04-21T07:34:52  <chatter29> hey guys
109 2017-04-21T07:34:54  <chatter29> allah is doing
110 2017-04-21T07:34:59  <chatter29> sun is not doing allah is doing
111 2017-04-21T07:35:02  <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
112 2017-04-21T07:35:06  *** chatter29 has quit IRC
113 2017-04-21T08:02:17  *** goksinen has joined #bitcoin-core-dev
114 2017-04-21T08:04:19  *** CubicEarth has joined #bitcoin-core-dev
115 2017-04-21T08:07:04  *** goksinen has quit IRC
116 2017-04-21T08:13:19  <CubicEarth> Should the default keypool size be increased to 1000?
117 2017-04-21T08:13:24  *** jannes has joined #bitcoin-core-dev
118 2017-04-21T08:14:01  <CubicEarth> Or is HD the new default?
119 2017-04-21T08:27:49  *** tw2006 has joined #bitcoin-core-dev
120 2017-04-21T08:32:19  *** tw2006 has quit IRC
121 2017-04-21T08:34:53  *** CubicEarth has quit IRC
122 2017-04-21T08:40:58  *** gm2052 has joined #bitcoin-core-dev
123 2017-04-21T08:42:19  *** molz_ has joined #bitcoin-core-dev
124 2017-04-21T08:44:19  *** gm2051 has quit IRC
125 2017-04-21T08:45:05  *** mol has quit IRC
126 2017-04-21T08:47:43  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86ea3c2ff247...694062eafec5
127 2017-04-21T08:47:43  <bitcoin-git> bitcoin/master 0611bc3 Shigeya Suzuki: Minor fix in build documentation for FreeBSD 11...
128 2017-04-21T08:47:44  <bitcoin-git> bitcoin/master 694062e Wladimir J. van der Laan: Merge #10245: Minor fix in build documentation for FreeBSD 11...
129 2017-04-21T08:48:08  <bitcoin-git> [bitcoin] laanwj closed pull request #10245: Minor fix in build documentation for FreeBSD 11 (master...freebsd-11-build-doc-fix) https://github.com/bitcoin/bitcoin/pull/10245
130 2017-04-21T08:54:10  *** gm2053 has joined #bitcoin-core-dev
131 2017-04-21T08:56:32  *** goksinen has joined #bitcoin-core-dev
132 2017-04-21T08:57:04  *** gm2051 has joined #bitcoin-core-dev
133 2017-04-21T08:57:15  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/694062eafec5...0416ea9f743f
134 2017-04-21T08:57:15  <bitcoin-git> bitcoin/master 394ccf7 Pieter Wuille: Make Boost use std::atomic internally
135 2017-04-21T08:57:16  <bitcoin-git> bitcoin/master 0416ea9 Wladimir J. van der Laan: Merge #10239: Make Boost use std::atomic internally...
136 2017-04-21T08:57:29  *** gm2052 has quit IRC
137 2017-04-21T08:57:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0416ea9f743f...f6f3b58a7250
138 2017-04-21T08:57:36  <bitcoin-git> bitcoin/master fb463d1 Russell Yanofsky: [qt] Don't call method on null WalletModel object...
139 2017-04-21T08:57:37  <bitcoin-git> bitcoin/master f6f3b58 Wladimir J. van der Laan: Merge #10242: [qt] Don't call method on null WalletModel object...
140 2017-04-21T08:57:57  <bitcoin-git> [bitcoin] laanwj closed pull request #10242: [qt] Don't call method on null WalletModel object (master...pr/rbfnull) https://github.com/bitcoin/bitcoin/pull/10242
141 2017-04-21T08:59:46  *** gm2053 has quit IRC
142 2017-04-21T09:01:09  *** goksinen has quit IRC
143 2017-04-21T09:12:47  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6f3b58a7250...27faa6cccd8d
144 2017-04-21T09:12:48  <bitcoin-git> bitcoin/master 3577603 Cory Fields: build: remove wonky auto top-level convenience targets...
145 2017-04-21T09:12:49  <bitcoin-git> bitcoin/master 91ab8f5 Cory Fields: build: fix bitcoin-config.h regeneration after touching build files...
146 2017-04-21T09:12:49  <bitcoin-git> bitcoin/master 27faa6c Wladimir J. van der Laan: Merge #10228: build: regenerate bitcoin-config.h as necessary...
147 2017-04-21T09:13:11  <bitcoin-git> [bitcoin] laanwj closed pull request #10228: build: regenerate bitcoin-config.h as necessary (master...fix-config-h) https://github.com/bitcoin/bitcoin/pull/10228
148 2017-04-21T09:14:13  *** AaronvanW has joined #bitcoin-core-dev
149 2017-04-21T09:15:47  *** SopaXorzTaker has quit IRC
150 2017-04-21T09:19:10  *** AaronvanW has quit IRC
151 2017-04-21T09:19:58  *** SopaXorzTaker has joined #bitcoin-core-dev
152 2017-04-21T09:38:08  * wumpus still deleting "qa" directories everywhere :-)
153 2017-04-21T09:43:08  *** jtimon has joined #bitcoin-core-dev
154 2017-04-21T09:50:53  *** goksinen has joined #bitcoin-core-dev
155 2017-04-21T09:55:20  *** goksinen has quit IRC
156 2017-04-21T10:04:57  *** AaronvanW has joined #bitcoin-core-dev
157 2017-04-21T10:04:57  *** AaronvanW has joined #bitcoin-core-dev
158 2017-04-21T10:09:40  *** laurentmt has joined #bitcoin-core-dev
159 2017-04-21T10:14:35  *** d_t has quit IRC
160 2017-04-21T10:16:42  *** tw2006 has joined #bitcoin-core-dev
161 2017-04-21T10:21:22  *** tw2006 has quit IRC
162 2017-04-21T10:44:59  *** goksinen has joined #bitcoin-core-dev
163 2017-04-21T10:49:39  *** goksinen has quit IRC
164 2017-04-21T10:54:37  *** elkalamar has quit IRC
165 2017-04-21T11:00:57  <jonasschnelli> #10244 and the IPC approach is in general good. Is there a broad agreement that we want to do this? I vaguely remember gmaxwell had some concerns. Just to give more clear feedback to ryanofsky
166 2017-04-21T11:00:59  <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
167 2017-04-21T11:01:09  <jonasschnelli> I like it
168 2017-04-21T11:02:07  <jonasschnelli> But I remember when I also tried to write such *larger* PRs... they just have a hard time getting reviewed. Constant rebase and often great risks when merging.
169 2017-04-21T11:15:05  *** nu11p7r has quit IRC
170 2017-04-21T11:17:10  *** BashCo has quit IRC
171 2017-04-21T11:18:38  *** laurentmt has quit IRC
172 2017-04-21T11:19:59  *** BashCo has joined #bitcoin-core-dev
173 2017-04-21T11:20:40  <wumpus> yes it's difficult to do a big change like thta
174 2017-04-21T11:21:59  <wumpus> I agree broadly, on the approach, the thing I didn't like about it is that he seemed to add more abstraction layers. What I don't like about that is that it reduces flexibility, hardcoding maybe stupid choices that were made years ago and made sense at the time, buried beneath layers of calls.
175 2017-04-21T11:22:41  <wumpus> my original plan was to make ClientModel and WalletModel the abstractions for the core, they are currently thin wrappers around it, and could be extended/changed to support a remote core instance instead
176 2017-04-21T11:23:14  <wumpus> along with using async notifications for replies from the core instead of synchronous calls and busy-waiting on locks
177 2017-04-21T11:23:55  <wumpus> so I'm happy he's doing it, but it's not in the way that I would, maybe I should just let it go though
178 2017-04-21T11:26:09  <wumpus> though I have a hard time reviewing code changes that aren't in line with my own thoughts
179 2017-04-21T11:26:17  <wumpus> especially big ones
180 2017-04-21T11:26:31  <sipa> wumpus: is your concern that the result makes the client/walletmodel less independent?
181 2017-04-21T11:26:46  <sipa> in that it now requires the IPC abstraction below it
182 2017-04-21T11:27:12  <wumpus> sipa: mostly that the code becomes even harder to work on
183 2017-04-21T11:27:46  <wumpus> it seems like a double abstraction; walletmodel is already an abstraction for core's CWallet
184 2017-04-21T11:27:49  <wumpus> now there's a class in between
185 2017-04-21T11:29:11  <sipa> seems like a reasonable concern to me... WalletModel and ClientModel don't really have much responsibility anymore
186 2017-04-21T11:29:28  <wumpus> the best way to implement remote-anything is not necessarily changing every direct call into a IPC call
187 2017-04-21T11:30:15  <wumpus> it's the easiest way to do it, but it's not how modern GUIs are written, ther shouldn't be anything waiting on replies from a remote process inside the GUI thread/loop
188 2017-04-21T11:31:03  <wumpus> even for local implementation this is wrong, and it means that while e.g. sending a transaction while cs_main is busy, the GUI hangs instead of being able to show a moving progress indicator
189 2017-04-21T11:31:20  <wumpus> I'm much more concerned with that than IPCing everything
190 2017-04-21T11:31:26  <sipa> seems reasonable, i don't know much about that
191 2017-04-21T11:31:50  <wumpus> so this is kind of calcifying the state of the code that I'm already not happy with
192 2017-04-21T11:35:04  <jonasschnelli> wumpus: I completely agree with you.
193 2017-04-21T11:35:43  <jonasschnelli> I think it will be very hard to change the GUI towards that goal with the current review strategy
194 2017-04-21T11:35:46  <wumpus> jonasschnelli: I tried to talk to him about this, but he seemed convinced that my concern had nothing to do with his changes, and that this can be done first.
195 2017-04-21T11:36:33  <jonasschnelli> Also the split between Wallet and Node (walletmodal / clientmodel) makes really sense.
196 2017-04-21T11:36:39  <jonasschnelli> *model
197 2017-04-21T11:37:24  <wumpus> and he's not entirely incorrect but I in my opinoin it makes sense to combine those two things; if the core and GUI communicate with asynchronous messages, goign from there to an IPC protocol is much easier
198 2017-04-21T11:37:59  <jonasschnelli> I often though maybe rewrite the GUI from the ground up,...
199 2017-04-21T11:38:02  <wumpus> and will likely be less complex
200 2017-04-21T11:38:40  <wumpus> I'm not sure that is a good idea
201 2017-04-21T11:38:50  <jonasschnelli> Yeah.. me neither... :)
202 2017-04-21T11:38:59  <wumpus> a rewrite is a lot of work to get feature parity, all bugs are born new, etc
203 2017-04-21T11:39:17  <wumpus> usually I prefer incremental improvements unless something is total junk, which I think the code is not
204 2017-04-21T11:39:21  <sipa> wumpus: that was my concern as well... it seems crazy to me that introducing an IPC layer somehow helps making things more asynchronous
205 2017-04-21T11:39:38  <wumpus> sipa: not the way he's doing it, at least
206 2017-04-21T11:39:45  <wumpus> in the way I always imagined doing it, it would
207 2017-04-21T11:39:51  <jonasschnelli> What design would make sense for asynchronous messages?
208 2017-04-21T11:40:22  <wumpus> jonasschnelli: qt signals/slots? same way that RPCConsole and RPCThread communicate for example
209 2017-04-21T11:41:11  <jonasschnelli> So each node call would run in its own thread? Or would that be a single node-/wallet-interaction thread with queue?
210 2017-04-21T11:41:13  <wumpus> signals could be generated by something that listens to a network pipe or local implemantion, most of the GUI code could be oblivous to that
211 2017-04-21T11:41:32  <wumpus> one thread should be OK usually
212 2017-04-21T11:42:00  *** gm2052 has joined #bitcoin-core-dev
213 2017-04-21T11:42:36  <wumpus> long running operations could be their own thread
214 2017-04-21T11:42:37  <jonasschnelli> Yes. I think this would be much better... would also require context sensitive activity-inidcators instead of a GUI freeze when communication is in progress
215 2017-04-21T11:42:51  <wumpus> right
216 2017-04-21T11:43:11  <jonasschnelli> reminds me that the RPCConcole/RPCThread missed a activity indicator...
217 2017-04-21T11:43:22  <wumpus> heck, even changing the cursor to a bee as on the Atari ST is better than hanging the GUI
218 2017-04-21T11:43:22  <jonasschnelli> (things like topupkeypool 1000)
219 2017-04-21T11:43:30  <jonasschnelli> wumpus: haha
220 2017-04-21T11:43:55  <wumpus> yes, indeed, it doesn't provide feedback that something is in progress
221 2017-04-21T11:43:59  <jonasschnelli> Yes. We could start with a general activity indicator ("node communication happening") in the status bar
222 2017-04-21T11:44:21  <jonasschnelli> I hope we can convince ryanofsky
223 2017-04-21T11:44:23  <wumpus> in any case showing a modal dialog is still possible
224 2017-04-21T11:44:31  <wumpus> if you don't want the user to do other things
225 2017-04-21T11:44:59  <wumpus> that's not hanging the GUI; the dialog could e.g. show an animation, or have an abort butotn, or react to the user in other ways
226 2017-04-21T11:45:30  <jonasschnelli> Yes. The modal non blocking concept is much better
227 2017-04-21T11:45:45  <jonasschnelli> Blocking the GUI must be avoided any time
228 2017-04-21T11:45:50  *** gm2051 has quit IRC
229 2017-04-21T11:45:56  <jonasschnelli> Otherwise users will force quite
230 2017-04-21T11:46:02  <jonasschnelli> force kill
231 2017-04-21T11:46:04  <wumpus> right. And some OSes will blank out the window
232 2017-04-21T11:52:19  *** Guyver2 has joined #bitcoin-core-dev
233 2017-04-21T11:53:42  *** BCBot has quit IRC
234 2017-04-21T11:54:01  *** BCBot has joined #bitcoin-core-dev
235 2017-04-21T11:54:59  *** belcher has quit IRC
236 2017-04-21T12:00:19  <bitcoin-git> [bitcoin] sipa opened pull request #10248: Introduce CHashVerifier to hash while deserializing (master...chashverifier) https://github.com/bitcoin/bitcoin/pull/10248
237 2017-04-21T12:02:09  <wumpus> so on the other hand I like that people actively work on the code and dno't want to discourage it, just because I have some different ideas
238 2017-04-21T12:05:38  *** tw2006 has joined #bitcoin-core-dev
239 2017-04-21T12:07:43  *** belcher has joined #bitcoin-core-dev
240 2017-04-21T12:10:44  *** tw2006 has quit IRC
241 2017-04-21T12:11:28  <wumpus> I know I myself have way too many ideas and too little time to work on them
242 2017-04-21T12:12:29  *** str4d has quit IRC
243 2017-04-21T12:13:03  <sipa> i think the ultimate goal of having the GUI being independent from the core, and being able to start/stop it separate is very nice
244 2017-04-21T12:13:23  *** nu11p7r has joined #bitcoin-core-dev
245 2017-04-21T12:13:29  <sipa> if that requires an extra abstraction layer somewhere, fine
246 2017-04-21T12:13:43  <sipa> but i'm not convinced why that abstraction layer can't be clientmodel/walletmodel
247 2017-04-21T12:24:16  <jonasschnelli> I think one of ryanofsky arguments is that the client-/walletmodal also contains "business" logic and not only communication handling.
248 2017-04-21T12:24:17  <jonasschnelli> Which I partially can follow
249 2017-04-21T12:25:04  <sipa> well that business logic should move to the core
250 2017-04-21T12:25:24  <sipa> some of it can likely be merged with some code in rpcwallet
251 2017-04-21T12:27:45  <luke-jr> Random reddit user suggests that txindex should default to on when pruning is disabled.
252 2017-04-21T12:28:26  <sipa> ...?
253 2017-04-21T12:28:55  <luke-jr> he was annoyed he had to reindex to setup an Electrum server because txindex defaulted to off, and argues that the txindex is small compared to the full blockchain
254 2017-04-21T12:29:10  <sipa> it's huge compared to the utxo set
255 2017-04-21T12:29:16  <luke-jr> https://www.reddit.com/r/Bitcoin/comments/66k36g/why_does_electrum_need_special_servers/dgjtg54/?context=3
256 2017-04-21T12:29:24  <sipa> and people shouldn't rely on having a txindex available
257 2017-04-21T12:29:36  <luke-jr> I don't think it's avoidable for Electrum
258 2017-04-21T12:29:57  <sipa> i think electrum server should have a specialized node for that, not rely on bitcoind
259 2017-04-21T12:30:00  <sipa> but ok
260 2017-04-21T12:30:09  <sipa> still doesn't mean everyone needs that
261 2017-04-21T12:30:09  <jonasschnelli> You suggesting making it default in order to be able to run an electrum server?
262 2017-04-21T12:30:29  <luke-jr> jonasschnelli: relatively low cost, and high benefit to users who want to use Electrum
263 2017-04-21T12:30:50  <luke-jr> sipa: not everyone needs BLOOM, but we have it enabled by default
264 2017-04-21T12:30:50  <jonasschnelli> Well,... a reindex with txindex takes a day or so?
265 2017-04-21T12:31:06  <luke-jr> true
266 2017-04-21T12:31:14  <jonasschnelli> bloom is network, txindex is loca
267 2017-04-21T12:31:18  <jonasschnelli> +l
268 2017-04-21T12:31:29  <luke-jr> jonasschnelli: txindex is used for Electrum network protocol
269 2017-04-21T12:31:35  <sipa> luke-jr: the way i see it, i'd have removed txindex support entirely with ultraprune
270 2017-04-21T12:31:52  <jonasschnelli> Yes. Just saying offering bloom is something you do for the public, txindex is local
271 2017-04-21T12:31:54  <sipa> luke-jr: but that would have caused too much problems for people relying on the software, so made it optional instead
272 2017-04-21T12:32:33  <sipa> i don't think bitcoind's goal should be indexing the blockchain... for some purposes it's useful to have that feature availab;e
273 2017-04-21T12:32:38  <sipa> but it's not optimized for it at all
274 2017-04-21T12:33:11  *** goksinen has joined #bitcoin-core-dev
275 2017-04-21T12:33:13  <luke-jr> perhaps not, but users care less about that than how easy it is to get things going
276 2017-04-21T12:33:37  <sipa> maybe we should create a separate tool that indexes the chain in a decent way
277 2017-04-21T12:33:42  <sipa> without doing validation etc
278 2017-04-21T12:35:48  <bitcoin-git> [bitcoin] sipa opened pull request #10249: Switch CCoinsMap from boost to std unordered_map (master...stdcoinmap) https://github.com/bitcoin/bitcoin/pull/10249
279 2017-04-21T12:37:01  <wumpus> no,  txindex should not be default-enabled at any time. By far most people don't use it, while it forces an overhead on everyone.
280 2017-04-21T12:37:35  *** goksinen has quit IRC
281 2017-04-21T12:38:09  <wumpus> if it's an annoyance to have to enable it once, well yes maybe, but there's a cost to everything
282 2017-04-21T12:39:16  <wumpus> can be kind of annoying if people have some far-out usage of a program and then expect everyone to accomodate to them
283 2017-04-21T12:39:35  <luke-jr> I suspect there are more Electrum users than Core-wallet users, sadly
284 2017-04-21T12:40:10  <wumpus> of course there are more electrum users, that doesn't invalidate anything I said, most people running bitcoin core do not run an electrum server
285 2017-04-21T12:40:25  <luke-jr> everyone using Electrum should be running their own Electrum server
286 2017-04-21T12:41:16  <wumpus> in any case people shoudl be encouraged to use an index on the utxo set intead of on the whole block chain
287 2017-04-21T12:41:43  <luke-jr> need an index on the whole blockchain to get tx history
288 2017-04-21T12:42:12  <wumpus> there should be no need to index the whole block chain ,ever, unless you're doing chain analysis stuff, in which case you're working with such big data thatdoing  an extra reindex should be peanuts
289 2017-04-21T12:44:30  <sipa> there is something crazy in this reasoning: bitcoin core is too annoying to use due to resource usage, thus people switch to electrum, but then complain they can't easily run their own server... which is even more expensive than just running a full node wallet in the first place
290 2017-04-21T12:44:56  <sipa> also, doesn't electrum full history require addrindex even?
291 2017-04-21T12:44:58  <sipa> not just txindex?
292 2017-04-21T12:45:02  <luke-jr> sipa: many people use Electrum because it supports hardware wallets
293 2017-04-21T12:45:20  <luke-jr> and yes, Electrum's server generates that itself from the txindex
294 2017-04-21T12:45:31  <sipa> then why can't it create the txindex too?
295 2017-04-21T12:45:43  <luke-jr> not sure.
296 2017-04-21T12:46:02  <sipa> luke-jr: well electrum uses a model that makes it inherently more expensive to run a server
297 2017-04-21T12:46:23  <luke-jr> sipa: depends whether storage/indexing costs more than doing the filtering on-the-fly for bloom nodes
298 2017-04-21T12:46:25  <sipa> stupid "the blockchain is my wallet model"
299 2017-04-21T12:46:29  <wumpus> it could, but remember that it is python code, so doing it there would be slower than having core handle it
300 2017-04-21T12:46:35  <luke-jr> indexes are far less expensive than filtering for each user
301 2017-04-21T12:46:59  <sipa> luke-jr: my view is that end users shouldn't need the full blockchain
302 2017-04-21T12:47:08  <sipa> much less so a fully indexed one
303 2017-04-21T12:47:34  <sipa> i understand electrum has advantages, but there must be ways to get them without burdening full nodes further
304 2017-04-21T12:47:46  <luke-jr> sipa: not sure that's avoidable
305 2017-04-21T12:47:59  <sipa> finding your old transactions should be a rare occurence
306 2017-04-21T12:48:02  <wumpus> if everyone ran their own trusted full node to connect to, they could run some remote wallet UI instead of electrum on the light device side
307 2017-04-21T12:48:11  <luke-jr> bloom allows you to get the data from other nodes, and use your own only for consensus, but those other nodes could omit info
308 2017-04-21T12:48:33  <luke-jr> wumpus: yes, in theory
309 2017-04-21T12:48:47  <wumpus> luke-jr: everyoen running their own electrum server is theory just as well
310 2017-04-21T12:48:55  <wumpus> luke-jr: and a much more overhead one at that
311 2017-04-21T12:48:57  <sipa> without the 'blockchain is my wallet' model, you could easily outsource the recovery of old transactions to a third party
312 2017-04-21T12:49:05  <wumpus> why would everyone need to index everyone's transactions?
313 2017-04-21T12:49:07  <wumpus> that's just crazy
314 2017-04-21T12:51:51  <sipa> to be clear: my concern is indirect... txindex is indeed that not much of a resource problem, but the fact that something 'requires' you to have txindex, implies it requires you to have the full blockchain readily available
315 2017-04-21T12:52:09  <sipa> an ecosystem that relies on everyone having the full blockchain available is disaster for scalability
316 2017-04-21T12:52:21  <wumpus> in any case txindex is already supported, people can use it if they want
317 2017-04-21T12:52:45  <wumpus> what I find deplorable is that people want to burden everyone with it just to avoid a one-time overhead for them
318 2017-04-21T12:53:27  <sipa> maybe instead we should make pruning default :)
319 2017-04-21T12:53:33  <instagibbs> ^ was about tot say that
320 2017-04-21T12:54:11  <wumpus> but I guess it fits well in the weird idea that many people have about the block chain, that it's some infinite externality that one can just keep dumping into, without relevant cost to anyone
321 2017-04-21T12:54:17  <luke-jr> sipa: IMO wait until we can IBD from pruned nodes
322 2017-04-21T12:54:19  <sdaftuar> sipa: lets merge that default to motivate block download improvements for 0.15 :)
323 2017-04-21T12:54:30  <sipa> luke-jr: fair point
324 2017-04-21T12:54:54  <luke-jr> I did make a pruning GUI for Knots, but it uses rwconf :x
325 2017-04-21T12:57:43  <wumpus> I think offering a choice in the initial GUI dialog would already be nice
326 2017-04-21T12:57:56  <sipa> agree
327 2017-04-21T12:58:05  <wumpus> (the one that lets you choose the data directory and shows an estimate of disk usage)
328 2017-04-21T12:58:47  <wumpus> I wouldn't like pruning to be the default because it means throwing away downloaded data by default. Prefer to err on the safe side.
329 2017-04-21T12:59:12  <wumpus> it's trivially possible to go from non-pruned to pruned, the other way around can be expensive
330 2017-04-21T13:00:06  <wumpus> sure if e.g. the machine has little disk space it can be encouraged strongly to prune
331 2017-04-21T13:00:20  <wumpus> just think it should not be enabled silently
332 2017-04-21T13:00:25  *** tw2006 has joined #bitcoin-core-dev
333 2017-04-21T13:01:23  <bitcoin-git> [bitcoin] sipa opened pull request #10250: Fix some empty vector references (master...nonnullref) https://github.com/bitcoin/bitcoin/pull/10250
334 2017-04-21T13:02:00  <luke-jr> wumpus: Knots firstrun: http://i.imgur.com/mKTQrVb.png http://i.imgur.com/jopLsLQ.png
335 2017-04-21T13:02:07  <sipa> in the GUI, a wizard setup dialog the first time that asks you seems nice
336 2017-04-21T13:02:18  <wumpus> luke-jr: exactly
337 2017-04-21T13:02:36  <luke-jr> perhaps I should re-PR rwconf without the GUI stuff?
338 2017-04-21T13:02:43  <sipa> what is rwconf?
339 2017-04-21T13:02:47  <luke-jr> although I guess that doesn't help get it to Intro
340 2017-04-21T13:02:56  <luke-jr> sipa: bitcoin_rw.conf file that the software modifies
341 2017-04-21T13:03:13  <sipa> which is also used by bitcoind?
342 2017-04-21T13:03:20  <luke-jr> Knots bitcoind, yes
343 2017-04-21T13:03:22  <wumpus> luke-jr: is that file at least in the per-network directory?
344 2017-04-21T13:03:43  <luke-jr> wumpus: yes
345 2017-04-21T13:03:47  <jonasschnelli> I once started a new GUI wizard with pruning: https://github.com/jonasschnelli/bitcoin/commit/7d8798d4942b7d7980a4c4f90cdd714432696ea7
346 2017-04-21T13:03:49  <wumpus> luke-jr: great
347 2017-04-21T13:04:22  <luke-jr> IIRC the hold-back from Core was that you wanted the GUI to use an enum for each setting
348 2017-04-21T13:04:52  <luke-jr> but maybe just a minimal approach that only uses it for pruning would be okay before that's done
349 2017-04-21T13:05:16  <jonasschnelli> The idea of the branch above was to ask about pruning / dbcache / folder (what we have right now)
350 2017-04-21T13:05:39  <wumpus> from a sandboxing point of view I don't really like the idea of daemons writing their own configuration files
351 2017-04-21T13:05:56  <wumpus> but if it doesn't write bitcoin.conf, well, it's not too bad
352 2017-04-21T13:06:00  <luke-jr> right, that's why it was an independent file
353 2017-04-21T13:06:03  <sipa> maybe we should go back to serializing settings into wallet.dat
354 2017-04-21T13:06:03  <wumpus> right
355 2017-04-21T13:06:04  * sipa ducks
356 2017-04-21T13:06:59  <wumpus> also having it in per-network directory cleverly avoids the problem of a testnet and mainnet instance trying to write the file at the same time
357 2017-04-21T13:09:00  <luke-jr> ok, so plan: 1) split the rwconf low-level from the GUI Options changes, and PR the former only; 2) in a second PR (?), do just the pruning Intro stuff?
358 2017-04-21T13:10:02  <luke-jr>  * [new tag]         v0.14.1.knots20170420 -> v0.14.1.knots20170420 <-- gitian builds please ☺
359 2017-04-21T13:11:59  <wumpus> yes, I hope adding yet another settings source doesn't introduce a mess, it makes it harder to reason what takes precedence
360 2017-04-21T13:12:04  <wumpus> ok, will build
361 2017-04-21T13:39:46  <luke-jr> thx
362 2017-04-21T13:50:30  *** d_t has joined #bitcoin-core-dev
363 2017-04-21T13:59:43  *** mol has joined #bitcoin-core-dev
364 2017-04-21T14:02:57  *** molz_ has quit IRC
365 2017-04-21T14:09:26  <jonasschnelli> Using lambdas in Qt is a no go? Right? It would break Qt4 compile compat?
366 2017-04-21T14:10:18  <sipa> you cant use c++11 lambdas?
367 2017-04-21T14:11:00  <jonasschnelli> You can... but I think if you are using Qt "connect" mechanism and directly embed a lambda it will no longer be compilable with Qt4...
368 2017-04-21T14:11:02  <jonasschnelli> not sure though
369 2017-04-21T14:19:01  <sipa> a lambda is just a function object
370 2017-04-21T14:19:04  <jonasschnelli> I'm always surprised what kind of hack from the CoinControl implementation I find: https://github.com/bitcoin/bitcoin/blame/master/src/qt/walletmodel.cpp#L64
371 2017-04-21T14:20:13  <jonasschnelli> sipa: Yeah. But I think Qt4 can't handle something like connect( inProject, &myProject::signal, [=] () {}); because it's a marco or a MOC function (or whatever Qt uses to decompose)
372 2017-04-21T14:21:28  <sipa> oh
373 2017-04-21T14:22:44  <Chris_Stewart_5> sipa: Since we are talking about lambdas, if i use '[&]' on lambdas that will force the arg to be passed by reference, instead of being copied correct?
374 2017-04-21T14:22:53  <Chris_Stewart_5> for things like this: https://github.com/Christewart/bitcoin/blob/6c929c05c51c266b6d991ff6e370425dee0f391a/src/test/gen/crypto_gen.h#L28
375 2017-04-21T14:23:49  <jonasschnelli> Chris_Stewart_5: correct
376 2017-04-21T14:24:31  <jonasschnelli> The L28 above makes a copy of the Key, right?
377 2017-04-21T14:25:16  <Chris_Stewart_5> From my understanding of it, yes. However it seems like i could scope it with '&'
378 2017-04-21T14:26:05  *** fao1 has quit IRC
379 2017-04-21T14:26:29  *** fao1 has joined #bitcoin-core-dev
380 2017-04-21T14:26:36  *** molz_ has joined #bitcoin-core-dev
381 2017-04-21T14:27:29  <Chris_Stewart_5> The way I have it written now is just the simplest way I could achieve what I was trying to do -- create a generator for a CPrivKey
382 2017-04-21T14:28:03  <sipa> Chris_Stewart_5: that lambda does not capture anything...
383 2017-04-21T14:28:59  *** Giszmo has quit IRC
384 2017-04-21T14:29:01  <sipa> [&] will have no effect
385 2017-04-21T14:29:23  *** mol has quit IRC
386 2017-04-21T14:29:37  <sipa> if you want the parameter key to be by reference, you just make it Key& key
387 2017-04-21T14:31:45  <sipa> [=] and [&] control the capture list, not the parameter list
388 2017-04-21T14:31:54  <Chris_Stewart_5> by 'capture' you just mean a variable that is a scope larger than that lambda, correct? For instance some global variable?
389 2017-04-21T14:32:15  <Chris_Stewart_5> by default it copies that global variable if you just provide '[]'?
390 2017-04-21T14:32:34  <sipa> if you provide [], it does not capture anything
391 2017-04-21T14:32:52  <sipa> if you provide [=] it captures everything, by value
392 2017-04-21T14:33:04  *** gm2053 has joined #bitcoin-core-dev
393 2017-04-21T14:33:12  <sipa> if you provide [&] it captures everything, by reference
394 2017-04-21T14:34:05  *** RubenSomsen has quit IRC
395 2017-04-21T14:34:56  <Chris_Stewart_5> Thanks for the explanation. That clears up a lot wrt to lambdas for me.
396 2017-04-21T14:35:22  *** gm2051 has joined #bitcoin-core-dev
397 2017-04-21T14:36:09  <sipa> Chris_Stewart_5: http://en.cppreference.com/w/cpp/language/lambda
398 2017-04-21T14:36:50  *** gm2052 has quit IRC
399 2017-04-21T14:38:19  *** gm2053 has quit IRC
400 2017-04-21T14:42:00  <ryanofsky> i kind of like the coding convention where you use unnamed [&] capture for any lambda called synchronously, and named capture [&var1, var2] or [] for any lambda called asynchronously
401 2017-04-21T14:42:56  <ryanofsky> asynchronously meaning the closure is copied and called after the lambda expression goes out of scope
402 2017-04-21T14:43:24  *** belcher has quit IRC
403 2017-04-21T14:43:37  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10251: Add balances cache / GUI: use a signal instead of a poll thread (master...2017/04/gui_rm_locks) https://github.com/bitcoin/bitcoin/pull/10251
404 2017-04-21T14:44:04  <sipa> ryanofsky: that's a nice convention
405 2017-04-21T14:44:25  <sipa> ryanofsky: is there a way to construct a non-copyable lambda?
406 2017-04-21T14:45:11  <ryanofsky> in c++14 there definitely is because you can capture by move
407 2017-04-21T14:45:34  <ryanofsky> so the resulting closure is move-only
408 2017-04-21T14:46:17  <ryanofsky> otherwise i don't think you can do it directly without std::bind or something
409 2017-04-21T14:46:59  <sipa> which incurs a performance penalty?
410 2017-04-21T14:47:51  <ryanofsky> yeah, probably minor unless lambda is capturing a lot of variables or a very big struct by copy
411 2017-04-21T14:48:30  *** luke-jr has quit IRC
412 2017-04-21T14:49:16  *** RubenSomsen has joined #bitcoin-core-dev
413 2017-04-21T14:57:28  *** luke-jr has joined #bitcoin-core-dev
414 2017-04-21T15:00:32  *** BashCo has quit IRC
415 2017-04-21T15:09:17  *** fao1 has quit IRC
416 2017-04-21T15:13:26  *** fao1 has joined #bitcoin-core-dev
417 2017-04-21T15:14:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/27faa6cccd8d...f3db4c601385
418 2017-04-21T15:14:32  <bitcoin-git> bitcoin/master 821dd5e Jimmy Song: Tests: Add test for getdifficulty...
419 2017-04-21T15:14:32  <bitcoin-git> bitcoin/master f3db4c6 Wladimir J. van der Laan: Merge #10229: Tests: Add test for getdifficulty...
420 2017-04-21T15:14:51  <bitcoin-git> [bitcoin] laanwj closed pull request #10229: Tests: Add test for getdifficulty (master...test_getdifficulty) https://github.com/bitcoin/bitcoin/pull/10229
421 2017-04-21T15:17:27  *** fao1 has quit IRC
422 2017-04-21T15:21:07  *** BashCo has joined #bitcoin-core-dev
423 2017-04-21T15:30:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f3db4c601385...5352e5e75da9
424 2017-04-21T15:30:04  <bitcoin-git> bitcoin/master c39a6b9 Jimmy Song: Tests: Refactor to create witness script creation function...
425 2017-04-21T15:30:05  <bitcoin-git> bitcoin/master 5352e5e Wladimir J. van der Laan: Merge #10223: Tests: Refactor to create witness script creation function...
426 2017-04-21T15:30:29  <bitcoin-git> [bitcoin] laanwj closed pull request #10223: Tests: Refactor to create witness script creation function (master...refactor_blocktools_for_segwit) https://github.com/bitcoin/bitcoin/pull/10223
427 2017-04-21T15:32:14  *** stoner19 has joined #bitcoin-core-dev
428 2017-04-21T15:32:31  <stoner19> can anyone link me to the actual code for segwit in bitcoin core?
429 2017-04-21T15:33:18  *** RubenSomsen has quit IRC
430 2017-04-21T15:33:34  *** Giszmo has joined #bitcoin-core-dev
431 2017-04-21T15:33:49  *** RubenSomsen has joined #bitcoin-core-dev
432 2017-04-21T15:34:24  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5352e5e75da9...1428f3030d99
433 2017-04-21T15:34:24  <bitcoin-git> bitcoin/master f478d98 Pieter Wuille: Fix some empty vector references...
434 2017-04-21T15:34:25  <bitcoin-git> bitcoin/master 1428f30 Wladimir J. van der Laan: Merge #10250: Fix some empty vector references...
435 2017-04-21T15:34:28  <sipa> stoner19: what part? consensus logic? p2p protocol changes? signing code for transactions?
436 2017-04-21T15:34:56  <bitcoin-git> [bitcoin] laanwj closed pull request #10250: Fix some empty vector references (master...nonnullref) https://github.com/bitcoin/bitcoin/pull/10250
437 2017-04-21T15:34:58  <stoner19> sipa, guess I'm just curious about it all. What needed to be changed in order to implement/signal segwit?
438 2017-04-21T15:35:16  <sipa> stoner19: signalling is 1 line of code, just changing the block nversion
439 2017-04-21T15:36:08  <sipa> stoner19: https://github.com/bitcoin/bitcoin/pull/8149/commits
440 2017-04-21T15:36:32  <stoner19> oh that helps significantly thank you
441 2017-04-21T15:38:39  *** RubenSomsen has quit IRC
442 2017-04-21T15:49:34  *** abpa has joined #bitcoin-core-dev
443 2017-04-21T15:51:27  <morcos> gmaxwell: sipa: wumpus: i update https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 to contain proposed fee estimation changes for 0.15
444 2017-04-21T15:51:49  <morcos> It's a bit more thorough description than is included in #10199
445 2017-04-21T15:51:51  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
446 2017-04-21T15:52:53  <morcos> It may have actually started to go into too much detail, but I'm happy to discuss further online if there are more questions
447 2017-04-21T16:26:07  *** molz_ has quit IRC
448 2017-04-21T16:42:43  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1428f3030d99...a6548a47a554
449 2017-04-21T16:42:43  <bitcoin-git> bitcoin/master 25660e9 Mario Dian: pass Consensus::Params& to ReceivedBlockTransactions()
450 2017-04-21T16:42:44  <bitcoin-git> bitcoin/master a6548a4 Wladimir J. van der Laan: Merge #10201: pass Consensus::Params& to ReceivedBlockTransactions()...
451 2017-04-21T16:44:03  <achow101> has 0.14.1 been officially released yet? or still waiting on gitian sigs?
452 2017-04-21T16:45:28  <bitcoin-git> [bitcoin] luke-jr opened pull request #10252: RPC/Mining: Restore API compatibility for prioritisetransaction (master...rpc_prioritise_api) https://github.com/bitcoin/bitcoin/pull/10252
453 2017-04-21T16:46:33  <luke-jr> achow101: thanks for the reminder to build signed bins :D
454 2017-04-21T16:51:40  <gmaxwell> morcos: 60% threshold at target/2
455 2017-04-21T16:51:42  <gmaxwell> 85% threshold at target
456 2017-04-21T16:52:21  <gmaxwell> so do we have any reason to expect that the 60% at target/2 won't dominate the estimate?
457 2017-04-21T16:55:31  *** Guest12838 has quit IRC
458 2017-04-21T16:59:44  *** Guest12838 has joined #bitcoin-core-dev
459 2017-04-21T17:00:01  <bitcoin-git> [bitcoin] jimmysong opened pull request #10253: Tests: Add test for getnetworkhashps (master...test_getnetworkhashps) https://github.com/bitcoin/bitcoin/pull/10253
460 2017-04-21T17:05:36  *** Giszmo has quit IRC
461 2017-04-21T17:19:08  *** fao1 has joined #bitcoin-core-dev
462 2017-04-21T17:20:08  *** Chris_Stewart_5 has quit IRC
463 2017-04-21T17:31:54  *** kadoban has joined #bitcoin-core-dev
464 2017-04-21T17:33:21  *** Giszmo has joined #bitcoin-core-dev
465 2017-04-21T17:37:13  *** gielbier has quit IRC
466 2017-04-21T17:49:18  *** jtimon_ has joined #bitcoin-core-dev
467 2017-04-21T17:49:41  *** gielbier has joined #bitcoin-core-dev
468 2017-04-21T17:50:28  <jtimon_> wumpus: it seems you added a commit to https://github.com/bitcoin/bitcoin/pull/10201 by mistake?
469 2017-04-21T17:54:34  <bitcoin-git> [bitcoin] jtimon closed pull request #10227: Make functions in validation.cpp static: (master...b14-chainparams-validation-static) https://github.com/bitcoin/bitcoin/pull/10227
470 2017-04-21T17:57:21  *** d_t has joined #bitcoin-core-dev
471 2017-04-21T18:02:41  *** d_t has quit IRC
472 2017-04-21T18:05:24  *** Giszmo has quit IRC
473 2017-04-21T18:24:32  *** Lauda has quit IRC
474 2017-04-21T18:28:46  *** moli_ has joined #bitcoin-core-dev
475 2017-04-21T18:28:58  *** d_t has joined #bitcoin-core-dev
476 2017-04-21T19:06:14  *** laurentmt has joined #bitcoin-core-dev
477 2017-04-21T19:06:24  *** laurentmt has quit IRC
478 2017-04-21T19:27:56  *** SopaXorzTaker has quit IRC
479 2017-04-21T19:41:50  *** owowo has quit IRC
480 2017-04-21T19:44:06  *** moli_ has quit IRC
481 2017-04-21T19:44:31  *** moli_ has joined #bitcoin-core-dev
482 2017-04-21T20:00:33  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10254: [Qt] Remove shutdown poll timer and replace it with a signal (master...2017/04/qt_shutdown) https://github.com/bitcoin/bitcoin/pull/10254
483 2017-04-21T20:05:32  <bitcoin-git> [bitcoin] jimmysong opened pull request #10255: [test] Add test for listaddressgroupings (master...test_listaddressgroupings) https://github.com/bitcoin/bitcoin/pull/10255
484 2017-04-21T20:11:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
485 2017-04-21T20:16:51  *** owowo has joined #bitcoin-core-dev
486 2017-04-21T20:16:51  *** owowo has joined #bitcoin-core-dev
487 2017-04-21T20:46:51  <morcos> gmaxwell: i think in practice, the 3 calculations are often quite close.
488 2017-04-21T20:47:09  <morcos> but i wouldn't be concerned if it turned out the target/2 one dominated
489 2017-04-21T20:53:23  *** stoner19 has left #bitcoin-core-dev
490 2017-04-21T20:53:59  <morcos> you can look at each data point (tx and how long it took to get confirmed) as an independent event in which case you would expect the 60% n/2 and 85% n estimates to be roughly the same
491 2017-04-21T20:55:19  <morcos> but also you know they aren't really independent and at the extreme end of that , all you care about is the current tx congestion and what fee rate is being cleared down to
492 2017-04-21T20:56:16  <morcos> the way i looked at it is i could kind of have the best of couple differnet worlds by combining (taking the max) of different estimates
493 2017-04-21T20:57:39  <morcos> the n/2 estimate allows you to react more quickly b/c lets you look at the more recent history for more of the estimates so you'll react more quickly to changing conditions
494 2017-04-21T20:59:04  <morcos> but its important to also have an estimate with a 95% threshold so that you do know that your tx is going to be confirmed within a reasonable time frame..  you don't know if some of the data points were accelerated via special arrangement or CPFP'ed or had other special characteristics
495 2017-04-21T20:59:30  <morcos> also, if you have a long history of 100% of things being concerned, it can take quite some time for estimates to drop
496 2017-04-21T20:59:53  <morcos> man this is hard to walk through on IRC, it kind of sounds so handwavy
497 2017-04-21T21:00:36  *** tw2006 has quit IRC
498 2017-04-21T21:02:13  *** belcher has joined #bitcoin-core-dev
499 2017-04-21T21:03:39  <sipa> haha
500 2017-04-21T21:03:56  *** NewLiberty has joined #bitcoin-core-dev
501 2017-04-21T21:10:01  *** pepe__ has joined #bitcoin-core-dev
502 2017-04-21T21:11:14  *** pepe__ has quit IRC
503 2017-04-21T21:12:00  *** elkalamar has joined #bitcoin-core-dev
504 2017-04-21T21:13:50  *** tw2006 has joined #bitcoin-core-dev
505 2017-04-21T21:15:00  *** tw2006 has quit IRC
506 2017-04-21T21:15:35  *** tw2006 has joined #bitcoin-core-dev
507 2017-04-21T21:53:04  *** NewLiberty has quit IRC
508 2017-04-21T21:56:48  *** NewLiberty has joined #bitcoin-core-dev
509 2017-04-21T22:10:20  *** str4d has joined #bitcoin-core-dev
510 2017-04-21T22:10:39  *** NewLiberty has quit IRC
511 2017-04-21T22:17:26  *** NewLiberty has joined #bitcoin-core-dev
512 2017-04-21T22:20:37  *** tw2006 has quit IRC
513 2017-04-21T22:40:25  <gmaxwell> sipa: is there a reason that the CBlock doesn't cache its hash and redblockfromdisk couldn't use something like CHashverifier to populate it on construction?
514 2017-04-21T22:50:52  *** gm2052 has joined #bitcoin-core-dev
515 2017-04-21T22:52:19  *** Guyver2 has quit IRC
516 2017-04-21T22:54:53  *** gm2051 has quit IRC
517 2017-04-21T23:01:12  <BlueMatt> gmaxwell: not so useful given hash is only 80 bytes...
518 2017-04-21T23:01:21  <BlueMatt> but, it should cache in some way, indeed
519 2017-04-21T23:17:36  <gmaxwell> yea, I guess the hashverifier doesn't really matter for performance due to the size.  I keep thinking it hashes the whole block I dunno why readblock from disk is so slow since it doesn't.
520 2017-04-21T23:21:38  <luke-jr> does it hash every transaction?
521 2017-04-21T23:22:58  <BlueMatt> gmaxwell: we have a benchmark for that because its so damned slow
522 2017-04-21T23:25:13  <instagibbs> why is it so damned slow
523 2017-04-21T23:26:39  *** laurentmt has joined #bitcoin-core-dev
524 2017-04-21T23:27:54  <BlueMatt> instagibbs: you're allocating a metric shitload of objects on the heap
525 2017-04-21T23:30:55  <gmaxwell> oh because of that. right. why do I keep forgetting the allocations.
526 2017-04-21T23:35:52  *** laurentmt has quit IRC
527 2017-04-21T23:37:46  *** laurentmt has joined #bitcoin-core-dev
528 2017-04-21T23:38:38  <gmaxwell> Luke's revised text for the 0.14.2 changes is confusing. :(
529 2017-04-21T23:38:43  <gmaxwell> er 0.14.1
530 2017-04-21T23:39:37  *** NewLiberty_ has joined #bitcoin-core-dev
531 2017-04-21T23:39:42  <gmaxwell> I wish text weren't so hard.
532 2017-04-21T23:40:03  <gmaxwell> Apparently it has people thinking that 0.14.1 change to relay blocks to non-segwit nodes. :( I can see how it's easy to read that way, but didn't notice it before.
533 2017-04-21T23:40:37  <luke-jr> huh? O.o
534 2017-04-21T23:41:42  *** laurentmt has quit IRC
535 2017-04-21T23:42:57  *** NewLiberty has quit IRC
536 2017-04-21T23:59:32  *** abpa has quit IRC