12017-07-27T00:01:37  *** chjj has quit IRC
  22017-07-27T00:10:43  *** jamesob_ has joined #bitcoin-core-dev
  32017-07-27T00:12:28  *** jamesob__ has quit IRC
  42017-07-27T00:15:18  *** chjj has joined #bitcoin-core-dev
  52017-07-27T00:46:17  *** Chris_Stewart_5 has quit IRC
  62017-07-27T00:47:40  *** Ylbam has quit IRC
  72017-07-27T00:48:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  82017-07-27T01:02:47  *** chjj has quit IRC
  92017-07-27T01:03:24  *** Murch has quit IRC
 102017-07-27T01:10:32  *** jamesob has quit IRC
 112017-07-27T01:15:39  *** chjj has joined #bitcoin-core-dev
 122017-07-27T01:23:02  *** dabura667 has joined #bitcoin-core-dev
 132017-07-27T01:26:35  *** Deacyde has joined #bitcoin-core-dev
 142017-07-27T01:32:43  *** promag has quit IRC
 152017-07-27T01:41:05  *** dabura667 has quit IRC
 162017-07-27T01:41:27  *** dabura667 has joined #bitcoin-core-dev
 172017-07-27T01:56:55  *** Squidicuz has joined #bitcoin-core-dev
 182017-07-27T02:18:22  *** murchandamus has quit IRC
 192017-07-27T02:19:02  *** kewde[m] has quit IRC
 202017-07-27T02:23:27  *** Chris_Stewart_5 has quit IRC
 212017-07-27T02:25:27  *** str4d has quit IRC
 222017-07-27T02:30:45  *** murchandamus has joined #bitcoin-core-dev
 232017-07-27T02:31:42  *** kewde[m] has joined #bitcoin-core-dev
 242017-07-27T02:40:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 252017-07-27T02:58:29  *** goatpig has quit IRC
 262017-07-27T03:00:51  *** Chris_Stewart_5 has quit IRC
 272017-07-27T03:03:08  *** KevinPan has joined #bitcoin-core-dev
 282017-07-27T03:24:55  *** PRab has joined #bitcoin-core-dev
 292017-07-27T03:27:31  *** Eagle[TM] has joined #bitcoin-core-dev
 302017-07-27T03:28:48  *** EagleTM has quit IRC
 312017-07-27T03:36:25  *** miknotauro has joined #bitcoin-core-dev
 322017-07-27T03:54:21  *** jeep-ss has quit IRC
 332017-07-27T03:55:07  *** KevinPan has quit IRC
 342017-07-27T03:57:26  *** CubicEarth has joined #bitcoin-core-dev
 352017-07-27T04:26:48  *** chjj has quit IRC
 362017-07-27T04:36:42  *** jb55 has joined #bitcoin-core-dev
 372017-07-27T05:11:23  *** CubicEarth has quit IRC
 382017-07-27T05:22:52  *** jb55 has quit IRC
 392017-07-27T06:25:28  <gmaxwell> ::sigh:: https://www.reddit.com/r/Bitcoin/comments/6pu13q/whats_up_with_bitcoin_core/  so github seems to be distributing tar files for our tags that have nothing to do with our distribution, and it sounds like netbsd's stuff was using them and is not happy that the checksums change (presumably because file order or compressor changed)
 402017-07-27T06:33:30  <sipa> they've complained about that before
 412017-07-27T06:33:34  <sipa> there was an issue about that years ago
 422017-07-27T06:34:13  <jonasschnelli> Can we disable tar download via github? I guess no...
 432017-07-27T06:36:27  <sipa> #2476
 442017-07-27T06:36:30  <gribble> https://github.com/bitcoin/bitcoin/issues/2476 | no separate source code tarball download available · Issue #2476 · bitcoin/bitcoin · GitHub
 452017-07-27T06:39:34  *** Ylbam has joined #bitcoin-core-dev
 462017-07-27T06:39:34  <wumpus> we've been creating stable tarballs for years now, for distributions and such, what's wrong with them?
 472017-07-27T06:40:25  <wumpus> more than two years, seeing that comment
 482017-07-27T06:43:03  <gmaxwell> yea, just read. For some reason it seems that after nagging the crap out of us, they didn't switch to using the tarballs they asked us to provide.
 492017-07-27T06:43:50  <sipa> almost 4 years ago
 502017-07-27T06:44:45  <wumpus> well if there's something wrong with the tarballs from their pov we'd like to hear, but wtf post it to reddit
 512017-07-27T06:45:32  <gmaxwell> well the person posting is probably an enduser, I guess
 522017-07-27T06:51:59  *** chjj has joined #bitcoin-core-dev
 532017-07-27T07:21:14  <luke-jr> gmaxwell: it's because git decided to change git-archive output in some recentish version
 542017-07-27T07:21:30  <luke-jr> they made the substituted hash abbreviation longer
 552017-07-27T07:21:53  <luke-jr> wumpus: the stable tarballs are missing a bunch of stuff still :/
 562017-07-27T07:22:15  <sipa> luke-jr: like?
 572017-07-27T07:22:39  <gmaxwell> how could they be missing stuff ... they're just make dists
 582017-07-27T07:23:06  <luke-jr> sipa: https://github.com/bitcoin/bitcoin/issues/6753
 592017-07-27T07:23:19  <luke-jr> gmaxwell: `make dist` is missing the files
 602017-07-27T07:23:53  <gmaxwell> Only in from-git/: .gitattributes
 612017-07-27T07:23:54  <gmaxwell> Only in from-git/: .gitignore
 622017-07-27T07:23:58  <gmaxwell> don't belong in the distribution
 632017-07-27T07:24:08  <sipa> how does git checkdist succeed if things are missing?
 642017-07-27T07:24:13  <sipa> or distcheck
 652017-07-27T07:24:21  <gmaxwell> but the readmes and stuff are not good.
 662017-07-27T07:24:33  <sipa> ah, agree
 672017-07-27T07:25:21  <gmaxwell> should be trivial to add DISTFILES to the autotools stuff...
 682017-07-27T07:26:05  <luke-jr> IIRC there's a bunch of contrib now missing
 692017-07-27T07:26:08  <luke-jr> like init scripts and such
 702017-07-27T07:26:18  <luke-jr> haven't done a full check recently
 712017-07-27T07:26:55  <gmaxwell> why didn't you PR a fix
 722017-07-27T07:28:12  *** coredump_ has quit IRC
 732017-07-27T07:33:49  *** Dyaheon has quit IRC
 742017-07-27T07:34:38  <luke-jr> I don't know a good solution
 752017-07-27T07:36:03  *** Dyaheon has joined #bitcoin-core-dev
 762017-07-27T07:37:18  *** riemann has joined #bitcoin-core-dev
 772017-07-27T07:39:28  *** Eagle[TM] has quit IRC
 782017-07-27T07:39:38  <gmaxwell> luke-jr: you list the files in EXTRA_DIST in makefile.am
 792017-07-27T07:39:56  <gmaxwell> (though don't add the git specific stuff)
 802017-07-27T07:41:46  <luke-jr> it's just going to get outdated again :/
 812017-07-27T07:42:00  <gmaxwell> luke-jr: thats what review is for.
 822017-07-27T07:42:05  <luke-jr> isn't there some way to get git to build the list?
 832017-07-27T07:42:25  <gmaxwell> among other things, we don't want every file in git to end up in the dist.
 842017-07-27T07:43:19  <luke-jr> the .git* files maybe not, but everything else we do
 852017-07-27T07:53:39  <gmaxwell> luke-jr: in some other projects I've worked on, there were some machine generated source files that weren't checked in but were just generated and included as extra_dist, and some of the build scripts for those didn't get extra_disted.
 862017-07-27T07:55:16  <bitcoin-git> [bitcoin] vadimVoloshanov opened pull request #10940: Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/10940
 872017-07-27T07:55:53  <bitcoin-git> [bitcoin] fanquake closed pull request #10940: Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/10940
 882017-07-27T07:56:13  <luke-jr> gmaxwell: IMO the latter would be a bug.. source should be buildable even if modified
 892017-07-27T07:56:30  <luke-jr> looking at an updated list, the big things are subtrees..
 902017-07-27T07:57:00  <gmaxwell> well subtrees should be handled in their sub makefiles.
 912017-07-27T07:57:06  <luke-jr> https://0bin.net/paste/-R85vsle0Z7ygcL8#Hb9C8u3Y95x1d8iXMm3mC8oPrkZyrKO4tYoGT6UWZsC
 922017-07-27T07:58:42  <gmaxwell> luke-jr: does our dist tarball even build?!
 932017-07-27T08:06:12  <cfields> travis builds from tarball
 942017-07-27T08:06:23  <cfields> (or something close to it)
 952017-07-27T08:07:05  <luke-jr> talking with cfields, I'm thinking list the files individually, and add a script for Travis to complain if we add a new file that isn't either included or explicitly excluded from dist
 962017-07-27T08:08:06  <cfields> that seems like more work to me, i'd rather just add "check for excluded files" as a step in the release process
 972017-07-27T08:08:15  *** Cory has quit IRC
 982017-07-27T08:08:32  <luke-jr> cfields: I'll do it
 992017-07-27T08:09:58  *** J-wolf has joined #bitcoin-core-dev
1002017-07-27T08:12:34  <gmaxwell> cfields: human steps get missed. (see also the last N RCs where versions didn't get bumped. :) )
1012017-07-27T08:13:14  <cfields> heh
1022017-07-27T08:15:37  *** riemann has quit IRC
1032017-07-27T08:27:45  *** miknotauro has quit IRC
1042017-07-27T08:37:37  <wumpus> luke-jr: which files are missing that would be required for a distro?
1052017-07-27T08:38:06  <wumpus> and yes, the dist tarball builds
1062017-07-27T08:38:26  <wumpus> it works fine, there have been no complaints about it at all, except from luke-jr apparently
1072017-07-27T08:39:43  <wumpus> stuff not included is not part of 'make install', so generally not relevant to distros
1082017-07-27T08:39:48  <wumpus> (such as developer tools)
1092017-07-27T08:39:56  *** timothy has joined #bitcoin-core-dev
1102017-07-27T08:40:30  *** dgenr8 has quit IRC
1112017-07-27T08:42:39  <gmaxwell> well there are files that are missing which should be included, including internal documentation, and contrib stuff like linearize.  (docs including things like INSTALL.md and README.md that tell you things about building the software)
1122017-07-27T08:42:56  <wumpus> if that's so, it should probably be part of 'make install'
1132017-07-27T08:43:11  <wumpus> if it's not installed somewhere, how aer people normally supposed to use it?
1142017-07-27T08:43:17  <gmaxwell> normally build instructions don't end up in make install though.. right.
1152017-07-27T08:43:25  <gmaxwell> er right?
1162017-07-27T08:43:38  <wumpus> that's maybe the only exception
1172017-07-27T08:44:04  <gmaxwell> development script would be another.
1182017-07-27T08:44:15  <wumpus> but linearize? I'm not sure that's generally useful to end-users, even if it should be, it's not in a fool proof state suited for that
1192017-07-27T08:44:26  <gmaxwell> yes, linearize should get installed.
1202017-07-27T08:44:38  <wumpus> then it should be maintained and tested too
1212017-07-27T08:45:13  <gmaxwell> ya, and if it's not fool proof enough, thats a reason to not install it right now I guess.
1222017-07-27T08:45:36  <wumpus> most developer scripts make no sense if you don't have a git checkout
1232017-07-27T08:46:07  <wumpus> a lot even rely on it explicitly (to find the root for pulling transifex translations, for example)
1242017-07-27T08:46:44  <wumpus> in any case I think being somewhat selective about what to include in the dist is fine
1252017-07-27T08:47:10  <wumpus> though I agree just a git tarball would make things a lot easier
1262017-07-27T08:47:56  *** dgenr8 has joined #bitcoin-core-dev
1272017-07-27T08:48:00  <gmaxwell> verify-binaries, are quite useful and very much part of our source. I don't really think we gain anything by leaving something out even if it might not be that useful,  except for pure git things like gitignore files.
1282017-07-27T08:48:11  <wumpus> well then
1292017-07-27T08:48:15  <wumpus> thinking of it, why don't we just skip the make dist and include everything
1302017-07-27T08:48:18  <wumpus> zip up the git repository
1312017-07-27T08:48:29  <wumpus> the tarball is the smallest file
1322017-07-27T08:48:40  <gmaxwell> the make dist eliminates the endusers need for a full and compatible autotools setup.
1332017-07-27T08:48:54  <wumpus> it's not like we have to worry about a few extra source files in the downlaod or storage
1342017-07-27T08:49:10  <wumpus> wouldn't running autogen.sh before zipping uphave the same effect?
1352017-07-27T08:49:29  <wumpus> (maybe with some special options)
1362017-07-27T08:49:41  <gmaxwell> Yes +/- some temp files I think autogen leaves behind.
1372017-07-27T08:49:51  <wumpus> we efiniltely don't need the selective part of 'make dist' then
1382017-07-27T08:50:02  <wumpus> yes, well that's not too bad
1392017-07-27T08:50:53  <gmaxwell> I don't think I have know any counterarguments to that point.
1402017-07-27T08:51:06  <gmaxwell> maybe someone who knows autotools better would be aware of something we're missing.
1412017-07-27T08:51:31  <wumpus> it would be the minimum energy expenditure to finally getting this discussion out of the way at least
1422017-07-27T08:53:57  *** owowo has quit IRC
1432017-07-27T08:54:07  <wumpus> I am kind of surprised verify-binaries isn't included
1442017-07-27T08:55:13  <wumpus> cfields: any reason not to do the above? e.g. make the tarball simply a repo dump + build system autogenerated files
1452017-07-27T08:55:22  <gmaxwell> looking at the list, I think its just accidental. stuff got added without anyone throwing it into extra dist because it's easy to forget. seems there are things in libsecp256k1 where we'd do that too.
1462017-07-27T08:55:49  <cfields> wumpus: i suppose that's fine
1472017-07-27T08:56:14  <wumpus> otherwise we're bound to forget things and have this "the tarball is useless!" discussion again and agian
1482017-07-27T08:56:43  *** owowo has joined #bitcoin-core-dev
1492017-07-27T08:56:50  <cfields> the 'make dist' stuff is kinda outdated. It's intended to be an explicit list of files so that the release tarball doesn't get polluted by the builder's working dir...
1502017-07-27T08:56:59  <cfields> but with our build process, it's really kinda moot
1512017-07-27T08:57:20  <wumpus> which could also be avoided by taking the snapshot before starting building
1522017-07-27T08:57:24  <wumpus> yeah
1532017-07-27T08:57:59  <cfields> yea, tar it up after bootstrap but before anything else
1542017-07-27T08:59:21  <wumpus> I understand the reasoning behind being selective about what to include, but we don't have the people nor attention to carefully decide that every time, so erring on the side of 'include everything' makes sense for this project. For others (like secp256k1) which are more focused it's probably different.
1552017-07-27T09:00:11  <luke-jr> fixing make dist is proving to be a real pain (hi depends/ … ) so I like the idea of not using it
1562017-07-27T09:00:42  <wumpus> depends/ is another joy in that regard, yes :)
1572017-07-27T09:00:47  <cfields> agreed
1582017-07-27T09:01:32  *** Aaronvan_ has quit IRC
1592017-07-27T09:02:10  *** AaronvanW has joined #bitcoin-core-dev
1602017-07-27T09:04:38  *** AaronvanW has quit IRC
1612017-07-27T09:04:58  *** AaronvanW has joined #bitcoin-core-dev
1622017-07-27T09:13:35  *** d_t has quit IRC
1632017-07-27T09:34:16  *** riemann has joined #bitcoin-core-dev
1642017-07-27T09:38:29  <wumpus> sigh, no, I still don't think it's acceptable to mention bitcoin-cli specifically in RPC error messages, it should be aimed at people using the JSON-RPC API, not people using bitcoin-cli only
1652017-07-27T09:38:46  <wumpus> there's no point in talking about a specific client in server error messages
1662017-07-27T09:39:05  <wumpus> that's just wrong, and won't help someone struggling with this interface in say python-bitcoinrpc
1672017-07-27T09:39:45  *** Dyaheon has quit IRC
1682017-07-27T09:40:41  *** Dyaheon has joined #bitcoin-core-dev
1692017-07-27T09:42:58  <wumpus> why is it so much to ask that documentation for bitcoin-cli arguments belongs in bitcoin-cli?
1702017-07-27T09:46:37  <wumpus> it doesn't belong in two places, no it just belongs in bitcoin-cli
1712017-07-27T09:54:35  *** promag has joined #bitcoin-core-dev
1722017-07-27T09:56:08  *** Cory has joined #bitcoin-core-dev
1732017-07-27T09:57:18  *** jtimon has quit IRC
1742017-07-27T10:03:01  *** Cory has quit IRC
1752017-07-27T10:11:29  <wumpus> gah, coredev.tech is september, scaling bitcoin in november, both in SF area, would have been better to plan it closer together :/
1762017-07-27T10:11:51  *** Aaronvan_ has joined #bitcoin-core-dev
1772017-07-27T10:13:01  *** Cory has joined #bitcoin-core-dev
1782017-07-27T10:15:11  *** AaronvanW has quit IRC
1792017-07-27T10:22:51  <wumpus> phew, at least 'make dist' includes the function test suite
1802017-07-27T10:24:54  <sipa> wumpus: just stay :)
1812017-07-27T10:25:49  <wumpus> sipa: if it was a two weeks in between instead of two months I would
1822017-07-27T10:26:16  <sipa> yeah :)
1832017-07-27T10:28:41  <wumpus> indeed, the ESTA allows staying 90 days, so theoretically it'd be possible, but just too much hassle
1842017-07-27T10:35:10  *** dabura667 has quit IRC
1852017-07-27T10:45:17  *** blisscan has joined #bitcoin-core-dev
1862017-07-27T10:48:40  *** riemann has quit IRC
1872017-07-27T10:50:38  <jonasschnelli> wumpus: Yeah. The SB guy contacted me after I have booked the room.
1882017-07-27T10:50:48  <jonasschnelli> He asked to move it closer... :)
1892017-07-27T10:50:55  <jonasschnelli> But was already too late.
1902017-07-27T10:51:07  <jonasschnelli> Too bad he did not contact me before announcing the date
1912017-07-27T10:51:17  <jonasschnelli> I bet the knew weeks ago
1922017-07-27T10:53:05  *** riemann has joined #bitcoin-core-dev
1932017-07-27T11:08:10  *** Giszmo has joined #bitcoin-core-dev
1942017-07-27T11:11:13  <bitcoin-git> [bitcoin] promag opened pull request #10941: Add blocknotify functional test (master...2017-07-blocknotify-functional-test) https://github.com/bitcoin/bitcoin/pull/10941
1952017-07-27T11:14:55  <promag> #10941 makes sense right? should add tests for -walletnotify too right?
1962017-07-27T11:14:56  <gribble> https://github.com/bitcoin/bitcoin/issues/10941 | Add blocknotify functional test by promag · Pull Request #10941 · bitcoin/bitcoin · GitHub
1972017-07-27T11:15:15  <wumpus> sure!
1982017-07-27T11:15:34  <promag> will do
1992017-07-27T11:15:38  <wumpus> ideally there should be tests for everything
2002017-07-27T11:16:03  <promag> right, makes reviewing easy
2012017-07-27T11:16:31  <promag> ideally changing code should have some impact in tests
2022017-07-27T11:17:02  <promag> most PR's don't change tests
2032017-07-27T11:18:14  <wumpus> right, apart from pure refactors and optimizations
2042017-07-27T11:19:39  <promag> even those
2052017-07-27T11:19:57  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5c8eb7916de7...8a99fe053a5d
2062017-07-27T11:19:58  <bitcoin-git> bitcoin/master f228b8e Marko Bencun: remove some unused functions...
2072017-07-27T11:19:59  <bitcoin-git> bitcoin/master 8a99fe0 Wladimir J. van der Laan: Merge #10501: remove some unused functions...
2082017-07-27T11:20:03  <wumpus> if the behavior stays the same, the tests can also stay the same
2092017-07-27T11:20:18  <bitcoin-git> [bitcoin] laanwj closed pull request #10501: remove some unused functions (master...unusedfuncs) https://github.com/bitcoin/bitcoin/pull/10501
2102017-07-27T11:21:08  *** blisscan has quit IRC
2112017-07-27T11:21:09  <promag> refactors can impact tests, for instance, a test uses a lib which has new signatures..
2122017-07-27T11:21:23  <promag> in terms of functional tests, yes you're right
2132017-07-27T11:23:33  <wumpus> you could have tests for e.g. optimizations, that check benchmarks for inner functions such as sha256 etc, but it'd require a stable dedicated platform, certainly not on our current infrastructure
2142017-07-27T11:25:29  <wumpus> also something that automatically syncs from a local node and keeps timings, daily w/ most recent master could be useful, but it'd certailny need a deterministic environment or there'd be too much noise
2152017-07-27T11:31:39  <promag> right
2162017-07-27T11:31:42  *** Giszmo has quit IRC
2172017-07-27T11:31:55  <promag> I'm for sure interested in improve that
2182017-07-27T11:32:10  <promag> it's a great way to get deeper in the project
2192017-07-27T11:32:13  *** promag has quit IRC
2202017-07-27T11:32:26  <wumpus> it'd need infrastructure, not so much coding work
2212017-07-27T11:32:54  <wumpus> with an available server it'd be quite easy to set it up
2222017-07-27T11:38:08  <jonasschnelli> promag: I could provide you the necessary infrastructure (server hosted remotly, ideally for test/benchmarks)
2232017-07-27T11:39:58  *** Giszmo has joined #bitcoin-core-dev
2242017-07-27T11:56:43  *** coredump_ has joined #bitcoin-core-dev
2252017-07-27T12:00:59  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8a99fe053a5d...ba1bbb049b8f
2262017-07-27T12:00:59  <bitcoin-git> bitcoin/master 72f0060 Dag Robole: Replace traditional for with ranged for in primitives
2272017-07-27T12:01:00  <bitcoin-git> bitcoin/master ba1bbb0 Wladimir J. van der Laan: Merge #10892: Replace traditional for with ranged for in block and transaction primitives...
2282017-07-27T12:01:30  <bitcoin-git> [bitcoin] laanwj closed pull request #10892: Replace traditional for with ranged for in block and transaction primitives (master...20170721-rangedfor-primitives) https://github.com/bitcoin/bitcoin/pull/10892
2292017-07-27T12:03:01  *** jannes has joined #bitcoin-core-dev
2302017-07-27T12:09:09  *** J-wolf has quit IRC
2312017-07-27T12:14:23  *** EagleTM has joined #bitcoin-core-dev
2322017-07-27T12:16:48  *** J-wolf has joined #bitcoin-core-dev
2332017-07-27T12:18:09  *** J-wolf has quit IRC
2342017-07-27T12:20:03  *** J-wolf has joined #bitcoin-core-dev
2352017-07-27T12:20:44  *** Dojixo has joined #bitcoin-core-dev
2362017-07-27T12:28:46  *** J-wolf has quit IRC
2372017-07-27T12:31:25  *** Blisscan has joined #bitcoin-core-dev
2382017-07-27T12:31:25  *** EagleTM has quit IRC
2392017-07-27T12:34:05  *** tucenaber has quit IRC
2402017-07-27T12:37:58  *** ivan has quit IRC
2412017-07-27T12:50:34  *** tucenaber has joined #bitcoin-core-dev
2422017-07-27T12:50:35  *** tucenaber has joined #bitcoin-core-dev
2432017-07-27T12:58:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2442017-07-27T13:10:52  *** coredump_ has quit IRC
2452017-07-27T13:14:51  *** goatpig has joined #bitcoin-core-dev
2462017-07-27T13:18:08  *** veleiro has joined #bitcoin-core-dev
2472017-07-27T13:29:32  *** cheese_ has joined #bitcoin-core-dev
2482017-07-27T13:39:45  *** Chris_Stewart_5 has quit IRC
2492017-07-27T13:55:14  *** RoyceX has joined #bitcoin-core-dev
2502017-07-27T13:56:17  *** johnpark_pj has quit IRC
2512017-07-27T13:56:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2522017-07-27T13:57:50  *** cheese_ has quit IRC
2532017-07-27T13:59:27  *** johnpark_pj has joined #bitcoin-core-dev
2542017-07-27T14:03:00  *** J-wolf has joined #bitcoin-core-dev
2552017-07-27T14:03:09  *** promag has joined #bitcoin-core-dev
2562017-07-27T14:04:28  *** intcat has quit IRC
2572017-07-27T14:04:35  *** Chris_Stewart_5 has quit IRC
2582017-07-27T14:05:12  *** J-wolf has quit IRC
2592017-07-27T14:05:38  *** intcat has joined #bitcoin-core-dev
2602017-07-27T14:06:51  *** J-wolf has joined #bitcoin-core-dev
2612017-07-27T14:14:48  *** Murch has joined #bitcoin-core-dev
2622017-07-27T14:33:48  *** iprokg has joined #bitcoin-core-dev
2632017-07-27T14:34:01  *** J-wolf has quit IRC
2642017-07-27T14:38:11  *** iprokg has quit IRC
2652017-07-27T14:48:43  *** promag has quit IRC
2662017-07-27T14:50:56  *** jb55 has joined #bitcoin-core-dev
2672017-07-27T14:54:53  *** riemann has quit IRC
2682017-07-27T15:02:01  *** Dyaheon has quit IRC
2692017-07-27T15:04:30  *** Dyaheon has joined #bitcoin-core-dev
2702017-07-27T15:09:40  *** Blisscan has quit IRC
2712017-07-27T15:32:43  *** praxeology has quit IRC
2722017-07-27T15:33:19  *** jb55 has quit IRC
2732017-07-27T15:37:15  *** Drabiv has joined #bitcoin-core-dev
2742017-07-27T15:41:07  *** RoyceX has quit IRC
2752017-07-27T15:42:38  *** Orion3k has quit IRC
2762017-07-27T15:58:11  <wumpus> re: installing linearize, I think the main thing that needs to be done to make it more user friendly is to make it one command, instead of the split between generating the blocks list and writing them out. These could be subcommands/options for when doing them separately.
2772017-07-27T15:59:52  <wumpus> at the least cookie authentication was already implemented, that's nice, used to be that it required always manually setting up the authentication
2782017-07-27T16:02:45  *** Orion3k has joined #bitcoin-core-dev
2792017-07-27T16:06:46  *** Orion3k has quit IRC
2802017-07-27T16:12:13  *** jb55 has joined #bitcoin-core-dev
2812017-07-27T16:14:25  *** marcoagner has quit IRC
2822017-07-27T16:15:25  *** Aaronvan_ has quit IRC
2832017-07-27T16:17:33  *** Orion3k has joined #bitcoin-core-dev
2842017-07-27T16:21:05  *** marcoagner has joined #bitcoin-core-dev
2852017-07-27T16:21:32  *** AaronvanW has joined #bitcoin-core-dev
2862017-07-27T16:23:03  *** jb55 has quit IRC
2872017-07-27T16:28:55  *** Orion3k has quit IRC
2882017-07-27T16:35:20  *** EagleTM has joined #bitcoin-core-dev
2892017-07-27T16:40:58  *** Orion3k has joined #bitcoin-core-dev
2902017-07-27T16:46:34  *** cluelessperson has quit IRC
2912017-07-27T16:52:07  *** jamesob has joined #bitcoin-core-dev
2922017-07-27T16:58:59  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ba1bbb049b8f...0b11a0784875
2932017-07-27T16:59:00  <bitcoin-git> bitcoin/master e526b3d Russell Yanofsky: Fix misleading "Method not found" multiwallet errors...
2942017-07-27T16:59:00  <bitcoin-git> bitcoin/master df389bc Russell Yanofsky: Change wallet method disabled error text...
2952017-07-27T16:59:01  <bitcoin-git> bitcoin/master 0b11a07 Wladimir J. van der Laan: Merge #10931: Fix misleading "Method not found" multiwallet errors...
2962017-07-27T16:59:35  <bitcoin-git> [bitcoin] laanwj closed pull request #10931: Fix misleading "Method not found" multiwallet errors (master...pr/multierr) https://github.com/bitcoin/bitcoin/pull/10931
2972017-07-27T17:07:48  *** Dyaheon has quit IRC
2982017-07-27T17:09:12  *** Dyaheon has joined #bitcoin-core-dev
2992017-07-27T17:12:39  *** abpa has joined #bitcoin-core-dev
3002017-07-27T17:14:53  *** Dojixo has quit IRC
3012017-07-27T17:17:17  *** Drabiv has quit IRC
3022017-07-27T17:26:14  *** Deacydal has joined #bitcoin-core-dev
3032017-07-27T17:27:25  *** Deacyde has quit IRC
3042017-07-27T17:32:04  *** jannes has quit IRC
3052017-07-27T17:39:19  *** eck has quit IRC
3062017-07-27T17:39:56  *** eck has joined #bitcoin-core-dev
3072017-07-27T17:56:19  *** cluelessperson has joined #bitcoin-core-dev
3082017-07-27T17:56:38  *** J-wolf has joined #bitcoin-core-dev
3092017-07-27T17:56:43  *** Dizzle has joined #bitcoin-core-dev
3102017-07-27T18:00:02  *** jtimon has joined #bitcoin-core-dev
3112017-07-27T18:00:53  *** timothy has quit IRC
3122017-07-27T18:01:20  *** harding has joined #bitcoin-core-dev
3132017-07-27T18:05:32  *** AaronvanW has quit IRC
3142017-07-27T18:06:08  *** AaronvanW has joined #bitcoin-core-dev
3152017-07-27T18:07:59  *** praxeology has joined #bitcoin-core-dev
3162017-07-27T18:08:10  *** praxeology has joined #bitcoin-core-dev
3172017-07-27T18:09:31  *** J-wolf has quit IRC
3182017-07-27T18:24:44  *** praxeology has left #bitcoin-core-dev
3192017-07-27T18:30:22  *** cluelessperson has quit IRC
3202017-07-27T18:31:23  *** eck has quit IRC
3212017-07-27T18:31:49  <morcos> Can we merge #10758 before I fill up all my disks with genesis blocks?
3222017-07-27T18:31:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
3232017-07-27T18:32:06  *** eck has joined #bitcoin-core-dev
3242017-07-27T18:36:10  *** Guyver2 has joined #bitcoin-core-dev
3252017-07-27T18:36:34  *** cluelessperson has joined #bitcoin-core-dev
3262017-07-27T18:37:37  <wumpus> morcos: and fix the error messages later? fine with me
3272017-07-27T18:44:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3282017-07-27T18:54:18  <BlueMatt> wumpus: morcos lol, give me a few minutes, I'm testing the on-the-fly compaction stuff
3292017-07-27T18:54:27  <BlueMatt> (which, on my test system, reliably makes it worse....)
3302017-07-27T18:55:41  <gmaxwell> https://en.wikipedia.org/wiki/Repeated_sequence_(DNA)
3312017-07-27T18:55:56  <BlueMatt> ?
3322017-07-27T18:57:13  <wumpus> "In many organisms, a significant fraction of the genomic DNA is highly repetitive, with over two-thirds of the sequence consisting of repetitive elements in human." well at least that means it could be compressed efficiently :p
3332017-07-27T18:57:43  *** sam_c has quit IRC
3342017-07-27T18:58:44  <BlueMatt> ???
3352017-07-27T18:59:17  <wumpus> probably responding to the genesis block that gets added again and again
3362017-07-27T18:59:29  *** sam_c has joined #bitcoin-core-dev
3372017-07-27T18:59:35  <gmaxwell> yes
3382017-07-27T18:59:37  <BlueMatt> ah
3392017-07-27T19:00:27  <wumpus> #startmeeting
3402017-07-27T19:00:27  <lightningbot> Meeting started Thu Jul 27 19:00:27 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3412017-07-27T19:00:27  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3422017-07-27T19:00:35  <jonasschnelli> hi
3432017-07-27T19:00:38  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
3442017-07-27T19:00:43  <gmaxwell> achow101:
3452017-07-27T19:00:49  <kanzure> hi.
3462017-07-27T19:00:50  <jonasschnelli> +promag
3472017-07-27T19:00:51  <achow101> hi
3482017-07-27T19:00:59  <morcos> here for 30
3492017-07-27T19:01:01  <Murch> hi
3502017-07-27T19:01:04  <BlueMatt> oh, thats today?
3512017-07-27T19:01:06  <jtimon> hi
3522017-07-27T19:01:08  <wumpus> I think it's most useful to discuss the still-open issues for 0.15 today
3532017-07-27T19:01:13  <wumpus> https://github.com/bitcoin/bitcoin/milestones/0.15.0
3542017-07-27T19:01:44  <jtimon> yep, sounds like a good first topic (that will probably take most of the meeting)
3552017-07-27T19:02:04  <wumpus> FWIW rc1 is planned for 2017-08-06
3562017-07-27T19:02:14  <wumpus> ok, I'll just follow the list
3572017-07-27T19:02:45  <wumpus> #topic test_bitcoin fails valgrind Tests (#9278)
3582017-07-27T19:02:46  <gribble> https://github.com/bitcoin/bitcoin/issues/9278 | test_bitcoin fails valgrind · Issue #9278 · bitcoin/bitcoin · GitHub
3592017-07-27T19:02:51  <wumpus> this is the oldest issue in the list
3602017-07-27T19:03:06  <achow101> I checked last week that this was still a problem
3612017-07-27T19:03:23  <wumpus> ok, so this still needs to be fixed?
3622017-07-27T19:03:43  <gmaxwell> cfields: are you working on that? if you don't have time, someone else can pick it up
3632017-07-27T19:03:44  <BlueMatt> its assigned cfields....
3642017-07-27T19:03:54  <achow101> it should probably be fixed, but I don't know if it is a blocker or how urgent a fix would be required
3652017-07-27T19:04:18  <morcos> He's only had 8 months cut him a break
3662017-07-27T19:04:18  <gmaxwell> Looks like it should be a trivial fix (famous last words)
3672017-07-27T19:04:20  <achow101> it was already pushed from 0.14 to 0.15, so I'm guessing it isn't all that urgent
3682017-07-27T19:04:24  <wumpus> I don't think uninitalized state in a test is important enough to block 0.15, though it could result in intermittent faliures which are always annoying
3692017-07-27T19:04:34  <jonasschnelli> Yes. Moving to 0.16 would be possible.
3702017-07-27T19:04:44  <wumpus> though it might hide real issues
3712017-07-27T19:04:56  <wumpus> (if the tests are not valgrind clean)
3722017-07-27T19:05:01  <gmaxwell> I'm guessing cfields and sipa are not in the meeting today due to timezones.
3732017-07-27T19:05:19  <gmaxwell> I'll follow up and make sure it gets fixed (either extract something cfields hasn't submitted yet or fix it myself)
3742017-07-27T19:05:42  <wumpus> ok, thanks
3752017-07-27T19:05:47  <gmaxwell> (or realize it isn't actually trivial and ask for a punt to the next version)
3762017-07-27T19:05:54  <wumpus> #topic sendtoaddress subtractfeefromamount=true does not respect paytxfee values (#10034)
3772017-07-27T19:05:56  <gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
3782017-07-27T19:06:13  <morcos> Are we going to do the wiki thing again for release notes?  If so can we put a link to it on the top of #9889.  I kept having trouble finding that link last release
3792017-07-27T19:06:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9889 | TODO for release notes 0.15.0 · Issue #9889 · bitcoin/bitcoin · GitHub
3802017-07-27T19:06:21  <wumpus> I'm not sure about this one, don't think it has been looked at much
3812017-07-27T19:06:41  <wumpus> morcos: yes, good idea
3822017-07-27T19:06:43  <gmaxwell> Lets decide if we're doing the wiki or not, last time the wiki merge killed release notes written directly. :)
3832017-07-27T19:06:59  <wumpus> but it helped a lot with actually getting release notes written
3842017-07-27T19:07:00  <gmaxwell> I've held off on writing release notes due to lack of clarity on this point.
3852017-07-27T19:07:14  <wumpus> and getting the style consistent etc
3862017-07-27T19:07:14  <gmaxwell> I'm fine with doing it, I just need to know where to put them.
3872017-07-27T19:07:26  <wumpus> well right now you simply have to create a PR
3882017-07-27T19:07:30  <gmaxwell> I don't want to write any outside of the wiki if we're using the wiki.
3892017-07-27T19:07:34  <wumpus> as soon as the wiki is open, do it there
3902017-07-27T19:07:36  <morcos> I recommend we do the wiki, but we need a good code of conduct, where people should not make potentially controversial changes without flagging them somehow
3912017-07-27T19:07:46  <gmaxwell> wumpus: I did that last time and they got stomped by the wiki merge. :)
3922017-07-27T19:08:02  <morcos> Let's do the wiki.
3932017-07-27T19:08:07  <jonasschnelli> +1
3942017-07-27T19:08:09  <wumpus> gmaxwell: I know, we should avoid that, but that's no reason to completely abandon a good idea
3952017-07-27T19:08:25  <gmaxwell> So on this feefrom amount, that sounds like the known overpayment bug with no change that we fixed though I don't recall if we fixed it in the feefrom amount case.
3962017-07-27T19:08:32  <gmaxwell> wumpus: I'm all for the wiki.
3972017-07-27T19:08:45  <achow101> we should do the wiki and probably open it now
3982017-07-27T19:08:54  <gmaxwell> Just someone point me to it and I'll write a bunch of release notes.
3992017-07-27T19:09:00  <wumpus> gmaxwell: I think we should put the commit id that the wiki 'forked' from on that page, so that it can be compared if there haven't been changes since when mering it back
4002017-07-27T19:09:12  <achow101> +1
4012017-07-27T19:09:13  <gmaxwell> that would help too.
4022017-07-27T19:09:23  <wumpus> (this was missing last time, so I had no reference point)
4032017-07-27T19:09:50  <wumpus> re: 10034, I'm not sure why that's labelled 0.15
4042017-07-27T19:09:57  <jtimon> wumpus: ack on commit id on the wiki
4052017-07-27T19:10:04  <kanzure> wumpus: if you mean github wiki, those are actually git repositories, so they do literally have forks/branches (even if github tosses them).
4062017-07-27T19:10:05  <achow101> is #10034 actually a problem or is it just an instance of an already known issue?
4072017-07-27T19:10:06  <gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
4082017-07-27T19:10:25  <morcos> I'll take a look at 10034, but there have been multiple changes to this code for 0.15, so not clear that even if there was a bug it would still be there
4092017-07-27T19:10:28  <wumpus> kanzure: true, you can fork and edit locally, but I mean the bitcoin core master revision
4102017-07-27T19:10:41  <wumpus> morcos: thanks
4112017-07-27T19:11:11  <jonasschnelli> Also, if 10034 is still a bug, it does not deserve the "medium" tag IMO
4122017-07-27T19:11:22  <gmaxwell> achow101: I think 10034 is the known thing that we fixed at least in the non-fee-from-value case.
4132017-07-27T19:11:46  <gmaxwell> jonasschnelli: Do you believe it deserves high.. overpaying fees should be high. IMO.
4142017-07-27T19:12:15  <morcos> gmaxwell: it seems to have some determinism in the description that bears a closer look.. but i'm not expecting to find anything
4152017-07-27T19:12:17  <wumpus> the dirty secret is that we don't really use the priority tags for issues/prs for anything :)
4162017-07-27T19:12:34  <jonasschnelli> heh
4172017-07-27T19:12:35  <gmaxwell> yea...
4182017-07-27T19:12:49  <gmaxwell> morcos: thanks for looking at it.
4192017-07-27T19:13:40  <jtimon> priority medium seems specially useless, if it's not tagged low or high, then it's medium, no?
4202017-07-27T19:13:44  <wumpus> #topic Force on-the-fly compaction during pertxout upgrade  UTXO Db and Indexes (#10526)
4212017-07-27T19:13:45  <gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
4222017-07-27T19:13:58  <gmaxwell> jtimon: untagged is a possible state (not evaluated yet).
4232017-07-27T19:14:04  <wumpus> jtimon: I think in practice only priority high could be useful, if someone paid attention to it
4242017-07-27T19:14:10  <gmaxwell> wumpus: as morocos noted on the PR, it's not shrinking on its own.
4252017-07-27T19:14:28  <gmaxwell> $ du -sh .
4262017-07-27T19:14:28  <gmaxwell> 5.8G    .
4272017-07-27T19:14:38  <wumpus> jtimon: then again, I think a year ago I checked "high priority" issues and some were >5 years old
4282017-07-27T19:14:41  <jtimon> gmaxwell: right, but then you have to tag them all with something about priority once you evaluate them
4292017-07-27T19:14:48  <BlueMatt> see my most recent comment on it: that pr makes upgrade time a bunch faster for me, but also doesnt actually save disk space directly (but its done later upon next-db-reopen cause i guess leveldb realizes it has a bunch of tables it doesnt need)
4302017-07-27T19:15:02  <BlueMatt> gmaxwell: I believe it may clean it up over time, but not quickly
4312017-07-27T19:15:09  <gmaxwell> So I think we really need to do that... but IIRC we had a report from wumpus saying that it didn't work for him.
4322017-07-27T19:15:23  <BlueMatt> anyway, yes, we should take 10526 for 15 imo, morcos had one code issue on it, but it doesnt appear to change behavior for me
4332017-07-27T19:15:23  <gmaxwell> BlueMatt: I've had two weeks and many startup and shutdowns on this node... so ... really not quickly.
4342017-07-27T19:15:37  <wumpus> gmaxwell: it doesn't work reliably for me, no
4352017-07-27T19:16:12  <gmaxwell> wumpus: could it be what bluematt says.. it works but doesn't take effect until after another restart?
4362017-07-27T19:16:17  <BlueMatt> gmaxwell: see my later comment, i meant that it'll do it when tables fill, ie when you connect more blocks and so
4372017-07-27T19:16:27  <wumpus> gmaxwell: sometimes after running upgrade on that test set it it is 2.1G sometimes 4.3G, apparently random, after another restart it's always down
4382017-07-27T19:16:31  <wumpus> gmaxwell: yes, that could well be
4392017-07-27T19:16:54  <gmaxwell> okay, well thats still better than behavior in master.. which I've tried on several hosts and it results in a persistant 5.8 gb state.
4402017-07-27T19:17:00  <morcos> well if it consistently shrinks at the very latest after another restart, that's a clear improvement
4412017-07-27T19:17:03  <wumpus> well the, we should merge it, better is better
4422017-07-27T19:17:18  <BlueMatt> if we want we can probably simulate restart by closing and re-opening db :p
4432017-07-27T19:17:22  <morcos> needs a bug fix though, commented on pr
4442017-07-27T19:18:01  <wumpus> yes
4452017-07-27T19:18:07  <achow101> I hope it does actually work. my node running master has a chainstate of 8.2 GB right now (it was upgraded from a previous 0.14 master)
4462017-07-27T19:18:08  <gmaxwell> BlueMatt: yes though that doesn't get rid of the peak usage, we'll need to release note that upgrading will require an extra 3GB free disk space.
4472017-07-27T19:18:13  <achow101> I can test it too
4482017-07-27T19:18:27  <gmaxwell> uh.. 5GB disk space.
4492017-07-27T19:18:28  <wumpus> achow101: yes, please test
4502017-07-27T19:18:38  <gmaxwell> achow101: well it doesn't fix already bloated ones.
4512017-07-27T19:18:41  <BlueMatt> gmaxwell: yes, please note that on the release notes todo
4522017-07-27T19:18:56  <morcos> how'd you get 8.2, that's yuuuge
4532017-07-27T19:19:02  <achow101> i don't know
4542017-07-27T19:19:08  <gmaxwell> morcos: don't make fun of how I pronounce huge. :(
4552017-07-27T19:19:47  <BlueMatt> heh
4562017-07-27T19:20:04  <gmaxwell> Maybe we should sneak in a hidden rpc to compact the whole database. (I think there is just a leveldb call to do that)
4572017-07-27T19:20:13  <wumpus> 8.2 is definitely abnormal, if it's from a very old version maybe something left behind
4582017-07-27T19:20:36  <BlueMatt> gmaxwell: seems reasonable to me
4592017-07-27T19:20:40  <achow101> wumpus: its the same datadir from a 0.10 master that has been periodically upgraded over the years
4602017-07-27T19:20:53  <achow101> to different random master builds
4612017-07-27T19:21:06  <wumpus> (leveldb changed some things also, over time, e.g. the extension for database files at some point even)
4622017-07-27T19:21:11  <gmaxwell> achow101: it would be interesting to see if leveldb compaction shrinks it, or if it actually has zombie records in it due to some kind of corruption.
4632017-07-27T19:21:22  <wumpus> achow101: can you send me a pastebinned 'ls'?
4642017-07-27T19:21:39  <wumpus> zombie records, or zombie files even
4652017-07-27T19:22:02  <gmaxwell> achow101: you should also try gettxoutsetinfo to compare its hash with another non-bloaty host.
4662017-07-27T19:22:21  <wumpus> adding a hidden RPC to compact databases is fine with me
4672017-07-27T19:22:26  <gmaxwell> I think we know what to do to go forward on this one then.
4682017-07-27T19:22:30  <wumpus> ye
4692017-07-27T19:22:34  <wumpus> #topic Fix some chainstate-init-order bugs (#10758)
4702017-07-27T19:22:36  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
4712017-07-27T19:22:49  <BlueMatt> lots of bugs, lots of complicated
4722017-07-27T19:23:07  <BlueMatt> #10919 fixes even more bugs!
4732017-07-27T19:23:08  <gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
4742017-07-27T19:23:10  <wumpus> i think that one's ready for merge, I found some silly error message discrepancies but seems was re-pushed after
4752017-07-27T19:23:14  <BlueMatt> and has lots of more complicated
4762017-07-27T19:23:15  <achow101> wumpus: https://pastebin.com/hAeYMjRW
4772017-07-27T19:23:19  <gmaxwell> This is what fixes the genesis block grey goo?
4782017-07-27T19:23:27  <BlueMatt> gmaxwell: among other issues, yes
4792017-07-27T19:23:45  <wumpus> yep
4802017-07-27T19:25:08  <gmaxwell> LGTM. I'll test it if it doesn't get merged first.
4812017-07-27T19:25:14  <wumpus> we'll get to 10919 later
4822017-07-27T19:25:17  <wumpus> #topic update assumevalid and minimum chain work (#10778)
4832017-07-27T19:25:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10778 | update assumevalid and minimum chain work · Issue #10778 · bitcoin/bitcoin · GitHub
4842017-07-27T19:25:44  <BlueMatt> i guess only question is do we need be concerned about doing it pre-/post- fork(s), I think not
4852017-07-27T19:25:48  <wumpus> assigning that one to gmaxwell
4862017-07-27T19:25:49  <gmaxwell> wumpus: when do you want me to PR that.. I can do it at any time.
4872017-07-27T19:25:55  <wumpus> gmaxwell: asap imo
4882017-07-27T19:26:02  <BlueMatt> why not next week?
4892017-07-27T19:26:04  <achow101> best before august 1st?
4902017-07-27T19:26:05  <wumpus> BlueMatt: yes that is a good point
4912017-07-27T19:26:06  <BlueMatt> later the better
4922017-07-27T19:26:16  <gmaxwell> Generally the later the better.
4932017-07-27T19:26:23  <gmaxwell> But I don't want to miss it.
4942017-07-27T19:26:34  <BlueMatt> worst case it misses rc1 but makes it in for rc2
4952017-07-27T19:26:36  <wumpus> yes though I doubt a week makes that much difference, ignoring possible fork scenario
4962017-07-27T19:26:36  <gmaxwell> It needs review before merge (since you'll need to check it matches your chain)
4972017-07-27T19:26:55  <wumpus> yes, so please make a PR asap
4982017-07-27T19:26:57  <BlueMatt> true, i dont care, gmaxwell up to you
4992017-07-27T19:27:10  <wumpus> it can always be updated
5002017-07-27T19:27:20  <gmaxwell> Okay, I'll PR soon.
5012017-07-27T19:27:21  <wumpus> (maybe it has to be, if reveiewers have problems with it)
5022017-07-27T19:27:27  <wumpus> ok, thanks
5032017-07-27T19:27:55  <gmaxwell> A week makes a measureable amount of synctime difference, unfortunately. :(  but not enough to worry about debating it much.
5042017-07-27T19:27:59  <gmaxwell> :)
5052017-07-27T19:28:05  <jtimon> yep, later better, but merged better too
5062017-07-27T19:28:43  <wumpus> yeah, I don't care about the exact day, let's just make sure that there is PR open that can be merged before we do the 0.15 branch
5072017-07-27T19:28:49  <wumpus> #topic Fix addwitnessaddress by replacing ismine with producesignature (#10788)
5082017-07-27T19:28:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10788 | [RPC] Fix addwitnessaddress by replacing ismine with producesignature by achow101 · Pull Request #10788 · bitcoin/bitcoin · GitHub
5092017-07-27T19:29:22  <wumpus> this seems to require some work still, according to sdaftuar
5102017-07-27T19:29:31  <morcos> I just started looking at that one, but I like sipa's suggestion for addressing sdaftuars concern
5112017-07-27T19:29:42  <gmaxwell> Urgency of fixing it increased by probablity of segwit activation.
5122017-07-27T19:29:44  <achow101> I'm not exactly sure what sdaftuar is concerned about
5132017-07-27T19:29:48  <morcos> I haven't thought about the performance of any of these things
5142017-07-27T19:30:08  <morcos> achow101: just wants it to be clear what code is responsible for accomplishing what requirements
5152017-07-27T19:30:17  <gmaxwell> achow101: sounds like a general concern about the safty of further code changes.
5162017-07-27T19:30:19  <achow101> ah, I see. So sipa's suggestion should be fine
5172017-07-27T19:30:23  <morcos> functionally it'll be no different after change, but it'll be a lot harder to accidentally break
5182017-07-27T19:30:28  <achow101> right
5192017-07-27T19:30:50  <wumpus> being hard to accidentally break is good
5202017-07-27T19:30:55  <gmaxwell> achow101: in addition to sipa's suggestion a strategic comment or two would help.
5212017-07-27T19:31:07  <gmaxwell> Purpose of source code is communication between programmers, after all.
5222017-07-27T19:31:23  <achow101> ok
5232017-07-27T19:32:01  <wumpus> going to skip #10851, as cfields is not here and it's a build system issue
5242017-07-27T19:32:03  <gribble> https://github.com/bitcoin/bitcoin/issues/10851 | depends: bump fontconfig to 2.12.4 by theuni · Pull Request #10851 · bitcoin/bitcoin · GitHub
5252017-07-27T19:32:25  <jtimon> gmaxwell: isn't the purpose of source code that people can read it and learn how to program?
5262017-07-27T19:32:30  <wumpus> #topic Keypool topup (#10882)
5272017-07-27T19:32:33  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
5282017-07-27T19:32:39  <gmaxwell> 10882 I need to sync up with the current state, it looked like it was going in a good direction. I see the latest comments have some improvements still needed.
5292017-07-27T19:33:01  <wumpus> jtimon: no, of course not, the purpose is that they can copy it and change the attribution and claim it's theirs :-)
5302017-07-27T19:33:03  <gmaxwell> but it seems like people know what to do...
5312017-07-27T19:33:09  <gmaxwell> wumpus: lol
5322017-07-27T19:33:10  <jtimon> wumpus: lol
5332017-07-27T19:33:13  <achow101> lol
5342017-07-27T19:33:52  <morcos> gmaxwell: i think 10882 is pretty much done
5352017-07-27T19:34:04  <BlueMatt> its very close, yes
5362017-07-27T19:34:19  <gmaxwell> \O/
5372017-07-27T19:34:25  <gmaxwell> I'll review today.
5382017-07-27T19:34:38  <jonasschnelli> Great
5392017-07-27T19:34:57  <gmaxwell> (as an aside, I'm really happy that people found solutions to issues I raised that I had no idea how to fix)
5402017-07-27T19:35:14  <wumpus> ah the instructions for manual wallet top-up were added, great
5412017-07-27T19:35:19  <wumpus> yeah
5422017-07-27T19:35:23  <gmaxwell> (in particular the two thresholds, so you can bypass critical shutdown)
5432017-07-27T19:36:29  <wumpus> lol github things the diff of wallet.cpp is so huge it hides it by default
5442017-07-27T19:37:08  <gmaxwell> I hate that feature.
5452017-07-27T19:37:21  <jonasschnelli> Yes. Make searching really painful
5462017-07-27T19:37:24  <jonasschnelli> *Makes
5472017-07-27T19:37:26  <gmaxwell> Caused me to screw up reviews before.
5482017-07-27T19:37:38  <gmaxwell> (because I searched for X and then complained a PR couldn't work because it didn't touch X)
5492017-07-27T19:37:38  <BlueMatt> lol just dont review on github directly :)
5502017-07-27T19:37:40  <BlueMatt> next pr?
5512017-07-27T19:37:41  <wumpus> gmaxwell: well they got complaints from people like me that browsers crashed/run out of memory if the page becomes very large, but I agree this is suboptimal too
5522017-07-27T19:37:57  <gmaxwell>  obviously we need to split that file. :P
5532017-07-27T19:38:10  <gmaxwell> lets move on
5542017-07-27T19:38:20  <wumpus> #topic Reject invalid wallets (#10885)
5552017-07-27T19:38:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10885 | Reject invalid wallets by promag · Pull Request #10885 · bitcoin/bitcoin · GitHub
5562017-07-27T19:38:33  <BlueMatt> i think its good
5572017-07-27T19:38:51  <BlueMatt> i saw john's comments but havent had a chance to read the responses or do another review myself
5582017-07-27T19:38:57  <BlueMatt> but is also very close
5592017-07-27T19:39:06  <wumpus> yes, I think it's pretty close
5602017-07-27T19:39:41  <wumpus> I think what's left is mostly comments onthe tests
5612017-07-27T19:39:50  <BlueMatt> thats it, no?
5622017-07-27T19:40:13  <wumpus> #topic Fix more init bugs (#10919)
5632017-07-27T19:40:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
5642017-07-27T19:40:24  <wumpus> no @BlueMatt ^^ moar init bugs
5652017-07-27T19:40:33  <BlueMatt> thats just #10758 part deux
5662017-07-27T19:40:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
5672017-07-27T19:40:59  <BlueMatt> to get the first one merged cause people didnt want me to have a huge ever-growing pile of fixes in one pr
5682017-07-27T19:41:10  <jtimon> probably obvious but why not symlinks?
5692017-07-27T19:42:12  <wumpus> jtimon: berkeleydb doesn't gracefully support them, especially if you link outside the context directory
5702017-07-27T19:42:27  <jtimon> thanks
5712017-07-27T19:42:37  <wumpus> so it's very, very dangerous
5722017-07-27T19:42:44  <wumpus> BlueMatt: ok
5732017-07-27T19:42:56  <wumpus> #topic segwit wallet release (gmaxwell)
5742017-07-27T19:43:53  <gmaxwell> So, segwit is going to activate. It would be nice to get a version out
5752017-07-27T19:43:54  <gmaxwell> soon that exposes a segwit wallet to the user, and maybe supports sending
5762017-07-27T19:43:56  <gmaxwell> to BIP173 style addresses. Maybe we could consider short cycling 0.16
5772017-07-27T19:43:59  <gmaxwell> with primarily just this functionality, or something like that?
5782017-07-27T19:44:01  <gmaxwell> Since we technically have support but don't wire it up by default, (except
5792017-07-27T19:44:04  <gmaxwell> via the RPCs) I believe it's a short effort; mostly a testing concern.
5802017-07-27T19:44:07  <gmaxwell> Another alternative would be to branch, off a 0.15+segwit and cut
5812017-07-27T19:44:09  <gmaxwell> expiremental releases for people.
5822017-07-27T19:44:12  <gmaxwell> There are some political implications, since getting adoption of SW
5832017-07-27T19:44:14  <gmaxwell> will tone down some mania in the industry.
5842017-07-27T19:44:31  <jonasschnelli> Agree
5852017-07-27T19:44:37  <BlueMatt> seems reasonable
5862017-07-27T19:44:47  <BlueMatt> i vote for at 15.segwit
5872017-07-27T19:44:53  <achow101> perhaps start off by giving out the p2sh nested addresses first and then move on to bech32?
5882017-07-27T19:44:55  <wumpus> no problem with doing 0.16 faster (create a specific segwit-themed feature release, if it is realistic to do it in less than 6 months but still takes significant time (say, 3 months)
5892017-07-27T19:45:02  <gmaxwell> Well I threw out two ideas: 0.16 fast and 0.15+segwit as a seperate downloadable thing...
5902017-07-27T19:45:19  <achow101> why not just a 0.15.x release?
5912017-07-27T19:45:26  <jonasschnelli> So 0.15.1 + 0.15.1+SW?
5922017-07-27T19:45:26  <gmaxwell> achow101: the point on 173 is support for sending to. We likely wouldn't actually issue those addresses for >1 year.
5932017-07-27T19:45:28  <wumpus> achow101: it's a feature
5942017-07-27T19:45:31  * BlueMatt would be somewhat dissapointed to see a full release number for such a small set of changes
5952017-07-27T19:45:38  <BlueMatt> 15.segwit seems reasonable, while working on 16 still
5962017-07-27T19:45:49  <gmaxwell> If we did 0.15+sw as a full release we should call that 0.16. But thats just a naming thing.
5972017-07-27T19:45:55  <wumpus> so is it really a small set of changes? or are you underestimating it?
5982017-07-27T19:45:56  <BlueMatt> well, ok
5992017-07-27T19:45:59  <jtimon> achow101: yeah, wondering the same
6002017-07-27T19:46:08  <gmaxwell> but we could also release it as 0.15+expiremental segwit, an explicit alternative.
6012017-07-27T19:46:09  <BlueMatt> point being lets not freeze master again soon just for this
6022017-07-27T19:46:24  <BlueMatt> gmaxwell: all you're saying is support sending to segwit addresses, right?
6032017-07-27T19:46:34  <BlueMatt> not gui showing them as a receive address?
6042017-07-27T19:46:54  <gmaxwell> BlueMatt: if we do BIP173 support it would just be sending to.
6052017-07-27T19:46:56  <wumpus> yeah full GUI support is significant work
6062017-07-27T19:47:10  <BlueMatt> wumpus: hmm?
6072017-07-27T19:47:20  <BlueMatt> i mean we're just talking about a send-only address format, no?
6082017-07-27T19:47:26  <gmaxwell> There are two questions:  segwit wallet, and sending to BIP173. I consider the second less important, it's also more work (because it isn't already dormant in the codebase).
6092017-07-27T19:47:39  <wumpus> it's very easy to underestimate the changes needed, the tests, reviews, iterations
6102017-07-27T19:47:49  <achow101> gmaxwell: what do you mean by segwit wallet?
6112017-07-27T19:47:52  <jtimon> well, with the short release (let's say, 3 months) we don't necessarily need to "freeze master", those would be just high priority features for the release but we can still keep doing other things, no?
6122017-07-27T19:48:03  <gmaxwell> Segwit wallet basically means making getnewaddress return p2sh embedded segwit addresses.
6132017-07-27T19:48:14  <gmaxwell> (and the GUI of course)
6142017-07-27T19:48:15  <BlueMatt> mmm, yea, thats...trickier
6152017-07-27T19:48:28  <gmaxwell> BlueMatt: well technically it's just a few lines changed, if we ignore the testing burden. :)
6162017-07-27T19:48:37  <BlueMatt> heh, yea, well testing
6172017-07-27T19:48:45  <wumpus> building it on top of 0.15 and calling it 0.16 that's possible too, though a big change from how releases have always been done
6182017-07-27T19:48:52  <gmaxwell> because the wallet does support segwit today... just doesn't use it without dorking with the rpc.
6192017-07-27T19:48:55  <wumpus> would be the first major release not branched from master
6202017-07-27T19:49:02  <BlueMatt> i mean its not a 2 week project, but i also dont think its worth freezing master to do it (and given it'd be nice to get it out, it'd be nice to have *only* it as changes)
6212017-07-27T19:49:23  <wumpus> and it still needs to land in master anyhow, no way around that
6222017-07-27T19:49:23  * BlueMatt is fine with calling it 0.15.1, fwiw
6232017-07-27T19:49:31  <gmaxwell> And in _theory_ the segwit support in the wallet is "tested".
6242017-07-27T19:49:38  <jtimon> yeah, nack on working on 0.15 and calling it 0.16, why not simply 0.15.1 ?
6252017-07-27T19:49:49  <gmaxwell> So there is a scope question and a naming question. Lets not conflate them.
6262017-07-27T19:50:03  <BlueMatt> fair, scope wise lets not creep
6272017-07-27T19:50:08  <BlueMatt> which means keep it on the 15 branch
6282017-07-27T19:50:19  <BlueMatt> naming, i dont feel strongly about, either way wfm
6292017-07-27T19:50:36  <wumpus> ok
6302017-07-27T19:50:46  <jonasschnelli> would the 0.15.SW always generate p2sh embedded sw addresses or optional?
6312017-07-27T19:51:00  <BlueMatt> by default, i assume
6322017-07-27T19:51:04  <gmaxwell> So there are two things I think are potential for scope, SW wallet (getnewaddress returns p2sh embedded SW), and BIP173 sending.  We don't have to do them at the same time but it would be nice to be able to say that any SW enabled wallet can send to 173 style addresses.
6332017-07-27T19:51:24  <gmaxwell> jonasschnelli: I assume we'd make it gated by a config option like usehd.
6342017-07-27T19:51:40  <gmaxwell> Unless we ran into hairballs that we couldn't resolve.
6352017-07-27T19:51:42  <jtimon> if the scope is smal it seems reasonable to do it on 0.15.1/0.15.segwit
6362017-07-27T19:51:46  <wumpus> it certainly needs to be optional, default behavior can't change in a minor version
6372017-07-27T19:51:48  <jonasschnelli> BIP173 sending only is kinda hard(er) to test without the rec. part
6382017-07-27T19:52:14  <jonasschnelli> wumpus: Yes. That makes sense
6392017-07-27T19:52:33  <gmaxwell> jonasschnelli: we can recieve BIP173 payments with some hidden options. (I believe the code is still there-- we have tests for that already)
6402017-07-27T19:52:33  <wumpus> sending obvs is optional in itself, you don't *need* tos send to BIP173 addresses, and if you do you know what you're doing. I mean about receiving.
6412017-07-27T19:53:09  <gmaxwell> jonasschnelli: BIP173 is native segwit, we have tests for native segwit... what BIP173 adds is just an address encoding for it, so that it can be made user accessible.
6422017-07-27T19:53:26  <jonasschnelli> Indeed
6432017-07-27T19:53:40  <gmaxwell> But actually generating 173 addresses won't be useful for a long time... since you don't want to do that until basically everyone can send to it, took 2-3 years for p2sh.
6442017-07-27T19:53:50  <wumpus> creating bip173 receiving addresses should be optional, to not confuse too much, especially as long as vrutally no other wallets have support for it
6452017-07-27T19:54:39  <gmaxwell> I could see 173 adoption going faster, but it'll still take a while, and I don't see any reason to push it. But we should get started soon.
6462017-07-27T19:54:53  <wumpus> yes
6472017-07-27T19:54:59  <gmaxwell> (also pushing for rapid 173 adoption has a downside of making people think it's needed for segwit, it's not)
6482017-07-27T19:56:06  <wumpus> so anyhow, we'll branch off a special branch from 0.15 after the 0.15.0 release, for this work to be done?
6492017-07-27T19:56:31  <gmaxwell> I would be okay with that. We don't need to decide quite yet, but I wanted to get people thinking about it.
6502017-07-27T19:56:41  <jtimon> so what about 0.15.1 -> segwit wallet, 0.15.2 - > send to bip173, optionally receive ?
6512017-07-27T19:56:44  <BlueMatt> wumpus: that seems reasonable to me, ultimately i dont care too much and its up to you
6522017-07-27T19:56:44  <wumpus> or, I guess development could still be done on master w/ backports as normal
6532017-07-27T19:56:53  <BlueMatt> oh, yea, I'd vote backports
6542017-07-27T19:56:58  <gmaxwell> wumpus: that would be better IMO
6552017-07-27T19:57:04  <BlueMatt> whether its on the 15 branch or on a 15.segwit branch I dont care
6562017-07-27T19:57:05  <achow101> ack backports
6572017-07-27T19:57:06  <wumpus> (in the other case you'd have to forward-port)
6582017-07-27T19:57:09  <achow101> so we can have it in 0.16 too
6592017-07-27T19:57:50  <wumpus> yes
6602017-07-27T19:58:08  <gmaxwell> I really think the segwit-wallet part will be pretty minimal effort, except perhaps for more testing... just because it's virtually already done.
6612017-07-27T19:58:43  <jtimon> 2 mins
6622017-07-27T19:58:51  <wumpus> I was thinking people wanted to work on the 0.15 branch for a moment, which would make sense if we expect master/0.16 to drift apart very quickly, but I don't think that's very true for the wallet (though there's more multi-wallet changes waiting for merge after the branch)
6632017-07-27T19:59:01  <gmaxwell> But who knows whatever dusty corners we'll expose.
6642017-07-27T19:59:18  <gmaxwell> wumpus: well it might favor delaying some 0.16 development to happen after this.
6652017-07-27T19:59:27  *** fronti has joined #bitcoin-core-dev
6662017-07-27T19:59:34  <wumpus> but forward and backporting isn't much different effort and it has to end up in master too
6672017-07-27T19:59:39  <gmaxwell> but I don't think there are many PRs already open that would get in the way.
6682017-07-27T19:59:49  <jonasschnelli> What about delaying 0.15 for P2SH(P2WPKH) support?
6692017-07-27T19:59:54  <wumpus> gmaxwell: in that case we're doing the 0.16 freeze that BlueMatt didn't want :)
6702017-07-27T19:59:58  <gmaxwell> jonasschnelli: I'd rather not.
6712017-07-27T20:00:13  <wumpus> I'd also prefer not
6722017-07-27T20:00:15  <wumpus> 0.15 is almost ready
6732017-07-27T20:00:17  <gmaxwell> jonasschnelli: if we wanted to do that, I'd rather we just do 0.15 and then release 0.16 a couple weeks later with it.
6742017-07-27T20:00:24  <wumpus> 0.15.1 is better
6752017-07-27T20:00:38  <jonasschnelli> Okay
6762017-07-27T20:00:56  <wumpus> would be very bad to delay 0.15.0 on a *feature* now, so long after the feature freeze
6772017-07-27T20:01:02  <wumpus> espeically one that doens't even have a PR open
6782017-07-27T20:01:08  *** timothy has joined #bitcoin-core-dev
6792017-07-27T20:01:13  <BlueMatt> *DONG*
6802017-07-27T20:01:16  <wumpus> #endmeeting
6812017-07-27T20:01:16  <lightningbot> Meeting ended Thu Jul 27 20:01:16 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6822017-07-27T20:01:16  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.html
6832017-07-27T20:01:16  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.txt
6842017-07-27T20:01:16  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.log.html
6852017-07-27T20:01:21  <gmaxwell> we ran over!
6862017-07-27T20:01:30  <wumpus> shit
6872017-07-27T20:01:59  <jtimon> yeah, nack on delaying 0.15
6882017-07-27T20:02:00  <BlueMatt> well, clearly we have failed, we should give up having meetings
6892017-07-27T20:02:24  <gmaxwell> that meeting was invalid, gonna have to drop it and make a new one
6902017-07-27T20:02:25  <achow101> so about the large chainstate I have, here's the pastebin in case you missed it: https://pastebin.com/hAeYMjRW
6912017-07-27T20:02:29  <wumpus> we should have a meeting about better timing of meetings
6922017-07-27T20:02:42  <wumpus> achow101: ah yes, thanks, forgot about that one
6932017-07-27T20:02:56  *** fydel has joined #bitcoin-core-dev
6942017-07-27T20:03:11  <gmaxwell> BlueMatt: so why do you think it's not a two week project.. barring testing, I think we just shim getnewaddress to add the witness address. And then it will just work(tm).
6952017-07-27T20:03:19  <wumpus> achow101: .fuse_hidden files?!
6962017-07-27T20:03:26  <achow101> dunno wtf those are
6972017-07-27T20:03:30  <BlueMatt> gmaxwell: i dunno, i dont expect anything to get done in 2 weeks
6982017-07-27T20:03:50  *** ndrst has joined #bitcoin-core-dev
6992017-07-27T20:03:52  <BlueMatt> gmaxwell: just review of wallet stuff is usually slow, plus testing and release cycle
7002017-07-27T20:03:52  <wumpus> achow101: what size do you get if you only measure LOG and .ldb files?
7012017-07-27T20:03:55  <gmaxwell> BlueMatt: well sure, but I think it's like a 1 day change plus N weeks of discussion and tweaking.
7022017-07-27T20:04:05  <wumpus> achow101: I think those are your junk files
7032017-07-27T20:04:26  <wumpus> achow101: fuse_hidden files are part of filesystem management anyhow, not of the leveldb database
7042017-07-27T20:04:30  *** fronti has left #bitcoin-core-dev
7052017-07-27T20:04:39  <BlueMatt> gmaxwell: yea, that
7062017-07-27T20:04:44  <gmaxwell> BIP173 is worse becuase it's just not implemented at all... I wouldn't even suggest it except for the nice property of being able to say "any segwit version can send to BC addresses".
7072017-07-27T20:04:46  <wumpus> achow101: sometimes they're left behind
7082017-07-27T20:04:47  *** goto_ has joined #bitcoin-core-dev
7092017-07-27T20:04:47  *** arowser has quit IRC
7102017-07-27T20:04:49  <jcorgan> what fs is dir in
7112017-07-27T20:04:49  <achow101> oh
7122017-07-27T20:05:27  <wumpus> sshfs?
7132017-07-27T20:05:33  <achow101> it's 5.8 of .ldb files
7142017-07-27T20:05:39  <achow101> *5.8 GB
7152017-07-27T20:06:14  <wumpus> achow101: that's more or  less the normal size after upgrade and before compaction
7162017-07-27T20:07:07  <gmaxwell> oh you said 8GB before, which was concerning.
7172017-07-27T20:07:08  *** Chris_Stewart_5 has quit IRC
7182017-07-27T20:07:09  <achow101> yeah, that makes sense
7192017-07-27T20:07:17  <achow101> gmaxwell: that's the entire chainstate folder
7202017-07-27T20:07:29  <gmaxwell> hm my entire chainstate folder is 5.8
7212017-07-27T20:07:30  <achow101> jcorgan: I think its an NTFS drive
7222017-07-27T20:07:36  <jcorgan> ah ok
7232017-07-27T20:07:48  <jcorgan> so ntfs-fuse then
7242017-07-27T20:07:50  <achow101> (I use it with windows occasionally)
7252017-07-27T20:07:53  <BlueMatt> ntfs? eww
7262017-07-27T20:08:02  <achow101> it started out as a windows drive
7272017-07-27T20:08:04  <wumpus> gmaxwell: it turns out to be full of fuse fs ghost files
7282017-07-27T20:08:11  <achow101> too lazy to change it
7292017-07-27T20:08:29  <jcorgan> those .fuse_hidden files are files deleted but someone still has an open file handle to it
7302017-07-27T20:08:42  <wumpus> I also had my datadir for one node on a ntfs-formatted external HDD for a long time, it seems to work surprisingly well
7312017-07-27T20:08:46  <gmaxwell> zoinks, well thats one mystery solved.
7322017-07-27T20:08:57  <achow101> jcorgan: can they be safely deleted?
7332017-07-27T20:08:58  <wumpus> jcorgan: yep, and sometimes it forgets about them and leaves them behind
7342017-07-27T20:09:05  <jcorgan> yes and yes
7352017-07-27T20:09:24  <wumpus> achow101: yes, maybe close bitcoind first just in case
7362017-07-27T20:09:30  <achow101> too late
7372017-07-27T20:09:46  <wumpus> (nothing *else* will be holding on handles to the chainstate files)
7382017-07-27T20:10:08  <jcorgan> the dates on those were from last september, you've probably rebooted since then :)
7392017-07-27T20:10:10  *** jtimon has quit IRC
7402017-07-27T20:10:18  <wumpus> lol, yes
7412017-07-27T20:10:32  <achow101> I probably have. uptime says 43 days
7422017-07-27T20:10:48  <wumpus> or at least restarted bitcoind
7432017-07-27T20:11:13  <jcorgan> yeah, then they were just a bunch of fuse turds
7442017-07-27T20:11:35  *** arowser has joined #bitcoin-core-dev
7452017-07-27T20:11:37  <achow101> so how about compacting the database after upgrade (and not upgrading with 10526)?
7462017-07-27T20:11:56  <achow101> or is that "you did something stupid so deal with it yourself" kind of thing?
7472017-07-27T20:12:18  *** Yogaqueef has joined #bitcoin-core-dev
7482017-07-27T20:12:30  <wumpus> achow101: gmaxwell was talking about adding a hidden RPC to do database compactions, seems like a reasonable idea
7492017-07-27T20:12:58  <achow101> would it be a bad idea to just compact every startup?
7502017-07-27T20:13:04  <wumpus> yes, slow
7512017-07-27T20:13:15  <achow101> I figured
7522017-07-27T20:13:39  <wumpus> leveldb does it automatically once in a while anyway
7532017-07-27T20:13:49  <wumpus> (depending on some metric)
7542017-07-27T20:14:17  <wumpus> normally you shouldn't want to bother with it, unless you just rewrote the entire database like with the upgrade
7552017-07-27T20:20:44  *** testeriknl has joined #bitcoin-core-dev
7562017-07-27T20:25:37  <morcos> Murch: how deterministic is the existing coin selection algorithm?  if you call it twice with the same nValueToSelect, how likely is it to return the same inputs?
7572017-07-27T20:28:26  *** J-wolf has joined #bitcoin-core-dev
7582017-07-27T20:30:39  <Murch> morcos: I have not explicitly checked that, but since it heavily biases towards the largest input available and removes the last when it overshoots, my gut feeling would be that the vast majority of the 1000 attempts would get the same result.
7592017-07-27T20:32:00  <Murch> or at least the vast majority would reach a very small set of results.
7602017-07-27T20:33:01  <morcos> ok, thanks, i'm just looking at #10034 and there is a some braindead behavior where we stupidly call SelectCoins a second time for no reason if we are subtracting from recipient
7612017-07-27T20:33:03  <gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
7622017-07-27T20:33:08  <Murch> ~50% of the results include the first utxo below target for starters. 25+% include the second utxo (depending on whether the first and second both fit at the same time)
7632017-07-27T20:33:49  <morcos> but i'm not seeing why it would consistently lead to significant overpaying
7642017-07-27T20:34:17  <Murch> morcos: The overpaying behavior comes from locking in the expected fees from the previous run.
7652017-07-27T20:34:49  <morcos> Murch: yes i'm aware of that problem, but that should be quite rare, not something that is seen over and over again
7662017-07-27T20:35:18  <morcos> and should be even less likely with subtractfeefromamount, b/c then you are trying to select the same value on the second run, so unlikly to choose far fewer inputs
7672017-07-27T20:37:44  *** goto_ has left #bitcoin-core-dev
7682017-07-27T20:39:23  <Murch> morcos:  every time when one round fails for selecting too little fees and then the next one succeeds with fewer inputs.
7692017-07-27T20:39:42  <sipa> so i think #10924 should be tagged for 0.15; i'll update with some more information
7702017-07-27T20:39:43  <gribble> https://github.com/bitcoin/bitcoin/issues/10924 | [RPC][Wallet][Segwit] Bug: Transaction sent to imported P2WSH does not appear in listtransaction. · Issue #10924 · bitcoin/bitcoin · GitHub
7712017-07-27T20:40:02  <sipa> it's possible to make gettransaction and listtransactions output diverge
7722017-07-27T20:40:05  <Murch> I think you changed something that took a minimal amount of fee from the change output when too little fee was selected. That should fix it. right?
7732017-07-27T20:41:00  <sipa> by importing a native segwit output script with importaddress, it getd detected as an ismine transaction, but the receiving end is treated as change
7742017-07-27T20:41:01  <morcos> Murch: my fixes didn't apply when you were subtracting fees from recipients, but in theory that case is the simplest to solve, just subtract fee from recipients. :)  But not sure we need that now for 0.15 or not
7752017-07-27T20:41:37  <Murch> morcos: I described the original problem on page twenty in my thesis: http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf
7762017-07-27T20:41:56  <sipa> the fix for #10924 is easy: we need to add P2WSH/P2WPKH to CTxDestination, which is needed anyway for bip173 support
7772017-07-27T20:41:57  <gribble> https://github.com/bitcoin/bitcoin/issues/10924 | [RPC][Wallet][Segwit] Bug: Transaction sent to imported P2WSH does not appear in listtransaction. · Issue #10924 · bitcoin/bitcoin · GitHub
7782017-07-27T20:42:57  <Murch> I seem to remember that you fixed at least the accumulative fee issue, but I'm not sure.
7792017-07-27T20:44:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7802017-07-27T20:44:59  *** treebeardd has joined #bitcoin-core-dev
7812017-07-27T20:52:22  *** treebeardd has quit IRC
7822017-07-27T20:54:59  *** J-wolf has quit IRC
7832017-07-27T20:55:00  *** jtimon has joined #bitcoin-core-dev
7842017-07-27T20:56:30  *** treebeardd has joined #bitcoin-core-dev
7852017-07-27T20:59:14  *** J-wolf has joined #bitcoin-core-dev
7862017-07-27T20:59:29  *** promag has joined #bitcoin-core-dev
7872017-07-27T20:59:37  <MarcoFalke> happy editing: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.15.0-Release-notes
7882017-07-27T21:00:07  <promag> wumpus: should I make the change https://github.com/bitcoin/bitcoin/pull/10885#issuecomment-318478956 ?
7892017-07-27T21:04:28  *** treebeardd has quit IRC
7902017-07-27T21:06:15  *** treebeardd has joined #bitcoin-core-dev
7912017-07-27T21:09:10  *** praxeology has joined #bitcoin-core-dev
7922017-07-27T21:10:29  *** J-wolf has quit IRC
7932017-07-27T21:21:44  *** J-wolf has joined #bitcoin-core-dev
7942017-07-27T21:27:49  <bitcoin-git> [bitcoin] morcos opened pull request #10942: Eliminate fee overpaying edge case when subtracting fee from recipients (master...subtractfee) https://github.com/bitcoin/bitcoin/pull/10942
7952017-07-27T21:30:33  *** Guyver2 has quit IRC
7962017-07-27T21:31:26  *** J-wolf has quit IRC
7972017-07-27T21:34:57  *** Chris_Stewart_5 has quit IRC
7982017-07-27T21:40:20  <promag> morcos: is fSubtractFeeFromAmount something really used?
7992017-07-27T21:40:43  <gmaxwell> Yes, people use it.
8002017-07-27T21:41:17  <gmaxwell> It's a pretty useful way, for example, to transfer funds to another account you control; like an exchange, when you want to spend a given amount.
8012017-07-27T21:42:42  <promag> ah I see, ty
8022017-07-27T21:45:53  <promag> however we could do the same without having that hassle in the algorithm: do as normal and then subtract the fee from those outputs and add it to the change
8032017-07-27T21:46:39  <gmaxwell> promag: one of the applications is completely emptying a wallet.
8042017-07-27T21:47:03  <gmaxwell> without subtract fee from amount there is basically no way to do that (other than manually with raw transactions)
8052017-07-27T21:47:29  <promag> I surrender
8062017-07-27T21:47:37  <gmaxwell> :)
8072017-07-27T21:47:47  <gmaxwell> It's a good instinct to want to simplify.
8082017-07-27T21:48:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8092017-07-27T21:48:16  <promag> it would be nice to have a test failing before https://github.com/bitcoin/bitcoin/pull/10942/files
8102017-07-27T21:48:47  <promag> I wonder if morcos is able to reproduce
8112017-07-27T21:52:58  <morcos> promag: irrelevangt of whether this fixes a bug or not, its a better design to just pick the inputs once and then subtract the fee.  That's what this PR accomplishes
8122017-07-27T21:53:23  <morcos> granted it does it in a kind of roundabout way, but all this code is going in the rubbish bin the day 0.15 is released
8132017-07-27T21:53:39  <morcos> so no reason to go crazy trying to make it pretty right now
8142017-07-27T21:53:55  *** Yogaqueef has quit IRC
8152017-07-27T21:53:57  <promag> yeah dejavu
8162017-07-27T21:54:41  <morcos> even if it doesn't look better, the logic is far clearer and smarter now than it was in 0.14
8172017-07-27T21:55:03  *** jeep-ss has joined #bitcoin-core-dev
8182017-07-27T22:02:27  *** Dizzle has quit IRC
8192017-07-27T22:03:46  <promag> morcos: some comments
8202017-07-27T22:11:47  *** Chris_Stewart_5 has quit IRC
8212017-07-27T22:18:35  *** vicenteH has quit IRC
8222017-07-27T22:20:16  *** ula has quit IRC
8232017-07-27T22:23:00  *** testeriknl has quit IRC
8242017-07-27T22:25:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8252017-07-27T22:25:13  *** belcher has joined #bitcoin-core-dev
8262017-07-27T22:27:45  *** ula has joined #bitcoin-core-dev
8272017-07-27T22:28:16  *** Eagle[TM] has joined #bitcoin-core-dev
8282017-07-27T22:29:26  *** EagleTM has quit IRC
8292017-07-27T22:29:45  *** Murch has quit IRC
8302017-07-27T22:30:25  *** Chris_Stewart_5 has quit IRC
8312017-07-27T22:37:39  *** echonaut has quit IRC
8322017-07-27T22:38:11  *** clarkmoody_ has joined #bitcoin-core-dev
8332017-07-27T22:38:11  *** snkey has joined #bitcoin-core-dev
8342017-07-27T22:42:04  *** lightningbot has joined #bitcoin-core-dev
8352017-07-27T22:42:12  *** achow101 has joined #bitcoin-core-dev
8362017-07-27T22:42:26  *** jeremyru1in has joined #bitcoin-core-dev
8372017-07-27T22:42:31  *** kinlo has quit IRC
8382017-07-27T22:42:35  *** zxzzt_ has joined #bitcoin-core-dev
8392017-07-27T22:42:37  *** jrayhawk_ has joined #bitcoin-core-dev
8402017-07-27T22:42:39  *** kinlo has joined #bitcoin-core-dev
8412017-07-27T22:42:42  *** earlz has joined #bitcoin-core-dev
8422017-07-27T22:42:42  *** berndj has quit IRC
8432017-07-27T22:42:43  *** harding has quit IRC
8442017-07-27T22:42:44  *** tucenaber has quit IRC
8452017-07-27T22:42:46  *** gribble has quit IRC
8462017-07-27T22:42:49  *** jeremyrubin has quit IRC
8472017-07-27T22:42:49  *** luke-jr has quit IRC
8482017-07-27T22:42:49  *** cryptapus has quit IRC
8492017-07-27T22:42:50  *** zxzzt has quit IRC
8502017-07-27T22:42:50  *** jrayhawk has quit IRC
8512017-07-27T22:42:50  *** newbie-- has quit IRC
8522017-07-27T22:42:52  *** stick` has quit IRC
8532017-07-27T22:42:56  *** lukedashjr has joined #bitcoin-core-dev
8542017-07-27T22:42:58  *** Murch has quit IRC
8552017-07-27T22:42:59  *** Victorsueca has joined #bitcoin-core-dev
8562017-07-27T22:43:02  *** berndj has joined #bitcoin-core-dev
8572017-07-27T22:43:25  *** snq has quit IRC
8582017-07-27T22:43:28  *** Guest92337 has quit IRC
8592017-07-27T22:43:36  *** haakonn has joined #bitcoin-core-dev
8602017-07-27T22:43:40  *** echonaut has joined #bitcoin-core-dev
8612017-07-27T22:43:46  *** newbie-- has joined #bitcoin-core-dev
8622017-07-27T22:44:00  *** haakonn is now known as Guest66563
8632017-07-27T22:44:51  *** Dyaheon has quit IRC
8642017-07-27T22:46:50  *** lukedashjr is now known as luke-jr
8652017-07-27T22:47:21  *** Murch has joined #bitcoin-core-dev
8662017-07-27T22:47:31  *** gribble has joined #bitcoin-core-dev
8672017-07-27T22:48:36  *** Dyaheon has joined #bitcoin-core-dev
8682017-07-27T22:48:58  *** harding has joined #bitcoin-core-dev
8692017-07-27T22:51:18  *** str4d has joined #bitcoin-core-dev
8702017-07-27T23:04:41  *** promag has left #bitcoin-core-dev
8712017-07-27T23:10:10  *** jamesob has quit IRC
8722017-07-27T23:45:00  *** veleiro has quit IRC
8732017-07-27T23:46:29  *** treebeardd has quit IRC
8742017-07-27T23:59:42  *** abpa has quit IRC