12017-04-27T00:00:09  *** goksinen has quit IRC
  22017-04-27T00:23:55  <cfields> well since we're all doing PRs for lots-of-changes-but-the-reason-isn't-obvious-until-the-next-PR, I suppose I'll do mine too.
  32017-04-27T00:24:20  *** marcoagner has quit IRC
  42017-04-27T00:24:53  *** marcoagner has joined #bitcoin-core-dev
  52017-04-27T00:24:59  <bitcoin-git> [bitcoin] theuni opened pull request #10285: net: refactor the connection process. moving towards async connections. (master...connman-events6) https://github.com/bitcoin/bitcoin/pull/10285
  62017-04-27T00:29:59  <fanquake> cfields Now just open two more, each with another 5 commits, all building on top of each other.
  72017-04-27T00:30:33  <cfields> fanquake: haha
  82017-04-27T00:31:40  <BlueMatt> cfields: to be fair, sipa objected to mine and so I'm gonna open the reason to get concept acks before merge of the dependant
  92017-04-27T00:32:58  <cfields> BlueMatt: sorry, that wasn't meant to be an insult. I've just been staring at this code for a week trying to figure out how to PR it. Just funny timing.
 102017-04-27T00:33:30  <BlueMatt> nor was mine, i was just pointing to the vague policy understanding i took from sipa's understanding of my own comments and figured I'd mention it as a possible suggestion
 112017-04-27T00:35:28  <sipa> as it seems to be a developing practice the past minutes in the vicinity of this communication channel to speak in relatively length sentences, i shall participate
 122017-04-27T00:35:42  <fanquake> cfields If you'd rather stare at some different code for a while; I've been tracking down a Windows issue that's blocking us from moving to latest ZMQ #9254
 132017-04-27T00:35:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9254 | [depends] ZeroMQ 4.2.2 by fanquake · Pull Request #9254 · bitcoin/bitcoin · GitHub
 142017-04-27T00:36:14  <cfields> greg was here.
 152017-04-27T00:36:16  <cfields> (probably)
 162017-04-27T00:36:29  <cfields> fanquake: looking
 172017-04-27T00:36:56  <BlueMatt> sipa: is your understanding of the developing practice of relatively lengthy sentences that it shall eventually move towards policy, or is it only a temporal disturbance in the sentence length requirement understanding of the participants of the vicinity of this channel?
 182017-04-27T00:37:49  <fanquake> Also, noticed that libzmq is being relicensed.
 192017-04-27T00:38:09  <fanquake> https://github.com/zeromq/libzmq/issues/2376
 202017-04-27T00:38:26  <BlueMatt> would that effect us?
 212017-04-27T00:38:42  <BlueMatt> ahh, if anything positively
 222017-04-27T00:38:55  <cfields> neat
 232017-04-27T00:39:14  <BlueMatt> man i do not envy them in having to collect license grants from /everyone/
 242017-04-27T00:39:44  <cfields> BlueMatt: they usually take the route of /everyone with a significant contribution/
 252017-04-27T00:39:50  <BlueMatt> even still
 262017-04-27T00:40:17  <cfields> yea: "from each individual contributor who wrote a major piece of code in the development process of libzmq"
 272017-04-27T00:40:37  <cfields> no fun
 282017-04-27T00:41:02  <cfields> but on the bright side, hooray for github centralization! Must make this much easier.
 292017-04-27T00:41:09  <BlueMatt> f$cking internet...isp has peering presence but only uses it for IPv6...time to go annoy some noc operators
 302017-04-27T00:41:24  <BlueMatt> s/peering/ix peering/
 312017-04-27T00:41:42  <cfields> heh
 322017-04-27T00:41:57  <cfields> fanquake: that error is very confusing. seems to be in a system header
 332017-04-27T00:42:21  <cfields> my best guess is there's some define magic going on somewhere?
 342017-04-27T00:44:36  <sipa> BlueMatt: i for one am of the opinion - which i shall hold until presented with sufficient evidence of the contrary - that this is merely a temporary phase, which will soon be considered inconvenient and unnecessary
 352017-04-27T00:46:35  <fanquake> cfields Yea I'll have to look into it further.
 362017-04-27T00:46:38  <gmaxwell> sipa: are you trying to match my length of lines on IRC?  It will take you an awful long time to catch up to my average.
 372017-04-27T00:46:48  *** marcoagner has quit IRC
 382017-04-27T00:47:34  <fanquake> cfields While you're here, any significant plans depends wise for 0.15.0 ? I had a bunch of updates lined up, but haven't PR'd anything because I wanted to know what you were doing.
 392017-04-27T00:47:56  <cfields> fanquake: go for it! the qt overhaul is the big one
 402017-04-27T00:48:01  <cfields> fanquake: an osx toolchain bump
 412017-04-27T00:48:47  <cfields> fanquake: I'll be doing the toolchain builder as well, but that should just plug in to current depends without too much interruption
 422017-04-27T00:49:05  <sipa> gmaxwell: that is an impossible task, i might venture to state, and surely one should not let mere statistics in the history of an ephemeral communication channel like this guide one's actions
 432017-04-27T00:49:19  <gmaxwell> sipa: You are currently at an average length of 54 in this channel... compared to my 103.
 442017-04-27T00:49:59  <fanquake> cfields qt overhaul in regard to 5.8? I think they have some new "lite" build system. Will we see any benefit from that, I would have thought we were already pretty optimised?
 452017-04-27T00:50:19  <achow101> gmaxwell: while you're here, any update on the alert key stuff?
 462017-04-27T00:50:26  <BlueMatt> lol
 472017-04-27T00:50:35  <cfields> fanquake: split builds for host/target.
 482017-04-27T00:50:36  <BlueMatt> saw that one coming
 492017-04-27T00:51:01  <cfields> fanquake: and yea, we'll benefit from the lite thing. We just need to crank up a long list of -no-feature-X
 502017-04-27T00:51:16  <cfields> (they're supposed to actually work now, rather than just breaking stuff)
 512017-04-27T00:51:33  <sipa> perhaps i shall go construct a plugin module for my Internet Relay Chat client to implement nagle's algorithm for outgoing messages and make it combine multiple successive lines into one?
 522017-04-27T00:51:46  <fanquake> cfields No worries, I'll have a look at that as well.
 532017-04-27T00:53:21  <cfields> fanquake: have you tried to bisect the zmq change? There are a bunch of versions in between :(
 542017-04-27T00:54:24  <gmaxwell> achow101: not yet. personally I'm hoping for more old stuff to age off the network, since the key is explotable against that old stuff. (A fact we didn't really know until I did the final homework before releasing the key)
 552017-04-27T00:55:03  *** vicenteH` has joined #bitcoin-core-dev
 562017-04-27T00:55:59  <fanquake> Somewhat, I originally opened that PR with 4.2.0, then moved to 4.2.1, then 4.2.2, all seemed to have the same issue. So I'm assuming it's something that might have happened between 4.1.6 -> 4.2.0 . Which I wouldn't have tested yet. I'll post in that PR if I find anything.
 572017-04-27T00:56:27  <achow101> gmaxwell: will those vulnerabilities be disclosed or not until old nodes drop off the network?
 582017-04-27T00:56:44  *** vicenteH has quit IRC
 592017-04-27T00:57:21  <cfields> fanquake: so 4.1.6 works?
 602017-04-27T00:57:52  <gmaxwell> achow101: well I'd rather not post a howto then later post the key. :)
 612017-04-27T00:58:19  <gmaxwell> achow101: if you want to amuse yourself, why not go find the issues yourself. Make a write up. though I'd ask you to keep ir private for now, though ultimately that would be up to you.
 622017-04-27T00:58:53  <achow101> but I can't know if I actually found something without the key
 632017-04-27T00:59:45  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10286: Call wallet notify callbacks in scheduler thread (without cs_main) (master...2017-01-wallet-cache-inmempool-4) https://github.com/bitcoin/bitcoin/pull/10286
 642017-04-27T01:00:27  <gmaxwell> achow101: well if you wanted to try it, you can change the key or rig the signature validation to return true for it.
 652017-04-27T01:01:10  <fanquake> cfields I can't remember if I tested it or just jumped straight to 4.2.0. I'll go back and take a look.
 662017-04-27T01:01:46  <cfields> fanquake: maybe try disabling the precompiled stuff?
 672017-04-27T01:02:07  <fanquake> The main windows related change from 4.1.6 seems to be https://github.com/zeromq/libzmq/issues/2091
 682017-04-27T01:03:16  <cfields> fanquake: aha! that could definitely be it. we may need to force the WINNT version
 692017-04-27T01:03:49  <achow101> gmaxwell: heh. social engineering failed :(. I will amuse myself and find those vulns
 702017-04-27T01:04:31  *** jcliff42 has quit IRC
 712017-04-27T01:04:35  <sipa> achow101: hahaha
 722017-04-27T01:05:39  <gmaxwell> hehe.
 732017-04-27T01:32:37  *** jcliff42 has joined #bitcoin-core-dev
 742017-04-27T01:34:00  <bitcoin-git> [bitcoin] jimmysong opened pull request #10287: [tests] Update Unit Test for addrman.h/addrman.cpp (master...test_addrman) https://github.com/bitcoin/bitcoin/pull/10287
 752017-04-27T01:36:04  *** tw2006 has joined #bitcoin-core-dev
 762017-04-27T01:40:23  *** tw2006 has quit IRC
 772017-04-27T01:43:28  *** goksinen has joined #bitcoin-core-dev
 782017-04-27T01:47:43  *** goksinen has quit IRC
 792017-04-27T01:49:16  *** annanay25 has quit IRC
 802017-04-27T01:49:18  *** Victor_sueca has joined #bitcoin-core-dev
 812017-04-27T01:49:25  *** annanay25 has joined #bitcoin-core-dev
 822017-04-27T01:52:11  *** Victorsueca has quit IRC
 832017-04-27T02:04:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 842017-04-27T02:24:02  *** jcliff42 has quit IRC
 852017-04-27T02:47:18  *** AaronvanW has quit IRC
 862017-04-27T03:03:17  *** Don_John has joined #bitcoin-core-dev
 872017-04-27T03:24:56  *** jcliff42 has joined #bitcoin-core-dev
 882017-04-27T03:24:58  *** tw2006 has joined #bitcoin-core-dev
 892017-04-27T03:29:05  *** jcliff42 has quit IRC
 902017-04-27T03:29:44  *** tw2006 has quit IRC
 912017-04-27T03:35:24  *** Azur has joined #bitcoin-core-dev
 922017-04-27T03:35:44  *** Azur has left #bitcoin-core-dev
 932017-04-27T03:39:57  <jl2012> on testnet I made a script to repeatedly send the same coin to myself every 15 second. When the tx chain becomes long enough, however, it stops working until confirmed. So there is a limit? Is it possible to bypass it?
 942017-04-27T03:40:43  <achow101> jl2012: the limit is 25 unconfirmed transactions in a chain
 952017-04-27T03:40:58  <achow101> you can raise it for your own node but not anyone else
 962017-04-27T03:41:41  <jl2012> so other miners won't mine beyond 25 txs by default?
 972017-04-27T03:41:52  <achow101> yes
 982017-04-27T03:42:06  <jl2012> thanks
 992017-04-27T03:45:54  *** Chris_Stewart_5 has quit IRC
1002017-04-27T04:01:51  *** goksinen has joined #bitcoin-core-dev
1012017-04-27T04:04:13  *** dodomojo has joined #bitcoin-core-dev
1022017-04-27T04:06:28  <sipa> jl2012: there is also an option to make the wallet refuse to create transactions with coins in too long chains (though it avoids using them by default)
1032017-04-27T04:07:43  *** goksinen has quit IRC
1042017-04-27T04:12:17  *** goksinen has joined #bitcoin-core-dev
1052017-04-27T04:14:17  *** moli_ has quit IRC
1062017-04-27T04:14:55  *** moli_ has joined #bitcoin-core-dev
1072017-04-27T04:15:37  *** dodomojo has quit IRC
1082017-04-27T04:26:38  *** jcliff42 has joined #bitcoin-core-dev
1092017-04-27T04:48:50  *** jcliff42 has quit IRC
1102017-04-27T04:53:44  *** jtimon has quit IRC
1112017-04-27T05:13:13  *** goksinen has quit IRC
1122017-04-27T05:13:55  *** tw2006 has joined #bitcoin-core-dev
1132017-04-27T05:18:22  *** tw2006 has quit IRC
1142017-04-27T05:45:10  *** jcliff42 has joined #bitcoin-core-dev
1152017-04-27T05:46:45  *** juscamarena has joined #bitcoin-core-dev
1162017-04-27T05:46:53  *** juscamarena_ has joined #bitcoin-core-dev
1172017-04-27T05:47:08  *** juscamarena is now known as Guest87345
1182017-04-27T06:00:14  *** dermoth has quit IRC
1192017-04-27T06:01:01  *** dermoth has joined #bitcoin-core-dev
1202017-04-27T06:06:04  *** Guest87345 has quit IRC
1212017-04-27T06:06:29  *** jcliff42 has quit IRC
1222017-04-27T06:44:22  *** vicenteH` is now known as vicenteH
1232017-04-27T07:00:40  *** BashCo has quit IRC
1242017-04-27T07:00:48  *** goksinen has joined #bitcoin-core-dev
1252017-04-27T07:02:54  *** tw2006 has joined #bitcoin-core-dev
1262017-04-27T07:03:56  *** kexkey has quit IRC
1272017-04-27T07:08:54  *** lightningbot has joined #bitcoin-core-dev
1282017-04-27T07:12:23  *** berndj has quit IRC
1292017-04-27T07:16:45  *** berndj has joined #bitcoin-core-dev
1302017-04-27T07:19:53  *** BashCo has joined #bitcoin-core-dev
1312017-04-27T07:25:53  *** Victor_sueca is now known as Victorsueca
1322017-04-27T07:48:16  *** BashCo has quit IRC
1332017-04-27T07:52:58  *** BashCo has joined #bitcoin-core-dev
1342017-04-27T07:53:28  *** isis has quit IRC
1352017-04-27T08:14:45  *** Ylbam has joined #bitcoin-core-dev
1362017-04-27T08:16:19  *** timothy has joined #bitcoin-core-dev
1372017-04-27T08:29:55  *** BashCo has quit IRC
1382017-04-27T08:30:14  *** jannes has joined #bitcoin-core-dev
1392017-04-27T08:30:39  *** mol has joined #bitcoin-core-dev
1402017-04-27T08:31:29  *** kungfuant has quit IRC
1412017-04-27T08:31:48  *** BashCo has joined #bitcoin-core-dev
1422017-04-27T08:32:08  *** moli_ has quit IRC
1432017-04-27T08:37:07  *** Don_John has quit IRC
1442017-04-27T08:51:47  *** tw2006 has joined #bitcoin-core-dev
1452017-04-27T08:55:51  *** Geovanni has joined #bitcoin-core-dev
1462017-04-27T08:56:16  *** tw2006 has quit IRC
1472017-04-27T09:43:23  *** goksinen has joined #bitcoin-core-dev
1482017-04-27T09:48:12  *** goksinen has quit IRC
1492017-04-27T09:57:15  *** jouke has quit IRC
1502017-04-27T09:59:22  *** jouke has joined #bitcoin-core-dev
1512017-04-27T10:11:05  *** mol has quit IRC
1522017-04-27T10:16:13  *** moli_ has joined #bitcoin-core-dev
1532017-04-27T10:35:39  *** jtimon has joined #bitcoin-core-dev
1542017-04-27T10:41:04  *** tw2006 has joined #bitcoin-core-dev
1552017-04-27T10:45:54  *** tw2006 has quit IRC
1562017-04-27T10:56:03  *** laurentmt has joined #bitcoin-core-dev
1572017-04-27T10:56:45  *** laurentmt has quit IRC
1582017-04-27T11:32:05  *** goksinen has joined #bitcoin-core-dev
1592017-04-27T11:33:52  *** Guyver2 has joined #bitcoin-core-dev
1602017-04-27T11:36:56  *** goksinen has quit IRC
1612017-04-27T11:37:07  *** AaronvanW has joined #bitcoin-core-dev
1622017-04-27T11:42:07  *** kexkey has joined #bitcoin-core-dev
1632017-04-27T11:49:47  *** tw2006 has joined #bitcoin-core-dev
1642017-04-27T12:04:04  *** Geovanni has quit IRC
1652017-04-27T12:26:21  *** goksinen has joined #bitcoin-core-dev
1662017-04-27T12:28:37  *** SopaXorzTaker has joined #bitcoin-core-dev
1672017-04-27T12:30:22  *** Victorsueca has quit IRC
1682017-04-27T12:31:04  *** goksinen has quit IRC
1692017-04-27T12:34:33  *** NewLiberty has joined #bitcoin-core-dev
1702017-04-27T12:35:13  *** NewLiberty has joined #bitcoin-core-dev
1712017-04-27T12:46:01  <fanquake> Is there a dev meeting tonight?
1722017-04-27T12:51:18  *** Ona has joined #bitcoin-core-dev
1732017-04-27T12:53:14  <jonasschnelli> fanquake: Yes.
1742017-04-27T12:53:28  <jonasschnelli> fanquake: in 6h and 7min.
1752017-04-27T12:54:06  <fanquake> jonasschnelli 3am :|
1762017-04-27T12:54:18  <jonasschnelli> fanquake: hah. Yeah. Hard for OZ.
1772017-04-27T13:08:48  *** Victorsueca has joined #bitcoin-core-dev
1782017-04-27T13:17:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1792017-04-27T13:25:59  <wumpus> yes the time is not exactly ideal for asia/OZ
1802017-04-27T13:43:27  *** paveljanik has quit IRC
1812017-04-27T13:45:09  *** NewLiberty has joined #bitcoin-core-dev
1822017-04-27T13:46:20  *** nu11p7r has quit IRC
1832017-04-27T13:50:38  *** d_t has joined #bitcoin-core-dev
1842017-04-27T13:53:09  *** goksinen has joined #bitcoin-core-dev
1852017-04-27T14:07:05  *** Chris_Stewart_5 has quit IRC
1862017-04-27T14:22:26  *** mol has joined #bitcoin-core-dev
1872017-04-27T14:25:52  *** moli_ has quit IRC
1882017-04-27T14:46:05  *** altoz_ is now known as altoz
1892017-04-27T14:53:22  *** Victorsueca has quit IRC
1902017-04-27T14:54:31  *** Victorsueca has joined #bitcoin-core-dev
1912017-04-27T14:58:04  *** BashCo has quit IRC
1922017-04-27T15:00:05  *** BashCo has joined #bitcoin-core-dev
1932017-04-27T15:42:34  *** laurentmt has joined #bitcoin-core-dev
1942017-04-27T15:42:49  *** BashCo has quit IRC
1952017-04-27T15:44:04  *** BashCo has joined #bitcoin-core-dev
1962017-04-27T15:44:53  *** bsm1175321 has joined #bitcoin-core-dev
1972017-04-27T15:49:14  *** bsm1175321 has quit IRC
1982017-04-27T15:53:15  *** abpa has joined #bitcoin-core-dev
1992017-04-27T16:08:05  *** BashCo has quit IRC
2002017-04-27T16:21:25  *** goksinen has quit IRC
2012017-04-27T16:24:46  *** BashCo has joined #bitcoin-core-dev
2022017-04-27T16:25:52  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/47535d7c3ec7...a550f6e415fd
2032017-04-27T16:25:52  <bitcoin-git> bitcoin/master 3edbd79 Alex Morcos: cleanup: reduce to one GetMinimumFee call signature
2042017-04-27T16:25:53  <bitcoin-git> bitcoin/master a550f6e Pieter Wuille: Merge #10283: Cleanup: reduce to one GetMinimumFee call signature...
2052017-04-27T16:26:15  <bitcoin-git> [bitcoin] sipa closed pull request #10283: Cleanup: reduce to one GetMinimumFee call signature (master...oneGetMinimumFee) https://github.com/bitcoin/bitcoin/pull/10283
2062017-04-27T16:41:58  *** Victorsueca has quit IRC
2072017-04-27T16:42:23  *** goksinen has joined #bitcoin-core-dev
2082017-04-27T16:43:05  *** Victorsueca has joined #bitcoin-core-dev
2092017-04-27T16:46:40  *** goksinen has quit IRC
2102017-04-27T16:59:59  *** timothy has quit IRC
2112017-04-27T17:21:27  *** jtimon has quit IRC
2122017-04-27T17:23:32  *** goksinen has joined #bitcoin-core-dev
2132017-04-27T17:28:59  *** goksinen has quit IRC
2142017-04-27T17:38:10  *** laurentmt has quit IRC
2152017-04-27T17:44:43  *** goksinen has joined #bitcoin-core-dev
2162017-04-27T17:45:09  *** Guyver2 has quit IRC
2172017-04-27T17:49:35  *** goksinen has quit IRC
2182017-04-27T17:55:30  *** afk11 has quit IRC
2192017-04-27T17:55:45  *** afk11 has joined #bitcoin-core-dev
2202017-04-27T18:04:26  *** goksinen has joined #bitcoin-core-dev
2212017-04-27T18:13:00  *** jcliff42 has joined #bitcoin-core-dev
2222017-04-27T18:20:01  *** tw2006 has quit IRC
2232017-04-27T18:20:37  *** tw2006 has joined #bitcoin-core-dev
2242017-04-27T18:22:14  *** jtimon has joined #bitcoin-core-dev
2252017-04-27T18:26:12  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a550f6e415fd...4c924011f535
2262017-04-27T18:26:12  <bitcoin-git> bitcoin/master b51aaf1 practicalswift: Remove unused C++ code not covered by unit tests
2272017-04-27T18:26:13  <bitcoin-git> bitcoin/master 4c92401 Wladimir J. van der Laan: Merge #10075: Remove unused C++ code not covered by unit tests...
2282017-04-27T18:26:32  <bitcoin-git> [bitcoin] laanwj closed pull request #10075: Remove unused C++ code not covered by unit tests (master...unused) https://github.com/bitcoin/bitcoin/pull/10075
2292017-04-27T18:27:10  *** goksinen has quit IRC
2302017-04-27T18:27:43  *** SopaXorzTaker has quit IRC
2312017-04-27T18:33:52  *** altoz has quit IRC
2322017-04-27T18:34:51  *** altoz has joined #bitcoin-core-dev
2332017-04-27T18:36:22  *** altoz has joined #bitcoin-core-dev
2342017-04-27T18:37:27  *** altoz has joined #bitcoin-core-dev
2352017-04-27T18:38:22  *** trippysa1mon has joined #bitcoin-core-dev
2362017-04-27T18:38:58  *** jonasschnelli has quit IRC
2372017-04-27T18:38:58  *** trippysalmon has quit IRC
2382017-04-27T18:38:58  *** thermoman has quit IRC
2392017-04-27T18:39:04  *** jonasschnelli_ has joined #bitcoin-core-dev
2402017-04-27T18:39:11  *** thermoman has joined #bitcoin-core-dev
2412017-04-27T18:40:30  *** jonasschnelli_ has quit IRC
2422017-04-27T18:40:42  *** jonasschnelli has joined #bitcoin-core-dev
2432017-04-27T18:40:58  *** jonasschnelli has joined #bitcoin-core-dev
2442017-04-27T18:49:04  *** Giszmo has joined #bitcoin-core-dev
2452017-04-27T18:56:39  *** belcher has quit IRC
2462017-04-27T18:59:27  *** jcliff42 has quit IRC
2472017-04-27T19:01:09  <luke-jr> meeting?
2482017-04-27T19:01:21  <jonasschnelli> Yes
2492017-04-27T19:01:24  <petertodd> yup
2502017-04-27T19:01:28  <kanzure> yes
2512017-04-27T19:02:00  <BlueMatt> wumpus, wherefor art thou wumpus
2522017-04-27T19:02:01  <wumpus> #startmeeting
2532017-04-27T19:02:01  <lightningbot> Meeting started Thu Apr 27 19:02:01 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2542017-04-27T19:02:01  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2552017-04-27T19:02:31  <jonasschnelli> I have two topic proposals: "hd-restore" and "limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling"
2562017-04-27T19:02:33  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
2572017-04-27T19:02:33  <wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
2582017-04-27T19:02:39  <kanzure> hi.
2592017-04-27T19:02:44  <instagibbs> here
2602017-04-27T19:02:47  <cfields> hi
2612017-04-27T19:03:03  *** edcba has joined #bitcoin-core-dev
2622017-04-27T19:03:17  <wumpus> #topic hd-restore (jonasschnelli)
2632017-04-27T19:03:17  *** praxeology has joined #bitcoin-core-dev
2642017-04-27T19:03:21  <jtimon> suggested topic: summary of BlueMatt's overall plan for libconsensu
2652017-04-27T19:03:41  <kanzure> is this 10240?
2662017-04-27T19:03:45  <jtimon> if BlueMatt wants of course
2672017-04-27T19:03:47  <BlueMatt> jtimon: k, can share. jonasschnelli you have the floor :)
2682017-04-27T19:03:50  <jonasschnelli> Re. HD restore. I'm not sure if we should always try to restore funds or if we should check for the bestblock and compare it to the chain tip and only then restore
2692017-04-27T19:04:12  <jonasschnelli> The main stuff is in #10240
2702017-04-27T19:04:13  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | [WIP] Add basic HD wallet restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
2712017-04-27T19:04:24  <instagibbs> ack libconsensus discussion
2722017-04-27T19:04:34  <jonasschnelli> But I think we should only restore if the wallet's bestblock lacks behind
2732017-04-27T19:04:35  <instagibbs> oh sorry, didnt see topic set already :)
2742017-04-27T19:04:44  <jonasschnelli> Because...
2752017-04-27T19:04:51  <jonasschnelli> Encrypted wallets may need to unlock
2762017-04-27T19:05:06  <jonasschnelli> And also for performance / log reasons
2772017-04-27T19:05:09  <BlueMatt> jonasschnelli: i assumed we'd always keep a buffer of X pubkeys around
2782017-04-27T19:05:15  <BlueMatt> because you may have wallet "forks"
2792017-04-27T19:05:21  <BlueMatt> not sure what you mean by "restore"?
2802017-04-27T19:05:28  <BlueMatt> (feel free to tell me to shut up and go read the pr)
2812017-04-27T19:05:55  <jonasschnelli> BlueMatt: By restore I mean always check the keypool keys and auto-extend (if only 50 [TBD] keys are left, topup to 100 [TBD]
2822017-04-27T19:05:57  <kanzure> looks like it's re: finding relevant transactions
2832017-04-27T19:06:19  <jonasschnelli> If we always restore... we would need to unlock encrypted wallet...
2842017-04-27T19:06:29  <jonasschnelli> (more often)
2852017-04-27T19:06:30  <sipa> jonasschnelli: my assumption was that we'd always mark seen keys as used (and we should do that independently)
2862017-04-27T19:06:43  <sipa> jonasschnelli: we should also always extend the keypool when we can
2872017-04-27T19:06:54  <BlueMatt> jonasschnelli: ah, you mean like "when do we extend keypool to watch buffer"?
2882017-04-27T19:06:56  <jonasschnelli> sipa: Yes. But what if we can't?
2892017-04-27T19:06:59  <sipa> jonasschnelli: and if the keypool runs out in a non-interactive setting, shutdown
2902017-04-27T19:07:00  <achow101> If it needs to generate keys you could prompt the user right when the main gui pops up
2912017-04-27T19:07:15  <jonasschnelli> And whats a save gap limit? I would assume >100 keys.
2922017-04-27T19:07:18  <BlueMatt> another option would be to stop updating best seen block
2932017-04-27T19:07:29  <BlueMatt> and then kick off a background rescan-from-that-height when wallet next unlocks
2942017-04-27T19:07:38  <jonasschnelli> If someone has handed out 101 keys and only the position 101 has payed...
2952017-04-27T19:07:38  <BlueMatt> if gap goes under some threshold
2962017-04-27T19:07:45  <kanzure> yea, trigger on next unlock is better than achow101 popup
2972017-04-27T19:07:58  <BlueMatt> achow101: needs to be cli-compatible, though
2982017-04-27T19:08:03  <jonasschnelli> achow101: GUI is solvable..
2992017-04-27T19:08:07  <sipa> jonasschnelli: if we fix the bdb flushing stupidity, generating new keys becomes very cheap
3002017-04-27T19:08:11  <jonasschnelli> I don't know how to solve the non GUI way
3012017-04-27T19:08:20  <sipa> jonasschnelli: shutdown. make sure it doesn't happen
3022017-04-27T19:08:21  <achow101> jonasschnelli: how would you hand out 101 keys if the 101st wasn't generated yet?
3032017-04-27T19:08:29  <BlueMatt> jonasschnelli: i mean keys are cheap, can do 250 or 500 or something crazy
3042017-04-27T19:08:35  <jonasschnelli> sipa: But how to unlock during init in the first place?
3052017-04-27T19:08:40  <sipa> jonasschnelli: you can't
3062017-04-27T19:08:47  <BlueMatt> jonasschnelli: but cant we just use the keypool number now as the "buffer"?
3072017-04-27T19:08:48  <sipa> ah, i see what you mean
3082017-04-27T19:08:50  <jonasschnelli> But right after we rescan and sync
3092017-04-27T19:09:07  <BlueMatt> and, like, the lower bound should be like keypool count / 2
3102017-04-27T19:09:21  <BlueMatt> sipa: you cant just shutdown mid-sync
3112017-04-27T19:09:30  <jonasschnelli> BlueMatt: Yes. But with the current 100 default, we would enforce a shutdown on startup for encrypted wallets
3122017-04-27T19:09:33  <sipa> BlueMatt: why not?
3132017-04-27T19:09:47  <sipa> it's an error condition that we cannot recover from
3142017-04-27T19:09:48  * BlueMatt re-proposes that we stop updating wallet's best height if our keypool falls below keypool / 2
3152017-04-27T19:09:56  <BlueMatt> and then rescan when keypool next gets filled
3162017-04-27T19:09:57  <sipa> hmm
3172017-04-27T19:10:05  <jonasschnelli> IMO an explicit "restore-mode" with a "unlock during startup" (not sure how) would be preferable for encrypted wallets
3182017-04-27T19:10:12  <sipa> BlueMatt: you should also stop pruning
3192017-04-27T19:10:20  <BlueMatt> sipa: yes, that would be my major reservation
3202017-04-27T19:10:29  <BlueMatt> jonasschnelli: not sure you realistically can in a daemon setting
3212017-04-27T19:10:40  <jonasschnelli> is stdin a total nogo? *duck*
3222017-04-27T19:10:44  <sipa> so i guess we need a special "stop syncing" mode that we go into when the keypool runs out
3232017-04-27T19:10:49  <sipa> jonasschnelli: there is no stdin with -daemon
3242017-04-27T19:10:51  <BlueMatt> sipa: i guess you can stop pruning and if disk fills it will do the shutdown part for you :p
3252017-04-27T19:10:58  <sipa> BlueMatt: ugh
3262017-04-27T19:11:02  <BlueMatt> yea, i know
3272017-04-27T19:11:03  <jonasschnelli> sipa: Yes. But at least you could run in non-daemon headless
3282017-04-27T19:11:07  <wumpus> yes a blocking mode makes sense in that case
3292017-04-27T19:11:24  <BlueMatt> ok, so blocking in pruning mode, rescan-later in non-pruning mode?
3302017-04-27T19:11:34  <wumpus> and no, stdin is not an option, there should be no expectation with bitcoind that there's anyone at the terminal
3312017-04-27T19:11:35  <jonasschnelli> If you run with an encrypted wallet and the bestblock lacks behind, shutdown if we can't unlock over stdin
3322017-04-27T19:11:52  <BlueMatt> no stdin, just shutdown
3332017-04-27T19:11:56  <jonasschnelli> wumpus: So we have only RPC to unlock?
3342017-04-27T19:11:57  <wumpus> everything should be scriptable
3352017-04-27T19:11:57  <BlueMatt> jonasschnelli: but only in prune mode
3362017-04-27T19:12:07  <wumpus> jonasschnelli: yes
3372017-04-27T19:12:14  <jonasschnelli> But how do we unlock/extend before we sync?
3382017-04-27T19:12:25  <wumpus> just wait until the wallet is unlocked to start
3392017-04-27T19:12:25  <jonasschnelli> rpc starts after chain sync
3402017-04-27T19:12:31  <sipa> jonasschnelli: you go into a blocking mode, and you continue after walletunlock
3412017-04-27T19:12:37  <wumpus> right
3422017-04-27T19:12:52  <sipa> jonasschnelli: and no, no stdin ever
3432017-04-27T19:13:03  <jonasschnelli> but can we block the sync and wait for RPC wallettunlock?
3442017-04-27T19:13:09  <sipa> jonasschnelli: why not?
3452017-04-27T19:13:15  <wumpus> sure
3462017-04-27T19:13:18  <jonasschnelli> (without changing too much)?
3472017-04-27T19:13:18  <BlueMatt> ProcessNewBlock { return false; }
3482017-04-27T19:13:31  <jonasschnelli> okay... sounds good. Need to take a closer look.
3492017-04-27T19:13:33  <sipa> add a function to validation.h to let the core know that validation cannot progress
3502017-04-27T19:13:42  <BlueMatt> maybe stop net too under the current net-pause stuff
3512017-04-27T19:13:47  <sipa> right
3522017-04-27T19:13:53  <jonasschnelli> Good point.
3532017-04-27T19:13:54  <kanzure> should it shutdown if wallet is not unlocked within a certain time period? if it's not shutdown users might expect it to still be syncing.
3542017-04-27T19:14:00  <jonasschnelli> Next question: what's a sane gap limit?
3552017-04-27T19:14:02  <wumpus> the only precondition for getting out of Init() is that the genesis block has been processed, everything else can be delayed
3562017-04-27T19:14:04  <jonasschnelli> 100 seems way to low to me
3572017-04-27T19:14:16  <sipa> jonasschnelli: fix bdb flushing insanity, and raise it to 1000 or 10000
3582017-04-27T19:14:17  <BlueMatt> jonasschnelli: keypool / 2?
3592017-04-27T19:14:18  <jonasschnelli> (risk of losing funds is involved)
3602017-04-27T19:14:24  <BlueMatt> and we can bump keypool to 500
3612017-04-27T19:14:25  <achow101> how would you know that it is blocking and you need to walletunlock?
3622017-04-27T19:14:29  <kanzure> jonasschnelli: i think the answer will depend on performance.  also, do you really want to encourage users to use gaps? the answer might be yes..
3632017-04-27T19:15:06  <kanzure> achow101: yes that is why i suggested shutdown after a certain period of time. users might not realize that syncing is stopped otherwise.
3642017-04-27T19:15:15  <jonasschnelli> there my next concern pops up... all user will always have to have 500+ keypools. In an explicit restore more, only then we would need to have a large pool
3652017-04-27T19:15:30  <sipa> jonasschnelli: who cares about 500 keys'
3662017-04-27T19:15:41  <sipa> it's 16 kB of memory
3672017-04-27T19:15:52  <sipa> well, some small constant multiple of that
3682017-04-27T19:15:52  <kanzure> i thought derivation time was the bottleneck?
3692017-04-27T19:15:56  <jonasschnelli> Hmm... yes.
3702017-04-27T19:15:57  *** tw2006 has quit IRC
3712017-04-27T19:16:08  <jonasschnelli> If it just would be a pubkey and H160 onyl.. but it's also the privatre key! hell
3722017-04-27T19:16:17  <wumpus> the memory usage of keys is not an issue, just generation time (and that's only due to bdb stupidity)
3732017-04-27T19:16:33  <sipa> kanzure: we can do ~10000 derivation steps per second on a single thread on modern CPU
3742017-04-27T19:16:37  *** tw2006 has joined #bitcoin-core-dev
3752017-04-27T19:16:42  <kanzure> is that with bdb madness? :)
3762017-04-27T19:16:46  <sipa> and maybe 5 due to BDB flushing
3772017-04-27T19:16:47  <wumpus> calling fsync after every key is not a good idea, it should create the entire keypool refill in one transaction
3782017-04-27T19:16:53  <luke-jr> IMO automatic pruning should probably have as a precondition that the wallet has updated to the block being pruned, if it doesn't already; then the wallet can just set its criteria for processing
3792017-04-27T19:17:20  <luke-jr> and if auto-pruning is enabled, block validation (safely) when the size is hit, until it can prune further?
3802017-04-27T19:17:30  <sipa> luke-jr: agree, but that's not a concern right now as the wallet updates synchronously... with BlueMatt's coming changes maybe that changes
3812017-04-27T19:17:42  <BlueMatt> yes, that changes, but it still shouldnt be too slow
3822017-04-27T19:17:48  <jonasschnelli> With HD, there would also be no need for the disk-keypool for unencrypted wallets,.. it's just legacy. We could always fill up in-mem
3832017-04-27T19:18:02  <BlueMatt> if your wallet falls behind consensus, you have a very, very large wallet
3842017-04-27T19:18:13  <BlueMatt> (and should pause sync anyway)
3852017-04-27T19:18:39  <sipa> right, the wallet should have the ability to pause syncing or prevent pruning
3862017-04-27T19:18:49  <jonasschnelli> Conclusion: a) always scan keypool and topup, b) extend keypool and gap-limit to 500+, c) block when encrypted until RPC unlocked.
3872017-04-27T19:19:11  <sipa> sgtm
3882017-04-27T19:19:17  <wumpus> yes
3892017-04-27T19:19:18  <jonasschnelli> thanks. That was effective
3902017-04-27T19:19:32  <wumpus> #topic libconsensus (BlueMatt)
3912017-04-27T19:19:51  <BlueMatt> yes, so obviously this is all based on #771
3922017-04-27T19:19:53  <gribble> https://github.com/bitcoin/bitcoin/issues/771 | CBlockStore by TheBlueMatt · Pull Request #771 · bitcoin/bitcoin · GitHub
3932017-04-27T19:19:59  <BlueMatt> :)
3942017-04-27T19:20:08  <jonasschnelli> (19 Jan 2012)
3952017-04-27T19:20:22  <wumpus> archeology?
3962017-04-27T19:20:23  <BlueMatt> but pr #10279 creates a CChainState class which will hold things like mapBlockIndex chainActive, etc, etc
3972017-04-27T19:20:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
3982017-04-27T19:20:40  <BlueMatt> and have ProcessNewBlock Activate..., Connect, etc, etc, etc
3992017-04-27T19:20:53  <sipa> yay
4002017-04-27T19:21:04  <BlueMatt> long-term that class' public interface will be libbitcoinconsensus, but right now its really just to clean up internal interfaces within validation.cpp
4012017-04-27T19:21:13  <wumpus> sounds good to me
4022017-04-27T19:21:29  <BlueMatt> that class would get a pcoinsTip and related stuff to write/read blocks from disk
4032017-04-27T19:21:39  <BlueMatt> and then only be able to call that and pure functions (eg script validation)
4042017-04-27T19:21:45  <jtimon> BlueMatt: so what's the next thing we will be able to expose with these changes?
4052017-04-27T19:21:51  <cfields> ooh, +1
4062017-04-27T19:21:54  <BlueMatt> there is a bit of cleanup in the pr, but mostly its just moving into a class
4072017-04-27T19:22:06  <BlueMatt> jtimon: expose-wise? probably nothing for like 2 more releases "until its ready"
4082017-04-27T19:22:15  * BlueMatt is not a fan of libbitcoinconsensus being a grab-bag of random verification functions
4092017-04-27T19:22:21  <jtimon> the class itself? mhmm
4102017-04-27T19:22:32  <BlueMatt> i mean "the class"  but I assume via a C API
4112017-04-27T19:24:01  <BlueMatt> any other questions? or next topic?
4122017-04-27T19:24:08  <jtimon> yes, I know, and I'm very open to see what you want to expose, even if I don't renounce to the verifyWithoutChangingState x {block, header, tx, script} + getFlags() vision I had
4132017-04-27T19:24:38  <jtimon> but that's helpful, I can just imagine the class being exposed as a c api
4142017-04-27T19:25:15  <wumpus> not directly, it's just another step toward being able to
4152017-04-27T19:25:36  <wumpus> #topic limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling (jonasschnelli)
4162017-04-27T19:25:57  <petertodd> wumpus: +1
4172017-04-27T19:25:57  <jonasschnelli> I wanted to ask if a first step to announce pruned NODE_NETWORK would make sense.
4182017-04-27T19:26:04  <jonasschnelli> Could be NODE_NETWORK_LIMITED
4192017-04-27T19:26:11  <sipa> jonasschnelli: what would it entail?
4202017-04-27T19:26:14  <jonasschnelli> The only requirement is relay, and serve the last 144 blocks
4212017-04-27T19:26:21  <petertodd> jonasschnelli: ACK
4222017-04-27T19:26:22  <wumpus> we had this discussion recently, I thnk the conclusion was to use two service bits
4232017-04-27T19:26:28  <wumpus> (or one, at first)
4242017-04-27T19:26:31  <gmaxwell> what wumpus said.
4252017-04-27T19:26:32  <jonasschnelli> (which is almost always possible with the current auto-prune limit)
4262017-04-27T19:26:43  <sipa> i would suggest something that guarantees 1 day and 1 week
4272017-04-27T19:26:51  <wumpus> one bit combination would be 144, one would be ~1000
4282017-04-27T19:26:58  <luke-jr> jonasschnelli: so segwit prune=550 wouldn't be allowed?
4292017-04-27T19:27:02  * BlueMatt resists the urge to bikeshed on the "1 week" number
4302017-04-27T19:27:02  <gmaxwell> Which should be 2 days and 2 weeks so the boundary condition doesn't leave you right out.
4312017-04-27T19:27:09  <sipa> BlueMatt: i have data!
4322017-04-27T19:27:11  <jonasschnelli> luke-jr: We would have to bump there
4332017-04-27T19:27:14  <gmaxwell> BlueMatt: sipa has data on request rates.
4342017-04-27T19:27:21  <BlueMatt> oh, true, thats right
4352017-04-27T19:27:22  <wumpus> luke-jr: it's allowed, but it can't signal anything
4362017-04-27T19:27:44  <sipa> BlueMatt: i'll analyse the numbers again if there is interest
4372017-04-27T19:27:44  <gmaxwell> The only think to bikeshed is how much higher do we need the cutoff than his data, it should be at least a couple blocks higher because of reorgs/boundary conditions.
4382017-04-27T19:27:49  *** mol has quit IRC
4392017-04-27T19:28:20  <gmaxwell> our existing minimum sizing for pruning is sized out for 288 blocks, so I think we should just do that, it will make ~144 pretty reliable.
4402017-04-27T19:28:29  <bitcoin-git> [bitcoin] sipa opened pull request #10290: Add -stopatheight for benchmarking (master...shutdown_at_height) https://github.com/bitcoin/bitcoin/pull/10290
4412017-04-27T19:28:38  <wumpus> yep
4422017-04-27T19:28:47  <BlueMatt> sipa: ack without seeing code
4432017-04-27T19:28:49  <jonasschnelli> Two service bits seems to be great. Did anyone started with specs/BIP?
4442017-04-27T19:29:27  <sipa> BlueMatt: i just have a log of which depths of blocks are being fetched from my node
4452017-04-27T19:29:42  <cfields> how would NODE_NETWORK_LIMITED interact (if at all) with the remote peer's advertised height?
4462017-04-27T19:29:49  *** jcliff42 has joined #bitcoin-core-dev
4472017-04-27T19:29:59  <sipa> BlueMatt: since february
4482017-04-27T19:30:03  <gmaxwell> cfields: I don't think it should?
4492017-04-27T19:30:05  <luke-jr> IMO would be nicer to have the new service bit require *some* historical storage, but I guess we're not running out..
4502017-04-27T19:30:08  <jonasschnelli> IMO the purpose is to signal "I have only a limited amount of blocks"
4512017-04-27T19:30:12  <wumpus> cfields: not at all, we ignore that value
4522017-04-27T19:30:24  <BlueMatt> sipa: yes, i recall now
4532017-04-27T19:30:26  <cfields> ok, good
4542017-04-27T19:30:27  <gmaxwell> That advetised height shouldn't be used for almost anything.
4552017-04-27T19:30:28  <wumpus> (as it's easily spoofable)
4562017-04-27T19:30:31  <jonasschnelli> The best-height in version doesn't matter IMO
4572017-04-27T19:30:32  <wumpus> it isn't used at all
4582017-04-27T19:30:39  <sipa> i believe it is not used at all
4592017-04-27T19:30:41  *** jcliff42 has quit IRC
4602017-04-27T19:30:44  <sipa> (by bitcoin core)
4612017-04-27T19:30:46  <luke-jr> I'm not sure why more than the last 1-2 blocks should be needed to indicate relaying
4622017-04-27T19:30:53  <jonasschnelli> wumpus: I  think it's used by SPV
4632017-04-27T19:31:01  <gmaxwell> luke-jr: because or reorgs.
4642017-04-27T19:31:14  *** jcliff42 has joined #bitcoin-core-dev
4652017-04-27T19:31:20  <gmaxwell> if I can't serve you the parents of my tip, I can't help you reorg onto it, making my serving nearly useless.
4662017-04-27T19:31:24  <wumpus> jonasschnelli: I meant in bitcoin core; I don't know about other implementations
4672017-04-27T19:31:24  <luke-jr> hmm
4682017-04-27T19:31:28  <jonasschnelli> Is a min of 144 blocks to height?
4692017-04-27T19:31:44  <jonasschnelli> No... nm
4702017-04-27T19:31:45  <petertodd> luke-jr: and requiring nodes to have a GB or two of space for this is a trivial cost these days
4712017-04-27T19:31:52  <achow101> is the point of NODE_NETWORK_LIMITED just to tell nodes that they can request the most recent blocks from said node?
4722017-04-27T19:31:55  <luke-jr> assuming we only fetch blocks when reorging to their chain
4732017-04-27T19:32:02  <instagibbs> It's the unbounded growth that gets people to shut off nodes
4742017-04-27T19:32:04  <achow101> and right now you can't request any blocks from pruned nodes?
4752017-04-27T19:32:11  <gmaxwell> In any case the bit must promise more than nodes count on.
4762017-04-27T19:32:17  <sipa> achow101: pruned nodes don't even advertize they can relay blocks
4772017-04-27T19:32:34  <instagibbs> achow101, NODE_NETWORK is a flag for that, and it's missing from pruned nodes currently
4782017-04-27T19:32:36  <jonasschnelli> achow101: once you are in sync (>-144) you can pair with pruned peers and be fine
4792017-04-27T19:32:53  <achow101> ok
4802017-04-27T19:32:56  <gmaxwell> Say nodes frequently need to catch up a day.  You only keep 144 blocks.   Peer needs to catch up a day, connects to you.. opps you can't help them because a day turned out to be 150 blocks, they wasted their time connecting to you for nothing.
4812017-04-27T19:33:43  <gmaxwell> So for this to be useful the requester has to be conservative and not try to talk to you unless it thinks you are _very_ likely to have what it needs, which means that you need a fair amount more than the target.
4822017-04-27T19:34:11  <gmaxwell> So to serve a day of blocks, you'll need a day and a half or so. Round it up to 288.
4832017-04-27T19:34:25  <gmaxwell> petertodd: oh hi. long time no see.
4842017-04-27T19:34:33  <petertodd> gmaxwell: heh
4852017-04-27T19:34:39  <gmaxwell> and as mentioned, our pruning limit is already there.
4862017-04-27T19:34:49  <jonasschnelli> I just think we should allow the current auto-pruning 550 peers to signal relay and "limited amount of blocks around the tip".
4872017-04-27T19:35:08  <luke-jr> so 137 blocks?
4882017-04-27T19:35:21  <jonasschnelli> If we set NODE_NETWORK_LIMIT higher while allowing to prune shorter,.. this would wast potential peers
4892017-04-27T19:35:22  <petertodd> luke-jr: 1337 blocks
4902017-04-27T19:35:27  <gmaxwell> jonasschnelli: then that will never be used.
4912017-04-27T19:35:28  <jonasschnelli> heh
4922017-04-27T19:35:43  <gmaxwell> If we don't know how many blocks to except we'll never connect to them.
4932017-04-27T19:35:55  *** jcliff42 has quit IRC
4942017-04-27T19:36:14  <gmaxwell> This impacts the connection logic, we'll need logic that changes the requested services based on an estimate of how far back we are.
4952017-04-27T19:36:17  <sipa> when you're fully synced, why wouldn't you connect to a node that guarantees for example having the last 10 blocks?
4962017-04-27T19:36:19  <jonasschnelli> gmaxwell: Well, if we are in sync, you could be friendly and make space for the one who need sync and re-connect to limited peers?
4972017-04-27T19:36:30  <jonasschnelli> Yes. What sipa said
4982017-04-27T19:36:57  <jonasschnelli> I would expect the larger the chain grows the more pruned peers we will see
4992017-04-27T19:37:09  <jonasschnelli> (rought assumption)
5002017-04-27T19:37:11  <sipa> not that we should support pruning that much, but for bandwidth reasons it may be reasonable that someone wants to relay new blocks, but not historical ones
5012017-04-27T19:37:46  *** midnightmagic has quit IRC
5022017-04-27T19:38:11  <petertodd> sipa: I think we can make a good argument that requiring nodes to have something like 1GB of storage for historical blocks isn't a big deal, and makes the logic around all this stuff simpler
5032017-04-27T19:38:12  <jonasschnelli> signaling the amount of block you have is also not extremly effective because of the addr-man, seed/crawl delay
5042017-04-27T19:38:18  <jonasschnelli> *blocks
5052017-04-27T19:38:30  <sipa> petertodd: again, not talking about storage, but about bandwidth
5062017-04-27T19:38:52  <sipa> it's an open question - i'm not convinced it's needed or useful
5072017-04-27T19:39:02  <jonasschnelli> Yes. Agree with sipa. Main pain point in historical blocks is upstream bandwidth
5082017-04-27T19:39:07  <gmaxwell> sipa sure that would also work: but (1) nodes that only keep ten blocks are a hazard to the network, and (2) there is no real reason to keep that little, and (3) we don't have signaling room to send out every tiny variation.
5092017-04-27T19:39:10  <petertodd> sipa: how much more bandwidth do your status say serving ~100 or whatever blocks is vs. 10?
5102017-04-27T19:39:21  <petertodd> sipa: I mean, you can just turn off NODE_NETWORK_LIMIT entirely
5112017-04-27T19:39:26  <jonasschnelli> gmaxwell: They would keep more but only willing to serve the last 10
5122017-04-27T19:39:28  <gmaxwell> sipa: if you want to limit your bandwidth, limit it.
5132017-04-27T19:39:32  <sipa> gmaxwell: well we have 3 possibilities
5142017-04-27T19:39:45  <jonasschnelli> NODE_NETWORK_LIMITED would be a limit
5152017-04-27T19:39:51  <sipa> fair enough, we have other mechanisms for limiting bandwidth
5162017-04-27T19:39:51  <edcba> QoS on historical blocks :)
5172017-04-27T19:40:20  <sipa> petertodd: i need to look again... it may not be that much difference
5182017-04-27T19:40:30  <gmaxwell> sipa: and we have had reorgs longer than 10 in recent memory, what happens if all of your peers are like that?
5192017-04-27T19:40:57  <BlueMatt> gmaxwell: we have?!
5202017-04-27T19:41:17  <sipa> BlueMatt: bip50 was 30 deep, iirc
5212017-04-27T19:41:17  <BlueMatt> oh, you mean the csv false-signaling reorgs?
5222017-04-27T19:41:22  <BlueMatt> yea, ok
5232017-04-27T19:41:44  <sipa> ok, i retract my suggestion for 10 deep
5242017-04-27T19:41:46  <jonasschnelli> Would the two bit amount-of-blocks-available signaling be effective regarding the delay of address distribution?
5252017-04-27T19:41:52  <BlueMatt> always need 2 * MAX_HUMAN_FIX_TIME_FACTOR for everything :p
5262017-04-27T19:42:02  <sipa> but we do have 3 possibilities with 2 bits... perhaps we can have a 3rd limit
5272017-04-27T19:42:08  <jonasschnelli> People tend to prune to MB rather then blocks (which could be a design mistake)
5282017-04-27T19:42:17  <gmaxwell> jonasschnelli: Why do you think it has much to do with address distribution delay at all?
5292017-04-27T19:42:29  <gmaxwell> if you keep the last 288 you keep the last 288.. you're not going to flicker that on and off.
5302017-04-27T19:42:42  <gmaxwell> jonasschnelli: the design guarentees that you'll have 288 blocks.
5312017-04-27T19:42:48  <gmaxwell> (of the software)
5322017-04-27T19:42:53  <jonasschnelli> gmaxwell: Maybe I'm looking to much to our seeders,... but the crawling till you serve IPs can be very delayed.
5332017-04-27T19:43:02  <gmaxwell> so?
5342017-04-27T19:43:09  <jtimon> jonasschnelli: I think I agree on prunning by height being more useful
5352017-04-27T19:43:13  <gmaxwell> You'll signal you keep X if you're guarenteed to keep X.
5362017-04-27T19:43:26  <jtimon> or relative height rather
5372017-04-27T19:43:33  <sipa> s/height/depth/
5382017-04-27T19:43:36  <jonasschnelli> Okay. But prune=550 is a MB target. Does it guarantee and amount of blocks?
5392017-04-27T19:43:42  <jtimon> sipa: right, thanks
5402017-04-27T19:43:43  <jonasschnelli> *an
5412017-04-27T19:44:10  <gmaxwell> jonasschnelli: it guarentees we'll keep 288 blocks. The whole feature was designed to guarentee that for reorg reasons, but people thought offering a MB centric UI would be more useful to users.
5422017-04-27T19:44:21  <gmaxwell> I think in the future we'll change it to a limited set of options.
5432017-04-27T19:44:45  <gmaxwell> Maybe all of them named after words for big in different languages, like starbucks. :P
5442017-04-27T19:44:53  <jonasschnelli> Okay. Fair enough...
5452017-04-27T19:44:53  <achow101> gmaxwell: the MB option confuses people though since it includes the undo data. people see 550 and they assume it means 550 blocks since 1 MB blocks
5462017-04-27T19:44:53  <luke-jr> eh, 550 MB is only guaranteed 137 blocks with segwit
5472017-04-27T19:45:04  <luke-jr> oh, forgot undo data
5482017-04-27T19:45:11  <sipa> gmaxwell: "For me a venti depruned node, please"
5492017-04-27T19:45:20  <wumpus> lol @ coffee names
5502017-04-27T19:45:23  <gmaxwell> luke-jr: then that needs to get fixed.
5512017-04-27T19:45:24  <jonasschnelli> lol
5522017-04-27T19:45:38  <gmaxwell> sipa: with a double shot of xthin.
5532017-04-27T19:45:43  <jonasschnelli> pfff
5542017-04-27T19:46:10  <gmaxwell> luke-jr: easy fix.
5552017-04-27T19:46:18  <luke-jr> controversial fix
5562017-04-27T19:46:24  <sipa> gmaxwell: it'll break existing configs
5572017-04-27T19:46:41  <jonasschnelli> Okay. I can start writing a draft specs about the two bit (144/~1000) NODE_NETWORK_LIMITED.. will announce once I have something
5582017-04-27T19:46:42  <BlueMatt> sipa: I'm sorry, I dont speak starbucks
5592017-04-27T19:46:49  <gmaxwell> sipa: so?
5602017-04-27T19:47:04  <gmaxwell> jonasschnelli: seriously, like why did I bother commenting today?
5612017-04-27T19:47:18  <sipa> BlueMatt: venti is italian for 20. easy. that's obviously more than "grande" or "tall"
5622017-04-27T19:47:22  <gmaxwell> first peak is at 144, if _must_ keep more than that to be useful.
5632017-04-27T19:47:49  <BlueMatt> sipa: ehh, I'll stick with my *good* coffee, thanks
5642017-04-27T19:47:56  <BlueMatt> anyway, next topic?
5652017-04-27T19:48:08  <wumpus> #topic high priority for review
5662017-04-27T19:48:14  <praxeology> My 2 cents: the UI should stay in MB, but underlying the variables stored by the software should be in block count... for the prune threshold.
5672017-04-27T19:48:43  <wumpus> anything to add to project https://github.com/bitcoin/bitcoin/projects/8?
5682017-04-27T19:48:55  * BlueMatt suggests adding #10199 for morcos 
5692017-04-27T19:48:56  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
5702017-04-27T19:49:00  <BlueMatt> (who is out today)
5712017-04-27T19:49:17  <sipa> i'd like to get review on #10195 (which i think is ready)
5722017-04-27T19:49:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
5732017-04-27T19:49:20  * BlueMatt humbly requests rebase of #7729 which is on that list
5742017-04-27T19:49:21  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
5752017-04-27T19:49:26  <BlueMatt> sipa: pyou already have an entry....
5762017-04-27T19:49:30  <sipa> oh :(
5772017-04-27T19:49:50  <wumpus> added 10199
5782017-04-27T19:50:23  <cfields> It's not urgent, but #10285 is first in a long line towards libevent
5792017-04-27T19:50:24  <sipa> ok, swap #10148 for #10195 then; 10148 needs more tests
5802017-04-27T19:50:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
5812017-04-27T19:50:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
5822017-04-27T19:50:26  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
5832017-04-27T19:50:38  <luke-jr> suggested topic? planned obsolecense
5842017-04-27T19:50:41  <jtimon> random though: what about maintaining the mb option an adding an incompatible one (you can only set one) with depth ? then the mb can be just an estimation that translates to depth on init, but you don't break old configs, only the expected guarantees about limits
5852017-04-27T19:51:00  <BlueMatt> luke-jr: NACK
5862017-04-27T19:51:16  <luke-jr> BlueMatt: NACK topic or NACK it altogether? :/
5872017-04-27T19:51:24  <achow101> luke-jr: planned obsolecense is a bad name for it
5882017-04-27T19:51:25  <BlueMatt> second
5892017-04-27T19:52:09  <wumpus> added 10285, swapped #10148 for #10195
5902017-04-27T19:52:10  * luke-jr waits for topic change before going into discussion
5912017-04-27T19:52:10  * jtimon checks https://github.com/bitcoin/bitcoin/pull/8855 is on the priority list
5922017-04-27T19:52:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
5932017-04-27T19:52:13  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
5942017-04-27T19:52:28  <sipa> thanks
5952017-04-27T19:52:50  <wumpus> #topic bitcoind expiration
5962017-04-27T19:53:42  <jonasschnelli> 10282
5972017-04-27T19:53:44  <jonasschnelli> #10282
5982017-04-27T19:53:45  <gribble> https://github.com/bitcoin/bitcoin/issues/10282 | Expire bitcoind & bitcoin-qt 7-8 years after its last change by luke-jr · Pull Request #10282 · bitcoin/bitcoin · GitHub
5992017-04-27T19:53:50  <luke-jr> BlueMatt: reasoning for NACK?
6002017-04-27T19:54:11  <cfields> luke-jr: maybe explain reasoning for doing so first?
6012017-04-27T19:54:12  <luke-jr> re achow101's comment, I don't really think it matters what we call it
6022017-04-27T19:54:23  <luke-jr> cfields: 10282 has a full explanation
6032017-04-27T19:54:51  <petertodd> any timeframe short enough to really be useful will probably be short enough to raise political risks...
6042017-04-27T19:54:51  <luke-jr> 1) it's basically guaranteed to be unsafe by then; 2) hardforks become softforks with enough lead time
6052017-04-27T19:55:00  <jtimon> I think if it's optional and disabled by default it kind of defeats the point, but I certainly don't want that for myself or the users I recommend to use bitcoin core
6062017-04-27T19:55:19  <sipa> luke-jr: i don't see how this has anything to do with consensus changes
6072017-04-27T19:55:32  <petertodd> also, is there any precedent for this kind of expiration in other software?
6082017-04-27T19:55:40  <BlueMatt> luke-jr: 110% sends the wrong message. if i expected any reasonable person to see that and think "I need to think for myself about what consensus of the network is" I'd be happy with it, but realistically the only people reading that will think "oh, I have to switch to the latest thing from Bitcoin Core, for whatever Bitcoin Core is according to my local google server"
6092017-04-27T19:55:43  <luke-jr> jtimon: what is the use case for running node software over 7 years after its release, without maintenance?
6102017-04-27T19:55:53  <gmaxwell> petertodd: yes, but I'm not aware of any that can be overridden.
6112017-04-27T19:56:06  <sipa> luke-jr: i think insecurity of the software is perhaps a good reason, but not consensus
6122017-04-27T19:56:07  <petertodd> gmaxwell: got any examples?
6132017-04-27T19:56:13  <gmaxwell> petertodd: see also the thing with debian and xscreensaver.
6142017-04-27T19:56:32  <luke-jr> BlueMatt: that's a problem independent of this IMO
6152017-04-27T19:56:35  <petertodd> gmaxwell: ah, yeah, that crazy situation...
6162017-04-27T19:56:54  *** Don_John has joined #bitcoin-core-dev
6172017-04-27T19:57:02  <BlueMatt> luke-jr: how is that independant of the thing which creates it? but, indeed, security may be a reasonable reason, not sure its justified, though
6182017-04-27T19:57:08  *** jcliff42 has joined #bitcoin-core-dev
6192017-04-27T19:57:26  <BlueMatt> am i really not allowed to not upgrade the bitcoind I've got running behind by bitcoind/xyz firewall?
6202017-04-27T19:57:33  <luke-jr> BlueMatt: people will mostly all update before this triggers; probably using the insecure method you describre
6212017-04-27T19:57:44  <gmaxwell> I agree with petertodd's point about short enough to be useful is short enough to be problematic. :( But there are other not really useful features...
6222017-04-27T19:57:50  <BlueMatt> oops, bitcoind crashed in production
6232017-04-27T19:58:23  <luke-jr> BlueMatt: note this has an explicit override allowed
6242017-04-27T19:58:26  <petertodd> gmaxwell: and there's a larger point too: chances are the surrounding software on your machine is also not getting updated anyway, so you've got other big problems
6252017-04-27T19:58:32  <luke-jr> if you really don't want to upgrade, just add to your config file
6262017-04-27T19:58:35  <BlueMatt> luke-jr: yes, and you can do that /after/ your bitcoind has crashed
6272017-04-27T19:58:36  <jtimon> luke-jr: let's say my friend remembers what I told him about being up to date 6 years and 11 months after I helped him install bitcoin core
6282017-04-27T19:58:38  <BlueMatt> which is kinda shit
6292017-04-27T19:58:48  <gmaxwell> it would be nice to be able to say there are no nodes running older than X without the user deciding to keep them running.
6302017-04-27T19:58:58  <luke-jr> BlueMatt: you could do it before as well, but IMO after 7 years it's okay to force the user to do something
6312017-04-27T19:59:04  <gmaxwell> BlueMatt: yes, but the crash was an RCE and all your funds are now gone. :)
6322017-04-27T19:59:27  <wumpus> if you run nodes in production you'll have some system to monitor it
6332017-04-27T19:59:30  <BlueMatt> gmaxwell: not if its the bitcoind that everything talks to on your network and it just sits behind sufficient layers of regularly-updated bitcoind firewalls
6342017-04-27T19:59:39  <wumpus> and summon an operator on crashes
6352017-04-27T19:59:53  <BlueMatt> wumpus: lol, i meannnnn, maybe
6362017-04-27T20:00:08  <sipa> wumpus: hahaha, yes, with a server farm at the end of the rainbow
6372017-04-27T20:00:19  <luke-jr> BlueMatt: and what if it doesn't crash, but someone exploits your failure to enforce a softfork?
6382017-04-27T20:00:21  <jtimon> or shouldn't I recommend bitcoin core for a wallet?
6392017-04-27T20:00:25  <petertodd> wumpus: you should talk to some banking IT guys about how hard it is to get approval to update things :)
6402017-04-27T20:00:33  <luke-jr> jtimon: I don't understand your argument.
6412017-04-27T20:00:45  <wumpus> petertodd: I'm not saying anything about updating
6422017-04-27T20:00:54  <instagibbs> jtimon, you can over-ride the setting, I believe
6432017-04-27T20:01:08  <petertodd> wumpus: literally touching a config option is an update by those standards
6442017-04-27T20:01:09  <jtimon> instagibbs: oh, I missed that
6452017-04-27T20:01:18  <wumpus> only about crashes, if some software is important to your business and it crashes, you'll notice.
6462017-04-27T20:01:41  <wumpus> anyhow
6472017-04-27T20:01:43  <wumpus> #endmeeting
6482017-04-27T20:01:43  <lightningbot> Meeting ended Thu Apr 27 20:01:43 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6492017-04-27T20:01:43  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.html
6502017-04-27T20:01:43  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.txt
6512017-04-27T20:01:43  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.log.html
6522017-04-27T20:01:59  <jtimon> luke-jr: sorry, I missed what instagibbs just said, should read the proposal I guess
6532017-04-27T20:03:16  <jnewbery> "after 7 years it's okay to force the user to do something" - not sure I understand this. Who's forcing the user to do something?
6542017-04-27T20:03:24  <wumpus> heck my nodes do nothing imporant and even I have a one-liner script that sends me a mail on crash or unexpected exit
6552017-04-27T20:03:44  <luke-jr> jnewbery: 7 years after it's released, bitcoind/-qt would exit and refuse to start until the user chose to either upgrade it, or override the expiration
6562017-04-27T20:03:48  <jtimon> jnewbery: also, this is free software, you can't force users
6572017-04-27T20:03:59  <jnewbery> jtimon - right that's my point
6582017-04-27T20:04:07  <sipa> my node does something important, and i have a 0-line script that sends me an mail on crash (= people mail me that my website stopped updating)
6592017-04-27T20:04:10  * sipa hides
6602017-04-27T20:04:18  <luke-jr> jtimon: you can force users to *do something* :P
6612017-04-27T20:04:20  <wumpus> sipa: well that works too
6622017-04-27T20:04:25  <luke-jr> sipa: haha
6632017-04-27T20:05:01  * BlueMatt has a feeling sipa's approach is more common
6642017-04-27T20:05:14  <jtimon> luke-jr: yes, but then I will disable the anti-feature for my friend the first time I help him install and tell him about updates
6652017-04-27T20:06:03  <luke-jr> jtimon: why?
6662017-04-27T20:06:12  <luke-jr> the "anti-feature" has no harm in any reasonable scenario
6672017-04-27T20:06:17  * BlueMatt would do the same
6682017-04-27T20:06:19  <jnewbery> I'd be happy for there to be a warning if running an old version, but I really don't like it automatically disabling a node after 7 years, particularly if the reason is "this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out."
6692017-04-27T20:06:20  <wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running
6702017-04-27T20:06:25  <wumpus> this would give less guarantees, but still
6712017-04-27T20:06:28  <jnewbery> In that case, we might as well have auto-update
6722017-04-27T20:06:49  * instagibbs imagining someone running a node non-stop for 7 years
6732017-04-27T20:06:50  <wumpus> jnewbery: wow that's very black and white
6742017-04-27T20:06:54  <luke-jr> jnewbery: not the same thing at all; the user can always opt to bypass the expiration
6752017-04-27T20:06:55  <petertodd> wumpus: god help us if we ever release a version that gets the date wrong...
6762017-04-27T20:07:00  <BlueMatt> wumpus: yea, something much more watered down may be reasonable, including huge fat warnings if the software is like 2 years old
6772017-04-27T20:07:21  <BlueMatt> wumpus: the perception will be black and white as well
6782017-04-27T20:07:23  <wumpus> petertodd: well it could mention the flag to override I guess
6792017-04-27T20:07:44  <jtimon> luke-jr: again, sorry, should read the proposal but "programmed obsolecense" definitely sounds like an anti-feature, after reading the proposal, if I think is a feature, will maybe just suggest to rename it
6802017-04-27T20:07:51  <BlueMatt> refusing to start with an error message mentioning the flag to override would be reasonable, but also largely useless
6812017-04-27T20:07:55  <wumpus> anyhow, apparently the consensus is to not do it, that's fine
6822017-04-27T20:07:59  <BlueMatt> though maybe not just to remind users
6832017-04-27T20:08:00  <petertodd> wumpus: you still might have quite a bit of chaos of nodes being shut down all at once
6842017-04-27T20:08:21  <wumpus> petertodd: that's why I suggested "<wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running"
6852017-04-27T20:08:41  <wumpus> in any case, seems there's too much drawbacks to this
6862017-04-27T20:09:01  <sipa> wumpus: so all you need to do after 7 years is find a remote crashing bug, and use it on every remaining node (and finding a remote crash bug for 7 yo software doesn't sound hard...)
6872017-04-27T20:09:05  <sipa> :)
6882017-04-27T20:09:06  <petertodd> wumpus: I'd think nodes get restarted reasonably often, and often by automatic means
6892017-04-27T20:09:15  <BlueMatt> wumpus: yes, your proposal i could get behind, mostly because it would inform users that they can add a conf option, making the "refuse to start" thing kinda moot, while still being really insistent on telling users to upgrade, which is fine
6902017-04-27T20:09:44  <wumpus> BlueMatt: I think that's acceptable after 7 years
6912017-04-27T20:10:01  <sipa> i don't think that there is much difference between refusing to start vs stopping to work
6922017-04-27T20:10:05  <wumpus> come on, 7 years is an eternity on the internet, we shouldn't bee too childish about this
6932017-04-27T20:10:14  <sipa> especially at that timeframe
6942017-04-27T20:10:26  <wumpus> sipa: right
6952017-04-27T20:10:38  <BlueMatt> sipa: I tend to disagree
6962017-04-27T20:10:41  <jnewbery> wumpus: not helpful. I think people are raising legitimate concerns
6972017-04-27T20:10:55  <wumpus> a startup check is simpler to implement and less error prone though
6982017-04-27T20:11:03  <BlueMatt> (re difference between startup and forced shutdown)
6992017-04-27T20:11:26  <wumpus> jnewbery: really, a legitimate concern, that people are running 7 year old software in production?
7002017-04-27T20:11:33  <BlueMatt> wumpus: yes
7012017-04-27T20:11:41  *** Giszmo has quit IRC
7022017-04-27T20:11:52  <jnewbery> a legitimate concern that devs don't have the right to "force" users to do something
7032017-04-27T20:11:53  <wumpus> sometimes it's just like people are just making up unlikely \things just to argue
7042017-04-27T20:11:55  <instagibbs> and can't be bothered to click through, or set a flag?
7052017-04-27T20:11:59  <BlueMatt> wumpus: 7 years is, in fact, *not* an eternity on the internet
7062017-04-27T20:12:07  <instagibbs> I understand it would need to be done right, but that's a little nuts.
7072017-04-27T20:12:17  <wumpus> it wouldn't be forcing to do anything, as there is an override
7082017-04-27T20:12:17  <wumpus> sigh
7092017-04-27T20:12:20  <BlueMatt> instagibbs: click through fine, shutdown *while running*?
7102017-04-27T20:12:31  <luke-jr> BlueMatt: it's only slightly shorter than Bitcoin's current lifetime
7112017-04-27T20:12:32  <wumpus> BlueMatt: okay, what ever
7122017-04-27T20:12:37  <instagibbs> BlueMatt, sure, that's another dot on the matrix, I agree on that one
7132017-04-27T20:12:56  <jtimon> it should still be relatively easy for users to get out of the stuck situation in case they can't upgrade in the same system or something, like maybe deleting a filed named ~/.bitcoin/DELETE_ME_ONLY_IF_YOU_CANT_UPGRADE_IN_THIS_SYSTEM or something
7142017-04-27T20:13:13  <luke-jr> jtimon: yes, it's already easy to override
7152017-04-27T20:13:22  <BlueMatt> jtimon: conf flag seems neater, no one checks their bitcoin datadir
7162017-04-27T20:13:23  <luke-jr> we can make it easier perhaps by taking a YYYY instead of POSIX timestamp
7172017-04-27T20:13:31  <petertodd> gmaxwell: btw, re: your comment in the meeting, no-one's funding me to do any work on Bitcoin Core these days
7182017-04-27T20:13:39  <jtimon> luke-jr: BlueMatt: great
7192017-04-27T20:14:19  <luke-jr> jnewbery: nobody is forcing users to run Core at all.
7202017-04-27T20:15:09  <BlueMatt> wumpus: on a less controversial note, #7729 is ripe for rebase-and-review, no? or are we now so bogged down on major features that need review you're waiting? :/
7212017-04-27T20:15:11  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
7222017-04-27T20:15:30  <jnewbery> luke-jr indeed, and I don't think core devs should attempt to force users to upgrade
7232017-04-27T20:16:00  <luke-jr> jnewbery: we're not. by running Core, they would be opting in to being forced to either upgrade OR tell the software they don't want to
7242017-04-27T20:16:07  <wumpus> BlueMatt: yes, I tried once, but so much moved around since that it's pretty much "re-do" instead of rebase
7252017-04-27T20:16:15  <BlueMatt> grr, sorry about that :/
7262017-04-27T20:16:16  <luke-jr> "forced" is really the wrong word here
7272017-04-27T20:16:47  <BlueMatt> luke-jr: thats ridiculous, you're living in a world where people have the time go read a ton of bitcoin core docs/code before running it, and do...neither of which are true
7282017-04-27T20:16:49  <wumpus> I don't think we're going to agree on this luke-jr
7292017-04-27T20:16:49  <jtimon> yeah, as BlueMatt said, being annoying about upgrading is fine
7302017-04-27T20:17:25  * BlueMatt goes back to trying to make a dent in the review pile
7312017-04-27T20:17:28  <luke-jr> BlueMatt: not before, simply read a short notice when it tells them to make a decision
7322017-04-27T20:17:33  <wumpus> when it detoriorates to arguing about what words to use it's better to just stop
7332017-04-27T20:17:38  *** tw2006 has quit IRC
7342017-04-27T20:18:07  <luke-jr> jtimon: well, this proposal comes down to being annoying at worst, and BlueMatt doesn't like it either
7352017-04-27T20:18:30  <BlueMatt> luke-jr: which proposal now? refusing to startup or crashing while running?
7362017-04-27T20:18:39  <wumpus> BlueMatt: IIRC I don't think any of the wallet changes that complicate rebasing #7729 are your fault, just a lot happened there
7372017-04-27T20:18:39  <BlueMatt> but, yea, I'm gonna go back to review, this has devolved
7382017-04-27T20:18:41  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
7392017-04-27T20:18:52  <luke-jr> BlueMatt: yes, being able to override it means it's merely annoying
7402017-04-27T20:19:04  <BlueMatt> wumpus: fair, but its on the rest of us to get it reviewed in a timely manner :p
7412017-04-27T20:19:45  <jtimon> luke-jr: as said, without reading it, my only concern that it wasn't relatively easy or undocumented for a user to overrule the annoyance
7422017-04-27T20:19:46  <michagogo> Last week we were talking about WSL and Gitian
7432017-04-27T20:19:49  <wumpus> I would have liked quicker feedback on the API. But I think there's agreement on that now so implementation should be fairy simple
7442017-04-27T20:20:03  <michagogo> I haven't tried with VBox yet, but I can confirm that LXC doesn't work
7452017-04-27T20:20:13  <jtimon> what is the link again?
7462017-04-27T20:20:16  <wumpus> what doesn't work?
7472017-04-27T20:20:27  <michagogo> make-base-vm fails, as does lxc-create
7482017-04-27T20:20:28  <wumpus> building master using gitian?
7492017-04-27T20:20:36  <michagogo> No, running LXC in WSL
7502017-04-27T20:20:43  <luke-jr> no surprise there
7512017-04-27T20:20:45  <wumpus> ohh. Yes we know that, that's an upstream problem
7522017-04-27T20:20:47  <michagogo> Right
7532017-04-27T20:20:51  <wumpus> bother microsoft :)
7542017-04-27T20:20:55  <michagogo> I wasn't expecting it to, at all
7552017-04-27T20:21:08  <michagogo> But someone last week thought maybe it would, so I tried it
7562017-04-27T20:21:12  <wumpus> even building depends in WSL currently doesn't work, due to some vague change in their ubuntu
7572017-04-27T20:21:34  <BlueMatt> microsoft: taking "compatibility" to a new level
7582017-04-27T20:21:38  <wumpus> https://github.com/bitcoin/bitcoin/issues/10269
7592017-04-27T20:21:54  <wumpus> BlueMatt: yeah embrace and extinguish, round N
7602017-04-27T20:22:51  <michagogo> Really? I didn't know that.
7612017-04-27T20:23:07  <michagogo> I remember when WSL was pretty new I tried it and it worked perfectly
7622017-04-27T20:23:26  <wumpus> it worked at some point
7632017-04-27T20:24:24  <BlueMatt> it worked when they made the press release for all the people to try it, after that they only cared that it appeared to work so that windows folks build software that doesnt really work on linux, but claims to :p
7642017-04-27T20:24:39  <michagogo> It's times like this that I wish I had Windows 10 on my computer
7652017-04-27T20:24:52  <BlueMatt> ewwwwwww
7662017-04-27T20:25:01  <BlueMatt> thats worse than starbucks coffee!
7672017-04-27T20:25:05  <michagogo> I mean, I'm on Win7 right now
7682017-04-27T20:25:14  <BlueMatt> ouch
7692017-04-27T20:26:11  <michagogo> Haven't upgraded for two reasons. First, I don't use my computer at home so much lately (= the last couple years) and don't have so much time to spend with it to try and fix it if it gets messed up, smooth out the kinks, etc.
7702017-04-27T20:26:34  <michagogo> Second, at work I have 7, and I'm concerned that one of two things will happen
7712017-04-27T20:26:35  <edcba> 7yrs software in prod rotfl: in 2016 i was supporting xp at work...
7722017-04-27T20:27:22  *** Giszmo has joined #bitcoin-core-dev
7732017-04-27T20:27:25  <jtimon> is there an issue in win7's github for the bug on their side? let's just go concept ack there
7742017-04-27T20:27:46  <michagogo> Either it'll be too different and I won't adjust to it because I'll still be mostly using 7, and then my time with it will be annoying, or, it'll be amazing and I'll get used to having stuff from it, and then be sad when I go back to 7 at work
7752017-04-27T20:27:51  <michagogo> "win7's github"?
7762017-04-27T20:28:00  <jtimon> sorry, bad joke
7772017-04-27T20:28:01  <BlueMatt> michagogo: i think it was a joke :p
7782017-04-27T20:28:09  <BlueMatt> jtimon: i found it comical
7792017-04-27T20:28:25  <michagogo> Wait, which bug?
7802017-04-27T20:28:33  <michagogo> I first thought you meant Windows 10
7812017-04-27T20:28:42  <jtimon> BlueMatt: oh, thanks, I read your "I think" as a confirmation that it was bad
7822017-04-27T20:28:54  <michagogo> Because if Core builds on Ubuntu but not in WSL, that *is* a bug in WSL
7832017-04-27T20:29:42  <wumpus> after all we did a gitian build very shortly ago, which uses the same version of ubuntu (14.04)
7842017-04-27T20:30:03  <wumpus> maybe it's some magic with line endings or such
7852017-04-27T20:30:23  <michagogo> I think as of Creator Update, a couple weeks ago, new WSL installs are Xenial
7862017-04-27T20:30:39  <wumpus> ugh
7872017-04-27T20:30:45  <michagogo> Ugh? Why?
7882017-04-27T20:30:57  <wumpus> the windows toolchain on xenial is kind of broken
7892017-04-27T20:31:10  <BlueMatt> no wonder wsl is broken
7902017-04-27T20:31:19  <wumpus> yes, that explains it then
7912017-04-27T20:31:27  <michagogo> Really? Have bugs been filed?
7922017-04-27T20:31:30  <wumpus> they can be happy they don't get executables
7932017-04-27T20:31:49  <wumpus> I don't think it was ever narrowed down
7942017-04-27T20:32:19  <michagogo> Is there anything different besides gcc being replaced by mingw-w64?
7952017-04-27T20:32:42  <wumpus> see "Ubuntu 16.04 Windows cross-build" on https://github.com/bitcoin/bitcoin/projects for a collection of issues
7962017-04-27T20:33:01  <wumpus> it's a newer version of mingw-w64 that doesn't work so well
7972017-04-27T20:33:10  <michagogo> I was thinking of upgrading my Ubuntu VM (that I use mostly for gitian building) from Trusty to Xenial - should I not do that?
7982017-04-27T20:33:19  <wumpus> fstack-protector produces broken executables, and there was some c++11 threading snafu
7992017-04-27T20:33:32  <wumpus> could be that these are solved by now, I have no idea, haven't tried it for months
8002017-04-27T20:34:12  <wumpus> you can't use xenial for gitian building without everyone else changing too
8012017-04-27T20:34:27  <michagogo> I meant for the host
8022017-04-27T20:34:33  <wumpus> oh the host can be anything
8032017-04-27T20:34:35  <michagogo> Not changing the target container
8042017-04-27T20:34:41  <wumpus> I use debian for the host
8052017-04-27T20:34:49  <jtimon> wumpus: btw, it would be nice to put BlueMatt 's libconsensus-related PRs in https://github.com/bitcoin/bitcoin/projects/6 (and always tag anything there with "consensus")
8062017-04-27T20:34:56  <michagogo> I wonder if I should delete my precise sandbox VM
8072017-04-27T20:35:22  <wumpus> michagogo: yes, why not
8082017-04-27T20:35:24  <wumpus> jtimon: ok
8092017-04-27T20:36:19  *** jcliff42 has quit IRC
8102017-04-27T20:36:29  <jtimon> wumpus: thanks, I mean, not a priority, just would be somewhat helpful
8112017-04-27T20:41:17  <jtimon> btw BlueMatt thanks for https://github.com/bitcoin/bitcoin/pull/771 I shouldn't look at it much and look at the new things instead but like these things if I find the time
8122017-04-27T20:41:52  <BlueMatt> jtimon: lol, that was so long ago even I dont remember how it was designed
8132017-04-27T20:42:23  <jtimon> but you said it was based on it, so I was hoping some ideas remained
8142017-04-27T20:43:09  <jtimon> that's what makes it more interesting IMO, it could be the same general idea with very different code
8152017-04-27T20:44:16  <jtimon> or more or less the same code, which I would find more amusing
8162017-04-27T20:45:15  *** tommyhot has joined #bitcoin-core-dev
8172017-04-27T20:45:54  *** JackH has quit IRC
8182017-04-27T20:55:59  *** jcliff42 has joined #bitcoin-core-dev
8192017-04-27T21:01:11  <sipa> jtimon: i think the extent of the similarity is "encapsulate all the state related to blockchain censensus"
8202017-04-27T21:04:21  *** jcliff42 has quit IRC
8212017-04-27T21:06:30  *** Giszmo has quit IRC
8222017-04-27T21:09:01  *** jcliff42 has joined #bitcoin-core-dev
8232017-04-27T21:09:40  *** CubicEarth has joined #bitcoin-core-dev
8242017-04-27T21:09:50  *** jcliff42 has joined #bitcoin-core-dev
8252017-04-27T21:12:10  *** Dyaheon has quit IRC
8262017-04-27T21:13:27  *** Dyaheon has joined #bitcoin-core-dev
8272017-04-27T21:14:54  *** comboy has joined #bitcoin-core-dev
8282017-04-27T21:17:01  <achow101> wumpus: michagogo windows cross compile on ubuntu xenial is still broken.
8292017-04-27T21:17:16  <achow101> on wsl, there's a different problem with depends failing
8302017-04-27T21:18:52  *** midnightmagic has joined #bitcoin-core-dev
8312017-04-27T21:21:24  *** Giszmo has joined #bitcoin-core-dev
8322017-04-27T21:24:09  <wumpus> achow101: yes, seems to be different issues - confusing
8332017-04-27T21:24:28  <wumpus> building on xenial, for xenial works fine in any case
8342017-04-27T21:24:45  <wumpus> it only breaks with windows in the picture (either as cross compile or WSL)
8352017-04-27T21:30:28  *** praxeology has quit IRC
8362017-04-27T21:33:55  <michagogo> Hm, if I have a VM with a snapshot and a bunch of changes since the snapshot, and I want to create a snapshot of the current state and delete the existing one
8372017-04-27T21:34:19  <michagogo> Does it matter at all whether I delete the current one before or after taking the new one, in terms of final size?
8382017-04-27T21:42:57  *** Giszmo has quit IRC
8392017-04-27T21:44:26  *** marcoagner has joined #bitcoin-core-dev
8402017-04-27T21:44:54  *** Cheeseo has joined #bitcoin-core-dev
8412017-04-27T21:56:21  *** jcliff42 has quit IRC
8422017-04-27T21:57:58  *** Giszmo has joined #bitcoin-core-dev
8432017-04-27T22:02:55  *** tw2006 has joined #bitcoin-core-dev
8442017-04-27T22:11:39  *** moli_ has joined #bitcoin-core-dev
8452017-04-27T22:13:34  *** jamoes has quit IRC
8462017-04-27T22:17:08  *** giannis has joined #bitcoin-core-dev
8472017-04-27T22:17:11  *** eragmus has quit IRC
8482017-04-27T22:17:31  *** giannis is now known as Guest50266
8492017-04-27T22:18:08  *** pindarhk has quit IRC
8502017-04-27T22:18:14  *** jamoes has joined #bitcoin-core-dev
8512017-04-27T22:18:28  *** trotski2000 has quit IRC
8522017-04-27T22:20:37  *** Guest50266 has quit IRC
8532017-04-27T22:22:13  *** justanotheruser has quit IRC
8542017-04-27T22:22:48  *** justanotheruser has joined #bitcoin-core-dev
8552017-04-27T22:26:07  *** eragmus has joined #bitcoin-core-dev
8562017-04-27T22:26:57  *** trotski2000 has joined #bitcoin-core-dev
8572017-04-27T22:27:53  *** pindarhk has joined #bitcoin-core-dev
8582017-04-27T22:30:31  *** jcliff42 has joined #bitcoin-core-dev
8592017-04-27T22:30:40  *** tripleslash has quit IRC
8602017-04-27T22:31:32  *** vicenteH has quit IRC
8612017-04-27T22:37:58  *** tripleslash has joined #bitcoin-core-dev
8622017-04-27T22:46:49  *** [\\\] has joined #bitcoin-core-dev
8632017-04-27T22:46:56  *** tripleslash has quit IRC
8642017-04-27T22:49:11  <bitcoin-git> [bitcoin] practicalswift closed pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
8652017-04-27T22:49:39  *** [\\\] is now known as tripleslash
8662017-04-27T22:51:40  <bitcoin-git> [bitcoin] practicalswift reopened pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
8672017-04-27T22:59:33  *** laurentmt has joined #bitcoin-core-dev
8682017-04-27T23:00:29  *** Giszmo has quit IRC
8692017-04-27T23:08:17  *** laurentmt has quit IRC
8702017-04-27T23:09:27  *** gm2051 has quit IRC
8712017-04-27T23:20:08  *** tripleslash has quit IRC
8722017-04-27T23:23:39  *** jcliff42 has quit IRC
8732017-04-27T23:24:05  *** marcoagner has quit IRC
8742017-04-27T23:32:48  *** tripleslash has joined #bitcoin-core-dev
8752017-04-27T23:33:27  *** jcliff42 has joined #bitcoin-core-dev
8762017-04-27T23:37:14  *** jamoes has quit IRC
8772017-04-27T23:37:16  *** marcoagner has joined #bitcoin-core-dev
8782017-04-27T23:50:38  *** justanotheruser has quit IRC
8792017-04-27T23:51:08  *** justanotheruser has joined #bitcoin-core-dev
8802017-04-27T23:58:58  *** abpa has quit IRC