--- Day changed Thu Jul 27 2017
00:21 < luke-jr> gmaxwell: it's because git decided to change git-archive output in some recentish version
00:21 < luke-jr> they made the substituted hash abbreviation longer
00:21 < luke-jr> wumpus: the stable tarballs are missing a bunch of stuff still :/
00:22 < sipa> luke-jr: like?
00:22 < gmaxwell> how could they be missing stuff ... they're just make dists
00:23 < luke-jr> sipa: https://github.com/bitcoin/bitcoin/issues/6753
00:23 < luke-jr> gmaxwell: `make dist` is missing the files
00:23 < gmaxwell> Only in from-git/: .gitattributes
00:23 < gmaxwell> Only in from-git/: .gitignore
00:23 < gmaxwell> don't belong in the distribution
00:24 < sipa> how does git checkdist succeed if things are missing?
00:24 < sipa> or distcheck
00:24 < gmaxwell> but the readmes and stuff are not good.
00:24 < sipa> ah, agree
00:25 < gmaxwell> should be trivial to add DISTFILES to the autotools stuff...
00:26 < luke-jr> IIRC there's a bunch of contrib now missing
00:26 < luke-jr> like init scripts and such
00:26 < luke-jr> haven't done a full check recently
00:26 < gmaxwell> why didn't you PR a fix
00:28 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 260 seconds]     
00:33 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
00:34 < luke-jr> I don't know a good solution
00:36 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
00:37 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev     
00:39 -!- Eagle[TM] [~EagleTM@x4db47f1f.dyn.telefonica.de] has quit [Ping timeout: 276 seconds]     
00:39 < gmaxwell> luke-jr: you list the files in EXTRA_DIST in makefile.am
00:39 < gmaxwell> (though don't add the git specific stuff)
00:41 < luke-jr> it's just going to get outdated again :/
00:42 < gmaxwell> luke-jr: thats what review is for.
00:42 < luke-jr> isn't there some way to get git to build the list?
00:42 < gmaxwell> among other things, we don't want every file in git to end up in the dist.
00:43 < luke-jr> the .git* files maybe not, but everything else we do
00:53 < 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.
00:55 < bitcoin-git> [bitcoin] vadimVoloshanov opened pull request #10940: Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/10940
00:55 < bitcoin-git> [bitcoin] fanquake closed pull request #10940: Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/10940
00:56 < luke-jr> gmaxwell: IMO the latter would be a bug.. source should be buildable even if modified
00:56 < luke-jr> looking at an updated list, the big things are subtrees..
00:57 < gmaxwell> well subtrees should be handled in their sub makefiles.
00:57 < luke-jr> https://0bin.net/paste/-R85vsle0Z7ygcL8#Hb9C8u3Y95x1d8iXMm3mC8oPrkZyrKO4tYoGT6UWZsC
00:58 < gmaxwell> luke-jr: does our dist tarball even build?!
01:06 < cfields> travis builds from tarball
01:06 < cfields> (or something close to it)
01:07 < 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
01:08 < cfields> that seems like more work to me, i'd rather just add "check for excluded files" as a step in the release process
01:08 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]     
01:08 < luke-jr> cfields: I'll do it
01:09 -!- J-wolf [~J-wolf@188.225.171.82] has joined #bitcoin-core-dev     
01:12 < gmaxwell> cfields: human steps get missed. (see also the last N RCs where versions didn't get bumped. :) )
01:13 < cfields> heh     
01:15 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Quit: Leaving]     
01:27 -!- miknotauro [~miknotaur@201.141.107.91] has quit [Ping timeout: 248 seconds]     
01:37 < wumpus> luke-jr: which files are missing that would be required for a distro?
01:38 < wumpus> and yes, the dist tarball builds
01:38 < wumpus> it works fine, there have been no complaints about it at all, except from luke-jr apparently
01:39 < wumpus> stuff not included is not part of 'make install', so generally not relevant to distros
01:39 < wumpus> (such as developer tools)
01:39 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:40 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 240 seconds]     
01:42 < 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)
01:42 < wumpus> if that's so, it should probably be part of 'make install'
01:43 < wumpus> if it's not installed somewhere, how aer people normally supposed to use it?
01:43 < gmaxwell> normally build instructions don't end up in make install though.. right.
01:43 < gmaxwell> er right?
01:43 < wumpus> that's maybe the only exception
01:44 < gmaxwell> development script would be another.
01:44 < 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
01:44 < gmaxwell> yes, linearize should get installed.
01:44 < wumpus> then it should be maintained and tested too
01:45 < gmaxwell> ya, and if it's not fool proof enough, thats a reason to not install it right now I guess.
01:45 < wumpus> most developer scripts make no sense if you don't have a git checkout
01:46 < wumpus> a lot even rely on it explicitly (to find the root for pulling transifex translations, for example)
01:46 < wumpus> in any case I think being somewhat selective about what to include in the dist is fine
01:47 < wumpus> though I agree just a git tarball would make things a lot easier
01:47 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
01:48 < 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.
01:48 < wumpus> well then
01:48 < wumpus> thinking of it, why don't we just skip the make dist and include everything
01:48 < wumpus> zip up the git repository
01:48 < wumpus> the tarball is the smallest file
01:48 < gmaxwell> the make dist eliminates the endusers need for a full and compatible autotools setup.
01:48 < wumpus> it's not like we have to worry about a few extra source files in the downlaod or storage
01:49 < wumpus> wouldn't running autogen.sh before zipping uphave the same effect?
01:49 < wumpus> (maybe with some special options)
01:49 < gmaxwell> Yes +/- some temp files I think autogen leaves behind.
01:49 < wumpus> we efiniltely don't need the selective part of 'make dist' then
01:50 < wumpus> yes, well that's not too bad
01:50 < gmaxwell> I don't think I have know any counterarguments to that point.
01:51 < gmaxwell> maybe someone who knows autotools better would be aware of something we're missing.
01:51 < wumpus> it would be the minimum energy expenditure to finally getting this discussion out of the way at least
01:53 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
01:54 < wumpus> I am kind of surprised verify-binaries isn't included
01:55 < wumpus> cfields: any reason not to do the above? e.g. make the tarball simply a repo dump + build system autogenerated files 
01:55 < 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.
01:55 < cfields> wumpus: i suppose that's fine
01:56 < wumpus> otherwise we're bound to forget things and have this "the tarball is useless!" discussion again and agian
01:56 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
01:56 < 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...
01:56 < cfields> but with our build process, it's really kinda moot
01:57 < wumpus> which could also be avoided by taking the snapshot before starting building
01:57 < wumpus> yeah
01:57 < cfields> yea, tar it up after bootstrap but before anything else
01:59 < 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.
02:00 < luke-jr> fixing make dist is proving to be a real pain (hi depends/ … ) so I like the idea of not using it
02:00 < wumpus> depends/ is another joy in that regard, yes :)
02:00 < cfields> agreed
02:01 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
02:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:13 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds]     
02:34 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
02:38 < 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
02:38 < wumpus> there's no point in talking about a specific client in server error messages
02:39 < wumpus> that's just wrong, and won't help someone struggling with this interface in say python-bitcoinrpc
02:39 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]     
02:40 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
02:42 < wumpus> why is it so much to ask that documentation for bitcoin-cli arguments belongs in bitcoin-cli?
02:46 < wumpus> it doesn't belong in two places, no it just belongs in bitcoin-cli
02:54 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:56 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
02:57 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]     
03:03 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]     
03:11 < wumpus> gah, coredev.tech is september, scaling bitcoin in november, both in SF area, would have been better to plan it closer together :/
03:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:13 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
03:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
03:22 < wumpus> phew, at least 'make dist' includes the function test suite
03:24 < sipa> wumpus: just stay :)
03:25 < wumpus> sipa: if it was a two weeks in between instead of two months I would
03:26 < sipa> yeah :)
03:28 < wumpus> indeed, the ESTA allows staying 90 days, so theoretically it'd be possible, but just too much hassle
03:35 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
03:45 -!- blisscan [5123d5a5@gateway/web/freenode/ip.81.35.213.165] has joined #bitcoin-core-dev     
03:48 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Ping timeout: 255 seconds]     
03:50 < jonasschnelli> wumpus: Yeah. The SB guy contacted me after I have booked the room.
03:50 < jonasschnelli> He asked to move it closer... :)
03:50 < jonasschnelli> But was already too late.
03:51 < jonasschnelli> Too bad he did not contact me before announcing the date
03:51 < jonasschnelli> I bet the knew weeks ago
03:53 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
04:08 -!- Giszmo [~leo@46.128.249.133.dynamic.cablesurf.de] has joined #bitcoin-core-dev     
04:11 < 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
04:14 < promag> #10941 makes sense right? should add tests for -walletnotify too right?
04:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10941 | Add blocknotify functional test by promag · Pull Request #10941 · bitcoin/bitcoin · GitHub
04:15 < wumpus> sure!
04:15 < promag> will do
04:15 < wumpus> ideally there should be tests for everything
04:16 < promag> right, makes reviewing easy
04:16 < promag> ideally changing code should have some impact in tests
04:17 < promag> most PR's don't change tests
04:18 < wumpus> right, apart from pure refactors and optimizations
04:19 < promag> even those
04:19 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5c8eb7916de7...8a99fe053a5d
04:19 < bitcoin-git> bitcoin/master f228b8e Marko Bencun: remove some unused functions...
04:19 < bitcoin-git> bitcoin/master 8a99fe0 Wladimir J. van der Laan: Merge #10501: remove some unused functions...
04:20 < wumpus> if the behavior stays the same, the tests can also stay the same
04:20 < bitcoin-git> [bitcoin] laanwj closed pull request #10501: remove some unused functions (master...unusedfuncs) https://github.com/bitcoin/bitcoin/pull/10501
04:21 -!- blisscan [5123d5a5@gateway/web/freenode/ip.81.35.213.165] has quit [Quit: Page closed]     
04:21 < promag> refactors can impact tests, for instance, a test uses a lib which has new signatures..
04:21 < promag> in terms of functional tests, yes you're right
04:23 < 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
04:25 < 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
04:31 < promag> right
04:31 -!- Giszmo [~leo@46.128.249.133.dynamic.cablesurf.de] has quit [Quit: Leaving.]     
04:31 < promag> I'm for sure interested in improve that
04:32 < promag> it's a great way to get deeper in the project
04:32 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
04:32 < wumpus> it'd need infrastructure, not so much coding work
04:32 < wumpus> with an available server it'd be quite easy to set it up
04:38 < jonasschnelli> promag: I could provide you the necessary infrastructure (server hosted remotly, ideally for test/benchmarks)
04:39 -!- Giszmo [~leo@2001:4c50:33e:9700:c041:5873:d545:a0ac] has joined #bitcoin-core-dev     
04:56 -!- coredump_ [~quassel@101.165.128.225] has joined #bitcoin-core-dev     
05:00 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8a99fe053a5d...ba1bbb049b8f
05:00 < bitcoin-git> bitcoin/master 72f0060 Dag Robole: Replace traditional for with ranged for in primitives
05:00 < bitcoin-git> bitcoin/master ba1bbb0 Wladimir J. van der Laan: Merge #10892: Replace traditional for with ranged for in block and transaction primitives...
05:01 < 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
05:03 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
05:09 -!- J-wolf [~J-wolf@188.225.171.82] has quit [Remote host closed the connection]     
05:14 -!- EagleTM [~EagleTM@x4db47f1f.dyn.telefonica.de] has joined #bitcoin-core-dev     
05:16 -!- J-wolf [~J-wolf@188.225.171.82] has joined #bitcoin-core-dev     
05:18 -!- J-wolf [~J-wolf@188.225.171.82] has quit [Remote host closed the connection]     
05:20 -!- J-wolf [~J-wolf@188.225.171.82] has joined #bitcoin-core-dev     
05:20 -!- Dojixo [~Dojixo@197.51.107.144] has joined #bitcoin-core-dev     
05:28 -!- J-wolf [~J-wolf@188.225.171.82] has quit [Remote host closed the connection]     
05:31 -!- Blisscan [1f04ce3e@gateway/web/freenode/ip.31.4.206.62] has joined #bitcoin-core-dev     
05:31 -!- EagleTM [~EagleTM@x4db47f1f.dyn.telefonica.de] has quit []     
05:34 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 240 seconds]     
05:37 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire]     
05:50 -!- tucenaber [~tucenaber@o144.231.lokis.net.pl] has joined #bitcoin-core-dev     
05:50 -!- tucenaber [~tucenaber@o144.231.lokis.net.pl] has quit [Changing host]     
05:50 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-core-dev     
05:58 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:10 -!- coredump_ [~quassel@101.165.128.225] has quit [Ping timeout: 255 seconds]     
06:14 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev     
06:18 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
06:29 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
06:39 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
06:55 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
06:56 -!- johnpark_pj [~quassel@211.46.62.22] has quit [Read error: Connection reset by peer]     
06:56 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:57 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
06:59 -!- johnpark_pj [~quassel@211.46.62.22] has joined #bitcoin-core-dev     
07:03 -!- J-wolf [~J-wolf@188.225.171.82] has joined #bitcoin-core-dev     
07:03 -!- promag [~joao@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
07:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Quit: intcat]     
07:04 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 268 seconds]     
07:05 -!- J-wolf [~J-wolf@188.225.171.82] has quit [Remote host closed the connection]     
07:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:06 -!- J-wolf [~J-wolf@188.225.171.82] has joined #bitcoin-core-dev     
07:14 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:33 -!- iprokg [~Mutter@91.205.49.8] has joined #bitcoin-core-dev     
07:34 -!- J-wolf [~J-wolf@188.225.171.82] has quit [Remote host closed the connection]     
07:38 -!- iprokg [~Mutter@91.205.49.8] has quit [Client Quit]     
07:48 -!- promag [~joao@bl6-24-70.dsl.telepac.pt] has quit [Quit: Leaving.]     
07:50 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
07:54 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving]     
08:02 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds]     
08:04 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
08:09 -!- Blisscan [1f04ce3e@gateway/web/freenode/ip.31.4.206.62] has quit [Quit: Page closed]     
08:32 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Quit: Leaving.]     
08:33 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 276 seconds]     
08:37 -!- Drabiv [3e50a908@gateway/web/cgi-irc/kiwiirc.com/ip.62.80.169.8] has joined #bitcoin-core-dev     
08:41 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 260 seconds]     
08:42 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has quit [Ping timeout: 268 seconds]     
08:58 < 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.
08:59 < wumpus> at the least cookie authentication was already implemented, that's nice, used to be that it required always manually setting up the authentication
09:02 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
09:06 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has quit [Ping timeout: 246 seconds]     
09:12 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
09:14 -!- marcoagner [~user@187.113.148.71] has quit [Ping timeout: 248 seconds]     
09:15 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
09:17 -!- Orion3k [~Orion3k@gateway/vpn/privateinternetaccess/orion3k] has joined #bitcoin-core-dev     
09:21 -!- marcoagner [~user@187.113.148.71] has joined #bitcoin-core-dev     
09:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:23 -!- jb55 [~jb55@208.98.200.100] has quit [Quit: Lost terminal]     
09:28 -!- Orion3k [~Orion3k@gateway/vpn/privateinternetaccess/orion3k] has quit [Ping timeout: 255 seconds]     
09:35 -!- EagleTM [~EagleTM@x4db47f1f.dyn.telefonica.de] has joined #bitcoin-core-dev     
09:40 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
09:46 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Ping timeout: 264 seconds]     
09:52 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has joined #bitcoin-core-dev     
09:58 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ba1bbb049b8f...0b11a0784875
09:59 < bitcoin-git> bitcoin/master e526b3d Russell Yanofsky: Fix misleading "Method not found" multiwallet errors...
09:59 < bitcoin-git> bitcoin/master df389bc Russell Yanofsky: Change wallet method disabled error text...
09:59 < bitcoin-git> bitcoin/master 0b11a07 Wladimir J. van der Laan: Merge #10931: Fix misleading "Method not found" multiwallet errors...
09:59 < 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
10:07 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
10:09 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
10:12 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:14 -!- Dojixo [~Dojixo@197.51.107.144] has quit [Quit: Leaving]     
10:17 -!- Drabiv [3e50a908@gateway/web/cgi-irc/kiwiirc.com/ip.62.80.169.8] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
10:26 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
10:27 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 255 seconds]     
10:32 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
10:39 -!- eck [~eck@fsf/member/eck] has quit [Quit: poop]     
10:39 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
10:56 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
10:56 -!- J-wolf [~J-wolf@82.102.252.13] has joined #bitcoin-core-dev     
10:56 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:00 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:00 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
11:01 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev     
11:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
11:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
11:07 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has joined #bitcoin-core-dev     
11:08 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has quit [Changing host]     
11:08 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
11:09 -!- J-wolf [~J-wolf@82.102.252.13] has quit [Remote host closed the connection]     
11:24 -!- praxeology [~praxeolog@unaffiliated/praxeology] has left #bitcoin-core-dev []     
11:30 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Ping timeout: 264 seconds]     
11:31 -!- eck [~eck@fsf/member/eck] has quit [Quit: bye]     
11:31 < morcos> Can we merge #10758 before I fill up all my disks with genesis blocks?
11:31 < gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
11:32 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
11:36 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:36 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
11:37 < wumpus> morcos: and fix the error messages later? fine with me
11:44 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
11:54 < BlueMatt> wumpus: morcos lol, give me a few minutes, I'm testing the on-the-fly compaction stuff
11:54 < BlueMatt> (which, on my test system, reliably makes it worse....)
11:55 < gmaxwell> https://en.wikipedia.org/wiki/Repeated_sequence_(DNA)
11:55 < BlueMatt> ?     
11:57 < 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
11:57 -!- sam_c [~sam_c@unaffiliated/cmpct] has quit [Quit: ZNC - http://znc.in]     
11:58 < BlueMatt> ???     
11:59 < wumpus> probably responding to the genesis block that gets added again and again
11:59 -!- sam_c [~sam_c@unaffiliated/cmpct] has joined #bitcoin-core-dev     
11:59 < gmaxwell> yes     
11:59 < BlueMatt> ah     
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jul 27 19:00:27 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < jonasschnelli> hi     
12:00 < 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
12:00 < gmaxwell> achow101: 
12:00 < kanzure> hi.     
12:00 < jonasschnelli> +promag
12:00 < achow101> hi     
12:00 < morcos> here for 30
12:01 < Murch> hi     
12:01 < BlueMatt> oh, thats today?
12:01 < jtimon> hi     
12:01 < wumpus> I think it's most useful to discuss the still-open issues for 0.15 today
12:01 < wumpus> https://github.com/bitcoin/bitcoin/milestones/0.15.0
12:01 < jtimon> yep, sounds like a good first topic (that will probably take most of the meeting)
12:02 < wumpus> FWIW rc1 is planned for 2017-08-06
12:02 < wumpus> ok, I'll just follow the list
12:02 < wumpus> #topic test_bitcoin fails valgrind Tests (#9278)
12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9278 | test_bitcoin fails valgrind · Issue #9278 · bitcoin/bitcoin · GitHub
12:02 < wumpus> this is the oldest issue in the list
12:03 < achow101> I checked last week that this was still a problem
12:03 < wumpus> ok, so this still needs to be fixed?
12:03 < gmaxwell> cfields: are you working on that? if you don't have time, someone else can pick it up
12:03 < BlueMatt> its assigned cfields....
12:03 < achow101> it should probably be fixed, but I don't know if it is a blocker or how urgent a fix would be required
12:04 < morcos> He's only had 8 months cut him a break
12:04 < gmaxwell> Looks like it should be a trivial fix (famous last words)
12:04 < achow101> it was already pushed from 0.14 to 0.15, so I'm guessing it isn't all that urgent
12:04 < 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
12:04 < jonasschnelli> Yes. Moving to 0.16 would be possible.
12:04 < wumpus> though it might hide real issues
12:04 < wumpus> (if the tests are not valgrind clean)
12:05 < gmaxwell> I'm guessing cfields and sipa are not in the meeting today due to timezones.
12:05 < gmaxwell> I'll follow up and make sure it gets fixed (either extract something cfields hasn't submitted yet or fix it myself)
12:05 < wumpus> ok, thanks
12:05 < gmaxwell> (or realize it isn't actually trivial and ask for a punt to the next version)
12:05 < wumpus> #topic sendtoaddress subtractfeefromamount=true does not respect paytxfee values (#10034)
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
12:06 < 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
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9889 | TODO for release notes 0.15.0 · Issue #9889 · bitcoin/bitcoin · GitHub
12:06 < wumpus> I'm not sure about this one, don't think it has been looked at much
12:06 < wumpus> morcos: yes, good idea
12:06 < gmaxwell> Lets decide if we're doing the wiki or not, last time the wiki merge killed release notes written directly. :)
12:06 < wumpus> but it helped a lot with actually getting release notes written
12:07 < gmaxwell> I've held off on writing release notes due to lack of clarity on this point.
12:07 < wumpus> and getting the style consistent etc
12:07 < gmaxwell> I'm fine with doing it, I just need to know where to put them.
12:07 < wumpus> well right now you simply have to create a PR
12:07 < gmaxwell> I don't want to write any outside of the wiki if we're using the wiki.
12:07 < wumpus> as soon as the wiki is open, do it there
12:07 < 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
12:07 < gmaxwell> wumpus: I did that last time and they got stomped by the wiki merge. :)
12:08 < morcos> Let's do the wiki.
12:08 < jonasschnelli> +1     
12:08 < wumpus> gmaxwell: I know, we should avoid that, but that's no reason to completely abandon a good idea
12:08 < 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.
12:08 < gmaxwell> wumpus: I'm all for the wiki.
12:08 < achow101> we should do the wiki and probably open it now
12:08 < gmaxwell> Just someone point me to it and I'll write a bunch of release notes.
12:09 < 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
12:09 < achow101> +1     
12:09 < gmaxwell> that would help too.
12:09 < wumpus> (this was missing last time, so I had no reference point)
12:09 < wumpus> re: 10034, I'm not sure why that's labelled 0.15
12:09 < jtimon> wumpus: ack on commit id on the wiki
12:10 < kanzure> wumpus: if you mean github wiki, those are actually git repositories, so they do literally have forks/branches (even if github tosses them).
12:10 < achow101> is #10034 actually a problem or is it just an instance of an already known issue?
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
12:10 < 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
12:10 < wumpus> kanzure: true, you can fork and edit locally, but I mean the bitcoin core master revision
12:10 < wumpus> morcos: thanks
12:11 < jonasschnelli> Also, if 10034 is still a bug, it does not deserve the "medium" tag IMO
12:11 < gmaxwell> achow101: I think 10034 is the known thing that we fixed at least in the non-fee-from-value case.
12:11 < gmaxwell> jonasschnelli: Do you believe it deserves high.. overpaying fees should be high. IMO.
12:12 < morcos> gmaxwell: it seems to have some determinism in the description that bears a closer look.. but i'm not expecting to find anything
12:12 < wumpus> the dirty secret is that we don't really use the priority tags for issues/prs for anything :)
12:12 < jonasschnelli> heh     
12:12 < gmaxwell> yea...
12:12 < gmaxwell> morcos: thanks for looking at it.
12:13 < jtimon> priority medium seems specially useless, if it's not tagged low or high, then it's medium, no?
12:13 < wumpus> #topic Force on-the-fly compaction during pertxout upgrade  UTXO Db and Indexes (#10526)
12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa · Pull Request #10526 · bitcoin/bitcoin · GitHub
12:13 < gmaxwell> jtimon: untagged is a possible state (not evaluated yet).
12:14 < wumpus> jtimon: I think in practice only priority high could be useful, if someone paid attention to it
12:14 < gmaxwell> wumpus: as morocos noted on the PR, it's not shrinking on its own.
12:14 < gmaxwell> $ du -sh .
12:14 < gmaxwell> 5.8G    .
12:14 < wumpus> jtimon: then again, I think a year ago I checked "high priority" issues and some were >5 years old
12:14 < jtimon> gmaxwell: right, but then you have to tag them all with something about priority once you evaluate them
12:14 < 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)
12:15 < BlueMatt> gmaxwell: I believe it may clean it up over time, but not quickly
12:15 < 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. 
12:15 < 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
12:15 < gmaxwell> BlueMatt: I've had two weeks and many startup and shutdowns on this node... so ... really not quickly.
12:15 < wumpus> gmaxwell: it doesn't work reliably for me, no
12:16 < gmaxwell> wumpus: could it be what bluematt says.. it works but doesn't take effect until after another restart?
12:16 < BlueMatt> gmaxwell: see my later comment, i meant that it'll do it when tables fill, ie when you connect more blocks and so
12:16 < 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
12:16 < wumpus> gmaxwell: yes, that could well be
12:16 < 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.
12:17 < morcos> well if it consistently shrinks at the very latest after another restart, that's a clear improvement
12:17 < wumpus> well the, we should merge it, better is better
12:17 < BlueMatt> if we want we can probably simulate restart by closing and re-opening db :p
12:17 < morcos> needs a bug fix though, commented on pr
12:18 < wumpus> yes     
12:18 < 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)
12:18 < 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.
12:18 < achow101> I can test it too
12:18 < gmaxwell> uh.. 5GB disk space.
12:18 < wumpus> achow101: yes, please test
12:18 < gmaxwell> achow101: well it doesn't fix already bloated ones.
12:18 < BlueMatt> gmaxwell: yes, please note that on the release notes todo
12:18 < morcos> how'd you get 8.2, that's yuuuge
12:19 < achow101> i don't know
12:19 < gmaxwell> morcos: don't make fun of how I pronounce huge. :(
12:19 < BlueMatt> heh     
12:20 < 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)
12:20 < wumpus> 8.2 is definitely abnormal, if it's from a very old version maybe something left behind
12:20 < BlueMatt> gmaxwell: seems reasonable to me
12:20 < achow101> wumpus: its the same datadir from a 0.10 master that has been periodically upgraded over the years
12:20 < achow101> to different random master builds
12:21 < wumpus> (leveldb changed some things also, over time, e.g. the extension for database files at some point even)
12:21 < 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.
12:21 < wumpus> achow101: can you send me a pastebinned 'ls'?
12:21 < wumpus> zombie records, or zombie files even
12:22 < gmaxwell> achow101: you should also try gettxoutsetinfo to compare its hash with another non-bloaty host.
12:22 < wumpus> adding a hidden RPC to compact databases is fine with me
12:22 < gmaxwell> I think we know what to do to go forward on this one then.
12:22 < wumpus> ye     
12:22 < wumpus> #topic Fix some chainstate-init-order bugs (#10758)
12:22 < gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
12:22 < BlueMatt> lots of bugs, lots of complicated
12:23 < BlueMatt> #10919 fixes even more bugs!
12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
12:23 < wumpus> i think that one's ready for merge, I found some silly error message discrepancies but seems was re-pushed after
12:23 < BlueMatt> and has lots of more complicated
12:23 < achow101> wumpus: https://pastebin.com/hAeYMjRW
12:23 < gmaxwell> This is what fixes the genesis block grey goo?
12:23 < BlueMatt> gmaxwell: among other issues, yes
12:23 < wumpus> yep     
12:25 < gmaxwell> LGTM. I'll test it if it doesn't get merged first.
12:25 < wumpus> we'll get to 10919 later
12:25 < wumpus> #topic update assumevalid and minimum chain work (#10778)
12:25 < gribble> https://github.com/bitcoin/bitcoin/issues/10778 | update assumevalid and minimum chain work · Issue #10778 · bitcoin/bitcoin · GitHub
12:25 < BlueMatt> i guess only question is do we need be concerned about doing it pre-/post- fork(s), I think not
12:25 < wumpus> assigning that one to gmaxwell
12:25 < gmaxwell> wumpus: when do you want me to PR that.. I can do it at any time.
12:25 < wumpus> gmaxwell: asap imo
12:26 < BlueMatt> why not next week?
12:26 < achow101> best before august 1st?
12:26 < wumpus> BlueMatt: yes that is a good point
12:26 < BlueMatt> later the better
12:26 < gmaxwell> Generally the later the better.
12:26 < gmaxwell> But I don't want to miss it.
12:26 < BlueMatt> worst case it misses rc1 but makes it in for rc2
12:26 < wumpus> yes though I doubt a week makes that much difference, ignoring possible fork scenario
12:26 < gmaxwell> It needs review before merge (since you'll need to check it matches your chain)
12:26 < wumpus> yes, so please make a PR asap
12:26 < BlueMatt> true, i dont care, gmaxwell up to you
12:27 < wumpus> it can always be updated
12:27 < gmaxwell> Okay, I'll PR soon.
12:27 < wumpus> (maybe it has to be, if reveiewers have problems with it)
12:27 < wumpus> ok, thanks
12:27 < gmaxwell> A week makes a measureable amount of synctime difference, unfortunately. :(  but not enough to worry about debating it much. 
12:27 < gmaxwell> :)     
12:28 < jtimon> yep, later better, but merged better too
12:28 < 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
12:28 < wumpus> #topic Fix addwitnessaddress by replacing ismine with producesignature (#10788)
12:28 < gribble> https://github.com/bitcoin/bitcoin/issues/10788 | [RPC] Fix addwitnessaddress by replacing ismine with producesignature by achow101 · Pull Request #10788 · bitcoin/bitcoin · GitHub
12:29 < wumpus> this seems to require some work still, according to sdaftuar
12:29 < morcos> I just started looking at that one, but I like sipa's suggestion for addressing sdaftuars concern
12:29 < gmaxwell> Urgency of fixing it increased by probablity of segwit activation.
12:29 < achow101> I'm not exactly sure what sdaftuar is concerned about
12:29 < morcos> I haven't thought about the performance of any of these things
12:30 < morcos> achow101: just wants it to be clear what code is responsible for accomplishing what requirements
12:30 < gmaxwell> achow101: sounds like a general concern about the safty of further code changes.
12:30 < achow101> ah, I see. So sipa's suggestion should be fine
12:30 < morcos> functionally it'll be no different after change, but it'll be a lot harder to accidentally break
12:30 < achow101> right
12:30 < wumpus> being hard to accidentally break is good 
12:30 < gmaxwell> achow101: in addition to sipa's suggestion a strategic comment or two would help.
12:31 < gmaxwell> Purpose of source code is communication between programmers, after all.
12:31 < achow101> ok     
12:32 < wumpus> going to skip #10851, as cfields is not here and it's a build system issue
12:32 < gribble> https://github.com/bitcoin/bitcoin/issues/10851 | depends: bump fontconfig to 2.12.4 by theuni · Pull Request #10851 · bitcoin/bitcoin · GitHub
12:32 < jtimon> gmaxwell: isn't the purpose of source code that people can read it and learn how to program?
12:32 < wumpus> #topic Keypool topup (#10882)
12:32 < gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
12:32 < 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.
12:33 < wumpus> jtimon: no, of course not, the purpose is that they can copy it and change the attribution and claim it's theirs :-)
12:33 < gmaxwell> but it seems like people know what to do...
12:33 < gmaxwell> wumpus: lol
12:33 < jtimon> wumpus: lol
12:33 < achow101> lol     
12:33 < morcos> gmaxwell: i think 10882 is pretty much done
12:34 < BlueMatt> its very close, yes
12:34 < gmaxwell> \O/     
12:34 < gmaxwell> I'll review today.
12:34 < jonasschnelli> Great
12:34 < gmaxwell> (as an aside, I'm really happy that people found solutions to issues I raised that I had no idea how to fix)
12:35 < wumpus> ah the instructions for manual wallet top-up were added, great
12:35 < wumpus> yeah
12:35 < gmaxwell> (in particular the two thresholds, so you can bypass critical shutdown)
12:36 < wumpus> lol github things the diff of wallet.cpp is so huge it hides it by default
12:37 < gmaxwell> I hate that feature.
12:37 < jonasschnelli> Yes. Make searching really painful
12:37 < jonasschnelli> *Makes
12:37 < gmaxwell> Caused me to screw up reviews before.
12:37 < gmaxwell> (because I searched for X and then complained a PR couldn't work because it didn't touch X)
12:37 < BlueMatt> lol just dont review on github directly :)
12:37 < BlueMatt> next pr?
12:37 < 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
12:37 < gmaxwell>  obviously we need to split that file. :P
12:38 < gmaxwell> lets move on
12:38 < wumpus> #topic Reject invalid wallets (#10885)
12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/10885 | Reject invalid wallets by promag · Pull Request #10885 · bitcoin/bitcoin · GitHub
12:38 < BlueMatt> i think its good
12:38 < BlueMatt> i saw john's comments but havent had a chance to read the responses or do another review myself
12:38 < BlueMatt> but is also very close
12:39 < wumpus> yes, I think it's pretty close
12:39 < wumpus> I think what's left is mostly comments onthe tests
12:39 < BlueMatt> thats it, no?
12:40 < wumpus> #topic Fix more init bugs (#10919)
12:40 < gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
12:40 < wumpus> no @BlueMatt ^^ moar init bugs
12:40 < BlueMatt> thats just #10758 part deux
12:40 < gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
12:40 < BlueMatt> to get the first one merged cause people didnt want me to have a huge ever-growing pile of fixes in one pr
12:41 < jtimon> probably obvious but why not symlinks?
12:42 < wumpus> jtimon: berkeleydb doesn't gracefully support them, especially if you link outside the context directory
12:42 < jtimon> thanks
12:42 < wumpus> so it's very, very dangerous
12:42 < wumpus> BlueMatt: ok
12:42 < wumpus> #topic segwit wallet release (gmaxwell)
12:43 < gmaxwell> So, segwit is going to activate. It would be nice to get a version out
12:43 < gmaxwell> soon that exposes a segwit wallet to the user, and maybe supports sending
12:43 < gmaxwell> to BIP173 style addresses. Maybe we could consider short cycling 0.16
12:43 < gmaxwell> with primarily just this functionality, or something like that?
12:44 < gmaxwell> Since we technically have support but don't wire it up by default, (except
12:44 < gmaxwell> via the RPCs) I believe it's a short effort; mostly a testing concern.
12:44 < gmaxwell> Another alternative would be to branch, off a 0.15+segwit and cut
12:44 < gmaxwell> expiremental releases for people. 
12:44 < gmaxwell> There are some political implications, since getting adoption of SW  
12:44 < gmaxwell> will tone down some mania in the industry.
12:44 < jonasschnelli> Agree
12:44 < BlueMatt> seems reasonable
12:44 < BlueMatt> i vote for at 15.segwit
12:44 < achow101> perhaps start off by giving out the p2sh nested addresses first and then move on to bech32?
12:44 < 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)
12:45 < gmaxwell> Well I threw out two ideas: 0.16 fast and 0.15+segwit as a seperate downloadable thing...
12:45 < achow101> why not just a 0.15.x release?
12:45 < jonasschnelli> So 0.15.1 + 0.15.1+SW?
12:45 < gmaxwell> achow101: the point on 173 is support for sending to. We likely wouldn't actually issue those addresses for >1 year.
12:45 < wumpus> achow101: it's a feature
12:45  * BlueMatt would be somewhat dissapointed to see a full release number for such a small set of changes
12:45 < BlueMatt> 15.segwit seems reasonable, while working on 16 still
12:45 < gmaxwell> If we did 0.15+sw as a full release we should call that 0.16. But thats just a naming thing.
12:45 < wumpus> so is it really a small set of changes? or are you underestimating it?
12:45 < BlueMatt> well, ok
12:45 < jtimon> achow101: yeah, wondering the same
12:46 < gmaxwell> but we could also release it as 0.15+expiremental segwit, an explicit alternative.
12:46 < BlueMatt> point being lets not freeze master again soon just for this
12:46 < BlueMatt> gmaxwell: all you're saying is support sending to segwit addresses, right?
12:46 < BlueMatt> not gui showing them as a receive address?
12:46 < gmaxwell> BlueMatt: if we do BIP173 support it would just be sending to.
12:46 < wumpus> yeah full GUI support is significant work
12:47 < BlueMatt> wumpus: hmm?
12:47 < BlueMatt> i mean we're just talking about a send-only address format, no?
12:47 < 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).
12:47 < wumpus> it's very easy to underestimate the changes needed, the tests, reviews, iterations
12:47 < achow101> gmaxwell: what do you mean by segwit wallet?
12:47 < 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?
12:48 < gmaxwell> Segwit wallet basically means making getnewaddress return p2sh embedded segwit addresses.
12:48 < gmaxwell> (and the GUI of course)
12:48 < BlueMatt> mmm, yea, thats...trickier
12:48 < gmaxwell> BlueMatt: well technically it's just a few lines changed, if we ignore the testing burden. :)
12:48 < BlueMatt> heh, yea, well testing
12:48 < 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
12:48 < gmaxwell> because the wallet does support segwit today... just doesn't use it without dorking with the rpc.
12:48 < wumpus> would be the first major release not branched from master
12:49 < 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)
12:49 < wumpus> and it still needs to land in master anyhow, no way around that
12:49  * BlueMatt is fine with calling it 0.15.1, fwiw
12:49 < gmaxwell> And in _theory_ the segwit support in the wallet is "tested".
12:49 < jtimon> yeah, nack on working on 0.15 and calling it 0.16, why not simply 0.15.1 ?
12:49 < gmaxwell> So there is a scope question and a naming question. Lets not conflate them.
12:50 < BlueMatt> fair, scope wise lets not creep
12:50 < BlueMatt> which means keep it on the 15 branch
12:50 < BlueMatt> naming, i dont feel strongly about, either way wfm
12:50 < wumpus> ok     
12:50 < jonasschnelli> would the 0.15.SW always generate p2sh embedded sw addresses or optional?
12:51 < BlueMatt> by default, i assume
12:51 < 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.
12:51 < gmaxwell> jonasschnelli: I assume we'd make it gated by a config option like usehd.
12:51 < gmaxwell> Unless we ran into hairballs that we couldn't resolve.
12:51 < jtimon> if the scope is smal it seems reasonable to do it on 0.15.1/0.15.segwit
12:51 < wumpus> it certainly needs to be optional, default behavior can't change in a minor version
12:51 < jonasschnelli> BIP173 sending only is kinda hard(er) to test without the rec. part
12:52 < jonasschnelli> wumpus: Yes. That makes sense
12:52 < 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.
12:52 < gmaxwell> jonasschnelli: we can recieve BIP173 payments with some hidden options. (I believe the code is still there-- we have tests for that already)
12:53 < 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.
12:53 < jonasschnelli> Indeed
12:53 < 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.
12:53 < 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
12:54 < 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.
12:54 < wumpus> yes     
12:54 < gmaxwell> (also pushing for rapid 173 adoption has a downside of making people think it's needed for segwit, it's not)
12:56 < 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?
12:56 < gmaxwell> I would be okay with that. We don't need to decide quite yet, but I wanted to get people thinking about it.
12:56 < jtimon> so what about 0.15.1 -> segwit wallet, 0.15.2 - > send to bip173, optionally receive ?
12:56 < BlueMatt> wumpus: that seems reasonable to me, ultimately i dont care too much and its up to you
12:56 < wumpus> or, I guess development could still be done on master w/ backports as normal
12:56 < BlueMatt> oh, yea, I'd vote backports
12:56 < gmaxwell> wumpus: that would be better IMO
12:57 < BlueMatt> whether its on the 15 branch or on a 15.segwit branch I dont care
12:57 < achow101> ack backports
12:57 < wumpus> (in the other case you'd have to forward-port)
12:57 < achow101> so we can have it in 0.16 too
12:57 < wumpus> yes     
12:58 < 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.
12:58 < jtimon> 2 mins
12:58 < 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)
12:59 < gmaxwell> But who knows whatever dusty corners we'll expose.
12:59 < gmaxwell> wumpus: well it might favor delaying some 0.16 development to happen after this.
12:59 -!- fronti [~fronti@irc.fh-biergarten.de] has joined #bitcoin-core-dev     
12:59 < wumpus> but forward and backporting isn't much different effort and it has to end up in master too
12:59 < gmaxwell> but I don't think there are many PRs already open that would get in the way.
12:59 < jonasschnelli> What about delaying 0.15 for P2SH(P2WPKH) support?
12:59 < wumpus> gmaxwell: in that case we're doing the 0.16 freeze that BlueMatt didn't want :)
12:59 < gmaxwell> jonasschnelli: I'd rather not.
13:00 < wumpus> I'd also prefer not
13:00 < wumpus> 0.15 is almost ready
13:00 < 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.
13:00 < wumpus> 0.15.1 is better
13:00 < jonasschnelli> Okay
13:00 < wumpus> would be very bad to delay 0.15.0 on a *feature* now, so long after the feature freeze
13:01 < wumpus> espeically one that doens't even have a PR open
13:01 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
13:01 -!- timothy [~tredaelli@redhat/timothy] has quit [Client Quit]     
13:01 < BlueMatt> *DONG*
13:01 < wumpus> #endmeeting
13:01 < lightningbot> Meeting ended Thu Jul 27 20:01:16 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.html
13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.txt
13:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-27-19.00.log.html
13:01 < gmaxwell> we ran over!
13:01 < wumpus> shit
13:01 < jtimon> yeah, nack on delaying 0.15
13:02 < BlueMatt> well, clearly we have failed, we should give up having meetings
13:02 < gmaxwell> that meeting was invalid, gonna have to drop it and make a new one
13:02 < achow101> so about the large chainstate I have, here's the pastebin in case you missed it: https://pastebin.com/hAeYMjRW
13:02 < wumpus> we should have a meeting about better timing of meetings
13:02 < wumpus> achow101: ah yes, thanks, forgot about that one
13:02 -!- fydel [~quassel@204.12.217.226] has joined #bitcoin-core-dev     
13:03 < 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).
13:03 < wumpus> achow101: .fuse_hidden files?!
13:03 < achow101> dunno wtf those are
13:03 < BlueMatt> gmaxwell: i dunno, i dont expect anything to get done in 2 weeks
13:03 -!- ndrst [~ndrst@unaffiliated/ndrst] has joined #bitcoin-core-dev     
13:03 < BlueMatt> gmaxwell: just review of wallet stuff is usually slow, plus testing and release cycle
13:03 < wumpus> achow101: what size do you get if you only measure LOG and .ldb files?
13:03 < gmaxwell> BlueMatt: well sure, but I think it's like a 1 day change plus N weeks of discussion and tweaking.
13:04 < wumpus> achow101: I think those are your junk files
13:04 < wumpus> achow101: fuse_hidden files are part of filesystem management anyhow, not of the leveldb database
13:04 -!- fronti [~fronti@irc.fh-biergarten.de] has left #bitcoin-core-dev []     
13:04 < BlueMatt> gmaxwell: yea, that
13:04 < 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".
13:04 < wumpus> achow101: sometimes they're left behind
13:04 -!- goto_ [~goto@satoshis.guru] has joined #bitcoin-core-dev     
13:04 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 260 seconds]     
13:04 < jcorgan> what fs is dir in
13:04 < achow101> oh     
13:05 < wumpus> sshfs?
13:05 < achow101> it's 5.8 of .ldb files
13:05 < achow101> *5.8 GB
13:06 < wumpus> achow101: that's more or  less the normal size after upgrade and before compaction
13:07 < gmaxwell> oh you said 8GB before, which was concerning.
13:07 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
13:07 < achow101> yeah, that makes sense
13:07 < achow101> gmaxwell: that's the entire chainstate folder
13:07 < gmaxwell> hm my entire chainstate folder is 5.8
13:07 < achow101> jcorgan: I think its an NTFS drive
13:07 < jcorgan> ah ok
13:07 < jcorgan> so ntfs-fuse then
13:07 < achow101> (I use it with windows occasionally)
13:07 < BlueMatt> ntfs? eww
13:08 < achow101> it started out as a windows drive
13:08 < wumpus> gmaxwell: it turns out to be full of fuse fs ghost files
13:08 < achow101> too lazy to change it
13:08 < jcorgan> those .fuse_hidden files are files deleted but someone still has an open file handle to it
13:08 < 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
13:08 < gmaxwell> zoinks, well thats one mystery solved.
13:08 < achow101> jcorgan: can they be safely deleted?
13:08 < wumpus> jcorgan: yep, and sometimes it forgets about them and leaves them behind
13:09 < jcorgan> yes and yes
13:09 < wumpus> achow101: yes, maybe close bitcoind first just in case
13:09 < achow101> too late
13:09 < wumpus> (nothing *else* will be holding on handles to the chainstate files)
13:10 < jcorgan> the dates on those were from last september, you've probably rebooted since then :)
13:10 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
13:10 < wumpus> lol, yes
13:10 < achow101> I probably have. uptime says 43 days
13:10 < wumpus> or at least restarted bitcoind
13:11 < jcorgan> yeah, then they were just a bunch of fuse turds
13:11 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
13:11 < achow101> so how about compacting the database after upgrade (and not upgrading with 10526)?
13:11 < achow101> or is that "you did something stupid so deal with it yourself" kind of thing?
13:12 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has joined #bitcoin-core-dev     
13:12 < wumpus> achow101: gmaxwell was talking about adding a hidden RPC to do database compactions, seems like a reasonable idea
13:12 < achow101> would it be a bad idea to just compact every startup?
13:13 < wumpus> yes, slow
13:13 < achow101> I figured
13:13 < wumpus> leveldb does it automatically once in a while anyway
13:13 < wumpus> (depending on some metric)
13:14 < wumpus> normally you shouldn't want to bother with it, unless you just rewrote the entire database like with the upgrade
13:20 -!- testeriknl [~testerikn@2001:985:a326:1:543b:9b09:2eb5:fca7] has joined #bitcoin-core-dev     
13:25 < 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?
13:28 -!- J-wolf [~J-wolf@82.102.252.13] has joined #bitcoin-core-dev     
13:30 < 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.
13:32 < Murch> or at least the vast majority would reach a very small set of results.
13:33 < 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
13:33 < gribble> https://github.com/bitcoin/bitcoin/issues/10034 | sendtoaddress subtractfeefromamount=true does not respect paytxfee values · Issue #10034 · bitcoin/bitcoin · GitHub
13:33 < 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)
13:33 < morcos> but i'm not seeing why it would consistently lead to significant overpaying
13:34 < Murch> morcos: The overpaying behavior comes from locking in the expected fees from the previous run.
13:34 < morcos> Murch: yes i'm aware of that problem, but that should be quite rare, not something that is seen over and over again
13:35 < 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
13:37 -!- goto_ [~goto@satoshis.guru] has left #bitcoin-core-dev []     
13:39 < Murch> morcos:  every time when one round fails for selecting too little fees and then the next one succeeds with fewer inputs.
13:39 < sipa> so i think #10924 should be tagged for 0.15; i'll update with some more information
13:39 < 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
13:40 < sipa> it's possible to make gettransaction and listtransactions output diverge
13:40 < 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?
13:41 < 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
13:41 < 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
13:41 < Murch> morcos: I described the original problem on page twenty in my thesis: http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf
13:41 < sipa> the fix for #10924 is easy: we need to add P2WSH/P2WPKH to CTxDestination, which is needed anyway for bip173 support
13:41 < 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
13:42 < Murch> I seem to remember that you fixed at least the accumulative fee issue, but I'm not sure.
13:44 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
13:44 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:52 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
13:54 -!- J-wolf [~J-wolf@82.102.252.13] has quit [Remote host closed the connection]     
13:55 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:56 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:59 -!- J-wolf [~J-wolf@82.102.252.13] has joined #bitcoin-core-dev     
13:59 -!- promag [~joao@2001:8a0:fe30:de01:ddd5:57a1:4a4d:4800] has joined #bitcoin-core-dev     
13:59 < MarcoFalke> happy editing: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.15.0-Release-notes
14:00 < promag> wumpus: should I make the change https://github.com/bitcoin/bitcoin/pull/10885#issuecomment-318478956 ?
14:04 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
14:06 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:09 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
14:10 -!- J-wolf [~J-wolf@82.102.252.13] has quit [Remote host closed the connection]     
14:21 -!- J-wolf [~J-wolf@82.102.252.13] has joined #bitcoin-core-dev     
14:27 < 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
14:30 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
14:31 -!- J-wolf [~J-wolf@82.102.252.13] has quit [Remote host closed the connection]     
14:34 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
14:40 < promag> morcos: is fSubtractFeeFromAmount something really used?
14:40 < gmaxwell> Yes, people use it.
14:41 < 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.
14:42 < promag> ah I see, ty
14:45 < 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
14:46 < gmaxwell> promag: one of the applications is completely emptying a wallet.
14:47 < gmaxwell> without subtract fee from amount there is basically no way to do that (other than manually with raw transactions)
14:47 < promag> I surrender
14:47 < gmaxwell> :)     
14:47 < gmaxwell> It's a good instinct to want to simplify.
14:48 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
14:48 < promag> it would be nice to have a test failing before https://github.com/bitcoin/bitcoin/pull/10942/files
14:48 < promag> I wonder if morcos is able to reproduce
14:52 < 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
14:53 < 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
14:53 < morcos> so no reason to go crazy trying to make it pretty right now
14:53 -!- Yogaqueef [~textual@dsl-hkibng42-5673c3-32.dhcp.inet.fi] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]     
14:53 < promag> yeah dejavu
14:54 < morcos> even if it doesn't look better, the logic is far clearer and smarter now than it was in 0.14
14:55 -!- jeep-ss [~chatzilla@78.31.64.4] has joined #bitcoin-core-dev     
15:02 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
15:03 < promag> morcos: some comments
15:11 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
15:18 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]     
15:20 -!- ula [~kvirc@b2b-78-94-9-226.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]     
15:23 -!- testeriknl [~testerikn@2001:985:a326:1:543b:9b09:2eb5:fca7] has quit [Quit: Leaving...]     
15:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
15:25 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
15:27 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev     
15:28 -!- Eagle[TM] [~EagleTM@x4db47f1f.dyn.telefonica.de] has joined #bitcoin-core-dev     
15:29 -!- EagleTM [~EagleTM@x4db47f1f.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]     
15:29 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
15:30 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
15:37 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
15:37 -!- clarkmoody_ [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
15:37 -!- snkey [~random@185.32.222.18] has joined #bitcoin-core-dev     
15:40 -!- tucenaber_ [~tucenaber@o144.231.lokis.net.pl] has joined #bitcoin-core-dev     
15:40 -!- cryptapus_ [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
15:40 -!- cryptapus_ [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
15:40 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
15:40 -!- cryptapus_ is now known as cryptapus_afk     
15:41 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:41 -!- rafalcpp_ [~racalcppp@84.10.11.234] has joined #bitcoin-core-dev     
15:41 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Excess Flood]     
15:41 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood]     
15:41 -!- stick`` [~stick@sway.gk2.sk] has joined #bitcoin-core-dev     
15:41 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has quit [Remote host closed the connection]     
15:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Excess Flood]     
15:41 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Write error: Broken pipe]     
15:41 -!- altoz [~Jimmy@2605:6000:1017:40c6:54bb:2fc6:541a:2537] has quit [Remote host closed the connection]     
15:41 -!- earlz [~earlz@earlz.net] has quit [Remote host closed the connection]     
15:42 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
15:42 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
15:42 -!- jeremyru1in [~jeremyrub@biohazard-cafe.mit.edu] has joined #bitcoin-core-dev     
15:42 -!- kinlo [~peter@unaffiliated/kinlo] has quit [Read error: Connection reset by peer]     
15:42 -!- zxzzt_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
15:42 -!- jrayhawk_ [~jrayhawk@unaffiliated/jrayhawk] has joined #bitcoin-core-dev     
15:42 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev     
15:42 -!- earlz [~earlz@earlz.net] has joined #bitcoin-core-dev     
15:42 -!- berndj [~berndj@mail.azna.co.za] has quit [Excess Flood]     
15:42 -!- harding [~harding@mail.dtrt.org] has quit [Write error: Broken pipe]     
15:42 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Write error: Broken pipe]     
15:42 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Disconnected by services]     
15:42 -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has quit [Write error: Broken pipe]     
15:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
15:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]     
15:42 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Remote host closed the connection]     
15:42 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has quit [Remote host closed the connection]     
15:42 -!- newbie-- [~irc@mirk.info] has quit [Remote host closed the connection]     
15:42 -!- stick` [~stick@sway.gk2.sk] has quit [Remote host closed the connection]     
15:42 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
15:42 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]     
15:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
15:43 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
15:43 -!- snq [~random@185.32.222.18] has quit [Write error: Broken pipe]     
15:43 -!- Guest92337 [~haakonn@146.185.155.218] has quit [Remote host closed the connection]     
15:43 -!- haakonn [~haakonn@146.185.155.218] has joined #bitcoin-core-dev     
15:43 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
15:43 -!- newbie-- [~irc@mirk.info] has joined #bitcoin-core-dev     
15:44 -!- haakonn is now known as Guest66563     
15:44 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 247 seconds]     
15:46 -!- lukedashjr is now known as luke-jr     
15:47 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
15:47 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
15:48 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
15:48 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev     
15:51 -!- str4d [~str4d@nova-153-092-136-128.cpe.nova.is] has joined #bitcoin-core-dev     
16:04 -!- promag [~joao@2001:8a0:fe30:de01:ddd5:57a1:4a4d:4800] has left #bitcoin-core-dev []     
16:10 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has quit [Ping timeout: 240 seconds]     
16:45 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Quit: Leaving.]     
16:46 -!- treebeardd [~treebeard@50-248-210-131-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:01 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #bitcoin-core-dev     
17:03 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:13 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
17:15 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has joined #bitcoin-core-dev     
17:21 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Ping timeout: 255 seconds]     
17:22 -!- sam_c [~sam_c@unaffiliated/cmpct] has quit [Quit: ZNC - http://znc.in]     
17:27 -!- sam_c [~sam_c@unaffiliated/cmpct] has joined #bitcoin-core-dev     
17:30 -!- sam_c [~sam_c@unaffiliated/cmpct] has quit [Client Quit]     
17:41 -!- sam_c [~sam_c@unaffiliated/cmpct] has joined #bitcoin-core-dev     
17:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-syysxujgxlmyybpu] has quit [Quit: Connection closed for inactivity]     
18:09 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
18:13 < bitcoin-git> [bitcoin] gmaxwell opened pull request #10945: Update defaultAssumeValid according to release-process.md. (master...201707-update-assumevalid) https://github.com/bitcoin/bitcoin/pull/10945
18:22 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:24 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
18:24 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]     
18:36 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:41 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Remote host closed the connection]     
18:50 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
18:52 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds]     
18:57 -!- snkey [~random@185.32.222.18] has quit [Remote host closed the connection]     
19:04 -!- jamesob [~james@tempo-automation.static.monkeybrains.net] has quit [Ping timeout: 240 seconds]     
19:06 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev     
19:07 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
19:15 -!- snq [~random@185.32.222.18] has joined #bitcoin-core-dev     
19:21 -!- snq [~random@185.32.222.18] has quit [Quit: Leaving]     
19:21 -!- PRab [~chatzilla@c-68-56-234-28.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 54.0.1/20170628075643]]     
19:30 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
19:32 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
19:42 -!- snq [~random@217.23.5.224] has joined #bitcoin-core-dev     
19:45 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
19:46 -!- str4d [~str4d@nova-153-092-136-128.cpe.nova.is] has quit [Ping timeout: 240 seconds]     
20:09 -!- praxeology [~praxeolog@unaffiliated/praxeology] has quit [Ping timeout: 240 seconds]     
20:13 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has joined #bitcoin-core-dev     
20:14 -!- praxeology [~praxeolog@cpe-76-187-72-181.tx.res.rr.com] has quit [Changing host]     
20:14 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
20:23 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has quit [Quit: Leaving]     
20:26 -!- EagleTM [~EagleTM@x4e376af0.dyn.telefonica.de] has joined #bitcoin-core-dev     
20:27 -!- Eagle[TM] [~EagleTM@x4db47f1f.dyn.telefonica.de] has quit [Ping timeout: 255 seconds]     
20:39 -!- snq [~random@217.23.5.224] has quit [Quit: Leaving]     
20:41 -!- jamesob [~james@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
20:45 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
20:49 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 255 seconds]     
20:58 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev     
21:04 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Quit: Page closed]     
21:14 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]     
21:21 -!- jeep-ss [~chatzilla@78.31.64.4] has quit [Ping timeout: 268 seconds]     
21:32 -!- veleiro [~sleeper@fsf/member/veleiro] has quit [Ping timeout: 240 seconds]     
21:52 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
21:54 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
22:07 -!- HeyRoll [49e7c219@gateway/web/freenode/ip.73.231.194.25] has joined #bitcoin-core-dev     
22:09 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
22:19 < bitcoin-git> [bitcoin] sipa opened pull request #10946: Add chainwork to getchaintxstats (master...20170727_chainworkstats) https://github.com/bitcoin/bitcoin/pull/10946
22:29 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
22:30 -!- snq [~random@93.190.141.161] has joined #bitcoin-core-dev     
22:31 -!- snq [~random@93.190.141.161] has quit [Client Quit]     
22:32 -!- snq [~random@185.32.222.13] has joined #bitcoin-core-dev     
22:33 < gmaxwell> sipa: should I add updating ChainTxData to the PR I have for the assumevalid?
22:38 -!- snq [~random@185.32.222.13] has quit [Quit: Leaving]     
22:40 -!- snq [~random@77.243.183.11] has joined #bitcoin-core-dev     
22:40 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 255 seconds]     
22:42 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.9]     
22:46 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
22:50 < sipa> gmaxwell: ?
22:51 < gmaxwell> sipa: I have a PR open to update the assumevalid, I could update chainTxData too, I was reminded by your above PR.
22:55 < wumpus> profall: it's really useful for giving whole UTXOs away
22:56 < wumpus> (or alternatively, sending them to some other wallet of yourself, but the idea is to not have to add anything extra for fee, resulting in change)
22:57 < wumpus> this used to be a process of bisection
22:59 < sipa> gmaxwell: ah, i see!
22:59 < sipa> i just wrote thst PR to verify your nMinimumChainWork
22:59 < gmaxwell> sipa: yes, I responded to that PR to point out that the info is already in getblockchaininfo, the release process docs tell you how to verify it. :)
23:00 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
23:01 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
23:07 < wumpus> "The fee rate (in %s/kB) used to discard change (to fee) if it would be dust at this fee rate (default: %s) Note: We will always discard up to the dust relay fee and a discard fee above that is limited by the longest target fee estimate" 
23:07 < wumpus> this confuses translators
23:08 < wumpus> - "the dust relay fee" -- this sounds like a fee applied to relaying dust; is it?
23:08 < wumpus> - "a discard fee" -- this sounds like a fee applied when discarding something, which is probably isn't. Does it relate to the fee rate which seems to be the main topic of this string?
23:08 < wumpus> - "discard change (to fee)" -- perhaps the explanation in the parentheses could be more precise. Does this suggest that the change is added to the fee in case it is otherwise considered dust? Then perhaps the parentheses may say something like "(by adding change to the fee instead)"?
23:09 < wumpus> - "longest target fee estimate" -- which of the other words does "longest" relate to here? Could this be rewritten as "longest estimete of the target fee", or perhaps "fee estimate of the longest target", or something else?
23:10 < wumpus> is this a user-servicable option at all? if not, might I propose moving it to debug-help wholesale and not translating it?
23:12 -!- HeyRoll [49e7c219@gateway/web/freenode/ip.73.231.194.25] has quit [Quit: Page closed]     
23:15 < wumpus> it uses too many internal technical terms that appear nowhere else, which indicates that someone that doesn't know internal wallet logic has no business setting it
23:16 < sipa> longest refers to long term estimate, i believe
23:16 < sipa> i would agree with making it an expert/debug option
23:19 < gmaxwell> I don't think the target thing should really be a user servisable option.
23:20 < gmaxwell> The discard threshold is.
23:20 < wumpus> this is about 'discardfee=<amt>'
23:20 < wumpus> well if so, it needs better documentation
23:22 < wumpus> this is from a person that has been translating bitcoin strings to Danish for a long time, I think it's a good indication that if he doesn't understand any of it, no other non-dev will
23:22 < gmaxwell> Right!
23:25 < wumpus> this again makes me doubt whether it makes sense to translate option helps at all. It's a bit like translating obscure error messages - having a variant of the technical terms in every language doesn't make it easier to look for
23:25 < wumpus> especially if the translators don't understand it and just do a literal translation
23:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rmakqoeihgujhejw] has joined #bitcoin-core-dev     
23:37 -!- jamesob [~james@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
23:41 -!- J-wolf [~J-wolf@82.102.252.13] has joined #bitcoin-core-dev     
23:47 -!- marcoagner [~user@187.113.148.71] has quit [Ping timeout: 255 seconds]     
23:50 -!- J-wolf [~J-wolf@82.102.252.13] has quit [Remote host closed the connection]