12020-05-28T00:00:02  *** Guest8623 has quit IRC
  22020-05-28T00:00:27  *** ghost43 has quit IRC
  32020-05-28T00:01:10  *** pinheadmz has quit IRC
  42020-05-28T00:01:19  *** ghost43 has joined #bitcoin-core-dev
  52020-05-28T00:06:20  *** kaftejiman has left #bitcoin-core-dev
  62020-05-28T00:14:16  *** justanotheruser has joined #bitcoin-core-dev
  72020-05-28T00:15:40  *** bitcoin-git has joined #bitcoin-core-dev
  82020-05-28T00:15:40  <bitcoin-git> [bitcoin] ajtowns opened pull request #19084: net: add comments on dns seed behaviour (master...202005-dns-seed-doc) https://github.com/bitcoin/bitcoin/pull/19084
  92020-05-28T00:15:41  *** bitcoin-git has left #bitcoin-core-dev
 102020-05-28T00:18:23  *** RC-3004 has joined #bitcoin-core-dev
 112020-05-28T00:20:11  *** luke-jr has quit IRC
 122020-05-28T00:21:03  *** luke-jr has joined #bitcoin-core-dev
 132020-05-28T00:34:27  *** promag has quit IRC
 142020-05-28T00:37:57  *** promag has joined #bitcoin-core-dev
 152020-05-28T00:42:28  *** promag has quit IRC
 162020-05-28T00:51:22  *** jarthur has quit IRC
 172020-05-28T01:20:25  *** proofofk_ has joined #bitcoin-core-dev
 182020-05-28T01:20:39  *** proofofkeags has quit IRC
 192020-05-28T01:21:12  *** proofofkeags has joined #bitcoin-core-dev
 202020-05-28T01:24:57  *** proofofk_ has quit IRC
 212020-05-28T01:33:03  *** PaulTroon has joined #bitcoin-core-dev
 222020-05-28T01:38:02  *** PaulTroon has quit IRC
 232020-05-28T01:41:46  *** pinheadmz has joined #bitcoin-core-dev
 242020-05-28T01:49:11  *** roconnor has quit IRC
 252020-05-28T02:29:41  *** sdaftuar has quit IRC
 262020-05-28T02:30:03  *** DeanWeen has quit IRC
 272020-05-28T02:30:07  *** sdaftuar has joined #bitcoin-core-dev
 282020-05-28T02:40:07  *** shesek has quit IRC
 292020-05-28T02:40:33  *** shesek has joined #bitcoin-core-dev
 302020-05-28T02:40:33  *** shesek has joined #bitcoin-core-dev
 312020-05-28T02:50:19  *** Relis has quit IRC
 322020-05-28T02:55:52  *** Highway61 has quit IRC
 332020-05-28T02:57:27  *** DeanWeen has joined #bitcoin-core-dev
 342020-05-28T03:00:02  *** RC-3004 has quit IRC
 352020-05-28T03:01:24  *** bitcoin-git has joined #bitcoin-core-dev
 362020-05-28T03:01:24  <bitcoin-git> [bitcoin] jnewbery opened pull request #19085: Refactor: clean up PeriodicFlush() (master...2020-05-refactor-periodic-flush) https://github.com/bitcoin/bitcoin/pull/19085
 372020-05-28T03:01:25  *** bitcoin-git has left #bitcoin-core-dev
 382020-05-28T03:01:38  *** tylerdmace has joined #bitcoin-core-dev
 392020-05-28T03:06:30  *** Relis has joined #bitcoin-core-dev
 402020-05-28T03:17:14  *** surja795 has quit IRC
 412020-05-28T03:21:13  *** Darki has joined #bitcoin-core-dev
 422020-05-28T03:22:09  *** surja795 has joined #bitcoin-core-dev
 432020-05-28T03:26:24  *** surja795 has quit IRC
 442020-05-28T04:01:41  <jeremyrubin> For #18191 I'm really conflicted with what to do on the compiler warnings that jonatack is reporting. The const txiter that I wrote is intentionally const. I'm a const-me-if-you-can beleiver. But it causes a false-positive compiler warning on certain clangs, and I don't love removing a safety annotation for a compiler warning.
 452020-05-28T04:01:44  <gribble> https://github.com/bitcoin/bitcoin/issues/18191 | Change UpdateForDescendants to use Epochs by JeremyRubin · Pull Request #18191 · bitcoin/bitcoin · GitHub
 462020-05-28T04:02:07  <jeremyrubin> I'm happy to do whatever wumpus says I should do here
 472020-05-28T04:06:36  <sipa> jeremyrubin: making it const txiter& isn't removing any safety?
 482020-05-28T04:07:07  *** jarthur has joined #bitcoin-core-dev
 492020-05-28T04:13:13  *** justanotheruser has quit IRC
 502020-05-28T04:14:04  *** Relis has quit IRC
 512020-05-28T04:16:11  <jeremyrubin> Ah right I am a bit foggy today I misremembered what the fix is and why I didn't like it. I think maybe if we should change this code, it's maybe worth style guiding to not use copy vs ref or remove -Wrange-loop-analysis if we don't want to require it
 522020-05-28T04:16:37  *** instagibbs has quit IRC
 532020-05-28T04:21:02  <sipa> i think for any moderately decent optimizing compiler, passing by reference is never worse (and often better)
 542020-05-28T04:23:43  *** vasild has quit IRC
 552020-05-28T04:23:57  *** justanotheruser has joined #bitcoin-core-dev
 562020-05-28T04:24:00  <sipa> so the advice of -Wrange-loop-analysis always applies
 572020-05-28T04:26:47  <jeremyrubin> ok I guess i'll squash in changing them. My frustration is less so about this one in specific and more so that there's like 30 some odd other commits that I need to re-write for this warning for the pending work on the mempool project.
 582020-05-28T04:27:11  <jeremyrubin> Is there any way that gcc can throw this warning as well or we can make it more reliably triggered?
 592020-05-28T04:27:48  *** jarthur has quit IRC
 602020-05-28T04:30:13  *** vasild has joined #bitcoin-core-dev
 612020-05-28T04:30:50  <jeremyrubin> I re-asked this on the github thread in case anyone knows
 622020-05-28T04:30:55  <jeremyrubin> 'night
 632020-05-28T04:32:58  *** proofofkeags has quit IRC
 642020-05-28T04:35:28  *** promag has joined #bitcoin-core-dev
 652020-05-28T04:39:34  *** promag has quit IRC
 662020-05-28T04:58:39  *** bitdex has joined #bitcoin-core-dev
 672020-05-28T05:00:24  *** ghost43 has quit IRC
 682020-05-28T05:00:51  *** ghost43 has joined #bitcoin-core-dev
 692020-05-28T05:09:15  *** proofofkeags has joined #bitcoin-core-dev
 702020-05-28T05:17:58  *** proofofkeags has quit IRC
 712020-05-28T05:25:11  *** marcoagner has joined #bitcoin-core-dev
 722020-05-28T05:33:42  *** Wendell69Maggio has joined #bitcoin-core-dev
 732020-05-28T05:45:49  *** Wendell69Maggio has quit IRC
 742020-05-28T06:00:01  *** Darki has quit IRC
 752020-05-28T06:06:24  *** danielyin has quit IRC
 762020-05-28T06:19:51  *** Harwood has joined #bitcoin-core-dev
 772020-05-28T06:25:38  *** bitcoin-git has joined #bitcoin-core-dev
 782020-05-28T06:25:38  <bitcoin-git> [bitcoin] lareq opened pull request #19086: fixed typo - polish translation (master...master) https://github.com/bitcoin/bitcoin/pull/19086
 792020-05-28T06:25:39  *** bitcoin-git has left #bitcoin-core-dev
 802020-05-28T06:26:48  *** bitcoin-git has joined #bitcoin-core-dev
 812020-05-28T06:26:48  <bitcoin-git> [bitcoin] fanquake closed pull request #19086: fixed typo - polish translation (master...master) https://github.com/bitcoin/bitcoin/pull/19086
 822020-05-28T06:26:49  *** bitcoin-git has left #bitcoin-core-dev
 832020-05-28T06:41:15  *** frogar has quit IRC
 842020-05-28T06:41:36  *** frogar has joined #bitcoin-core-dev
 852020-05-28T06:51:51  *** johanna1 has joined #bitcoin-core-dev
 862020-05-28T06:52:50  *** PaulTroon has joined #bitcoin-core-dev
 872020-05-28T07:12:47  *** Pavlenex has joined #bitcoin-core-dev
 882020-05-28T07:15:02  *** proofofkeags has joined #bitcoin-core-dev
 892020-05-28T07:16:29  *** jonatack_ has quit IRC
 902020-05-28T07:17:24  *** jonatack_ has joined #bitcoin-core-dev
 912020-05-28T07:18:40  *** jonatack_ has quit IRC
 922020-05-28T07:19:53  *** proofofkeags has quit IRC
 932020-05-28T07:28:56  *** jonatack has joined #bitcoin-core-dev
 942020-05-28T07:34:49  *** CubicEarth has quit IRC
 952020-05-28T07:36:34  *** CubicEarth has joined #bitcoin-core-dev
 962020-05-28T07:38:33  *** Deacyde has quit IRC
 972020-05-28T07:40:25  *** Deacyde has joined #bitcoin-core-dev
 982020-05-28T07:42:14  *** johanna1 has quit IRC
 992020-05-28T07:42:36  *** Guyver2 has joined #bitcoin-core-dev
1002020-05-28T07:50:41  *** bitcoin-git has joined #bitcoin-core-dev
1012020-05-28T07:50:41  <bitcoin-git> [bitcoin] fanquake opened pull request #19088: validation: use std::chrono throughout some validation functions (master...validation_chrono) https://github.com/bitcoin/bitcoin/pull/19088
1022020-05-28T07:50:49  *** bitcoin-git has left #bitcoin-core-dev
1032020-05-28T07:54:01  *** yojoots has quit IRC
1042020-05-28T07:54:14  *** yojoots has joined #bitcoin-core-dev
1052020-05-28T07:55:44  *** kljasdfvv has quit IRC
1062020-05-28T07:57:46  *** kljasdfvv has joined #bitcoin-core-dev
1072020-05-28T07:58:26  *** jonatack has quit IRC
1082020-05-28T08:00:40  *** jonatack has joined #bitcoin-core-dev
1092020-05-28T08:03:39  *** lehnberg has joined #bitcoin-core-dev
1102020-05-28T08:06:49  *** proofofkeags has joined #bitcoin-core-dev
1112020-05-28T08:07:10  *** proofofkeags has quit IRC
1122020-05-28T08:19:23  *** justanotheruser has quit IRC
1132020-05-28T08:20:38  *** Mister_X1 has joined #bitcoin-core-dev
1142020-05-28T08:29:54  *** justanotheruser has joined #bitcoin-core-dev
1152020-05-28T08:30:14  *** kristapsk has quit IRC
1162020-05-28T08:30:40  *** kristapsk has joined #bitcoin-core-dev
1172020-05-28T08:34:21  *** timothy has joined #bitcoin-core-dev
1182020-05-28T08:37:20  *** promag has joined #bitcoin-core-dev
1192020-05-28T08:38:11  *** jonatack has quit IRC
1202020-05-28T08:38:40  *** jonatack_ has joined #bitcoin-core-dev
1212020-05-28T09:00:02  *** Mister_X1 has quit IRC
1222020-05-28T09:18:16  *** Luke-Jr-jr has joined #bitcoin-core-dev
1232020-05-28T09:21:05  *** Pavlenex has quit IRC
1242020-05-28T09:37:26  *** jonatack_ has quit IRC
1252020-05-28T09:39:53  *** Dean_Guss has joined #bitcoin-core-dev
1262020-05-28T09:40:10  *** DeanWeen has quit IRC
1272020-05-28T09:43:57  *** jonatack has joined #bitcoin-core-dev
1282020-05-28T09:44:18  *** Pavlenex has joined #bitcoin-core-dev
1292020-05-28T09:46:02  *** EagleTM has joined #bitcoin-core-dev
1302020-05-28T09:47:51  *** mrostecki has quit IRC
1312020-05-28T09:53:05  *** mrostecki has joined #bitcoin-core-dev
1322020-05-28T09:53:31  *** shesek has quit IRC
1332020-05-28T09:55:48  *** Guyver2_ has joined #bitcoin-core-dev
1342020-05-28T09:56:06  <hebasto> MarcoFalke: recent changes in #19064 introduced new circular deps. Which is the best: revert changes or allow new circular deps?
1352020-05-28T09:56:09  <gribble> https://github.com/bitcoin/bitcoin/issues/19064 | refactor: Cleanup thread ctor calls by hebasto · Pull Request #19064 · bitcoin/bitcoin · GitHub
1362020-05-28T09:58:12  *** shaunsun has joined #bitcoin-core-dev
1372020-05-28T09:58:42  *** Guyver2 has quit IRC
1382020-05-28T10:00:04  *** shaunsun_ has joined #bitcoin-core-dev
1392020-05-28T10:02:36  *** shaunsun has quit IRC
1402020-05-28T10:03:18  *** Mabelle34Bartole has joined #bitcoin-core-dev
1412020-05-28T10:06:14  *** Pavlenex has quit IRC
1422020-05-28T10:08:07  *** Mabelle34Bartole has quit IRC
1432020-05-28T10:11:07  *** surja795 has joined #bitcoin-core-dev
1442020-05-28T10:15:59  *** justanotheruser has quit IRC
1452020-05-28T10:17:39  *** EagleTM has quit IRC
1462020-05-28T10:20:17  *** Pavlenex has joined #bitcoin-core-dev
1472020-05-28T10:22:13  *** midnight has quit IRC
1482020-05-28T10:23:41  *** midnight has joined #bitcoin-core-dev
1492020-05-28T10:24:43  *** justanotheruser has joined #bitcoin-core-dev
1502020-05-28T10:31:03  *** shesek has joined #bitcoin-core-dev
1512020-05-28T10:31:03  *** shesek has joined #bitcoin-core-dev
1522020-05-28T10:35:46  *** PaulTroon has quit IRC
1532020-05-28T10:38:30  *** promag has quit IRC
1542020-05-28T10:39:19  *** promag has joined #bitcoin-core-dev
1552020-05-28T10:39:55  *** promag has joined #bitcoin-core-dev
1562020-05-28T10:44:14  *** promag has quit IRC
1572020-05-28T11:04:50  *** PaulTroon has joined #bitcoin-core-dev
1582020-05-28T11:07:59  <wumpus> hebasto: as the goal of the PR is only 'readabillity and maintainability' I'd err on the site of reverting the part that introduces the circular dependency
1592020-05-28T11:08:23  <wumpus> if it was anything critical like a bugfix or feeature I'd say otherwise
1602020-05-28T11:10:03  *** Dean_Guss has quit IRC
1612020-05-28T11:12:26  *** jonatack has quit IRC
1622020-05-28T11:13:39  <hebasto> wumpus: thanks
1632020-05-28T11:14:41  *** jonatack has joined #bitcoin-core-dev
1642020-05-28T11:26:55  <wumpus> in general we have checks like 'prevent circular dependencies' because we want to work toward a state where there are none, ideally all commits should leave the source in a better state in that regard than they found is
1652020-05-28T11:30:22  <wumpus> or at least not worse
1662020-05-28T11:44:25  *** instagibbs has joined #bitcoin-core-dev
1672020-05-28T11:50:14  *** promag has joined #bitcoin-core-dev
1682020-05-28T11:55:26  *** Zenton has quit IRC
1692020-05-28T11:55:39  *** promag has quit IRC
1702020-05-28T11:59:57  *** bitcoin-git has joined #bitcoin-core-dev
1712020-05-28T11:59:57  <bitcoin-git> [bitcoin] jonatack opened pull request #19089: cli, test, doc: bitcoin-cli -getinfo multiwallet balances follow-ups (master...cli-getinfo-multiwallet-follow-ups) https://github.com/bitcoin/bitcoin/pull/19089
1722020-05-28T11:59:58  *** bitcoin-git has left #bitcoin-core-dev
1732020-05-28T12:00:02  *** Luke-Jr-jr has quit IRC
1742020-05-28T12:16:21  *** ghost43 has quit IRC
1752020-05-28T12:17:05  *** ghost43 has joined #bitcoin-core-dev
1762020-05-28T12:23:37  *** jonatack has quit IRC
1772020-05-28T12:33:58  *** ghost43 has quit IRC
1782020-05-28T12:34:25  *** ghost43 has joined #bitcoin-core-dev
1792020-05-28T12:49:54  *** Guest37028 has joined #bitcoin-core-dev
1802020-05-28T12:56:05  *** Relis has joined #bitcoin-core-dev
1812020-05-28T13:03:46  *** Guyver2_ has quit IRC
1822020-05-28T13:03:53  *** jonatack has joined #bitcoin-core-dev
1832020-05-28T13:03:54  *** Relis has quit IRC
1842020-05-28T13:07:34  *** bitcoin-git has joined #bitcoin-core-dev
1852020-05-28T13:07:34  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19090: refactor: Misc scheduler cleanups (master...2005-schedulerCleanup) https://github.com/bitcoin/bitcoin/pull/19090
1862020-05-28T13:07:35  *** bitcoin-git has left #bitcoin-core-dev
1872020-05-28T13:08:54  *** jonatack has quit IRC
1882020-05-28T13:10:25  *** troygiorshev has joined #bitcoin-core-dev
1892020-05-28T13:11:00  *** jonatack has joined #bitcoin-core-dev
1902020-05-28T13:13:09  *** ghost43 has quit IRC
1912020-05-28T13:13:34  *** ghost43 has joined #bitcoin-core-dev
1922020-05-28T13:15:41  *** Highway61 has joined #bitcoin-core-dev
1932020-05-28T13:21:13  *** Dean_Guss has joined #bitcoin-core-dev
1942020-05-28T13:31:55  *** shesek has quit IRC
1952020-05-28T13:34:40  *** mdunnio has joined #bitcoin-core-dev
1962020-05-28T13:44:48  *** jonatack has quit IRC
1972020-05-28T13:46:43  *** troygiorshev has quit IRC
1982020-05-28T13:47:35  *** Relis has joined #bitcoin-core-dev
1992020-05-28T13:48:07  *** Pavlenex has quit IRC
2002020-05-28T13:50:58  *** d_t has joined #bitcoin-core-dev
2012020-05-28T13:51:36  *** Pavlenex has joined #bitcoin-core-dev
2022020-05-28T13:54:28  *** Pavlenex has joined #bitcoin-core-dev
2032020-05-28T13:55:14  *** d_t has quit IRC
2042020-05-28T14:11:35  *** a5m0 has quit IRC
2052020-05-28T14:17:49  *** a5m0 has joined #bitcoin-core-dev
2062020-05-28T14:23:38  *** a5m0 has quit IRC
2072020-05-28T14:24:30  *** a5m0 has joined #bitcoin-core-dev
2082020-05-28T14:31:45  *** ghost43 has quit IRC
2092020-05-28T14:32:44  *** ghost43 has joined #bitcoin-core-dev
2102020-05-28T14:33:48  *** Guyver2 has joined #bitcoin-core-dev
2112020-05-28T14:35:05  *** lehnberg has quit IRC
2122020-05-28T14:35:15  *** promag has joined #bitcoin-core-dev
2132020-05-28T14:35:20  *** lehnberg has joined #bitcoin-core-dev
2142020-05-28T14:36:10  *** jonatack has joined #bitcoin-core-dev
2152020-05-28T14:48:59  *** Highway61 has quit IRC
2162020-05-28T14:49:24  *** Highway61 has joined #bitcoin-core-dev
2172020-05-28T14:50:36  *** bitcoin-git has joined #bitcoin-core-dev
2182020-05-28T14:50:37  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/55b4c65bd1d8...082a417abcce
2192020-05-28T14:50:38  <bitcoin-git> bitcoin/master 79be487 Hennadii Stepanov: Add thread safety annotated wrapper for std::mutex
2202020-05-28T14:50:39  <bitcoin-git> bitcoin/master dfb75ae Hennadii Stepanov: refactor: Rename LockGuard to StdLockGuard for consistency with StdMutex
2212020-05-28T14:50:40  <bitcoin-git> bitcoin/master 971a468 Hennadii Stepanov: Use template function instead of void* parameter
2222020-05-28T14:50:41  *** bitcoin-git has left #bitcoin-core-dev
2232020-05-28T14:51:06  *** bitcoin-git has joined #bitcoin-core-dev
2242020-05-28T14:51:06  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18635: Replace -Wthread-safety-analysis with broader -Wthread-safety (master...200414-threads) https://github.com/bitcoin/bitcoin/pull/18635
2252020-05-28T14:51:07  *** bitcoin-git has left #bitcoin-core-dev
2262020-05-28T15:00:02  *** Guest37028 has quit IRC
2272020-05-28T15:08:30  *** justanotheruser has quit IRC
2282020-05-28T15:15:03  *** mrostecki has quit IRC
2292020-05-28T15:16:35  *** Pavlenex has quit IRC
2302020-05-28T15:17:16  *** mrostecki has joined #bitcoin-core-dev
2312020-05-28T15:18:14  *** Toflar has joined #bitcoin-core-dev
2322020-05-28T15:20:06  *** Highway62 has joined #bitcoin-core-dev
2332020-05-28T15:21:39  *** Highway61 has quit IRC
2342020-05-28T15:21:39  *** Highway62 is now known as Highway61
2352020-05-28T15:30:38  *** Talkless has joined #bitcoin-core-dev
2362020-05-28T15:32:05  *** Pavlenex has joined #bitcoin-core-dev
2372020-05-28T15:33:10  *** proofofkeags has joined #bitcoin-core-dev
2382020-05-28T15:34:08  *** kristapsk_ has joined #bitcoin-core-dev
2392020-05-28T15:34:31  *** kristapsk has quit IRC
2402020-05-28T15:38:28  *** justanotheruser has joined #bitcoin-core-dev
2412020-05-28T15:39:23  *** proofofkeags has quit IRC
2422020-05-28T15:41:27  *** proofofkeags has joined #bitcoin-core-dev
2432020-05-28T15:43:22  *** troygiorshev has joined #bitcoin-core-dev
2442020-05-28T15:53:03  *** ghost43 has quit IRC
2452020-05-28T15:53:30  *** ghost43 has joined #bitcoin-core-dev
2462020-05-28T15:55:48  *** bitcoin-git has joined #bitcoin-core-dev
2472020-05-28T15:55:49  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/082a417abcce...ea3e9e0b84c5
2482020-05-28T15:55:49  <bitcoin-git> bitcoin/master e8fa0a3 Samuel Dobson: Fix WSL file locking by using flock instead of fcntl
2492020-05-28T15:55:49  <bitcoin-git> bitcoin/master ea3e9e0 Wladimir J. van der Laan: Merge #18700: Fix locking on WSL using flock instead of fcntl
2502020-05-28T15:55:51  *** bitcoin-git has left #bitcoin-core-dev
2512020-05-28T15:56:19  *** bitcoin-git has joined #bitcoin-core-dev
2522020-05-28T15:56:19  <bitcoin-git> [bitcoin] laanwj merged pull request #18700: Fix locking on WSL using flock instead of fcntl (master...202004_file_lock_windows) https://github.com/bitcoin/bitcoin/pull/18700
2532020-05-28T15:56:20  *** bitcoin-git has left #bitcoin-core-dev
2542020-05-28T15:57:01  *** PaulTroon has quit IRC
2552020-05-28T16:05:01  *** jarthur has joined #bitcoin-core-dev
2562020-05-28T16:08:45  *** justanotheruser has quit IRC
2572020-05-28T16:12:04  *** Pavlenex has quit IRC
2582020-05-28T16:17:31  <MarcoFalke> #proposedmeetingtopic 0.20.0-final
2592020-05-28T16:17:50  <MarcoFalke> #proposedmeetingtopic separate repo for the gui
2602020-05-28T16:17:56  *** PaulTroon has joined #bitcoin-core-dev
2612020-05-28T16:19:52  *** Talkless has quit IRC
2622020-05-28T16:20:21  *** vasild_ has joined #bitcoin-core-dev
2632020-05-28T16:20:32  *** Talkless has joined #bitcoin-core-dev
2642020-05-28T16:23:14  *** Highway62 has joined #bitcoin-core-dev
2652020-05-28T16:24:03  *** vasild has quit IRC
2662020-05-28T16:24:04  *** vasild_ is now known as vasild
2672020-05-28T16:24:34  *** Highway61 has quit IRC
2682020-05-28T16:24:34  *** Highway62 is now known as Highway61
2692020-05-28T16:25:58  *** justanotheruser has joined #bitcoin-core-dev
2702020-05-28T16:29:44  *** Relis has quit IRC
2712020-05-28T16:32:56  *** Highway61 has quit IRC
2722020-05-28T16:34:43  *** Relis has joined #bitcoin-core-dev
2732020-05-28T16:36:19  *** PaulTroon has quit IRC
2742020-05-28T16:46:04  *** bitcoin-git has joined #bitcoin-core-dev
2752020-05-28T16:46:05  <bitcoin-git> [bitcoin] jonatack opened pull request #19092: cli: display multiwallet total balance in -getinfo (master...cli-getinfo-multiwallet-total-balance) https://github.com/bitcoin/bitcoin/pull/19092
2762020-05-28T16:46:06  *** bitcoin-git has left #bitcoin-core-dev
2772020-05-28T16:51:13  *** ghost43 has quit IRC
2782020-05-28T16:51:43  *** ghost43 has joined #bitcoin-core-dev
2792020-05-28T16:54:34  *** joerodgers has quit IRC
2802020-05-28T16:58:47  *** Sammie51Dibbert has joined #bitcoin-core-dev
2812020-05-28T17:04:23  *** Highway61 has joined #bitcoin-core-dev
2822020-05-28T17:05:24  *** timothy has quit IRC
2832020-05-28T17:05:44  *** Sammie51Dibbert has quit IRC
2842020-05-28T17:07:33  *** mmitech_ has joined #bitcoin-core-dev
2852020-05-28T17:12:49  *** troygiorshev has quit IRC
2862020-05-28T17:22:53  *** cltrbreak_MAD2 has quit IRC
2872020-05-28T17:23:21  *** cltrbreak_MAD2 has joined #bitcoin-core-dev
2882020-05-28T17:23:29  *** Hilario58Smith has joined #bitcoin-core-dev
2892020-05-28T17:30:21  *** bitcoin-git has joined #bitcoin-core-dev
2902020-05-28T17:30:22  <bitcoin-git> [bitcoin] rajarshimaitra opened pull request #19093: RPC: testmempoolaccept returns transaction fee (master...fee-trial3) https://github.com/bitcoin/bitcoin/pull/19093
2912020-05-28T17:30:22  *** bitcoin-git has left #bitcoin-core-dev
2922020-05-28T17:33:22  *** mol has joined #bitcoin-core-dev
2932020-05-28T17:36:20  *** mol_ has quit IRC
2942020-05-28T17:37:22  *** bitcoin-git has joined #bitcoin-core-dev
2952020-05-28T17:37:22  <bitcoin-git> [bitcoin] laanwj opened pull request #19094: build: Only allow ASCII identifiers (master...2020_05_no_extended_identifiers) https://github.com/bitcoin/bitcoin/pull/19094
2962020-05-28T17:37:23  *** bitcoin-git has left #bitcoin-core-dev
2972020-05-28T17:38:56  *** bitcoin-git has joined #bitcoin-core-dev
2982020-05-28T17:38:57  <bitcoin-git> [bitcoin] jnewbery opened pull request #19095: [tools] Update clang-format config for multi-line function declarations and calls (master...2020-05-clang-tidy) https://github.com/bitcoin/bitcoin/pull/19095
2992020-05-28T17:38:58  *** bitcoin-git has left #bitcoin-core-dev
3002020-05-28T17:39:47  *** troygiorshev has joined #bitcoin-core-dev
3012020-05-28T17:49:49  *** Hilario58Smith has quit IRC
3022020-05-28T17:50:56  *** Noemi32Moore has joined #bitcoin-core-dev
3032020-05-28T17:53:16  *** dgenr8 has quit IRC
3042020-05-28T17:55:07  *** Highway62 has joined #bitcoin-core-dev
3052020-05-28T17:56:37  *** Highway61 has quit IRC
3062020-05-28T17:56:38  *** Highway62 is now known as Highway61
3072020-05-28T17:58:14  *** Noemi32Moore has quit IRC
3082020-05-28T18:00:02  *** Toflar has quit IRC
3092020-05-28T18:05:06  *** bitcoin-git has joined #bitcoin-core-dev
3102020-05-28T18:05:06  <bitcoin-git> [bitcoin] ryanofsky opened pull request #19096: Remove g_rpc_chain global (master...pr/wc) https://github.com/bitcoin/bitcoin/pull/19096
3112020-05-28T18:05:18  *** bitcoin-git has left #bitcoin-core-dev
3122020-05-28T18:16:30  *** Highway61 has quit IRC
3132020-05-28T18:20:54  *** promag_ has joined #bitcoin-core-dev
3142020-05-28T18:21:04  *** promag has quit IRC
3152020-05-28T18:21:09  *** promag_ is now known as promag
3162020-05-28T18:21:42  *** promag_ has joined #bitcoin-core-dev
3172020-05-28T18:22:09  *** esandeen has joined #bitcoin-core-dev
3182020-05-28T18:22:41  *** proofofkeags has quit IRC
3192020-05-28T18:29:20  *** proofofkeags has joined #bitcoin-core-dev
3202020-05-28T18:29:20  *** proofofkeags has quit IRC
3212020-05-28T18:29:34  *** proofofkeags has joined #bitcoin-core-dev
3222020-05-28T18:34:42  *** lehnberg has quit IRC
3232020-05-28T18:48:14  *** go11111111111 is now known as go1111111
3242020-05-28T18:58:56  *** bitcoin-git has joined #bitcoin-core-dev
3252020-05-28T18:58:56  <bitcoin-git> [bitcoin] achow101 opened pull request #19097: qt: Add missing QPainterPath include (master...qpainterpath-include) https://github.com/bitcoin/bitcoin/pull/19097
3262020-05-28T18:58:57  *** bitcoin-git has left #bitcoin-core-dev
3272020-05-28T19:00:39  <wumpus> #startmeeting
3282020-05-28T19:00:39  <lightningbot> Meeting started Thu May 28 19:00:39 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3292020-05-28T19:00:39  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3302020-05-28T19:00:47  <achow101> hi
3312020-05-28T19:00:48  <sipa> hi
3322020-05-28T19:00:48  <fjahr> hi
3332020-05-28T19:00:50  <provoostenator> hi
3342020-05-28T19:00:55  <jnewbery> hi
3352020-05-28T19:01:01  <instagibbs> hi
3362020-05-28T19:01:06  <amiti> hi
3372020-05-28T19:01:07  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
3382020-05-28T19:01:09  <harding> hi
3392020-05-28T19:01:09  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
3402020-05-28T19:01:17  <promag> hi
3412020-05-28T19:01:29  <jamesob> Hi
3422020-05-28T19:01:31  <dongcarl> hi
3432020-05-28T19:01:45  <troygiorshev> hi
3442020-05-28T19:01:45  <ariard> hi
3452020-05-28T19:01:46  <aj> hi
3462020-05-28T19:01:47  <wumpus> two proposed topics (by MarcoFalke): 0.20.0-final, separate repo for the gui
3472020-05-28T19:02:08  <MarcoFalke> hi, anyone heard or seen of issues with 0.20.0?
3482020-05-28T19:02:22  <kanzure> hi
3492020-05-28T19:02:23  <wumpus> none!
3502020-05-28T19:02:26  <sipa> yes, it's not released yet
3512020-05-28T19:02:32  <MarcoFalke> *rc2
3522020-05-28T19:02:38  <sipa> ;)
3532020-05-28T19:02:46  <MarcoFalke> ah
3542020-05-28T19:03:06  <jonasschnelli> hi
3552020-05-28T19:03:19  <provoostenator> I'm using rc2 on a Linux and macOS machine, so far so good.
3562020-05-28T19:03:22  <wumpus> if not, it's probably time to do the release soon
3572020-05-28T19:03:53  <MarcoFalke> ack
3582020-05-28T19:04:32  <wumpus> #topic High priority for review
3592020-05-28T19:04:50  <fjahr> #18000 can be removed from chasing concept ACK
3602020-05-28T19:04:52  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  currently 5 blockers, 1 bugfix, 4 chasing concept ACK
3612020-05-28T19:04:53  <gribble> https://github.com/bitcoin/bitcoin/issues/18000 | [WIP] Index for UTXO Set Statistics by fjahr · Pull Request #18000 · bitcoin/bitcoin · GitHub
3622020-05-28T19:05:00  <MarcoFalke> Can I exchange mine for #18968 plz
3632020-05-28T19:05:02  <gribble> https://github.com/bitcoin/bitcoin/issues/18968 | doc: noban precludes maxuploadtarget disconnects by MarcoFalke · Pull Request #18968 · bitcoin/bitcoin · GitHub
3642020-05-28T19:05:07  <achow101> add ##18971
3652020-05-28T19:05:09  <wumpus> fjahr: done
3662020-05-28T19:05:10  <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
3672020-05-28T19:05:12  <fjahr> And i would like to add #19055 to blockers, it’s the start of #18000 being split up
3682020-05-28T19:05:14  <gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Calculate UTXO set hash using Muhash by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
3692020-05-28T19:05:16  <promag> #19033 its tagged for 0.20
3702020-05-28T19:05:16  <gribble> https://github.com/bitcoin/bitcoin/issues/18000 | [WIP] Index for UTXO Set Statistics by fjahr · Pull Request #18000 · bitcoin/bitcoin · GitHub
3712020-05-28T19:05:18  <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
3722020-05-28T19:05:35  *** nullptr| has quit IRC
3732020-05-28T19:05:54  <sipa> can i have #18468 ?
3742020-05-28T19:05:57  <gribble> https://github.com/bitcoin/bitcoin/issues/18468 | Span improvements by sipa · Pull Request #18468 · bitcoin/bitcoin · GitHub
3752020-05-28T19:06:11  *** nullptr| has joined #bitcoin-core-dev
3762020-05-28T19:06:13  <sipa> also, thanks everyone for getting the serialization improvements in
3772020-05-28T19:06:18  <sipa> it took a while :)
3782020-05-28T19:06:19  <wumpus> MarcoFalke: done
3792020-05-28T19:06:33  <provoostenator> I'd like to nominate #15382
3802020-05-28T19:06:36  <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | util: add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
3812020-05-28T19:06:56  *** shaunsun_ has quit IRC
3822020-05-28T19:06:59  <jonatack> hi
3832020-05-28T19:07:21  <provoostenator> For code review, but if it gets stuck in another concept discussion, we can bump it to that column.
3842020-05-28T19:08:36  <wumpus> achow101, sipa, fjahr: added
3852020-05-28T19:08:44  <wumpus> sipa: yess finally
3862020-05-28T19:08:46  <sipa> thanks
3872020-05-28T19:08:50  <fjahr> Thank you!
3882020-05-28T19:09:26  <MarcoFalke> sipa: Was good that they were split up into reviewable chunks
3892020-05-28T19:09:32  <wumpus> provoostenator: added
3902020-05-28T19:09:39  <wumpus> right, that really helped
3912020-05-28T19:10:49  *** shaunsun has joined #bitcoin-core-dev
3922020-05-28T19:11:16  <wumpus> promag: added
3932020-05-28T19:11:26  <sipa> MarcoFalke: yes, it really helped; the resulting changes were much better than the original monolithic PR too
3942020-05-28T19:11:35  *** Talkless has quit IRC
3952020-05-28T19:11:40  <MarcoFalke> #18971 has almost 20 commits and changes 1000 lines of code. that sounds like a whole afternoon of review. I wonder if it can be split up as well
3962020-05-28T19:11:43  <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
3972020-05-28T19:12:09  <achow101> MarcoFalke: I'll look into it
3982020-05-28T19:12:41  <provoostenator> achow101: MarcoFalke I'm getting used to the behemoths :-)
3992020-05-28T19:12:51  <wumpus> achow101: great work on the sqlite wallet stuff
4002020-05-28T19:12:58  <jamesob> if high prio list isn't too full, can add #18637?
4012020-05-28T19:13:00  <gribble> https://github.com/bitcoin/bitcoin/issues/18637 | coins: allow cache resize after init by jamesob · Pull Request #18637 · bitcoin/bitcoin · GitHub
4022020-05-28T19:13:30  <MarcoFalke> jamesob: Every contributor is allowed to add one thing, so it's not full yet for you ;)
4032020-05-28T19:13:44  * sipa spins up his sybils
4042020-05-28T19:14:02  <wumpus> jamesob: added
4052020-05-28T19:14:09  <jamesob> thanks maintainers
4062020-05-28T19:15:22  <wumpus> #topic Separate repository for GUI (MarcoFalke)
4072020-05-28T19:15:25  <MarcoFalke> Some more background in #19071
4082020-05-28T19:15:27  <gribble> https://github.com/bitcoin/bitcoin/issues/19071 | [WIP RFC DONOTMERGE] meta: Separate repository for the gui by MarcoFalke · Pull Request #19071 · bitcoin/bitcoin · GitHub
4092020-05-28T19:16:48  <wumpus> I like the idea at least
4102020-05-28T19:17:13  <provoostenator> Same, it seems worth a try and easy to reverse.
4112020-05-28T19:17:15  <MarcoFalke> It is hard to predict if that is going to be benefical for the GUI (Does it increase review or decrease?)
4122020-05-28T19:17:23  <jnewbery> concept ACK. Haven't thought too much about the approach
4132020-05-28T19:17:30  <achow101> i feel like that might kill the gui further..
4142020-05-28T19:17:30  <wumpus> I'd like it to increase contributions mainly
4152020-05-28T19:17:39  <MarcoFalke> Yes, the change is only "meta" (no build system changes), so it should be trivial to revert
4162020-05-28T19:17:54  <wumpus> currently it's *scary* to contribute to the GUI being part of the same repository as the consensus code
4172020-05-28T19:17:55  <MarcoFalke> wumpus: Same, and I think it will.
4182020-05-28T19:18:00  <wumpus> this turns away some ppl
4192020-05-28T19:18:04  <jonasschnelli> Yeah. Definitively worth a try.
4202020-05-28T19:18:27  <jamesob> wumpus: do you really think it actually turns away people, just that GUI is under bitcoin/bitcoin?
4212020-05-28T19:18:34  <wumpus> jamesob: yes
4222020-05-28T19:18:36  <MarcoFalke> The GUI review isn't in the best state anyway right now. It can't get much worse tbh
4232020-05-28T19:18:39  <wumpus> the bar is really high
4242020-05-28T19:18:51  <provoostenator> It's hard to predict. The smaller Github repo might create more of a critical mass for GUI devs. Or it slows down. But in that case we can undo.
4252020-05-28T19:18:57  <jamesob> wumpus: but won't process be the same in the GUI "repo"?
4262020-05-28T19:18:58  <wumpus> MarcoFalke: also true, we could get some more people involed then too
4272020-05-28T19:19:14  <jonatack> I think the key question is if it will draw new contributors to it.
4282020-05-28T19:19:42  <wumpus> jamesob: the process, yeah, I guess, but we don't have to have exactly the same team there
4292020-05-28T19:19:51  <MarcoFalke> jonatack: Even if it didn't draw any new contributors, but the existing ones can more effectively work on core or the gui (or both), then that is already a win, imo
4302020-05-28T19:19:53  <promag> but in what way does it ease new comers and progress if it's another repo? and at the end its all built together?
4312020-05-28T19:19:58  <jamesob> afaict all this change (as proposed) accomplishes is segmentation of email/github alerts & issue/PR queues  - and I'm certainly not knocking that
4322020-05-28T19:20:26  <wumpus> promag: marcofalke's work is one step
4332020-05-28T19:20:28  <MarcoFalke> jamesob: Yes, it is mostly a meta way to form different notification streams
4342020-05-28T19:20:39  <wumpus> I think eventually the GUI should evolve faster / partially separate from the rest
4352020-05-28T19:20:42  <jonasschnelli> The PR/issue separation is IMO already solvable
4362020-05-28T19:20:55  <promag> isn't it better to do this after multiprocess is in?
4372020-05-28T19:20:58  <wumpus> but even separating things like issues is probably good
4382020-05-28T19:21:04  <wumpus> promag: it doesn't matter
4392020-05-28T19:21:22  <provoostenator> I've _rarely_ used the GUI tag to look for GUI PR's. I don't know if I'm more likely to look at a seperate repo, but I image that I'm reviewing 1 GUI PR, I'm more likely to notice another one.
4402020-05-28T19:21:46  <wumpus> the current repository just has too wide a scope
4412020-05-28T19:22:15  <wumpus> it makes sense, conceptually, in the long term to separate things out so why not try to make a little progress
4422020-05-28T19:22:16  <MarcoFalke> It is not only about the tag, but any kind of communication or notifications
4432020-05-28T19:22:16  <harding> I think it's important for Bitcoin Core to continue to ship releases with a default GUI, which this allows, and making it easier for people to follow just GUI issues sounds very nice to me, so +1
4442020-05-28T19:22:25  <jnewbery> promag: there aren't any dependencies between separating GUI into a different repo and multiprocess
4452020-05-28T19:22:27  <troygiorshev> i can imagine it may help attract people who are more UI/UX focused, and who would be scared away by the breadth of the main repo
4462020-05-28T19:22:33  <wumpus> harding: yeah what we ship is not going to change
4472020-05-28T19:23:07  <harding> wumpus: excellent!  I was rather worried about that when I saw the proposed meeting topic.
4482020-05-28T19:23:07  <gwillen> jnewbery: I was going to kind of ask about the same thing, I imagine that a clean interface separation would make it much easier for people to work on the GUI with confidence about not touching anything in consensus or whatever
4492020-05-28T19:23:08  <jamesob> troygiorshev: per this proposal, the breadth in terms of code will be the same (which I think may confuse people)
4502020-05-28T19:23:09  <wumpus> troygiorshev: right
4512020-05-28T19:23:20  *** joerodgers has joined #bitcoin-core-dev
4522020-05-28T19:23:25  <MarcoFalke> I think the only requirement for this split was the src/interfaces cleanup, because previously the gui directly accessed node globals and state IIRC
4532020-05-28T19:23:26  <wumpus> gwillen: there is a clear interface separation already
4542020-05-28T19:23:29  *** jarthur has quit IRC
4552020-05-28T19:23:30  <jnewbery> gwillen: there already is clean interface separation
4562020-05-28T19:23:45  <wumpus> has been there, for a while
4572020-05-28T19:24:13  <achow101> I think this will make some wallet improvements harder. the gui almost has direct access to wallet things and some wallet changes have an effect on the gui
4582020-05-28T19:24:15  <gwillen> I guess a lot of GUI changes do respect that, it's my own fault that my own GUI changes also require changes to that interface and so touch both sides
4592020-05-28T19:24:40  <achow101> so then you end up with having a wallet change that requires simultaneous gui changes. with 2 repos, that's more difficult
4602020-05-28T19:24:57  <jnewbery> at the moment, both sides of that interface are in the same process. But everything goes through src/interfaces/node
4612020-05-28T19:25:01  <promag> but whats the idea? someone clones the gui repo, pulls core somehow and builds eveything?
4622020-05-28T19:25:15  <gwillen> one thing I see a lot of is the GUI reaching "through" the interface layer to grab a direct pointer to an object on the other side and twiddle it
4632020-05-28T19:25:27  <gwillen> but anyway maybe this is off the current topic
4642020-05-28T19:25:29  <wumpus> achow101: for most things the GUI shouldn't care about the *kind* of wallet though
4652020-05-28T19:26:08  <jnewbery> that interface was introduced a couple of years ago and has been cleaned up continually. If separating the GUI dev process into a separate repo makes us clean it up faster, so much the better!
4662020-05-28T19:26:11  <wumpus> achow101: e.g. imagine the GUI or some other software accesses the core wallet through RPC, why would it care the wallet was implemented differently?
4672020-05-28T19:26:27  <MarcoFalke> achow101: If a wallet change has an effect on the gui (e.g. a wallet method was renamed), then that simply goes into the main repo
4682020-05-28T19:26:28  <sipa> i don't have much of an opinion on the repo separation here... i'm skeptical that it will help, but i agree it's easy to revert if not
4692020-05-28T19:26:31  <wumpus> achow101: seems also a matter of interface design
4702020-05-28T19:27:02  <jamesob> it sounds like some people are conflating this proposal with having separate source trees in separate repos; the proposal as-is (IIUC) is to have the same source tree in two separate github repos just to segment github workflow
4712020-05-28T19:27:03  <promag> adding stuff to core+gui at the same time will take longer too right?
4722020-05-28T19:27:15  <wumpus> promag: yes
4732020-05-28T19:27:37  <wumpus> promag: but the preferred flow *already* is, and has been for a long time: implement it in bitcoind, then later add it to the GUI
4742020-05-28T19:27:45  <MarcoFalke> I also don't think we will see groundbreaking changes, but at least we can gather some data points and experience. And based on those a future "complete" split will be easier to reject or accept.
4752020-05-28T19:28:08  <sipa> as for better defined interfaces... if the hope is that this will result in more GUI work, and that happens, I expect we'll find out that more work on the GUI will entail more changes to the interface as well... and having things in separate repositories will only complicate things (i realize that this is not what this PR does, but if that's the eventual goal... it can cut both ways)
4762020-05-28T19:28:26  <jamesob> sipa: agreed
4772020-05-28T19:28:34  <jnewbery> sipa: sounds like a good problem
4782020-05-28T19:28:34  <wumpus> I like to split up the repository, ideally I'd like to have started at seperating out consensus code, but we all agree it's much harder than the GUI :)
4792020-05-28T19:28:39  <achow101> wumpus: I think a specific example of what I'm talking about was with descriptor wallets and watchonly. The GUI had to display different things for descriptor wallets because of the different watchonly behavior, so there needed to be simultaneous wallet and gui changes otherwise the gui would show the wrong thing.
4802020-05-28T19:28:49  <MarcoFalke> sipa: It is currently not decided if interfaces count to the gui side or the node side
4812020-05-28T19:28:51  <achow101> I suppose that's more an artifact of legacy wallets though and maybe doesn't matter moving forwards
4822020-05-28T19:28:56  *** kvaciral has joined #bitcoin-core-dev
4832020-05-28T19:29:08  <sipa> MarcoFalke: node side, obviously?
4842020-05-28T19:29:13  <jonasschnelli> why would the interface be on the GUI side?
4852020-05-28T19:29:13  <wumpus> achow101: I agree it will make some things more difficult, though, that seems like a one-time thing
4862020-05-28T19:29:13  <sipa> they're also used by RPC, no?
4872020-05-28T19:29:21  <MarcoFalke> are they?
4882020-05-28T19:29:28  <wumpus> the interface would be node-side, I guess
4892020-05-28T19:29:32  <MarcoFalke> the rpc directly calls into the node right now
4902020-05-28T19:29:34  <wumpus> that's the idea of an interface
4912020-05-28T19:29:36  <jonasschnelli> it's an interface,.. the GUI consumes/adapts to it.
4922020-05-28T19:29:39  <wumpus> yes
4932020-05-28T19:29:46  *** Highway61 has joined #bitcoin-core-dev
4942020-05-28T19:29:52  *** mol has quit IRC
4952020-05-28T19:29:57  <wumpus> the node defines the interface the GUI uses it
4962020-05-28T19:30:10  <jnewbery> the rpc doesn't use the interface (but I agree with everyone else that it's part of the node)
4972020-05-28T19:30:20  <sipa> huh
4982020-05-28T19:30:23  <wumpus> the GUI can have arbitrary changes as long as the interface doesn't need to change
4992020-05-28T19:30:24  <jonasschnelli> and since the interface is on the node/core side, I think changing the GUI will be much harder
5002020-05-28T19:30:31  <wumpus> no, the RPC doesn't use that interface
5012020-05-28T19:30:35  <wumpus> that doesn't matter here though
5022020-05-28T19:30:37  <sipa> ok, i never paid attention to the interface side, but i assumed it would be shared between GUI and RPC
5032020-05-28T19:30:40  *** dgenr8 has joined #bitcoin-core-dev
5042020-05-28T19:30:58  <wumpus> RPC is very tightly bound to the node and that's not going to change any time soon
5052020-05-28T19:31:09  <jamesob> ironic that the guy leading process sep (ryanofsky) isn't saying anything!
5062020-05-28T19:31:26  <MarcoFalke> silence means ACK, right?
5072020-05-28T19:31:34  <jamesob> maxim of the law, yes
5082020-05-28T19:31:44  <jonatack> What were the pain points driving the proposed change? ISTM this isn't clear in the RFC. Lack of GUI review? Other things?
5092020-05-28T19:31:50  <troygiorshev> is there confusion in where PRs that touch both sides would go?
5102020-05-28T19:31:52  <jnewbery> but again, process sep is almost completely orthogonal
5112020-05-28T19:31:57  <wumpus> jonasschnelli: it will make changing the GUI harder *if* it needs an interface change
5122020-05-28T19:31:59  <provoostenator> Two seperate repos might also make it (slightly) easier to demo more radical forms of splitting the code.
5132020-05-28T19:32:03  <jamesob> jnewbery: right
5142020-05-28T19:32:22  <jonasschnelli> MarcoFalke: I'm currently working on a GUI PR that (mempool histogram) that changes the interface.. how would I have to proceed?
5152020-05-28T19:32:24  <wumpus> jonasschnelli: if it's internal to the GUI, say, moving around some buttons or changing dialogs, not so much, and that's the kind of thing that *needs* to be easier
5162020-05-28T19:32:26  <provoostenator> troygiorshev: no, they go to the main repo
5172020-05-28T19:32:51  <jonasschnelli> First PR the interface change (without an consuming element),... then PR the GUI part? Or simultanously... how do we handle the merge?
5182020-05-28T19:32:59  <promag> wumpus: why? is it hard?
5192020-05-28T19:33:07  <provoostenator> jonasschnelli: I usually make two PR's that build on eachother
5202020-05-28T19:33:14  <MarcoFalke> jonasschnelli: Well, everyone except me said that interfaces are node code, so I guess you will have to add the interface first and then make the gui changes
5212020-05-28T19:33:44  <sipa> jnewbery: i don't know if an outcome where it's easier to make nitty changes, but harder to make substantial changes, is an improvement
5222020-05-28T19:33:48  <wumpus> yes, you'll have to change the interface first
5232020-05-28T19:34:02  <wumpus> same as if you were going to change an RPC-facing application and needed some new interface
5242020-05-28T19:34:03  <jonasschnelli> MarcoFalke: what would be merged first? Or simulatnously?
5252020-05-28T19:34:03  <MarcoFalke> Obviously this means there will be an unsused method in the interface temporarily, but that should be ok
5262020-05-28T19:34:09  <gwillen> sipa: well, I think it depends on what your goal is for the GUI
5272020-05-28T19:34:15  <MarcoFalke> the interface change will be merged first
5282020-05-28T19:34:24  <gwillen> right now it is clearly a user interface designed by programmers who would rather be doing literally anything other than designing a user interface ;-)
5292020-05-28T19:34:29  <jonasschnelli> what is the GUI change never gets merged?
5302020-05-28T19:34:34  *** lehnberg has joined #bitcoin-core-dev
5312020-05-28T19:34:47  <MarcoFalke> It can also be merged at the same time, I guess?
5322020-05-28T19:34:49  <gwillen> I assume the hope is that separating it means that the GUI can get a lot more work from people who have more expertise in GUIs and less in the backend behind it
5332020-05-28T19:34:50  *** owowo has quit IRC
5342020-05-28T19:34:57  <jonasschnelli> If we merge at the same time... do we have really benefits?
5352020-05-28T19:35:05  <wumpus> jonasschnelli: sure, you'd have to coordinate that
5362020-05-28T19:35:14  <provoostenator> I hope eventually the GUI and RPC use the same interface, but that's not anytime soon...
5372020-05-28T19:35:15  <sipa> as an example... btcd started out with separate repos and well-defined interfaces between wallet and node and p2p and ... and after a while they realized it's too much of a pain and moved everything into one repo
5382020-05-28T19:35:24  <MarcoFalke> jonasschnelli: The majority of GUI changes hopefully don't change the interface
5392020-05-28T19:35:29  <wumpus> provoostenator: that was always my preference, but it's not going to happen, face it
5402020-05-28T19:35:30  <sipa> because interesting changes invariable change the interface
5412020-05-28T19:35:41  <jonasschnelli> ^ +1
5422020-05-28T19:35:41  <MarcoFalke> I hope the interface converges over time
5432020-05-28T19:35:51  <jonasschnelli> That would mean the GUI has stalled
5442020-05-28T19:36:04  <jonasschnelli> (eventually)
5452020-05-28T19:36:16  <jonasschnelli> (maybe not)
5462020-05-28T19:36:23  <wumpus> I do think it's absurd to have everything from the consensus code to GUI in the same repo, and would like to change this
5472020-05-28T19:36:28  <wumpus> but yes where to start
5482020-05-28T19:36:32  <jamesob> I was going to argue that true repo separation is good because it makes us more likely to screw up the dangerous stuff (consensus, network), but I'm not even sure there's a good argument for that
5492020-05-28T19:36:34  <sipa> wumpus: yes, i know
5502020-05-28T19:36:40  <jonasschnelli> wumpus. Yes. I agree.
5512020-05-28T19:36:41  <ryanofsky> sorry missed earlier discussion, but i think there's a lot of work can get done in gui that doesn't require changing interfaces
5522020-05-28T19:36:42  <jamesob> *less likely!
5532020-05-28T19:37:00  <jonasschnelli> But still,... a tiny GUI change can draw the code node down (since everything runs in the same process)
5542020-05-28T19:37:01  *** Highway61 has quit IRC
5552020-05-28T19:37:05  <jonasschnelli> We still have to be careful
5562020-05-28T19:37:07  <jnewbery> sipa: "if this will result in more GUI work ... more work on the GUI will entail more changes to the interface" is the good problem :)
5572020-05-28T19:37:15  <wumpus> jonasschnelli: hence the process separation work
5582020-05-28T19:37:31  <ryanofsky> for changes that do affect interfaces, just submit the pr in the main repo. or if it's easy just add the interface in one pr and use it in a different pr
5592020-05-28T19:37:31  <promag> how would this benefit new GUIs?
5602020-05-28T19:37:37  <jonasschnelli> Yes. I just wonder if it would be wiser to seperate the repositories with merging "the" process seprataion
5612020-05-28T19:37:41  <elichai2> Sipa I can give an example of where it does work. In the rust compiler there's a monorepo that contains most of the complex compiler stuff and it contains submodules of interface tools (static analysis, dynamic analysis, more lints etc) and when a PR changes both repos they're linked together and after ACK on both sides they first merge the compiler side and then the tool's side.
5622020-05-28T19:38:02  <MarcoFalke> promag: Right now the change does not benefit new GUIs
5632020-05-28T19:38:14  <wumpus> it's only one step
5642020-05-28T19:38:18  <wumpus> come on
5652020-05-28T19:38:36  <jonasschnelli> Yeah. I agree that its worth a try
5662020-05-28T19:38:47  <jonasschnelli> It might be simpler and more efficient that we initially think.
5672020-05-28T19:38:48  <MarcoFalke> It is a step in the direction. If we can't get that done, then we shouldn't attempt any further splits imo
5682020-05-28T19:38:49  <jonasschnelli> Lets try
5692020-05-28T19:38:49  <achow101> I suppose that if we can easily revert it later then it's fine
5702020-05-28T19:38:57  <sipa> yeah, this discussion isn't about this PR anymore but more longer-term effects
5712020-05-28T19:39:01  <jamesob> heck I'm ACK. it'll be easy to revert, and if maintainers want it then so be it - they're the ones who it affects most
5722020-05-28T19:39:03  <ryanofsky> yeah, it's just a minor step. i can't see how it would help anything that email filtering wouldn't help, but it seems harmless
5732020-05-28T19:39:12  <sipa> i agree with this because it's so easy to revert
5742020-05-28T19:39:27  <jonasschnelli> PR/email filtering is easy... that should not be the reason to split off
5752020-05-28T19:39:40  <wumpus> yes, filtering is easy, that's not the point
5762020-05-28T19:39:40  <jonasschnelli> review style,.. contributors should it be
5772020-05-28T19:39:41  <wumpus> delegation is
5782020-05-28T19:39:45  <jonasschnelli> yes
5792020-05-28T19:39:50  <wumpus> I don't want to be the bottleneck for everything
5802020-05-28T19:39:56  <wumpus> certainly not on the long run
5812020-05-28T19:40:02  <sipa> of course
5822020-05-28T19:40:03  <jonasschnelli> indeed.
5832020-05-28T19:40:08  <wumpus> the bitcoi repositry is way too broad
5842020-05-28T19:40:09  <jb55> I wouldn't say its that easy, there's no way to filter based on labels via email
5852020-05-28T19:40:11  <elichai2> The downside of "reverting" is losing PRs/Issues history.(by having some of it in a deprecated out of date repo) Altough that's probably not a big deal
5862020-05-28T19:40:27  <promag> wumpus: right, one step, I'm just wondering about the next steps
5872020-05-28T19:40:28  <ryanofsky> how is this different than you just filtering out gui-tagged prs and issues?
5882020-05-28T19:40:33  <provoostenator> I don't even use email for notifications :-)
5892020-05-28T19:40:35  <wumpus> sigh...
5902020-05-28T19:40:39  <achow101> elichai2: issues can be moved between repos now. not sure about prs
5912020-05-28T19:40:56  <elichai2> achow101: you're right. Forgot about that feature
5922020-05-28T19:40:59  <jamesob> jb55: agree, also curious how people are filtering gui emails out...
5932020-05-28T19:41:01  <MarcoFalke> elichai2: The same pr (commit hash) can be opened against either repo
5942020-05-28T19:41:08  <sipa> ryanofsky: someone has to merge things still, and i think wumpus feels responsible for that eventually
5952020-05-28T19:41:11  <wumpus> yes, how are you even doing that?
5962020-05-28T19:41:37  *** owowo has joined #bitcoin-core-dev
5972020-05-28T19:41:45  <MarcoFalke> I click on "mute conversation" manually on most gui emails
5982020-05-28T19:41:54  <achow101> isn't jonasschnelli supposed to be the gui maintainer?
5992020-05-28T19:42:01  <jamesob> achow101: LOL
6002020-05-28T19:42:03  <jonasschnelli> I try to take care of the GUI prs...
6012020-05-28T19:42:08  <jonasschnelli> though there are a lot of PR waiting for more reviewers..
6022020-05-28T19:42:18  <wumpus> currently, yes
6032020-05-28T19:42:23  <jonasschnelli> or are of isigificance that it doesnt attact reviewers
6042020-05-28T19:42:25  <jonatack> github-cli now works quite well for filtering things by label
6052020-05-28T19:42:40  <jnewbery> MarcoFalke: what's the process for merging from the GUI repo to the main repo? Do you propose that it happens immediately after a PR is merged, or do you batch it? Do all of the reviewer ACKs get lost?
6062020-05-28T19:42:48  <jonasschnelli> if a GUI misses review or maintainer action,.. just point me to it.
6072020-05-28T19:42:59  <wumpus> I can't be the only person why things it's, in principle, absurd for the GUI to be in the same repository as critical consensus code
6082020-05-28T19:43:00  <MarcoFalke> jnewbery: The github-merge.py script does it
6092020-05-28T19:43:11  <jonasschnelli> wumpus: agre
6102020-05-28T19:43:14  <MarcoFalke> It is instantaneous to both repos, nothing is lost
6112020-05-28T19:43:25  <jamesob> what is the anticipated burden of rerouting people filing issues/PRs in bitcoin/bitcoin to bitcoin/bitcoin-gui when appropriate?
6122020-05-28T19:43:35  <MarcoFalke> jonasschnelli: I think #16432 is close to merge (off-topic)
6132020-05-28T19:43:39  <gribble> https://github.com/bitcoin/bitcoin/issues/16432 | qt: Add privacy to the Overview page by hebasto · Pull Request #16432 · bitcoin/bitcoin · GitHub
6142020-05-28T19:43:42  <wumpus> but in any case it seems I have a large disconnect with other developers in that regard
6152020-05-28T19:43:43  *** jarthur has joined #bitcoin-core-dev
6162020-05-28T19:44:01  <MarcoFalke> jamesob: A linter could do that
6172020-05-28T19:44:16  <jamesob> wumpus: no I think there's broad agreement there. does *anyone* think that all else equal, gui + consensus is a good thing?
6182020-05-28T19:44:24  <jonasschnelli> MarcoFalke: indeed... will take a final look
6192020-05-28T19:44:38  <ryanofsky> MarcoFalke, master branch is effectively mirrored both repos?
6202020-05-28T19:44:44  <provoostenator> One can make the same argument for the wallet, but that's about the only think I can think of splitting.
6212020-05-28T19:44:48  <MarcoFalke> ryanofsky: Yes. monotree
6222020-05-28T19:44:52  *** Highway61 has joined #bitcoin-core-dev
6232020-05-28T19:44:56  <wumpus> jamesob: I don't know, this comes up every few years and it seems besides a few people agreeing, most thing the status quo is okay
6242020-05-28T19:45:09  <MarcoFalke> The gui repo only has the master branch (or tree)
6252020-05-28T19:45:17  <wumpus> provoostenator: yes, one can make the same argument for the walet, but that's a discussion for another time
6262020-05-28T19:45:35  <provoostenator> agreed, GUI is a good place to start
6272020-05-28T19:45:37  <MarcoFalke> Yes, let's wait with the wallet until at least next year :)
6282020-05-28T19:45:52  <MarcoFalke> No need to rush
6292020-05-28T19:46:00  <wumpus> right, need to start somewheere and with some small step
6302020-05-28T19:46:20  <MarcoFalke> Separation was suggested in 2013. At one point we need to take a small step
6312020-05-28T19:46:25  <wumpus> yes...
6322020-05-28T19:46:26  <MarcoFalke> (or even earlier)
6332020-05-28T19:46:29  <jonasschnelli> heh
6342020-05-28T19:46:30  <wumpus> 2012 I think
6352020-05-28T19:46:37  <wumpus> I was ther
6362020-05-28T19:46:49  <sipa> you wrote the qt gui :p
6372020-05-28T19:46:57  <MarcoFalke> blame wumpus
6382020-05-28T19:46:57  <wumpus> biggest mistake in my life
6392020-05-28T19:47:02  <MarcoFalke> xD
6402020-05-28T19:47:04  <sipa> no it wasn't
6412020-05-28T19:47:08  <wumpus> well ,second (but not going into details there)
6422020-05-28T19:47:09  <jonasschnelli> hah
6432020-05-28T19:47:14  <jamesob> lol
6442020-05-28T19:47:18  <jb55> at least it wasn't an electron gui
6452020-05-28T19:47:22  <sipa> imagine we'd still be stuck on a pre-release wxwindows version
6462020-05-28T19:47:22  <MarcoFalke> the gui made me contribute to Core
6472020-05-28T19:47:24  <wumpus> heh
6482020-05-28T19:47:30  <jonasschnelli> me 2
6492020-05-28T19:47:43  <jonasschnelli> the GUI is a great module to win new contributors
6502020-05-28T19:48:02  <aj> jamesob: (consensus and a block-explorer gui; p2p and a p2p gui; and wallet and wallet gui make sense as individual pairs; consensus and wallet gui seem weird, but not an unreasonable consequence of us not having split consensus, p2p and wallet into separate repos)
6512020-05-28T19:48:05  <wumpus> I'm sorry to not have addressed #17145 though when I could
6522020-05-28T19:48:06  <gribble> https://github.com/bitcoin/bitcoin/issues/17145 | GUI event loop should be block free · Issue #17145 · bitcoin/bitcoin · GitHub
6532020-05-28T19:48:07  <jonasschnelli> without the interfaces, it was also easier to learn about the internals
6542020-05-28T19:48:14  <elichai2> I know dozens of people that run full nodes only because of the gui
6552020-05-28T19:48:52  <jonasschnelli> wumpus: no worries. Don't blame yourself. Things evolve. No-one would have started everything async in 2011.
6562020-05-28T19:48:55  <wumpus> I'm glad to hear some people do appreciate it :)
6572020-05-28T19:49:14  <jb55> elichai2: yeah I mainly use gui now due to the recent psbt/hww features
6582020-05-28T19:49:14  <jamesob> aj: I see what you're getting at there - but I think the rationale is that consensus is so sensitive that you want it as isolated as is practical
6592020-05-28T19:49:22  <jonasschnelli> Yeah. We should not underestimate the GUI (even if most of us devs won't use it).
6602020-05-28T19:50:01  <MarcoFalke> I like the RPC console :)
6612020-05-28T19:50:08  <MarcoFalke> (10 min left)
6622020-05-28T19:50:09  <jonasschnelli> m2
6632020-05-28T19:50:11  <gwillen> jb55: :D that's exciting to hear, and I swear I am going to go rebase #18027 today so you can use it on master :-)
6642020-05-28T19:50:14  <gribble> https://github.com/bitcoin/bitcoin/issues/18027 | "PSBT Operations" dialog by gwillen · Pull Request #18027 · bitcoin/bitcoin · GitHub
6652020-05-28T19:50:15  <ariard> side-topic, on altnet, I've started to gather issues here : https://github.com/ariard/altnet-proposals
6662020-05-28T19:50:37  <wumpus> jamesob: yes, isolating the consensus code would be the other side to start, but it technically much more difficult
6672020-05-28T19:50:44  * sipa idly wonders if bitcoin 0.4.0 would compile against wxwidget 3.0 (as the 2.9 that was used at the time was never released...)
6682020-05-28T19:50:45  <ariard> currently in the process talking with people who do actually alt-coms, to learn what could help them
6692020-05-28T19:51:08  <jb55> gwillen: :+1:
6702020-05-28T19:51:10  <instagibbs> gwillen, :D
6712020-05-28T19:51:20  <jamesob> ariard: nice ascii art
6722020-05-28T19:51:20  <provoostenator> jonasschnelli: without the interfaces, you had no choice but to learn the internals :-)
6732020-05-28T19:51:29  <jonasschnelli> right!
6742020-05-28T19:51:43  <MarcoFalke> writing new interfaces will also teach the internals ;)
6752020-05-28T19:52:17  <gwillen> instagibbs: :D thanks for the reminder about that PR last week, you put it back on my radar, then I avoided replying out of embarrassment
6762020-05-28T19:52:27  <jonatack> gwillen: nice!
6772020-05-28T19:52:30  <wumpus> but definitely, if someone was to start designing a GUI nowadays, they'd start with using RPC and an all-async design
6782020-05-28T19:52:35  <MarcoFalke> And maybe it is a good thing that new gui contributors don't need to learn the cs_main horror
6792020-05-28T19:52:36  <provoostenator> Looking forward to reviewing that one gwillen
6802020-05-28T19:53:03  <wumpus> but hey my GUI was better separated from the core code than Satoshi's was…
6812020-05-28T19:53:04  <promag> MarcoFalke: re separation, all in to help out - still skeptical though
6822020-05-28T19:53:11  <instagibbs> gwillen, non-0 amount of people including me will use it
6832020-05-28T19:53:17  <jamesob> "How I Learned to Stop Worrying and Love cs_main"
6842020-05-28T19:53:32  <jb55> we should bring back the poker client as per satoshi's vision
6852020-05-28T19:53:56  <MarcoFalke> Also fun draw transaction (requested in 2016)
6862020-05-28T19:54:05  <sipa> wumpus: you mean it was a problem that main.cpp called into the GUI directly?
6872020-05-28T19:54:22  <sipa> MarcoFalke: and savage wallet
6882020-05-28T19:54:25  <wumpus> sipa: heh
6892020-05-28T19:54:29  <MarcoFalke> what could possibly go wrong?
6902020-05-28T19:55:04  <jamesob> hey uh by the way when's the next coredev?
6912020-05-28T19:55:14  <jamesob> should we do something digitally?
6922020-05-28T19:55:28  <jonasschnelli> in person?! 😱
6932020-05-28T19:55:35  <MarcoFalke> Wait for the vaccine first, maybe
6942020-05-28T19:55:54  <instagibbs> jamesob, might be worth asking fulmo folks they've done a few hackathons
6952020-05-28T19:55:56  <wumpus> at the first next year I guess
6962020-05-28T19:56:13  <sipa> i don't know how valuable a virtual coredev would be
6972020-05-28T19:56:20  <wumpus> travel is going to be a mess for a while
6982020-05-28T19:56:22  <jonasschnelli> we have that already
6992020-05-28T19:56:24  <MarcoFalke> IRC!
7002020-05-28T19:56:25  <sipa> i feel IRC is pretty good for communication
7012020-05-28T19:56:26  <wumpus> yesss
7022020-05-28T19:56:42  <sipa> in-person is definitely better... but, we'll need to wait for that
7032020-05-28T19:56:47  <wumpus> I personally don't feel like doing vr or video chat or something
7042020-05-28T19:57:04  <MarcoFalke> I am certainly not buying VR glasses
7052020-05-28T19:57:04  <sipa> i like vr meetups... but not for more than 1-2 hours
7062020-05-28T19:57:18  <jb55> can't get my vr setup working on my linux distro :(
7072020-05-28T19:57:21  <sipa> and they're more a social thing than a communication thing
7082020-05-28T19:57:31  <jonasschnelli> yes
7092020-05-28T19:57:33  <jamesob> right
7102020-05-28T19:57:36  <jonatack> agree
7112020-05-28T19:57:39  <jonasschnelli> Lets aim for next year...
7122020-05-28T19:57:42  <jonasschnelli> plz hawaii. :)
7132020-05-28T19:57:49  <jnewbery> jonasschnelli: do you mind taking a look at https://github.com/bitcoin/bitcoin/pull/15206#issuecomment-634707439? I like the approach there that moves the header checking to net.cpp and doesn't change behaviour
7142020-05-28T19:58:04  <jonasschnelli> jnewbery: it's on my list
7152020-05-28T19:58:05  <jonasschnelli> will do first thing tmr
7162020-05-28T19:58:06  <wumpus> :D
7172020-05-28T19:58:14  <jnewbery> great. Thanks!
7182020-05-28T19:58:54  <promag> facebook has this rooms thing now -.-
7192020-05-28T19:59:24  <wumpus> concept ACK #15206 somehow missed that one
7202020-05-28T19:59:24  <gribble> https://github.com/bitcoin/bitcoin/issues/15206 | Immediately disconnect on invalid net message checksum by jonasschnelli · Pull Request #15206 · bitcoin/bitcoin · GitHub
7212020-05-28T19:59:29  <wumpus> oh I didn't but it's more than a year old hehe
7222020-05-28T20:00:02  <promag> dong
7232020-05-28T20:00:04  <jonasschnelli> Yeah.. you concept ACKd long time ago
7242020-05-28T20:00:06  <wumpus> #endmeeting
7252020-05-28T20:00:06  <lightningbot> Meeting ended Thu May 28 20:00:06 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7262020-05-28T20:00:06  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-28-19.00.html
7272020-05-28T20:00:06  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-28-19.00.txt
7282020-05-28T20:00:06  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-28-19.00.log.html
7292020-05-28T20:00:13  <jamesob> pretty good meeting. missed you guys :)
7302020-05-28T20:00:30  <MarcoFalke> jamesob: wen assumeutxo?
7312020-05-28T20:00:33  <jnewbery> wumpus: I think https://github.com/troygiorshev/bitcoin/tree/p2p-refactor-header is possibly a cleaner implementation
7322020-05-28T20:00:40  <jamesob> MarcoFalke: as fast as you can merge it buddy
7332020-05-28T20:01:57  <MarcoFalke> jnewbery: I am happy to review both versions. From the perspective of the disconnected peer, they should behave identical.
7342020-05-28T20:02:36  <jnewbery> the p2p-refactor-header doesn't disconnect the peer (maintains current behaviour)
7352020-05-28T20:03:43  *** kristapsk_ has quit IRC
7362020-05-28T20:03:50  <MarcoFalke> The tests are changed, so it changes log behavior at least :)
7372020-05-28T20:03:54  <wumpus> jamesob: welcome back!
7382020-05-28T20:04:31  <wumpus> jnewbery: wait, isn't the disconnection the point?
7392020-05-28T20:06:07  <troygiorshev> wumpus: not really.  Yes from the title of the PR, but the discussion has moved to it just being a refactor of the checks into net from net_processing
7402020-05-28T20:06:19  <troygiorshev> #15197 is the "other half"
7412020-05-28T20:06:21  <wumpus> if a peer sends invalid data it should be disconnected imo
7422020-05-28T20:06:21  <gribble> https://github.com/bitcoin/bitcoin/issues/15197 | Refactor and slightly stricter p2p message processing by jonasschnelli · Pull Request #15197 · bitcoin/bitcoin · GitHub
7432020-05-28T20:06:55  <wumpus> if it's just a refactor I'm not sure it's that interesting
7442020-05-28T20:07:42  *** promag has quit IRC
7452020-05-28T20:11:01  *** shaunsun_ has joined #bitcoin-core-dev
7462020-05-28T20:12:57  *** shaunsun has quit IRC
7472020-05-28T20:13:23  <wumpus> I guess the only thing causing it to disconnect on complete garbage is the invalid messagestart bytes now
7482020-05-28T20:14:08  <troygiorshev> i found in testing that most of the time garbage was being rejected on message size
7492020-05-28T20:14:19  <troygiorshev> (pretty likely to have a 1 in the first 15 bits of the message size field)
7502020-05-28T20:15:41  <wumpus> will it disconnect for invalid size though?
7512020-05-28T20:15:48  <wumpus> m_valid_header=false doesn't seem to be a disconnect condition
7522020-05-28T20:15:56  <troygiorshev> it's in readheader
7532020-05-28T20:16:55  <troygiorshev> it's there so that we don't possibly read and hash >4G from the peer before disconnecting
7542020-05-28T20:17:34  <wumpus> yes there's that :)
7552020-05-28T20:19:19  *** DeanWeen has joined #bitcoin-core-dev
7562020-05-28T20:21:28  <troygiorshev> m_valid_header effectively only pertains to the messagetype.  The other two checks (size and netmagic) are done and dealt with beforehand.  I think (hope) i caught all of the overlap in my branch
7572020-05-28T20:21:40  <achow101> MarcoFalke: How split up do you want #18971 to be? Most of the commits are self contained and could standalone, but don't necessarily make sense by themselves. So I could make 10 PRs with 2 or so commits each, but would that really be beneficial?
7582020-05-28T20:21:42  <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
7592020-05-28T20:21:43  *** Dean_Guss has quit IRC
7602020-05-28T20:22:05  <wumpus> troygiorshev: right, invalid message types are okay to ignore
7612020-05-28T20:22:43  <wumpus> explicitly shouldn't disconnect for those as it's an extension mechanism
7622020-05-28T20:22:44  <MarcoFalke> achow101: Not sure. I guess reviewers can also do several afternoons reviewing 5 commits each and then sharing their intermediate review comments incrementally
7632020-05-28T20:26:24  <wumpus> (though having NUL bytes in between the name, what it checks for there, is questionable, and also tends to indicate corruption or a buggy implementation)
7642020-05-28T20:33:50  <troygiorshev> imo we should disconnect on those two checks (0s and invalid chars), and disconnect on checksum fail, and stay connected on an unrecognized but otherwise well-constructed message type.  There was a lot of disagreement in the pr and the pr review club though.  At least my branch will make it easier to do that in the future :)
7652020-05-28T20:35:03  *** lehnberg has quit IRC
7662020-05-28T20:38:54  <wumpus> I guess checksum failures can *rarely* happen for users that are on really crappy networks, TCP and IP checksums will catch most corruption, it needs to be really bad for it to sometimes slip through that
7672020-05-28T20:39:29  <wumpus> in the case of something like SSH that's annoying because yo ureally want to remain connected to that one host, for bitcoin P2P though ,they'll just connect to a different node
7682020-05-28T20:39:38  *** Guyver2 has quit IRC
7692020-05-28T20:42:16  *** jarthur has quit IRC
7702020-05-28T20:46:32  <jnewbery> wumpus: there was lots of discussion about whether we should drop the message or disconnect in the case of a bad checksum. See here onwards if you're interested: https://bitcoincore.reviews/15206.html#l-81
7712020-05-28T20:47:18  *** marcoagner has quit IRC
7722020-05-28T20:47:37  <wumpus> jnewbery: thanks!
7732020-05-28T20:48:15  <jnewbery> the short answer is that jonasschnelli's PR did two things: move checksum checking from net_processing into net (definitely good), and change behaviour from drop message to disconnect peer (probably good, but at least worth discussion)
7742020-05-28T20:48:52  <jnewbery> Troy's branch just does the first, so discussion of the behaviour change can be separated
7752020-05-28T20:49:15  <wumpus> I understand, disconnecting a peer for one corrupted message sounds like overkill somehow, and not really robust
7762020-05-28T20:49:51  <wumpus> especially as bitcoin's P2P protocol is more or less stateless and can handle lost messages
7772020-05-28T20:50:21  <jnewbery> right. There was some discussion about whether an overzelous firewall could mess around with IP addresses in version or addr messages and break the checksum. Anyway, it's all in the review club notes :)
7782020-05-28T20:50:44  <jonasschnelli> I start to agree with wumpus...
7792020-05-28T20:51:11  <jonasschnelli> The longer i noodle about it,... the more sense it makes to close 15206
7802020-05-28T20:51:58  <jnewbery> jonasschnelli: not changing behaviour is the conservative choice
7812020-05-28T20:52:25  <jonasschnelli> Yeah. But the refactor alone doesn't really make much sense...
7822020-05-28T20:52:31  *** mol has joined #bitcoin-core-dev
7832020-05-28T20:52:59  <jonasschnelli> its nice. but not necessary anymore for future transport protocols (like BIP324)
7842020-05-28T20:53:06  *** jarthur has joined #bitcoin-core-dev
7852020-05-28T20:53:08  <jnewbery> I think it does. Moving header checking down and making net processing unaware of p2p header format is a useful thing
7862020-05-28T20:53:17  *** jarthur has quit IRC
7872020-05-28T20:53:20  <jnewbery> both for BIP324 and altnet
7882020-05-28T20:53:31  <jnewbery> and just good architecture
7892020-05-28T20:53:37  <jonasschnelli> Yes. I agree.
7902020-05-28T20:53:44  *** jarthur has joined #bitcoin-core-dev
7912020-05-28T20:53:49  *** kristapsk has joined #bitcoin-core-dev
7922020-05-28T20:53:50  <jonasschnelli> I strip down the PR... but it's impact and refactoring leverage is minimal.
7932020-05-28T20:54:35  <wumpus> jnewbery: that's an interesting thought though: if it replaces a certain 4-byte sequence with another one, consistently, that will also interfere with some blocks and header propagation at the least
7942020-05-28T20:54:41  <jnewbery> take a look at Troy's branch before you spend too much time changing yours. It's slightly fiddly to do the checking in net.cpp without causing a disconnect
7952020-05-28T20:54:56  <jonasschnelli> Yes. I'll do that.
7962020-05-28T20:57:37  <jnewbery> wumpus: I'm not personally convinced about the firewalls changing messages argument, but it was presented as a reason to be careful about changing behaviour
7972020-05-28T21:00:01  *** esandeen has quit IRC
7982020-05-28T21:01:14  <wumpus> jnewbery: clearly we should do scrambling + error correction at the application layer to work around network layer corruption :-)
7992020-05-28T21:02:23  <wumpus> or even just scrabling, at least the bit patterns that cause packet drop would be unpredictable then
8002020-05-28T21:03:14  *** bitcoin-git has joined #bitcoin-core-dev
8012020-05-28T21:03:14  <bitcoin-git> [bitcoin] ryanofsky opened pull request #19098: test: Remove duplicate NodeContext hacks (master...pr/qtx) https://github.com/bitcoin/bitcoin/pull/19098
8022020-05-28T21:03:15  *** bitcoin-git has left #bitcoin-core-dev
8032020-05-28T21:03:57  *** promag has joined #bitcoin-core-dev
8042020-05-28T21:04:08  *** waxwing has quit IRC
8052020-05-28T21:04:16  *** waxwing_ has joined #bitcoin-core-dev
8062020-05-28T21:07:57  <wumpus> in any case the only reason this is controversial at all is because bitcoin's P2P is semi-stateless so losing a packet is not necessarily fatal, in a stateful protocol the only sensible thing is to disconnect
8072020-05-28T21:08:24  <sipa> many messages aren't stateless at all
8082020-05-28T21:08:35  <wumpus> I know, hence the semi-
8092020-05-28T21:08:43  <wumpus> otherwise the best suggestion would be to just go UDP
8102020-05-28T21:08:49  <sipa> right
8112020-05-28T21:15:43  <wumpus> when corruption happens in the middle of something stateful it's probably better to disconnect immediately instead of continue and wait for expiration
8122020-05-28T21:19:54  *** JesusFreke has joined #bitcoin-core-dev
8132020-05-28T21:25:04  <wumpus> the firewall case is statistically mostly bound to happen in addr messages of course
8142020-05-28T21:25:26  *** bitcoin-git has joined #bitcoin-core-dev
8152020-05-28T21:25:26  <bitcoin-git> [bitcoin] ryanofsky opened pull request #19099: refactor: Move wallet methods out of chain.h and node.h (master...pr/wclient) https://github.com/bitcoin/bitcoin/pull/19099
8162020-05-28T21:25:27  *** bitcoin-git has left #bitcoin-core-dev
8172020-05-28T21:25:28  <sipa> and the initial version message
8182020-05-28T21:26:08  <sipa> but yes... if it's in addr messages, maintaining the connection would be preferable
8192020-05-28T21:26:20  <wumpus> that's an interesting one, if the checksum of the initial version message fails ... the connection will never go anywhere
8202020-05-28T21:26:58  <sipa> though it could be a firewall that's only rewriting some address ranges, which only occur in randomly gossiped addressed, not the addresses of the connection partners
8212020-05-28T21:27:44  <wumpus> I know it disconnects if some other message is sent as first message, but a checksum failure will probably keep open the connection
8222020-05-28T21:28:22  <sipa> if anyone is interested: an evolution of current libsecp256k1 master's verification speed in various gcc versions: https://user-images.githubusercontent.com/548488/83195267-d4bc6b00-a0ee-11ea-8e47-4489cd9824ae.png
8232020-05-28T21:28:25  <wumpus> yes it could be very specific about that
8242020-05-28T21:29:57  <wumpus> interesting
8252020-05-28T21:29:59  <sipa> which gcc are 0.20 release binaries built with?
8262020-05-28T21:30:21  <wumpus> so O3 is faster than O3 with asm with 10.0.1?
8272020-05-28T21:30:30  <sipa> indeed
8282020-05-28T21:30:35  <luke-jr> interesting
8292020-05-28T21:30:51  <sipa> but -O2 without asm is suddenly a lot slower
8302020-05-28T21:31:12  <sipa> (note that the y axis isn't rooted at 0)
8312020-05-28T21:31:14  <wumpus> we should do the same check for ARM, I sometimes wonder if gcc already managed to beat my ARM assembly, for RISC-V I couldn't beat it
8322020-05-28T21:31:26  <luke-jr> could it be CPU-specific?
8332020-05-28T21:31:55  <sipa> it's not -march=native or so
8342020-05-28T21:32:04  <sipa> so this is optimized for generic x86_64
8352020-05-28T21:32:14  <luke-jr> but CPUs do perform differently
8362020-05-28T21:32:22  <sipa> of course, my CPU could be more or less close to the generic thing GCC optimizes for
8372020-05-28T21:32:27  <sipa> but that'd be coincidence
8382020-05-28T21:32:39  <wumpus> sipa: gcc 8.x
8392020-05-28T21:32:55  <luke-jr> IMO it'd be an interesting datapoint to get march=native on a few Intel vs AMD CPUs
8402020-05-28T21:33:11  <luke-jr> probably harder to compare tho
8412020-05-28T21:33:14  <sipa> i'll run the same on a ARM threadripper
8422020-05-28T21:33:16  <sipa> eh, AMD
8432020-05-28T21:33:24  * sipa wishes: ARM threadripper
8442020-05-28T21:33:28  <luke-jr> heh
8452020-05-28T21:33:43  <luke-jr> sipa: why wouldn't you just use POWER for that use case?
8462020-05-28T21:33:46  * wumpus wishes: RISC-V threadripper
8472020-05-28T21:34:03  <luke-jr> wumpus: but POWER is more open than RISC-V last I checked ;)
8482020-05-28T21:34:33  <sipa> return -ETOOMANYHYPOTHETICALS;
8492020-05-28T21:38:49  <tryphe> sipa: wow, that's cool! and here i am using gcc 6.3 like a cave man.
8502020-05-28T21:39:21  <sipa> same for clang: https://user-images.githubusercontent.com/548488/83189237-c584ef80-a0e5-11ea-828c-ffea26c50ea1.png
8512020-05-28T21:39:44  <sipa> interestingly for clang, -O2 asm and -O3 asm seem indistinguishable
8522020-05-28T21:42:10  *** Pavlenex has joined #bitcoin-core-dev
8532020-05-28T21:43:48  <wumpus> weird
8542020-05-28T21:44:30  <wumpus> so there, too, asm makes -O3 slower and -O2 faster
8552020-05-28T21:45:36  <wumpus> but not as extreme as for gcc 10.0.1, so they end up on top of each other
8562020-05-28T21:46:02  <luke-jr> could it be issues were found with some optimisers so got demoted to -O3?
8572020-05-28T22:06:37  <wumpus> it wouldn't be the first time secp256k1 triggers a compiler bug, but i doubt compilers are self-aware enough to demote optimizations in that case :)
8582020-05-28T22:07:23  <sipa> wumpus: hmm, i can't recall any examples
8592020-05-28T22:07:24  <luke-jr> well, as long as the bug doesn't impact correctness..
8602020-05-28T22:07:30  <sipa> of secp256k1 triggering a known bug
8612020-05-28T22:08:35  <sipa> maybe it's some meltdown/spectre style protections that got enabled by default?
8622020-05-28T22:08:39  <sipa> unsure about that
8632020-05-28T22:09:13  <luke-jr> speaking of, did anyone ever figure out if we should be enabling retpolines?
8642020-05-28T22:11:06  *** bitcoin-git has joined #bitcoin-core-dev
8652020-05-28T22:11:06  <bitcoin-git> [bitcoin] ryanofsky opened pull request #19101: refactor: remove ::vpwallets and related global variables (master...pr/novp) https://github.com/bitcoin/bitcoin/pull/19101
8662020-05-28T22:11:07  *** bitcoin-git has left #bitcoin-core-dev
8672020-05-28T22:11:19  <wumpus> it's probably better to leave such things to the OS/compiler
8682020-05-28T22:12:14  *** troygiorshev has quit IRC
8692020-05-28T22:13:10  <sipa> gcc has some flags to enable protections, but they're not enabled by default afaik
8702020-05-28T22:13:40  <wumpus> likely because they make things much slower
8712020-05-28T22:13:50  *** bitcoin-git has joined #bitcoin-core-dev
8722020-05-28T22:13:51  <bitcoin-git> [bitcoin] achow101 opened pull request #19102: wallet: Introduce and use DummyDatabase instead of dummy BerkeleyDatabase (master...true-dummydb) https://github.com/bitcoin/bitcoin/pull/19102
8732020-05-28T22:13:51  *** bitcoin-git has left #bitcoin-core-dev
8742020-05-28T22:14:40  <luke-jr> wumpus: the OS/compiler can't guess at what we need
8752020-05-28T22:17:21  <wumpus> there's quite a few kernel-level workarounds at least that activate based on the actual CPU
8762020-05-28T22:20:14  <wumpus> this mostly has to do with guarding the userspace-kernel space interface, which is a clear boundary, inside applications it's a lot less clear what you can do, and there's been such a cesspool of different vulnerabilities I'm not sure anyone does
8772020-05-28T22:21:57  <sipa> applications that have JIT compiled code executed in the same process also are particularly vulnerable, but that's not the case for us either
8782020-05-28T22:22:21  <sipa> or more specifically, untrusted JIT compiled code
8792020-05-28T22:22:31  <sipa> (browser tab spying on another browser tab etc)
8802020-05-28T22:23:10  *** Pavlenex has quit IRC
8812020-05-28T22:25:37  <wumpus> yup, that's another trusted-untrusted boundary
8822020-05-28T22:27:38  *** EagleTM has joined #bitcoin-core-dev
8832020-05-28T22:40:00  *** mdunnio has quit IRC
8842020-05-28T22:45:14  *** IGHOR has quit IRC
8852020-05-28T22:46:16  <fanquake> sipa: it depends on the distribution you’re using, if the flags are on by default
8862020-05-28T22:47:00  *** IGHOR has joined #bitcoin-core-dev
8872020-05-28T22:49:33  <fanquake> If we were to upgrade to a newer Ubuntu for gitian builds, we’d end up with a few new protections turned on unless we start explicitly opting out.
8882020-05-28T22:51:08  <sipa> fanquake: ah good to know
8892020-05-28T22:51:29  <sipa> i'm on ubuntu focal, so this may have influenced my measurements
8902020-05-28T22:51:48  <fanquake> Yep. They started patching new things in from unit in 19.10 onwards
8912020-05-28T22:51:57  <fanquake> *Ubuntu
8922020-05-28T22:52:24  <fanquake> I have a PR open with some details, but haven’t gotten to any significant benchmarking
8932020-05-28T22:52:44  *** troygiorshev has joined #bitcoin-core-dev
8942020-05-28T22:53:09  <fanquake> #18921
8952020-05-28T22:53:11  <gribble> https://github.com/bitcoin/bitcoin/issues/18921 | build: add stack-clash and control-flow protection options to hardening flags by fanquake · Pull Request #18921 · bitcoin/bitcoin · GitHub
8962020-05-28T22:53:35  <fanquake> Waiting to convince jamesob to throw it into bitcoinperf
8972020-05-28T23:03:26  <luke-jr> hmm, does that suggest we ought to be enabling those things? (new Ubuntu defaults)
8982020-05-28T23:08:40  *** ghost43 has quit IRC
8992020-05-28T23:09:34  *** ghost43 has joined #bitcoin-core-dev
9002020-05-28T23:13:43  *** DeanWeen has quit IRC
9012020-05-28T23:18:54  *** promag has quit IRC
9022020-05-28T23:21:41  *** jarthur has quit IRC
9032020-05-28T23:27:10  *** Highway61 has quit IRC
9042020-05-28T23:27:20  *** justanotheruser has quit IRC
9052020-05-28T23:29:04  *** troygiorshev has quit IRC
9062020-05-28T23:41:20  *** promag has joined #bitcoin-core-dev
9072020-05-28T23:41:52  *** justanotheruser has joined #bitcoin-core-dev
9082020-05-28T23:51:42  *** shaunsun_ has quit IRC
9092020-05-28T23:53:36  *** troygiorshev has joined #bitcoin-core-dev