--- Day changed Thu Nov 30 2017
00:00 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:01 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:12 -!- JackH [~laptop@ip-213-127-58-112.ip.prioritytelecom.net] has quit [Ping timeout: 248 seconds]     
00:13 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 248 seconds]     
00:22 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:26 -!- JackH [~laptop@212.78.169.180] has joined #bitcoin-core-dev     
00:28 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
00:42 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
00:55 -!- unholymachine [~quassel@2601:8c:c003:9f16:1ca7:d5b5:613c:ea93] has quit [Ping timeout: 255 seconds]     
00:56 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:57 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
00:57 -!- unholymachine [~quassel@c-69-248-123-139.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
00:58 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
01:01 -!- wxss [~user@185.145.66.255] has joined #bitcoin-core-dev     
01:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:09 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has quit [Ping timeout: 248 seconds]     
01:16 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
01:17 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 248 seconds]     
01:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:29 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
01:38 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
01:39 -!- cdecker_ [~cdecker@mail.snyke.net] has joined #bitcoin-core-dev     
01:39 -!- unholymachine [~quassel@c-69-248-123-139.hsd1.nj.comcast.net] has quit [Remote host closed the connection]     
01:39 -!- cdecker [~cdecker@mail.snyke.net] has quit [Ping timeout: 240 seconds]     
01:39 -!- Masaomi[m] [masaomimat@gateway/shell/matrix.org/x-hknxkhhzbpippags] has quit [Ping timeout: 240 seconds]     
01:39 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 240 seconds]     
01:39 -!- _flow_ [flow@star.geekplace.eu] has quit [Ping timeout: 240 seconds]     
01:39 -!- berndj [~berndj@mail.azna.co.za] has quit [Ping timeout: 240 seconds]     
01:39 -!- cdecker_ is now known as cdecker     
01:39 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
01:39 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]     
01:39 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
01:40 -!- unholymachine [~quassel@2601:8c:c003:9f16:b501:a0b0:4f:b5a5] has joined #bitcoin-core-dev     
01:40 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
01:40 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-vbbtkajcqlrtvmni] has quit [Quit: Connection closed for inactivity]     
01:41 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev     
01:42 -!- _flow_ [flow@star.geekplace.eu] has joined #bitcoin-core-dev     
01:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
01:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
01:45 -!- Masaomi[m] [masaomimat@gateway/shell/matrix.org/x-fxosxejzlwpnoqdh] has joined #bitcoin-core-dev     
01:55 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-aormxjsjqrzekrzh] has joined #bitcoin-core-dev     
01:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
02:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rhfgqlbziozzlake] has quit [Quit: Connection closed for inactivity]     
02:06 < bitcoin-git> [bitcoin] laanwj closed pull request #11793: Docs: Bump OS X version to 10.13 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11793
02:08 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
02:09 -!- lysobit_ [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev     
02:10 -!- lysobit_ is now known as musalbas     
02:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:12 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 265 seconds]     
02:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:15 -!- Netsplit over, joins: meshcollider, windsok, Dyaheon, qrestlove
02:20 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
02:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:27 < aj> jnewbery: apparently github detects merge conflicts even when git merge and rebase both work fine, so i've split the preliminary changes from #11774 into #11796; hopefully 11796 can be easily merged once acked, since it shouldn't break any pending PRs
02:27 < gribble> https://github.com/bitcoin/bitcoin/issues/11774 | [WIP] [tests] Rename functional tests by ajtowns · Pull Request #11774 · bitcoin/bitcoin · GitHub
02:27 < gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
02:28 < wumpus> github is really sensitive with regard to merges, more than the stock git commands
02:29 < wumpus> might be so that at least no one blames them for merges going wrong
02:30 < aj> wumpus: yeah, it does make sense. bit weird not being able to tell quite what github thinks the conflict is though
02:30 < wumpus> at a company I used to work for the integration dept had a similar rule. Two changes affect the same file? let the devs sort it out
02:31 < wumpus> yeah it could use some better reporting
02:33 < wumpus> something I'd really like on github would be a graph of which open PRs collide with which other PRs
02:34 < wumpus> would help a lot in finding the optimal merge order, as well as notify authors early if their PR is going to need to be rebased
02:35 < sipa> that would be very useful
02:35 < sipa> n^2 complexity though in the number of PRs, i think
02:37 < wumpus> worst case, though the n^2 could be filtered by excluding PRs that affect completely distinct files
02:38 < wumpus> also one'd want to avoid recomputing the whole thing, just incrementally take opens/closes into account
02:40 < wumpus> (ugh, and PRs that are re-pushed)
02:40 < aj> that just makes it O(n) for each PR change though
02:41 < wumpus> which is reasonable, you can do it in the background, not at the time someone opens the graph
02:42 < aj> yeah, n isn't /that/ large
02:43 < wumpus> though yeah if github wants to do it for all projects it could get bad for them
02:43 < wumpus> I don't really care if it would be a paid-only feature or such
02:43 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection]     
02:45 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev     
03:00 < wumpus> I've changed "Docs and output" label to just "Docs", it is only for documentation, for logging changes and such please use "Utils/logging/libs" instead. 
03:00 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
03:01 < wumpus> I think lumping everything output-related in one issue was a bit confusing
03:01 < wumpus> in one label*
03:02 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
03:02 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
03:02 -!- JackH [~laptop@212.78.169.180] has quit [Read error: Connection reset by peer]     
03:05 -!- gitju [~gitju@5.230.145.49] has joined #bitcoin-core-dev     
03:05 -!- gitju_ [~gitju@5.230.145.49] has joined #bitcoin-core-dev     
03:07 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
03:07 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
03:08 -!- unholymachine [~quassel@2601:8c:c003:9f16:b501:a0b0:4f:b5a5] has quit [Remote host closed the connection]     
03:09 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds]     
03:10 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:454f:112b:9095:f0ea] has quit [Ping timeout: 250 seconds]     
03:10 -!- commavir [vir@2604:180::502b:135a] has quit [Ping timeout: 255 seconds]     
03:10 -!- unholymachine [~quassel@2601:8c:c003:9f16:b501:a0b0:4f:b5a5] has joined #bitcoin-core-dev     
03:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:11 -!- commavir [vir@2604:180::502b:135a] has joined #bitcoin-core-dev     
03:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:13 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
03:14 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-cbkltrspzmsvygkb] has quit [Ping timeout: 240 seconds]     
03:14 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-cwkhkcenzpxqchnj] has quit [Ping timeout: 248 seconds]     
03:14 -!- Masaomi[m] [masaomimat@gateway/shell/matrix.org/x-fxosxejzlwpnoqdh] has quit [Ping timeout: 246 seconds]     
03:14 -!- griswaalt[m] [griswaaltm@gateway/shell/matrix.org/x-xejfnexcqvhuhzjr] has quit [Ping timeout: 264 seconds]     
03:15 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:454f:112b:9095:f0ea] has joined #bitcoin-core-dev     
03:16 -!- gitju_ [~gitju@5.230.145.49] has quit [Quit: Leaving]     
03:17 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
03:22 < aj> wumpus: had a quick play, and it seems like you can get somewhere with detecting PR conflicts using git locally. for xa in $tsts; do a=pull/origin/$xa; if (git reset --hard origin/master && git merge $a -m "merge $a to master") >/dev/null; then for xb in $tsts; do if [ "$xa" -ge "$xb" ]; then continue; fi; b=pull/origin/$xb; (git format-patch $(git merge-base $a $b)..$b --stdout | git apply --check 
03:22 < aj> -) > APPLY_${xa}_${xb} 2>&1 && echo "no conflict between $xa $xb" || echo "merge conflict $xa $xb ?"; done; else echo "conflict with $a and master"; fi; done > CONFLICT
03:22 < aj> gah     
03:22 < aj> wumpus: had a quick play, and it seems like you can get somewhere with detecting PR conflicts using git locally.  -- was what i was trying to say
03:22 < aj> wumpus: https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- was what i was trying to paste
03:22 < wumpus> awesome!
03:24 < wumpus> pretty clever that you manage to avoid touching the working tree
03:24 < wumpus> but yes seems I won't get around to setting up a git tree that pulls all the PRs locally
03:25 < aj> wumpus: hmm? pulling all the PRs locally is easy and awesome though?
03:26 < wumpus> yeah no problem, just don't do it at the moment to avoid cluttering my tree further, I have 858 branches of my own at this point :)
03:27 < fanquake> git branch -D *
03:28 < aj> wumpus: the pull requests don't show up in git branch -av for me, so i don't even notice (actually, i don't even know how to get a list of them...)
03:28 < wumpus> fanquake: git branch -D doesn't take a pattern :-) you'd need something like git branch | xargs git branch -D 
03:29 < wumpus> aj: interesting, I'd have expected them to show up
03:31 < wumpus> (I regularly do 'git branch --list 'pull/*' | xargs git branch -D' to get rid of the temporary branches left behind by github-merge.py in some cases)
03:31 < aj> ah, "git remote show origin" will at least give me a list of them
03:32 < wumpus> apart from that I use a single repository with worktrees for persistent branches like 0.15
03:33 < wumpus> anyhow it works pretty well, I think it will still work pretty will with 231 more branches; will have to find something to clean up closed PRs though
03:33 < aj> updated that gist with the compatible and conflicts graphs for a handful of recent PRs
03:33 < wumpus> or does that automatically remove removed branches at the gh side as well?
03:34 < wumpus> aj: oh wow
03:36 < aj> wumpus: the only thing i can think of to make it useful is dumping data into python to work out which collections of PRs have complete subgraphs of compatability
03:36 < wumpus> so a connection means a conflict? why do 11790 and 11741 conflict?
03:37 < wumpus> 11741 only changes two files, yet conflicts with 9 PRs or so
03:37 < wumpus> it's possible :)
03:38 -!- BGL [~BGLWrK@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]     
03:40 < aj> yeah, they merge fine manually; git apply --check complains about multiwallet.py, rpc/rawtransaction.cpp and test/txvalidation_tests.cpp
03:41 < aj> ah, i'm trying to apply patches from master twice
03:41 < wumpus> but 11741 touches neither of those
03:42 < wumpus> hehe okay
03:45 < fanquake> nice
03:48 < wumpus> oope, so fetch = +refs/pull/*/head:refs/pull/origin/*  doesn't just fetch *open* pull requests
03:49 < wumpus> whee tracking 8288 branches now
03:49 < aj> https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- conflict graph looks better now
03:50 < wumpus> happy I did it in a temporary repo :)
03:52 < wumpus> aj: great
03:56 < Varunram> aj: thanks for the gist :)
03:58 < aj> probably needs to work out which PR branched off from master most recently and use that as a base
04:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:17 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-aormxjsjqrzekrzh] has quit [Quit: Connection closed for inactivity]     
04:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:25 -!- griswaalt[m] [griswaaltm@gateway/shell/matrix.org/x-nyzhthzpbrbhhjnr] has joined #bitcoin-core-dev     
04:29 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
04:34 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-vekxstiqwrskepig] has joined #bitcoin-core-dev     
04:34 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-iomcebwqehgefnnq] has joined #bitcoin-core-dev     
04:34 -!- Masaomi[m] [masaomimat@gateway/shell/matrix.org/x-svbvmeqclfjgdfio] has joined #bitcoin-core-dev     
04:41 -!- BGL [fifty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
04:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
04:43 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
04:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
04:44 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving]     
04:44 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
04:45 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
04:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
04:50 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
04:52 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
04:54 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
04:55 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:21 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
05:22 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
05:28 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:34 -!- frostbyte1982 [18f845a2@gateway/web/freenode/ip.24.248.69.162] has quit [Quit: Page closed]     
05:41 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 250 seconds]     
05:48 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
05:48 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:57 -!- zxsanny [d462636a@gateway/web/freenode/ip.212.98.99.106] has joined #bitcoin-core-dev     
06:00 -!- jack__ [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
06:01 -!- zxsanny [d462636a@gateway/web/freenode/ip.212.98.99.106] has quit [Client Quit]     
06:07 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 250 seconds]     
06:19 -!- wordsToLiveBy [~wordsToLi@gateway/vpn/privateinternetaccess/wordstoliveby] has joined #bitcoin-core-dev     
06:19 < wordsToLiveBy> I'm reading the bitcoin white paper, and in section 11 Satoshi gives the calculations for how you can prove with probability that an attacker can't outpace the combined processing power of the rest of the nodes, but I am not quite getting the math being used.
06:19 -!- wordsToLiveBy [~wordsToLi@gateway/vpn/privateinternetaccess/wordstoliveby] has quit [Max SendQ exceeded]     
06:25 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
06:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
06:31 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
06:38 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
06:39 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
06:40 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
06:42 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
06:43 -!- Cogito_Ergo_Sum [~Myself@80.107.149.55] has joined #bitcoin-core-dev     
06:43 -!- Cogito_Ergo_Sum [~Myself@80.107.149.55] has quit [Changing host]     
06:43 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
06:55 < andytoshi> #bitcoin please, this is just about software development
06:55 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
07:04 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
07:08 < jnewbery> aj: thanks. I've reviewed #11796. It should be an easy review/merge for others.
07:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
07:21 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:24 -!- saint_ [~saint_@unaffiliated/saint-/x-0540772] has joined #bitcoin-core-dev     
07:24 < aj> jnewbery: ugh, what sort of person points out a bug and says not to fix it /o\
07:27 < saint_> any idea why can't bitcoin core download the blockchain on a remote NAS drive ? 
07:27 < wumpus> saint_: ask in #bitcoin please, will answer there
07:27 < saint_> okay
07:28 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
07:29 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
07:40 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
07:41 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
07:43 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds]     
07:48 -!- owowo [ovovo@gateway/vpn/mullvad/x-ikbedbhzepafyfwo] has joined #bitcoin-core-dev     
07:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds]     
07:49 -!- Emcy [~Emcy@cpc124520-swan5-2-0-cust45.7-3.cable.virginm.net] has joined #bitcoin-core-dev     
07:49 -!- Emcy [~Emcy@cpc124520-swan5-2-0-cust45.7-3.cable.virginm.net] has quit [Changing host]     
07:49 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
07:51 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:02 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]     
08:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
08:03 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:06 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:08 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds]     
08:11 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:12 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]     
08:12 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:12 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
08:16 < jnewbery> aj: I wanted to get in before someone else pointed it out and told you to fix it :)
08:16 < jnewbery> I don't think it matters since the next PR should remove that code anyway
08:25 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:25 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 252 seconds]     
08:25 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
08:30 -!- dqx [~dqx@unaffiliated/dqx] has quit [Quit: .]     
08:41 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev     
08:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
08:46 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
08:46 -!- Vimalraj [6acb5373@gateway/web/freenode/ip.106.203.83.115] has joined #bitcoin-core-dev     
08:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
08:52 -!- Vimalraj [6acb5373@gateway/web/freenode/ip.106.203.83.115] has quit [Ping timeout: 260 seconds]     
08:53 -!- quantbot_ [~quantbot@38.101.106.141] has quit [Ping timeout: 248 seconds]     
08:54 -!- quantbot [~quantbot@cpe-74-73-145-69.nyc.res.rr.com] has joined #bitcoin-core-dev     
08:55 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 250 seconds]     
09:02 -!- quantbot_ [~quantbot@38.101.106.141] has joined #bitcoin-core-dev     
09:03 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
09:03 -!- quantbot [~quantbot@cpe-74-73-145-69.nyc.res.rr.com] has quit [Ping timeout: 260 seconds]     
09:09 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 276 seconds]     
09:10 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
09:10 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:11 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev     
09:21 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
09:22 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
09:24 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
09:25 < achow101> is the github git notifier dead?
09:26 -!- anon [48bccec9@gateway/web/freenode/ip.72.188.206.201] has joined #bitcoin-core-dev     
09:27 -!- anon is now known as Guest18586     
09:27 -!- Guest18586 [48bccec9@gateway/web/freenode/ip.72.188.206.201] has quit [Client Quit]     
09:32 -!- lvmbdv [~root@188.226.130.89] has quit [Quit: brb]     
09:35 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Read error: Connection reset by peer]     
09:35 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit []     
09:36 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
09:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:37 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has joined #bitcoin-core-dev     
09:48 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 255 seconds]     
09:51 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
09:51 -!- bule2 [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
09:53 < wumpus> achow101: intermittently, yes
09:54 < wumpus> achow101: it seems incredibly unreliable
09:54 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 248 seconds]     
10:01 -!- kexkey [~kexkey@67.215.14.205] has joined #bitcoin-core-dev     
10:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:09 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
10:13 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 260 seconds]     
10:27 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
10:27 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
10:39 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-yvjwcjswtbfywzug] has joined #bitcoin-core-dev     
10:40 < jonasschnelli> I wonder how the Twitter commit feed works... I expect them polling
10:42 < wumpus> I think it must be; it isn't a webhook that we set up
10:43 < wumpus> we only have a slack webhook, and the IRC integration
10:43 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:43 -!- ExtraCrispy [~ExtraCris@185.22.175.244] has joined #bitcoin-core-dev     
10:52 < wumpus> so having ruled out that it listens on IRC, it must either be listening on slack or polling
10:52 < wumpus> not sure whether the slack notiifications do go through
10:53 -!- nanomouse [~nonomouse@197.237.254.92] has joined #bitcoin-core-dev     
10:54 < wumpus> if the normal webhook works we could set up our own IRC bot
10:56 < jonasschnelli> wumpus: slack works...
10:57 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-uvidmkycbrxqazhk] has joined #bitcoin-core-dev     
10:57 < wumpus> jonasschnelli: great, so we isolated it to a problem with their IRC bot, not their notifications in general
10:57 < instagibbs> meeting in 3?
10:57 < jonasschnelli> Looks like
10:57 < instagibbs> or am i off
10:58 < wumpus> you're right
10:59 < wumpus> if the bot stays flaky like this tomorrow I'll contact github support, it's already been for a few days
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Nov 30 19:00:03 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < wumpus> #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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag
11:00 < cfields> hi     
11:00 < sipa> hi     
11:00 < CodeShark> hello
11:00 < achow101> hi     
11:00 < Provoostenator> hi     
11:00 < instagibbs> hi     
11:00 < jonasschnelli> hi     
11:00 < wumpus> #topic high priority for review
11:01 < meshcollider> hi     
11:01 < luke-jr> hi     
11:01 < wumpus> 8 PRs have been tagged for https://github.com/bitcoin/bitcoin/projects/8
11:01 < BlueMatt> why does cfields have 2?
11:01 < wumpus> I added cfields's BanMan last week as it's blocking his further net refactoring
11:01 < cfields> BlueMatt: wasn't me, but i'll take it :)
11:02 < wumpus> ohh is it unfair?
11:02  * jonasschnelli also have two :|
11:02 < instagibbs> achow101, i see you rebased yours? we shooting for post-0.16?
11:02 < BlueMatt> i think we try to have only one per person
11:02 < jtimon> hi     
11:02 < BlueMatt> well i suggested we include jonasschnelli's other one as its kinda a segwit-wallet-blocker imo
11:02 < BlueMatt> or at least in-same-release
11:02 < achow101> instagibbs: I'm shooting for 0.16
11:02 < achow101> but it may not make it
11:03 < instagibbs> ok, I can give it more love, though I think I've given a lot already, probably needs others....
11:03 -!- karelb [b99c7828@gateway/web/freenode/ip.185.156.120.40] has joined #bitcoin-core-dev     
11:03 < achow101> still some segwit related things to do and runn1ng wants simulations
11:03 < achow101> also been busy with exams and classwork
11:03 < wumpus> well, good solution for that, review and merge one of cfields's PRs and there will be only one left :)
11:03 < karelb> achow101: I came just in time :) yes I wanted some simulations
11:03 < jonasschnelli> wumpus: heh
11:03 < sipa> so i think we're maybe unintentionally moving from a "we release regularly with whatever is finished" to "X is a blocker for release Y"
11:04 < BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
11:04 < wumpus> sipa: segwit is the only exception to that
11:04 < cfields> i have no problem with removing one of mine if it's an issue. But yes, I think 11363 is ready/easy to review
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
11:04 < BlueMatt> sipa: I think we'll go back to that post-segwit-wallet, no?
11:04 < wumpus> sipa: for the rest, releases are only ever blocked on bugfixes not features
11:04 < achow101> sipa: I think 0.16 is the exception? because segwit wallet
11:04 < wumpus> yes     
11:04 < jtimon> sipa: what is the blocker for 0.16 ?
11:04 < sipa> okay, that's fine - i'm not saying it's a bad thing
11:04 < instagibbs> i think it's openly acknowledged 
11:04 < wumpus> and segwit wallet is not intended as a *blocker* for 0.16
11:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
11:05 < wumpus> we intend to release 0.16 early after that's in
11:05 < sipa> fair enough
11:05 < wumpus> so it's more like a trigger
11:05 < sipa> but it still changes prioritization a bit
11:05 < BlueMatt> indeed
11:05 < instagibbs> i think the segwit pr is shaping up nicely at least
11:05 < wumpus> if segwit wallet takes longer than the 0.16 release window, then IMO we should release 0.16 without it
11:05 < wumpus> but I don't expect that
11:05 < BlueMatt> wumpus: agreed
11:06 < jtimon> oh, I see, we want to release 0.16 soon after segwit wallet gets in
11:06 < wumpus> jtimon: yep
11:06 < sipa> i'm about to push some review fixes to #11403
11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:06 < wumpus> jtimon: seems more advisable than trying to backport the whole lot + dependencies to 0.15
11:06 < cfields> sipa: not sure if you've clarified somewhere, do you consider all of the listed TODOs in 11403 blockers for release as well?
11:06 < jtimon> wumpus: yeah, I think I suggested that, eithe way it makes sense to me
11:07 < wumpus> jtimon: thanks in that case :)
11:07 < luke-jr> branch 0.15 into 0.16 ;)
11:07 < sipa> cfields: yes
11:07 < cfields> ok, thanks
11:08 < gmaxwell> So, segwit-wallet is done?
11:08 < jtimon> I'm not following review on the segwit wallet pr, how is it going?
11:08 < sipa> i think #11403 is pretty much done - just nits in command line option handling and output
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:08 < jtimon> great
11:08 < achow101> I tried reviewing it but it's big and scary
11:09 < wumpus> awesome
11:09 < sipa> we may want to discuss what to do with things like how dumpprivkey and signmessage should work in a post-segwit world
11:09  * Randolf congratulates achow101 for trying
11:09 < cfields> i found it reasonable review on a per-commit basis
11:09 < instagibbs> cfields, same
11:09 < sipa> as i believe some projects have come up with formats on their own
11:09 < cfields> *to review
11:09 < achow101> sipa: trezor has implemented their own segwit message signing thing
11:09 < jtimon> I guess I need tofix the nits in #8994 and #10757 if I want them to have a chance to get merged before 0.16 then
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
11:10 < achow101> I think that might be the only one though
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
11:10 < sipa> achow101: perhaps we can just adopt that
11:10 < jtimon> what are we referring to by "soon after"?
11:10 < wumpus> sipa: well if other project's import/export formats make sense, it'd be good to use them for interchangeability
11:10 < achow101> sipa: I don't think it's documented anywhere though
11:10 < meshcollider> Should there be a BIP to formalise it
11:10 < achow101> at least not yet
11:10 < Provoostenator> Is there a good standard for message signing?
11:10 < sipa> longer term i think a script-based signing would nice, but i don't think we're ready to adopt something like that
11:10 < gmaxwell> I thought they did but backed it out because it wasn't standardized yet. What they did didn't seem to awful, though I feel a little uneasy about the mutability between keytypes.
11:11 < karelb> sipa: ad sign message - in trezor we changed v constant - https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-316032523 - no BIP, no time :(
11:11 < sipa> karelb: ok, i'll have a look
11:11 < sipa> the original bitcoin core message signing doesn't have a bip either
11:11 < luke-jr> Provoostenator: no
11:11 < wumpus> a BIP is not a requirement for us implementing it, though in parallel it'd be nice
11:11 < BlueMatt> sipa: it probably should if we change it, though
11:11 < achow101> sipa: perhaps it should? retcon one :p
11:11 < sipa> seems reasonable
11:11 < wumpus> good to already have implementations and the BIP just formalizes it
11:12 < gmaxwell> Well, signmessage is generally not very good; but fixing it should be a longer term thing.
11:12 < Provoostenator> I vaguely remember trying to implement / refactor signing and being not amused by the lack of a standard. 
11:12 < luke-jr> current signed messages get very little real use, and most "usage" is based on misconceptions
11:12 < karelb> sipa yes good point. I wanted to write up a document that describes both current and segwit message signing, but I got stuck on how ecdsa signing actually works :)
11:12 < wumpus> luke-jr: agree
11:12 < luke-jr> IMO it'd make sense to just deprecate it until a better replacement is made
11:12 < wumpus> luke-jr: it's not a priority at least
11:12 < instagibbs> luke-jr, it's used for airdrops :P
11:12 < sipa> luke-jr: i agree it's not all that useful
11:12 < Provoostenator> Can it be made coin-agnostic as well?
11:12 < wumpus> certainly shouldn't be a blocker for 0.16
11:12 < luke-jr> instagibbs: that's a misuse, since it doesn't prove you have funds ;)
11:12 < gmaxwell> Provoostenator: no.
11:13 < karelb> we didn't have segwit message signing in web wallet, but users repeatedly demanded it
11:13 < instagibbs> luke-jr, but i profit from it, how can it be misuse ;P
11:13 < instagibbs> +1 tho
11:13 -!- ExtraCrispy [~ExtraCris@185.22.175.244] has quit [Quit: Remember...Arrays start at 0!!!ALWAYS]     
11:13 < gmaxwell> The fact that it's inherently incompatible with multisig is a real bummer.
11:13 < luke-jr> karelb: for what, though?
11:13 < achow101> instagibbs: lol
11:13 < gmaxwell> luke-jr: airdrops
11:13 < luke-jr> XD     
11:13 < wumpus> using bitcoin keys for anything else than signing transactions continues to make me uneasy
11:13 < jtimon> yeah, +1 to move to signing messages based on scripts
11:14 < luke-jr> MAST-based signmessage would be a sensible replacement
11:14 < Provoostenator> jtimon: what would that look like?
11:14 < wumpus> do hardware wallets even support it?
11:14 < luke-jr> Provoostenator: you could have a MAST if-branch that is always false for transactions, and then true for meta uses
11:14 < gmaxwell> wumpus: If I were to it again, I'd make signmessage work by just creating a transaction which is inherently unminable. It would make it a lot more compatible, though somewhat larger.
11:14 < CodeShark> gmaxwell: a general solution for airdrops seems extremely difficult
11:15 < jtimon> Provoostenator: like we sign txs but signing any message, in elements we sign blocks so perhaps you want to take a look (since there's generic functions to sign stuff, but they're not exposed and only used for blocks)
11:15 < gmaxwell> In elements sipa wrote a patch for a script based signmessage; but we ran into ... challenges.. with how softforks would be handled.
11:15 -!- nanymouse [~nonomouse@197.237.254.92] has joined #bitcoin-core-dev     
11:15 < wumpus> gmaxwell: that'd have been better; at least the keys would only be used to sign things in one format
11:15 < gmaxwell> Segwit script versioning would fix those challenges.
11:15 < CodeShark> yes, two chains might have very different redemption conditions for the same utxo
11:15 -!- nanomouse [~nonomouse@197.237.254.92] has quit [Remote host closed the connection]     
11:16 < Provoostenator> Hah, so you can do multisig messages? :-)
11:16 < sipa> Provoostenator: yes
11:16 < sipa> Provoostenator: and timelocked signatures :p
11:16 < Provoostenator> Or even partial messages?
11:16 < jtimon> gmaxwell: I think they should be handled with flags
11:16 < sipa> jtimon: yes, but the general property of softforks doesn't apply
11:16 < jtimon> oh, right, script versioning solves it too
11:16 < sipa> you don't want a "oh, i don't know this signature version! it's valid!!"
11:17 < gmaxwell> jtimon: the 'pubkey' needs to commit to the rules. pre-segwit style softforks don't. 
11:17 < gmaxwell> Well you can tristate:  Valid, invalid, unknown public key version.
11:17 < wumpus> right
11:17 < luke-jr> sipa: that's a risk for txs too, though
11:17 < jtimon> sipa: sure, I mean, this is out of the blockchain, so you just need to know which flags to use when validating...what gmaxwell said, commit to the rules
11:18 < gmaxwell> prior to having the explicit versions we couldn't do that, which is why we never even merged the patch in elements, much less brought it to bitcoin.
11:18 < luke-jr> why sighash flags can't fail valid
11:18 < gmaxwell> luke-jr: attacker controls signature side flags.
11:18 -!- nanymouse [~nonomouse@197.237.254.92] has quit [Remote host closed the connection]     
11:18 < luke-jr> gmaxwell: right, that's my point
11:18 -!- nanymouse [~nonomouse@197.237.254.92] has joined #bitcoin-core-dev     
11:19 < gmaxwell> same reason sighash flags can fail valid in bitcoin: If I pick an out of range sighash flag I could forge signatures for your pubkeys.
11:19 < sipa> ?     
11:20 < CodeShark> I also don't follow
11:20 -!- Krellan [~krellan@2601:640:4000:ab47:5841:9d8a:7994:5b02] has quit [Ping timeout: 252 seconds]     
11:20 < luke-jr> [19:16:56] <sipa> you don't want a "oh, i don't know this signature version! it's valid‼" <-- this is a problem for transactions just as much as for signed messages
11:20 < wumpus> are there any topics we really want to discuss in this meeting? I think we're drifting off a bit
11:20 < gmaxwell> You cannot trigger "unknown behavior, I'll let it pass" based on sighash flags like you can based on the content of public keys.
11:21 < cfields> next (quick) topic suggestion: codesigning keys update
11:21 < jnewbery> Other PRs I'd love to see merged for v0.16 are #10583 #10579 #11415 . They're all removing wallet dependencies from server, but are API changes so have a one release deprecation lag time before the dependency can actually be removed.
11:21 < gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
11:21 < gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
11:21 < gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
11:21 < jtimon> yeah, how about what "shortly after" means for 0.16 ?
11:21 < jonasschnelli> Two topic proposals: 1) review "nits" reduction, 2) bitcoin core code signing assoc.
11:21 < jonasschnelli> 2) goes in hand with cfields topicp.
11:22 < wumpus> jnewbery: thanks, I think adding all of them to high priority is a bit much, but we could add one
11:22 < wumpus> #topic codesigning
11:22 < cfields> I just wanted to point out that after researching for a bit, there's no painless way to renew our osx cert (without involving the btcf), so I think it's prudent that we explore other options.
11:22  * cfields passes the mic to jonasschnelli
11:22 < jonasschnelli> https://github.com/bitcoincore-codesigning-association
11:22 < achow101> wumpus: it seems like some of those are ready to be merged. they have utACKs and no comments left
11:22 < jonasschnelli> https://bitcoincorecodesigning.org
11:22 < jonasschnelli> The association stands and apple has accepted the entity
11:22 < jonasschnelli> Code sining certificates are ready (need to setup the key)
11:23 < cfields> jonasschnelli: oh that's fantastic! nice work :)
11:23 < wumpus> achow101: if they're ready for merge even better, please notify me of those things outside the meeting 
11:23 < jnewbery> wumpus: thanks. I think they're all pretty much ready for merge. achow101 has been doing a great job maintaining and rebasing them - perhaps just a bit more ACKing and they can go in
11:23 < jonasschnelli> We need a windows code signing cert... have never done that but I'm ready to order if someone gives instructions where and how
11:24 < wumpus> PSA: if something is ready for merge just let me know here instead of waiting for me to stumble on it accidentally :)
11:24 < BlueMatt> jnewbery: afaict only maybe the last is ready? the second only has one ack?
11:24 < achow101> wumpus: ok!
11:24 < BlueMatt> jonasschnelli: that was fast!
11:24 < wumpus> jonasschnelli: oh great!
11:24 < achow101> jonasschnelli: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
11:25 < cfields> achow101: note that a driver cert is different. More requirements.
11:25 < wumpus> getting a driver cert is much more difficult
11:25 < achow101> oh, didn't see that that was for drivers
11:25 < wumpus> I guess it should be, with the privilege level it operates at
11:26 < jonasschnelli> The question is if we want to try that distributed RSA key
11:26 < wumpus> we do
11:26 < BlueMatt> gmaxwell: mic?
11:26 < BlueMatt> or who was it who said they were gonna look into hooking it into a reasonable way to use it?
11:26 < cfields> I'll work on the CSR handling as promised. I assume we'll just have to shove the result back into the expected format.
11:27 < gmaxwell> I didn't think we were going to bother to do it for the first one. but this is going faster than expected! :)
11:27 < jonasschnelli> cfields: Yeah. Apple needs that -----BEGIN CERTIFICATE REQUEST-----
11:27 < achow101> BlueMatt: that was gmaxwell. I also wanted to take a look at it. it looked painful
11:27 < gmaxwell> it's not so painful but we need a process for converting raw RSA numbers into csrs and what not, which cfields was going to look into.
11:28 < gmaxwell> The easiest thing to do may be to just do trusted setup: generate the key normally on an offline machine, and we can split it after the the fact.
11:28 < BlueMatt> ugh     
11:28 < gmaxwell> the MPC signing is radically simple and faster than MPC key generation.
11:29 < BlueMatt> i thought the mpc generation was implemented?
11:29 < gmaxwell> Though the stuff I linked to does both. (though it's setup for only three parties atm)
11:29 < BlueMatt> i mean thats probably fine?
11:29 < BlueMatt> 3/3, I assume?
11:29 < achow101> gmaxwell: can it be done faster than what is already implemented?
11:29 < gmaxwell> achow101: of course, but do we care if it takes hours?
11:30 < wumpus> if it's a one-time thing we don't
11:30 < cfields> jonasschnelli: let's talk after the meeting. It'd be great if we could get a dummy to test with.
11:30 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:30 < gmaxwell> BlueMatt: yes 3/3. Generation you'd always do as n/n then potentially reshare to a different threshold. 
11:30 < jonasschnelli> cfields: sure
11:30 < BlueMatt> its not like this is holding a zksnark trusted-setup for all btc
11:30 < gmaxwell> How big are the keys they use for these things? 2kbit or 4kbit?
11:31 < Provoostenator> BlueMatt: would be nice to get another blog from P
11:31 < Provoostenator> l     
11:31 < sipa> ?     
11:31 < BlueMatt> ?     
11:31 < Provoostenator> Peter todd riding down Canada to generate his signing key.
11:31 < jonasschnelli> gmaxwell: 2048 is what my apple RSA keys are
11:31 < Provoostenator> And then bragging that's more secure than Zcash
11:31 < wumpus> indeed, it's just code signing, for one OS, if something is signed that is not validated by the gitian process that's discovered soon enough anyway
11:31 < gmaxwell> Provoostenator: it's totally unrelated.
11:31 < jonasschnelli> Code signing won't give a lot of additional security...
11:32 < jonasschnelli> It's just a UX thing IMO
11:32 < gmaxwell> zcash has a backdoor for the whole system, this is just some code signing crud.
11:32 < wumpus> right
11:32 < Provoostenator> I know.
11:32 < gmaxwell> the users shouldn't care AT ALL about the MPC we use for it, the purpose of the MPC is to protect the developers personally from being implicated in the unfortunate case their own computers get hacked.
11:32 < sipa> does the MPC generation have a trusted setup?
11:32 < gmaxwell> sipa: no.
11:33 < sipa> i assume not - if you're fine with trusted setup, just generate a single key and split it layer
11:33 < sipa> ok, so it is entirely unrelated
11:33  * jtimon is curious about the "review nits reduction" topic...
11:33 < wumpus> yes it's just to prevent the person doing the code signing from becoming a specific target
11:34 < jonasschnelli> review nit reduction topic?
11:34 < gmaxwell> sipa: it just uses paillier, and lots of roundtrips. it's pretty simple. 
11:34 < wumpus> #topic review nit reduction
11:35 < jonasschnelli> I just feel that we spend a lot of time in finding code-style nits, fixing code-style nits and some of the PRs are almost a single wall of nits... It doesn't seem to be efficient... I think..
11:35 < jonasschnelli> We should enforce the rules... ( I know I already brought that up )
11:36 -!- nanymouse [~nonomouse@197.237.254.92] has quit [Ping timeout: 268 seconds]     
11:36 < jonasschnelli> The libcurl project does that... it won't compile (make) if the code style doesn't matches
11:36 < jonasschnelli> It would reduce the review time a lot...
11:36 < jonasschnelli> And we apperently fixing the nits anyways at some point in time
11:36 < jtimon> you mean getting travis to complain about style nits?
11:36 < Provoostenator> Currently we're only running whitespace linter?
11:37 < jonasschnelli> jtimon: travis already does this... (whitespace)
11:37 < BlueMatt> if there were an easy way to apply it to new code only, I'd say thats probably fine
11:37 < jonasschnelli> I just want to get the code styling nits away from github comments
11:37  * jtimon nods
11:37 < BlueMatt> but it was my impression we were not able to find a way to do so
11:37 < jonasschnelli> BlueMatt: only new code. Yes.
11:37 < jtimon> BlueMatt: that was my understanding too
11:38 < wumpus> so have e.g. clang-format check the diff of pull requests?
11:38 < sipa> jonasschnelli: (brainstorming) or we could have a bot that marks a PR ready for review only after all nits are fixed
11:38 < jonasschnelli> wumpus: Yes. Can we enforce that somehow?
11:38 < jonasschnelli> sipa: Would also be something.. yes.
11:38 < sipa> so that people know not to look at something while there is still automated review going on
11:38 < wumpus> jonasschnelli: I don't know...
11:38 < Provoostenator> It would also help to offer some hints for developers how to run linters in their editor. I'll add an entry for OSX Atom once I figure it out myself.
11:38 < jtimon> didn't someone wrote something like that at some point?
11:38 < wumpus> sipa: as long as it doesn't generate noise (posts) that's ok with me
11:38 < wumpus> sipa: so if it works like travis, just adds another cross to the status
11:38 < jonasschnelli> Would something speak against enforcing the clang-format-diff check during make?
11:39 < wumpus> w/ a link to the list of problems
11:39 < sipa> wumpus: right,t hat would be nice
11:39 < meshcollider> BlueMatt: adding new linters to Travis would only affect PRs now since #11699
11:39 < gribble> https://github.com/bitcoin/bitcoin/issues/11699 | [travis-ci] Only run linters on Pull Requests by jnewbery · Pull Request #11699 · bitcoin/bitcoin · GitHub
11:39 < wumpus> but I don't want any bots that generate notifications in my mail
11:39 < sipa> right
11:39 < jonasschnelli> wumpus: Yes, That would disturb even more
11:39 < jonasschnelli> Just an indication if its ready to review...
11:39 < jonasschnelli> And so we can have less of those "brackets, spaces missing blabla"
11:40  * BlueMatt was always in favor, did we find out if we could get a reasonably stable output out of clang-format?
11:40 < BlueMatt> or was it always very version-dependant?
11:40 < jonasschnelli> It just feels some reviews are more or less a "clang-format diff output"
11:40 < wumpus> I like how golang handles that, they just have one true style
11:41 < wumpus> and their linter can be safely used in e.g. pull request checks, w/ no ambiguity
11:41 < jtimon> jonasschnelli: wouldn't we need to comply with clang format in the whole project before doing the clang check in make? has anyone seen haw many changes trying to apply clang-format to the whole project produces right now?
11:41 < morcos> do we have good developer documentation on how to do the right thing locally (not what the rules are, but how to check them?)
11:41 < sipa> you can apply clang-format on just the diffs
11:41 < meshcollider> jtimon: not if it's only run on the diff
11:41 < jonasschnelli> yes     
11:41 < sipa> but clang-format only checks whitespace/newlines
11:41 < wumpus> morcos: good point!
11:41 < sipa> it doesn't check variable names etc
11:41 < jonasschnelli> morcos: we should focus on that
11:41 < gmaxwell> A small amount of code style nits on github are probably good for teamwork.
11:42 < wumpus> sipa: I think that's fine, those are the ones we want out of the way
11:42 < jonasschnelli> sipa: not sure if that is possible
11:42 < jtimon> meshcollider: right, only for pr diffs, yeah, I thought he meant every time you build locally
11:42 < wumpus> sipa: variable names are more of a human thing anyhow
11:42 < wumpus> sipa: so it's fine if humans comment on them
11:42 < morcos> i'd be happy to do more locally, i'm sure my PR's are disasters, but it would be nice if a good workflow was spelled out
11:42 < jonasschnelli> morcos: Indeed
11:42 < meshcollider> Scripted diffs will probably regularly require style change commits too to keep Travis happy
11:42 < jtimon> gmaxwell: there's always style nits that go beyond clang-format
11:43 < wumpus> I mean it could check basic things like is_this_snake_case for variable names in theory, but not whether it's a good name in the first place...
11:43 < sipa> sur     
11:43 < jonasschnelli> yes     
11:43 < jonasschnelli> It's more about the naming convenction (m_, snake_case, CONSTANTS, etc,)
11:43 < wumpus> and the latter is much more important for maintainablility :-)
11:43 < kanzure> do we have a clang-format file
11:43 < MarcoFalke> meshcollider: I'd prefer if we didn't use clang-format in scripted diffs. Makes it impossible to reproduce ...
11:43 < gmaxwell> jtimon: yes true enough, I guess my point was that they're not all bad.
11:43 < wumpus> kanzure: yes
11:43 < jonasschnelli> kanzure: yes
11:44 < wumpus> contrib/devtools/clang-format-diff.py
11:44 < wumpus> src/.clang-format
11:44 < kanzure> ah thanks.
11:44 < cfields> i assume it'd be possible to setup a git alias that shows the current diff, diff'd against the clang-format result
11:44  * cfields plays around
11:44 < jonasschnelli> MarcoFalke: are you up to write a higher level documentation for the clang-format-diff.py workflow?
11:44  * MarcoFalke proposed to add '.style.yapf' and hides
11:44 < jtimon> wumpus: right, that's what I remember being written
11:44 < MarcoFalke> jonasschnelli: I did
11:45 < MarcoFalke> git diff | cfd
11:45 -!- jointek [~w33d@cpe-86-58-102-221.static.triera.net] has joined #bitcoin-core-dev     
11:45 < wumpus> yapf?
11:45 < gmaxwell> general problem with clang format is that it isn't stable across versions, or at least hasn't been historically. In general we don't have a highly consistent enviroment htat people contribute from.
11:45 < ryanofsky> fwiw, i am not bothered by nits whatsoever. at the very least they mean somebody is actually looking at my pr. i also use clang-format and clang-format diff all the time
11:45 < wumpus> gmaxwell: right, that has always bothered about it
11:45 < jonasschnelli> gmaxwell: yeah. that
11:45 < MarcoFalke> also what gmaxwell said
11:45 -!- jointek [~w33d@cpe-86-58-102-221.static.triera.net] has left #bitcoin-core-dev []     
11:45 < MarcoFalke> wumpus: The same thing for python
11:45 < jtimon> well, the version can be fixed on travis, though
11:46 < wumpus> MarcoFalke: that's not very shocking
11:46 < jonasschnelli> ryanofsky: nits should still remain... just not stuff that computers can find and are covered by our code styling rules
11:46 < sipa> jtimon: right, but that makes travis effectively part of your workflow, which is unfortunate
11:46 < wumpus> you need to be able to run any checks that travis does locally
11:46 < sipa> jtimon: as in, you won't really know a PR is acceptable before pushing and waiting for travis
11:46 < gmaxwell> We could give developers a VM image or equivilent, but it's asking a lot.
11:46 < jtimon> sipa: right, or the concrete version if I want to run it locally first
11:47 < luke-jr> Travis is slow, too
11:47 < sipa> maybe someone should investigate how stable clang-format/ clang-tidy/ iwyu/ ... are
11:47 < morcos> my issue with the nits on PR's is it leads to sloppier review.  When nits get fixed and potentially rebased.  Prior reviewers can get sloppy about assuming that the final version is well reviewed, especially if its happened repeatedly
11:47 < jonasschnelli> Could we not do a check with clang-format-diff.py during "make" and at least place a bold warning (or even refuse to compile *duck*)
11:48 < achow101> jonasschnelli: it would blow up on existing code
11:48 < sipa> jonasschnelli: the problem is that different clang-format versions say different things
11:48 < jonasschnelli> sipa: significant?
11:48 < sipa> jonasschnelli: irrelevant, i think
11:48 < wumpus> jonasschnelli: 'make lint' would be nice
11:48 < sipa> and making something work on your own system, and then seeing travis complain about the exact same things but requiring something else would be pretty demotivating
11:48 < wumpus> jonasschnelli: that would just run all the checks, for C/C++, for python, for whitespace in docs, etc
11:48 < cfields> wumpus: +1
11:48 < gmaxwell> morcos: that is more a problem with the intermixing of nits and serious review, and also how github handles tracking comments (them magically vanishing when the code changes)
11:49 < jonasschnelli> wumpus: Maybe it should by bypassable, but the novice contributor should get warned if he uses invalid code-styling
11:49 < sipa> gmaxwell: that's no longer true with the 'review' function
11:49 < gmaxwell> Obviously we should just pull clang into our code tree and ship it too. :P 
11:49 < sipa> you can see all former review comments, and the code they apply on
11:49 < wumpus> jonasschnelli: well, travis and the person that merge can also check
11:49 < jtimon> sipa: oh, that's what is for...
11:49 < instagibbs> sipa, interesting, more reason to use it
11:49 < wumpus> jonasschnelli: it just should be possible to do it locally too
11:49 < morcos> gmaxwell: yes, i'd argue that once serious review stars, nits should not be squashed, but should be left as a cleanup commit at the end.  (at least of some kinds)
11:49 < sipa> jtimon: yes, you should use it :)
11:49 < wumpus> jonasschnelli: I'm not so much concerned with forcing people to run it but making it easy
11:50 < jonasschnelli> wumpus: yes. Travis code style check is not what we want in the first place (it helps,.. but you want to catch it before)
11:50 < sipa> something i have noticed is that sometimes 'nit' reviews start on PRs which are far from certain they'll be even concept ACKed
11:50 < wumpus> jonasschnelli: well if you don't do it before, travis will stop you and you need to wait longer, simple as that :)
11:50 < instagibbs> morcos, we might need to have guidelines for "ACK lockin"
11:50 < jonasschnelli> Okay... I'll have a look at lint and something simple within the make-process
11:50 < jonasschnelli> sipa: that also
11:50 < cfields> morcos: i have no problem with squashing nits as the pre/post-squash can be diff'd locally. It's rebasing to master that makes re-review a challenge imo.
11:51 < wumpus> sipa: yeah... then it adds even more nosie
11:51 < instagibbs> cfields, can be diffed if you locally checked 
11:51 < sipa> cfields: right, i try to avoid rebasing, but i pretty liberally squash nits
11:51 < instagibbs> many times im just reading off of github(lazy)
11:51 < sipa> cfields: and i don't mind others doing that too, except for very complicated PRs
11:51 < instagibbs> unless it's a particularly intense series of commits
11:51 < achow101> instagibbs: that kind of breaks when there's lots of merge conflicts
11:51 < wumpus> sometimes I wish 'git fetch' could fetch by commit id to fetch individual commits, unfortunately that doesn't work
11:51 < cfields> pretty sure github can show the diff from a squash a well, you just have to come up with the url for it
11:52 < gmaxwell> well we have contributors who don't feel comfortable (or just don't have the expirence) to do much other than nit reviews. Their contributions are usually pretty helpful and I wouldn't want to ask most of them to stop. We could perhaps ask them to wait a day on new PRs so that there is at least time for Concept NAKs to show up first.
11:52 < wumpus> it can only be used with branch names
11:52 < wumpus> github can give you the patch for an arbitrary commit id though, but it's kind of annoying to do automatically
11:52 < gmaxwell> it is a little sad for someone to show up with a change, and then have two cycles on trivial changes before someone more expirenced comes in and says no-way-because-x.
11:53 < wumpus> gmaxwell: yeah...
11:53 < aj> gmaxwell: might be helpful to tag PRs as looking for concept acks vs looking for nits and style vs looking for tested acks and merging?
11:53 < MarcoFalke> wumpus: We could set up a bot to create branches for each utACK that is posted to gh
11:53 < instagibbs> not nitting a PR that doens't have any ACKs of any kind seems like a decent rule
11:53 < MarcoFalke> on a separate repo that is
11:53 < wumpus> MarcoFalke: that'd be kind of nice
11:53 < jtimon> cfields: at the same time rebasing is often good, for example, #8994 could unexpectedly start failing tests even if no new conflicts appear and github says it's all ready to merge it
11:53 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
11:53 < wumpus> rebasing is often necessary
11:53 < jonasschnelli> Yes. What aj says. The things is just, unenforced user rules tend to get ignored. :)
11:53 < Provoostenator> gmaxwell: as long as you learn something from the nits, it's not the end of the world having them concept-nacked later, imo 
11:53 < MarcoFalke> then `git fetch bitcoin_reviewed_commits` will get you all the reviews
11:54 < gmaxwell> sometimes you don't know what you're going to do when you read it.. there are certantly PRs where I read them and then come away with no real opinions on it other than "you missed some braces here and there"
11:54 < wumpus> some files are hotspots and generate a lot of merge conflicts
11:54 < wumpus> although it's better now that main.cpp is dead
11:54 < gmaxwell> Provoostenator: no, but some people find it demotivating; 'they made me do more work then threw it out'. :)
11:54 < Provoostenator> True
11:54 -!- karelb [b99c7828@gateway/web/freenode/ip.185.156.120.40] has quit [Quit: Page closed]     
11:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
11:55 < wumpus> Provoostenator: these are not the kind of nits that help you learn btter programming :)
11:55 < gmaxwell> Provoostenator: that can be resolved with a better perspective; bitcoin development is a distributed process, your effort is your contribution not the fact that it was merged, etc. 
11:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
11:55 < jonasschnelli> gmaxwell: indeed
11:55 < gmaxwell> Provoostenator: but we can't really send every new contributor to a zen mastery class before they contribute.
11:56 < Provoostenator> Well, we could... but that would be flagged as spam :-)
11:56 < wumpus> Provoostenator: if it's a nit like 'it's better to use build in function X' or 'the loop can be more efficiently written like this' then I think it's great
11:57 < cfields> a slightly different work-flow might be: create a "fixed nits" commit on top of the branch, and squash all nits into that as they arise. Then merge that in without squashing.
11:57 < cfields> it makes for ugly commits getting merged in, but avoids the re-review after squash-for-nits issue.
11:57 < Provoostenator> So far I find most of the nits I received useful. They either taught me to look up coding practices, or motivated me to figure out how to run a linter.
11:57 < gmaxwell> a challenge with that is that we do get new contributions from people with zero git expirence.
11:58 < sipa> who think they need to open a new PR to fix a nit :)
11:58 < wumpus> the git basics stuff is explained pretty well in the contributing doc nowadays
11:58 < aj> do people think the +1, +0, -1, concept nak/ack thing from https://github.com/bitcoin/bitcoin/pull/11426#issuecomment-334091207 is good btw?
11:58 < wumpus> I've not gotten the question on how to squash a commit for a long time now
11:58 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
11:58 < gmaxwell> wumpus: I've noticed that, I wondered why.
11:59 < Provoostenator> Some projects make a giant squashed merge commit and just point to the original PR (e.g. AngularJS), but that's not ideal for other reasons.
11:59 < instagibbs> oh that's where -0 came from
11:59 < BlueMatt> aj: yes, I'm a fan
11:59 < wumpus> Provoostenator: we only want to encourage squashing when it's iterative changes, not atomic separate changes
11:59 < jtimon> aj: I would have preffered that BlueMatt had maintained a nack but answered my questions/rebute, to be honest
11:59 < BlueMatt> specifically caues we end up with lots of need for concept review
12:00 < BlueMatt> we have lots of prs where lots of folks are +0/-0 and dont think its worth review
12:00 < BlueMatt> but they sit open for months
12:00 < BlueMatt> which is bad
12:00 < MarcoFalke> +0 on end meeting
12:00 < BlueMatt> +1     
12:00 < instagibbs> -0     
12:00 < wumpus> oh, it's that time already
12:00 < wumpus> #endmeeting
12:00 < lightningbot> Meeting ended Thu Nov 30 20:00:33 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.log.html
12:01 < instagibbs> so hold on, the numbers are for what? pre-ACK reflection on idea?
12:01 < BlueMatt> generally, ive been usint them as that, yea
12:01 < MarcoFalke> warren: I tested it in august. Should still work, as the vm-builder is compiled from source
12:01 < BlueMatt> see aj's link
12:01 < wumpus> did we just spend an hour talking about nits and code signing, oh - also the signmessage thing :-)
12:01 < BlueMatt> yes :(
12:01 < jtimon> BlueMatt: if they are worth merging I don't think it's bad they sit open for months, even if a couple of  folks said -0
12:01 < instagibbs> wumpus, 0.16 release too
12:01 < BlueMatt> spent an hour talking about how we waste time on nits
12:01 < MarcoFalke> warren: We do that on debian and ubuntu, so I sticked with it
12:01 < wumpus> BlueMatt: lol!
12:01 < wumpus> instagibbs: yes, you're right
12:01 < morcos> didn't you guys have a libevent topic
12:01 < aj> instagibbs: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions is the apache link
12:01 < instagibbs> BlueMatt, more irc meetings until throughput increases
12:01 < BlueMatt> wumpus: <BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
12:02 < jtimon> so, yeah, how long is "shortly after" for 0.16 ?
12:02 < Provoostenator> Is there a safe way to make Travis cache more stuff? It's insanely slow.
12:02 < BlueMatt> fuck, we forgot to talk about cfields' libevent question :(
12:02 < BlueMatt> that actually mattered
12:02 < instagibbs> feel free to talk on it
12:02 < morcos> well if you, wumpus and cfields are here, you can still talk
12:02 < cfields> it's ok, I'm still investigating something locally
12:02 < gmaxwell> too bad we're not allowed to talk about things except in meetings :(
12:03 < Dizzle> Has libevent merged pass-in-your-own-socket yet?
12:03 < cfields> heh     
12:03 < cfields> The specific issue is how to deal with #11785
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
12:03 < wumpus> Dizzle: I don't think so
12:03 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
12:04 < wumpus> Dizzle: at least not for the http client, if you mean that, there's ton of ways to pass your own socket but not there
12:04 < cfields> I'm not convinced that we can fix it entirely, so it remains unclear what to do about it
12:04 < Dizzle> wumpus: thanks, that's what I was wondering about. stratum wallet and stratum mining projects are looking forward to unix socket RPC
12:04 < gmaxwell> well we could always merge some code that tries to increase our FD count, but thats not a fix.
12:05 < instagibbs> aj I still don't see the exact relationship between the numbers and ACKs.
12:05 < wumpus> BlueMatt: you mean #10279 for high priority for review?
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
12:05 < BlueMatt> yes     
12:05 < instagibbs> seems to be concept ACK on sliding scale
12:05 < wumpus> Dizzle: do you need it to be in bitcoin-cli for that?
12:05 < cfields> gmaxwell: the second part of the PR does that, but that makes me really nervous :(
12:06 < aj> instagibbs: +1 -1 = concept ack / concept nak; in between is "leaning this way or not, but not decided either way"
12:06 < wumpus> Dizzle: we could just merge the server side, then you can use it from your own code, just not the command line
12:06 < Dizzle> wumpus: nope, most pools and electrum servers use json-rpc themselves for that.
12:06 < Dizzle> that would be neat!
12:06 < instagibbs> aj ok so it is a replacement for concept acks... that makes more sense
12:06 < BlueMatt> mostly I love -0 - I dont think this is worth anyone's time to review, but if others want to, fine
12:06 < instagibbs> wumpus, speaking of merge ready, 10677
12:06 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 248 seconds]     
12:06 < Dizzle> BTW, if anyone's curious how Electrum implements message signatures on native segwit addrs, we just iterate through the possible address types until there's match: https://github.com/spesmilo/electrum/blob/66cce115ef93c913d65ef5c7d781c8065f79bbaf/lib/bitcoin.py#L632
12:06 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has left #bitcoin-core-dev ["Leaving"]     
12:07 < gmaxwell> cfields: don't we have to eliminate the use of select before we go increasing the default maximum beyond FD_SETSIZE?
12:07 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
12:07 < wumpus> Dizzle: I don't think it's awfully useful in bitcoin-cli anyhow though it's useful for testing (though OTOH, the patch also changed the RPC testing framework to be able to use UNIX sockets)
12:07 < wumpus> instagibbs: ok
12:07 < cfields> gmaxwell: I believe the limit becomes FD_SETSIZE*2 if you're using 2 select loops?
12:07 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
12:07 -!- photonclock_ [~photonclo@47.37.153.193] has quit [Remote host closed the connection]     
12:08 < wumpus> cfields: no
12:08 < gmaxwell> to my great shame I seem to have forgotten how select is implemented internally. :P
12:08 < wumpus> cfields: select limits the max fd, using multiple selects doesn't change that
12:08 < wumpus> we should probably have switched to poll a long time ago
12:09 < wumpus> IIRC there have been PRs for that, but rejected because libevent P2P was just around the corner...
12:09 < gmaxwell> cfields: we've been waiting forever for the great networking refactors to eliminate the use of select, but perhaps this is a mistake-- select on windows scales fine, and switchin to poll on *nix is a couple line patch IIRC.
12:09 < cfields> well regardless, libevent is using epoll/kqueue/etc. here, so the select limits don't (or shouldn't) apply to rpc
12:09 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds]     
12:09 < wumpus> cfields: no, but the fd's used might be in select's limit!
12:10 < wumpus> cfields: if 1024 fd's are used, then select is dead, no matter who claimed them
12:10 < gmaxwell> cfields: yes, but if we increase the process FD count, we're going to end up with FDs with high numbers which I thought broke select but as mentioned since I seem to have forgotten how it works internally I could be confused.
12:10 < wumpus> gmaxwell: you're right
12:10 < wumpus> cfields: you're right that RPC itself won't be affected, but it still messes up P2P nevertheless
12:10 < cfields> ok, i was confused about the limit then.
12:11 < gmaxwell> cfields: basically as-i-fake-recall the FD number itself is converted into a position in the array, so if you only have 8 FD's monitored but one of them has number 21318 you're going to be in trouble.
12:11 < wumpus> gmaxwell: yup the fd number is converted to a bit position in the array
12:11 < wumpus> which is also what makes it so inefficient
12:12 < wumpus> if it is a sparse array....
12:12 -!- photonclock_ [~photonclo@47.37.153.193] has joined #bitcoin-core-dev     
12:12 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-blawebgnrnbchrva] has joined #bitcoin-core-dev     
12:12 < gmaxwell> I believe bluematt wrote a very small patch to change bitcoin to poll.  We could take, that and wrap it in ifdefs so we still select on windows, and call that sub-issue done.
12:12 < BlueMatt> none of these things solve the problem....
12:13 < BlueMatt> the issue ends up being in eg leveldb
12:13 < gmaxwell> BlueMatt: no but it lets you increase the process limit above 1024.
12:13 < BlueMatt> i mean it'll blow up our p2p first, but mostly thats not a big deal
12:13 < wumpus> does leveldb use select?
12:13 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
12:13 < gmaxwell> since when does leveldb use select?
12:13 < wumpus> I don't hink so
12:13 < BlueMatt> wumpus: no, in this case we literally ran out of process fds
12:13 < wumpus> leveldb only croaks if you run out of all process fds
12:13 < wumpus> which is what vii's patch more or less solves
12:13 < gmaxwell> As I said above: increasing the count isn't a _fix_; ... but it's a pretty good mitigation.
12:14 < wumpus> at least the obvious 'attack RPC with tons of separate connections' doesn't work as an exhaustion attack anymore after that
12:14 < BlueMatt> increasing the count also mostly doesnt break p2p, p2p will just keep opening new sockets until it gets a low numbered one
12:14 < cfields> wumpus: unfortunately, it doesn't :(
12:14 < wumpus> cfields: oh?
12:14 < BlueMatt> its smart enough to handle it
12:14 < gmaxwell> BlueMatt: really? what? lol.
12:14 < cfields> wumpus: nah, i can still exhaust the FDs with little effort.
12:15 < BlueMatt> i mean its not *that* smart, eg it will fail each connection
12:15 < BlueMatt> but it wil lkeep trying to make connections
12:15 < wumpus> cfields: so we really need a fix at the libevent side?
12:15 < gmaxwell> BlueMatt: so if an incoming connection has a high FD number it just drops it?
12:15 < BlueMatt> yes     
12:15 < wumpus> it's interesting as I did load tests when I started using libevent and never stumbled on this
12:16 < gmaxwell> thats really ugly, and doesn't let us increase the maximum, consider, we make the maximum 65536... and the most of your connections start getting dropped. :)
12:16 < cfields> wumpus: yes. Problem is that it does while(something){accept()...}
12:16 < wumpus> if I only had known its http server was so crappy :(
12:16 < cfields> so if you manage to make a shitload of connections while it's in that loop, it'll keep swallowing 'em
12:16 < BlueMatt> gmaxwell: i mean if your rpc is getting flooded you probably want to drop most connections :p
12:16 < BlueMatt> cause you're already overloaded
12:16 < wumpus> BlueMatt: yes, you want to drop them
12:17 < wumpus> BlueMatt: that would be the right solution, not hoard file descriptors
12:17 < gmaxwell> BlueMatt: yea sure but I think the FD assignment is next highest in range until it hits the maximum, not lowest available.
12:17 < wumpus> AFAIK fd assignment is lowest available on many OSes
12:17 < BlueMatt> hmm, my node doesnt seem to break and i run with high fd limit
12:17 < gmaxwell> okay, I needed to be wrong about at least one thing.
12:17 < BlueMatt> so....dont think so on linux?
12:17 < gmaxwell> BlueMatt: without the poll patch?
12:18 < BlueMatt> yes, without
12:18 < wumpus> try to close stdout and the next fd you open :-)
12:18 < BlueMatt> i stopped using it and you can still get something like 800 maxonncections
12:18 < gmaxwell> gessh comeone we should just switch to poll, if its *nix only it should be a dozen line patch. 
12:18 < gmaxwell> wumpus: lol. 
12:18  * BlueMatt 's point is that it is almost entirely irrelevant to this issue
12:19 < wumpus> it's still relevant though
12:19 < gmaxwell> well increasing the fd count would change the urgency.
12:19  * BlueMatt 's point is we can increase fd count today
12:19 < BlueMatt> without poll
12:19 < wumpus> maybe not for this specific issue, but there's no good reason at all we're still using select, it only has drawbacks
12:20 < BlueMatt> fair
12:20 < gmaxwell> I really don't want to troubleshoot mysterious connection failures from "your FD was too high"
12:20 < Dizzle> Does select do ok on macOS? If not, would need to add kqueue polling to those 12 lines of code.
12:20 < gmaxwell> oh right osx poll is broken isn't it?
12:21 < wumpus> how is poll broken on osx?
12:21 < gmaxwell> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
12:22 < gmaxwell> sounds like they've fixed it, broken it again, and fixed it.
12:22 < wumpus> lol I'm not surprised, even validating the root password seems to be too difficult for them
12:22 < cfields> iirc they're just flip-flopping on undefined return values?
12:23 < gmaxwell> yea, it seems like that the case discussed there should be easy to avoid.
12:23 < wumpus> they took poor old freebsd and turned it to crap
12:23 < Dizzle> Of note, in addition to the issue that blog mentions, macOS' poll doesn't work on devices.
12:24 < gmaxwell> but shiny plastic crap
12:24 < gmaxwell> we only need it on sockets.
12:24 < wumpus> indeed, that doesn't matter
12:25 < wumpus> windows can't do select on devices or files either,we don't use that
12:26 < gmaxwell> BlueMatt: where is that poll patch?
12:26 < BlueMatt> uhhhh, lost?
12:26 < BlueMatt> i dunno
12:27 < Dizzle> I feel like ifdefing kqueue isn't a big stretch if we're already ifdefing poll. Python project ended up with a selector selector API on top of all this: https://docs.python.org/3/library/selectors.html#selectors.DefaultSelector
12:27 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 240 seconds]     
12:28 < gmaxwell> Dizzle: no probably not but whats the gain? 
12:28 < Dizzle> performance and it works on those few versions of OS X with the broken poll
12:28 < gmaxwell> the performance differences are negligible for our sorts of usage.
12:29 < cfields> Dizzle: there's an abstraction that's done-ish, waiting on pre-requisites to go in. It uses epoll/kqueue/poll/etc. The poll discussion here arose because presumably it'd be simple.
12:29 < wumpus> on the fd assignment, this prints "0" on linux 4.10.0 https://gist.github.com/laanwj/8125d4971728dcfe85f6f5bd09dd572f , so at least anecdotally linux seems to assign the first available fd
12:29 < wumpus> Dizzle: that's why the goal is to move P2P to libevent, it already handles all those polling methods
12:29 < Dizzle> cfields: this abstraction on libevent or bitcoin core?
12:29 < cfields> yea     
12:29 < Dizzle> OK, great. Sorry for the noise then :)
12:30 < wumpus> we really don't want to replicate all of that 
12:30 < gmaxwell> the general problem with more ifdef paths is less coverage, the majority of the developers are are on linux, as are the majority of serious technical users who will try strange things and actually report results.
12:30 < cfields> #11227
12:30 < gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
12:30 < gmaxwell> so we should have a strong general preference to minimize platform ifdefs just on the basis that if we introduce a bug in one of them, it may take a long time to discover and fix.
12:30 < cfields> wumpus: as a data point, even with #11785, i can exhaust all handles via rpc in a minute or two.
12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
12:31 < wumpus> at least the low-level libevent stuff is well tested
12:31 < gmaxwell> yes, at least libevent gets testing by other people.
12:31 < cfields> So I'm not sure that it's worth adding work-around hacks
12:31 < wumpus> cfields: so what can we do? (except say "don't do this")
12:31 < wumpus> I mean it's kind of sad to DoS yourself
12:32 < bitcoin-git> [bitcoin] luke-jr opened pull request #11803: Bugfix: RPC/Wallet: Include HD key metadata in dumpwallet (master...bugfix_dumpwallet_hdkeypath) https://github.com/bitcoin/bitcoin/pull/11803
12:32 < wumpus> and outside of localhost I doubt you'll ever accomplish such a rate
12:32 < gmaxwell> Though I think our general expirence with dependencies (including, sadly, libevent) is that we still run into bugs in them... in part because everything everywhere is broken, and small brokenness in most things is just background noise. ... so the fact that dependency foo is widely used helps less than we might guess.
12:32 < wumpus> that's just a fact of life, everything has bugs
12:33 < cfields> wumpus: yea, i'm not really sure
12:33 < gmaxwell> split rpc into another process. :P
12:33 < wumpus> I mean we even find gcc bugs
12:33 -!- Krellan [~krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
12:33 < wumpus> if anything should be well-tested...
12:33 < gmaxwell> wumpus: yea, well I used to comment that I was worried about our testing because we weren't finding GCC bugs. Glad thats fixed now. :)
12:34 < cfields> gmaxwell: yea, i expected some opposition, especially as these bugs crop up. I'd be ok with doing our own abstractions if it came down to it.
12:34 < wumpus> cfields: could we patch it at the libevent side?
12:34 < wumpus> cfields: I think trying to fix it in bitcoind is looking at it the wrong way
12:34 < gmaxwell> I think we should fix libevent.
12:34 < wumpus> cfields: it's a libevent bug
12:34 < cfields> wumpus: yea, pretty easily I believe
12:35 < wumpus> cfields: trying to work around upstream issues (at least permanently) instead of fixing them is pretty not done in open source
12:35 < cfields> through it might kill performance in some applications, so I'm not sure they'd want it upstream
12:35 < gmaxwell> and in the short term apply some mitigations in bitcoin, like increasing the FD count (ugh but I really don't like counting on FD magnitude sniffing)
12:35 < cfields> *though
12:35 < gmaxwell> cfields: surely exausting a processes' FDs isn't a cool move.
12:35 < wumpus> cfields: I don't think they care about performance in the http server
12:36 < cfields> wumpus: well it's in the listener, which is intended to be generic. The http server is just a user
12:36 < cfields> but yes, I'll do up a patch
12:36 < Randolf> [Syntax]:  That's a nice way to encourage people.  I like that.
12:36 < gmaxwell> among other things, it can contribute to amazing security vulns and remote crashes when it makes it impossible to open /dev/urandom to get randomness. 
12:36 < Randolf> Whoops, sorry, wrong channel.
12:37 < wumpus> cfields: so the bug is deeper than just the http server, and woudl affect other clients (such as tor) as well?
12:37 < wumpus> cfields: now I'm interested :)
12:37 < cfields> wumpus: I'm unsure who/what else uses the listener
12:37 < BlueMatt> cfields: having a limited queue is a simple patch upstream *should* do
12:38 < cfields> i assume their dns server, as a quick example
12:38 < BlueMatt> so you can crash their dns server with enough tcp traffic?
12:39 < cfields> sec, checking
12:39 < gmaxwell> FWIW speaking of urandom, we'll assert if the open fails, so if you didn't know it this exhaust issue probably also causes (safe) crashes for us. 
12:40 < wumpus> gmaxwell: yes luckily we check for that
12:41 < cfields> ok no, they only use the listener internally for http
12:41 < BlueMatt> what else uses libevent's http server?
12:41 -!- andrelam [~Mutter@179.223.105.169] has joined #bitcoin-core-dev     
12:41 < wumpus> cfields: I have a tor checkout here, anything I can easily grep for to see if they use it?
12:41 < BlueMatt> anything should be crashable
12:41 < cfields> wumpus: evconnlistener
12:42 < wumpus> cfields: no matches
12:42 < cfields> whew :)
12:43 < wumpus> they also don't use evhttp
12:45 -!- andrelam [~Mutter@179.223.105.169] has quit [Quit: Mutter: www.mutterirc.com]     
12:45 < wumpus> they do have a http client in src/or/directory.c but apparently they rolled their own there
12:45 < wumpus> eh not that the client would suffer from this
12:46 -!- andrelam [~Mutter@179.223.105.169] has joined #bitcoin-core-dev     
12:49 < wumpus> still, there might be tons of things out there that use it
12:50 < wumpus> so if this can be triggered over the network it might still be reasonably serious
12:50 -!- Hen_ [~Hen@62-243-108-58-static.dk.customer.tdc.net] has joined #bitcoin-core-dev     
12:52 < wumpus> gah why are code search engines so useless
12:52 < wumpus> find 1000 forks of libevent, of course they have that string
12:53 -!- Hen_ [~Hen@62-243-108-58-static.dk.customer.tdc.net] has quit [Client Quit]     
12:53 < cfields> testing a patch
12:54 < wumpus> cfields: cool
12:55 -!- jack__ [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: jack__]     
12:56 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
13:00 -!- Ahia [6d4224c7@gateway/web/freenode/ip.109.66.36.199] has joined #bitcoin-core-dev     
13:02 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
13:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:16 -!- JackH [~laptop@212.123.9.170] has joined #bitcoin-core-dev     
13:20 -!- gitju [~gitju@5.230.145.49] has quit [Quit: Leaving]     
13:21 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
13:25 -!- andrelam [~Mutter@179.223.105.169] has quit [Remote host closed the connection]     
13:25 -!- andrelam [~Mutter@179.223.105.169] has joined #bitcoin-core-dev     
13:33 -!- owowo [ovovo@gateway/vpn/mullvad/x-ikbedbhzepafyfwo] has quit [Ping timeout: 240 seconds]     
13:39 -!- jezeba [~jezeba@c-73-240-117-56.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
13:39 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit []     
13:40 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 248 seconds]     
13:41 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
13:42 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit [Client Quit]     
13:43 -!- jezeba [~jezeba@c-73-240-117-56.hsd1.or.comcast.net] has quit [Quit: leaving]     
13:44 -!- Ahia [6d4224c7@gateway/web/freenode/ip.109.66.36.199] has quit [Ping timeout: 260 seconds]     
13:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:46 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
13:48 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer]     
13:49 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Quit: Leaving]     
13:50 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
13:51 -!- andrelam [~Mutter@179.223.105.169] has quit [Quit: Mutter: www.mutterirc.com]     
13:52 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev     
13:55 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
13:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:57 -!- alreadylate [~textual@c-250e71d5.153-1-64736c10.cust.bredbandsbolaget.se] has quit []     
14:03 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 255 seconds]     
14:05 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
14:05 -!- warxhead [warxhead@c-73-243-180-191.hsd1.co.comcast.net] has quit []     
14:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]     
14:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:12 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
14:13 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e38d357447e...fbce66a98267
14:13 < bitcoin-git> bitcoin/master 680bc2c practicalswift: Use range-based for loops (C++11) when looping over map elements...
14:13 < bitcoin-git> bitcoin/master fbce66a MarcoFalke: Merge #10493: Use range-based for loops (C++11) when looping over map elements...
14:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
14:22 -!- Vision [~Vision@97-85-227-163.static.stls.mo.charter.com] has joined #bitcoin-core-dev     
14:23 < Vision> where are the proxy settings stored for bitcoin-qt?   I cleared the proxy settings in the Options dialog, and now entering the settings dialog causes a crash.  definitely a bug.
14:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
14:24 < meshcollider> Vision: what operating system?
14:24 < Vision> meshcollider: windows
14:25 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
14:25 < meshcollider> Vision: in that case, the options will be in the registry, under HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt iirc
14:26 < wumpus> Vision: what version?
14:26 < wumpus> (of bitcoin core)
14:26 < Vision> 15.1 64-bit
14:26 < wumpus> there was a bug in 0.15.0 which caused crashes in the settings dialog, this was fixed in 0.15.0.1 and 0.15.1
14:26 < wumpus> ok     
14:26 < meshcollider> Vision: please let us know what values are in the registry before you modify them
14:26 < Vision> will do
14:26 < Vision> cuz yeah this is kinda catastrophic
14:26 < wumpus> it's better to use the flag to clear the gui settings
14:27 < wumpus> it will automatically make a backup
14:27 < meshcollider> wumpus: depends if he wants to clear all settings or just fix the proxy issue manually though :)
14:27 < wumpus> run  bitcoin-qt with -resetguisettings
14:27 < Vision> looks like addrProxy is :10
14:27 < wumpus> this resets the settings and creates a guisettings.ini.bak with the old settings for troubleshooting
14:27 < Vision> lemme change that alone and see if that fixes
14:28 < achow101> start with -resetguisettings and then drop the backup file here
14:28 < wumpus> how did you manage to get :10 in there?
14:28 < meshcollider> just :10 with no IP?
14:28 < Vision> wumpus: clearing the boxes.
14:28 < Vision> I think :10 was the port
14:28 < Vision> maybe I left the port in
14:28 < Vision> and cleared just the IP
14:29 < Vision> meshcollider: indeed
14:29 < achow101> oh, I know how it crashed
14:29 < wumpus> strange, it shouldn't save in that case, but yeah possible
14:29 < Vision> oh it saved alright.
14:29 < achow101> it splits on the colon and does [0] and [1] to get the right params. that'll be an index out of bounds
14:29 < achow101> if there's no IP and just :port
14:30 < Vision> aha :D sounds like a culprit achow101.
14:30 < Vision> yeah I guess I just cleared the IP and not port
14:30 < Vision> and fixing that in the registry DID clear up the cache.
14:30 < Vision> CRASH*
14:30 < Vision> wtf. I swear I'm not retarded.
14:30 < achow101> I don't know how it let that save though
14:31 < Vision> once I finish what I was doing I may try to replicate it
14:31 < Vision> I swear I saw the '10' jump into the IP box before the dialog closed.
14:31 < Vision> if that helps
14:32 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 250 seconds]     
14:33 < Vision> aaaand I think it crashed instantly at that point.
14:36 < wumpus> it's clearly possible, though it might be that you stumbled on a very unlikely race condition. The parsing code really shouldn't crash on invalid input anyhow.
14:36 < Vision> aye     
14:38 < meshcollider> Vision: were you using port 10 before you tried to clear it or is that number completely random
14:38 < Vision> yep I was
14:38 < Vision> not random
14:40 < Vision> oh yeah well that's easy to replicate
14:40 < Vision> have 'connect through socks5 proxy' checked, have an ip and port in the box, clear IP and hit OK
14:40 < Vision> instant crash
14:41 < Vision> and :port gets saved to registry
14:42 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:44 < wumpus> the code here https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsmodel.cpp#L231 for ProxyIP and ProxyPORT needs to catch the condition where the list is empty, or not long enough
14:44 < meshcollider> Yep I have replicated the issue on 0.15.1
14:45 < meshcollider> wumpus: I believe that is the part where it is loaded from the registry, we should deal with this when it is saved I think
14:45 < wumpus> meshcollider: yes but the parsing should be fixed too, it'd be two lines of code or so
14:46 < wumpus> meshcollider: this is the so-manieth time we run into crashes there for one reason or another
14:46 < meshcollider> wumpus: yeah :/
14:47 < Vision> [0] days since last crash
14:47 < meshcollider> why would this validator return true for an empty string: https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsdialog.cpp#L337
14:50 < Vision> why is 9050 hardcoded in that
14:51 < meshcollider> it is the default port
14:51 < meshcollider> if no port is specified
14:51 < Vision> ah.     
14:52 < Vision> just seems an odd place for it
14:52 < wumpus> that's tor's default
14:54 < Vision> (cuz it looks like it's already in src/qt/optionsmodel.cpp as default)
14:54 < wumpus> yeah, feel free to send a patch that makes it a constant instead
15:03 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev     
15:10 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
15:11 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
15:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
15:34 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
15:38 -!- dqx [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]     
15:39 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
15:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
15:39 -!- titim [2dfae328@gateway/web/freenode/ip.45.250.227.40] has joined #bitcoin-core-dev     
15:39 < titim> Hi     
15:40 < titim> lapoda lapoda
15:40 -!- titim [2dfae328@gateway/web/freenode/ip.45.250.227.40] has quit [Client Quit]     
15:41 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:41 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
15:44 -!- dqx [~dqx@unaffiliated/dqx] has quit [Read error: Connection reset by peer]     
15:45 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
15:51 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
15:52 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
15:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
15:58 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
15:58 -!- bule2 [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
15:59 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
16:05 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
16:06 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
16:13 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
16:14 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
16:15 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 260 seconds]     
16:21 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Read error: Connection reset by peer]     
16:22 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
16:22 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has quit [Client Quit]     
16:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
16:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
16:30 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
16:31 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
16:32 -!- wxss [~user@185.145.66.255] has quit [Quit: leaving]     
16:38 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
17:05 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has quit [Ping timeout: 240 seconds]     
17:08 < promag> sipa: > involve downgrading/upgrading between versions
17:08 < sipa> yes?
17:09 < promag> could have those wallets as fixtures'
17:09 < promag> ?     
17:09 < sipa> ?     
17:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
17:12 < promag> you mean that to test you have to use different versions of the wallet or the binary?
17:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:12 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
17:12 < sipa> yes     
17:13 < sipa> any automated testing that downgrading/upgrading is supported under the intended scenarios would involve having tests with access to different versions of binaries
17:13 < sipa> which is just hard logistically
17:17 < promag> why? could make use of docker for instance
17:17 < sipa> i fail to understand what kind of universe you live in where that doesn't qualify as "logistically hard" :)
17:17 < promag> but yes, a pain
17:18 < sipa> i'm not saying it's impossible - but it requires very nontrivial changes to our setup
17:18 < sipa> so i'm looking for opinions
17:18 < sipa> is it enough to do manual testing for downgrade/upgrade scenarios, for example?
17:19 < promag> how about having some wallets created offline with different versions commited to the source code, to use in the the tests?
17:19 < sipa> that would be a good idea!
17:19 < sipa> it can't test downgrade scenarios, though - only upgrade
17:20 < promag> why? the downgrade should produce an expected wallet (also commited)
17:21 < sipa> we don't have old binaries available
17:21 < meshcollider> promag: what about testing a wallet generated by the new version, against old software
17:21 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:21 < sipa> oh, by downgrade i mean opening a new file in an old version of the software
17:21 < meshcollider> e.g. generate wallet with 0.16.0, test against 0.15.1
17:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
17:22 < meshcollider> downgrading the software not the wallet :)
17:22 < promag> no need to test agains 0.15.1
17:22 < meshcollider> I mean any previous versin
17:22 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
17:23 < promag> you just happen to know downgrade result, so just check the downgrade result, offline you know it works in that version
17:23 < sipa> promag: practically the entire discussion about segwit wallet support is about downgrading and restoring backups across versions
17:23 < sipa> so no, we absolutely do care about how 0.15.1 deals with 0.16 files
17:23 -!- dqx [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]     
17:24 < promag> I'm not saying otherwise
17:24 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 248 seconds]     
17:24 < meshcollider> old binaries are all stored on bitcoincore.org so just write another testing framework to use those ;)
17:24 < sipa> promag: then i don't understand what you're saying
17:25 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
17:25 < meshcollider> oh actually there is nothing pre-0.9.5 there
17:26 < promag> so offline with create and downgrade the wallet, test with older versions, if it's ok then commit a test that does the same and at the end verifies the downgraded wallet
17:27 < sipa> what does 'verifies the downgraded wallet' mean?
17:27 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
17:27 < sipa> there is no such thing as a downgraded wallet - it's just a wallet file that was modified by master, and we care about how old software deals with it
17:27 < promag> for instance, the sha(downgraded wallet file) must be ....
17:28 < sipa> bdb files aren't deterministic
17:28 < meshcollider> in reality it'd require a whole new testing framework to ensure things like signrawtransaction, listunspent, etc. all work on the old versions aye
17:28 < sipa> and testing exact equivalence would be painful to maintain, as it would need updating after pretty much any change
17:29 < promag> 2 downgrades of the same can be different?
17:29 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev     
17:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
17:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
17:30 < sipa> promag: BDB files aren't deterministic, so you can't predict at all what the wallet file will look like after _any_ change
17:30 < sipa> you could dump the key/values in it, and compare those
17:30 < sipa> but my point is that you don't want to do that
17:30 < sipa> we don't care about the exact contents - we care about whether it works in old versions :)
17:31 < promag> my point is that those "exact contents" work in previous versions
17:31 < sipa> yes, but we can't predict what exact contents will be in master
17:31 < sipa> unless you want to modify that pre-committed exact contents after any change in master that affects the wallet file
17:31 < promag> that should not change often?
17:31 < sipa> maybe not
17:32 < sipa> it'd still be a pain
17:32 < promag> I mean, until a better testing framework exists it's better than nothing
17:32 < sipa> maybe
17:32 < meshcollider> just checking the hash of the wallet file is not sufficient though?
17:32 < sipa> meshcollider: no, the hash of the wallet file is completely unpredictable
17:33 < meshcollider> yeah, isn't that what promag is suggestion though
17:33 < promag> hash, key/values, whatever
17:34 < sipa> i generally dislike tests that test for exact equivalence
17:34 < meshcollider> key/values dumped by a newer version won't necessarily match those of an older version also, because changes to e.g. dumpscript would change the output
17:34 < promag> the test should just expect something. if master changes that then it might mean an old version can't use a downgraded wallet 
17:34 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
17:34 < sipa> especially if its unclear how those expected values should change
17:34 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
17:35 < promag> but yes, if a wallet decides to add a new key/value for soemthing else then its' a pain
17:35 < sipa> or a timestamp
17:35 < sipa> or a version number
17:35 < sipa> or a txid that's hard to make constant during the test
17:36 < promag> and pick the relevant key/values?
17:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:37 < promag> nothing better than actually use the old binaries
17:37 < meshcollider> yeah
17:37 < promag> what versions you think it should tests?
17:38 < meshcollider> well even 0.11 is now EOL isn't it, so I think it would be sufficient to just test on 12+ ?
17:38 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 255 seconds]     
17:38 < meshcollider> (automatically, of course we shouldn't deliberately break compatibility with earlier versions too just not test against them all automatically)?
17:38 < promag> only final releases right?
17:39 < meshcollider> you mean like, not rc? or just 0.14.2 not 0.14.1?
17:40 < promag> not rc
17:40 < promag> anyone knows who owns this https://hub.docker.com/u/bitcoincore/ ?
17:41 < sipa> it's a good question what versions should be supportedd for downgrading
17:45 < sipa> the use case is generally that someone upgrades, notices that the new version does something else/unexpected that is incompatible with their business, and downgrades until the issue is resolved
17:46 < sipa> and obvious for the specific case of segwit wallet support - downgrading below 0.13 is impossible of course
17:47 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit []     
17:50 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed]     
17:56 -!- ekrion [~ff@adsl201-232-238-252.epm.net.co] has joined #bitcoin-core-dev     
17:59 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev     
17:59 < promag> I guess you should add this testing as a follow up in #11403
17:59 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
18:01 < promag> a checklist for manual testing downgrade would be great also
18:02 < sipa> good point
18:04 < promag> bed time o/
18:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
18:08 < meshcollider> IMO its safe enough to support downgrading to versions which havent reached EOL and not bother testing the others too 
18:09 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev     
18:10 -!- baldur_ [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has joined #bitcoin-core-dev     
18:10 -!- gaf__ [~fag@12.smos-linux.org] has joined #bitcoin-core-dev     
18:11 -!- baldur [~baldur@pool-100-2-154-254.nycmny.btas.verizon.net] has quit [Ping timeout: 240 seconds]     
18:14 -!- davec_ [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
18:14 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
18:15 -!- whphhg_ [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
18:15 -!- Vision-_- [~Vision@97-85-227-163.static.stls.mo.charter.com] has joined #bitcoin-core-dev     
18:16 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev     
18:17 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
18:17 -!- jnewbery_ [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
18:18 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
18:19 -!- cluelessperson_ [~cluelessp@cpe-76-85-20-142.tx.res.rr.com] has joined #bitcoin-core-dev     
18:20 -!- noglar_ [~cl0uding@62.43.144.42.dyn.user.ono.com] has joined #bitcoin-core-dev     
18:20 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
18:20 -!- gaf_ [~fag@12.smos-linux.org] has quit [Ping timeout: 248 seconds]     
18:21 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 248 seconds]     
18:22 -!- midnightmagic_ [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev     
18:22 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 240 seconds]     
18:23 -!- Netsplit over, joins: Anduck
18:26 -!- Netsplit over, joins: [b__b]
18:27 -!- DigitalDank [DigitalDan@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev     
18:27 -!- Netsplit over, joins: Ge0rges
18:33 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has quit [Ping timeout: 240 seconds]     
18:35 -!- jackeroojohnson [49fe506d@gateway/web/freenode/ip.73.254.80.109] has joined #bitcoin-core-dev     
18:35 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev     
18:36 -!- jackeroojohnson [49fe506d@gateway/web/freenode/ip.73.254.80.109] has quit [Client Quit]     
18:48 -!- owowo [ovovo@gateway/vpn/mullvad/x-zjneaxxoepncwqvp] has joined #bitcoin-core-dev     
18:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-blawebgnrnbchrva] has quit [Quit: Connection closed for inactivity]     
18:51 -!- Krellan [~krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]     
19:24 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
19:31 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
20:05 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Quit: .]     
20:23 < Varunram> Is it possible to change the difficulty on a regtest chain?
20:24 -!- cluelessperson_ [~cluelessp@cpe-76-85-20-142.tx.res.rr.com] has quit [Quit: Laters]     
20:24 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev     
20:28 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has quit [Ping timeout: 260 seconds]     
20:33 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has joined #bitcoin-core-dev     
20:37 -!- Vision-_- [~Vision@97-85-227-163.static.stls.mo.charter.com] has left #bitcoin-core-dev ["Leaving"]     
20:41 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has quit [Ping timeout: 248 seconds]     
20:45 -!- jack__ [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
20:50 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]     
21:07 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-uvidmkycbrxqazhk] has quit [Quit: Connection closed for inactivity]     
21:12 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
21:12 -!- lari [~quassel@195.148.220.32] has quit [Quit: No Ping reply in 180 seconds.]     
21:14 -!- lari [~quassel@195.148.220.32] has joined #bitcoin-core-dev     
21:21 -!- whphhg_ is now known as whphhg     
21:27 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has joined #bitcoin-core-dev     
21:59 -!- midnightmagic_ is now known as midnightmagic     
22:01 -!- jack__ [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: jack__]     
22:07 -!- Yop [5898b5df@gateway/web/freenode/ip.88.152.181.223] has joined #bitcoin-core-dev     
22:08 -!- Yop [5898b5df@gateway/web/freenode/ip.88.152.181.223] has quit [Client Quit]     
22:12 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev     
22:44 -!- saint_ [~saint_@unaffiliated/saint-/x-0540772] has quit [Quit: UNIVERSE CORRUPTED. REBOOT (Y/N) ?]     
22:59 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 248 seconds]     
23:17 -!- Cogito_Ergo_Sum [~Myself@80.107.149.55] has joined #bitcoin-core-dev     
23:17 -!- Cogito_Ergo_Sum [~Myself@80.107.149.55] has quit [Changing host]     
23:17 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
23:18 -!- eurofap [~eurofap@dsl-tkubng12-54fb0d-75.dhcp.inet.fi] has joined #bitcoin-core-dev     
23:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:27 -!- eurofap [~eurofap@dsl-tkubng12-54fb0d-75.dhcp.inet.fi] has quit []     
23:37 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Ping timeout: 248 seconds]     
23:44 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
23:46 < kallewoof> Trying to get gitian working, and am having issues with LXC. I am getting "sudo: unable to resolve host gitian / cannot set terminal process group (1): Inappropriate ioctl for device / no job control in this shell" for the line "sudo $LXC_EXECUTE -n gitian -f var/lxc.config -- sudo -u $TUSER $ENV -i -- $*" in libexec/on-target, called from make-clean-vm (the bootstrap-fixup part). Any ideas?
23:54 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
23:55 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev