12017-07-11T00:21:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  22017-07-11T00:36:00  *** Ylbam has quit IRC
  32017-07-11T00:49:48  *** chjj has quit IRC
  42017-07-11T01:01:55  *** chjj has joined #bitcoin-core-dev
  52017-07-11T01:12:39  *** AaronvanW has joined #bitcoin-core-dev
  62017-07-11T01:13:47  *** BashCo has quit IRC
  72017-07-11T01:13:52  *** AaronvanW has quit IRC
  82017-07-11T01:14:22  *** BashCo has joined #bitcoin-core-dev
  92017-07-11T01:15:35  *** Aaronva__ has quit IRC
 102017-07-11T01:29:15  *** Murch has quit IRC
 112017-07-11T01:35:15  <bitcoin-git> [bitcoin] achow101 opened pull request #10788: Replace ismine with producesignature check in witnessifier (master...fix-addwitnessaddress) https://github.com/bitcoin/bitcoin/pull/10788
 122017-07-11T01:40:05  *** str4d has joined #bitcoin-core-dev
 132017-07-11T01:40:10  *** chjj has quit IRC
 142017-07-11T01:40:37  *** dabura667 has joined #bitcoin-core-dev
 152017-07-11T01:50:31  *** Chris_Stewart_5 has quit IRC
 162017-07-11T01:51:39  *** Murch has joined #bitcoin-core-dev
 172017-07-11T02:03:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 182017-07-11T02:05:56  <bitcoin-git> [bitcoin] stevendlander opened pull request #10789: Punctuation/grammer fixes in rpcwallet.cpp (master...cli-punctuation-standardization) https://github.com/bitcoin/bitcoin/pull/10789
 192017-07-11T02:26:07  *** Murch has quit IRC
 202017-07-11T02:37:07  *** joelsbeard has quit IRC
 212017-07-11T02:42:15  <jtimon> mhm, can't I use something I have in /etc/host with -rpcallowip ? only hardcoded ips ?
 222017-07-11T02:42:24  <jtimon> not even localhost it seems :(
 232017-07-11T02:45:24  *** dermoth has quit IRC
 242017-07-11T02:46:41  *** dermoth has joined #bitcoin-core-dev
 252017-07-11T02:49:17  <sipa> jtimon: it has to be a netmask, i think
 262017-07-11T02:49:19  <sipa> so no
 272017-07-11T02:51:34  <jtimon> found getent hosts myhostname | awk '{ print $1 }', hope it solves my issue
 282017-07-11T02:52:03  <jtimon> thanks for confirming
 292017-07-11T03:08:05  *** Chris_Stewart_5 has quit IRC
 302017-07-11T03:24:11  <bitcoin-git> [bitcoin] MeshCollider opened pull request #10790: Use vector::data() instead of &vch[0] in base58.cpp (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10790
 312017-07-11T03:35:02  *** d9b4bef9 has quit IRC
 322017-07-11T03:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
 332017-07-11T03:38:11  *** CubicEarth has joined #bitcoin-core-dev
 342017-07-11T03:39:48  *** kvp has joined #bitcoin-core-dev
 352017-07-11T03:44:04  *** chjj has joined #bitcoin-core-dev
 362017-07-11T04:11:59  *** jamesob has joined #bitcoin-core-dev
 372017-07-11T04:23:50  *** str4d has quit IRC
 382017-07-11T04:36:40  *** chjj has quit IRC
 392017-07-11T04:47:45  *** dermoth has quit IRC
 402017-07-11T05:17:49  <gmaxwell> hurray for protocol improvements, you can see the inv rate on this chart approve as people upgrade to 0.13+ https://statoshi.info/dashboard/db/p2p-messages?from=1453110746831&to=1499750141000
 412017-07-11T05:20:53  *** jcorgan has quit IRC
 422017-07-11T05:24:08  *** BashCo has quit IRC
 432017-07-11T05:24:53  *** BashCo has joined #bitcoin-core-dev
 442017-07-11T06:06:42  *** CubicEarth has quit IRC
 452017-07-11T06:23:02  *** ula has joined #bitcoin-core-dev
 462017-07-11T06:35:41  *** Ylbam has joined #bitcoin-core-dev
 472017-07-11T06:52:17  *** shadders has joined #bitcoin-core-dev
 482017-07-11T06:54:02  *** chjj has joined #bitcoin-core-dev
 492017-07-11T07:03:51  *** Murch has joined #bitcoin-core-dev
 502017-07-11T07:06:09  *** chjj has quit IRC
 512017-07-11T07:11:35  *** Dyaheon has quit IRC
 522017-07-11T07:13:08  *** Dyaheon has joined #bitcoin-core-dev
 532017-07-11T07:16:00  *** Meghan has quit IRC
 542017-07-11T07:23:23  <wumpus> right, some of the options support host lookup as of master, but rpcallowip certainly doesn't
 552017-07-11T07:24:04  <wumpus> (e.g. #9774)
 562017-07-11T07:24:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9774 | Enable host lookups for -proxy and -onion parameters by jmcorgan · Pull Request #9774 · bitcoin/bitcoin · GitHub
 572017-07-11T07:24:12  *** dermoth has joined #bitcoin-core-dev
 582017-07-11T07:26:44  <wumpus> oh yes, inv rate looks a lot more calm recently
 592017-07-11T07:28:50  <gmaxwell> the changes for inv batching and timing make it basically constant.
 602017-07-11T07:35:01  *** d9b4bef9 has quit IRC
 612017-07-11T07:38:08  *** d9b4bef9 has joined #bitcoin-core-dev
 622017-07-11T07:39:18  <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/9edda0c5f5f2...21ed30a314cf
 632017-07-11T07:39:19  <bitcoin-git> bitcoin/master ff6a834 Matt Corallo: Use TestingSetup to DRY qt rpcnestedtests
 642017-07-11T07:39:19  <bitcoin-git> bitcoin/master 3a19fed Matt Corallo: Make ValidationInterface signals-type-agnostic...
 652017-07-11T07:39:20  <bitcoin-git> bitcoin/master cda1429 Matt Corallo: Give CMainSignals a reference to the global scheduler...
 662017-07-11T07:39:33  <bitcoin-git> [bitcoin] laanwj closed pull request #10179: Give CValidationInterface Support for calling notifications on the CScheduler Thread (master...2017-01-wallet-cache-inmempool-3) https://github.com/bitcoin/bitcoin/pull/10179
 672017-07-11T07:46:40  <bitcoin-git> [bitcoin] maaku opened pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792
 682017-07-11T07:50:48  *** coredump_ has quit IRC
 692017-07-11T07:54:13  <gmaxwell> you mean it doesn't compute the max of the last two stack variables!?!?
 702017-07-11T07:54:16  <gmaxwell> :P
 712017-07-11T07:55:41  *** promag has joined #bitcoin-core-dev
 722017-07-11T07:56:45  <gmaxwell> [OT-ish] https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf  < the ictp described here is neat. I wish pax stuff was open.
 732017-07-11T07:57:05  <sipa> gmaxwell: ???
 742017-07-11T07:57:13  <sipa> (re: last two stack variables)
 752017-07-11T07:58:28  *** arowser has quit IRC
 762017-07-11T08:00:24  *** Murch has quit IRC
 772017-07-11T08:00:55  <gmaxwell> sipa: joke on mark's MAX_OPCODE
 782017-07-11T08:01:11  <gmaxwell> that it doesn't compute max()
 792017-07-11T08:01:32  *** paveljanik has quit IRC
 802017-07-11T08:01:44  *** Murch has joined #bitcoin-core-dev
 812017-07-11T08:02:07  <sipa> ah
 822017-07-11T08:04:14  *** Murch has quit IRC
 832017-07-11T08:04:39  *** arowser has joined #bitcoin-core-dev
 842017-07-11T08:07:46  *** promag has quit IRC
 852017-07-11T08:16:34  <bitcoin-git> [bitcoin] MeshCollider closed pull request #10790: Use vector::data() instead of &vch[0] in base58.cpp (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10790
 862017-07-11T08:39:33  *** Murch has joined #bitcoin-core-dev
 872017-07-11T08:44:07  *** vicenteH has joined #bitcoin-core-dev
 882017-07-11T08:45:08  *** Aaronvan_ has joined #bitcoin-core-dev
 892017-07-11T08:50:42  *** timothy has joined #bitcoin-core-dev
 902017-07-11T08:52:00  *** pyface has joined #bitcoin-core-dev
 912017-07-11T09:11:42  *** promag has joined #bitcoin-core-dev
 922017-07-11T09:26:12  *** Murch has quit IRC
 932017-07-11T09:33:48  *** riemann has joined #bitcoin-core-dev
 942017-07-11T09:37:39  *** jtimon has quit IRC
 952017-07-11T09:44:05  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21ed30a314cf...379aed0e53a6
 962017-07-11T09:44:05  <bitcoin-git> bitcoin/master f2f1d0a Gregory Sanders: document script-based return fields for validateaddress
 972017-07-11T09:44:06  <bitcoin-git> bitcoin/master 379aed0 Wladimir J. van der Laan: Merge #10676: document script-based return fields for validateaddress...
 982017-07-11T09:44:31  <bitcoin-git> [bitcoin] laanwj closed pull request #10676: document script-based return fields for validateaddress (master...validatata) https://github.com/bitcoin/bitcoin/pull/10676
 992017-07-11T09:45:44  <bitcoin-git> [bitcoin] MeshCollider opened pull request #10793: Changing &var[0] to var.data() (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10793
1002017-07-11T09:48:27  *** goatpig has joined #bitcoin-core-dev
1012017-07-11T09:58:26  <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/379aed0e53a6...104f5f21dc24
1022017-07-11T09:58:27  <bitcoin-git> bitcoin/master cfaef69 Alex Morcos: remove default argument from GetMinimumFee
1032017-07-11T09:58:27  <bitcoin-git> bitcoin/master d507c30 Alex Morcos: Introduce a fee estimate mode....
1042017-07-11T09:58:28  <bitcoin-git> bitcoin/master e0738e3 Alex Morcos: remove default argument from estimateSmartFee
1052017-07-11T09:58:46  <bitcoin-git> [bitcoin] laanwj closed pull request #10589: More economical fee estimates for RBF and RPC options to control (master...rpcestimatechoice) https://github.com/bitcoin/bitcoin/pull/10589
1062017-07-11T10:20:45  *** coredump_ has joined #bitcoin-core-dev
1072017-07-11T10:36:27  *** coredump_ has quit IRC
1082017-07-11T10:36:45  *** pyface has quit IRC
1092017-07-11T10:42:29  *** coredump_ has joined #bitcoin-core-dev
1102017-07-11T10:46:07  *** Aaronvan_ has quit IRC
1112017-07-11T10:50:01  *** promag has quit IRC
1122017-07-11T10:54:26  *** Victorsueca has quit IRC
1132017-07-11T10:58:57  *** Victorsueca has joined #bitcoin-core-dev
1142017-07-11T11:00:05  *** Dyaheon has quit IRC
1152017-07-11T11:02:29  *** Dyaheon has joined #bitcoin-core-dev
1162017-07-11T11:13:15  *** coredump_ has quit IRC
1172017-07-11T11:36:47  *** coredump_ has joined #bitcoin-core-dev
1182017-07-11T11:40:01  *** laurentmt has joined #bitcoin-core-dev
1192017-07-11T11:41:35  *** laurentmt has quit IRC
1202017-07-11T11:51:23  *** coredump_ has quit IRC
1212017-07-11T12:14:37  *** JackH has joined #bitcoin-core-dev
1222017-07-11T12:31:29  *** PlaneteNamek has joined #bitcoin-core-dev
1232017-07-11T12:31:58  <PlaneteNamek> Hello world 😊
1242017-07-11T12:34:07  <jonasschnelli> Beg for review on: https://github.com/bitcoin/bitcoin/pull/9502
1252017-07-11T12:48:20  *** PlaneteNamek has quit IRC
1262017-07-11T12:53:32  *** robotpoop has joined #bitcoin-core-dev
1272017-07-11T12:57:51  *** CubicEarth has joined #bitcoin-core-dev
1282017-07-11T13:01:56  *** ula has quit IRC
1292017-07-11T13:05:14  *** ProfMac has quit IRC
1302017-07-11T13:08:05  *** robotpoop has quit IRC
1312017-07-11T13:10:10  *** jrayhawk has quit IRC
1322017-07-11T13:11:33  *** jrayhawk has joined #bitcoin-core-dev
1332017-07-11T13:11:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1342017-07-11T13:12:42  <wumpus> #9502
1352017-07-11T13:12:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub
1362017-07-11T13:13:54  *** AaronvanW has joined #bitcoin-core-dev
1372017-07-11T13:21:52  <bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/104f5f21dc24...e4f226a133d0
1382017-07-11T13:21:53  <bitcoin-git> bitcoin/master 32cffe6 John Newbery: [tests] Fix import order in getblocktemplate test
1392017-07-11T13:21:53  <bitcoin-git> bitcoin/master 0a3a5ff John Newbery: [tests] Fix flake8 warnings in getblocktemplate tests
1402017-07-11T13:21:54  <bitcoin-git> bitcoin/master 38b38cd John Newbery: [tests] getblocktemplate_proposals.py: add logging
1412017-07-11T13:21:59  *** Guyver2 has joined #bitcoin-core-dev
1422017-07-11T13:22:14  <bitcoin-git> [bitcoin] laanwj closed pull request #10190: [tests] mining functional tests (including regression test for submitblock) (master...mining_functional_test) https://github.com/bitcoin/bitcoin/pull/10190
1432017-07-11T13:24:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4f226a133d0...badd81bd3185
1442017-07-11T13:24:34  <bitcoin-git> bitcoin/master c8e29d7 Mark Friedenbach: Replace MAX_OPCODE for OP_NOP10....
1452017-07-11T13:24:35  <bitcoin-git> bitcoin/master badd81b Wladimir J. van der Laan: Merge #10792: Replace MAX_OPCODE for OP_NOP10....
1462017-07-11T13:25:07  <bitcoin-git> [bitcoin] laanwj closed pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792
1472017-07-11T13:25:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/badd81bd3185...cef4b5ccaa37
1482017-07-11T13:25:34  <bitcoin-git> bitcoin/master 6270d62 Matt Corallo: Verify binaries from bitcoincore.org and bitcoin.org
1492017-07-11T13:25:35  <bitcoin-git> bitcoin/master cef4b5c Wladimir J. van der Laan: Merge #10651: Verify binaries from bitcoincore.org and bitcoin.org...
1502017-07-11T13:25:58  <bitcoin-git> [bitcoin] laanwj closed pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651
1512017-07-11T13:26:53  *** dabura667 has quit IRC
1522017-07-11T13:30:36  *** CubicEarth has quit IRC
1532017-07-11T13:32:47  *** AaronvanW has quit IRC
1542017-07-11T13:33:23  *** AaronvanW has joined #bitcoin-core-dev
1552017-07-11T13:37:20  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cef4b5ccaa37...b27b004532db
1562017-07-11T13:37:21  <bitcoin-git> bitcoin/master 9c85b91 Alex Morcos: Change API to estimaterawfee...
1572017-07-11T13:37:22  <bitcoin-git> bitcoin/master 1fafd70 Alex Morcos: Add function to report highest estimate target tracked per horizon
1582017-07-11T13:37:22  <bitcoin-git> bitcoin/master 5e3b7b5 Alex Morcos: Improve error reporting for estimaterawfee
1592017-07-11T13:37:40  <bitcoin-git> [bitcoin] laanwj closed pull request #10543: Change API to estimaterawfee (master...estimaterawapi) https://github.com/bitcoin/bitcoin/pull/10543
1602017-07-11T13:37:52  *** AaronvanW has quit IRC
1612017-07-11T13:40:35  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b27b004532db...ca4c545cc7e8
1622017-07-11T13:40:35  <bitcoin-git> bitcoin/master 475c08c Pieter Wuille: Add PR description to merge commit in github-merge.py
1632017-07-11T13:40:36  <bitcoin-git> bitcoin/master ca4c545 Wladimir J. van der Laan: Merge #10786: Add PR description to merge commit in github-merge.py...
1642017-07-11T13:41:12  <bitcoin-git> [bitcoin] laanwj closed pull request #10786: Add PR description to merge commit in github-merge.py (master...20170710_prbody) https://github.com/bitcoin/bitcoin/pull/10786
1652017-07-11T14:06:15  *** cheese_ has joined #bitcoin-core-dev
1662017-07-11T14:12:07  <ryanofsky> can #10235 be merged?
1672017-07-11T14:12:09  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
1682017-07-11T14:31:11  *** RoyceX has joined #bitcoin-core-dev
1692017-07-11T14:34:08  *** cheese_ has quit IRC
1702017-07-11T14:53:34  <morcos> I think #10712 can also be merged.  sipa: you left just a nit, were you still reviewing?  I'll skip the nit since the current commit has 3 ack's
1712017-07-11T14:53:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
1722017-07-11T14:59:44  *** riemann has quit IRC
1732017-07-11T15:01:44  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10794: Add simple light-client mode (RPC only) (master...2017/07/spv) https://github.com/bitcoin/bitcoin/pull/10794
1742017-07-11T15:02:25  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9171: Introduce auxiliary block requests (master...2016/11/spv_step_1) https://github.com/bitcoin/bitcoin/pull/9171
1752017-07-11T15:02:50  *** Herta has joined #bitcoin-core-dev
1762017-07-11T15:05:05  *** JackH has quit IRC
1772017-07-11T15:09:25  *** JackH has joined #bitcoin-core-dev
1782017-07-11T15:12:28  <BlueMatt> wumpus: would be nice to get a quick glance and merge on #10235
1792017-07-11T15:12:30  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
1802017-07-11T15:14:52  *** Dizzle has joined #bitcoin-core-dev
1812017-07-11T15:34:01  *** Herta has quit IRC
1822017-07-11T15:35:06  <morcos> BlueMatt: How does it know what index to create key at if the keypool is empty? (same question before your PR)
1832017-07-11T15:36:26  <BlueMatt> hmm?
1842017-07-11T15:36:41  <BlueMatt> it doesnt matter if the pool is empty, use index 0?
1852017-07-11T15:37:08  <BlueMatt> the indexes dont really have a purpose, its more of a set
1862017-07-11T15:37:13  <wumpus> looking at 10235
1872017-07-11T15:37:25  <morcos> yeah i just figured that out, that the indices are only for keypool management
1882017-07-11T15:37:30  <BlueMatt> yea
1892017-07-11T15:37:58  <morcos> but are you sure there is not a bug now that you have two keypools
1902017-07-11T15:38:27  <BlueMatt> well afterwards you should still make sure they keyids are unique, ie creating at the max of both sets
1912017-07-11T15:38:27  <morcos> if external runs out, couldn't you create a new key in the external pool with the same index as one in the internal pool
1922017-07-11T15:38:38  <BlueMatt> i hope that pr doesnt do that
1932017-07-11T15:39:58  <morcos> i'm not sure if there is a bug, i'm making my way through all this logic for the first time, but i think it would be a lot clearer if you figured out nInternalEnd and nExternalEnd and maxed them for nEnd
1942017-07-11T15:40:51  <morcos> actually it seems even worse than that
1952017-07-11T15:40:58  <morcos> i just don't think this logic works with two pools
1962017-07-11T15:41:14  <morcos> imagine internal = {1,3} and external = {2,4}
1972017-07-11T15:41:14  <BlueMatt> hmm?
1982017-07-11T15:41:18  <morcos> then external runs out
1992017-07-11T15:41:29  <BlueMatt> you can reuse indexes
2002017-07-11T15:41:32  <morcos> you'll now generate 4 as the next internal key or external key
2012017-07-11T15:41:32  <BlueMatt> thats no problem
2022017-07-11T15:41:35  <morcos> oh yeah, i guess thats ok
2032017-07-11T15:42:19  <morcos> ok, so ignore me
2042017-07-11T15:42:28  <morcos> maybe it's pretty clear.
2052017-07-11T15:43:43  <morcos> what about the pool on disk though?  it seems like you shouldn't start reusining indices until you're sure they aren't in there?
2062017-07-11T15:44:29  <BlueMatt> hmmmmmm, yea, there is a bug there, but I didnt introduce it
2072017-07-11T15:44:42  <morcos> yeah, but made it much more likely to get hit i think
2082017-07-11T15:44:50  <BlueMatt> dont think so?
2092017-07-11T15:45:02  <BlueMatt> ReserveKeyFromKeyPool, (keypool now empty), TopUpKeyPool, fucked
2102017-07-11T15:45:14  <BlueMatt> I dont think i made a real difference to the likelyhood there
2112017-07-11T15:45:24  <morcos> well before you start over again at 1, so it's unlikely the initial indices are still in disk pool
2122017-07-11T15:45:40  <morcos> but with yours you could easily reuse a recent one as per my {1,3} {2,4} example above
2132017-07-11T15:45:43  <BlueMatt> depends on your keypool size
2142017-07-11T15:45:51  <BlueMatt> true
2152017-07-11T15:45:52  <morcos> sure, seems like a bug either way
2162017-07-11T15:46:03  <BlueMatt> anyway, its only really likely if you have a small pool, but still not good
2172017-07-11T15:46:16  <BlueMatt> unless you object I'll fix it in a separate pr?
2182017-07-11T15:47:31  <wumpus> what is the worst that can happen if an index is inadvertently reused?
2192017-07-11T15:47:35  <morcos> so what happens, do you overwrite the old keypool entry with the new one on disk?  and seems like you could either return the reserved key or use it, and either case might cause problems
2202017-07-11T15:47:42  <BlueMatt> jonasschnelli: where are you on #10650? We
2212017-07-11T15:47:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
2222017-07-11T15:47:47  <morcos> wumpus: not clear to me
2232017-07-11T15:47:50  <BlueMatt> re dangerously close to having multiwallet slip to 16
2242017-07-11T15:48:27  <BlueMatt> wumpus: yea, not clear to me either, intuitively it should be rather minimal, not like we're clearing private keys or anything, but I could see it hitting an assert somewhere
2252017-07-11T15:48:34  <morcos> BlueMatt: I suppose I have a slight preference for you adding another commit to that PR to fix it.
2262017-07-11T15:48:36  <wumpus> is everything necessary for multiwallet tagged as 0.15?
2272017-07-11T15:48:49  <BlueMatt> i think its just 10650 at this point, no?
2282017-07-11T15:49:02  *** kvp has quit IRC
2292017-07-11T15:49:13  <wumpus> yes, I think so, and that one is tagged, good
2302017-07-11T15:50:06  <BlueMatt> morcos: heh, ok, I was trying to avoid polluting the bugfix-vs-not distinction, but I suppose the performance regression is somewhat bugfix-y anyway
2312017-07-11T15:50:50  <morcos> 64-bits is a big number.. seems pretty safe to just have an in-memory nextIndex that is initialized by taking max of the on-disk last entry in the set?
2322017-07-11T15:50:58  <morcos> sets
2332017-07-11T15:51:26  <wumpus> if you do that, please do make it per-wallet, not global
2342017-07-11T15:51:44  <BlueMatt> yes, that was my preferred fix
2352017-07-11T15:51:53  <wumpus> but if it's 64-bit I don't think we have to be worried about reusing
2362017-07-11T15:52:15  <wumpus> unless small numbers are preferable because they are more efficient for some reason
2372017-07-11T15:52:21  <wumpus> but I don't think so in this case
2382017-07-11T15:52:36  <BlueMatt> ugh, no, bigger numbers better
2392017-07-11T15:53:23  <wumpus> ok, so hold off on merging #10235?
2402017-07-11T15:53:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
2412017-07-11T15:53:31  <BlueMatt> i guess
2422017-07-11T15:53:46  <wumpus> I'm not sure that's the right thing to do if that bug was not introduced here
2432017-07-11T15:53:55  * BlueMatt does care
2442017-07-11T15:54:02  <morcos> wumpus: don't hold off for my sake
2452017-07-11T15:54:16  <morcos> i trust we'll merge the fix before 0.15
2462017-07-11T15:54:30  <BlueMatt> heh, ok, how bout i just open a pr right now to fix it
2472017-07-11T15:54:34  <BlueMatt> and take 10235
2482017-07-11T15:54:48  <morcos> BlueMatt: stop talking and start coding
2492017-07-11T15:55:58  <wumpus> std::max(nEnd, *(--setExternalKeyPool.end()) + 1);
2502017-07-11T15:56:05  <wumpus> whaaaa
2512017-07-11T15:56:19  <BlueMatt> lol, i didnt introduce that
2522017-07-11T15:56:22  <wumpus> what is *that*
2532017-07-11T15:56:57  <BlueMatt> there's no back() in set :(
2542017-07-11T15:57:10  <wumpus> I'm not blaming you, but that's not acceptable, certainly not without a comment
2552017-07-11T15:57:25  <wumpus> then add a back(set) helper function maybe
2562017-07-11T15:57:30  <BlueMatt> lol, ok, sec
2572017-07-11T15:57:33  <wumpus> factor this out to a sensible something
2582017-07-11T15:58:00  <BlueMatt> fwiw, I find that pretty readable, but ok
2592017-07-11T15:58:07  <wumpus> no, that's not readable
2602017-07-11T15:58:08  <wumpus> not at all
2612017-07-11T15:58:24  <wumpus> why would you want to infix-decrease end()?
2622017-07-11T15:58:30  <wumpus> what does that even do?
2632017-07-11T15:58:39  <wumpus> does it move the end of the set?
2642017-07-11T15:59:46  <BlueMatt> but, then, i write iterator garbage that looks like https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/blockencodings.cpp#L281
2652017-07-11T16:00:20  <wumpus> people have to be able to maintain that code, also people that are not you
2662017-07-11T16:00:34  <BlueMatt> i didnt write it
2672017-07-11T16:00:44  <BlueMatt> I'm fixing...
2682017-07-11T16:01:59  <wumpus> that function in fibre looks more understandable
2692017-07-11T16:02:11  <wumpus> it doesn't do anything really crazy and it does it step by step
2702017-07-11T16:03:02  <BlueMatt> ok, fixed on 10235
2712017-07-11T16:03:31  <BlueMatt> lol, clearly I need to try harder to write garbage iterator code in fibre then
2722017-07-11T16:04:04  <wumpus> well as long as you don't inadvertently add UB
2732017-07-11T16:04:33  <wumpus> but if you really want to, make sure it's all in one expression and the order of operations, as well as what applies to what isn't clear
2742017-07-11T16:05:12  *** jtimon has joined #bitcoin-core-dev
2752017-07-11T16:05:16  <wumpus> yes, this is much better, thanks
2762017-07-11T16:05:24  <BlueMatt> heh, I was joking, that stuff is hard enough to maintain when I go back once every three months and rewrite big chunks to get another 2 milliseconds out of it :p
2772017-07-11T16:05:41  <BlueMatt> without remembering the threading model that will cause a segfault-in-a-million if you break it
2782017-07-11T16:07:36  <wumpus> I can imagine
2792017-07-11T16:07:38  <cfields> BlueMatt: fwiw, you can use *.rend() if !empty()
2802017-07-11T16:07:49  <cfields> er, rbegin
2812017-07-11T16:07:57  <BlueMatt> yea, that too
2822017-07-11T16:13:00  <BlueMatt> wumpus: err, nvm, easier to just fix the first bug than bother with simplifying that code
2832017-07-11T16:13:29  <wumpus> I'm afraid #10712 doesn't build on top of current master
2842017-07-11T16:13:31  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
2852017-07-11T16:13:36  <wumpus> BlueMatt: well you had simplified that code just fine imo
2862017-07-11T16:13:42  *** Murch has joined #bitcoin-core-dev
2872017-07-11T16:13:45  <BlueMatt> yes, but the next pr is to remove it :p
2882017-07-11T16:13:47  * morcos loves it when someone elses code gets made fun of  (ha ha, wow poor timeing to say that)
2892017-07-11T16:13:58  <morcos> ok will look
2902017-07-11T16:14:01  <BlueMatt> lol
2912017-07-11T16:14:03  <wumpus> BlueMatt: lol, oops, that happens to me all the time
2922017-07-11T16:14:16  <wumpus> spend optimizing or improving some part of the code, then it's no longer necessary :p
2932017-07-11T16:15:31  <wumpus> re: #10712: src/wallet/wallet.cpp:2763:151: error: too few arguments to function call, expected 7, have 5
2942017-07-11T16:15:31  <wumpus> CAmount fee_needed_for_change = GetMinimumFee(change_prototype_size, currentConfirmationTarget, ::mempool, ::feeEstimator, nullptr);
2952017-07-11T16:15:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub
2962017-07-11T16:15:55  <BlueMatt> well, I'll lave 10235 with the fix for now, since it should be an easy merge
2972017-07-11T16:16:06  <BlueMatt> and then it'll get removed in the next pr, which will need a whole review cycle
2982017-07-11T16:17:11  <morcos> yeah conflict with my other PR you just merged but in a newly added line, will fix 10712
2992017-07-11T16:18:38  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10795: No longer ever reuse keypool indexes (master...2017-07-wallet-keypool-overwrite) https://github.com/bitcoin/bitcoin/pull/10795
3002017-07-11T16:41:48  *** vicenteH has quit IRC
3012017-07-11T16:47:14  *** JackH has quit IRC
3022017-07-11T16:50:54  *** vicenteH has joined #bitcoin-core-dev
3032017-07-11T16:51:36  *** JackH has joined #bitcoin-core-dev
3042017-07-11T16:57:27  *** JackH has quit IRC
3052017-07-11T17:02:59  <sipa> these are some preliminary benchmarks for a reindex-chainstate up to height 450000 (before assumevalid, so no signature checking), with infinity dbcache, for various sha256 implementations:
3062017-07-11T17:03:03  <sipa> bitcoind-rorx: 4835
3072017-07-11T17:03:06  <sipa> bitcoind-shani: 4297
3082017-07-11T17:03:08  <sipa> bitcoind-basic: 5134
3092017-07-11T17:03:11  <sipa> bitcoind-sse: 4875
3102017-07-11T17:04:00  <sipa> basic is master
3112017-07-11T17:04:10  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca4c545cc7e8...e8b95239eeb0
3122017-07-11T17:04:11  <bitcoin-git> bitcoin/master 253cd7e Alex Morcos: Only reserve key for scriptChange once in CreateTransaction...
3132017-07-11T17:04:11  <bitcoin-git> bitcoin/master 0f402b9 Alex Morcos: Fix rare edge case of paying too many fees when transaction has no change....
3142017-07-11T17:04:12  <bitcoin-git> bitcoin/master e8b9523 Wladimir J. van der Laan: Merge #10712: Add change output if necessary to reduce excess fee...
3152017-07-11T17:04:22  <sipa> rorx and sse are from wumpus' work to include some asm optimized versions
3162017-07-11T17:04:40  <bitcoin-git> [bitcoin] laanwj closed pull request #10712: Add change output if necessary to reduce excess fee (master...addchangehwenoverpaying) https://github.com/bitcoin/bitcoin/pull/10712
3172017-07-11T17:04:47  <sipa> the shani version is using code from cryptopp
3182017-07-11T17:06:00  *** chjj has joined #bitcoin-core-dev
3192017-07-11T17:07:34  <BlueMatt> lol, Make Bitcoin CryptoPP Again
3202017-07-11T17:08:14  <BlueMatt> thats a pretty impressive gain
3212017-07-11T17:08:33  <sipa> unfortunately, very few systems right now have sha-ni instructions
3222017-07-11T17:09:03  <BlueMatt> yes, but that should change over time
3232017-07-11T17:09:10  <BlueMatt> the sha-ni in intel and amd are identical, no?
3242017-07-11T17:09:34  <sipa> afaik, there is exists no "sha-ni in intel" yet :)
3252017-07-11T17:10:34  <wumpus> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :)
3262017-07-11T17:10:44  *** JackH has joined #bitcoin-core-dev
3272017-07-11T17:11:07  <sipa> sse is present in nearly every x86_64 cpu, i think
3282017-07-11T17:12:00  <wumpus> yes, sse is present in all of them
3292017-07-11T17:12:41  <wumpus> even sse2 should be in all of them
3302017-07-11T17:13:29  <BlueMatt> sipa: hmm? I was under the impression they had announced something like the next arch will get it
3312017-07-11T17:13:31  <gmaxwell> sse2 is required by x86_64.
3322017-07-11T17:13:34  <BlueMatt> no shipping ones, obviously
3332017-07-11T17:14:14  <wumpus> those are not exactly new instructions though :) anyhow supporting shani as well is nice, just takes time and it will be in near everything...
3342017-07-11T17:14:54  <gmaxwell> here is something funny: compilng bitcoin with -march=native makes the sha2 in C most of the speed of the sse one. (compiler manages to use rorx)
3352017-07-11T17:15:32  <gmaxwell> Also the x86 simd support will make it easier to plug in arm versions; which will be more important for speed.
3362017-07-11T17:15:56  <BlueMatt> wow, yay compiler smarts
3372017-07-11T17:16:02  <gmaxwell> sipa: there is an intel chip with sha-ni, but it's some crappy atom processor.
3382017-07-11T17:16:24  <BlueMatt> <wumpus> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :)
3392017-07-11T17:16:27  <BlueMatt> heh, guess not, then
3402017-07-11T17:17:23  <sipa> gmaxwell: compiling all of bitcoind with -march=native actually makes it overall another 100s faster to sync
3412017-07-11T17:17:29  <gmaxwell> well aformentioned atom is some server atom that isn't very widely deployed from what I can tell.
3422017-07-11T17:17:46  <BlueMatt> do you have lto benchmarks?
3432017-07-11T17:17:52  <sipa> not yet, but i can create
3442017-07-11T17:18:05  <wumpus> yes, march=native is nice, everyone compiling bitcoind locally should use it
3452017-07-11T17:18:25  <gmaxwell> #9804 looks like a good change that is getting forgotten. (I say that as someone whos only concept acked so far...)
3462017-07-11T17:18:27  <gribble> https://github.com/bitcoin/bitcoin/issues/9804 | Fixes subscript 0 ([0]) where should use (var.data()) instead. by JeremyRubin · Pull Request #9804 · bitcoin/bitcoin · GitHub
3472017-07-11T17:18:56  <wumpus> with so many open PRs it's unavoidable that some things get forgotten, unfortunately
3482017-07-11T17:19:08  <wumpus> but no, that one isn't
3492017-07-11T17:19:49  <wumpus> I just referred people to review it today (because they opened a PR that was a strict subset of it)
3502017-07-11T17:20:43  <sipa> wumpus: thanks for that, i had almost forgotten about jeremy's version
3512017-07-11T17:30:31  <BlueMatt> lolwut
3522017-07-11T17:30:39  <BlueMatt> ehh, wrong window
3532017-07-11T17:31:44  <sipa> seems totally appropriate here
3542017-07-11T17:32:05  <BlueMatt> ok, then I'll pretend I meant to
3552017-07-11T17:33:09  *** vicenteH` has joined #bitcoin-core-dev
3562017-07-11T17:34:57  *** vicenteH has quit IRC
3572017-07-11T17:36:35  *** Dyaheon has quit IRC
3582017-07-11T17:37:54  *** timothy has quit IRC
3592017-07-11T17:38:26  *** Dyaheon has joined #bitcoin-core-dev
3602017-07-11T17:46:08  *** vicenteH` has quit IRC
3612017-07-11T17:47:57  *** RoyceX has quit IRC
3622017-07-11T17:58:27  <sipa> running benchmarks for lto and shani+lto as well now
3632017-07-11T17:58:39  <sipa> will have numbers in a day...
3642017-07-11T17:59:22  *** riemann has joined #bitcoin-core-dev
3652017-07-11T17:59:33  <sipa> interestingly, the shani+lto does not even contain any non-shani sha code, even though it's dispatched to a modifiable pointer
3662017-07-11T17:59:39  <BlueMatt> heh
3672017-07-11T17:59:43  <BlueMatt> oh nice
3682017-07-11T17:59:48  <sipa> the compiler must notice there are no assignments to that pointer, and treats it as a constant
3692017-07-11T18:00:05  <BlueMatt> yea, lto can be clever sometimes
3702017-07-11T18:01:57  *** chjj has quit IRC
3712017-07-11T18:08:36  <gmaxwell> if compiler versions are still keeping up from ltoing by default perhaps we could add a --gofast configure flag to do -march=native -O3 -lto
3722017-07-11T18:09:05  <BlueMatt> is O3 a win in bitcoin?
3732017-07-11T18:09:39  <sipa> i guess i'll benchmark that too :)
3742017-07-11T18:09:54  <BlueMatt> heh
3752017-07-11T18:13:50  <wumpus> I don't see why something as basic as that would need a configure fla
3762017-07-11T18:14:00  <wumpus> people that want to supply their own CXXFLAGS can do so already
3772017-07-11T18:14:30  <wumpus> could just mention it in the build document
3782017-07-11T18:14:55  <wumpus> a dedicated configure flag only makes sense if we use something for the gitian build, so people can do their own build with the same settings
3792017-07-11T18:15:08  <gmaxwell> wumpus: fair enough
3802017-07-11T18:15:23  <wumpus> but using -march=native would be a bad idea there, -flto might be a good one
3812017-07-11T18:15:51  <BlueMatt> yea, flto could use its own configure flat...doing it manually is like 6 variables long
3822017-07-11T18:17:39  <gmaxwell> well I think we should lto by default, but there was still some question of compiler support. (which I think was mooted by C++11, but perhaps I'm wrong, since we still haven't done it.)
3832017-07-11T18:18:42  <wumpus> I'm not convinced anything but -O2 optimization should be default
3842017-07-11T18:19:13  <gmaxwell> wumpus: why shouldn't it be lto-ing by default?
3852017-07-11T18:19:16  <wumpus> cfields might have more of an opinion, but in my experience buildling open source software for lots of platforms, I've had lots of annoyances with software that tried to forcibly injects certain sets of optimizations flags
3862017-07-11T18:19:33  <wumpus> it should be left up to the distribution ideally to set optimization flags
3872017-07-11T18:19:36  <BlueMatt> gmaxwell: lto does not work on moderately-recent compilers
3882017-07-11T18:19:43  <wumpus> well even if it did
3892017-07-11T18:19:48  <BlueMatt> eg debian jessie
3902017-07-11T18:19:57  <sipa> works fine here, and for release builds we control the environment entirely anyway
3912017-07-11T18:20:05  <BlueMatt> well, i guess 4.9 isnt moderately-recent
3922017-07-11T18:20:06  <wumpus> yes, for release builds flto would be good
3932017-07-11T18:20:11  <BlueMatt> anyway, we support it, and lto doesnt work on it
3942017-07-11T18:20:13  <cfields> wumpus: agreed. "-02 -g" is expected to be the default, I get really irritated when that's not the case
3952017-07-11T18:20:20  <wumpus> cfields: exactly
3962017-07-11T18:20:35  <sipa> benchmarking reindex with "-O2", "-O3", "-flto -O2",  and "-flto -O3"
3972017-07-11T18:20:39  <BlueMatt> nice
3982017-07-11T18:21:12  <wumpus> don't get me wrong, flto would be great for gitian builds, and we could have a configure option for that, but adding non-standard optimization flags by default on configure tends to be really annoying in edge cases
3992017-07-11T18:21:50  <sipa> cfields was concerned about having release builds deviate too much from developers-tested builds
4002017-07-11T18:21:52  <cfields> I get the impression i should go ahead and wire up --enable-lto before someone sneaks in something unexpected :)
4012017-07-11T18:22:05  <gmaxwell> BlueMatt: I do not believe that LTO fails to work on anything that can compile Bitcoin Core.   It's been supported since GCC 4.7
4022017-07-11T18:22:19  <wumpus> if you want to encourage people to build with optimization flags then just document it in e.g. build-unix.md
4032017-07-11T18:22:24  <wumpus> don't do anything sneaky
4042017-07-11T18:22:35  <gmaxwell> Our cflags are far from -O2 -g, though, we add about two dozen warning flags.
4052017-07-11T18:22:46  <wumpus> warning flags don't do aything funny to the code
4062017-07-11T18:22:56  <cfields> sipa: i think an --enable-lto alleviates that somewhat, since it makes it easy for devs to get the same results
4072017-07-11T18:23:04  <BlueMatt> gmaxwell: I dunno, I've been building on lto for a long time and every debian jessie server I've ever installed has always failed to build lto
4082017-07-11T18:23:17  <sipa> BlueMatt: due to some boost interaction, right?
4092017-07-11T18:23:19  <BlueMatt> its an easy fix - just recompile util.cpp without lto and then it works, but its broken
4102017-07-11T18:23:27  <BlueMatt> sipa: its not boost-specific, but thats where it fails
4112017-07-11T18:23:37  <BlueMatt> it appears to be some general issue with destructors defined in headers
4122017-07-11T18:23:40  <cfields> sipa: iirc i hit a boost::filesystem problem last i tried
4132017-07-11T18:23:48  <gmaxwell> BlueMatt: good datapoint then.
4142017-07-11T18:23:52  <BlueMatt> I've seen it fail on other things, but normally the thing you see is ~boost::filesystem()
4152017-07-11T18:23:59  <cfields> but i assumed it was local
4162017-07-11T18:24:01  <BlueMatt> ehh, sorry, not filesystem
4172017-07-11T18:24:06  <BlueMatt> some boost::filesystem path ~ thing
4182017-07-11T18:25:19  <cfields> sipa: ooh i know, we can wire it up with depends builds
4192017-07-11T18:25:40  <BlueMatt> cfields: didnt you tell me you were gonna wire up a "trusting-trust" gcc build in depends for 15? :P
4202017-07-11T18:25:44  <BlueMatt> I still dont see a PR
4212017-07-11T18:26:11  <cfields> that way anyone using depends gets lto by default, and we also know what dep versions we're dealing with
4222017-07-11T18:26:20  <wumpus> our good friend ubuntu trusty has gcc 4.8.4, hopefully that can do flto without probems (especially worried about windows! but we'll see)
4232017-07-11T18:26:34  <cfields> BlueMatt: i don't think it's going to make it :(
4242017-07-11T18:26:37  <BlueMatt> wumpus: I'd be kinda surprised if it did
4252017-07-11T18:26:51  <BlueMatt> cfields: what? by this coming sunday? yea, somehow i doubt it
4262017-07-11T18:27:11  <wumpus> can someone please just try instead of guess :-)
4272017-07-11T18:27:25  <BlueMatt> +1
4282017-07-11T18:27:28  <BlueMatt> go cfields, go
4292017-07-11T18:27:39  <wumpus> I can do it, np, but thought cfields was going to
4302017-07-11T18:28:33  <cfields> add lto to configure (and see if it works) ?
4312017-07-11T18:28:58  <wumpus> cfields: yes, doing a gitian build with lto (for all platforms)
4322017-07-11T18:29:11  <BlueMatt> oh, i thought we were talking about a "trusting trust" copy of gcc
4332017-07-11T18:29:11  <wumpus> then seeing where/if the result crashes
4342017-07-11T18:29:12  <cfields> sure, i can do that
4352017-07-11T18:29:18  <BlueMatt> yea, ok, adding lto is much easier, that could make it
4362017-07-11T18:29:47  <wumpus> BlueMatt: I thoughtwe were talking about optimizations
4372017-07-11T18:29:59  * wumpus confused
4382017-07-11T18:30:09  *** dermoth has quit IRC
4392017-07-11T18:30:26  <cfields> adding lto to configure now, then seeing where it works.
4402017-07-11T18:32:06  *** dermoth has joined #bitcoin-core-dev
4412017-07-11T18:32:47  <wumpus> cool
4422017-07-11T18:34:24  *** cluelessperson has joined #bitcoin-core-dev
4432017-07-11T18:34:54  <cluelessperson> Hey guys, I'm looking at buying some new server hardware.
4442017-07-11T18:34:56  <cluelessperson> https://www.asus.com/us/Commercial-Servers-Workstations/RS100-E9-PI2/specifications/
4452017-07-11T18:35:18  <cluelessperson> is currently on my plate, but I was wondering if you might suggest something else that might be more beneficial towards bitcoin development, testing/QA?
4462017-07-11T18:38:10  <wumpus> this really isn't the channel for server hw suggestions
4472017-07-11T18:38:16  <midnightmagic> I sent him here.
4482017-07-11T18:39:08  <BlueMatt> cluelessperson: anything with fast disk and lots of memory
4492017-07-11T18:39:12  <BlueMatt> otherwise, O/T
4502017-07-11T18:40:02  <cluelessperson> BlueMatt: I could do PCI-SSD, but what type of ram requirements are we talking?
4512017-07-11T18:40:13  <midnightmagic> -- since he was hoping to help in some capacity with the development itself, and I know occasionally guidance in terms of e.g. differing hardware or stuff that would be more helpful than generic hardware is sometimes in demand.
4522017-07-11T18:40:24  <BlueMatt> ok, no big deal, lets move to #bitcoin
4532017-07-11T18:43:20  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #8369: [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" (master...2016/07/wallet_features) https://github.com/bitcoin/bitcoin/pull/8369
4542017-07-11T18:48:05  *** Guest23212 has quit IRC
4552017-07-11T18:51:34  *** Guest89066 has joined #bitcoin-core-dev
4562017-07-11T18:55:37  *** chjj has joined #bitcoin-core-dev
4572017-07-11T19:00:06  <morcos> ryanofsky: #10244 is marked high-priority, but seems to me from reading the conversation that although it is now concept acked it's targeted for post-0.15?
4582017-07-11T19:00:08  <gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
4592017-07-11T19:00:30  <morcos> just want to direct my review appropriately with 0.15 coming up
4602017-07-11T19:00:56  *** Chris_Stewart_5 has quit IRC
4612017-07-11T19:01:54  <jonasschnelli> morcos: Yes. Agree. 10244 should probably removed until there is conceptual consensus (not cleat to me if we have that or not, which probably means we have not :) )
4622017-07-11T19:02:19  <ryanofsky> i thought i had two concept acks
4632017-07-11T19:02:28  <jonasschnelli> Oh. Yes. Right..
4642017-07-11T19:02:47  <ryanofsky> but it's not intended for 15. maybe search for milestone:0.15.0
4652017-07-11T19:02:53  <jonasschnelli> I take back my last comment then...
4662017-07-11T19:04:21  <jonasschnelli> I think for 10244, it makes sense to rebase it after 0.15 has been split off and concentrate review (and hope for a merge)
4672017-07-11T19:04:35  <jonasschnelli> It's a large PR though
4682017-07-11T19:04:43  <jonasschnelli> +2,262 −1,152
4692017-07-11T19:04:59  <ryanofsky> it's pretty much a mechanical change
4702017-07-11T19:06:36  <wumpus> agreed
4712017-07-11T19:06:50  <wumpus> it's not an end-user visible change, we should prioritize those for 0.15
4722017-07-11T19:07:11  <wumpus> all the code cleanups pure refactorings can wait for 0.16
4732017-07-11T19:11:11  <morcos> ok, i was viewing high priority as a subset of milestone:0.15, but perhaps that isn't correct
4742017-07-11T19:12:37  <jonasschnelli> wumpus, ryanofsky: Argee about it beeing mechanical, though it still require line by line review by at least 2-3 guys.
4752017-07-11T19:12:42  <wumpus> well maybe it is now, but in general it's just something that people can request review if it blocks future PRs from themselves
4762017-07-11T19:12:58  <wumpus> but I agree ahving something high-prio that won't make 0.15 anyway is a bad idea
4772017-07-11T19:13:05  <wumpus> right now
4782017-07-11T19:13:21  <jonasschnelli> Yes. I had the same feeling. High-Prio in context of holding back the individual developer / focus of the individual developer.
4792017-07-11T19:14:46  <jonasschnelli> About sipa's ser. changes (#10785), is it worth to benchmark the differences or do we expect non to little impact on performance?
4802017-07-11T19:14:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa · Pull Request #10785 · bitcoin/bitcoin · GitHub
4812017-07-11T19:15:11  <jonasschnelli> (otherwise I can add a bench-package for the serialization code
4822017-07-11T19:15:13  <jonasschnelli> )
4832017-07-11T19:17:58  <jonasschnelli> ryanofsky about the CAuxiliaryRequest, where do you think we have duplicated code? Also, what do you think about the points I wrote (https://github.com/bitcoin/bitcoin/pull/10794#issuecomment-314534086)?
4842017-07-11T19:18:49  <jonasschnelli> (maybe its better to discuss some thing here instead of have to much discussion on the PR before we actually get reviews)
4852017-07-11T19:18:54  <jonasschnelli> things*
4862017-07-11T19:19:10  <sipa> jonasschnelli: i expect 0 impact on performance
4872017-07-11T19:19:28  <jonasschnelli> sipa: Okay. Then it's probably not worth...
4882017-07-11T19:19:29  <ryanofsky> it's been months since i've looked at it but, i remember duplicated logic in the aux request class & normal network download code
4892017-07-11T19:20:37  <jonasschnelli> ryanofsky: I can't see any real duplication, maybe some lines that take care of passing to the instance and for the callback approach...
4902017-07-11T19:20:53  <ryanofsky> i'm looking up my old comments
4912017-07-11T19:21:42  <jonasschnelli> Great. Thanks..
4922017-07-11T19:22:23  <sipa> jonasschnelli: it could be considered a bugfix though (but almost certainly not one that matters)
4932017-07-11T19:22:53  <ryanofsky> here is the comment where i point out the duplication: https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677
4942017-07-11T19:22:57  <jonasschnelli> sipa: you mean the "cast ways the const"?
4952017-07-11T19:23:05  <jonasschnelli> "cast away"
4962017-07-11T19:24:06  <ryanofsky> jonasschnelli, my broader point is that i would like you to get some concept ack on your networking design from some other developers who know more about the networking code than me, before i spend more time reviewing it
4972017-07-11T19:24:30  <jonasschnelli> ryanofsky: Yes. Sure. That makes sense.
4982017-07-11T19:25:04  *** chjj has quit IRC
4992017-07-11T19:25:36  <jonasschnelli> About your comment, I saw that and I think its then not about duplication, it's a slightly different approach (which seems also to make sense).
5002017-07-11T19:26:04  <jonasschnelli> I just like the have-its-own file approach for the reasons I wrote.. but lets get other opinions
5012017-07-11T19:26:32  <ryanofsky> fillInNextBlocks is duplicative of FindNextBlocksToDownload, processWithPossibleBlock is duplicative of ProcessNewBlock was my point
5022017-07-11T19:27:25  <ryanofsky> i don't think you are going to convince me that having two different control flows for regular downloads vs priority downloads is the way to go, but you don't have to convince me. i'm happy to accept that if others think it is a good idea
5032017-07-11T19:27:43  <jonasschnelli> ryanofsky: I don't think its duplicative, if we would eliminate the class, that logic has just to move into net_processing.cpp/validation.cpp
5042017-07-11T19:28:01  *** AaronvanW has joined #bitcoin-core-dev
5052017-07-11T19:28:09  <gmaxwell> ryanofsky: I think others do not think it's a good idea, and already raised the concern.
5062017-07-11T19:28:17  <ryanofsky> iirc, more logic could be shared if they were in the same place
5072017-07-11T19:28:31  <gmaxwell> When that code was first implemented; ... made sense to do for a demo or whatnot.
5082017-07-11T19:28:45  *** ivan_ has joined #bitcoin-core-dev
5092017-07-11T19:28:47  <sipa> just have a means to tell the network layer "i need block X, and here is callback for when you have it"
5102017-07-11T19:29:37  <jonasschnelli> Okay. But the network layer hasn't to be stuffed into a single file/class?
5112017-07-11T19:29:38  <ryanofsky> sipa, yes that is what i requested. i think the auxilliary class is too low level
5122017-07-11T19:30:22  <jonasschnelli> But if the general opinion goes direction of having the logic in net_processing.cpp directly, then I'm fine with moving it there...
5132017-07-11T19:30:23  <sipa> jonasschnelli: net_processing is already a single file
5142017-07-11T19:30:26  <ryanofsky> jonasschnelli, i think agree networking code is monolithic. but that you have to find the right way to break it up and this does not seem like the right way
5152017-07-11T19:31:09  <jonasschnelli> sipa: Yes. And I think having specialized functions (like the light client block rquests) in dedicated files makes sense.. rebasing, patches, code-overview
5162017-07-11T19:32:15  <sipa> jonasschnelli: i really don't think block fetching code should be in more than 1 place
5172017-07-11T19:32:35  <gmaxwell> we have a hard enough time keeping the two existing block requesting state machine functioning and maintained... really pretty ugly to add another seperate one for the wallet in another place.
5182017-07-11T19:32:43  <sipa> it's arguably already too spread out in net_processing (dealing with invs, direct fetching, headers fetching, async fetching ...)
5192017-07-11T19:32:53  <jonasschnelli> sipa: it's not fetching,.. is an object that hold information about what it should fetch and if it's done or not and eventuall the process flow
5202017-07-11T19:33:10  <sipa> jonasschnelli: yes, that's probably how all the fetching code should work
5212017-07-11T19:33:32  <sipa> keep information on what blocks are to be downloaded
5222017-07-11T19:34:08  <jonasschnelli> ryanofsky gmaxwell: I think the out-of-band (auxiliary) requests need state, and therefore a class makes sense (when was the request initiated, how much is done, etc.) would you add that class into net_processing rathern then creating a new file?
5232017-07-11T19:34:23  <ryanofsky> i think if you wanted to move code *out* of net_processing into your new download implementation, that would be nice. but just adding the new download implementation alongside does not seem seem so nice
5242017-07-11T19:34:32  <gmaxwell> jonasschnelli: all block requests need state.
5252017-07-11T19:34:51  <gmaxwell> jonasschnelli: we have to track what we've asked for, what we need, whats been recieved... and so on.
5262017-07-11T19:34:55  <jonasschnelli> gmaxwell: yes. But here it is a user-requested range
5272017-07-11T19:35:10  <sipa> jonasschnelli: in the current case, the user is the block validation logic
5282017-07-11T19:35:19  <sipa> you just want to add another user
5292017-07-11T19:35:26  <gmaxwell> ^
5302017-07-11T19:35:41  <jonasschnelli> sipa: can't follow the "user is the block validation logic" :/
5312017-07-11T19:35:42  <ryanofsky> to make discussion more concrete, what do you think of my blocksToDownloadFirst suggestion?
5322017-07-11T19:36:38  <jonasschnelli> ryanofsky: Yes. Make sense. But still, the requester (assume wallet) will need to blocks in a clear sequence (assume A, B, C, D and not C, D, A, B).
5332017-07-11T19:37:20  <jonasschnelli> Therefore there must be something that takes care of the state of a wallet/user initiated out-of-band block request and make sure, it will be passed in in sequence
5342017-07-11T19:38:22  <jonasschnelli> IMO its about "requesting n amount of "range of blocks" rather then just requesting blocks
5352017-07-11T19:40:12  <gmaxwell> jonasschnelli: right now the consensus logic requests the block download machinery to download blocks, keep track of the requests and what not.
5362017-07-11T19:40:16  <ryanofsky> i'm not sure i see the problem. that state could be tracked inside the wallet. wallet just needs to request blocks, get notifications when they come in, then request more blocks
5372017-07-11T19:40:29  <gmaxwell> jonasschnelli: sipa is pointing out that what you're doing is just adding an addition set of callers.
5382017-07-11T19:40:59  <gmaxwell> jonasschnelli: why does the wallet need blocks in order?
5392017-07-11T19:42:02  <jonasschnelli> gmaxwell: if we assume the wallet does show to the user what it had processed it would probably look strange if the wallet would update the balance, tx-list of block that come in out of order
5402017-07-11T19:42:38  <jonasschnelli> Also, detecting re-orgs would be difficult?
5412017-07-11T19:42:40  <ryanofsky> can't wallet keep track of it's own requests and ignore anything it wants to ignore?
5422017-07-11T19:43:13  <gmaxwell> if the wallet is just saying how far it had processed, couldn't it just show the minimum height processed so far?  showing things out of order would certantly allow things faster.
5432017-07-11T19:43:16  <jonasschnelli> ryanofsky: Yes. If we assume only wallets want that. What about the other user cases, ZMQ, light-client "middleware" (Oh I had this term)
5442017-07-11T19:44:53  <ryanofsky> jonasschnelli, that's why i was asking for some kind of design doc, going into the what specifically you envision there
5452017-07-11T19:45:17  <jonasschnelli> gmaxwell: hmm.. I guess the user would look at the transaction list and see a possible incoming transaction while a older expected incoming transaction is missing, regardless of how the wallet communicates "minimum process height"
5462017-07-11T19:45:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5472017-07-11T19:45:49  <sipa> jonasschnelli: right now, the only thing that "needs" blocks is the block validation
5482017-07-11T19:45:59  <sipa> you're adding something else that needs blocks
5492017-07-11T19:46:05  <jonasschnelli> ryanofsky: Not only, #10794 is purely RPC/ZMQ
5502017-07-11T19:46:06  <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
5512017-07-11T19:46:12  <sipa> both of them should be seen as users of the block fetching logic
5522017-07-11T19:46:24  <jonasschnelli> sipa: Ah. I understand now
5532017-07-11T19:48:02  *** chjj has joined #bitcoin-core-dev
5542017-07-11T19:48:24  <jonasschnelli> sipa, ryanofsky: The idea in 10794 is to have the validation triggered download logic in tact (minimal impact) while preferring out-of-band requests. And I tried to keep the logic, state-machine outside of net_processing.cpp to allow later code splits
5552017-07-11T19:49:11  <sipa> i think that's the wrong approach (though admittedly i haven't reviewed the code)
5562017-07-11T19:49:28  <jonasschnelli> (It's good you haven't so I can change it before you do. :) )
5572017-07-11T19:49:49  <jonasschnelli> sipa: what would you prefer then?
5582017-07-11T19:49:54  <sipa> jonasschnelli: as i explained
5592017-07-11T19:50:13  <sipa> refactor the current block downloading logic to support multiple users
5602017-07-11T19:50:24  <sipa> make it keep track of what blocks to download
5612017-07-11T19:50:43  <sipa> and what to do when they arrive
5622017-07-11T19:50:44  <jonasschnelli> sipa: I thought you are going to say that... I just think this is way larger but probably cleaner
5632017-07-11T19:50:56  <sipa> it's much more refactoring, yes
5642017-07-11T19:51:05  <sipa> but it'll be tiny to add light client fetching on top :)
5652017-07-11T19:51:28  <jonasschnelli> heh.. Yes. After that one or two year for the block download refactoring.. :)
5662017-07-11T19:52:47  <ryanofsky> am i missing something? https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677 seems pretty straightforward and not a large amount of refactoring
5672017-07-11T19:53:02  <jonasschnelli> I guess I focus to much on the minimal.impact solution rather then on the clean solution because I'm too much feature driven
5682017-07-11T19:53:54  *** vicenteH has joined #bitcoin-core-dev
5692017-07-11T19:54:22  <jonasschnelli> ryanofsky: Not sure if the idea in that comment fulfils sipa idea of having "multiple users for the download logic"
5702017-07-11T19:55:30  <morcos> sipa: i also like that idea, but i wonder if there is a priority difference there...  like how quickly you time out, or find someone else to deliver or penalize for bad behavior or etc...
5712017-07-11T19:55:45  <ryanofsky> because blocksToDownloadFirst is not sufficient for multiple users?
5722017-07-11T19:55:55  <morcos> who me?
5732017-07-11T19:56:03  <morcos> oh him
5742017-07-11T19:58:06  <jonasschnelli> ryanofsky: No I think because we would only partially (out of band request) allow multiple users for the block download. But not exactly sure to what extend sipas solution should go to
5752017-07-11T19:58:23  <ryanofsky> oh i think i see the difference. sipa's idea is to keep track of blocks to download and "what to do when they arrive". my idea would just do the first and let client figure out what to do when blocks come
5762017-07-11T19:58:25  <sipa> what do you mean with 'out of band' ?
5772017-07-11T19:59:19  <jonasschnelli> sipa: out-of-band is a poor multi-user approach for block download (the in-band is validation, the rest is out-of-band)
5782017-07-11T19:59:46  <sipa> i don't understand what you mean with 'out of band' in this context
5792017-07-11T19:59:55  <jonasschnelli> sipa: i guess what you meant is that the validation part uses the same block download interface then the light-client wallet? right?
5802017-07-11T20:00:16  <sipa> yes
5812017-07-11T20:01:03  <jonasschnelli> sipa: the validation requests block after it's own logic (not to far away, etc.), out-of-band requests can request a range of blocks that make no sense for the validation (in terms of time prioritation)
5822017-07-11T20:01:51  <jonasschnelli> sipa: I guess ryanofsky terms `blocksToDownloadFirst` is much better
5832017-07-11T20:01:52  <sipa> i still don't understand what you mean with out of band
5842017-07-11T20:02:31  <sipa> there are blocks to download, there is logic to determine which ones to download in what order, they're processed when they arrive
5852017-07-11T20:02:40  <jonasschnelli> I think i should call it "priorizedBlockRequests"
5862017-07-11T20:03:38  <jonasschnelli> sipa: Yes. But the light client (wallet) wants to break that oder by a) preferring other blocks first, b) pass them through BlockConnected() before they are connected to the tip
5872017-07-11T20:04:05  <jonasschnelli> (connected to the tip == validated, not connected == spv)
5882017-07-11T20:05:43  <sipa> sure
5892017-07-11T20:05:45  <jonasschnelli> ryanofsky: I think sipa's idea makes sense in the long run (don't distinct between wallet spv block requests and the validation triggered block request), ideally the validation would then use the same interface then the (light-client) wallet would use
5902017-07-11T20:06:09  <jonasschnelli> but this would be a lot of work
5912017-07-11T20:06:41  <sipa> sure, not everything has to happen in one go
5922017-07-11T20:06:47  <ryanofsky> yeah, i get that now. i think that refactoring is basically orthogonal though
5932017-07-11T20:07:06  <jonasschnelli> I agree...
5942017-07-11T20:07:07  <ryanofsky> you could do that refactoring with or without prioritized downloads, or vice versa
5952017-07-11T20:07:24  <sipa> ryanofsky: agree
5962017-07-11T20:07:36  <jonasschnelli> I even think implementing the prioritized downloads gives a better feeling on how-to-refactor
5972017-07-11T20:07:53  <jonasschnelli> because you refactor with a clear interface use-case
5982017-07-11T20:08:08  <sipa> yes, fair enough
5992017-07-11T20:08:53  <jonasschnelli> But I'm still not sure if it makes then sense to implement it within net_processing or leave it in a designated file (not very different IMO)
6002017-07-11T20:09:13  <jonasschnelli> Probably most devs things within net_processing.cpp makes more sense...
6012017-07-11T20:09:17  <jonasschnelli> *think
6022017-07-11T20:09:44  <jonasschnelli> Then let me do that and let me rename it from auxiliary (out-of-band) to prioritizedBlockRequests
6032017-07-11T20:14:26  *** AaronvanW has quit IRC
6042017-07-11T20:15:01  *** AaronvanW has joined #bitcoin-core-dev
6052017-07-11T20:19:06  *** jamesob_ has joined #bitcoin-core-dev
6062017-07-11T20:19:19  *** AaronvanW has quit IRC
6072017-07-11T20:21:28  *** jamesob has quit IRC
6082017-07-11T20:25:17  *** abpa has joined #bitcoin-core-dev
6092017-07-11T20:25:42  *** ybit2 is now known as ybit
6102017-07-11T20:31:55  <cfields> ok, i managed to patch boost and fix the lto linking error...
6112017-07-11T20:32:23  <cfields> anyone feel like looking at a head-scratcher?
6122017-07-11T20:32:38  <BlueMatt> really? I failed to do so previously
6132017-07-11T20:32:41  * BlueMatt is curious
6142017-07-11T20:33:24  <cfields> BlueMatt: was this your problem as well? https://pastebin.com/raw/kmqJVmfq
6152017-07-11T20:33:45  <BlueMatt> oh, no
6162017-07-11T20:34:01  <cfields> oh. what's yours?
6172017-07-11T20:34:03  <BlueMatt> i always got a link-time "~boost::filesystem::path() undefined" error
6182017-07-11T20:34:23  <BlueMatt> and occasionally for other destructors that were implicitly-defined in headers or explicitly defined in headers
6192017-07-11T20:34:31  <cfields> oh, same thing
6202017-07-11T20:34:40  <cfields> ZN5boost10filesystem4pathD1Ev is mangled destructor
6212017-07-11T20:35:14  <cfields> right, so the fix was to give it an explicit destructor in the .cpp
6222017-07-11T20:35:18  <BlueMatt> heh, your linker has garbage error messages
6232017-07-11T20:35:30  <BlueMatt> yes, but boost::filesystem::path has no .cpp
6242017-07-11T20:35:31  <cfields> but i'm not understanding why
6252017-07-11T20:35:33  <BlueMatt> or, i dont recall one
6262017-07-11T20:35:36  <BlueMatt> oh, i have no idea why
6272017-07-11T20:35:38  <cfields> it does
6282017-07-11T20:35:42  <BlueMatt> oh, ok
6292017-07-11T20:35:44  <sipa> BlueMatt: go test cfields's fix :p
6302017-07-11T20:36:03  <cfields> heh, I'll PR as soon as I can understand why it's a fix :)
6312017-07-11T20:36:16  <BlueMatt> and it mostly only happens to that one place, not on other destructors-defined-in-headers
6322017-07-11T20:36:25  <BlueMatt> but i have seen it on others before
6332017-07-11T20:36:30  <cfields> BlueMatt: right, there's a particular reason for these, sec
6342017-07-11T20:36:54  <sipa> there are fairly complicated rules in C++ about which object the implementation of some implicit methods goes into
6352017-07-11T20:37:11  <cfields> https://github.com/boostorg/filesystem/blob/develop/src/path.cpp#L703
6362017-07-11T20:37:33  <cfields> they're static vars there
6372017-07-11T20:38:20  <cfields> (and statics for each of the failures in the link)
6382017-07-11T20:38:27  <BlueMatt> ah, is that why? static objects with implicitly-defined destructors?
6392017-07-11T20:39:18  <cfields> so my best guess is... the static vars are created there when the lib is built, so an entry for the dtor is added. But we never use those functions...
6402017-07-11T20:39:56  <cfields> so i think it's either: a gcc/lto bug, or some crazy ODR-like issue
6412017-07-11T20:40:37  <cfields> oh, also, we build with fvisibility=hidden. when that's off for boost _and_ our build, it links fine
6422017-07-11T20:41:08  *** Dyaheon has quit IRC
6432017-07-11T20:41:55  <BlueMatt> lol
6442017-07-11T20:43:35  *** Dyaheon has joined #bitcoin-core-dev
6452017-07-11T20:56:16  *** AaronvanW has joined #bitcoin-core-dev
6462017-07-11T20:56:17  *** dermoth has quit IRC
6472017-07-11T20:58:38  *** dermoth has joined #bitcoin-core-dev
6482017-07-11T21:01:21  *** jamesob has joined #bitcoin-core-dev
6492017-07-11T21:03:17  *** jamesob_ has quit IRC
6502017-07-11T21:04:39  *** cheese_ has joined #bitcoin-core-dev
6512017-07-11T21:16:34  <gmaxwell> Did Paul Sztorc talk to anyone here before publishing his thing? (except luke-jr) I want to remark on his "
6522017-07-11T21:16:58  <gmaxwell> I wrote the roadmap to try to be representative of a Core / developer position." -- that if so he might have wanted to talk to some of the more frequent ones, it doesn't appear that he did.
6532017-07-11T21:17:09  <gmaxwell> But I want a fact-check before saying htat.
6542017-07-11T21:17:14  <gmaxwell> s/htat/that/
6552017-07-11T21:17:22  <BlueMatt> i havent heard from him
6562017-07-11T21:17:37  <BlueMatt> (nor speak to him specifically about that issue at any point i can recall)
6572017-07-11T21:21:33  *** abpa has quit IRC
6582017-07-11T21:26:48  *** Chris_Stewart_5 has quit IRC
6592017-07-11T21:32:59  *** JackH has quit IRC
6602017-07-11T21:33:05  *** dermoth has quit IRC
6612017-07-11T21:34:07  *** dermoth has joined #bitcoin-core-dev
6622017-07-11T21:43:57  *** timothy has joined #bitcoin-core-dev
6632017-07-11T21:48:34  *** PRab has quit IRC
6642017-07-11T21:49:37  *** dermoth has quit IRC
6652017-07-11T21:50:16  <jtimon> images... https://github.com/bitcoin/bitcoin/pull/10757#issuecomment-314581913
6662017-07-11T21:51:11  *** dermoth has joined #bitcoin-core-dev
6672017-07-11T21:53:12  <luke-jr> wumpus: https://github.com/UASF/bitcoin/releases/tag/v0.14.2-uasfsegwit1.0
6682017-07-11T22:11:31  *** cheese_ has quit IRC
6692017-07-11T22:15:10  *** cheese_ has joined #bitcoin-core-dev
6702017-07-11T22:16:59  *** Victor_sueca has joined #bitcoin-core-dev
6712017-07-11T22:20:06  *** Victorsueca has quit IRC
6722017-07-11T22:20:58  *** jouke has quit IRC
6732017-07-11T22:22:37  *** jouke has joined #bitcoin-core-dev
6742017-07-11T22:22:37  *** jouke has quit IRC
6752017-07-11T22:22:37  *** jouke has joined #bitcoin-core-dev
6762017-07-11T22:25:28  <cfields> sipa: aha, you were right
6772017-07-11T22:27:03  <cfields> i traced the symbol references in linker dumps. as-is, with lto, the destructor gets stuffed into util.o (because it's one of the files where there's a static reference)
6782017-07-11T22:27:50  <cfields> but when i comment out the static references in util.cpp, it links fine, and the destructor goes into a boost object (operations.o)
6792017-07-11T22:28:40  <cfields> IIRC when it's ambiguous, the linker is free to choose where to put the symbol, as long as it's just added to one object
6802017-07-11T22:29:38  <cfields> but with lto, it gets put into util.o. then, the link-order causes boost_filesystem to be unable to find it
6812017-07-11T22:29:47  <sipa> cfields: so, you fixed it?
6822017-07-11T22:30:06  <cfields> i believe so
6832017-07-11T22:30:43  *** promag has joined #bitcoin-core-dev
6842017-07-11T22:30:53  <cfields> 2 fixes: 1 quick hack to use a static string rather than a fs::path, to avoid the issue entirely. 2. the upstream boost fix
6852017-07-11T22:31:26  <promag> jtimon: please rename #10757
6862017-07-11T22:31:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
6872017-07-11T22:35:58  <jtimon> oh, right, I did s/getperblockstats/getblockstats/ as you suggested...thanks!
6882017-07-11T22:36:16  <bitcoin-git> [bitcoin] jnewbery opened pull request #10798: test bitcoin-cli (master...cli_tests) https://github.com/bitcoin/bitcoin/pull/10798
6892017-07-11T22:43:40  *** Dizzle has quit IRC
6902017-07-11T22:47:38  *** Dyaheon has quit IRC
6912017-07-11T22:47:38  *** riemann has quit IRC
6922017-07-11T22:49:13  *** Dyaheon has joined #bitcoin-core-dev
6932017-07-11T22:55:10  <cluelessperson> BlueMatt: So I'm looking at a 3.8ghz Xeon Quad Core,  256 GB PCI SSD 3200MBps Read, 1500MBps Write,   64 GB RAM DDR4, thoughts?
6942017-07-11T22:55:17  <cluelessperson> $1400
6952017-07-11T22:55:22  <cluelessperson> (rounded up)
6962017-07-11T22:55:43  <BlueMatt> -> #bitcoin
6972017-07-11T22:59:18  *** Aaronvan_ has joined #bitcoin-core-dev
6982017-07-11T23:00:08  *** spinza has quit IRC
6992017-07-11T23:00:20  *** Guyver2 has quit IRC
7002017-07-11T23:01:16  *** AaronvanW has quit IRC
7012017-07-11T23:03:22  *** ivan_ is now known as ivan
7022017-07-11T23:06:09  *** spinza has joined #bitcoin-core-dev
7032017-07-11T23:34:10  *** coredump_ has joined #bitcoin-core-dev
7042017-07-11T23:35:34  *** Aaronvan_ is now known as AaronvanW
7052017-07-11T23:37:13  *** cheese_ has quit IRC
7062017-07-11T23:50:10  *** goatpig has quit IRC
7072017-07-11T23:55:46  *** ivan has quit IRC