12017-11-30T00:05:55 *** intcat has quit IRC
22017-11-30T00:06:51 *** intcat has joined #bitcoin-core-dev
32017-11-30T00:13:57 *** intcat has quit IRC
42017-11-30T00:15:06 *** intcat has joined #bitcoin-core-dev
52017-11-30T00:17:14 *** justanotheruser has quit IRC
62017-11-30T00:23:39 *** Peilin-Yang has joined #bitcoin-core-dev
72017-11-30T00:31:42 *** Randolf has quit IRC
82017-11-30T00:31:59 *** dqx has quit IRC
92017-11-30T00:32:52 *** DvdKhl has quit IRC
102017-11-30T00:33:30 *** dqx has joined #bitcoin-core-dev
112017-11-30T00:38:23 *** dqx has quit IRC
122017-11-30T00:41:26 *** Peilin-Yang has quit IRC
132017-11-30T00:50:07 *** unholymachine has joined #bitcoin-core-dev
142017-11-30T00:54:04 *** Krellan has quit IRC
152017-11-30T00:54:35 *** Krellan has joined #bitcoin-core-dev
162017-11-30T00:57:14 *** AaronvanW has quit IRC
172017-11-30T01:14:16 *** Randolf has joined #bitcoin-core-dev
182017-11-30T01:16:55 *** intcat has quit IRC
192017-11-30T01:21:14 *** intcat has joined #bitcoin-core-dev
202017-11-30T01:21:16 *** wxss has quit IRC
212017-11-30T01:23:13 *** Randolf has quit IRC
222017-11-30T01:27:17 <promag> fanquake: extended tests too? https://github.com/bitcoin/bitcoin/pull/11791#issuecomment-348052591
232017-11-30T01:30:35 *** promag has quit IRC
242017-11-30T01:31:59 <fanquake> promag I can run them also
252017-11-30T01:36:05 *** Ylbam has quit IRC
262017-11-30T01:39:18 *** roidster has joined #bitcoin-core-dev
272017-11-30T01:43:23 *** Randolf has joined #bitcoin-core-dev
282017-11-30T01:45:05 *** Cogito_Ergo_Sum has quit IRC
292017-11-30T01:59:39 *** dqx has joined #bitcoin-core-dev
302017-11-30T02:09:49 *** dqx has quit IRC
312017-11-30T02:10:19 *** dqx has joined #bitcoin-core-dev
322017-11-30T02:12:12 *** fanquake has left #bitcoin-core-dev
332017-11-30T02:12:14 *** goatpig has quit IRC
342017-11-30T02:17:21 *** bule has quit IRC
352017-11-30T02:17:36 *** bule has joined #bitcoin-core-dev
362017-11-30T02:20:58 *** intcat has quit IRC
372017-11-30T02:23:02 *** intcat has joined #bitcoin-core-dev
382017-11-30T02:23:21 *** Murch has quit IRC
392017-11-30T02:29:44 *** meshcollider has quit IRC
402017-11-30T02:48:31 *** Cheeseo has quit IRC
412017-11-30T02:55:58 *** Chris_Stewart_5 has joined #bitcoin-core-dev
422017-11-30T03:07:34 *** Krellan has quit IRC
432017-11-30T03:08:07 *** Krellan has joined #bitcoin-core-dev
442017-11-30T03:15:52 *** dabura667 has joined #bitcoin-core-dev
452017-11-30T03:18:56 *** intcat has quit IRC
462017-11-30T03:20:49 *** intcat has joined #bitcoin-core-dev
472017-11-30T03:23:30 *** dqx_ has joined #bitcoin-core-dev
482017-11-30T03:27:15 *** dqx has quit IRC
492017-11-30T03:31:54 *** Emcy_ has joined #bitcoin-core-dev
502017-11-30T03:35:16 *** Emcy has quit IRC
512017-11-30T03:35:27 *** dabura667 has quit IRC
522017-11-30T03:41:33 *** Chris_Stewart_5 has quit IRC
532017-11-30T03:48:17 *** Cory has quit IRC
542017-11-30T03:53:57 *** Pasha has joined #bitcoin-core-dev
552017-11-30T03:54:02 *** intcat has quit IRC
562017-11-30T03:54:45 *** intcat has joined #bitcoin-core-dev
572017-11-30T03:57:09 *** Pasha is now known as Cory
582017-11-30T03:59:56 *** intcat has quit IRC
592017-11-30T04:00:45 *** intcat has joined #bitcoin-core-dev
602017-11-30T04:16:06 *** Emcy has joined #bitcoin-core-dev
612017-11-30T04:16:57 *** intcat has quit IRC
622017-11-30T04:17:45 *** intcat has joined #bitcoin-core-dev
632017-11-30T04:18:26 *** Emcy_ has quit IRC
642017-11-30T04:35:42 *** roidster has quit IRC
652017-11-30T04:40:02 *** roidster has joined #bitcoin-core-dev
662017-11-30T04:40:25 *** roidster is now known as Guest70745
672017-11-30T04:40:48 *** Guest70745 is now known as roidster
682017-11-30T04:44:05 *** dqx has joined #bitcoin-core-dev
692017-11-30T04:46:02 *** dqx_ has quit IRC
702017-11-30T05:02:20 *** ula has quit IRC
712017-11-30T05:11:21 *** jouke has quit IRC
722017-11-30T05:11:58 *** intcat has quit IRC
732017-11-30T05:13:16 *** intcat has joined #bitcoin-core-dev
742017-11-30T05:13:40 *** Krellan has quit IRC
752017-11-30T05:14:37 *** Krellan has joined #bitcoin-core-dev
762017-11-30T05:29:18 *** murr4y has quit IRC
772017-11-30T05:29:39 *** StopAndDecrypt has quit IRC
782017-11-30T05:30:03 *** StopAndDecrypt has joined #bitcoin-core-dev
792017-11-30T05:30:04 *** StopAndDecrypt has quit IRC
802017-11-30T05:30:04 *** StopAndDecrypt has joined #bitcoin-core-dev
812017-11-30T05:35:27 *** roidster has quit IRC
822017-11-30T05:46:44 *** Emcy has quit IRC
832017-11-30T05:51:27 *** dqx has quit IRC
842017-11-30T05:53:01 *** dqx has joined #bitcoin-core-dev
852017-11-30T06:03:17 *** chjj has quit IRC
862017-11-30T06:04:15 <warren> MarcoFalke: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-fedora.md nice! how recently did you test this btw?
872017-11-30T06:04:28 *** arubi_ has quit IRC
882017-11-30T06:04:57 <warren> MarcoFalke: I have had python-vm-builder RPM packages for years but it broke sometime this year and couldn't figure out how to fix it. although I use only qemu-kvm, not lxc.
892017-11-30T06:07:17 *** intcat has quit IRC
902017-11-30T06:08:02 *** intcat has joined #bitcoin-core-dev
912017-11-30T06:09:35 *** arubi has joined #bitcoin-core-dev
922017-11-30T06:10:24 *** DigitalDank has joined #bitcoin-core-dev
932017-11-30T06:19:37 *** DigitalDank has quit IRC
942017-11-30T06:19:50 *** jouke has joined #bitcoin-core-dev
952017-11-30T06:19:58 *** intcat has quit IRC
962017-11-30T06:20:48 *** intcat has joined #bitcoin-core-dev
972017-11-30T06:21:11 *** DigitalDank has joined #bitcoin-core-dev
982017-11-30T06:24:02 *** dqx has quit IRC
992017-11-30T06:25:21 *** intcat has quit IRC
1002017-11-30T06:26:12 *** intcat has joined #bitcoin-core-dev
1012017-11-30T06:28:03 *** DigitalDank has quit IRC
1022017-11-30T06:29:24 *** DigitalDank has joined #bitcoin-core-dev
1032017-11-30T06:31:04 *** meshcollider has joined #bitcoin-core-dev
1042017-11-30T06:35:45 *** DigitalDank has quit IRC
1052017-11-30T06:36:25 *** DigitalDank has joined #bitcoin-core-dev
1062017-11-30T06:37:43 *** DigitalDank has quit IRC
1072017-11-30T06:49:55 *** Ylbam has joined #bitcoin-core-dev
1082017-11-30T06:50:21 *** Emcy has joined #bitcoin-core-dev
1092017-11-30T07:00:47 *** chirayu has joined #bitcoin-core-dev
1102017-11-30T07:02:39 *** chirayu has quit IRC
1112017-11-30T07:10:07 *** DvdKhl has joined #bitcoin-core-dev
1122017-11-30T07:10:21 *** Murch has joined #bitcoin-core-dev
1132017-11-30T07:17:04 *** intcat has quit IRC
1142017-11-30T07:17:32 *** arubi has quit IRC
1152017-11-30T07:18:07 *** intcat has joined #bitcoin-core-dev
1162017-11-30T07:19:05 <bitcoin-git> [bitcoin] Varunram opened pull request #11793: Docs: Bump OS X version to 10.13 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11793
1172017-11-30T07:19:11 *** arubi has joined #bitcoin-core-dev
1182017-11-30T07:19:30 *** Krellan has quit IRC
1192017-11-30T07:19:49 <Varunram> ^ This needn't be a standalone PR in itself, can be merged with other fixes
1202017-11-30T07:20:08 *** Krellan has joined #bitcoin-core-dev
1212017-11-30T07:23:00 *** Murch has quit IRC
1222017-11-30T07:25:41 *** timothy has joined #bitcoin-core-dev
1232017-11-30T07:27:22 *** murr4y has joined #bitcoin-core-dev
1242017-11-30T07:27:58 *** intcat has quit IRC
1252017-11-30T07:29:07 *** intcat has joined #bitcoin-core-dev
1262017-11-30T07:37:41 <bitcoin-git> [bitcoin] laanwj closed pull request #9254: [depends] ZeroMQ 4.2.2 (master...zeromq-4-2-0) https://github.com/bitcoin/bitcoin/pull/9254
1272017-11-30T07:38:07 *** BashCo has quit IRC
1282017-11-30T07:48:17 *** jtimon has quit IRC
1292017-11-30T07:53:09 *** chjj has joined #bitcoin-core-dev
1302017-11-30T07:55:05 *** dabura667 has joined #bitcoin-core-dev
1312017-11-30T07:57:58 *** intcat has quit IRC
1322017-11-30T07:58:43 *** intcat has joined #bitcoin-core-dev
1332017-11-30T07:59:51 *** BashCo has joined #bitcoin-core-dev
1342017-11-30T08:00:56 *** intcat has quit IRC
1352017-11-30T08:01:48 *** intcat has joined #bitcoin-core-dev
1362017-11-30T08:05:00 *** intcat has quit IRC
1372017-11-30T08:06:06 *** intcat has joined #bitcoin-core-dev
1382017-11-30T08:12:17 *** JackH has quit IRC
1392017-11-30T08:13:32 *** bule has quit IRC
1402017-11-30T08:22:15 *** Guyver2 has joined #bitcoin-core-dev
1412017-11-30T08:26:09 *** JackH has joined #bitcoin-core-dev
1422017-11-30T08:28:28 *** owowo has quit IRC
1432017-11-30T08:42:30 *** owowo has joined #bitcoin-core-dev
1442017-11-30T08:55:39 *** unholymachine has quit IRC
1452017-11-30T08:56:18 *** laurentmt has joined #bitcoin-core-dev
1462017-11-30T08:57:15 *** d9b4bef9 has quit IRC
1472017-11-30T08:57:31 *** unholymachine has joined #bitcoin-core-dev
1482017-11-30T08:58:22 *** d9b4bef9 has joined #bitcoin-core-dev
1492017-11-30T09:01:29 *** wxss has joined #bitcoin-core-dev
1502017-11-30T09:05:57 *** intcat has quit IRC
1512017-11-30T09:08:07 *** intcat has joined #bitcoin-core-dev
1522017-11-30T09:09:53 *** DvdKhl has quit IRC
1532017-11-30T09:16:24 *** Guyver2 has quit IRC
1542017-11-30T09:17:51 *** chjj has quit IRC
1552017-11-30T09:28:31 *** AaronvanW has joined #bitcoin-core-dev
1562017-11-30T09:29:18 *** Aaronvan_ has joined #bitcoin-core-dev
1572017-11-30T09:32:47 *** AaronvanW has quit IRC
1582017-11-30T09:38:12 *** Krellan has quit IRC
1592017-11-30T09:39:13 *** cdecker_ has joined #bitcoin-core-dev
1602017-11-30T09:39:36 *** unholymachine has quit IRC
1612017-11-30T09:39:36 *** cdecker has quit IRC
1622017-11-30T09:39:36 *** Masaomi[m] has quit IRC
1632017-11-30T09:39:37 *** nickler has quit IRC
1642017-11-30T09:39:37 *** _flow_ has quit IRC
1652017-11-30T09:39:38 *** berndj has quit IRC
1662017-11-30T09:39:38 *** cdecker_ is now known as cdecker
1672017-11-30T09:39:43 *** Krellan has joined #bitcoin-core-dev
1682017-11-30T09:39:48 *** [b__b] has quit IRC
1692017-11-30T09:39:55 *** nickler has joined #bitcoin-core-dev
1702017-11-30T09:40:04 *** unholymachine has joined #bitcoin-core-dev
1712017-11-30T09:40:05 *** [b__b] has joined #bitcoin-core-dev
1722017-11-30T09:40:48 *** meshcollider has quit IRC
1732017-11-30T09:41:47 *** berndj has joined #bitcoin-core-dev
1742017-11-30T09:42:29 *** _flow_ has joined #bitcoin-core-dev
1752017-11-30T09:42:52 *** Victorsueca has quit IRC
1762017-11-30T09:44:09 *** Victorsueca has joined #bitcoin-core-dev
1772017-11-30T09:45:45 *** Masaomi[m] has joined #bitcoin-core-dev
1782017-11-30T09:55:07 *** meshcollider has joined #bitcoin-core-dev
1792017-11-30T09:55:12 *** shesek has quit IRC
1802017-11-30T10:04:38 *** Ylbam has quit IRC
1812017-11-30T10:06:53 <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
1822017-11-30T10:08:30 *** dabura667 has quit IRC
1832017-11-30T10:09:49 *** lysobit_ has joined #bitcoin-core-dev
1842017-11-30T10:09:57 *** meshcollider has quit IRC
1852017-11-30T10:09:57 *** musalbas has quit IRC
1862017-11-30T10:09:57 *** qrestlove has quit IRC
1872017-11-30T10:09:57 *** windsok has quit IRC
1882017-11-30T10:09:59 *** Dyaheon has quit IRC
1892017-11-30T10:10:16 *** lysobit_ is now known as musalbas
1902017-11-30T10:12:11 *** intcat has quit IRC
1912017-11-30T10:12:27 *** Randolf has quit IRC
1922017-11-30T10:13:10 *** intcat has joined #bitcoin-core-dev
1932017-11-30T10:15:26 *** meshcollider has joined #bitcoin-core-dev
1942017-11-30T10:15:26 *** qrestlove has joined #bitcoin-core-dev
1952017-11-30T10:15:26 *** windsok has joined #bitcoin-core-dev
1962017-11-30T10:15:26 *** Dyaheon has joined #bitcoin-core-dev
1972017-11-30T10:20:48 *** Randolf has joined #bitcoin-core-dev
1982017-11-30T10:21:58 *** intcat has quit IRC
1992017-11-30T10:23:06 *** intcat has joined #bitcoin-core-dev
2002017-11-30T10:27:54 <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
2012017-11-30T10:27:56 <gribble> https://github.com/bitcoin/bitcoin/issues/11774 | [WIP] [tests] Rename functional tests by ajtowns · Pull Request #11774 · bitcoin/bitcoin · GitHub
2022017-11-30T10:27:57 <gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
2032017-11-30T10:28:46 <wumpus> github is really sensitive with regard to merges, more than the stock git commands
2042017-11-30T10:29:08 <wumpus> might be so that at least no one blames them for merges going wrong
2052017-11-30T10:30:29 <aj> wumpus: yeah, it does make sense. bit weird not being able to tell quite what github thinks the conflict is though
2062017-11-30T10:30:33 <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
2072017-11-30T10:31:10 <wumpus> yeah it could use some better reporting
2082017-11-30T10:33:48 <wumpus> something I'd really like on github would be a graph of which open PRs collide with which other PRs
2092017-11-30T10:34:19 <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
2102017-11-30T10:35:04 <sipa> that would be very useful
2112017-11-30T10:35:18 <sipa> n^2 complexity though in the number of PRs, i think
2122017-11-30T10:37:50 <wumpus> worst case, though the n^2 could be filtered by excluding PRs that affect completely distinct files
2132017-11-30T10:38:41 <wumpus> also one'd want to avoid recomputing the whole thing, just incrementally take opens/closes into account
2142017-11-30T10:40:02 <wumpus> (ugh, and PRs that are re-pushed)
2152017-11-30T10:40:46 <aj> that just makes it O(n) for each PR change though
2162017-11-30T10:41:19 <wumpus> which is reasonable, you can do it in the background, not at the time someone opens the graph
2172017-11-30T10:42:22 <aj> yeah, n isn't /that/ large
2182017-11-30T10:43:19 <wumpus> though yeah if github wants to do it for all projects it could get bad for them
2192017-11-30T10:43:42 <wumpus> I don't really care if it would be a paid-only feature or such
2202017-11-30T10:43:51 *** murchandamus has quit IRC
2212017-11-30T10:45:10 *** murchandamus has joined #bitcoin-core-dev
2222017-11-30T11:00:13 <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.
2232017-11-30T11:00:53 *** fanquake has joined #bitcoin-core-dev
2242017-11-30T11:00:59 <wumpus> I think lumping everything output-related in one issue was a bit confusing
2252017-11-30T11:01:15 <wumpus> in one label*
2262017-11-30T11:02:19 *** Krellan has quit IRC
2272017-11-30T11:02:48 *** Krellan has joined #bitcoin-core-dev
2282017-11-30T11:02:51 *** JackH has quit IRC
2292017-11-30T11:05:28 *** gitju has joined #bitcoin-core-dev
2302017-11-30T11:05:42 *** gitju_ has joined #bitcoin-core-dev
2312017-11-30T11:07:01 *** Krellan has quit IRC
2322017-11-30T11:07:29 *** Krellan has joined #bitcoin-core-dev
2332017-11-30T11:08:59 *** unholymachine has quit IRC
2342017-11-30T11:09:52 *** Randolf has quit IRC
2352017-11-30T11:10:01 *** qrestlove has quit IRC
2362017-11-30T11:10:12 *** commavir has quit IRC
2372017-11-30T11:10:43 *** unholymachine has joined #bitcoin-core-dev
2382017-11-30T11:10:58 *** intcat has quit IRC
2392017-11-30T11:11:10 *** commavir has joined #bitcoin-core-dev
2402017-11-30T11:13:00 *** intcat has joined #bitcoin-core-dev
2412017-11-30T11:13:03 *** Emcy has quit IRC
2422017-11-30T11:14:09 *** kewde[m] has quit IRC
2432017-11-30T11:14:24 *** herzmeister[m] has quit IRC
2442017-11-30T11:14:24 *** Masaomi[m] has quit IRC
2452017-11-30T11:14:47 *** griswaalt[m] has quit IRC
2462017-11-30T11:15:03 *** qrestlove has joined #bitcoin-core-dev
2472017-11-30T11:16:56 *** gitju_ has quit IRC
2482017-11-30T11:17:50 *** Randolf has joined #bitcoin-core-dev
2492017-11-30T11:22:11 <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
2502017-11-30T11:22:12 <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
2512017-11-30T11:22:14 <aj> gah
2522017-11-30T11:22:42 <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
2532017-11-30T11:22:53 <aj> wumpus: https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- was what i was trying to paste
2542017-11-30T11:22:56 <wumpus> awesome!
2552017-11-30T11:24:10 <wumpus> pretty clever that you manage to avoid touching the working tree
2562017-11-30T11:24:42 <wumpus> but yes seems I won't get around to setting up a git tree that pulls all the PRs locally
2572017-11-30T11:25:45 <aj> wumpus: hmm? pulling all the PRs locally is easy and awesome though?
2582017-11-30T11:26:43 <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 :)
2592017-11-30T11:27:09 <fanquake> git branch -D *
2602017-11-30T11:28:22 <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...)
2612017-11-30T11:28:53 <wumpus> fanquake: git branch -D doesn't take a pattern :-) you'd need something like git branch | xargs git branch -D
2622017-11-30T11:29:22 <wumpus> aj: interesting, I'd have expected them to show up
2632017-11-30T11:31:22 <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)
2642017-11-30T11:31:54 <aj> ah, "git remote show origin" will at least give me a list of them
2652017-11-30T11:32:08 <wumpus> apart from that I use a single repository with worktrees for persistent branches like 0.15
2662017-11-30T11:33:02 <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
2672017-11-30T11:33:10 <aj> updated that gist with the compatible and conflicts graphs for a handful of recent PRs
2682017-11-30T11:33:38 <wumpus> or does that automatically remove removed branches at the gh side as well?
2692017-11-30T11:34:35 <wumpus> aj: oh wow
2702017-11-30T11:36:29 <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
2712017-11-30T11:36:34 <wumpus> so a connection means a conflict? why do 11790 and 11741 conflict?
2722017-11-30T11:37:27 <wumpus> 11741 only changes two files, yet conflicts with 9 PRs or so
2732017-11-30T11:37:36 <wumpus> it's possible :)
2742017-11-30T11:38:35 *** BGL has quit IRC
2752017-11-30T11:40:44 <aj> yeah, they merge fine manually; git apply --check complains about multiwallet.py, rpc/rawtransaction.cpp and test/txvalidation_tests.cpp
2762017-11-30T11:41:53 <aj> ah, i'm trying to apply patches from master twice
2772017-11-30T11:41:54 <wumpus> but 11741 touches neither of those
2782017-11-30T11:42:26 <wumpus> hehe okay
2792017-11-30T11:45:33 <fanquake> nice
2802017-11-30T11:48:41 <wumpus> oope, so fetch = +refs/pull/*/head:refs/pull/origin/* doesn't just fetch *open* pull requests
2812017-11-30T11:49:34 <wumpus> whee tracking 8288 branches now
2822017-11-30T11:49:52 <aj> https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- conflict graph looks better now
2832017-11-30T11:50:08 <wumpus> happy I did it in a temporary repo :)
2842017-11-30T11:52:04 <wumpus> aj: great
2852017-11-30T11:56:44 <Varunram> aj: thanks for the gist :)
2862017-11-30T11:58:14 <aj> probably needs to work out which PR branched off from master most recently and use that as a base
2872017-11-30T12:06:58 *** intcat has quit IRC
2882017-11-30T12:08:09 *** intcat has joined #bitcoin-core-dev
2892017-11-30T12:17:58 *** intcat has quit IRC
2902017-11-30T12:20:48 *** meshcollider has quit IRC
2912017-11-30T12:22:59 *** intcat has joined #bitcoin-core-dev
2922017-11-30T12:25:09 *** griswaalt[m] has joined #bitcoin-core-dev
2932017-11-30T12:29:25 *** SopaXorzTaker has joined #bitcoin-core-dev
2942017-11-30T12:34:32 *** kewde[m] has joined #bitcoin-core-dev
2952017-11-30T12:34:32 *** herzmeister[m] has joined #bitcoin-core-dev
2962017-11-30T12:34:33 *** Masaomi[m] has joined #bitcoin-core-dev
2972017-11-30T12:41:06 *** BGL has joined #bitcoin-core-dev
2982017-11-30T12:42:12 *** Victorsueca has quit IRC
2992017-11-30T12:43:19 *** d9b4bef9 has quit IRC
3002017-11-30T12:43:24 *** Victorsueca has joined #bitcoin-core-dev
3012017-11-30T12:44:02 *** niska has quit IRC
3022017-11-30T12:44:27 *** d9b4bef9 has joined #bitcoin-core-dev
3032017-11-30T12:46:26 *** d9b4bef9 has joined #bitcoin-core-dev
3042017-11-30T12:50:20 *** intcat has quit IRC
3052017-11-30T12:52:30 *** Emcy has joined #bitcoin-core-dev
3062017-11-30T12:54:28 *** niska has joined #bitcoin-core-dev
3072017-11-30T12:55:29 *** intcat has joined #bitcoin-core-dev
3082017-11-30T13:14:57 *** intcat has quit IRC
3092017-11-30T13:15:45 *** intcat has joined #bitcoin-core-dev
3102017-11-30T13:21:30 *** Krellan has quit IRC
3112017-11-30T13:22:55 *** Krellan has joined #bitcoin-core-dev
3122017-11-30T13:28:18 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3132017-11-30T13:34:26 *** frostbyte1982 has quit IRC
3142017-11-30T13:41:15 *** Emcy has quit IRC
3152017-11-30T13:48:25 *** promag has joined #bitcoin-core-dev
3162017-11-30T13:48:27 *** fanquake has quit IRC
3172017-11-30T13:57:09 *** zxsanny has joined #bitcoin-core-dev
3182017-11-30T14:00:02 *** jack__ has joined #bitcoin-core-dev
3192017-11-30T14:01:17 *** zxsanny has quit IRC
3202017-11-30T14:07:41 *** Chris_Stewart_5 has quit IRC
3212017-11-30T14:19:13 *** wordsToLiveBy has joined #bitcoin-core-dev
3222017-11-30T14:19:30 <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.
3232017-11-30T14:19:34 *** wordsToLiveBy has quit IRC
3242017-11-30T14:25:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3252017-11-30T14:26:35 *** Victorsueca has quit IRC
3262017-11-30T14:27:54 *** Victorsueca has joined #bitcoin-core-dev
3272017-11-30T14:31:15 *** goatpig has joined #bitcoin-core-dev
3282017-11-30T14:38:52 *** SopaXorzTaker has quit IRC
3292017-11-30T14:39:38 *** arubi has quit IRC
3302017-11-30T14:40:01 *** arubi has joined #bitcoin-core-dev
3312017-11-30T14:42:07 *** Chris_Stewart_5 has quit IRC
3322017-11-30T14:43:49 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
3332017-11-30T14:43:49 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
3342017-11-30T14:55:40 <andytoshi> #bitcoin please, this is just about software development
3352017-11-30T14:55:52 *** Giszmo has quit IRC
3362017-11-30T15:04:21 *** Giszmo has joined #bitcoin-core-dev
3372017-11-30T15:08:18 <jnewbery> aj: thanks. I've reviewed #11796. It should be an easy review/merge for others.
3382017-11-30T15:08:19 <gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
3392017-11-30T15:21:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3402017-11-30T15:24:08 *** saint_ has joined #bitcoin-core-dev
3412017-11-30T15:24:57 <aj> jnewbery: ugh, what sort of person points out a bug and says not to fix it /o\
3422017-11-30T15:27:02 <saint_> any idea why can't bitcoin core download the blockchain on a remote NAS drive ?
3432017-11-30T15:27:19 <wumpus> saint_: ask in #bitcoin please, will answer there
3442017-11-30T15:27:23 <saint_> okay
3452017-11-30T15:28:10 *** Krellan has quit IRC
3462017-11-30T15:29:23 *** Krellan has joined #bitcoin-core-dev
3472017-11-30T15:40:47 *** arubi has quit IRC
3482017-11-30T15:41:07 *** arubi has joined #bitcoin-core-dev
3492017-11-30T15:43:34 *** owowo has quit IRC
3502017-11-30T15:48:14 *** owowo has joined #bitcoin-core-dev
3512017-11-30T15:49:01 *** ghost43 has quit IRC
3522017-11-30T15:49:28 *** Emcy has joined #bitcoin-core-dev
3532017-11-30T15:49:44 *** Emcy has quit IRC
3542017-11-30T15:49:44 *** Emcy has joined #bitcoin-core-dev
3552017-11-30T15:51:33 *** jtimon has joined #bitcoin-core-dev
3562017-11-30T16:02:15 *** Emcy has quit IRC
3572017-11-30T16:03:08 *** ghost43 has joined #bitcoin-core-dev
3582017-11-30T16:03:10 *** Emcy has joined #bitcoin-core-dev
3592017-11-30T16:06:42 *** Murch has joined #bitcoin-core-dev
3602017-11-30T16:08:14 *** Emcy has quit IRC
3612017-11-30T16:11:32 *** Emcy has joined #bitcoin-core-dev
3622017-11-30T16:12:03 *** Emcy has quit IRC
3632017-11-30T16:12:31 *** Emcy has joined #bitcoin-core-dev
3642017-11-30T16:12:42 *** dqx has joined #bitcoin-core-dev
3652017-11-30T16:16:02 <jnewbery> aj: I wanted to get in before someone else pointed it out and told you to fix it :)
3662017-11-30T16:16:12 <jnewbery> I don't think it matters since the next PR should remove that code anyway
3672017-11-30T16:25:08 *** Emcy_ has joined #bitcoin-core-dev
3682017-11-30T16:25:38 *** Emcy has quit IRC
3692017-11-30T16:25:47 *** DvdKhl has joined #bitcoin-core-dev
3702017-11-30T16:30:25 *** dqx has quit IRC
3712017-11-30T16:41:26 *** alreadylate has joined #bitcoin-core-dev
3722017-11-30T16:44:50 *** Victorsueca has quit IRC
3732017-11-30T16:46:10 *** Victorsueca has joined #bitcoin-core-dev
3742017-11-30T16:46:28 *** Vimalraj has joined #bitcoin-core-dev
3752017-11-30T16:52:28 *** promag has quit IRC
3762017-11-30T16:52:40 *** Vimalraj has quit IRC
3772017-11-30T16:53:51 *** quantbot_ has quit IRC
3782017-11-30T16:54:18 *** quantbot has joined #bitcoin-core-dev
3792017-11-30T16:55:49 *** Randolf has quit IRC
3802017-11-30T17:02:37 *** quantbot_ has joined #bitcoin-core-dev
3812017-11-30T17:03:35 *** Murch has quit IRC
3822017-11-30T17:03:57 *** quantbot has quit IRC
3832017-11-30T17:09:53 *** esotericnonsense has quit IRC
3842017-11-30T17:10:45 *** esotericnonsense has joined #bitcoin-core-dev
3852017-11-30T17:10:50 *** Murch has joined #bitcoin-core-dev
3862017-11-30T17:11:01 *** ula has joined #bitcoin-core-dev
3872017-11-30T17:21:51 *** Randolf has joined #bitcoin-core-dev
3882017-11-30T17:22:58 *** Dizzle has joined #bitcoin-core-dev
3892017-11-30T17:24:15 *** laurentmt has quit IRC
3902017-11-30T17:25:36 <achow101> is the github git notifier dead?
3912017-11-30T17:26:38 *** anon has joined #bitcoin-core-dev
3922017-11-30T17:27:01 *** anon is now known as Guest18586
3932017-11-30T17:32:15 *** lvmbdv has quit IRC
3942017-11-30T17:35:37 *** Krellan has quit IRC
3952017-11-30T17:35:52 *** alreadylate has quit IRC
3962017-11-30T17:36:34 *** bule has joined #bitcoin-core-dev
3972017-11-30T17:37:13 *** BashCo has quit IRC
3982017-11-30T17:37:18 *** Krellan has joined #bitcoin-core-dev
3992017-11-30T17:48:53 *** esotericnonsense has quit IRC
4002017-11-30T17:51:13 *** esotericnonsense has joined #bitcoin-core-dev
4012017-11-30T17:51:50 *** bule2 has joined #bitcoin-core-dev
4022017-11-30T17:53:48 <wumpus> achow101: intermittently, yes
4032017-11-30T17:54:01 <wumpus> achow101: it seems incredibly unreliable
4042017-11-30T17:54:52 *** bule has quit IRC
4052017-11-30T18:01:14 *** kexkey has joined #bitcoin-core-dev
4062017-11-30T18:02:18 *** BashCo has joined #bitcoin-core-dev
4072017-11-30T18:09:53 *** Giszmo has quit IRC
4082017-11-30T18:13:57 *** esotericnonsense has quit IRC
4092017-11-30T18:27:24 *** Giszmo has joined #bitcoin-core-dev
4102017-11-30T18:27:42 *** esotericnonsense has joined #bitcoin-core-dev
4112017-11-30T18:39:52 *** ajtowns[m] has joined #bitcoin-core-dev
4122017-11-30T18:40:59 <jonasschnelli> I wonder how the Twitter commit feed works... I expect them polling
4132017-11-30T18:42:33 <wumpus> I think it must be; it isn't a webhook that we set up
4142017-11-30T18:43:08 <wumpus> we only have a slack webhook, and the IRC integration
4152017-11-30T18:43:16 *** timothy has quit IRC
4162017-11-30T18:43:55 *** ExtraCrispy has joined #bitcoin-core-dev
4172017-11-30T18:52:21 <wumpus> so having ruled out that it listens on IRC, it must either be listening on slack or polling
4182017-11-30T18:52:39 <wumpus> not sure whether the slack notiifications do go through
4192017-11-30T18:53:59 *** nanomouse has joined #bitcoin-core-dev
4202017-11-30T18:54:49 <wumpus> if the normal webhook works we could set up our own IRC bot
4212017-11-30T18:56:56 <jonasschnelli> wumpus: slack works...
4222017-11-30T18:57:26 *** meshcollider has joined #bitcoin-core-dev
4232017-11-30T18:57:32 <wumpus> jonasschnelli: great, so we isolated it to a problem with their IRC bot, not their notifications in general
4242017-11-30T18:57:44 <instagibbs> meeting in 3?
4252017-11-30T18:57:46 <instagibbs> or am i off
4262017-11-30T18:57:46 <jonasschnelli> Looks like
4272017-11-30T18:58:25 <wumpus> you're right
4282017-11-30T18:59:24 <wumpus> if the bot stays flaky like this tomorrow I'll contact github support, it's already been for a few days
4292017-11-30T19:00:03 <wumpus> #startmeeting
4302017-11-30T19:00:03 <lightningbot> Meeting started Thu Nov 30 19:00:03 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4312017-11-30T19:00:03 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4322017-11-30T19:00:23 <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
4332017-11-30T19:00:32 <cfields> hi
4342017-11-30T19:00:35 <sipa> hi
4352017-11-30T19:00:36 <CodeShark> hello
4362017-11-30T19:00:44 <achow101> hi
4372017-11-30T19:00:46 <Provoostenator> hi
4382017-11-30T19:00:51 <instagibbs> hi
4392017-11-30T19:00:55 <jonasschnelli> hi
4402017-11-30T19:00:59 <wumpus> #topic high priority for review
4412017-11-30T19:01:01 <meshcollider> hi
4422017-11-30T19:01:16 <luke-jr> hi
4432017-11-30T19:01:20 <wumpus> 8 PRs have been tagged for https://github.com/bitcoin/bitcoin/projects/8
4442017-11-30T19:01:39 <BlueMatt> why does cfields have 2?
4452017-11-30T19:01:44 <wumpus> I added cfields's BanMan last week as it's blocking his further net refactoring
4462017-11-30T19:01:59 <cfields> BlueMatt: wasn't me, but i'll take it :)
4472017-11-30T19:02:06 <wumpus> ohh is it unfair?
4482017-11-30T19:02:09 * jonasschnelli also have two :|
4492017-11-30T19:02:18 <instagibbs> achow101, i see you rebased yours? we shooting for post-0.16?
4502017-11-30T19:02:21 <BlueMatt> i think we try to have only one per person
4512017-11-30T19:02:24 <jtimon> hi
4522017-11-30T19:02:34 <BlueMatt> well i suggested we include jonasschnelli's other one as its kinda a segwit-wallet-blocker imo
4532017-11-30T19:02:38 <BlueMatt> or at least in-same-release
4542017-11-30T19:02:42 <achow101> instagibbs: I'm shooting for 0.16
4552017-11-30T19:02:47 <achow101> but it may not make it
4562017-11-30T19:03:04 <instagibbs> ok, I can give it more love, though I think I've given a lot already, probably needs others....
4572017-11-30T19:03:17 *** karelb has joined #bitcoin-core-dev
4582017-11-30T19:03:21 <achow101> still some segwit related things to do and runn1ng wants simulations
4592017-11-30T19:03:31 <achow101> also been busy with exams and classwork
4602017-11-30T19:03:37 <wumpus> well, good solution for that, review and merge one of cfields's PRs and there will be only one left :)
4612017-11-30T19:03:44 <karelb> achow101: I came just in time :) yes I wanted some simulations
4622017-11-30T19:03:51 <jonasschnelli> wumpus: heh
4632017-11-30T19:03:57 <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"
4642017-11-30T19:04:10 <BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
4652017-11-30T19:04:13 <wumpus> sipa: segwit is the only exception to that
4662017-11-30T19:04:14 <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
4672017-11-30T19:04:15 <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
4682017-11-30T19:04:23 <BlueMatt> sipa: I think we'll go back to that post-segwit-wallet, no?
4692017-11-30T19:04:25 <wumpus> sipa: for the rest, releases are only ever blocked on bugfixes not features
4702017-11-30T19:04:29 <achow101> sipa: I think 0.16 is the exception? because segwit wallet
4712017-11-30T19:04:35 <wumpus> yes
4722017-11-30T19:04:36 <jtimon> sipa: what is the blocker for 0.16 ?
4732017-11-30T19:04:41 <sipa> okay, that's fine - i'm not saying it's a bad thing
4742017-11-30T19:04:50 <instagibbs> i think it's openly acknowledged
4752017-11-30T19:04:55 <wumpus> and segwit wallet is not intended as a *blocker* for 0.16
4762017-11-30T19:04:59 *** SopaXorzTaker has joined #bitcoin-core-dev
4772017-11-30T19:05:07 <wumpus> we intend to release 0.16 early after that's in
4782017-11-30T19:05:13 <wumpus> so it's more like a trigger
4792017-11-30T19:05:13 <sipa> fair enough
4802017-11-30T19:05:20 <sipa> but it still changes prioritization a bit
4812017-11-30T19:05:28 <BlueMatt> indeed
4822017-11-30T19:05:32 <instagibbs> i think the segwit pr is shaping up nicely at least
4832017-11-30T19:05:34 <wumpus> if segwit wallet takes longer than the 0.16 release window, then IMO we should release 0.16 without it
4842017-11-30T19:05:43 <wumpus> but I don't expect that
4852017-11-30T19:05:48 <BlueMatt> wumpus: agreed
4862017-11-30T19:06:09 <jtimon> oh, I see, we want to release 0.16 soon after segwit wallet gets in
4872017-11-30T19:06:14 <wumpus> jtimon: yep
4882017-11-30T19:06:26 <sipa> i'm about to push some review fixes to #11403
4892017-11-30T19:06:30 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
4902017-11-30T19:06:31 <wumpus> jtimon: seems more advisable than trying to backport the whole lot + dependencies to 0.15
4912017-11-30T19:06:34 <cfields> sipa: not sure if you've clarified somewhere, do you consider all of the listed TODOs in 11403 blockers for release as well?
4922017-11-30T19:06:53 <jtimon> wumpus: yeah, I think I suggested that, eithe way it makes sense to me
4932017-11-30T19:07:18 <wumpus> jtimon: thanks in that case :)
4942017-11-30T19:07:26 <luke-jr> branch 0.15 into 0.16 ;)
4952017-11-30T19:07:32 <sipa> cfields: yes
4962017-11-30T19:07:48 <cfields> ok, thanks
4972017-11-30T19:08:03 <gmaxwell> So, segwit-wallet is done?
4982017-11-30T19:08:15 <jtimon> I'm not following review on the segwit wallet pr, how is it going?
4992017-11-30T19:08:31 <sipa> i think #11403 is pretty much done - just nits in command line option handling and output
5002017-11-30T19:08:34 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
5012017-11-30T19:08:45 <jtimon> great
5022017-11-30T19:08:55 <achow101> I tried reviewing it but it's big and scary
5032017-11-30T19:09:10 <wumpus> awesome
5042017-11-30T19:09:23 <sipa> we may want to discuss what to do with things like how dumpprivkey and signmessage should work in a post-segwit world
5052017-11-30T19:09:29 * Randolf congratulates achow101 for trying
5062017-11-30T19:09:30 <cfields> i found it reasonable review on a per-commit basis
5072017-11-30T19:09:37 <instagibbs> cfields, same
5082017-11-30T19:09:40 <sipa> as i believe some projects have come up with formats on their own
5092017-11-30T19:09:41 <cfields> *to review
5102017-11-30T19:09:55 <achow101> sipa: trezor has implemented their own segwit message signing thing
5112017-11-30T19:09:59 <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
5122017-11-30T19:10:02 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
5132017-11-30T19:10:03 <achow101> I think that might be the only one though
5142017-11-30T19:10:07 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
5152017-11-30T19:10:22 <sipa> achow101: perhaps we can just adopt that
5162017-11-30T19:10:25 <jtimon> what are we referring to by "soon after"?
5172017-11-30T19:10:30 <wumpus> sipa: well if other project's import/export formats make sense, it'd be good to use them for interchangeability
5182017-11-30T19:10:45 <achow101> sipa: I don't think it's documented anywhere though
5192017-11-30T19:10:48 <meshcollider> Should there be a BIP to formalise it
5202017-11-30T19:10:48 <achow101> at least not yet
5212017-11-30T19:10:52 <Provoostenator> Is there a good standard for message signing?
5222017-11-30T19:10:53 <sipa> longer term i think a script-based signing would nice, but i don't think we're ready to adopt something like that
5232017-11-30T19:10:59 <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.
5242017-11-30T19:11:00 <karelb> sipa: ad sign message - in trezor we changed v constant - https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-316032523 - no BIP, no time :(
5252017-11-30T19:11:13 <sipa> karelb: ok, i'll have a look
5262017-11-30T19:11:22 <sipa> the original bitcoin core message signing doesn't have a bip either
5272017-11-30T19:11:33 <luke-jr> Provoostenator: no
5282017-11-30T19:11:40 <wumpus> a BIP is not a requirement for us implementing it, though in parallel it'd be nice
5292017-11-30T19:11:43 <BlueMatt> sipa: it probably should if we change it, though
5302017-11-30T19:11:45 <achow101> sipa: perhaps it should? retcon one :p
5312017-11-30T19:11:56 <sipa> seems reasonable
5322017-11-30T19:11:57 <wumpus> good to already have implementations and the BIP just formalizes it
5332017-11-30T19:12:08 <gmaxwell> Well, signmessage is generally not very good; but fixing it should be a longer term thing.
5342017-11-30T19:12:09 <Provoostenator> I vaguely remember trying to implement / refactor signing and being not amused by the lack of a standard.
5352017-11-30T19:12:16 <luke-jr> current signed messages get very little real use, and most "usage" is based on misconceptions
5362017-11-30T19:12:23 <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 :)
5372017-11-30T19:12:24 <wumpus> luke-jr: agree
5382017-11-30T19:12:26 <luke-jr> IMO it'd make sense to just deprecate it until a better replacement is made
5392017-11-30T19:12:29 <wumpus> luke-jr: it's not a priority at least
5402017-11-30T19:12:33 <instagibbs> luke-jr, it's used for airdrops :P
5412017-11-30T19:12:40 <sipa> luke-jr: i agree it's not all that useful
5422017-11-30T19:12:44 <Provoostenator> Can it be made coin-agnostic as well?
5432017-11-30T19:12:48 <wumpus> certainly shouldn't be a blocker for 0.16
5442017-11-30T19:12:50 <luke-jr> instagibbs: that's a misuse, since it doesn't prove you have funds ;)
5452017-11-30T19:12:51 <gmaxwell> Provoostenator: no.
5462017-11-30T19:13:09 <karelb> we didn't have segwit message signing in web wallet, but users repeatedly demanded it
5472017-11-30T19:13:12 <instagibbs> luke-jr, but i profit from it, how can it be misuse ;P
5482017-11-30T19:13:19 <instagibbs> +1 tho
5492017-11-30T19:13:21 *** ExtraCrispy has quit IRC
5502017-11-30T19:13:21 <gmaxwell> The fact that it's inherently incompatible with multisig is a real bummer.
5512017-11-30T19:13:22 <luke-jr> karelb: for what, though?
5522017-11-30T19:13:27 <achow101> instagibbs: lol
5532017-11-30T19:13:31 <gmaxwell> luke-jr: airdrops
5542017-11-30T19:13:35 <luke-jr> XD
5552017-11-30T19:13:49 <wumpus> using bitcoin keys for anything else than signing transactions continues to make me uneasy
5562017-11-30T19:13:50 <jtimon> yeah, +1 to move to signing messages based on scripts
5572017-11-30T19:14:09 <luke-jr> MAST-based signmessage would be a sensible replacement
5582017-11-30T19:14:14 <Provoostenator> jtimon: what would that look like?
5592017-11-30T19:14:44 <wumpus> do hardware wallets even support it?
5602017-11-30T19:14:51 <luke-jr> Provoostenator: you could have a MAST if-branch that is always false for transactions, and then true for meta uses
5612017-11-30T19:14:53 <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.
5622017-11-30T19:14:53 <CodeShark> gmaxwell: a general solution for airdrops seems extremely difficult
5632017-11-30T19:15:29 <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)
5642017-11-30T19:15:30 <gmaxwell> In elements sipa wrote a patch for a script based signmessage; but we ran into ... challenges.. with how softforks would be handled.
5652017-11-30T19:15:48 *** nanymouse has joined #bitcoin-core-dev
5662017-11-30T19:15:50 <wumpus> gmaxwell: that'd have been better; at least the keys would only be used to sign things in one format
5672017-11-30T19:15:56 <gmaxwell> Segwit script versioning would fix those challenges.
5682017-11-30T19:15:57 <CodeShark> yes, two chains might have very different redemption conditions for the same utxo
5692017-11-30T19:16:00 *** nanomouse has quit IRC
5702017-11-30T19:16:02 <Provoostenator> Hah, so you can do multisig messages? :-)
5712017-11-30T19:16:07 <sipa> Provoostenator: yes
5722017-11-30T19:16:15 <sipa> Provoostenator: and timelocked signatures :p
5732017-11-30T19:16:16 <Provoostenator> Or even partial messages?
5742017-11-30T19:16:20 <jtimon> gmaxwell: I think they should be handled with flags
5752017-11-30T19:16:43 <sipa> jtimon: yes, but the general property of softforks doesn't apply
5762017-11-30T19:16:45 <jtimon> oh, right, script versioning solves it too
5772017-11-30T19:16:56 <sipa> you don't want a "oh, i don't know this signature version! it's valid!!"
5782017-11-30T19:17:01 <gmaxwell> jtimon: the 'pubkey' needs to commit to the rules. pre-segwit style softforks don't.
5792017-11-30T19:17:16 <gmaxwell> Well you can tristate: Valid, invalid, unknown public key version.
5802017-11-30T19:17:48 <wumpus> right
5812017-11-30T19:17:50 <luke-jr> sipa: that's a risk for txs too, though
5822017-11-30T19:17:54 <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
5832017-11-30T19:18:06 <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.
5842017-11-30T19:18:07 <luke-jr> why sighash flags can't fail valid
5852017-11-30T19:18:24 <gmaxwell> luke-jr: attacker controls signature side flags.
5862017-11-30T19:18:29 *** nanymouse has quit IRC
5872017-11-30T19:18:32 <luke-jr> gmaxwell: right, that's my point
5882017-11-30T19:18:49 *** nanymouse has joined #bitcoin-core-dev
5892017-11-30T19:19:15 <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.
5902017-11-30T19:19:38 <sipa> ?
5912017-11-30T19:20:24 <CodeShark> I also don't follow
5922017-11-30T19:20:32 *** Krellan has quit IRC
5932017-11-30T19:20:49 <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
5942017-11-30T19:20:50 <wumpus> are there any topics we really want to discuss in this meeting? I think we're drifting off a bit
5952017-11-30T19:21:00 <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.
5962017-11-30T19:21:06 <cfields> next (quick) topic suggestion: codesigning keys update
5972017-11-30T19:21:07 <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.
5982017-11-30T19:21:10 <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
5992017-11-30T19:21:14 <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
6002017-11-30T19:21:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
6012017-11-30T19:21:18 <jtimon> yeah, how about what "shortly after" means for 0.16 ?
6022017-11-30T19:21:24 <jonasschnelli> Two topic proposals: 1) review "nits" reduction, 2) bitcoin core code signing assoc.
6032017-11-30T19:21:39 <jonasschnelli> 2) goes in hand with cfields topicp.
6042017-11-30T19:22:07 <wumpus> jnewbery: thanks, I think adding all of them to high priority is a bit much, but we could add one
6052017-11-30T19:22:09 <wumpus> #topic codesigning
6062017-11-30T19:22:17 <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.
6072017-11-30T19:22:22 * cfields passes the mic to jonasschnelli
6082017-11-30T19:22:28 <jonasschnelli> https://github.com/bitcoincore-codesigning-association
6092017-11-30T19:22:44 <achow101> wumpus: it seems like some of those are ready to be merged. they have utACKs and no comments left
6102017-11-30T19:22:45 <jonasschnelli> https://bitcoincorecodesigning.org
6112017-11-30T19:22:45 <jonasschnelli> The association stands and apple has accepted the entity
6122017-11-30T19:22:57 <jonasschnelli> Code sining certificates are ready (need to setup the key)
6132017-11-30T19:23:12 <cfields> jonasschnelli: oh that's fantastic! nice work :)
6142017-11-30T19:23:15 <wumpus> achow101: if they're ready for merge even better, please notify me of those things outside the meeting
6152017-11-30T19:23:16 <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
6162017-11-30T19:23:47 <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
6172017-11-30T19:24:00 <wumpus> PSA: if something is ready for merge just let me know here instead of waiting for me to stumble on it accidentally :)
6182017-11-30T19:24:17 <BlueMatt> jnewbery: afaict only maybe the last is ready? the second only has one ack?
6192017-11-30T19:24:22 <achow101> wumpus: ok!
6202017-11-30T19:24:25 <BlueMatt> jonasschnelli: that was fast!
6212017-11-30T19:24:36 <wumpus> jonasschnelli: oh great!
6222017-11-30T19:24:37 <achow101> jonasschnelli: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
6232017-11-30T19:25:15 <cfields> achow101: note that a driver cert is different. More requirements.
6242017-11-30T19:25:28 <wumpus> getting a driver cert is much more difficult
6252017-11-30T19:25:42 <achow101> oh, didn't see that that was for drivers
6262017-11-30T19:25:47 <wumpus> I guess it should be, with the privilege level it operates at
6272017-11-30T19:26:01 <jonasschnelli> The question is if we want to try that distributed RSA key
6282017-11-30T19:26:09 <wumpus> we do
6292017-11-30T19:26:26 <BlueMatt> gmaxwell: mic?
6302017-11-30T19:26:48 <BlueMatt> or who was it who said they were gonna look into hooking it into a reasonable way to use it?
6312017-11-30T19:26:54 <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.
6322017-11-30T19:27:21 <gmaxwell> I didn't think we were going to bother to do it for the first one. but this is going faster than expected! :)
6332017-11-30T19:27:22 <jonasschnelli> cfields: Yeah. Apple needs that -----BEGIN CERTIFICATE REQUEST-----
6342017-11-30T19:27:23 <achow101> BlueMatt: that was gmaxwell. I also wanted to take a look at it. it looked painful
6352017-11-30T19:27:58 <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.
6362017-11-30T19:28:30 <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.
6372017-11-30T19:28:48 <BlueMatt> ugh
6382017-11-30T19:28:50 <gmaxwell> the MPC signing is radically simple and faster than MPC key generation.
6392017-11-30T19:29:01 <BlueMatt> i thought the mpc generation was implemented?
6402017-11-30T19:29:08 <gmaxwell> Though the stuff I linked to does both. (though it's setup for only three parties atm)
6412017-11-30T19:29:17 <BlueMatt> i mean thats probably fine?
6422017-11-30T19:29:22 <BlueMatt> 3/3, I assume?
6432017-11-30T19:29:22 <achow101> gmaxwell: can it be done faster than what is already implemented?
6442017-11-30T19:29:35 <gmaxwell> achow101: of course, but do we care if it takes hours?
6452017-11-30T19:30:12 <wumpus> if it's a one-time thing we don't
6462017-11-30T19:30:15 <cfields> jonasschnelli: let's talk after the meeting. It'd be great if we could get a dummy to test with.
6472017-11-30T19:30:16 *** laurentmt has joined #bitcoin-core-dev
6482017-11-30T19:30:19 <gmaxwell> BlueMatt: yes 3/3. Generation you'd always do as n/n then potentially reshare to a different threshold.
6492017-11-30T19:30:25 <jonasschnelli> cfields: sure
6502017-11-30T19:30:27 <BlueMatt> its not like this is holding a zksnark trusted-setup for all btc
6512017-11-30T19:30:37 <gmaxwell> How big are the keys they use for these things? 2kbit or 4kbit?
6522017-11-30T19:31:02 <Provoostenator> BlueMatt: would be nice to get another blog from P
6532017-11-30T19:31:02 <Provoostenator> l
6542017-11-30T19:31:11 <sipa> ?
6552017-11-30T19:31:13 <BlueMatt> ?
6562017-11-30T19:31:19 <Provoostenator> Peter todd riding down Canada to generate his signing key.
6572017-11-30T19:31:29 <jonasschnelli> gmaxwell: 2048 is what my apple RSA keys are
6582017-11-30T19:31:33 <Provoostenator> And then bragging that's more secure than Zcash
6592017-11-30T19:31:36 <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
6602017-11-30T19:31:38 <gmaxwell> Provoostenator: it's totally unrelated.
6612017-11-30T19:31:58 <jonasschnelli> Code signing won't give a lot of additional security...
6622017-11-30T19:32:02 <jonasschnelli> It's just a UX thing IMO
6632017-11-30T19:32:07 <gmaxwell> zcash has a backdoor for the whole system, this is just some code signing crud.
6642017-11-30T19:32:25 <wumpus> right
6652017-11-30T19:32:29 <Provoostenator> I know.
6662017-11-30T19:32:43 <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.
6672017-11-30T19:32:53 <sipa> does the MPC generation have a trusted setup?
6682017-11-30T19:32:59 <gmaxwell> sipa: no.
6692017-11-30T19:33:07 <sipa> i assume not - if you're fine with trusted setup, just generate a single key and split it layer
6702017-11-30T19:33:13 <sipa> ok, so it is entirely unrelated
6712017-11-30T19:33:15 * jtimon is curious about the "review nits reduction" topic...
6722017-11-30T19:33:25 <wumpus> yes it's just to prevent the person doing the code signing from becoming a specific target
6732017-11-30T19:34:12 <jonasschnelli> review nit reduction topic?
6742017-11-30T19:34:25 <gmaxwell> sipa: it just uses paillier, and lots of roundtrips. it's pretty simple.
6752017-11-30T19:34:48 <wumpus> #topic review nit reduction
6762017-11-30T19:35:10 <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..
6772017-11-30T19:35:30 <jonasschnelli> We should enforce the rules... ( I know I already brought that up )
6782017-11-30T19:36:02 *** nanymouse has quit IRC
6792017-11-30T19:36:03 <jonasschnelli> The libcurl project does that... it won't compile (make) if the code style doesn't matches
6802017-11-30T19:36:10 <jonasschnelli> It would reduce the review time a lot...
6812017-11-30T19:36:20 <jonasschnelli> And we apperently fixing the nits anyways at some point in time
6822017-11-30T19:36:52 <jtimon> you mean getting travis to complain about style nits?
6832017-11-30T19:36:56 <Provoostenator> Currently we're only running whitespace linter?
6842017-11-30T19:37:10 <jonasschnelli> jtimon: travis already does this... (whitespace)
6852017-11-30T19:37:18 <BlueMatt> if there were an easy way to apply it to new code only, I'd say thats probably fine
6862017-11-30T19:37:27 <jonasschnelli> I just want to get the code styling nits away from github comments
6872017-11-30T19:37:28 * jtimon nods
6882017-11-30T19:37:33 <BlueMatt> but it was my impression we were not able to find a way to do so
6892017-11-30T19:37:42 <jonasschnelli> BlueMatt: only new code. Yes.
6902017-11-30T19:37:47 <jtimon> BlueMatt: that was my understanding too
6912017-11-30T19:38:03 <wumpus> so have e.g. clang-format check the diff of pull requests?
6922017-11-30T19:38:12 <sipa> jonasschnelli: (brainstorming) or we could have a bot that marks a PR ready for review only after all nits are fixed
6932017-11-30T19:38:15 <jonasschnelli> wumpus: Yes. Can we enforce that somehow?
6942017-11-30T19:38:28 <jonasschnelli> sipa: Would also be something.. yes.
6952017-11-30T19:38:31 <sipa> so that people know not to look at something while there is still automated review going on
6962017-11-30T19:38:32 <wumpus> jonasschnelli: I don't know...
6972017-11-30T19:38:33 <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.
6982017-11-30T19:38:35 <jtimon> didn't someone wrote something like that at some point?
6992017-11-30T19:38:41 <wumpus> sipa: as long as it doesn't generate noise (posts) that's ok with me
7002017-11-30T19:38:55 <wumpus> sipa: so if it works like travis, just adds another cross to the status
7012017-11-30T19:38:59 <jonasschnelli> Would something speak against enforcing the clang-format-diff check during make?
7022017-11-30T19:39:02 <wumpus> w/ a link to the list of problems
7032017-11-30T19:39:02 <sipa> wumpus: right,t hat would be nice
7042017-11-30T19:39:08 <meshcollider> BlueMatt: adding new linters to Travis would only affect PRs now since #11699
7052017-11-30T19:39:10 <gribble> https://github.com/bitcoin/bitcoin/issues/11699 | [travis-ci] Only run linters on Pull Requests by jnewbery · Pull Request #11699 · bitcoin/bitcoin · GitHub
7062017-11-30T19:39:14 <wumpus> but I don't want any bots that generate notifications in my mail
7072017-11-30T19:39:32 <sipa> right
7082017-11-30T19:39:33 <jonasschnelli> wumpus: Yes, That would disturb even more
7092017-11-30T19:39:46 <jonasschnelli> Just an indication if its ready to review...
7102017-11-30T19:39:59 <jonasschnelli> And so we can have less of those "brackets, spaces missing blabla"
7112017-11-30T19:40:32 * BlueMatt was always in favor, did we find out if we could get a reasonably stable output out of clang-format?
7122017-11-30T19:40:38 <BlueMatt> or was it always very version-dependant?
7132017-11-30T19:40:47 <jonasschnelli> It just feels some reviews are more or less a "clang-format diff output"
7142017-11-30T19:40:52 <wumpus> I like how golang handles that, they just have one true style
7152017-11-30T19:41:12 <wumpus> and their linter can be safely used in e.g. pull request checks, w/ no ambiguity
7162017-11-30T19:41:14 <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?
7172017-11-30T19:41:29 <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?)
7182017-11-30T19:41:32 <sipa> you can apply clang-format on just the diffs
7192017-11-30T19:41:37 <meshcollider> jtimon: not if it's only run on the diff
7202017-11-30T19:41:44 <jonasschnelli> yes
7212017-11-30T19:41:47 <sipa> but clang-format only checks whitespace/newlines
7222017-11-30T19:41:47 <wumpus> morcos: good point!
7232017-11-30T19:41:55 <sipa> it doesn't check variable names etc
7242017-11-30T19:41:56 <jonasschnelli> morcos: we should focus on that
7252017-11-30T19:41:57 <gmaxwell> A small amount of code style nits on github are probably good for teamwork.
7262017-11-30T19:42:03 <wumpus> sipa: I think that's fine, those are the ones we want out of the way
7272017-11-30T19:42:04 <jonasschnelli> sipa: not sure if that is possible
7282017-11-30T19:42:06 <jtimon> meshcollider: right, only for pr diffs, yeah, I thought he meant every time you build locally
7292017-11-30T19:42:11 <wumpus> sipa: variable names are more of a human thing anyhow
7302017-11-30T19:42:17 <wumpus> sipa: so it's fine if humans comment on them
7312017-11-30T19:42:29 <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
7322017-11-30T19:42:44 <jonasschnelli> morcos: Indeed
7332017-11-30T19:42:48 <meshcollider> Scripted diffs will probably regularly require style change commits too to keep Travis happy
7342017-11-30T19:42:57 <jtimon> gmaxwell: there's always style nits that go beyond clang-format
7352017-11-30T19:43:05 <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...
7362017-11-30T19:43:13 <sipa> sur
7372017-11-30T19:43:16 <jonasschnelli> yes
7382017-11-30T19:43:35 <jonasschnelli> It's more about the naming convenction (m_, snake_case, CONSTANTS, etc,)
7392017-11-30T19:43:36 <wumpus> and the latter is much more important for maintainablility :-)
7402017-11-30T19:43:48 <kanzure> do we have a clang-format file
7412017-11-30T19:43:49 <MarcoFalke> meshcollider: I'd prefer if we didn't use clang-format in scripted diffs. Makes it impossible to reproduce ...
7422017-11-30T19:43:50 <gmaxwell> jtimon: yes true enough, I guess my point was that they're not all bad.
7432017-11-30T19:43:52 <wumpus> kanzure: yes
7442017-11-30T19:43:53 <jonasschnelli> kanzure: yes
7452017-11-30T19:44:15 <wumpus> contrib/devtools/clang-format-diff.py
7462017-11-30T19:44:15 <wumpus> src/.clang-format
7472017-11-30T19:44:25 <kanzure> ah thanks.
7482017-11-30T19:44:39 <cfields> i assume it'd be possible to setup a git alias that shows the current diff, diff'd against the clang-format result
7492017-11-30T19:44:43 * cfields plays around
7502017-11-30T19:44:44 <jonasschnelli> MarcoFalke: are you up to write a higher level documentation for the clang-format-diff.py workflow?
7512017-11-30T19:44:49 * MarcoFalke proposed to add '.style.yapf' and hides
7522017-11-30T19:44:56 <jtimon> wumpus: right, that's what I remember being written
7532017-11-30T19:44:57 <MarcoFalke> jonasschnelli: I did
7542017-11-30T19:45:06 <MarcoFalke> git diff | cfd
7552017-11-30T19:45:18 <wumpus> yapf?
7562017-11-30T19:45:19 *** jointek has joined #bitcoin-core-dev
7572017-11-30T19:45:23 <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.
7582017-11-30T19:45:29 <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
7592017-11-30T19:45:36 <wumpus> gmaxwell: right, that has always bothered about it
7602017-11-30T19:45:37 <jonasschnelli> gmaxwell: yeah. that
7612017-11-30T19:45:39 <MarcoFalke> also what gmaxwell said
7622017-11-30T19:45:44 *** jointek has left #bitcoin-core-dev
7632017-11-30T19:45:51 <MarcoFalke> wumpus: The same thing for python
7642017-11-30T19:45:59 <jtimon> well, the version can be fixed on travis, though
7652017-11-30T19:46:02 <wumpus> MarcoFalke: that's not very shocking
7662017-11-30T19:46:21 <jonasschnelli> ryanofsky: nits should still remain... just not stuff that computers can find and are covered by our code styling rules
7672017-11-30T19:46:23 <sipa> jtimon: right, but that makes travis effectively part of your workflow, which is unfortunate
7682017-11-30T19:46:42 <wumpus> you need to be able to run any checks that travis does locally
7692017-11-30T19:46:43 <sipa> jtimon: as in, you won't really know a PR is acceptable before pushing and waiting for travis
7702017-11-30T19:46:47 <gmaxwell> We could give developers a VM image or equivilent, but it's asking a lot.
7712017-11-30T19:46:48 <jtimon> sipa: right, or the concrete version if I want to run it locally first
7722017-11-30T19:47:19 <luke-jr> Travis is slow, too
7732017-11-30T19:47:30 <sipa> maybe someone should investigate how stable clang-format/ clang-tidy/ iwyu/ ... are
7742017-11-30T19:47:33 <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
7752017-11-30T19:47:39 <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*)
7762017-11-30T19:48:00 <achow101> jonasschnelli: it would blow up on existing code
7772017-11-30T19:48:07 <sipa> jonasschnelli: the problem is that different clang-format versions say different things
7782017-11-30T19:48:20 <jonasschnelli> sipa: significant?
7792017-11-30T19:48:26 <sipa> jonasschnelli: irrelevant, i think
7802017-11-30T19:48:29 <wumpus> jonasschnelli: 'make lint' would be nice
7812017-11-30T19:48:45 <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
7822017-11-30T19:48:49 <wumpus> jonasschnelli: that would just run all the checks, for C/C++, for python, for whitespace in docs, etc
7832017-11-30T19:48:49 <cfields> wumpus: +1
7842017-11-30T19:48:57 <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)
7852017-11-30T19:49:08 <jonasschnelli> wumpus: Maybe it should by bypassable, but the novice contributor should get warned if he uses invalid code-styling
7862017-11-30T19:49:15 <sipa> gmaxwell: that's no longer true with the 'review' function
7872017-11-30T19:49:28 <gmaxwell> Obviously we should just pull clang into our code tree and ship it too. :P
7882017-11-30T19:49:28 <sipa> you can see all former review comments, and the code they apply on
7892017-11-30T19:49:30 <wumpus> jonasschnelli: well, travis and the person that merge can also check
7902017-11-30T19:49:37 <jtimon> sipa: oh, that's what is for...
7912017-11-30T19:49:37 <instagibbs> sipa, interesting, more reason to use it
7922017-11-30T19:49:38 <wumpus> jonasschnelli: it just should be possible to do it locally too
7932017-11-30T19:49: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)
7942017-11-30T19:49:51 <sipa> jtimon: yes, you should use it :)
7952017-11-30T19:49:54 <wumpus> jonasschnelli: I'm not so much concerned with forcing people to run it but making it easy
7962017-11-30T19:50:08 <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)
7972017-11-30T19:50:33 <wumpus> jonasschnelli: well if you don't do it before, travis will stop you and you need to wait longer, simple as that :)
7982017-11-30T19:50:33 <sipa> something i have noticed is that sometimes 'nit' reviews start on PRs which are far from certain they'll be even concept ACKed
7992017-11-30T19:50:39 <instagibbs> morcos, we might need to have guidelines for "ACK lockin"
8002017-11-30T19:50:44 <jonasschnelli> Okay... I'll have a look at lint and something simple within the make-process
8012017-11-30T19:50:46 <jonasschnelli> sipa: that also
8022017-11-30T19:50:52 <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.
8032017-11-30T19:51:05 <wumpus> sipa: yeah... then it adds even more nosie
8042017-11-30T19:51:07 <instagibbs> cfields, can be diffed if you locally checked
8052017-11-30T19:51:20 <sipa> cfields: right, i try to avoid rebasing, but i pretty liberally squash nits
8062017-11-30T19:51:21 <instagibbs> many times im just reading off of github(lazy)
8072017-11-30T19:51:36 <sipa> cfields: and i don't mind others doing that too, except for very complicated PRs
8082017-11-30T19:51:38 <instagibbs> unless it's a particularly intense series of commits
8092017-11-30T19:51:41 <achow101> instagibbs: that kind of breaks when there's lots of merge conflicts
8102017-11-30T19:51:51 <wumpus> sometimes I wish 'git fetch' could fetch by commit id to fetch individual commits, unfortunately that doesn't work
8112017-11-30T19:52:00 <cfields> pretty sure github can show the diff from a squash a well, you just have to come up with the url for it
8122017-11-30T19:52:03 <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.
8132017-11-30T19:52:05 <wumpus> it can only be used with branch names
8142017-11-30T19:52:38 <wumpus> github can give you the patch for an arbitrary commit id though, but it's kind of annoying to do automatically
8152017-11-30T19:52:54 <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.
8162017-11-30T19:53:02 <wumpus> gmaxwell: yeah...
8172017-11-30T19:53:04 <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?
8182017-11-30T19:53:08 <MarcoFalke> wumpus: We could set up a bot to create branches for each utACK that is posted to gh
8192017-11-30T19:53:13 <instagibbs> not nitting a PR that doens't have any ACKs of any kind seems like a decent rule
8202017-11-30T19:53:16 <MarcoFalke> on a separate repo that is
8212017-11-30T19:53:23 <wumpus> MarcoFalke: that'd be kind of nice
8222017-11-30T19:53:28 <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
8232017-11-30T19:53:32 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
8242017-11-30T19:53:48 <wumpus> rebasing is often necessary
8252017-11-30T19:53:52 <jonasschnelli> Yes. What aj says. The things is just, unenforced user rules tend to get ignored. :)
8262017-11-30T19:53:54 <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
8272017-11-30T19:54:00 <MarcoFalke> then `git fetch bitcoin_reviewed_commits` will get you all the reviews
8282017-11-30T19:54:01 <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"
8292017-11-30T19:54:13 <wumpus> some files are hotspots and generate a lot of merge conflicts
8302017-11-30T19:54:28 <wumpus> although it's better now that main.cpp is dead
8312017-11-30T19:54:32 <gmaxwell> Provoostenator: no, but some people find it demotivating; 'they made me do more work then threw it out'. :)
8322017-11-30T19:54:52 <Provoostenator> True
8332017-11-30T19:54:53 *** karelb has quit IRC
8342017-11-30T19:55:09 *** ghost43 has quit IRC
8352017-11-30T19:55:10 <wumpus> Provoostenator: these are not the kind of nits that help you learn btter programming :)
8362017-11-30T19:55:30 <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.
8372017-11-30T19:55:32 *** ghost43 has joined #bitcoin-core-dev
8382017-11-30T19:55:48 <jonasschnelli> gmaxwell: indeed
8392017-11-30T19:55:52 <gmaxwell> Provoostenator: but we can't really send every new contributor to a zen mastery class before they contribute.
8402017-11-30T19:56:10 <Provoostenator> Well, we could... but that would be flagged as spam :-)
8412017-11-30T19:56:11 <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
8422017-11-30T19:57:17 <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.
8432017-11-30T19:57:40 <cfields> it makes for ugly commits getting merged in, but avoids the re-review after squash-for-nits issue.
8442017-11-30T19:57:41 <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.
8452017-11-30T19:57:44 <gmaxwell> a challenge with that is that we do get new contributions from people with zero git expirence.
8462017-11-30T19:58:10 <sipa> who think they need to open a new PR to fix a nit :)
8472017-11-30T19:58:10 <wumpus> the git basics stuff is explained pretty well in the contributing doc nowadays
8482017-11-30T19:58:27 <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?
8492017-11-30T19:58:29 <wumpus> I've not gotten the question on how to squash a commit for a long time now
8502017-11-30T19:58:39 *** SopaXorzTaker has quit IRC
8512017-11-30T19:58:41 <gmaxwell> wumpus: I've noticed that, I wondered why.
8522017-11-30T19:59:03 <instagibbs> oh that's where -0 came from
8532017-11-30T19:59:03 <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.
8542017-11-30T19:59:33 <BlueMatt> aj: yes, I'm a fan
8552017-11-30T19:59:37 <wumpus> Provoostenator: we only want to encourage squashing when it's iterative changes, not atomic separate changes
8562017-11-30T19:59:40 <jtimon> aj: I would have preffered that BlueMatt had maintained a nack but answered my questions/rebute, to be honest
8572017-11-30T19:59:42 <BlueMatt> specifically caues we end up with lots of need for concept review
8582017-11-30T20:00:13 <BlueMatt> we have lots of prs where lots of folks are +0/-0 and dont think its worth review
8592017-11-30T20:00:16 <BlueMatt> but they sit open for months
8602017-11-30T20:00:17 <BlueMatt> which is bad
8612017-11-30T20:00:24 <MarcoFalke> +0 on end meeting
8622017-11-30T20:00:29 <BlueMatt> +1
8632017-11-30T20:00:29 <instagibbs> -0
8642017-11-30T20:00:31 <wumpus> oh, it's that time already
8652017-11-30T20:00:33 <wumpus> #endmeeting
8662017-11-30T20:00:33 <lightningbot> Meeting ended Thu Nov 30 20:00:33 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
8672017-11-30T20:00:33 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.html
8682017-11-30T20:00:33 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.txt
8692017-11-30T20:00:33 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.log.html
8702017-11-30T20:01:00 <instagibbs> so hold on, the numbers are for what? pre-ACK reflection on idea?
8712017-11-30T20:01:13 <BlueMatt> generally, ive been usint them as that, yea
8722017-11-30T20:01:19 <MarcoFalke> warren: I tested it in august. Should still work, as the vm-builder is compiled from source
8732017-11-30T20:01:21 <BlueMatt> see aj's link
8742017-11-30T20:01:21 <wumpus> did we just spend an hour talking about nits and code signing, oh - also the signmessage thing :-)
8752017-11-30T20:01:28 <BlueMatt> yes :(
8762017-11-30T20:01:34 <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
8772017-11-30T20:01:35 <instagibbs> wumpus, 0.16 release too
8782017-11-30T20:01:38 <BlueMatt> spent an hour talking about how we waste time on nits
8792017-11-30T20:01:42 <MarcoFalke> warren: We do that on debian and ubuntu, so I sticked with it
8802017-11-30T20:01:42 <wumpus> BlueMatt: lol!
8812017-11-30T20:01:46 <wumpus> instagibbs: yes, you're right
8822017-11-30T20:01:48 <morcos> didn't you guys have a libevent topic
8832017-11-30T20:01:50 <aj> instagibbs: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions is the apache link
8842017-11-30T20:01:53 <instagibbs> BlueMatt, more irc meetings until throughput increases
8852017-11-30T20:01:57 <BlueMatt> wumpus: <BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
8862017-11-30T20:02:00 <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
8872017-11-30T20:02:11 <jtimon> so, yeah, how long is "shortly after" for 0.16 ?
8882017-11-30T20:02:11 <Provoostenator> Is there a safe way to make Travis cache more stuff? It's insanely slow.
8892017-11-30T20:02:28 <BlueMatt> fuck, we forgot to talk about cfields' libevent question :(
8902017-11-30T20:02:33 <BlueMatt> that actually mattered
8912017-11-30T20:02:42 <instagibbs> feel free to talk on it
8922017-11-30T20:02:47 <morcos> well if you, wumpus and cfields are here, you can still talk
8932017-11-30T20:02:48 <cfields> it's ok, I'm still investigating something locally
8942017-11-30T20:02:57 <gmaxwell> too bad we're not allowed to talk about things except in meetings :(
8952017-11-30T20:03:07 <Dizzle> Has libevent merged pass-in-your-own-socket yet?
8962017-11-30T20:03:10 <cfields> heh
8972017-11-30T20:03:32 <cfields> The specific issue is how to deal with #11785
8982017-11-30T20:03:33 <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
8992017-11-30T20:03:42 <wumpus> Dizzle: I don't think so
9002017-11-30T20:03:45 *** clarkmoody has joined #bitcoin-core-dev
9012017-11-30T20:04:07 <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
9022017-11-30T20:04:29 <cfields> I'm not convinced that we can fix it entirely, so it remains unclear what to do about it
9032017-11-30T20:04:49 <Dizzle> wumpus: thanks, that's what I was wondering about. stratum wallet and stratum mining projects are looking forward to unix socket RPC
9042017-11-30T20:04:50 <gmaxwell> well we could always merge some code that tries to increase our FD count, but thats not a fix.
9052017-11-30T20:05:01 <instagibbs> aj I still don't see the exact relationship between the numbers and ACKs.
9062017-11-30T20:05:18 <wumpus> BlueMatt: you mean #10279 for high priority for review?
9072017-11-30T20:05:21 <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
9082017-11-30T20:05:21 <BlueMatt> yes
9092017-11-30T20:05:22 <instagibbs> seems to be concept ACK on sliding scale
9102017-11-30T20:05:43 <wumpus> Dizzle: do you need it to be in bitcoin-cli for that?
9112017-11-30T20:05:52 <cfields> gmaxwell: the second part of the PR does that, but that makes me really nervous :(
9122017-11-30T20:06:00 <aj> instagibbs: +1 -1 = concept ack / concept nak; in between is "leaning this way or not, but not decided either way"
9132017-11-30T20:06:11 <wumpus> Dizzle: we could just merge the server side, then you can use it from your own code, just not the command line
9142017-11-30T20:06:13 <Dizzle> wumpus: nope, most pools and electrum servers use json-rpc themselves for that.
9152017-11-30T20:06:21 <Dizzle> that would be neat!
9162017-11-30T20:06:24 <instagibbs> aj ok so it is a replacement for concept acks... that makes more sense
9172017-11-30T20:06:30 <BlueMatt> mostly I love -0 - I dont think this is worth anyone's time to review, but if others want to, fine
9182017-11-30T20:06:54 <instagibbs> wumpus, speaking of merge ready, 10677
9192017-11-30T20:06:55 *** esotericnonsense has quit IRC
9202017-11-30T20:06:56 <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
9212017-11-30T20:06:58 *** instagibbs has left #bitcoin-core-dev
9222017-11-30T20:07:00 <gmaxwell> cfields: don't we have to eliminate the use of select before we go increasing the default maximum beyond FD_SETSIZE?
9232017-11-30T20:07:08 *** instagibbs has joined #bitcoin-core-dev
9242017-11-30T20:07:10 <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)
9252017-11-30T20:07:25 <wumpus> instagibbs: ok
9262017-11-30T20:07:40 <cfields> gmaxwell: I believe the limit becomes FD_SETSIZE*2 if you're using 2 select loops?
9272017-11-30T20:07:52 *** esotericnonsense has joined #bitcoin-core-dev
9282017-11-30T20:07:53 *** photonclock_ has quit IRC
9292017-11-30T20:08:04 <wumpus> cfields: no
9302017-11-30T20:08:10 <gmaxwell> to my great shame I seem to have forgotten how select is implemented internally. :P
9312017-11-30T20:08:24 <wumpus> cfields: select limits the max fd, using multiple selects doesn't change that
9322017-11-30T20:08:45 <wumpus> we should probably have switched to poll a long time ago
9332017-11-30T20:09:23 <wumpus> IIRC there have been PRs for that, but rejected because libevent P2P was just around the corner...
9342017-11-30T20:09:27 <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.
9352017-11-30T20:09:29 <cfields> well regardless, libevent is using epoll/kqueue/etc. here, so the select limits don't (or shouldn't) apply to rpc
9362017-11-30T20:09:49 *** dermoth has quit IRC
9372017-11-30T20:09:51 <wumpus> cfields: no, but the fd's used might be in select's limit!
9382017-11-30T20:10:06 <wumpus> cfields: if 1024 fd's are used, then select is dead, no matter who claimed them
9392017-11-30T20:10:13 <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.
9402017-11-30T20:10:25 <wumpus> gmaxwell: you're right
9412017-11-30T20:10:51 <wumpus> cfields: you're right that RPC itself won't be affected, but it still messes up P2P nevertheless
9422017-11-30T20:10:51 <cfields> ok, i was confused about the limit then.
9432017-11-30T20:11:18 <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.
9442017-11-30T20:11:37 <wumpus> gmaxwell: yup the fd number is converted to a bit position in the array
9452017-11-30T20:11:52 <wumpus> which is also what makes it so inefficient
9462017-11-30T20:12:00 <wumpus> if it is a sparse array....
9472017-11-30T20:12:12 *** photonclock_ has joined #bitcoin-core-dev
9482017-11-30T20:12:24 *** Ylbam has joined #bitcoin-core-dev
9492017-11-30T20:12:35 <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.
9502017-11-30T20:12:55 <BlueMatt> none of these things solve the problem....
9512017-11-30T20:13:00 <BlueMatt> the issue ends up being in eg leveldb
9522017-11-30T20:13:09 <gmaxwell> BlueMatt: no but it lets you increase the process limit above 1024.
9532017-11-30T20:13:10 <BlueMatt> i mean it'll blow up our p2p first, but mostly thats not a big deal
9542017-11-30T20:13:14 <wumpus> does leveldb use select?
9552017-11-30T20:13:16 *** Guyver2 has joined #bitcoin-core-dev
9562017-11-30T20:13:22 <gmaxwell> since when does leveldb use select?
9572017-11-30T20:13:24 <wumpus> I don't hink so
9582017-11-30T20:13:28 <BlueMatt> wumpus: no, in this case we literally ran out of process fds
9592017-11-30T20:13:34 <wumpus> leveldb only croaks if you run out of all process fds
9602017-11-30T20:13:49 <wumpus> which is what vii's patch more or less solves
9612017-11-30T20:13:53 <gmaxwell> As I said above: increasing the count isn't a _fix_; ... but it's a pretty good mitigation.
9622017-11-30T20:14:22 <wumpus> at least the obvious 'attack RPC with tons of separate connections' doesn't work as an exhaustion attack anymore after that
9632017-11-30T20:14:24 <BlueMatt> increasing the count also mostly doesnt break p2p, p2p will just keep opening new sockets until it gets a low numbered one
9642017-11-30T20:14:28 <cfields> wumpus: unfortunately, it doesn't :(
9652017-11-30T20:14:33 <wumpus> cfields: oh?
9662017-11-30T20:14:35 <BlueMatt> its smart enough to handle it
9672017-11-30T20:14:49 <gmaxwell> BlueMatt: really? what? lol.
9682017-11-30T20:15:00 <cfields> wumpus: nah, i can still exhaust the FDs with little effort.
9692017-11-30T20:15:02 <BlueMatt> i mean its not *that* smart, eg it will fail each connection
9702017-11-30T20:15:09 <BlueMatt> but it wil lkeep trying to make connections
9712017-11-30T20:15:16 <wumpus> cfields: so we really need a fix at the libevent side?
9722017-11-30T20:15:20 <gmaxwell> BlueMatt: so if an incoming connection has a high FD number it just drops it?
9732017-11-30T20:15:24 <BlueMatt> yes
9742017-11-30T20:15:46 <wumpus> it's interesting as I did load tests when I started using libevent and never stumbled on this
9752017-11-30T20:16:08 <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. :)
9762017-11-30T20:16:15 <cfields> wumpus: yes. Problem is that it does while(something){accept()...}
9772017-11-30T20:16:16 <wumpus> if I only had known its http server was so crappy :(
9782017-11-30T20:16:32 <cfields> so if you manage to make a shitload of connections while it's in that loop, it'll keep swallowing 'em
9792017-11-30T20:16:34 <BlueMatt> gmaxwell: i mean if your rpc is getting flooded you probably want to drop most connections :p
9802017-11-30T20:16:45 <BlueMatt> cause you're already overloaded
9812017-11-30T20:16:51 <wumpus> BlueMatt: yes, you want to drop them
9822017-11-30T20:17:05 <wumpus> BlueMatt: that would be the right solution, not hoard file descriptors
9832017-11-30T20:17:15 <gmaxwell> BlueMatt: yea sure but I think the FD assignment is next highest in range until it hits the maximum, not lowest available.
9842017-11-30T20:17:38 <wumpus> AFAIK fd assignment is lowest available on many OSes
9852017-11-30T20:17:47 <BlueMatt> hmm, my node doesnt seem to break and i run with high fd limit
9862017-11-30T20:17:49 <gmaxwell> okay, I needed to be wrong about at least one thing.
9872017-11-30T20:17:52 <BlueMatt> so....dont think so on linux?
9882017-11-30T20:17:57 <gmaxwell> BlueMatt: without the poll patch?
9892017-11-30T20:18:00 <BlueMatt> yes, without
9902017-11-30T20:18:05 <wumpus> try to close stdout and the next fd you open :-)
9912017-11-30T20:18:11 <BlueMatt> i stopped using it and you can still get something like 800 maxonncections
9922017-11-30T20:18:22 <gmaxwell> gessh comeone we should just switch to poll, if its *nix only it should be a dozen line patch.
9932017-11-30T20:18:29 <gmaxwell> wumpus: lol.
9942017-11-30T20:18:39 * BlueMatt 's point is that it is almost entirely irrelevant to this issue
9952017-11-30T20:19:10 <wumpus> it's still relevant though
9962017-11-30T20:19:12 <gmaxwell> well increasing the fd count would change the urgency.
9972017-11-30T20:19:35 * BlueMatt 's point is we can increase fd count today
9982017-11-30T20:19:38 <BlueMatt> without poll
9992017-11-30T20:19:52 <wumpus> maybe not for this specific issue, but there's no good reason at all we're still using select, it only has drawbacks
10002017-11-30T20:20:00 <BlueMatt> fair
10012017-11-30T20:20:03 <gmaxwell> I really don't want to troubleshoot mysterious connection failures from "your FD was too high"
10022017-11-30T20:20:10 <Dizzle> Does select do ok on macOS? If not, would need to add kqueue polling to those 12 lines of code.
10032017-11-30T20:20:44 <gmaxwell> oh right osx poll is broken isn't it?
10042017-11-30T20:21:02 <wumpus> how is poll broken on osx?
10052017-11-30T20:21:29 <gmaxwell> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
10062017-11-30T20:22:00 <gmaxwell> sounds like they've fixed it, broken it again, and fixed it.
10072017-11-30T20:22:08 <wumpus> lol I'm not surprised, even validating the root password seems to be too difficult for them
10082017-11-30T20:22:24 <cfields> iirc they're just flip-flopping on undefined return values?
10092017-11-30T20:23:09 <gmaxwell> yea, it seems like that the case discussed there should be easy to avoid.
10102017-11-30T20:23:15 <wumpus> they took poor old freebsd and turned it to crap
10112017-11-30T20:23:55 <Dizzle> Of note, in addition to the issue that blog mentions, macOS' poll doesn't work on devices.
10122017-11-30T20:24:06 <gmaxwell> but shiny plastic crap
10132017-11-30T20:24:12 <gmaxwell> we only need it on sockets.
10142017-11-30T20:24:53 <wumpus> indeed, that doesn't matter
10152017-11-30T20:25:20 <wumpus> windows can't do select on devices or files either,we don't use that
10162017-11-30T20:26:03 <gmaxwell> BlueMatt: where is that poll patch?
10172017-11-30T20:26:26 <BlueMatt> uhhhh, lost?
10182017-11-30T20:26:28 <BlueMatt> i dunno
10192017-11-30T20:27:29 <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
10202017-11-30T20:27:57 *** esotericnonsense has quit IRC
10212017-11-30T20:28:11 <gmaxwell> Dizzle: no probably not but whats the gain?
10222017-11-30T20:28:27 <Dizzle> performance and it works on those few versions of OS X with the broken poll
10232017-11-30T20:28:46 <gmaxwell> the performance differences are negligible for our sorts of usage.
10242017-11-30T20:29:03 <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.
10252017-11-30T20:29:05 <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
10262017-11-30T20:29:30 <wumpus> Dizzle: that's why the goal is to move P2P to libevent, it already handles all those polling methods
10272017-11-30T20:29:30 <Dizzle> cfields: this abstraction on libevent or bitcoin core?
10282017-11-30T20:29:38 <cfields> yea
10292017-11-30T20:29:45 <Dizzle> OK, great. Sorry for the noise then :)
10302017-11-30T20:30:06 <wumpus> we really don't want to replicate all of that
10312017-11-30T20:30:08 <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.
10322017-11-30T20:30:09 <cfields> #11227
10332017-11-30T20:30:11 <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
10342017-11-30T20:30:56 <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.
10352017-11-30T20:31:00 <cfields> wumpus: as a data point, even with #11785, i can exhaust all handles via rpc in a minute or two.
10362017-11-30T20:31:01 <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
10372017-11-30T20:31:02 <wumpus> at least the low-level libevent stuff is well tested
10382017-11-30T20:31:18 <gmaxwell> yes, at least libevent gets testing by other people.
10392017-11-30T20:31:19 <cfields> So I'm not sure that it's worth adding work-around hacks
10402017-11-30T20:31:48 <wumpus> cfields: so what can we do? (except say "don't do this")
10412017-11-30T20:31:57 <wumpus> I mean it's kind of sad to DoS yourself
10422017-11-30T20:32:13 <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
10432017-11-30T20:32:17 <wumpus> and outside of localhost I doubt you'll ever accomplish such a rate
10442017-11-30T20:32:31 <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.
10452017-11-30T20:32:45 <wumpus> that's just a fact of life, everything has bugs
10462017-11-30T20:33:01 <cfields> wumpus: yea, i'm not really sure
10472017-11-30T20:33:18 <gmaxwell> split rpc into another process. :P
10482017-11-30T20:33:19 <wumpus> I mean we even find gcc bugs
10492017-11-30T20:33:37 *** Krellan has joined #bitcoin-core-dev
10502017-11-30T20:33:42 <wumpus> if anything should be well-tested...
10512017-11-30T20:33:44 <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. :)
10522017-11-30T20:34:01 <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.
10532017-11-30T20:34:12 <wumpus> cfields: could we patch it at the libevent side?
10542017-11-30T20:34:26 <wumpus> cfields: I think trying to fix it in bitcoind is looking at it the wrong way
10552017-11-30T20:34:33 <gmaxwell> I think we should fix libevent.
10562017-11-30T20:34:34 <wumpus> cfields: it's a libevent bug
10572017-11-30T20:34:45 <cfields> wumpus: yea, pretty easily I believe
10582017-11-30T20:35:11 <wumpus> cfields: trying to work around upstream issues (at least permanently) instead of fixing them is pretty not done in open source
10592017-11-30T20:35:21 <cfields> through it might kill performance in some applications, so I'm not sure they'd want it upstream
10602017-11-30T20:35:22 <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)
10612017-11-30T20:35:40 <cfields> *though
10622017-11-30T20:35:46 <gmaxwell> cfields: surely exausting a processes' FDs isn't a cool move.
10632017-11-30T20:35:47 <wumpus> cfields: I don't think they care about performance in the http server
10642017-11-30T20:36:31 <cfields> wumpus: well it's in the listener, which is intended to be generic. The http server is just a user
10652017-11-30T20:36:37 <cfields> but yes, I'll do up a patch
10662017-11-30T20:36:38 <Randolf> [Syntax]: That's a nice way to encourage people. I like that.
10672017-11-30T20:36:42 <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.
10682017-11-30T20:36:46 <Randolf> Whoops, sorry, wrong channel.
10692017-11-30T20:37:16 <wumpus> cfields: so the bug is deeper than just the http server, and woudl affect other clients (such as tor) as well?
10702017-11-30T20:37:19 <wumpus> cfields: now I'm interested :)
10712017-11-30T20:37:46 <cfields> wumpus: I'm unsure who/what else uses the listener
10722017-11-30T20:37:49 <BlueMatt> cfields: having a limited queue is a simple patch upstream *should* do
10732017-11-30T20:38:04 <cfields> i assume their dns server, as a quick example
10742017-11-30T20:38:51 <BlueMatt> so you can crash their dns server with enough tcp traffic?
10752017-11-30T20:39:15 <cfields> sec, checking
10762017-11-30T20:39:32 <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.
10772017-11-30T20:40:08 <wumpus> gmaxwell: yes luckily we check for that
10782017-11-30T20:41:06 <cfields> ok no, they only use the listener internally for http
10792017-11-30T20:41:24 <BlueMatt> what else uses libevent's http server?
10802017-11-30T20:41:25 *** andrelam has joined #bitcoin-core-dev
10812017-11-30T20:41:26 <wumpus> cfields: I have a tor checkout here, anything I can easily grep for to see if they use it?
10822017-11-30T20:41:28 <BlueMatt> anything should be crashable
10832017-11-30T20:41:40 <cfields> wumpus: evconnlistener
10842017-11-30T20:42:08 <wumpus> cfields: no matches
10852017-11-30T20:42:23 <cfields> whew :)
10862017-11-30T20:43:23 <wumpus> they also don't use evhttp
10872017-11-30T20:45:08 *** andrelam has quit IRC
10882017-11-30T20:45:08 <wumpus> they do have a http client in src/or/directory.c but apparently they rolled their own there
10892017-11-30T20:45:31 <wumpus> eh not that the client would suffer from this
10902017-11-30T20:46:41 *** andrelam has joined #bitcoin-core-dev
10912017-11-30T20:49:35 <wumpus> still, there might be tons of things out there that use it
10922017-11-30T20:50:08 <wumpus> so if this can be triggered over the network it might still be reasonably serious
10932017-11-30T20:50:34 *** Hen_ has joined #bitcoin-core-dev
10942017-11-30T20:51:59 <wumpus> gah why are code search engines so useless
10952017-11-30T20:52:50 <wumpus> find 1000 forks of libevent, of course they have that string
10962017-11-30T20:53:00 *** Hen_ has quit IRC
10972017-11-30T20:53:23 <cfields> testing a patch
10982017-11-30T20:54:13 <wumpus> cfields: cool
10992017-11-30T20:55:56 *** jack__ has quit IRC
11002017-11-30T20:56:11 *** alreadylate has joined #bitcoin-core-dev
11012017-11-30T21:00:19 *** Ahia has joined #bitcoin-core-dev
11022017-11-30T21:02:18 *** Cheeseo has joined #bitcoin-core-dev
11032017-11-30T21:05:00 *** Victorsueca has quit IRC
11042017-11-30T21:06:10 *** Victorsueca has joined #bitcoin-core-dev
11052017-11-30T21:16:23 *** JackH has joined #bitcoin-core-dev
11062017-11-30T21:20:19 *** gitju has quit IRC
11072017-11-30T21:21:03 *** jtimon has quit IRC
11082017-11-30T21:25:16 *** andrelam has quit IRC
11092017-11-30T21:25:33 *** andrelam has joined #bitcoin-core-dev
11102017-11-30T21:33:52 *** owowo has quit IRC
11112017-11-30T21:39:10 *** jezeba has joined #bitcoin-core-dev
11122017-11-30T21:39:15 *** alreadylate has quit IRC
11132017-11-30T21:40:49 *** Giszmo has quit IRC
11142017-11-30T21:41:11 *** alreadylate has joined #bitcoin-core-dev
11152017-11-30T21:42:46 *** alreadylate has quit IRC
11162017-11-30T21:43:15 *** jezeba has quit IRC
11172017-11-30T21:44:20 *** Ahia has quit IRC
11182017-11-30T21:44:26 *** promag has joined #bitcoin-core-dev
11192017-11-30T21:46:50 *** Giszmo has joined #bitcoin-core-dev
11202017-11-30T21:48:13 *** Cheeseo has quit IRC
11212017-11-30T21:49:57 *** clarkmoody has quit IRC
11222017-11-30T21:50:28 *** Chris_Stewart_5 has quit IRC
11232017-11-30T21:51:56 *** andrelam has quit IRC
11242017-11-30T21:52:09 *** alreadylate has joined #bitcoin-core-dev
11252017-11-30T21:55:39 *** Cheeseo has joined #bitcoin-core-dev
11262017-11-30T21:56:55 *** promag has quit IRC
11272017-11-30T21:57:15 *** alreadylate has quit IRC
11282017-11-30T22:03:08 *** Cheeseo has quit IRC
11292017-11-30T22:05:29 *** jtimon has joined #bitcoin-core-dev
11302017-11-30T22:05:34 *** warxhead has quit IRC
11312017-11-30T22:11:35 *** Aaronvan_ has quit IRC
11322017-11-30T22:11:37 *** AaronvanW has joined #bitcoin-core-dev
11332017-11-30T22:12:20 *** Aaronvan_ has joined #bitcoin-core-dev
11342017-11-30T22:12:27 *** laurentmt has quit IRC
11352017-11-30T22:13:15 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e38d357447e...fbce66a98267
11362017-11-30T22:13:15 <bitcoin-git> bitcoin/master 680bc2c practicalswift: Use range-based for loops (C++11) when looping over map elements...
11372017-11-30T22:13:15 <bitcoin-git> bitcoin/master fbce66a MarcoFalke: Merge #10493: Use range-based for loops (C++11) when looping over map elements...
11382017-11-30T22:15:35 *** AaronvanW has quit IRC
11392017-11-30T22:22:21 *** Vision has joined #bitcoin-core-dev
11402017-11-30T22:23:11 <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.
11412017-11-30T22:23:17 *** AaronvanW has joined #bitcoin-core-dev
11422017-11-30T22:24:31 <meshcollider> Vision: what operating system?
11432017-11-30T22:24:41 <Vision> meshcollider: windows
11442017-11-30T22:25:00 *** Aaronvan_ has quit IRC
11452017-11-30T22:25:58 <meshcollider> Vision: in that case, the options will be in the registry, under HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt iirc
11462017-11-30T22:26:04 <wumpus> Vision: what version?
11472017-11-30T22:26:08 <wumpus> (of bitcoin core)
11482017-11-30T22:26:24 <Vision> 15.1 64-bit
11492017-11-30T22:26:28 <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
11502017-11-30T22:26:29 <wumpus> ok
11512017-11-30T22:26:34 <meshcollider> Vision: please let us know what values are in the registry before you modify them
11522017-11-30T22:26:38 <Vision> will do
11532017-11-30T22:26:48 <Vision> cuz yeah this is kinda catastrophic
11542017-11-30T22:26:55 <wumpus> it's better to use the flag to clear the gui settings
11552017-11-30T22:27:00 <wumpus> it will automatically make a backup
11562017-11-30T22:27:16 <meshcollider> wumpus: depends if he wants to clear all settings or just fix the proxy issue manually though :)
11572017-11-30T22:27:16 <wumpus> run bitcoin-qt with -resetguisettings
11582017-11-30T22:27:51 <wumpus> this resets the settings and creates a guisettings.ini.bak with the old settings for troubleshooting
11592017-11-30T22:27:51 <Vision> looks like addrProxy is :10
11602017-11-30T22:27:58 <Vision> lemme change that alone and see if that fixes
11612017-11-30T22:28:00 <achow101> start with -resetguisettings and then drop the backup file here
11622017-11-30T22:28:11 <wumpus> how did you manage to get :10 in there?
11632017-11-30T22:28:19 <meshcollider> just :10 with no IP?
11642017-11-30T22:28:21 <Vision> wumpus: clearing the boxes.
11652017-11-30T22:28:33 <Vision> I think :10 was the port
11662017-11-30T22:28:50 <Vision> maybe I left the port in
11672017-11-30T22:28:55 <Vision> and cleared just the IP
11682017-11-30T22:29:03 <Vision> meshcollider: indeed
11692017-11-30T22:29:05 <achow101> oh, I know how it crashed
11702017-11-30T22:29:10 <wumpus> strange, it shouldn't save in that case, but yeah possible
11712017-11-30T22:29:20 <Vision> oh it saved alright.
11722017-11-30T22:29:38 <achow101> it splits on the colon and does [0] and [1] to get the right params. that'll be an index out of bounds
11732017-11-30T22:29:53 <achow101> if there's no IP and just :port
11742017-11-30T22:30:06 <Vision> aha :D sounds like a culprit achow101.
11752017-11-30T22:30:16 <Vision> yeah I guess I just cleared the IP and not port
11762017-11-30T22:30:26 <Vision> and fixing that in the registry DID clear up the cache.
11772017-11-30T22:30:36 <Vision> CRASH*
11782017-11-30T22:30:41 <Vision> wtf. I swear I'm not retarded.
11792017-11-30T22:30:42 <achow101> I don't know how it let that save though
11802017-11-30T22:31:18 <Vision> once I finish what I was doing I may try to replicate it
11812017-11-30T22:31:54 <Vision> I swear I saw the '10' jump into the IP box before the dialog closed.
11822017-11-30T22:31:57 <Vision> if that helps
11832017-11-30T22:32:58 *** Randolf has quit IRC
11842017-11-30T22:33:53 <Vision> aaaand I think it crashed instantly at that point.
11852017-11-30T22:36:05 <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.
11862017-11-30T22:36:54 <Vision> aye
11872017-11-30T22:38:03 <meshcollider> Vision: were you using port 10 before you tried to clear it or is that number completely random
11882017-11-30T22:38:37 <Vision> yep I was
11892017-11-30T22:38:39 <Vision> not random
11902017-11-30T22:40:37 <Vision> oh yeah well that's easy to replicate
11912017-11-30T22:40:56 <Vision> have 'connect through socks5 proxy' checked, have an ip and port in the box, clear IP and hit OK
11922017-11-30T22:40:57 <Vision> instant crash
11932017-11-30T22:41:42 <Vision> and :port gets saved to registry
11942017-11-30T22:42:20 *** Guyver2 has quit IRC
11952017-11-30T22:44:05 <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
11962017-11-30T22:44:27 <meshcollider> Yep I have replicated the issue on 0.15.1
11972017-11-30T22:45:06 <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
11982017-11-30T22:45:48 <wumpus> meshcollider: yes but the parsing should be fixed too, it'd be two lines of code or so
11992017-11-30T22:46:30 <wumpus> meshcollider: this is the so-manieth time we run into crashes there for one reason or another
12002017-11-30T22:46:46 <meshcollider> wumpus: yeah :/
12012017-11-30T22:47:13 <Vision> [0] days since last crash
12022017-11-30T22:47:13 <meshcollider> why would this validator return true for an empty string: https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsdialog.cpp#L337
12032017-11-30T22:50:37 <Vision> why is 9050 hardcoded in that
12042017-11-30T22:51:17 <meshcollider> it is the default port
12052017-11-30T22:51:23 <meshcollider> if no port is specified
12062017-11-30T22:51:33 <Vision> ah.
12072017-11-30T22:52:11 <Vision> just seems an odd place for it
12082017-11-30T22:52:20 <wumpus> that's tor's default
12092017-11-30T22:54:03 <Vision> (cuz it looks like it's already in src/qt/optionsmodel.cpp as default)
12102017-11-30T22:54:58 <wumpus> yeah, feel free to send a patch that makes it a constant instead
12112017-11-30T23:03:11 *** Randolf has joined #bitcoin-core-dev
12122017-11-30T23:10:02 *** dqx has joined #bitcoin-core-dev
12132017-11-30T23:11:18 *** Dizzle has quit IRC
12142017-11-30T23:18:49 *** promag has joined #bitcoin-core-dev
12152017-11-30T23:34:10 *** Cogito_Ergo_Sum has quit IRC
12162017-11-30T23:38:26 *** dqx has quit IRC
12172017-11-30T23:39:02 *** dqx has joined #bitcoin-core-dev
12182017-11-30T23:39:22 *** promag has quit IRC
12192017-11-30T23:39:25 *** titim has joined #bitcoin-core-dev
12202017-11-30T23:39:30 <titim> Hi
12212017-11-30T23:40:03 <titim> lapoda lapoda
12222017-11-30T23:40:17 *** titim has quit IRC
12232017-11-30T23:41:02 *** chjj has joined #bitcoin-core-dev
12242017-11-30T23:41:53 *** vicenteH has quit IRC
12252017-11-30T23:44:14 *** dqx has quit IRC
12262017-11-30T23:45:30 *** DigitalDank has joined #bitcoin-core-dev
12272017-11-30T23:51:48 *** DigitalDank has quit IRC
12282017-11-30T23:52:19 *** DigitalDank has joined #bitcoin-core-dev
12292017-11-30T23:57:10 *** promag has joined #bitcoin-core-dev
12302017-11-30T23:58:07 *** DigitalDank has quit IRC
12312017-11-30T23:58:42 *** bule2 has quit IRC
12322017-11-30T23:59:23 *** DigitalDank has joined #bitcoin-core-dev