12017-04-21T00:13:10  *** AaronvanW has quit IRC
  22017-04-21T00:16:24  *** AaronvanW has joined #bitcoin-core-dev
  32017-04-21T00:18:02  *** d_t has quit IRC
  42017-04-21T00:19:53  *** tw2006 has joined #bitcoin-core-dev
  52017-04-21T00:29:24  *** jannes has quit IRC
  62017-04-21T00:43:35  *** AaronvanW has quit IRC
  72017-04-21T00:51:14  *** abpa has quit IRC
  82017-04-21T01:00:58  *** Ylbam has quit IRC
  92017-04-21T01:14:01  *** AaronvanW has joined #bitcoin-core-dev
 102017-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.
 112017-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.
 122017-04-21T01:27:32  <michagogo> Isn't that already a thing?
 132017-04-21T01:28:02  *** d9b4bef9 has quit IRC
 142017-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
 152017-04-21T01:29:08  *** d9b4bef9 has joined #bitcoin-core-dev
 162017-04-21T01:30:14  *** AaronvanW has quit IRC
 172017-04-21T01:33:12  <gmaxwell> yea, peter todd's dustbgone
 182017-04-21T01:34:05  <michagogo> Yep, that's the one.
 192017-04-21T01:34:19  <michagogo> BTW, something occurred to me earlier.
 202017-04-21T01:34:46  <michagogo> In the latest update (Creators', I think it was called?) to Windows 10, they upgraded WSL
 212017-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.
 222017-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)
 232017-04-21T01:36:17  <achow101> oh, they updated to xenial? then you can't cross compile from wsl
 242017-04-21T01:36:32  <michagogo> achow101: yeah, for new installations
 252017-04-21T01:36:39  <michagogo> Wait, really?
 262017-04-21T01:36:56  <achow101> mingw on xenial does work IIRC
 272017-04-21T01:37:21  <michagogo> So why can't you cross-compile?
 282017-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
 292017-04-21T01:38:25  <michagogo> Weird.
 302017-04-21T01:38:45  <achow101> michagogo: https://github.com/bitcoin/bitcoin/projects/1
 312017-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?
 322017-04-21T01:39:23  <michagogo> Anyway, what occurred to me was this: Gitian supports virtualbox, right?
 332017-04-21T01:39:29  <achow101> yes
 342017-04-21T01:39:44  <achow101> I don't think it does it well though
 352017-04-21T01:39:51  <michagogo> And I assume vboxmanage works the same (in terms of parameters etc) on Windows and Linux?
 362017-04-21T01:40:27  <achow101> idk. I don't use virtualbox
 372017-04-21T01:40:47  <michagogo> If that is the case, it should (I think?) now be possible to run Gitian from within WSL
 382017-04-21T01:41:11  <achow101> couldn't you already do it with lxc?
 392017-04-21T01:41:59  <michagogo> Can you?
 402017-04-21T01:42:08  <michagogo> I would not expect LXC to work in WSL
 412017-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
 422017-04-21T01:44:05  *** jtimon has quit IRC
 432017-04-21T01:56:42  *** goksinen has joined #bitcoin-core-dev
 442017-04-21T01:58:03  <cfields> Any other gitian builders? Waiting for 1 more sig.
 452017-04-21T02:01:10  *** goksinen has quit IRC
 462017-04-21T02:04:09  <achow101> how many sigs do you need before doing the signed binaries?
 472017-04-21T02:10:26  <luke-jr> https://github.com/bitcoin/bitcoin/pull/7107 should probably be reopened
 482017-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.
 492017-04-21T02:40:13  <michagogo> cfields: mine's building right now
 502017-04-21T02:41:05  <michagogo> dammit, accidentally hit ctrl-c
 512017-04-21T02:42:55  <michagogo> Anyway, managed to get this for Linux: https://www.irccloud.com/pastebin/NPg3fSPm/
 522017-04-21T02:43:12  <michagogo> Restarting the build for Windows and macOS now
 532017-04-21T02:49:35  *** justan0theruser has quit IRC
 542017-04-21T02:50:16  *** justanotheruser has joined #bitcoin-core-dev
 552017-04-21T02:56:53  <cfields> michagogo: thanks!
 562017-04-21T02:58:55  *** Giszmo has quit IRC
 572017-04-21T03:00:21  *** goksinen has joined #bitcoin-core-dev
 582017-04-21T03:03:15  *** gm2052 has joined #bitcoin-core-dev
 592017-04-21T03:03:32  *** PaulCape_ has joined #bitcoin-core-dev
 602017-04-21T03:03:58  *** gm2053 has quit IRC
 612017-04-21T03:03:58  *** PaulCapestany has quit IRC
 622017-04-21T03:05:05  *** goksinen has quit IRC
 632017-04-21T03:06:14  *** n1ce has quit IRC
 642017-04-21T03:07:03  *** n1ce has joined #bitcoin-core-dev
 652017-04-21T03:09:25  *** n1ce has quit IRC
 662017-04-21T03:10:16  *** n1ce has joined #bitcoin-core-dev
 672017-04-21T03:10:58  *** AaronvanW has joined #bitcoin-core-dev
 682017-04-21T03:15:23  *** AaronvanW has quit IRC
 692017-04-21T03:18:20  <michagogo> cfields: https://www.irccloud.com/pastebin/XrNoFzY5/
 702017-04-21T03:20:11  *** Giszmo has joined #bitcoin-core-dev
 712017-04-21T03:25:12  *** justan0theruser has joined #bitcoin-core-dev
 722017-04-21T03:25:39  *** n1ce has quit IRC
 732017-04-21T03:27:47  *** justanotheruser has quit IRC
 742017-04-21T03:35:00  *** waxwing has quit IRC
 752017-04-21T03:47:20  *** waxwing has joined #bitcoin-core-dev
 762017-04-21T03:49:00  *** tw2006 has quit IRC
 772017-04-21T04:20:49  <michagogo> cfields: PR up now
 782017-04-21T04:26:09  <cfields> michagogo: thanks!
 792017-04-21T04:27:27  *** harrymm has quit IRC
 802017-04-21T04:31:29  <cfields> gitian builders: detached sigs pushed for 0.14.1
 812017-04-21T04:32:46  *** harrymm has joined #bitcoin-core-dev
 822017-04-21T04:41:41  <michagogo> Oops.
 832017-04-21T04:42:15  <michagogo> I was running a while ! loop on the script to do the signed build
 842017-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
 852017-04-21T04:49:57  *** tw2006 has joined #bitcoin-core-dev
 862017-04-21T04:54:48  *** tw2006 has quit IRC
 872017-04-21T04:57:23  *** d_t has joined #bitcoin-core-dev
 882017-04-21T05:11:39  *** AaronvanW has joined #bitcoin-core-dev
 892017-04-21T05:17:19  *** AaronvanW has quit IRC
 902017-04-21T05:29:01  *** d9b4bef9 has quit IRC
 912017-04-21T05:32:08  *** d9b4bef9 has joined #bitcoin-core-dev
 922017-04-21T05:39:54  *** arubi_ is now known as arubi
 932017-04-21T05:56:37  *** Ylbam has joined #bitcoin-core-dev
 942017-04-21T06:01:29  *** str4d has joined #bitcoin-core-dev
 952017-04-21T06:32:23  *** RubenSomsen has joined #bitcoin-core-dev
 962017-04-21T06:32:57  *** SopaXorzTaker has joined #bitcoin-core-dev
 972017-04-21T06:38:51  *** tw2006 has joined #bitcoin-core-dev
 982017-04-21T06:43:47  *** tw2006 has quit IRC
 992017-04-21T06:48:28  *** gm2053 has joined #bitcoin-core-dev
1002017-04-21T06:49:52  *** gm2051 has joined #bitcoin-core-dev
1012017-04-21T06:52:24  *** gm2052 has quit IRC
1022017-04-21T06:53:19  *** gm2053 has quit IRC
1032017-04-21T06:58:58  *** BashCo has quit IRC
1042017-04-21T07:08:02  *** goksinen has joined #bitcoin-core-dev
1052017-04-21T07:12:57  *** goksinen has quit IRC
1062017-04-21T07:17:16  *** BashCo has joined #bitcoin-core-dev
1072017-04-21T07:34:40  *** chatter29 has joined #bitcoin-core-dev
1082017-04-21T07:34:52  <chatter29> hey guys
1092017-04-21T07:34:54  <chatter29> allah is doing
1102017-04-21T07:34:59  <chatter29> sun is not doing allah is doing
1112017-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
1122017-04-21T07:35:06  *** chatter29 has quit IRC
1132017-04-21T08:02:17  *** goksinen has joined #bitcoin-core-dev
1142017-04-21T08:04:19  *** CubicEarth has joined #bitcoin-core-dev
1152017-04-21T08:07:04  *** goksinen has quit IRC
1162017-04-21T08:13:19  <CubicEarth> Should the default keypool size be increased to 1000?
1172017-04-21T08:13:24  *** jannes has joined #bitcoin-core-dev
1182017-04-21T08:14:01  <CubicEarth> Or is HD the new default?
1192017-04-21T08:27:49  *** tw2006 has joined #bitcoin-core-dev
1202017-04-21T08:32:19  *** tw2006 has quit IRC
1212017-04-21T08:34:53  *** CubicEarth has quit IRC
1222017-04-21T08:40:58  *** gm2052 has joined #bitcoin-core-dev
1232017-04-21T08:42:19  *** molz_ has joined #bitcoin-core-dev
1242017-04-21T08:44:19  *** gm2051 has quit IRC
1252017-04-21T08:45:05  *** mol has quit IRC
1262017-04-21T08:47:43  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86ea3c2ff247...694062eafec5
1272017-04-21T08:47:43  <bitcoin-git> bitcoin/master 0611bc3 Shigeya Suzuki: Minor fix in build documentation for FreeBSD 11...
1282017-04-21T08:47:44  <bitcoin-git> bitcoin/master 694062e Wladimir J. van der Laan: Merge #10245: Minor fix in build documentation for FreeBSD 11...
1292017-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
1302017-04-21T08:54:10  *** gm2053 has joined #bitcoin-core-dev
1312017-04-21T08:56:32  *** goksinen has joined #bitcoin-core-dev
1322017-04-21T08:57:04  *** gm2051 has joined #bitcoin-core-dev
1332017-04-21T08:57:15  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/694062eafec5...0416ea9f743f
1342017-04-21T08:57:15  <bitcoin-git> bitcoin/master 394ccf7 Pieter Wuille: Make Boost use std::atomic internally
1352017-04-21T08:57:16  <bitcoin-git> bitcoin/master 0416ea9 Wladimir J. van der Laan: Merge #10239: Make Boost use std::atomic internally...
1362017-04-21T08:57:29  *** gm2052 has quit IRC
1372017-04-21T08:57:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0416ea9f743f...f6f3b58a7250
1382017-04-21T08:57:36  <bitcoin-git> bitcoin/master fb463d1 Russell Yanofsky: [qt] Don't call method on null WalletModel object...
1392017-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...
1402017-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
1412017-04-21T08:59:46  *** gm2053 has quit IRC
1422017-04-21T09:01:09  *** goksinen has quit IRC
1432017-04-21T09:12:47  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6f3b58a7250...27faa6cccd8d
1442017-04-21T09:12:48  <bitcoin-git> bitcoin/master 3577603 Cory Fields: build: remove wonky auto top-level convenience targets...
1452017-04-21T09:12:49  <bitcoin-git> bitcoin/master 91ab8f5 Cory Fields: build: fix bitcoin-config.h regeneration after touching build files...
1462017-04-21T09:12:49  <bitcoin-git> bitcoin/master 27faa6c Wladimir J. van der Laan: Merge #10228: build: regenerate bitcoin-config.h as necessary...
1472017-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
1482017-04-21T09:14:13  *** AaronvanW has joined #bitcoin-core-dev
1492017-04-21T09:15:47  *** SopaXorzTaker has quit IRC
1502017-04-21T09:19:10  *** AaronvanW has quit IRC
1512017-04-21T09:19:58  *** SopaXorzTaker has joined #bitcoin-core-dev
1522017-04-21T09:38:08  * wumpus still deleting "qa" directories everywhere :-)
1532017-04-21T09:43:08  *** jtimon has joined #bitcoin-core-dev
1542017-04-21T09:50:53  *** goksinen has joined #bitcoin-core-dev
1552017-04-21T09:55:20  *** goksinen has quit IRC
1562017-04-21T10:04:57  *** AaronvanW has joined #bitcoin-core-dev
1572017-04-21T10:04:57  *** AaronvanW has joined #bitcoin-core-dev
1582017-04-21T10:09:40  *** laurentmt has joined #bitcoin-core-dev
1592017-04-21T10:14:35  *** d_t has quit IRC
1602017-04-21T10:16:42  *** tw2006 has joined #bitcoin-core-dev
1612017-04-21T10:21:22  *** tw2006 has quit IRC
1622017-04-21T10:44:59  *** goksinen has joined #bitcoin-core-dev
1632017-04-21T10:49:39  *** goksinen has quit IRC
1642017-04-21T10:54:37  *** elkalamar has quit IRC
1652017-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
1662017-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
1672017-04-21T11:01:09  <jonasschnelli> I like it
1682017-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.
1692017-04-21T11:15:05  *** nu11p7r has quit IRC
1702017-04-21T11:17:10  *** BashCo has quit IRC
1712017-04-21T11:18:38  *** laurentmt has quit IRC
1722017-04-21T11:19:59  *** BashCo has joined #bitcoin-core-dev
1732017-04-21T11:20:40  <wumpus> yes it's difficult to do a big change like thta
1742017-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.
1752017-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
1762017-04-21T11:23:14  <wumpus> along with using async notifications for replies from the core instead of synchronous calls and busy-waiting on locks
1772017-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
1782017-04-21T11:26:09  <wumpus> though I have a hard time reviewing code changes that aren't in line with my own thoughts
1792017-04-21T11:26:17  <wumpus> especially big ones
1802017-04-21T11:26:31  <sipa> wumpus: is your concern that the result makes the client/walletmodel less independent?
1812017-04-21T11:26:46  <sipa> in that it now requires the IPC abstraction below it
1822017-04-21T11:27:12  <wumpus> sipa: mostly that the code becomes even harder to work on
1832017-04-21T11:27:46  <wumpus> it seems like a double abstraction; walletmodel is already an abstraction for core's CWallet
1842017-04-21T11:27:49  <wumpus> now there's a class in between
1852017-04-21T11:29:11  <sipa> seems like a reasonable concern to me... WalletModel and ClientModel don't really have much responsibility anymore
1862017-04-21T11:29:28  <wumpus> the best way to implement remote-anything is not necessarily changing every direct call into a IPC call
1872017-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
1882017-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
1892017-04-21T11:31:20  <wumpus> I'm much more concerned with that than IPCing everything
1902017-04-21T11:31:26  <sipa> seems reasonable, i don't know much about that
1912017-04-21T11:31:50  <wumpus> so this is kind of calcifying the state of the code that I'm already not happy with
1922017-04-21T11:35:04  <jonasschnelli> wumpus: I completely agree with you.
1932017-04-21T11:35:43  <jonasschnelli> I think it will be very hard to change the GUI towards that goal with the current review strategy
1942017-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.
1952017-04-21T11:36:33  <jonasschnelli> Also the split between Wallet and Node (walletmodal / clientmodel) makes really sense.
1962017-04-21T11:36:39  <jonasschnelli> *model
1972017-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
1982017-04-21T11:37:59  <jonasschnelli> I often though maybe rewrite the GUI from the ground up,...
1992017-04-21T11:38:02  <wumpus> and will likely be less complex
2002017-04-21T11:38:40  <wumpus> I'm not sure that is a good idea
2012017-04-21T11:38:50  <jonasschnelli> Yeah.. me neither... :)
2022017-04-21T11:38:59  <wumpus> a rewrite is a lot of work to get feature parity, all bugs are born new, etc
2032017-04-21T11:39:17  <wumpus> usually I prefer incremental improvements unless something is total junk, which I think the code is not
2042017-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
2052017-04-21T11:39:38  <wumpus> sipa: not the way he's doing it, at least
2062017-04-21T11:39:45  <wumpus> in the way I always imagined doing it, it would
2072017-04-21T11:39:51  <jonasschnelli> What design would make sense for asynchronous messages?
2082017-04-21T11:40:22  <wumpus> jonasschnelli: qt signals/slots? same way that RPCConsole and RPCThread communicate for example
2092017-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?
2102017-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
2112017-04-21T11:41:32  <wumpus> one thread should be OK usually
2122017-04-21T11:42:00  *** gm2052 has joined #bitcoin-core-dev
2132017-04-21T11:42:36  <wumpus> long running operations could be their own thread
2142017-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
2152017-04-21T11:42:51  <wumpus> right
2162017-04-21T11:43:11  <jonasschnelli> reminds me that the RPCConcole/RPCThread missed a activity indicator...
2172017-04-21T11:43:22  <wumpus> heck, even changing the cursor to a bee as on the Atari ST is better than hanging the GUI
2182017-04-21T11:43:22  <jonasschnelli> (things like topupkeypool 1000)
2192017-04-21T11:43:30  <jonasschnelli> wumpus: haha
2202017-04-21T11:43:55  <wumpus> yes, indeed, it doesn't provide feedback that something is in progress
2212017-04-21T11:43:59  <jonasschnelli> Yes. We could start with a general activity indicator ("node communication happening") in the status bar
2222017-04-21T11:44:21  <jonasschnelli> I hope we can convince ryanofsky
2232017-04-21T11:44:23  <wumpus> in any case showing a modal dialog is still possible
2242017-04-21T11:44:31  <wumpus> if you don't want the user to do other things
2252017-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
2262017-04-21T11:45:30  <jonasschnelli> Yes. The modal non blocking concept is much better
2272017-04-21T11:45:45  <jonasschnelli> Blocking the GUI must be avoided any time
2282017-04-21T11:45:50  *** gm2051 has quit IRC
2292017-04-21T11:45:56  <jonasschnelli> Otherwise users will force quite
2302017-04-21T11:46:02  <jonasschnelli> force kill
2312017-04-21T11:46:04  <wumpus> right. And some OSes will blank out the window
2322017-04-21T11:52:19  *** Guyver2 has joined #bitcoin-core-dev
2332017-04-21T11:53:42  *** BCBot has quit IRC
2342017-04-21T11:54:01  *** BCBot has joined #bitcoin-core-dev
2352017-04-21T11:54:59  *** belcher has quit IRC
2362017-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
2372017-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
2382017-04-21T12:05:38  *** tw2006 has joined #bitcoin-core-dev
2392017-04-21T12:07:43  *** belcher has joined #bitcoin-core-dev
2402017-04-21T12:10:44  *** tw2006 has quit IRC
2412017-04-21T12:11:28  <wumpus> I know I myself have way too many ideas and too little time to work on them
2422017-04-21T12:12:29  *** str4d has quit IRC
2432017-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
2442017-04-21T12:13:23  *** nu11p7r has joined #bitcoin-core-dev
2452017-04-21T12:13:29  <sipa> if that requires an extra abstraction layer somewhere, fine
2462017-04-21T12:13:43  <sipa> but i'm not convinced why that abstraction layer can't be clientmodel/walletmodel
2472017-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.
2482017-04-21T12:24:17  <jonasschnelli> Which I partially can follow
2492017-04-21T12:25:04  <sipa> well that business logic should move to the core
2502017-04-21T12:25:24  <sipa> some of it can likely be merged with some code in rpcwallet
2512017-04-21T12:27:45  <luke-jr> Random reddit user suggests that txindex should default to on when pruning is disabled.
2522017-04-21T12:28:26  <sipa> ...?
2532017-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
2542017-04-21T12:29:10  <sipa> it's huge compared to the utxo set
2552017-04-21T12:29:16  <luke-jr> https://www.reddit.com/r/Bitcoin/comments/66k36g/why_does_electrum_need_special_servers/dgjtg54/?context=3
2562017-04-21T12:29:24  <sipa> and people shouldn't rely on having a txindex available
2572017-04-21T12:29:36  <luke-jr> I don't think it's avoidable for Electrum
2582017-04-21T12:29:57  <sipa> i think electrum server should have a specialized node for that, not rely on bitcoind
2592017-04-21T12:30:00  <sipa> but ok
2602017-04-21T12:30:09  <sipa> still doesn't mean everyone needs that
2612017-04-21T12:30:09  <jonasschnelli> You suggesting making it default in order to be able to run an electrum server?
2622017-04-21T12:30:29  <luke-jr> jonasschnelli: relatively low cost, and high benefit to users who want to use Electrum
2632017-04-21T12:30:50  <luke-jr> sipa: not everyone needs BLOOM, but we have it enabled by default
2642017-04-21T12:30:50  <jonasschnelli> Well,... a reindex with txindex takes a day or so?
2652017-04-21T12:31:06  <luke-jr> true
2662017-04-21T12:31:14  <jonasschnelli> bloom is network, txindex is loca
2672017-04-21T12:31:18  <jonasschnelli> +l
2682017-04-21T12:31:29  <luke-jr> jonasschnelli: txindex is used for Electrum network protocol
2692017-04-21T12:31:35  <sipa> luke-jr: the way i see it, i'd have removed txindex support entirely with ultraprune
2702017-04-21T12:31:52  <jonasschnelli> Yes. Just saying offering bloom is something you do for the public, txindex is local
2712017-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
2722017-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
2732017-04-21T12:32:38  <sipa> but it's not optimized for it at all
2742017-04-21T12:33:11  *** goksinen has joined #bitcoin-core-dev
2752017-04-21T12:33:13  <luke-jr> perhaps not, but users care less about that than how easy it is to get things going
2762017-04-21T12:33:37  <sipa> maybe we should create a separate tool that indexes the chain in a decent way
2772017-04-21T12:33:42  <sipa> without doing validation etc
2782017-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
2792017-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.
2802017-04-21T12:37:35  *** goksinen has quit IRC
2812017-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
2822017-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
2832017-04-21T12:39:35  <luke-jr> I suspect there are more Electrum users than Core-wallet users, sadly
2842017-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
2852017-04-21T12:40:25  <luke-jr> everyone using Electrum should be running their own Electrum server
2862017-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
2872017-04-21T12:41:43  <luke-jr> need an index on the whole blockchain to get tx history
2882017-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
2892017-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
2902017-04-21T12:44:56  <sipa> also, doesn't electrum full history require addrindex even?
2912017-04-21T12:44:58  <sipa> not just txindex?
2922017-04-21T12:45:02  <luke-jr> sipa: many people use Electrum because it supports hardware wallets
2932017-04-21T12:45:20  <luke-jr> and yes, Electrum's server generates that itself from the txindex
2942017-04-21T12:45:31  <sipa> then why can't it create the txindex too?
2952017-04-21T12:45:43  <luke-jr> not sure.
2962017-04-21T12:46:02  <sipa> luke-jr: well electrum uses a model that makes it inherently more expensive to run a server
2972017-04-21T12:46:23  <luke-jr> sipa: depends whether storage/indexing costs more than doing the filtering on-the-fly for bloom nodes
2982017-04-21T12:46:25  <sipa> stupid "the blockchain is my wallet model"
2992017-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
3002017-04-21T12:46:35  <luke-jr> indexes are far less expensive than filtering for each user
3012017-04-21T12:46:59  <sipa> luke-jr: my view is that end users shouldn't need the full blockchain
3022017-04-21T12:47:08  <sipa> much less so a fully indexed one
3032017-04-21T12:47:34  <sipa> i understand electrum has advantages, but there must be ways to get them without burdening full nodes further
3042017-04-21T12:47:46  <luke-jr> sipa: not sure that's avoidable
3052017-04-21T12:47:59  <sipa> finding your old transactions should be a rare occurence
3062017-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
3072017-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
3082017-04-21T12:48:33  <luke-jr> wumpus: yes, in theory
3092017-04-21T12:48:47  <wumpus> luke-jr: everyoen running their own electrum server is theory just as well
3102017-04-21T12:48:55  <wumpus> luke-jr: and a much more overhead one at that
3112017-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
3122017-04-21T12:49:05  <wumpus> why would everyone need to index everyone's transactions?
3132017-04-21T12:49:07  <wumpus> that's just crazy
3142017-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
3152017-04-21T12:52:09  <sipa> an ecosystem that relies on everyone having the full blockchain available is disaster for scalability
3162017-04-21T12:52:21  <wumpus> in any case txindex is already supported, people can use it if they want
3172017-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
3182017-04-21T12:53:27  <sipa> maybe instead we should make pruning default :)
3192017-04-21T12:53:33  <instagibbs> ^ was about tot say that
3202017-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
3212017-04-21T12:54:17  <luke-jr> sipa: IMO wait until we can IBD from pruned nodes
3222017-04-21T12:54:19  <sdaftuar> sipa: lets merge that default to motivate block download improvements for 0.15 :)
3232017-04-21T12:54:30  <sipa> luke-jr: fair point
3242017-04-21T12:54:54  <luke-jr> I did make a pruning GUI for Knots, but it uses rwconf :x
3252017-04-21T12:57:43  <wumpus> I think offering a choice in the initial GUI dialog would already be nice
3262017-04-21T12:57:56  <sipa> agree
3272017-04-21T12:58:05  <wumpus> (the one that lets you choose the data directory and shows an estimate of disk usage)
3282017-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.
3292017-04-21T12:59:12  <wumpus> it's trivially possible to go from non-pruned to pruned, the other way around can be expensive
3302017-04-21T13:00:06  <wumpus> sure if e.g. the machine has little disk space it can be encouraged strongly to prune
3312017-04-21T13:00:20  <wumpus> just think it should not be enabled silently
3322017-04-21T13:00:25  *** tw2006 has joined #bitcoin-core-dev
3332017-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
3342017-04-21T13:02:00  <luke-jr> wumpus: Knots firstrun: http://i.imgur.com/mKTQrVb.png http://i.imgur.com/jopLsLQ.png
3352017-04-21T13:02:07  <sipa> in the GUI, a wizard setup dialog the first time that asks you seems nice
3362017-04-21T13:02:18  <wumpus> luke-jr: exactly
3372017-04-21T13:02:36  <luke-jr> perhaps I should re-PR rwconf without the GUI stuff?
3382017-04-21T13:02:43  <sipa> what is rwconf?
3392017-04-21T13:02:47  <luke-jr> although I guess that doesn't help get it to Intro
3402017-04-21T13:02:56  <luke-jr> sipa: bitcoin_rw.conf file that the software modifies
3412017-04-21T13:03:13  <sipa> which is also used by bitcoind?
3422017-04-21T13:03:20  <luke-jr> Knots bitcoind, yes
3432017-04-21T13:03:22  <wumpus> luke-jr: is that file at least in the per-network directory?
3442017-04-21T13:03:43  <luke-jr> wumpus: yes
3452017-04-21T13:03:47  <jonasschnelli> I once started a new GUI wizard with pruning: https://github.com/jonasschnelli/bitcoin/commit/7d8798d4942b7d7980a4c4f90cdd714432696ea7
3462017-04-21T13:03:49  <wumpus> luke-jr: great
3472017-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
3482017-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
3492017-04-21T13:05:16  <jonasschnelli> The idea of the branch above was to ask about pruning / dbcache / folder (what we have right now)
3502017-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
3512017-04-21T13:05:56  <wumpus> but if it doesn't write bitcoin.conf, well, it's not too bad
3522017-04-21T13:06:00  <luke-jr> right, that's why it was an independent file
3532017-04-21T13:06:03  <sipa> maybe we should go back to serializing settings into wallet.dat
3542017-04-21T13:06:03  <wumpus> right
3552017-04-21T13:06:04  * sipa ducks
3562017-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
3572017-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?
3582017-04-21T13:10:02  <luke-jr>  * [new tag]         v0.14.1.knots20170420 -> v0.14.1.knots20170420 <-- gitian builds please ☺
3592017-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
3602017-04-21T13:12:04  <wumpus> ok, will build
3612017-04-21T13:39:46  <luke-jr> thx
3622017-04-21T13:50:30  *** d_t has joined #bitcoin-core-dev
3632017-04-21T13:59:43  *** mol has joined #bitcoin-core-dev
3642017-04-21T14:02:57  *** molz_ has quit IRC
3652017-04-21T14:09:26  <jonasschnelli> Using lambdas in Qt is a no go? Right? It would break Qt4 compile compat?
3662017-04-21T14:10:18  <sipa> you cant use c++11 lambdas?
3672017-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...
3682017-04-21T14:11:02  <jonasschnelli> not sure though
3692017-04-21T14:19:01  <sipa> a lambda is just a function object
3702017-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
3712017-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)
3722017-04-21T14:21:28  <sipa> oh
3732017-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?
3742017-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
3752017-04-21T14:23:49  <jonasschnelli> Chris_Stewart_5: correct
3762017-04-21T14:24:31  <jonasschnelli> The L28 above makes a copy of the Key, right?
3772017-04-21T14:25:16  <Chris_Stewart_5> From my understanding of it, yes. However it seems like i could scope it with '&'
3782017-04-21T14:26:05  *** fao1 has quit IRC
3792017-04-21T14:26:29  *** fao1 has joined #bitcoin-core-dev
3802017-04-21T14:26:36  *** molz_ has joined #bitcoin-core-dev
3812017-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
3822017-04-21T14:28:03  <sipa> Chris_Stewart_5: that lambda does not capture anything...
3832017-04-21T14:28:59  *** Giszmo has quit IRC
3842017-04-21T14:29:01  <sipa> [&] will have no effect
3852017-04-21T14:29:23  *** mol has quit IRC
3862017-04-21T14:29:37  <sipa> if you want the parameter key to be by reference, you just make it Key& key
3872017-04-21T14:31:45  <sipa> [=] and [&] control the capture list, not the parameter list
3882017-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?
3892017-04-21T14:32:15  <Chris_Stewart_5> by default it copies that global variable if you just provide '[]'?
3902017-04-21T14:32:34  <sipa> if you provide [], it does not capture anything
3912017-04-21T14:32:52  <sipa> if you provide [=] it captures everything, by value
3922017-04-21T14:33:04  *** gm2053 has joined #bitcoin-core-dev
3932017-04-21T14:33:12  <sipa> if you provide [&] it captures everything, by reference
3942017-04-21T14:34:05  *** RubenSomsen has quit IRC
3952017-04-21T14:34:56  <Chris_Stewart_5> Thanks for the explanation. That clears up a lot wrt to lambdas for me.
3962017-04-21T14:35:22  *** gm2051 has joined #bitcoin-core-dev
3972017-04-21T14:36:09  <sipa> Chris_Stewart_5: http://en.cppreference.com/w/cpp/language/lambda
3982017-04-21T14:36:50  *** gm2052 has quit IRC
3992017-04-21T14:38:19  *** gm2053 has quit IRC
4002017-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
4012017-04-21T14:42:56  <ryanofsky> asynchronously meaning the closure is copied and called after the lambda expression goes out of scope
4022017-04-21T14:43:24  *** belcher has quit IRC
4032017-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
4042017-04-21T14:44:04  <sipa> ryanofsky: that's a nice convention
4052017-04-21T14:44:25  <sipa> ryanofsky: is there a way to construct a non-copyable lambda?
4062017-04-21T14:45:11  <ryanofsky> in c++14 there definitely is because you can capture by move
4072017-04-21T14:45:34  <ryanofsky> so the resulting closure is move-only
4082017-04-21T14:46:17  <ryanofsky> otherwise i don't think you can do it directly without std::bind or something
4092017-04-21T14:46:59  <sipa> which incurs a performance penalty?
4102017-04-21T14:47:51  <ryanofsky> yeah, probably minor unless lambda is capturing a lot of variables or a very big struct by copy
4112017-04-21T14:48:30  *** luke-jr has quit IRC
4122017-04-21T14:49:16  *** RubenSomsen has joined #bitcoin-core-dev
4132017-04-21T14:57:28  *** luke-jr has joined #bitcoin-core-dev
4142017-04-21T15:00:32  *** BashCo has quit IRC
4152017-04-21T15:09:17  *** fao1 has quit IRC
4162017-04-21T15:13:26  *** fao1 has joined #bitcoin-core-dev
4172017-04-21T15:14:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/27faa6cccd8d...f3db4c601385
4182017-04-21T15:14:32  <bitcoin-git> bitcoin/master 821dd5e Jimmy Song: Tests: Add test for getdifficulty...
4192017-04-21T15:14:32  <bitcoin-git> bitcoin/master f3db4c6 Wladimir J. van der Laan: Merge #10229: Tests: Add test for getdifficulty...
4202017-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
4212017-04-21T15:17:27  *** fao1 has quit IRC
4222017-04-21T15:21:07  *** BashCo has joined #bitcoin-core-dev
4232017-04-21T15:30:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f3db4c601385...5352e5e75da9
4242017-04-21T15:30:04  <bitcoin-git> bitcoin/master c39a6b9 Jimmy Song: Tests: Refactor to create witness script creation function...
4252017-04-21T15:30:05  <bitcoin-git> bitcoin/master 5352e5e Wladimir J. van der Laan: Merge #10223: Tests: Refactor to create witness script creation function...
4262017-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
4272017-04-21T15:32:14  *** stoner19 has joined #bitcoin-core-dev
4282017-04-21T15:32:31  <stoner19> can anyone link me to the actual code for segwit in bitcoin core?
4292017-04-21T15:33:18  *** RubenSomsen has quit IRC
4302017-04-21T15:33:34  *** Giszmo has joined #bitcoin-core-dev
4312017-04-21T15:33:49  *** RubenSomsen has joined #bitcoin-core-dev
4322017-04-21T15:34:24  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5352e5e75da9...1428f3030d99
4332017-04-21T15:34:24  <bitcoin-git> bitcoin/master f478d98 Pieter Wuille: Fix some empty vector references...
4342017-04-21T15:34:25  <bitcoin-git> bitcoin/master 1428f30 Wladimir J. van der Laan: Merge #10250: Fix some empty vector references...
4352017-04-21T15:34:28  <sipa> stoner19: what part? consensus logic? p2p protocol changes? signing code for transactions?
4362017-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
4372017-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?
4382017-04-21T15:35:16  <sipa> stoner19: signalling is 1 line of code, just changing the block nversion
4392017-04-21T15:36:08  <sipa> stoner19: https://github.com/bitcoin/bitcoin/pull/8149/commits
4402017-04-21T15:36:32  <stoner19> oh that helps significantly thank you
4412017-04-21T15:38:39  *** RubenSomsen has quit IRC
4422017-04-21T15:49:34  *** abpa has joined #bitcoin-core-dev
4432017-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
4442017-04-21T15:51:49  <morcos> It's a bit more thorough description than is included in #10199
4452017-04-21T15:51:51  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
4462017-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
4472017-04-21T16:26:07  *** molz_ has quit IRC
4482017-04-21T16:42:43  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1428f3030d99...a6548a47a554
4492017-04-21T16:42:43  <bitcoin-git> bitcoin/master 25660e9 Mario Dian: pass Consensus::Params& to ReceivedBlockTransactions()
4502017-04-21T16:42:44  <bitcoin-git> bitcoin/master a6548a4 Wladimir J. van der Laan: Merge #10201: pass Consensus::Params& to ReceivedBlockTransactions()...
4512017-04-21T16:44:03  <achow101> has 0.14.1 been officially released yet? or still waiting on gitian sigs?
4522017-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
4532017-04-21T16:46:33  <luke-jr> achow101: thanks for the reminder to build signed bins :D
4542017-04-21T16:51:40  <gmaxwell> morcos: 60% threshold at target/2
4552017-04-21T16:51:42  <gmaxwell> 85% threshold at target
4562017-04-21T16:52:21  <gmaxwell> so do we have any reason to expect that the 60% at target/2 won't dominate the estimate?
4572017-04-21T16:55:31  *** Guest12838 has quit IRC
4582017-04-21T16:59:44  *** Guest12838 has joined #bitcoin-core-dev
4592017-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
4602017-04-21T17:05:36  *** Giszmo has quit IRC
4612017-04-21T17:19:08  *** fao1 has joined #bitcoin-core-dev
4622017-04-21T17:20:08  *** Chris_Stewart_5 has quit IRC
4632017-04-21T17:31:54  *** kadoban has joined #bitcoin-core-dev
4642017-04-21T17:33:21  *** Giszmo has joined #bitcoin-core-dev
4652017-04-21T17:37:13  *** gielbier has quit IRC
4662017-04-21T17:49:18  *** jtimon_ has joined #bitcoin-core-dev
4672017-04-21T17:49:41  *** gielbier has joined #bitcoin-core-dev
4682017-04-21T17:50:28  <jtimon_> wumpus: it seems you added a commit to https://github.com/bitcoin/bitcoin/pull/10201 by mistake?
4692017-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
4702017-04-21T17:57:21  *** d_t has joined #bitcoin-core-dev
4712017-04-21T18:02:41  *** d_t has quit IRC
4722017-04-21T18:05:24  *** Giszmo has quit IRC
4732017-04-21T18:24:32  *** Lauda has quit IRC
4742017-04-21T18:28:46  *** moli_ has joined #bitcoin-core-dev
4752017-04-21T18:28:58  *** d_t has joined #bitcoin-core-dev
4762017-04-21T19:06:14  *** laurentmt has joined #bitcoin-core-dev
4772017-04-21T19:06:24  *** laurentmt has quit IRC
4782017-04-21T19:27:56  *** SopaXorzTaker has quit IRC
4792017-04-21T19:41:50  *** owowo has quit IRC
4802017-04-21T19:44:06  *** moli_ has quit IRC
4812017-04-21T19:44:31  *** moli_ has joined #bitcoin-core-dev
4822017-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
4832017-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
4842017-04-21T20:11:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4852017-04-21T20:16:51  *** owowo has joined #bitcoin-core-dev
4862017-04-21T20:16:51  *** owowo has joined #bitcoin-core-dev
4872017-04-21T20:46:51  <morcos> gmaxwell: i think in practice, the 3 calculations are often quite close.
4882017-04-21T20:47:09  <morcos> but i wouldn't be concerned if it turned out the target/2 one dominated
4892017-04-21T20:53:23  *** stoner19 has left #bitcoin-core-dev
4902017-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
4912017-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
4922017-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
4932017-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
4942017-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
4952017-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
4962017-04-21T20:59:53  <morcos> man this is hard to walk through on IRC, it kind of sounds so handwavy
4972017-04-21T21:00:36  *** tw2006 has quit IRC
4982017-04-21T21:02:13  *** belcher has joined #bitcoin-core-dev
4992017-04-21T21:03:39  <sipa> haha
5002017-04-21T21:03:56  *** NewLiberty has joined #bitcoin-core-dev
5012017-04-21T21:10:01  *** pepe__ has joined #bitcoin-core-dev
5022017-04-21T21:11:14  *** pepe__ has quit IRC
5032017-04-21T21:12:00  *** elkalamar has joined #bitcoin-core-dev
5042017-04-21T21:13:50  *** tw2006 has joined #bitcoin-core-dev
5052017-04-21T21:15:00  *** tw2006 has quit IRC
5062017-04-21T21:15:35  *** tw2006 has joined #bitcoin-core-dev
5072017-04-21T21:53:04  *** NewLiberty has quit IRC
5082017-04-21T21:56:48  *** NewLiberty has joined #bitcoin-core-dev
5092017-04-21T22:10:20  *** str4d has joined #bitcoin-core-dev
5102017-04-21T22:10:39  *** NewLiberty has quit IRC
5112017-04-21T22:17:26  *** NewLiberty has joined #bitcoin-core-dev
5122017-04-21T22:20:37  *** tw2006 has quit IRC
5132017-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?
5142017-04-21T22:50:52  *** gm2052 has joined #bitcoin-core-dev
5152017-04-21T22:52:19  *** Guyver2 has quit IRC
5162017-04-21T22:54:53  *** gm2051 has quit IRC
5172017-04-21T23:01:12  <BlueMatt> gmaxwell: not so useful given hash is only 80 bytes...
5182017-04-21T23:01:21  <BlueMatt> but, it should cache in some way, indeed
5192017-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.
5202017-04-21T23:21:38  <luke-jr> does it hash every transaction?
5212017-04-21T23:22:58  <BlueMatt> gmaxwell: we have a benchmark for that because its so damned slow
5222017-04-21T23:25:13  <instagibbs> why is it so damned slow
5232017-04-21T23:26:39  *** laurentmt has joined #bitcoin-core-dev
5242017-04-21T23:27:54  <BlueMatt> instagibbs: you're allocating a metric shitload of objects on the heap
5252017-04-21T23:30:55  <gmaxwell> oh because of that. right. why do I keep forgetting the allocations.
5262017-04-21T23:35:52  *** laurentmt has quit IRC
5272017-04-21T23:37:46  *** laurentmt has joined #bitcoin-core-dev
5282017-04-21T23:38:38  <gmaxwell> Luke's revised text for the 0.14.2 changes is confusing. :(
5292017-04-21T23:38:43  <gmaxwell> er 0.14.1
5302017-04-21T23:39:37  *** NewLiberty_ has joined #bitcoin-core-dev
5312017-04-21T23:39:42  <gmaxwell> I wish text weren't so hard.
5322017-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.
5332017-04-21T23:40:37  <luke-jr> huh? O.o
5342017-04-21T23:41:42  *** laurentmt has quit IRC
5352017-04-21T23:42:57  *** NewLiberty has quit IRC
5362017-04-21T23:59:32  *** abpa has quit IRC