12020-09-10T00:00:02 *** maurits1 has quit IRC
22020-09-10T00:02:04 *** melande1 has quit IRC
32020-09-10T00:02:19 *** melande1 has joined #bitcoin-core-dev
42020-09-10T00:21:20 *** mrostecki has quit IRC
52020-09-10T00:28:01 *** melande1 has quit IRC
62020-09-10T00:28:21 *** melande1 has joined #bitcoin-core-dev
72020-09-10T00:33:05 *** arowser has quit IRC
82020-09-10T00:33:25 *** arowser has joined #bitcoin-core-dev
92020-09-10T00:48:40 *** braydonf has quit IRC
102020-09-10T00:49:05 *** braydonf has joined #bitcoin-core-dev
112020-09-10T00:55:09 *** zepheiryan has joined #bitcoin-core-dev
122020-09-10T01:00:51 *** EagleTM has joined #bitcoin-core-dev
132020-09-10T01:04:49 *** alko89 has quit IRC
142020-09-10T01:05:53 *** troygiorshev has joined #bitcoin-core-dev
152020-09-10T01:12:55 *** melande1 has quit IRC
162020-09-10T01:13:20 *** melande1 has joined #bitcoin-core-dev
172020-09-10T01:22:55 *** melande1 has quit IRC
182020-09-10T01:23:19 *** melande1 has joined #bitcoin-core-dev
192020-09-10T01:25:34 *** troygiorshev has quit IRC
202020-09-10T01:25:51 *** alko89 has joined #bitcoin-core-dev
212020-09-10T01:38:41 *** EagleTM has quit IRC
222020-09-10T01:41:20 *** justanotheruser has joined #bitcoin-core-dev
232020-09-10T01:43:49 *** mdunnio has joined #bitcoin-core-dev
242020-09-10T01:48:34 *** mdunnio has quit IRC
252020-09-10T01:49:23 *** cato_ has quit IRC
262020-09-10T01:54:46 *** cato_ has joined #bitcoin-core-dev
272020-09-10T01:58:05 *** arowser has quit IRC
282020-09-10T01:58:25 *** arowser has joined #bitcoin-core-dev
292020-09-10T02:24:56 *** melande1 has quit IRC
302020-09-10T02:25:18 *** melande1 has joined #bitcoin-core-dev
312020-09-10T02:26:21 *** melande1 has quit IRC
322020-09-10T02:26:21 *** melande2 has joined #bitcoin-core-dev
332020-09-10T02:33:59 *** proofofkeags has joined #bitcoin-core-dev
342020-09-10T02:47:05 *** arowser has quit IRC
352020-09-10T02:49:00 *** arowser has joined #bitcoin-core-dev
362020-09-10T02:54:47 *** brianhoffman has joined #bitcoin-core-dev
372020-09-10T02:58:21 *** Highway61 has quit IRC
382020-09-10T03:00:01 *** zepheiryan has quit IRC
392020-09-10T03:06:56 *** tralfaz has joined #bitcoin-core-dev
402020-09-10T03:07:09 *** davterra has quit IRC
412020-09-10T03:19:57 *** melande2 has quit IRC
422020-09-10T03:20:19 *** melande2 has joined #bitcoin-core-dev
432020-09-10T03:21:18 *** melande11 has joined #bitcoin-core-dev
442020-09-10T03:21:58 *** shoman94 has joined #bitcoin-core-dev
452020-09-10T03:23:22 *** wullon587 has joined #bitcoin-core-dev
462020-09-10T03:25:59 *** proofofkeags has quit IRC
472020-09-10T03:27:56 *** andreacab has joined #bitcoin-core-dev
482020-09-10T03:28:43 *** melande11 has quit IRC
492020-09-10T03:32:07 *** jonatack has quit IRC
502020-09-10T03:32:21 *** andreacab has quit IRC
512020-09-10T03:34:29 *** jonatack has joined #bitcoin-core-dev
522020-09-10T03:35:30 *** melande11 has joined #bitcoin-core-dev
532020-09-10T03:57:50 *** Highway61 has joined #bitcoin-core-dev
542020-09-10T04:07:56 *** melande11 has quit IRC
552020-09-10T04:08:21 *** melande11 has joined #bitcoin-core-dev
562020-09-10T04:17:05 *** arowser has quit IRC
572020-09-10T04:17:29 *** arowser has joined #bitcoin-core-dev
582020-09-10T04:21:00 *** melande11 has quit IRC
592020-09-10T04:21:25 *** melande11 has joined #bitcoin-core-dev
602020-09-10T04:28:56 <kallewoof> Signet review beg -- no more changes planned, probably RFM: https://github.com/bitcoin/bitcoin/pull/18267
612020-09-10T04:31:06 *** arowser has quit IRC
622020-09-10T04:31:30 *** arowser has joined #bitcoin-core-dev
632020-09-10T04:39:54 <phantomcircuit> sipa, 563,289,128
642020-09-10T04:40:21 <sipa> phantomcircuit: that's unpossible
652020-09-10T04:40:25 <sipa> txouts?
662020-09-10T04:40:50 <phantomcircuit> wait did i count transactions
672020-09-10T04:41:09 <sipa> i count 566823026 transactions
682020-09-10T04:41:25 <phantomcircuit> damn it
692020-09-10T04:42:06 *** arowser has quit IRC
702020-09-10T04:42:23 <phantomcircuit> sipa, yeha i counted short at 99.4% done
712020-09-10T04:42:28 <phantomcircuit> lets try that again
722020-09-10T04:42:47 *** arowser has joined #bitcoin-core-dev
732020-09-10T04:51:46 <phantomcircuit> 2020-09-10T04:49:27Z FlushStateToDisk: write coins cache to disk (72011604 coins, 9823747kB) started
742020-09-10T04:51:52 <phantomcircuit> ok lets try that in 10-20 minutes
752020-09-10T04:54:08 *** brianhoffman_ has joined #bitcoin-core-dev
762020-09-10T04:55:02 *** brianhoffman has quit IRC
772020-09-10T04:55:02 *** brianhoffman_ is now known as brianhoffman
782020-09-10T04:57:25 <phantomcircuit> only took 411.70s
792020-09-10T05:01:58 <sipa> i hope my numbers are accurated, i have a script that maintains a database with some per-block statistics
802020-09-10T05:02:03 <sipa> so i just added all the numbers in it
812020-09-10T05:08:59 *** melande11 has quit IRC
822020-09-10T05:09:21 *** melande11 has joined #bitcoin-core-dev
832020-09-10T05:13:50 *** shesek has quit IRC
842020-09-10T05:16:07 *** Mercury_Vapor has quit IRC
852020-09-10T05:24:05 *** arowser has quit IRC
862020-09-10T05:24:25 *** arowser has joined #bitcoin-core-dev
872020-09-10T05:29:40 <phantomcircuit> sipa, 1,506,642,276
882020-09-10T05:32:06 <sipa> that's more like it
892020-09-10T05:34:19 *** MrPaz has quit IRC
902020-09-10T05:38:48 <phantomcircuit> sipa, yeah so this guy has no hope https://github.com/bitcoin/bitcoin/issues/19921
912020-09-10T05:39:47 <sipa> phantomcircuit: it's not O(m*n)
922020-09-10T05:40:17 <sipa> IsMine is O(log n) in the number of keys you have, i think
932020-09-10T05:43:49 <phantomcircuit> sipa, there's a mapWallet.count, IsMine, IsFromMe, all of which will run if the transaction doesn't involve your wallet
942020-09-10T05:44:29 <sipa> phantomcircuit: yes, but they run once per transaction, not per transactions*keycount
952020-09-10T05:45:13 <sipa> only the lookups in the keystore have a time that scales with the number of keys, but it's not linear
962020-09-10T05:51:59 <phantomcircuit> sipa, right so it's O(m log n) for m transactions and n keys
972020-09-10T05:52:04 <phantomcircuit> or something close to that
982020-09-10T05:52:13 <phantomcircuit> transaction outputs not transactions
992020-09-10T05:54:01 <sipa> yes
1002020-09-10T05:54:20 <sipa> O(outputs+inputs)
1012020-09-10T05:54:30 <sipa> O((outputs+inputs)*log(keys))
1022020-09-10T06:00:01 *** shoman94 has quit IRC
1032020-09-10T06:09:37 <achow101> it'll just take a long time
1042020-09-10T06:10:07 <achow101> probably a bit faster if mapKeys was unordered map instead of map
1052020-09-10T06:11:51 <sipa> yeah
1062020-09-10T06:12:03 <sipa> and way faster if it was a map of scriptPubKeys ;)
1072020-09-10T06:12:24 <achow101> I suppose he could try #16910
1082020-09-10T06:12:33 <gribble> https://github.com/bitcoin/bitcoin/issues/16910 | wallet: reduce loading time by using unordered maps by achow101 · Pull Request #16910 · bitcoin/bitcoin · GitHub
1092020-09-10T06:12:35 <achow101> changes a bunch of things to unordered_map/unordered_set
1102020-09-10T06:17:55 *** mdunnio has joined #bitcoin-core-dev
1112020-09-10T06:21:56 *** steven1 has joined #bitcoin-core-dev
1122020-09-10T06:22:43 *** mdunnio has quit IRC
1132020-09-10T06:26:37 *** promag has joined #bitcoin-core-dev
1142020-09-10T06:36:05 *** arowser has quit IRC
1152020-09-10T06:37:27 *** promag has quit IRC
1162020-09-10T06:38:25 *** arowser has joined #bitcoin-core-dev
1172020-09-10T06:43:46 *** tralfaz has quit IRC
1182020-09-10T06:43:50 *** davterra has joined #bitcoin-core-dev
1192020-09-10T06:50:05 *** arowser has quit IRC
1202020-09-10T06:50:25 *** arowser has joined #bitcoin-core-dev
1212020-09-10T06:51:39 *** vasild has joined #bitcoin-core-dev
1222020-09-10T06:59:29 *** sdaftuar has quit IRC
1232020-09-10T06:59:58 *** sdaftuar has joined #bitcoin-core-dev
1242020-09-10T07:00:06 *** andreacab has joined #bitcoin-core-dev
1252020-09-10T07:09:03 *** tralfaz has joined #bitcoin-core-dev
1262020-09-10T07:10:01 <hebasto> who is interested in today's meeting topic suggested by jnewbery mind considering the overview gist https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34
1272020-09-10T07:10:29 *** davterra has quit IRC
1282020-09-10T07:11:15 *** marcoagner has joined #bitcoin-core-dev
1292020-09-10T07:21:06 *** arowser has quit IRC
1302020-09-10T07:21:47 *** arowser has joined #bitcoin-core-dev
1312020-09-10T07:23:05 *** arowser has quit IRC
1322020-09-10T07:23:27 *** arowser has joined #bitcoin-core-dev
1332020-09-10T07:28:02 *** jonatack has quit IRC
1342020-09-10T07:28:11 *** reallll has joined #bitcoin-core-dev
1352020-09-10T07:31:28 *** bitcoin-git has joined #bitcoin-core-dev
1362020-09-10T07:31:28 <bitcoin-git> [bitcoin] sipa opened pull request #19931: Change CSipHasher's count variable to uint8_t (master...202009_siphash_sillyness) https://github.com/bitcoin/bitcoin/pull/19931
1372020-09-10T07:31:29 *** bitcoin-git has left #bitcoin-core-dev
1382020-09-10T07:32:03 *** belcher_ has quit IRC
1392020-09-10T07:34:01 *** Guyver2 has joined #bitcoin-core-dev
1402020-09-10T07:47:23 *** Madars has quit IRC
1412020-09-10T07:47:30 *** promag has joined #bitcoin-core-dev
1422020-09-10T07:48:03 *** jb55 has quit IRC
1432020-09-10T07:48:25 *** kristapsk has quit IRC
1442020-09-10T07:48:57 *** kristapsk has joined #bitcoin-core-dev
1452020-09-10T07:51:15 *** andreacab has quit IRC
1462020-09-10T07:51:21 *** andreacab has joined #bitcoin-core-dev
1472020-09-10T07:54:35 *** Cory has quit IRC
1482020-09-10T08:00:54 *** Madars has joined #bitcoin-core-dev
1492020-09-10T08:04:05 *** arowser has quit IRC
1502020-09-10T08:04:10 *** promag_ has joined #bitcoin-core-dev
1512020-09-10T08:04:29 *** arowser has joined #bitcoin-core-dev
1522020-09-10T08:07:09 *** Pavlenex has joined #bitcoin-core-dev
1532020-09-10T08:08:53 *** promag_ has quit IRC
1542020-09-10T08:12:29 *** Cory has joined #bitcoin-core-dev
1552020-09-10T08:17:43 *** promag has quit IRC
1562020-09-10T08:19:54 *** Pavlenex has quit IRC
1572020-09-10T08:20:52 *** jb55 has joined #bitcoin-core-dev
1582020-09-10T08:21:24 *** promag has joined #bitcoin-core-dev
1592020-09-10T08:23:11 *** promag has quit IRC
1602020-09-10T08:23:37 *** andreacab has quit IRC
1612020-09-10T08:24:11 *** Madars has quit IRC
1622020-09-10T08:24:29 *** promag has joined #bitcoin-core-dev
1632020-09-10T08:24:34 *** andreacab has joined #bitcoin-core-dev
1642020-09-10T08:28:47 *** andreacab has quit IRC
1652020-09-10T08:29:48 *** andreacab has joined #bitcoin-core-dev
1662020-09-10T08:31:53 *** reallll is now known as belcher
1672020-09-10T08:33:31 *** bitcoin-git has joined #bitcoin-core-dev
1682020-09-10T08:33:31 <bitcoin-git> [bitcoin] hebasto closed pull request #19926: gui: Add Tor icon (master...200909-tor) https://github.com/bitcoin/bitcoin/pull/19926
1692020-09-10T08:33:32 *** bitcoin-git has left #bitcoin-core-dev
1702020-09-10T08:45:41 *** promag has quit IRC
1712020-09-10T08:47:10 *** Pavlenex has joined #bitcoin-core-dev
1722020-09-10T08:52:05 *** promag has joined #bitcoin-core-dev
1732020-09-10T08:52:12 *** Madars has joined #bitcoin-core-dev
1742020-09-10T08:57:20 *** jonatack has joined #bitcoin-core-dev
1752020-09-10T09:00:01 *** vincenzopalazzo has joined #bitcoin-core-dev
1762020-09-10T09:00:01 *** steven1 has quit IRC
1772020-09-10T09:04:10 *** promag has quit IRC
1782020-09-10T09:05:50 *** promag has joined #bitcoin-core-dev
1792020-09-10T09:15:02 *** promag has quit IRC
1802020-09-10T09:15:11 *** Madars has quit IRC
1812020-09-10T09:21:55 *** Avelino has joined #bitcoin-core-dev
1822020-09-10T09:27:50 *** andreacab has quit IRC
1832020-09-10T09:28:16 *** andreacab has joined #bitcoin-core-dev
1842020-09-10T09:29:30 *** andreacab has quit IRC
1852020-09-10T09:29:37 *** andreacab has joined #bitcoin-core-dev
1862020-09-10T09:34:05 *** jb55 has quit IRC
1872020-09-10T09:34:37 *** jb55 has joined #bitcoin-core-dev
1882020-09-10T09:36:24 *** Pavlenex has quit IRC
1892020-09-10T09:36:54 *** promag has joined #bitcoin-core-dev
1902020-09-10T09:37:24 *** justanotheruser has quit IRC
1912020-09-10T09:38:25 *** Pavlenex has joined #bitcoin-core-dev
1922020-09-10T09:38:31 *** Madars has joined #bitcoin-core-dev
1932020-09-10T09:42:09 *** promag has quit IRC
1942020-09-10T09:48:54 *** EagleTM has joined #bitcoin-core-dev
1952020-09-10T09:53:26 *** EagleTM has quit IRC
1962020-09-10T09:53:45 *** EagleTM has joined #bitcoin-core-dev
1972020-09-10T09:58:09 *** jonatack has quit IRC
1982020-09-10T09:58:51 *** promag has joined #bitcoin-core-dev
1992020-09-10T10:03:20 *** Madars has quit IRC
2002020-09-10T10:03:23 *** promag has quit IRC
2012020-09-10T10:05:24 *** andreacab has quit IRC
2022020-09-10T10:05:51 *** andreacab has joined #bitcoin-core-dev
2032020-09-10T10:09:17 *** mrostecki has joined #bitcoin-core-dev
2042020-09-10T10:10:20 *** andreacab has quit IRC
2052020-09-10T10:13:01 *** tralfaz has quit IRC
2062020-09-10T10:13:40 *** tralfaz has joined #bitcoin-core-dev
2072020-09-10T10:17:38 *** Bullit has quit IRC
2082020-09-10T10:18:05 *** arowser has quit IRC
2092020-09-10T10:18:11 *** Bullit has joined #bitcoin-core-dev
2102020-09-10T10:18:23 *** Tyrell41Kris has joined #bitcoin-core-dev
2112020-09-10T10:18:26 *** arowser has joined #bitcoin-core-dev
2122020-09-10T10:20:25 *** Evel-Knievel has quit IRC
2132020-09-10T10:21:01 *** Evel-Knievel has joined #bitcoin-core-dev
2142020-09-10T10:24:55 *** promag has joined #bitcoin-core-dev
2152020-09-10T10:28:05 *** arowser has quit IRC
2162020-09-10T10:28:24 *** arowser has joined #bitcoin-core-dev
2172020-09-10T10:29:35 *** promag has quit IRC
2182020-09-10T10:29:52 *** promag has joined #bitcoin-core-dev
2192020-09-10T10:32:31 *** Madars has joined #bitcoin-core-dev
2202020-09-10T10:36:26 *** promag has quit IRC
2212020-09-10T10:40:04 *** Tyrell41Kris has quit IRC
2222020-09-10T10:41:55 <jonasschnelli> #proposedmeetingtopic review the experience of 3 month bitcoin-core/gui repository
2232020-09-10T10:49:53 *** andreacab has joined #bitcoin-core-dev
2242020-09-10T10:52:35 *** Madars has quit IRC
2252020-09-10T10:54:17 *** andreacab has quit IRC
2262020-09-10T11:00:03 *** vasild has quit IRC
2272020-09-10T11:01:34 *** vasild has joined #bitcoin-core-dev
2282020-09-10T11:01:50 *** andreacab has joined #bitcoin-core-dev
2292020-09-10T11:02:25 *** Jackielove4u has quit IRC
2302020-09-10T11:11:31 *** ExEric3 has quit IRC
2312020-09-10T11:12:18 *** ExEric3 has joined #bitcoin-core-dev
2322020-09-10T11:14:50 *** Madars has joined #bitcoin-core-dev
2332020-09-10T11:31:26 *** paz_ has joined #bitcoin-core-dev
2342020-09-10T11:31:49 *** paz_ is now known as Guest48339
2352020-09-10T11:35:05 *** Madars has quit IRC
2362020-09-10T11:38:20 *** promag has joined #bitcoin-core-dev
2372020-09-10T11:42:04 *** andreacab has quit IRC
2382020-09-10T11:42:48 *** promag has quit IRC
2392020-09-10T11:46:46 *** andreacab has joined #bitcoin-core-dev
2402020-09-10T11:57:23 *** promag has joined #bitcoin-core-dev
2412020-09-10T11:57:27 *** Avelino has quit IRC
2422020-09-10T12:01:43 *** promag has quit IRC
2432020-09-10T12:02:09 *** Madars has joined #bitcoin-core-dev
2442020-09-10T12:03:37 *** Mercury_Vapor has joined #bitcoin-core-dev
2452020-09-10T12:05:47 *** alko89 has quit IRC
2462020-09-10T12:05:58 *** alko89 has joined #bitcoin-core-dev
2472020-09-10T12:15:47 *** andreacab has quit IRC
2482020-09-10T12:16:14 *** andreacab has joined #bitcoin-core-dev
2492020-09-10T12:18:16 *** provoostenator has joined #bitcoin-core-dev
2502020-09-10T12:20:30 *** andreacab has quit IRC
2512020-09-10T12:20:44 *** wolfy13391 has joined #bitcoin-core-dev
2522020-09-10T12:24:11 *** Madars has quit IRC
2532020-09-10T12:27:31 *** Aaronvan_ has joined #bitcoin-core-dev
2542020-09-10T12:29:33 *** AaronvanW has quit IRC
2552020-09-10T12:33:10 *** EagleTM has quit IRC
2562020-09-10T12:39:28 *** Guyver2 has quit IRC
2572020-09-10T12:43:02 *** jonatack has joined #bitcoin-core-dev
2582020-09-10T12:47:46 *** Emcy_ has joined #bitcoin-core-dev
2592020-09-10T12:47:47 *** gzhao408 has joined #bitcoin-core-dev
2602020-09-10T12:47:48 *** Emcy has quit IRC
2612020-09-10T13:02:30 *** EagleTM has joined #bitcoin-core-dev
2622020-09-10T13:06:05 *** arowser has quit IRC
2632020-09-10T13:06:46 *** arowser has joined #bitcoin-core-dev
2642020-09-10T13:08:06 *** arowser has quit IRC
2652020-09-10T13:08:26 *** arowser has joined #bitcoin-core-dev
2662020-09-10T13:09:06 *** arowser has quit IRC
2672020-09-10T13:09:26 *** arowser has joined #bitcoin-core-dev
2682020-09-10T13:10:05 *** arowser has quit IRC
2692020-09-10T13:10:48 *** arowser has joined #bitcoin-core-dev
2702020-09-10T13:11:02 *** Madars has joined #bitcoin-core-dev
2712020-09-10T13:11:05 *** arowser has quit IRC
2722020-09-10T13:11:26 *** arowser has joined #bitcoin-core-dev
2732020-09-10T13:12:05 *** arowser has quit IRC
2742020-09-10T13:12:25 *** arowser has joined #bitcoin-core-dev
2752020-09-10T13:24:04 *** arowser has quit IRC
2762020-09-10T13:24:25 *** arowser has joined #bitcoin-core-dev
2772020-09-10T13:36:50 *** Madars has quit IRC
2782020-09-10T13:37:22 *** jonatack has quit IRC
2792020-09-10T13:41:45 *** promag has joined #bitcoin-core-dev
2802020-09-10T13:58:21 *** promag has quit IRC
2812020-09-10T14:00:43 *** mdunnio has joined #bitcoin-core-dev
2822020-09-10T14:02:15 *** jonatack has joined #bitcoin-core-dev
2832020-09-10T14:06:05 *** arowser has quit IRC
2842020-09-10T14:06:27 *** arowser has joined #bitcoin-core-dev
2852020-09-10T14:06:47 *** proofofkeags has joined #bitcoin-core-dev
2862020-09-10T14:13:21 *** mdunnio has quit IRC
2872020-09-10T14:13:36 *** mdunnio has joined #bitcoin-core-dev
2882020-09-10T14:20:54 *** shaunsun has joined #bitcoin-core-dev
2892020-09-10T14:26:14 *** opsec_x122 has joined #bitcoin-core-dev
2902020-09-10T14:29:05 *** jeremyrubin has quit IRC
2912020-09-10T14:29:18 *** jeremyrubin has joined #bitcoin-core-dev
2922020-09-10T14:29:38 *** opsec_x12 has quit IRC
2932020-09-10T14:30:00 *** bitcoin-git has joined #bitcoin-core-dev
2942020-09-10T14:30:00 <bitcoin-git> [bitcoin] Saibato opened pull request #19933: wallet: bugfix; if datadir has a trailing '/' listwalletdir would strip lead char of walletname (master...wallet-fix-missing-chars-boost-1.47) https://github.com/bitcoin/bitcoin/pull/19933
2952020-09-10T14:30:02 *** bitcoin-git has left #bitcoin-core-dev
2962020-09-10T14:31:23 *** sdaftuar has quit IRC
2972020-09-10T14:31:24 *** afk11 has quit IRC
2982020-09-10T14:33:46 *** sdaftuar has joined #bitcoin-core-dev
2992020-09-10T14:33:53 *** afk11 has joined #bitcoin-core-dev
3002020-09-10T14:35:06 *** Madars has joined #bitcoin-core-dev
3012020-09-10T14:36:34 *** promag has joined #bitcoin-core-dev
3022020-09-10T14:38:49 *** bitcoin-git has joined #bitcoin-core-dev
3032020-09-10T14:38:49 <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/564e1ab0f3dc...a47e5964861d
3042020-09-10T14:38:50 <bitcoin-git> bitcoin/master 2ac8bf9 Pieter Wuille: Implement keccak-f[1600] and SHA3-256
3052020-09-10T14:38:50 <bitcoin-git> bitcoin/master 3f01ddb Pieter Wuille: Add SHA3 benchmark
3062020-09-10T14:38:51 <bitcoin-git> bitcoin/master ab654c7 Pieter Wuille: Unroll Keccak-f implementation
3072020-09-10T14:38:59 *** bitcoin-git has left #bitcoin-core-dev
3082020-09-10T14:39:14 *** bitcoin-git has joined #bitcoin-core-dev
3092020-09-10T14:39:14 <bitcoin-git> [bitcoin] laanwj merged pull request #19841: Implement Keccak and SHA3_256 (master...202008_sha3) https://github.com/bitcoin/bitcoin/pull/19841
3102020-09-10T14:39:15 *** bitcoin-git has left #bitcoin-core-dev
3112020-09-10T14:41:00 *** promag has quit IRC
3122020-09-10T14:43:43 *** opsec_x122 is now known as opsec_x12
3132020-09-10T14:46:30 *** luke-jr has quit IRC
3142020-09-10T14:49:34 *** luke-jr has joined #bitcoin-core-dev
3152020-09-10T14:51:19 *** promag has joined #bitcoin-core-dev
3162020-09-10T14:51:37 *** promag has joined #bitcoin-core-dev
3172020-09-10T14:53:01 *** Dean_Guss has quit IRC
3182020-09-10T14:53:29 *** Dean_Guss has joined #bitcoin-core-dev
3192020-09-10T14:57:14 *** gleb has quit IRC
3202020-09-10T14:57:28 *** bitcoin-git has joined #bitcoin-core-dev
3212020-09-10T14:57:28 <bitcoin-git> [bitcoin] practicalswift opened pull request #19934: tests: Add fuzzing harness for Keccak and SHA3_256 (master...fuzzers-keccak-and-sha3_256) https://github.com/bitcoin/bitcoin/pull/19934
3222020-09-10T14:57:29 *** bitcoin-git has left #bitcoin-core-dev
3232020-09-10T15:00:02 *** wolfy13391 has quit IRC
3242020-09-10T15:02:44 *** Guyver2 has joined #bitcoin-core-dev
3252020-09-10T15:04:27 *** andreacab has joined #bitcoin-core-dev
3262020-09-10T15:06:12 *** promag has quit IRC
3272020-09-10T15:07:56 *** promag has joined #bitcoin-core-dev
3282020-09-10T15:11:49 *** Madars has quit IRC
3292020-09-10T15:16:59 *** satoshi has joined #bitcoin-core-dev
3302020-09-10T15:20:02 *** andreacab has quit IRC
3312020-09-10T15:22:23 *** chrippa has joined #bitcoin-core-dev
3322020-09-10T15:30:43 *** Guyver2_ has joined #bitcoin-core-dev
3332020-09-10T15:31:48 *** andreacab has joined #bitcoin-core-dev
3342020-09-10T15:32:44 *** Guyver2 has quit IRC
3352020-09-10T15:33:58 *** bitcoin-git has joined #bitcoin-core-dev
3362020-09-10T15:33:58 <bitcoin-git> [bitcoin] achow101 opened pull request #19935: Move SaltedHashers to separate file and add some new ones (master...mv-saltedhash) https://github.com/bitcoin/bitcoin/pull/19935
3372020-09-10T15:33:59 *** bitcoin-git has left #bitcoin-core-dev
3382020-09-10T15:37:06 *** troygiorshev has joined #bitcoin-core-dev
3392020-09-10T15:38:27 *** troygiorshev has quit IRC
3402020-09-10T15:39:05 *** IGHOR has quit IRC
3412020-09-10T15:43:22 *** IGHOR has joined #bitcoin-core-dev
3422020-09-10T15:46:20 *** afk11 has quit IRC
3432020-09-10T15:46:43 *** afk11 has joined #bitcoin-core-dev
3442020-09-10T15:50:33 *** Talkless has joined #bitcoin-core-dev
3452020-09-10T16:10:21 *** Madars has joined #bitcoin-core-dev
3462020-09-10T16:12:50 *** promag has quit IRC
3472020-09-10T16:32:05 *** arowser has quit IRC
3482020-09-10T16:32:26 *** arowser has joined #bitcoin-core-dev
3492020-09-10T16:34:41 *** Madars has quit IRC
3502020-09-10T16:37:02 *** Emcy_ has quit IRC
3512020-09-10T16:38:26 *** Emcy has joined #bitcoin-core-dev
3522020-09-10T16:42:43 *** afk11 has quit IRC
3532020-09-10T16:43:57 *** afk11 has joined #bitcoin-core-dev
3542020-09-10T16:47:01 *** MrPaz has joined #bitcoin-core-dev
3552020-09-10T16:47:16 *** Guest48339 has quit IRC
3562020-09-10T16:48:29 *** promag has joined #bitcoin-core-dev
3572020-09-10T16:49:09 *** MrPaz has quit IRC
3582020-09-10T16:49:32 *** MrPaz has joined #bitcoin-core-dev
3592020-09-10T16:50:05 *** kristapsk has joined #bitcoin-core-dev
3602020-09-10T16:53:08 *** justanotheruser has joined #bitcoin-core-dev
3612020-09-10T16:53:23 *** mrostecki has quit IRC
3622020-09-10T16:53:40 *** justtestingthiso has joined #bitcoin-core-dev
3632020-09-10T16:54:06 *** mrostecki has joined #bitcoin-core-dev
3642020-09-10T16:56:02 *** promag has quit IRC
3652020-09-10T16:59:17 *** promag_ has joined #bitcoin-core-dev
3662020-09-10T17:03:32 *** Jackielove4u has joined #bitcoin-core-dev
3672020-09-10T17:09:16 *** justtestingthiso has left #bitcoin-core-dev
3682020-09-10T17:10:19 *** robertnnms has joined #bitcoin-core-dev
3692020-09-10T17:12:12 *** robertnnms has left #bitcoin-core-dev
3702020-09-10T17:13:10 *** robertnnms has joined #bitcoin-core-dev
3712020-09-10T17:13:47 <robertnnms> Hi,I need to do advanced testing on testnet, but I would need between 10-15 BTC, could someone send me to the following address: tb1qs25dr4e8k29rwclxvnxedfdtprh5e89jtp5wleMany thanks
3722020-09-10T17:14:06 *** satoshi has joined #bitcoin-core-dev
3732020-09-10T17:14:33 *** satoshi has quit IRC
3742020-09-10T17:14:39 <dongcarl> Anyone know what the `UnloadBlockIndex` call here does in the context of initialization? https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L1562
3752020-09-10T17:14:51 <dongcarl> First introduced in: https://github.com/bitcoin/bitcoin/commit/f7f3a96b74bb795d6e184a628adce21c744d234f#diff-c865a8939105e6350a50af02766291b7R805
3762020-09-10T17:14:56 *** Madars has joined #bitcoin-core-dev
3772020-09-10T17:17:19 *** Talkless has quit IRC
3782020-09-10T17:17:40 *** Talkless has joined #bitcoin-core-dev
3792020-09-10T17:20:05 *** arowser has quit IRC
3802020-09-10T17:20:47 *** arowser has joined #bitcoin-core-dev
3812020-09-10T17:24:50 *** promag has joined #bitcoin-core-dev
3822020-09-10T17:25:00 *** promag_ has quit IRC
3832020-09-10T17:26:23 *** IGHOR has quit IRC
3842020-09-10T17:27:33 *** IGHOR has joined #bitcoin-core-dev
3852020-09-10T17:35:43 *** robertnnms has quit IRC
3862020-09-10T17:36:27 *** promag has quit IRC
3872020-09-10T17:36:47 *** promag has joined #bitcoin-core-dev
3882020-09-10T17:36:59 *** Madars has quit IRC
3892020-09-10T17:37:03 *** IGHOR has quit IRC
3902020-09-10T17:38:12 *** IGHOR has joined #bitcoin-core-dev
3912020-09-10T17:40:01 *** Pavlenex has quit IRC
3922020-09-10T17:41:59 *** Pavlenex has joined #bitcoin-core-dev
3932020-09-10T17:52:10 *** promag has quit IRC
3942020-09-10T17:53:29 *** Cassidy67Schambe has joined #bitcoin-core-dev
3952020-09-10T17:53:31 *** promag has joined #bitcoin-core-dev
3962020-09-10T17:58:28 *** Cassidy67Schambe has quit IRC
3972020-09-10T18:00:02 *** chrippa has quit IRC
3982020-09-10T18:02:42 <wumpus> dongcarl: it's in a retry loop, I think it's there in case a previous block index load only succeeds partially?
3992020-09-10T18:03:04 <sipa> yep
4002020-09-10T18:05:33 <dongcarl> I see, that makes sense...
4012020-09-10T18:10:21 <phantomcircuit> achow101, the only real solution for rescanning with a huge number of keys is to use the block filter indexes
4022020-09-10T18:10:23 <phantomcircuit> it takes absolutely ages otherwise
4032020-09-10T18:11:10 *** Madars has joined #bitcoin-core-dev
4042020-09-10T18:15:28 *** promag has quit IRC
4052020-09-10T18:17:30 *** Guyver2_ has quit IRC
4062020-09-10T18:18:57 *** Guyver2 has joined #bitcoin-core-dev
4072020-09-10T18:21:44 *** popey1 has joined #bitcoin-core-dev
4082020-09-10T18:23:32 <phantomcircuit> sipa, lol he closed the issue, what a child
4092020-09-10T18:23:41 <phantomcircuit> still wondering how he ended up with 150m keys
4102020-09-10T18:24:54 <sipa> i assume he generated them using a dictionary
4112020-09-10T18:30:57 <jonasschnelli> a cracker!
4122020-09-10T18:31:27 <jonasschnelli> Why he is not using a full indexer like electrs or so is unclear to me.
4132020-09-10T18:31:51 <wumpus> if it's a criminal even more reason to not give them ideas
4142020-09-10T18:32:32 <jonasschnelli> maybe he lost some of his mnemonic words...
4152020-09-10T18:33:14 <jonasschnelli> also... i would rather scan agains the UTXO set in that case (and not against all blocks)
4162020-09-10T18:33:35 <yanmaani> It's not a very competent attack that's for suer
4172020-09-10T18:37:01 *** Highway62 has joined #bitcoin-core-dev
4182020-09-10T18:37:36 *** Highway61 has quit IRC
4192020-09-10T18:37:36 *** Highway62 is now known as Highway61
4202020-09-10T18:38:07 *** justanotheruser has quit IRC
4212020-09-10T18:38:34 *** Madars has quit IRC
4222020-09-10T18:47:08 *** gzhao408 has quit IRC
4232020-09-10T18:58:50 *** lightlike has joined #bitcoin-core-dev
4242020-09-10T19:00:25 <wumpus> #startmeeting
4252020-09-10T19:00:25 <lightningbot> Meeting started Thu Sep 10 19:00:25 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4262020-09-10T19:00:25 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4272020-09-10T19:00:30 <kanzure> hi
4282020-09-10T19:00:31 <achow101> hi
4292020-09-10T19:00:33 <jonasschnelli> hi
4302020-09-10T19:00:35 <hebasto> hi
4312020-09-10T19:00:36 <fjahr> hi
4322020-09-10T19:00:44 <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
4332020-09-10T19:00:47 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
4342020-09-10T19:01:01 <wumpus> two proposed meeting topics for today
4352020-09-10T19:01:02 <vasild> hi
4362020-09-10T19:01:06 <wumpus> strategies for removing recursive locking in the mempool (jnewbery), review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
4372020-09-10T19:01:06 <meshcollider> hi
4382020-09-10T19:01:23 <wumpus> any last minute topic proposals?
4392020-09-10T19:01:23 <jonatack> hi
4402020-09-10T19:02:36 <wumpus> #topic High priority for review
4412020-09-10T19:03:07 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 11 blockers, 1 bugfix, 2 chasins concept ACK
4422020-09-10T19:03:16 *** rorp has joined #bitcoin-core-dev
4432020-09-10T19:03:24 <jonatack> #19845?
4442020-09-10T19:03:37 <gribble> https://github.com/bitcoin/bitcoin/issues/19845 | net: CNetAddr: add support to (un)serialize as ADDRv2 by vasild · Pull Request #19845 · bitcoin/bitcoin · GitHub
4452020-09-10T19:04:17 <meshcollider> Actually 10 now :) one was merged and hadn't been removed
4462020-09-10T19:04:27 <jnewbery> hi
4472020-09-10T19:04:48 <wumpus> jonatack: added
4482020-09-10T19:04:53 *** promag has joined #bitcoin-core-dev
4492020-09-10T19:05:06 <meshcollider> #16378 pls
4502020-09-10T19:05:10 <gribble> https://github.com/bitcoin/bitcoin/issues/16378 | The ultimate send RPC by Sjors · Pull Request #16378 · bitcoin/bitcoin · GitHub
4512020-09-10T19:05:52 <achow101> #19077 please
4522020-09-10T19:06:00 <gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
4532020-09-10T19:06:12 <promag> #19033 for hp, ty
4542020-09-10T19:06:15 <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
4552020-09-10T19:06:21 <phantomcircuit> hi
4562020-09-10T19:06:52 * luke-jr pokes gribble
4572020-09-10T19:07:22 <wumpus> meshcollider, achow101 added
4582020-09-10T19:07:27 <wumpus> promag: already on there, right?
4592020-09-10T19:08:01 <jeremyrubin> i think so
4602020-09-10T19:08:58 <promag> indeed, I guess I have to name it "http: blocklist work queue..."
4612020-09-10T19:09:01 *** luke-jr has quit IRC
4622020-09-10T19:09:04 <wumpus> unless someone else just added it, but I vaguely remember it was already there
4632020-09-10T19:09:43 <wumpus> #topic Strategies for removing recursive locking in the mempool (jnewbery)
4642020-09-10T19:09:51 <wumpus> (https://github.com/bitcoin/bitcoin/pull/19872#issuecomment-688852261)
4652020-09-10T19:09:56 *** luke-jr has joined #bitcoin-core-dev
4662020-09-10T19:09:58 <jnewbery> Thanks wumpus
4672020-09-10T19:10:16 <jnewbery> gist here: https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34
4682020-09-10T19:10:53 <jnewbery> summary: RecusiveMutex is generally considered bad, and avoided if possible. It'd be nice to change the mempool's mutex from recursive to non-recursive
4692020-09-10T19:10:58 *** Talkless has quit IRC
4702020-09-10T19:11:00 <wumpus> I think getting rid of the recursive locks is good, though, it seems changes are becoming increasingly risky
4712020-09-10T19:11:07 <wumpus> and involved
4722020-09-10T19:11:22 <jnewbery> There are different ways to do this, and hebasto would like some input on which way is preferred
4732020-09-10T19:11:23 <wumpus> we had all the low-hanging fruit I guess
4742020-09-10T19:12:00 <jnewbery> wumpus: i don't think so. I think there's a lot more low-hanging fruit (although cs_mempool isn't very low hanging)
4752020-09-10T19:12:33 <hebasto> tracking issue for all recursive mutexes #19303
4762020-09-10T19:12:35 <gribble> https://github.com/bitcoin/bitcoin/issues/19303 | Replace all of the RecursiveMutex instances with the Mutex ones · Issue #19303 · bitcoin/bitcoin · GitHub
4772020-09-10T19:12:40 <jeremyrubin> Probably makes more sense to have the locking external to the functions
4782020-09-10T19:12:55 <jeremyrubin> More general to e.g., calling a function in a for loop
4792020-09-10T19:13:01 <jnewbery> Two possible ways are making a lot more of the mempool functions require the lock, and make locking external to the mempool
4802020-09-10T19:13:03 <wumpus> "... two functions could be used - one that locks and another that does not..." yes, that's the common solution
4812020-09-10T19:13:26 <jnewbery> and the other way is having two versions of the function - one which requires the lock and one which takes the lock
4822020-09-10T19:13:31 <jnewbery> wumpus: right
4832020-09-10T19:13:32 <wumpus> moving locking external has its own risks
4842020-09-10T19:13:51 <hebasto> what risk?
4852020-09-10T19:13:52 <jeremyrubin> wumpus: if we use the clang safety annotations it's lesser, right?
4862020-09-10T19:13:55 <wumpus> having separate private "without lock" avoids that
4872020-09-10T19:13:57 <jnewbery> wumpus: I agree. Best to keep locking internal wherever possible
4882020-09-10T19:14:24 <vasild> "the locking mechanism used by a thread-safe class is part of its internal implementation" (from https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34#gistcomment-3448023)
4892020-09-10T19:14:32 * luke-jr stabs ISP
4902020-09-10T19:14:36 <sipa> ideally, locks are internal
4912020-09-10T19:14:37 <wumpus> hebasto: well, it goes against, the principle of encapsulation, knowledge of how to remove locks moves to outside the code
4922020-09-10T19:15:06 <wumpus> hebasto: at the least it makes reasoning more difficult
4932020-09-10T19:15:14 <hebasto> wumpus: agree
4942020-09-10T19:15:25 <sipa> if a lock is internal to a class, and the class never invokes a callback passed down from elsewhere while holding that lock, it even guarantees no deadlocks
4952020-09-10T19:15:35 <wumpus> lock annotations are not a replacement for that
4962020-09-10T19:16:05 *** rorp has quit IRC
4972020-09-10T19:16:30 <jnewbery> if locks can't always be internal, then making two versions of the public interface function makes it explicit where the function is called with the lock held and without.
4982020-09-10T19:16:49 <sipa> jnewbery: that's what CAddrMan does
4992020-09-10T19:16:59 <sipa> but i don't see how one conflicts with the other
5002020-09-10T19:17:04 <jeremyrubin> What about a type-safe (using newtype) pass lock guard in as arugment?
5012020-09-10T19:17:14 <jeremyrubin> That would have both safety properties
5022020-09-10T19:17:20 <sipa> jeremyrubin: it works, but imho it still reeks of bad design
5032020-09-10T19:17:28 <jeremyrubin> as there would only be one way to get a satisfying lock
5042020-09-10T19:17:33 <wumpus> I don't really like that, I hope that can be avoided
5052020-09-10T19:17:34 <promag> and I'd like to discuss for() { LOCK(cs); } VS { LOCK() for() {} }
5062020-09-10T19:18:11 <hebasto> how to name this two functions? some kind of suffix to distinguish them?
5072020-09-10T19:18:12 <jnewbery> sipa: I'm not saying they do. Ideally, all locks are internal. If they can't be and sometimes need to be held by the caller, make it explicit where that is by using Mutex and having two versions of public functions where needed.
5082020-09-10T19:18:20 <aj> promag: with or without performance benchmarks?
5092020-09-10T19:18:29 <wumpus> promag: well that depends on the granularity of the work, so locking overhad versus the loop body, and whether it's undesirable to hold the lock for long
5102020-09-10T19:18:31 <sipa> promag: grabbing an uncontended lock is ~100 cpu cycles
5112020-09-10T19:18:46 <jeremyrubin> hebasto: I'd do a type tag argument maybe; like atmoic primitives.
5122020-09-10T19:19:09 <jeremyrubin> but maybe that's overkill
5132020-09-10T19:19:21 *** molz_ has joined #bitcoin-core-dev
5142020-09-10T19:19:25 <sipa> jnewbery: sorry, i misread what you suggested
5152020-09-10T19:20:00 <aj> jeremyrubin: void foo(int x); void foo(int x, LockAlreadyHeld h); foo(3, LockAlreadyHeld()); // ?
5162020-09-10T19:20:21 <wumpus> I'm starting to understand Marcofalke's point now--this is a lot of work, conflicts with other changes, while we don't have a direct problem with RecursiveMutex
5172020-09-10T19:20:23 <aj> jeremyrubin: LockAlreadyHeld(cs_main); ?
5182020-09-10T19:20:26 <jeremyrubin> aj: Uh that can work yeah
5192020-09-10T19:20:28 <vasild> promag: I would say if the current code does one of that, we better have some proof that changing it is for the better.
5202020-09-10T19:20:39 <sdaftuar> wumpus: that is my gut reaction as well
5212020-09-10T19:21:11 <promag> aj: in simple cases not really
5222020-09-10T19:21:26 <sdaftuar> it would be nice to motivate this change with some new behavior we wish to implement, that woudl benefit from it?
5232020-09-10T19:21:30 <wumpus> if it helps to have a non-recursive mutex for future mempool changes it makes sense to do it, of course, but this seems a lot of design work for a pure refactor
5242020-09-10T19:21:34 <wumpus> sdaftuar: +1
5252020-09-10T19:21:41 <jeremyrubin> overall, same. It works as is.
5262020-09-10T19:22:14 *** mol_ has quit IRC
5272020-09-10T19:22:20 <luke-jr> I suspect it actually might make future changes harder :x
5282020-09-10T19:22:39 <sipa> luke-jr: depends on how it's done, i think
5292020-09-10T19:22:48 <jeremyrubin> I think that's the motivation; if future changes are leaning more on the recursive mutexing we don't want to make them that way
5302020-09-10T19:22:51 <sipa> really usually cleaning up locking means cleaning up the boundary between interfaces
5312020-09-10T19:23:01 <sipa> and if that's a side effect, it may definitely make things easier
5322020-09-10T19:23:04 <promag> sipa: I'm taking about cs_main
5332020-09-10T19:23:05 <jnewbery> sipa: +1
5342020-09-10T19:23:10 <wumpus> sipa: yes, if it can make that clearer it's a good thing
5352020-09-10T19:23:10 <promag> wumpus: agree
5362020-09-10T19:23:14 <jnewbery> cs_main is something else entirely
5372020-09-10T19:23:30 <sipa> just doing a dumb "whatever necessary to avoid recursive locking" is unlikely to be beneficial
5382020-09-10T19:23:37 <wumpus> agree
5392020-09-10T19:23:53 *** Pavlenex has quit IRC
5402020-09-10T19:24:14 <promag> vasild: agree
5412020-09-10T19:24:26 <sipa> but it's probably hard to speak very generically here
5422020-09-10T19:24:43 <jnewbery> I think adding a lock-not-held version of all public functions which may or may not hold a lock is a pretty trivial change
5432020-09-10T19:25:16 <promag> i'm meh with that approach
5442020-09-10T19:25:19 <jeremyrubin> It's kinda annoying for other patches if you have to change 2 func signatures
5452020-09-10T19:25:35 <wumpus> jnewbery: at least that can be done virtually mechanically which makes it easier to review
5462020-09-10T19:25:36 <jnewbery> I think changing the function to assert the lock is held and then adding locks outside the class _isn't_ a good change
5472020-09-10T19:25:53 <vasild> funcUnprotected() { do stuff; }; func() { LOCK(); funcUnprotected(); }
5482020-09-10T19:25:54 <sipa> jnewbery: that does not seem crazy, but it's easier to judge with code
5492020-09-10T19:26:11 <wumpus> jnewbery: +1
5502020-09-10T19:26:18 <sdaftuar> i'm a bit confused -- would some of those functions not be used?
5512020-09-10T19:26:30 <promag> jnewbery: IMO it's a good change if it comes with a follow up refactor
5522020-09-10T19:26:40 <luke-jr> I don't see what's wrong with func() that locks if necessary, but also works inside an external lock :x
5532020-09-10T19:26:55 <jnewbery> sdaftuar: you'd only add new functions where it may or may not already hold the lock
5542020-09-10T19:27:20 <jeremyrubin> luke-jr: I think that's basically a recursive lock
5552020-09-10T19:27:25 <sipa> luke-jr: it's a very abstract objection, but to me it is: code should be written to work inside our outside the private parts of a class that need locking
5562020-09-10T19:27:34 <vasild> luke-jr: that's like re-implementing recursive mutex
5572020-09-10T19:27:35 <jeremyrubin> the difference being maybe you can assert if you know you have lock already or not
5582020-09-10T19:27:53 <luke-jr> sipa: this does..?
5592020-09-10T19:27:55 <sipa> luke-jr: it's just hard to reason about the interface if you have code that works in both
5602020-09-10T19:28:10 <wumpus> hand rolling a recursive-ish mutex sounds even worse than simply using one
5612020-09-10T19:28:17 <sipa> please no
5622020-09-10T19:28:22 <nehan> the argument in https://gist.github.com/hebasto/072ad3a9370641b035a36d08607a3d34 for why RecursiveMutex is bad indicates why it's bad to use RecursiveMutex in the first place (it is a symptom of an underlying problem). i do not see how it explains the benefit of removing RecursiveMutex without addressing the underlying problem.
5632020-09-10T19:28:38 *** Highway61 has quit IRC
5642020-09-10T19:28:38 <sipa> nehan: +1
5652020-09-10T19:28:41 <nehan> which it sounds like what this dual-function thing is doing
5662020-09-10T19:28:45 *** Highway62 has joined #bitcoin-core-dev
5672020-09-10T19:28:58 <sipa> nehan: i think the dual function makes the interface layer explicit
5682020-09-10T19:29:44 <nehan> so the benefit of it is making a small (perhaps important) step towards making the interface more clear?
5692020-09-10T19:29:48 <luke-jr> my point wasn't to reinvent RM, but that RM has a use :p
5702020-09-10T19:29:52 <jnewbery> and by making it explicit, brings to attention what the underlying problem may be
5712020-09-10T19:29:58 <sipa> nehan: right, it makes it obvious where the problem is
5722020-09-10T19:30:02 <sipa> it doesn't fix it
5732020-09-10T19:30:06 <wumpus> nehan: yes, the general arguments against recursive mutex described there definitely make sense
5742020-09-10T19:30:08 <sdaftuar> so i think the right next step would be to precisely define what the interface ought ot be
5752020-09-10T19:30:17 <sdaftuar> and then we can work towards that
5762020-09-10T19:30:18 <jeremyrubin> It sounds like it might be worth to prepare this PR and not merge it
5772020-09-10T19:30:34 <jeremyrubin> Because if it indentifies what the problem is, then we can see if a fix can be built on it
5782020-09-10T19:30:39 <sdaftuar> refactoring without a design in mind seems bad to me
5792020-09-10T19:31:02 <jnewbery> sometimes it's not a problem to have a function that can be called with or without a lock. Sometimes you want to carry out multiple operations on an object atomically. That's not a problem, but it's always better to be explicit about what you're doing
5802020-09-10T19:31:06 *** Highway62 is now known as Highway61
5812020-09-10T19:31:37 *** justanotheruser has joined #bitcoin-core-dev
5822020-09-10T19:32:18 *** bitcoin-git has joined #bitcoin-core-dev
5832020-09-10T19:32:18 <bitcoin-git> [bitcoin] instagibbs opened pull request #19936: Test: batch rpc with params (master...batch_param) https://github.com/bitcoin/bitcoin/pull/19936
5842020-09-10T19:32:19 *** bitcoin-git has left #bitcoin-core-dev
5852020-09-10T19:33:14 <promag> sipa: WITH_LOCK(..., ...) is already an indicator
5862020-09-10T19:33:25 <jnewbery> hebasto: did you have anything else that you wanted input on?
5872020-09-10T19:33:33 <vasild> I think we can/should make mempool.cs mutex private
5882020-09-10T19:33:51 <jnewbery> vasild: that's a lot of work
5892020-09-10T19:34:00 <jnewbery> and might not even be desirable
5902020-09-10T19:34:02 <hebasto> jnewbery: it seems all discussed. what is consensus?
5912020-09-10T19:34:21 <promag> vasild: lots of refactors right?
5922020-09-10T19:34:21 *** Highway62 has joined #bitcoin-core-dev
5932020-09-10T19:34:24 <vasild> IMO amount of work would be comparable to making it non-recursive
5942020-09-10T19:35:10 <jnewbery> vasild: not even close, I don't think. There are lots of places where we make multiple calls to the mempool atomically. Those would all need to be changed into higher-level interfaces to the mempool
5952020-09-10T19:35:12 <wumpus> vasild: at least that'd remove the problem of public functions needing the lock held
5962020-09-10T19:35:25 *** Highway61 has quit IRC
5972020-09-10T19:35:25 *** Highway62 is now known as Highway61
5982020-09-10T19:35:28 <wumpus> but yes, it's also much more work
5992020-09-10T19:35:54 <vasild> ok, my assessment could be wrong
6002020-09-10T19:35:54 *** sr_gi has quit IRC
6012020-09-10T19:36:10 <jeremyrubin> wild idea: mempool via message passing only?
6022020-09-10T19:36:12 *** sr_gi has joined #bitcoin-core-dev
6032020-09-10T19:36:24 <jnewbery> vasild: eg all of this would need to become a single call to the mempool: https://github.com/bitcoin/bitcoin/blob/564e1ab0f3dc573bd3ea60a80f6649c361243df9/src/rpc/blockchain.cpp#L1406-L1421
6042020-09-10T19:36:25 <jeremyrubin> Might be good as there are some proposals to make the mempool a separate entity
6052020-09-10T19:36:44 <jeremyrubin> and message passing based would cleanly separate internal details
6062020-09-10T19:37:01 <hebasto> vasild: that is possible
6072020-09-10T19:37:16 <vasild> jnewbery: yes, I looked into that, it would be one call that returns a struct holding all the data, not a big deal
6082020-09-10T19:38:02 *** Madars has joined #bitcoin-core-dev
6092020-09-10T19:38:14 <jonatack> i like sdaftuar's suggestion that it be motivated by new behavior or a clear idea of the desired design/interface
6102020-09-10T19:38:27 <jnewbery> vasild: maybe. It just feels like a much bigger change. If you had a branch that moved the lock to be totally internal, I'd be very interested to see it
6112020-09-10T19:38:40 <vasild> mempool.AtomicallyGiveMeYourStats(&pool_stats); ;-)
6122020-09-10T19:39:00 <vasild> jnewbery: no, I don't have
6132020-09-10T19:39:15 <aj> time for the gui repo topic?
6142020-09-10T19:39:24 <jeremyrubin> vasild: a mempool interior thread/workqueue with condvar for wake on return could implement that API :p
6152020-09-10T19:39:25 <wumpus> I guess it would be good to see an example of the various proposals and maybe re-discuss next week
6162020-09-10T19:39:46 <hebasto> wumpus: +1
6172020-09-10T19:39:51 <wumpus> if this is all worth it at all
6182020-09-10T19:40:03 <wumpus> maybe we're creaeting a problem where there's none
6192020-09-10T19:40:27 <wumpus> #topic Review the experience of 3 month bitcoin-core/gui repository (jonasschnelli)
6202020-09-10T19:40:39 <sdaftuar> i would reiterate that a design document for how the mempool would ideally interact with the rest of our software would be very helpful for evaulating any proposals
6212020-09-10T19:40:48 <jonasschnelli> I'd like to collect feedback on how well the separation of the GUI repository has been received.
6222020-09-10T19:41:16 <jonasschnelli> my feedback: it's seems still unclear how we merge things back to the main repository and if that has been documented.
6232020-09-10T19:41:23 <wumpus> yes, what's the plan for merging back the GUI changes?
6242020-09-10T19:41:32 <jonasschnelli> on top, the mix of PRs on both sides feels confusing to me.
6252020-09-10T19:41:54 <jnewbery> I think Marco has a script that merges them into both repositories simultaneously, no?
6262020-09-10T19:41:55 <jonasschnelli> Overall,... i would have prefered to split of the repository with a split off through a clean interface (process seperation in some ways)
6272020-09-10T19:42:08 <wumpus> I think it's nice to have GUI design discussions etc in the other repo
6282020-09-10T19:42:19 <jonasschnelli> jnewbery: could be. I don't know.
6292020-09-10T19:42:35 <jonasschnelli> Yes. I also like the split of the discussions and some GUI only PRs.
6302020-09-10T19:42:47 <jonasschnelli> I just don't know what burden we have when merging things back
6312020-09-10T19:42:58 <wumpus> it's sufficiently distinct from what happens in the main repo that that makes sense
6322020-09-10T19:43:05 <jonasschnelli> Also,... things that touch both "sides": still unclear how to handle that
6332020-09-10T19:43:16 <wumpus> I don't know either, looks like Marco Falke is missing for this discussion
6342020-09-10T19:43:22 <jonasschnelli> looks like
6352020-09-10T19:43:27 <promag> wumpus: most people just have to go to both repos.. it was a good change for those that want stay away from gui stuff
6362020-09-10T19:43:40 <jonasschnelli> However we go further, I think it would be nice to document the process more clear
6372020-09-10T19:44:29 <jnewbery> they seem to be pretty synchronized. The GUI repository is just one merge commit behind bitcoin/bitcoin
6382020-09-10T19:44:31 <jonasschnelli> Also unclear to me how we handle merge conflicts if we merge node stuff into the GUI repository
6392020-09-10T19:44:39 <jeremyrubin> jonasschnelli: +1 on process isolation being important for making the separation clearer
6402020-09-10T19:44:41 <luke-jr> did anyone ever get in touch with GitHub about the PR issues?
6412020-09-10T19:44:53 <jnewbery> jonasschnelli: they're the same commits
6422020-09-10T19:45:26 <jnewbery> there's no conflicts because it's always fast-forwards
6432020-09-10T19:45:28 <wumpus> jeremyrubin: IIRC there's a PR that does process isolation
6442020-09-10T19:45:29 <jonasschnelli> jnewbery: Right. I tihink its a non-issue as long as they stay in sync. Which I guess is a manual script
6452020-09-10T19:46:02 <jeremyrubin> wumpus: ryanofsky's right?
6462020-09-10T19:46:02 <michaelfolkson> I think the major concern is if review decreases with it being separate. I think people on the GUI repo need to regularly prod (cc) GUI reviewers who spend most of their time on the main repo.
6472020-09-10T19:46:22 <wumpus> ryanofsky is working on that #19461
6482020-09-10T19:46:25 <gribble> https://github.com/bitcoin/bitcoin/issues/19461 | multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky · Pull Request #19461 · bitcoin/bitcoin · GitHub
6492020-09-10T19:46:25 <wumpus> yes
6502020-09-10T19:46:33 <jonasschnelli> michaelfolkson: maybe only an initial issue. I think there are now also contributors stepping forward _because_ its GUI only
6512020-09-10T19:47:06 <hebasto> ^ and designers
6522020-09-10T19:47:07 <wumpus> jonasschnelli: exactly, though there's some overlap, it's also meant to get a different group of people involved
6532020-09-10T19:47:22 <michaelfolkson> But mainly designers right jonasschnelli? It needs normal Core reviewers too
6542020-09-10T19:48:03 <michaelfolkson> I think for design related review it is a material success so far
6552020-09-10T19:48:08 <wumpus> ideally we want more GUI contributors, improving the GUI, they don't necessarily need to get involved with the rest of the code
6562020-09-10T19:48:18 <jonasschnelli> michaelfolkson: Yes. Thats correct.
6572020-09-10T19:48:29 <jonasschnelli> It's a different complexity level (mostly). Also the risks are different.
6582020-09-10T19:48:36 <vasild> I think a separate GUI repository only makes sense as long as both repositories contain different chunks of software. Right now both contain the same, e.g. the gui repo contains bitcoind.cpp, net_processing.cpp, etc. Would it be possible to make only src/qt in the gui repo (and then make it a git submodule in the main one)?
6592020-09-10T19:48:45 <wumpus> a different kind of complexity to navigate at least
6602020-09-10T19:48:55 <jeremyrubin> wumpus: is there a framework for moving forward ryanofsky's work? last I checked it was still nack on capnproto?
6612020-09-10T19:49:15 <wumpus> I definitely found out I can't do it, I can't handle the subjectivity and bikeshedding involved :)
6622020-09-10T19:49:37 <jonasschnelli> vasild: this is a valid point
6632020-09-10T19:49:52 <jonasschnelli> wumpus : that. yes.
6642020-09-10T19:50:08 <wumpus> vasild: maybe, though it can't be built independently anymore then, it's harder for contributors
6652020-09-10T19:50:28 <hebasto> bikeshedding is a work for designers, no?
6662020-09-10T19:50:31 <yanmaani> Can't you refactor it to make the GUI an RPC client?
6672020-09-10T19:50:33 <vasild> hm, right, src/qt can't be build separately
6682020-09-10T19:50:50 <yanmaani> (and then optionally have it spawn a bitcoind)
6692020-09-10T19:50:55 <vasild> make make it compilable, libsrcqt.so :)
6702020-09-10T19:51:03 <jonasschnelli> yanmaani: I would also like to see that
6712020-09-10T19:51:16 <yanmaani> Then the GUI could indeed be moved to a separate repo
6722020-09-10T19:51:23 <jonasschnelli> but I guess we are drifting off-topic
6732020-09-10T19:51:24 <yanmaani> and you could have other people making other GUIs in other frameworks
6742020-09-10T19:51:26 <wumpus> yanmaani: that's what the multiprocess PR does, basically
6752020-09-10T19:51:28 <sipa> people tried that in 2012 or so, but it's terrible as RPC is query-response based, not asynchronous
6762020-09-10T19:51:46 <sipa> but the multiprocess work does this the right way
6772020-09-10T19:51:46 <jonasschnelli> sipa: we could use the long polling to make it faster though
6782020-09-10T19:51:47 <yanmaani> sipa: is RPC single-threaded?
6792020-09-10T19:51:48 <wumpus> yanmaani: (except it doesn't use JSON-RPC but its own RPC mechanism)
6802020-09-10T19:52:00 <promag> yanmaani: no
6812020-09-10T19:52:03 <wumpus> in any case ryanofsky's work already exists
6822020-09-10T19:52:10 <sipa> yanmaani: it would be more useful if you'd comment after you've spent some time looking at the code
6832020-09-10T19:52:21 <yanmaani> ok :)
6842020-09-10T19:52:34 <wumpus> no need to brainstorm the 2012 idea of doing it again now
6852020-09-10T19:52:37 <provoostenator> I suggest waiting a while before opening that can of worms though :-)
6862020-09-10T19:52:40 <jnewbery> yanmaani: even more useful if you review/test ryanofsky's work!
6872020-09-10T19:53:02 <jonasschnelli> I think I suggest then that we pimp up the documentation on how things are managed between the two repositories, avoid questions, etc.
6882020-09-10T19:53:17 <wumpus> jonasschnelli: +1
6892020-09-10T19:53:19 <jeremyrubin> wumpus: if some set of maintainers can establish a bit more of a framework on the validity of ryanofsky's approach i would spend some cycles on it. but AFAIU some contribs are nack on the approach so I'm not sure how likely it will proceed if that remains the case or what can be done to un-nack
6902020-09-10T19:53:21 <jonasschnelli> Let's hope MarcoFalke has time and willingness to do this
6912020-09-10T19:53:22 <wumpus> just documenting things would make sense
6922020-09-10T19:53:40 <wumpus> jeremyrubin: who is completely against it?
6932020-09-10T19:53:43 <jonasschnelli> people deserve to know what happens with PRs they write on the GUI repo
6942020-09-10T19:53:45 <jeremyrubin> gmax iirc?
6952020-09-10T19:54:15 <jeremyrubin> iirc he was against capnproto at all and wanted a custom IPC lib
6962020-09-10T19:54:16 <hebasto> +1 for documenting
6972020-09-10T19:54:24 <wumpus> for using capnproto for the GUI? I don't think so, he hates using it for internet protocols, but for internal communication between processes it doesn't matter too much
6982020-09-10T19:54:41 <sipa> no reason to speculate here
6992020-09-10T19:54:48 *** opsec_x122 has joined #bitcoin-core-dev
7002020-09-10T19:54:56 <sipa> afaik ryanofsky said that capnproto could easily be swapped out for something else if needed
7012020-09-10T19:55:06 <jonasschnelli> just the glue
7022020-09-10T19:55:11 <provoostenator> Indeed
7032020-09-10T19:55:12 <wumpus> I'd really dislike rolling our own IPC mechanism tbh
7042020-09-10T19:55:19 <jeremyrubin> do we already depend on it?
7052020-09-10T19:55:25 <jeremyrubin> It's in depends :)
7062020-09-10T19:55:38 <wumpus> there are so many one already, not everything needs to be invented here
7072020-09-10T19:55:44 <provoostenator> We already merged the build stuff for it.
7082020-09-10T19:55:54 <jonasschnelli> I'm still in favour or RPC
7092020-09-10T19:55:55 <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-289842646
7102020-09-10T19:55:56 <provoostenator> But it's an opt-in config flag
7112020-09-10T19:55:58 <wumpus> sipa: yes, it should be easy to swap out
7122020-09-10T19:56:14 <wumpus> he designed it so that the specific mechanism used is abstracted
7132020-09-10T19:56:15 <jnewbery> jonasschnelli: I think it's even easier than I said. Marco just merges the gui PR branch into the bitcoin/bitcoin repo
7142020-09-10T19:56:18 <wumpus> better just review the code...
7152020-09-10T19:56:29 <jonasschnelli> RPC can also work async. But yes. Not the topic now.
7162020-09-10T19:56:46 <wumpus> jonasschnelli: I mean we can do something wildly different but *only* if someone is willing to do the work
7172020-09-10T19:56:47 <jnewbery> and then I guess there's a bot or something that is syncing bitcoin-core/gui to the latest master
7182020-09-10T19:56:52 <jonatack> there is a good recent writeup by ryanofsky, one month ago, here: https://bitcoincore.reviews/19160
7192020-09-10T19:56:57 <wumpus> I see no reason to second-guess ryanofsky now after all this time
7202020-09-10T19:57:00 <jonasschnelli> wumpus: that's a point.
7212020-09-10T19:57:02 <jnewbery> https://github.com/bitcoin/bitcoin/pull/19071
7222020-09-10T19:57:14 <jeremyrubin> I have no issue with capnproto I think it's fine :)
7232020-09-10T19:57:18 <provoostenator> Last time I dug into it I found the approach pretty sane.
7242020-09-10T19:57:33 <wumpus> at least it's a step forward
7252020-09-10T19:57:34 <jeremyrubin> I spent a bunch of time reviewing it in '17 and think it's a good approach
7262020-09-10T19:57:44 <wumpus> when RPC one day converges on what we need for the GUI, then we can switch to that
7272020-09-10T19:58:16 *** opsec_x12 has quit IRC
7282020-09-10T19:58:18 <jonasschnelli> Haven't looked into it. But separating the GUI from the node via the internet/wireguard would be a requirement,.. right?
7292020-09-10T19:58:22 <wumpus> I think it's *very important* to take a step by step approach with things
7302020-09-10T19:58:23 <provoostenator> Conversely, when the IPC interface simplifies and needs fewer locks...
7312020-09-10T19:59:07 <wumpus> if not, we'll never go anywhere, this kind of thing has been proposed since at least 2012
7322020-09-10T19:59:16 <jonasschnelli> indeed
7332020-09-10T19:59:20 <wumpus> because everyone wants something else
7342020-09-10T19:59:29 <jonasschnelli> the power of open source
7352020-09-10T19:59:30 <wumpus> and then someone does it and peopel want yet something else
7362020-09-10T19:59:59 <jeremyrubin> I think that's all I'm asking. If ryanofsky's pr is reasonably reviewed
7372020-09-10T20:00:03 <wumpus> so, anyhow, if you're interested in process separation, please review ryanofsky's PRs
7382020-09-10T20:00:06 <jeremyrubin> there is no 'hard reason' it can't be merged
7392020-09-10T20:00:30 <jeremyrubin> which is great news for anyone willing to spend review cycles on it, it derisks that time spent
7402020-09-10T20:00:33 <wumpus> dont' come up with new wild ideas that would have to start from scratch :)
7412020-09-10T20:00:47 <sdaftuar> jeremyrubin: i would hope not, my understanding is that ryanofsky has been making progress towards this goal for quite some time now
7422020-09-10T20:00:51 *** arowser has quit IRC
7432020-09-10T20:01:18 *** arowser has joined #bitcoin-core-dev
7442020-09-10T20:01:28 <wumpus> of course after reviewing the PR you could give more targeted suggestions
7452020-09-10T20:01:38 <wumpus> oh, it's time
7462020-09-10T20:01:42 <wumpus> #endmeeting
7472020-09-10T20:01:42 <lightningbot> Meeting ended Thu Sep 10 20:01:42 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7482020-09-10T20:01:42 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.html
7492020-09-10T20:01:42 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.txt
7502020-09-10T20:01:42 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-10-19.00.log.html
7512020-09-10T20:01:48 <jonasschnelli> \o
7522020-09-10T20:01:57 <vasild> o/
7532020-09-10T20:02:01 <jonatack> psa, the signet PR seems to be in the final stretch if anyone wants to have a look
7542020-09-10T20:02:09 <wumpus> yay!
7552020-09-10T20:02:30 <jonatack> \o
7562020-09-10T20:02:59 <michaelfolkson> Final stretch as in we can start a barrage of follow up smaller signet PRs
7572020-09-10T20:03:03 *** Madars has quit IRC
7582020-09-10T20:03:16 <wumpus> but FWIW I had the idea that the capnproto approach for IPC communication was widely concept-ACKed a long time ago, that's why the build system part was merged
7592020-09-10T20:03:37 <jeremyrubin> I hadn't tracked that development :)
7602020-09-10T20:03:58 <luke-jr> I don't see why we need two RPC interfaces ;)
7612020-09-10T20:04:10 <wumpus> it's not a RPC interface it's internal interface only
7622020-09-10T20:04:21 <wumpus> it will not be documented for external clients so it has much more flexibility
7632020-09-10T20:04:37 <wumpus> it will also not be compatible between versions
7642020-09-10T20:04:43 <luke-jr> no matter how we use it, it's an RPC interface..
7652020-09-10T20:04:49 <jeremyrubin> I reviewed the process isolation stuff relatively early on, but it wasn't clear that it was going to move forward and didn't think i could do anything to move the needle on making an IPC interface available.
7662020-09-10T20:04:59 <luke-jr> we could just as well add an undocumented and unstable JSON-RPC interface
7672020-09-10T20:04:59 <jeremyrubin> now that I know it is, I'll re-review :)
7682020-09-10T20:05:10 <wumpus> there's a very different set of requirements for it anyhow
7692020-09-10T20:05:18 <wumpus> but as said maybe they can converge in the future
7702020-09-10T20:05:21 <jeremyrubin> luke-jr: the difference is that you can fork a process and explicitly set up the IPC channel
7712020-09-10T20:05:24 <wumpus> the idea is to allow for some experimentation here
7722020-09-10T20:05:39 <jeremyrubin> so that the connection is internal to one parent process
7732020-09-10T20:06:15 <jeremyrubin> You could maybe do this for RPC, but the point of IPC is to allow deeper integration & work with e.g. shared memory.
7742020-09-10T20:06:39 <luke-jr> so it won't be possible to run the GUI on another machine? :/
7752020-09-10T20:06:39 <wumpus> it's simply a pipe, it could send every protocol, but in any case, capnproto is ok for now imo
7762020-09-10T20:07:11 <sipa> jeremyrubin: first thing i hear about shared memory
7772020-09-10T20:07:21 <wumpus> I doubt there are any plans about shared memory
7782020-09-10T20:08:09 <wumpus> if gmaxwell is queasy about capnproto I'm sure he'll go insane when you mention shared memory :-)
7792020-09-10T20:08:31 <wumpus> it's also really not needed for this
7802020-09-10T20:10:35 <yanmaani> It's two different approaches. With well-defined RPC and all that, you can run it on separate machines, and you can have other projects writing GUIs. With shared memory and more "usual" IPC, you're more tightly coupled. So you can iterate faster, but you lose some of the benefits of keeping -gui separate
7812020-09-10T20:10:40 <yanmaani> if it always has to be the same version, for instance
7822020-09-10T20:11:07 <wumpus> yes
7832020-09-10T20:12:51 <luke-jr> fwiw someone mentioned to me the other day a desire to revive wxBitcoin - better separation helps that too
7842020-09-10T20:13:20 <jeremyrubin> iirc capnproto had some shared memory stuff but i may be wrong
7852020-09-10T20:14:02 <yanmaani> If you do the separation very cleanly you could have hundreds of random bozos making GUIs. Whether this is great or horrifying is up to your imagination.
7862020-09-10T20:15:24 <wumpus> revive wxbitcoin?!? whyy
7872020-09-10T20:15:30 <sipa> lol
7882020-09-10T20:15:39 <sipa> has 3.9 been released already?
7892020-09-10T20:15:42 <yanmaani> It was I. I don't like Qt.
7902020-09-10T20:16:01 <wumpus> sigh, I don't even want to know, I want to have 0 to do with the GUI anymore
7912020-09-10T20:16:07 <sipa> eh, 2.9 - apparently yes, they're at 3.1.4
7922020-09-10T20:16:48 <wumpus> sipa: progressss
7932020-09-10T20:17:07 <sipa> yanmaani: use RPC :p
7942020-09-10T20:17:08 <yanmaani> well, with these changes, you can just jettison the unloved components of the codebase
7952020-09-10T20:17:49 <wumpus> I just dislike all the bikeshedding, everyone wants something else, I think "I don't like library X" is an awful reason
7962020-09-10T20:17:55 <yanmaani> Or I can procrastinate on it and wait for these changes to be made, and use whatever you eventually bikeshed on.
7972020-09-10T20:18:52 <wumpus> imo ideally the GUI design should really be made by someone that gets GUIs at a psychological level and designs something that is usable by end-users, not by developers bikeshedding over libraries and widget types
7982020-09-10T20:19:11 <yanmaani> imo you should have two groups
7992020-09-10T20:19:26 <yanmaani> one group of designers who know design who design the psychologically optimal GUI in photoshop
8002020-09-10T20:19:30 <wumpus> developes come with ever sillier concerns
8012020-09-10T20:19:33 <yanmaani> one group of developers who bikeshed over widget types
8022020-09-10T20:19:39 <sipa> yanmaani: will you pay them all?
8032020-09-10T20:19:43 <yanmaani> (and implement the mockup)
8042020-09-10T20:20:23 <wumpus> it's interaction design, you can't really do that in photoshop
8052020-09-10T20:20:41 <sipa> UX is far more than graphical design
8062020-09-10T20:20:47 <wumpus> ^^ very much this
8072020-09-10T20:20:55 <yanmaani> I actually like the way the current GUI looks, and the fact that Electrum has converged on something extremely similar to Core is reassuring
8082020-09-10T20:22:00 <phantomcircuit> what's missing from the current gui is mostly debug related things, but im guessing the intersection between people who need debug stuff and people who won't use the cli is pretty small
8092020-09-10T20:22:18 <sipa> i haven't used the GUI in years
8102020-09-10T20:23:01 <luke-jr> ⥠current GUI
8112020-09-10T20:23:14 <yanmaani> ^
8122020-09-10T20:23:31 <sipa> then what's the problem with Qt?
8132020-09-10T20:23:46 <wumpus> phantomcircuit: what debug information are you missing?
8142020-09-10T20:24:32 * luke-jr ⥠Qt too
8152020-09-10T20:24:40 <achow101> the current gui kinda sucks with multiwallet
8162020-09-10T20:24:46 <achow101> it's really easy to accidentally use the wrong wallet
8172020-09-10T20:25:00 <luke-jr> admittedly, I don't use multiwallet much yet
8182020-09-10T20:25:08 <luke-jr> too much in the habit of closing one and opening another
8192020-09-10T20:25:20 <wumpus> I only use multiwallet for watch-only things
8202020-09-10T20:25:30 <gwillen> I mostly use multiwallet for manual testing tbh, but it's fantastic for that
8212020-09-10T20:26:09 <achow101> I run multiple wallets watching the same thing lol
8222020-09-10T20:26:22 <achow101> tbf, one is legacy, another descriptor, and the last sqlite descriptor
8232020-09-10T20:26:30 <wumpus> hehe
8242020-09-10T20:27:01 <phantomcircuit> wumpus, "is this transaction in the mempool", "how big is the mempool" ie things that aren't actually relevant to most users
8252020-09-10T20:27:24 <wumpus> phantomcircuit: ah yes, mempool information is a bit sparse
8262020-09-10T20:27:35 <achow101> phantomcircuit: how big is the mempool is reported
8272020-09-10T20:28:00 <sipa> i'd like a debug tool with a secp256k1 DL solver
8282020-09-10T20:28:02 <luke-jr> phantomcircuit: Knots has some mempool graph stuff jonasschnelli wrote years ago
8292020-09-10T20:28:04 <sipa> would come in really.handy
8302020-09-10T20:28:21 <wumpus> did we never merge the mempool graph stuff?
8312020-09-10T20:28:32 <wumpus> I thought that was pretty nice
8322020-09-10T20:28:48 <luke-jr> wumpus: I have rebased versions of an older version of the PR
8332020-09-10T20:28:59 <jonasschnelli> I have picked this up recently
8342020-09-10T20:29:03 <luke-jr> jonasschnelli changed the RPC side of it all around, but never updated the GUI for it
8352020-09-10T20:29:06 <luke-jr> ah, nice
8362020-09-10T20:29:12 <wumpus> that's the kind of things I like about the GUI tbh, debug and data visualization
8372020-09-10T20:29:18 <sipa> indeed
8382020-09-10T20:29:32 <jonasschnelli> Made it more like Jochen Hoenick ones
8392020-09-10T20:29:40 <jonasschnelli> With few ranges
8402020-09-10T20:29:57 <jonasschnelli> Iâll PR that soon.
8412020-09-10T20:30:01 <wumpus> jonasschnelli: awesome!
8422020-09-10T20:30:22 <wumpus> I think it would be very nice if users can see those things locally, without having to go to a site
8432020-09-10T20:30:46 *** Aracely71Hammes has joined #bitcoin-core-dev
8442020-09-10T20:31:52 <jeremyrubin> [9/10/20 13:28] <sipa> i'd like a debug tool with a secp256k1 DL solver
8452020-09-10T20:32:07 <jeremyrubin> I'd think you'd see this before a good QT GUI debugger
8462020-09-10T20:32:51 <jeremyrubin> The only question is if you can make a good trapdoor function out of bugs in QT
8472020-09-10T20:33:24 <jeremyrubin> BIP QT-root
8482020-09-10T20:35:41 *** Aracely71Hammes has quit IRC
8492020-09-10T20:36:01 <wumpus> a DL solver would definitely be useful :')
8502020-09-10T20:36:40 <wumpus> at least if it doesn't hold up the GUI loop for a million billion years
8512020-09-10T20:37:37 <sipa> haha
8522020-09-10T20:37:45 *** Highway61 has quit IRC
8532020-09-10T20:39:22 <promag> <sipa> i haven't used the GUI in years
8542020-09-10T20:39:25 <promag> because GUI uses sipa
8552020-09-10T20:39:27 <jonasschnelli> for the ones interested in the mempool size/fee chart: https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2020/03/mempool_graph?expand=1
8562020-09-10T20:39:32 <jonasschnelli> (it's WIP)
8572020-09-10T20:40:19 <jonasschnelli> It's more or less a clone of https://jochen-hoenicke.de/queue/#0,24h
8582020-09-10T20:40:20 <jonasschnelli> (but obviously internal and QT native)
8592020-09-10T20:40:20 <gribble> https://github.com/bitcoin/bitcoin/issues/0 | HTTP Error 404: Not Found
8602020-09-10T20:47:00 <phantomcircuit> sipa, btw going from 1000 to 100k keys only added 50% to the runtime of a rescan
8612020-09-10T20:47:33 <sipa> phantomcircuit: wait until you hit enough keys that the mapKeys structure doesn't fit in RAM anymore
8622020-09-10T20:47:42 <sipa> ;)
8632020-09-10T20:47:49 <luke-jr> could always use a bloom filter for the wallet keys, to speed it up ;)
8642020-09-10T20:48:04 <phantomcircuit> sipa, that would be a very very large number of keys
8652020-09-10T20:48:17 <sipa> phantomcircuit: you just have too much RAM
8662020-09-10T20:48:19 <sipa> ;)
8672020-09-10T20:49:04 <sipa> phantomcircuit: more seriously, i think the actual impact of number of keys on rescan speed isn't so much the O(log n) scaling, but whether or not the mapKeys fits in various levels of CPU cache or RAM
8682020-09-10T20:49:42 <phantomcircuit> sipa, indeed
8692020-09-10T20:50:30 <wumpus> jonasschnelli: that's great!
8702020-09-10T20:50:36 <phantomcircuit> luke-jr, the gcs filters that 'neutrino' use are what i was using, but to actually use them requires changing violating some assumptions the current logic has (namely that every block derives the filter key from the block hash)
8712020-09-10T20:54:50 *** promag has quit IRC
8722020-09-10T20:54:59 *** promag has joined #bitcoin-core-dev
8732020-09-10T20:55:47 *** promag has joined #bitcoin-core-dev
8742020-09-10T20:55:47 *** tryphe has joined #bitcoin-core-dev
8752020-09-10T20:57:06 *** Madars has joined #bitcoin-core-dev
8762020-09-10T20:57:17 *** vincenzopalazzo has quit IRC
8772020-09-10T20:57:45 *** tryphe_ has quit IRC
8782020-09-10T21:00:01 *** popey1 has quit IRC
8792020-09-10T21:00:16 *** promag has quit IRC
8802020-09-10T21:00:48 *** promag has joined #bitcoin-core-dev
8812020-09-10T21:01:11 *** Guyver2 has quit IRC
8822020-09-10T21:01:58 <luke-jr> phantomcircuit: I meant the other direction
8832020-09-10T21:02:07 *** promag has quit IRC
8842020-09-10T21:02:30 *** promag has joined #bitcoin-core-dev
8852020-09-10T21:04:47 *** Highway61 has joined #bitcoin-core-dev
8862020-09-10T21:05:31 <phantomcircuit> luke-jr, ?
8872020-09-10T21:05:41 <phantomcircuit> oh put the wallet keys into a filter
8882020-09-10T21:05:44 <luke-jr> yes
8892020-09-10T21:06:10 <luke-jr> if you do it right, you might even be able to do a union of the neutrino filters with the wallet filter..
8902020-09-10T21:06:11 <phantomcircuit> iirc most of the time for the current rescan is actually deserializing the block and verifying the merkle root
8912020-09-10T21:06:24 <achow101> sipa: interestingly on my branch where i've changed ~all of the wallet maps and sets to unordered_map/set, the rescan actually takes 10x longer. On both newly created legacy and descriptor wallets
8922020-09-10T21:06:26 <luke-jr> you don't need to verify the merkle root
8932020-09-10T21:06:52 <achow101> seems like siphash is a lot slower than one map comparison?
8942020-09-10T21:07:08 *** Highway61 has quit IRC
8952020-09-10T21:07:15 <sipa> achow101: interesting
8962020-09-10T21:07:48 <achow101> actually, siphash probably isn't being used there, the hashers for CKeyID and CScriptID just use uint's GetUint64
8972020-09-10T21:08:44 <phantomcircuit> luke-jr, ok but it does verify the merkle tree because you're loading the block from disk
8982020-09-10T21:09:39 <yanmaani> would PRs be accepted where you replace std::unordered_map with something else for CCoinsViewCache, or is that not worth looking into?
8992020-09-10T21:10:46 <sipa> if it's measurably faster, possibly
9002020-09-10T21:10:48 <wumpus> jonasschnelli: will try it out a bit tomorrow
9012020-09-10T21:11:46 <phantomcircuit> luke-jr, anyways if you setup the gcs filter index things using a local static key then you can calculate the hashes that you need to check against and save them, which makes the rescan basically just finding the union of two sets
9022020-09-10T21:12:17 <luke-jr> phantomcircuit: but make both sets a filter
9032020-09-10T21:12:48 <phantomcircuit> luke-jr, i guess you could take the gcs set and make a bloom filter on top of that?
9042020-09-10T21:12:51 <wumpus> besides being demostratively faster, it also depends on 'something else', e.g. probably not if it introduces any new dependencies on boost, or anything else external
9052020-09-10T21:13:07 <phantomcircuit> iono i suspect that would actually be slower than just doing the giant union of the sets calculation
9062020-09-10T21:13:19 <wumpus> also as it's a consensus critical data structure it's something to be very careful with
9072020-09-10T21:13:38 <luke-jr> bdb!
9082020-09-10T21:13:43 * luke-jr hides
9092020-09-10T21:14:12 <jb55> achow101: agreed on multiwallet gui. this is something I still use cli for over qt. would be great to have an "all wallets" transaction view.
9102020-09-10T21:19:00 <sipa> jb55: if you have the same key/address/descriptor imported in multiple simultaneously-loaded wallets, an "all wallets" overview may be confusing
9112020-09-10T21:19:39 * sipa predicts people creating 1M wallets with the same 21 BTC UTXO on it, and screenshottijg their 21M BTC combined balance
9122020-09-10T21:20:26 <achow101> sipa: it feels like importing the same thing into multiple wallets might not be something people tend to do
9132020-09-10T21:20:27 <luke-jr> sipa: then don't use it? :P
9142020-09-10T21:20:29 <jb55> sipa: maybe they shouldn't do that :P
9152020-09-10T21:20:55 <sipa> jb55: seems achow101 just did!
9162020-09-10T21:21:43 <achow101> sipa: I suspect that you won't be able to load 1M wallets
9172020-09-10T21:22:14 *** Theopolisme has joined #bitcoin-core-dev
9182020-09-10T21:22:28 <sipa> achow101: software should be optimized for all use cases!
9192020-09-10T21:22:36 *** luke-jr has quit IRC
9202020-09-10T21:22:50 <jb55> 150m keys should be instant imo
9212020-09-10T21:23:27 *** luke-jr has joined #bitcoin-core-dev
9222020-09-10T21:23:50 *** Madars has quit IRC
9232020-09-10T21:31:26 *** tryphe has quit IRC
9242020-09-10T21:32:11 *** tryphe has joined #bitcoin-core-dev
9252020-09-10T22:03:58 *** Madars has joined #bitcoin-core-dev
9262020-09-10T22:07:12 *** kristapsk has quit IRC
9272020-09-10T22:08:21 *** kristapsk has joined #bitcoin-core-dev
9282020-09-10T22:34:06 *** Eagle[TM] has joined #bitcoin-core-dev
9292020-09-10T22:35:37 *** EagleTM has quit IRC
9302020-09-10T22:38:41 *** bitcoin-git has joined #bitcoin-core-dev
9312020-09-10T22:38:41 <bitcoin-git> [bitcoin] ajtowns opened pull request #19937: signet mining utility (master...202009-signet-generate) https://github.com/bitcoin/bitcoin/pull/19937
9322020-09-10T22:38:43 *** bitcoin-git has left #bitcoin-core-dev
9332020-09-10T22:59:23 *** vasild has quit IRC
9342020-09-10T23:01:24 *** vasild has joined #bitcoin-core-dev
9352020-09-10T23:02:06 *** Aaronvan_ has quit IRC
9362020-09-10T23:16:57 *** promag has quit IRC
9372020-09-10T23:21:59 *** mdunnio has quit IRC
9382020-09-10T23:26:29 *** shaunsun has quit IRC
9392020-09-10T23:34:58 *** AaronvanW has joined #bitcoin-core-dev
9402020-09-10T23:39:38 *** AaronvanW has quit IRC
9412020-09-10T23:42:59 *** lightlike has quit IRC
9422020-09-10T23:45:52 *** sr_gi has quit IRC
9432020-09-10T23:45:52 *** mdunnio has joined #bitcoin-core-dev
9442020-09-10T23:46:25 *** sr_gi has joined #bitcoin-core-dev
9452020-09-10T23:50:19 *** mdunnio has quit IRC
9462020-09-10T23:53:48 *** Sambij has joined #bitcoin-core-dev