12020-02-11T00:00:02 *** yano1 has quit IRC
22020-02-11T00:00:07 *** lukedashjr is now known as luke-jr
32020-02-11T00:00:21 *** marcoagner has quit IRC
42020-02-11T00:00:32 *** kristapsk_ has quit IRC
52020-02-11T00:00:54 *** kristapsk_ has joined #bitcoin-core-dev
62020-02-11T00:02:08 *** lukedashjr has joined #bitcoin-core-dev
72020-02-11T00:03:32 *** luke-jr- has joined #bitcoin-core-dev
82020-02-11T00:04:27 *** luke-jr has quit IRC
92020-02-11T00:05:49 *** luke-jr has joined #bitcoin-core-dev
102020-02-11T00:06:05 *** bitcoin-git has joined #bitcoin-core-dev
112020-02-11T00:06:06 <bitcoin-git> [bitcoin] za-kk reopened pull request #17355: gui: grey out used address in address book (master...oct-19-17174) https://github.com/bitcoin/bitcoin/pull/17355
122020-02-11T00:06:07 *** bitcoin-git has left #bitcoin-core-dev
132020-02-11T00:07:17 *** lukedashjr has quit IRC
142020-02-11T00:08:09 *** lukedashjr has joined #bitcoin-core-dev
152020-02-11T00:08:51 *** luke-jr- has quit IRC
162020-02-11T00:09:36 *** luke-jr- has joined #bitcoin-core-dev
172020-02-11T00:11:17 *** luke-jr has quit IRC
182020-02-11T00:12:33 *** turbo_choo has quit IRC
192020-02-11T00:13:11 *** lukedashjr has quit IRC
202020-02-11T00:13:39 *** luke-jr has joined #bitcoin-core-dev
212020-02-11T00:14:20 *** lukedashjr has joined #bitcoin-core-dev
222020-02-11T00:15:39 *** luke-jr- has quit IRC
232020-02-11T00:16:20 *** luke-jr- has joined #bitcoin-core-dev
242020-02-11T00:18:17 *** angvp has joined #bitcoin-core-dev
252020-02-11T00:18:19 *** luke-jr has quit IRC
262020-02-11T00:18:40 *** angvp is now known as Guest20816
272020-02-11T00:20:06 *** luke-jr has joined #bitcoin-core-dev
282020-02-11T00:20:20 *** lukedashjr has quit IRC
292020-02-11T00:22:16 *** luke-jr- has quit IRC
302020-02-11T00:22:57 *** mryandao has quit IRC
312020-02-11T00:23:18 *** mryandao has joined #bitcoin-core-dev
322020-02-11T00:25:29 *** bitcoin-git has joined #bitcoin-core-dev
332020-02-11T00:25:29 <bitcoin-git> [bitcoin] jnewbery opened pull request #18113: [coins] Don't allow a coin to spent and FRESH. Improve commenting. (master...2020-01-prune-pruned) https://github.com/bitcoin/bitcoin/pull/18113
342020-02-11T00:25:30 *** bitcoin-git has left #bitcoin-core-dev
352020-02-11T00:28:15 *** lukedashjr has joined #bitcoin-core-dev
362020-02-11T00:31:56 *** luke-jr has quit IRC
372020-02-11T00:33:18 *** luke-jr has joined #bitcoin-core-dev
382020-02-11T00:34:05 *** lukedashjr has quit IRC
392020-02-11T00:36:17 *** opsec_x12 has joined #bitcoin-core-dev
402020-02-11T00:39:25 *** opsec_x122 has joined #bitcoin-core-dev
412020-02-11T00:40:24 *** opsec_x122 has quit IRC
422020-02-11T00:43:31 *** opsec_x12 has quit IRC
432020-02-11T00:44:22 *** lukedashjr has joined #bitcoin-core-dev
442020-02-11T00:45:04 *** luke-jr- has joined #bitcoin-core-dev
452020-02-11T00:45:20 *** AaronvanW has quit IRC
462020-02-11T00:47:13 *** promag has quit IRC
472020-02-11T00:47:29 *** luke-jr has quit IRC
482020-02-11T00:47:40 *** luke-jr| has joined #bitcoin-core-dev
492020-02-11T00:49:20 *** lukedashjr has quit IRC
502020-02-11T00:50:27 *** luke-jr has joined #bitcoin-core-dev
512020-02-11T00:51:02 *** lukedashjr has joined #bitcoin-core-dev
522020-02-11T00:51:16 *** luke-jr- has quit IRC
532020-02-11T00:51:52 *** pkr has joined #bitcoin-core-dev
542020-02-11T00:52:19 *** luke-jr- has joined #bitcoin-core-dev
552020-02-11T00:52:51 *** luke-jr| has quit IRC
562020-02-11T00:54:38 *** luke-jr| has joined #bitcoin-core-dev
572020-02-11T00:55:11 *** luke-jr has quit IRC
582020-02-11T00:55:17 *** jarthur_ has joined #bitcoin-core-dev
592020-02-11T00:55:39 *** lukedashjr has quit IRC
602020-02-11T00:57:04 *** luke-jr- has quit IRC
612020-02-11T00:58:53 *** luke-jr| is now known as luke-jr
622020-02-11T00:59:29 *** jarthur has quit IRC
632020-02-11T00:59:58 *** jarthur_ has quit IRC
642020-02-11T01:01:25 *** rafalcpp_ has joined #bitcoin-core-dev
652020-02-11T01:01:39 *** rafalcpp has quit IRC
662020-02-11T01:03:09 *** lukedashjr has joined #bitcoin-core-dev
672020-02-11T01:04:11 *** luke-jr- has joined #bitcoin-core-dev
682020-02-11T01:06:23 *** luke-jr has quit IRC
692020-02-11T01:06:43 *** Dean_Guss has quit IRC
702020-02-11T01:07:12 *** luke-jr has joined #bitcoin-core-dev
712020-02-11T01:08:25 *** luke-jr| has joined #bitcoin-core-dev
722020-02-11T01:08:27 *** lukedashjr has quit IRC
732020-02-11T01:10:11 *** luke-jr- has quit IRC
742020-02-11T01:12:03 *** luke-jr has quit IRC
752020-02-11T01:12:13 <cfields_> gitian builders: detached sigs for v0.19.1rc2 are up.
762020-02-11T01:12:25 <fanquake> ð
772020-02-11T01:12:49 *** luke-jr has joined #bitcoin-core-dev
782020-02-11T01:13:39 *** luke-jr| has quit IRC
792020-02-11T01:14:40 *** lukedashjr has joined #bitcoin-core-dev
802020-02-11T01:18:14 *** luke-jr- has joined #bitcoin-core-dev
812020-02-11T01:18:25 *** luke-jr has quit IRC
822020-02-11T01:19:39 *** lukedashjr has quit IRC
832020-02-11T01:21:07 *** promag has joined #bitcoin-core-dev
842020-02-11T01:24:07 *** luke-jr- has quit IRC
852020-02-11T01:25:20 *** luke-jr has joined #bitcoin-core-dev
862020-02-11T01:28:20 *** lukedashjr has joined #bitcoin-core-dev
872020-02-11T01:31:07 *** promag has quit IRC
882020-02-11T01:31:43 *** luke-jr has quit IRC
892020-02-11T01:33:37 *** lukedashjr has quit IRC
902020-02-11T01:34:52 *** luke-jr has joined #bitcoin-core-dev
912020-02-11T01:41:08 *** luke-jr has quit IRC
922020-02-11T01:42:24 *** luke-jr has joined #bitcoin-core-dev
932020-02-11T01:43:20 *** lukedashjr has joined #bitcoin-core-dev
942020-02-11T01:46:51 *** luke-jr has quit IRC
952020-02-11T01:49:27 *** lukedashjr has quit IRC
962020-02-11T01:49:30 *** luke-jr has joined #bitcoin-core-dev
972020-02-11T02:01:09 *** jarthur has joined #bitcoin-core-dev
982020-02-11T02:03:23 *** promag has joined #bitcoin-core-dev
992020-02-11T02:05:03 *** vasild has quit IRC
1002020-02-11T02:08:07 *** promag has quit IRC
1012020-02-11T02:27:21 *** krvopije has joined #bitcoin-core-dev
1022020-02-11T02:29:47 *** krvopije has quit IRC
1032020-02-11T02:45:36 *** jarthur has quit IRC
1042020-02-11T02:47:34 *** turbo_choo has joined #bitcoin-core-dev
1052020-02-11T02:49:29 *** Dean_Guss has joined #bitcoin-core-dev
1062020-02-11T03:00:01 *** Guest20816 has quit IRC
1072020-02-11T03:01:36 *** abrissbi1ne has joined #bitcoin-core-dev
1082020-02-11T03:04:44 *** abrissbirne has quit IRC
1092020-02-11T03:04:54 *** commavir has quit IRC
1102020-02-11T03:06:26 *** commavir has joined #bitcoin-core-dev
1112020-02-11T03:13:39 *** Highway61 has quit IRC
1122020-02-11T03:14:43 *** jb55 has quit IRC
1132020-02-11T03:15:04 *** ghost43 has quit IRC
1142020-02-11T03:15:04 *** braydonf_ has quit IRC
1152020-02-11T03:15:04 *** afk11 has quit IRC
1162020-02-11T03:15:31 *** jarthur has joined #bitcoin-core-dev
1172020-02-11T03:15:43 *** Dean_Guss has quit IRC
1182020-02-11T03:15:44 *** kristapsk_ has quit IRC
1192020-02-11T03:15:44 *** morcos has quit IRC
1202020-02-11T03:15:44 *** alec has quit IRC
1212020-02-11T03:15:44 *** sipa has quit IRC
1222020-02-11T03:15:44 *** SiAnDoG__ has quit IRC
1232020-02-11T03:17:02 *** wyk has joined #bitcoin-core-dev
1242020-02-11T03:17:36 *** StarBrilliant1 has joined #bitcoin-core-dev
1252020-02-11T03:18:35 *** wyk has quit IRC
1262020-02-11T03:24:27 *** turbo_choo has quit IRC
1272020-02-11T03:26:22 *** turbo_choo has joined #bitcoin-core-dev
1282020-02-11T03:29:07 *** ddustin has joined #bitcoin-core-dev
1292020-02-11T03:40:53 *** felixfoertsch has joined #bitcoin-core-dev
1302020-02-11T03:41:33 *** felixfoertsch23 has quit IRC
1312020-02-11T03:47:15 *** ddustin has quit IRC
1322020-02-11T03:59:38 *** jb55 has joined #bitcoin-core-dev
1332020-02-11T04:02:07 *** sipa has joined #bitcoin-core-dev
1342020-02-11T04:03:48 *** braydonf_ has joined #bitcoin-core-dev
1352020-02-11T04:03:49 *** afk11 has joined #bitcoin-core-dev
1362020-02-11T04:05:45 *** DeanGuss has joined #bitcoin-core-dev
1372020-02-11T04:12:14 *** vasild has joined #bitcoin-core-dev
1382020-02-11T04:16:45 *** ghost43 has joined #bitcoin-core-dev
1392020-02-11T04:40:59 *** promag has joined #bitcoin-core-dev
1402020-02-11T04:42:01 *** alec has joined #bitcoin-core-dev
1412020-02-11T04:46:09 *** promag has quit IRC
1422020-02-11T04:58:44 *** Eagle[TM] has joined #bitcoin-core-dev
1432020-02-11T05:00:39 *** EagleTM has quit IRC
1442020-02-11T05:23:43 *** bitcoin-git has joined #bitcoin-core-dev
1452020-02-11T05:23:43 <bitcoin-git> [bitcoin] achow101 opened pull request #18115: [wallet] Pass in transactions and messages for signing instead of exporting the private keys (master...sign-in-spkman) https://github.com/bitcoin/bitcoin/pull/18115
1462020-02-11T05:23:53 *** bitcoin-git has left #bitcoin-core-dev
1472020-02-11T05:42:34 *** ttttt has joined #bitcoin-core-dev
1482020-02-11T05:47:46 *** ttttt has left #bitcoin-core-dev
1492020-02-11T05:59:25 *** ghost43 has quit IRC
1502020-02-11T05:59:43 *** ghost43 has joined #bitcoin-core-dev
1512020-02-11T06:00:02 *** StarBrilliant1 has quit IRC
1522020-02-11T06:06:33 *** morcos has joined #bitcoin-core-dev
1532020-02-11T06:25:26 *** rjected has quit IRC
1542020-02-11T06:42:54 *** rex4539 has joined #bitcoin-core-dev
1552020-02-11T06:46:58 *** ButterflyOfFire has joined #bitcoin-core-dev
1562020-02-11T06:50:00 *** promag has joined #bitcoin-core-dev
1572020-02-11T06:53:39 *** anon_ribit has quit IRC
1582020-02-11T06:54:03 *** promag has quit IRC
1592020-02-11T06:54:53 *** anon_ribit has joined #bitcoin-core-dev
1602020-02-11T07:00:48 *** ddustin has joined #bitcoin-core-dev
1612020-02-11T07:04:00 *** jarthur has quit IRC
1622020-02-11T07:06:55 *** goatpig has joined #bitcoin-core-dev
1632020-02-11T07:11:10 *** Eagle[TM] has quit IRC
1642020-02-11T07:16:21 *** jaheller has joined #bitcoin-core-dev
1652020-02-11T07:20:03 <jaheller> Hi, some multisig "gurus" here? Got a question regarding multisig, seems like there was a change in how multisig transactions are being created. Running a node using bitcoind v0.16.3 and another one using latest bitcoind (v.0.19.0.1). The multisig transaction created on the old node can be decoded by https://coinb.in correctly (it's displayed as a
1662020-02-11T07:20:04 <jaheller> multisig 2:3 transaction). Using the newest bitcoind to create transaction coinb.in isn't able to display it correctly. Someone involved into this?
1672020-02-11T07:26:58 *** bitcoin-git has joined #bitcoin-core-dev
1682020-02-11T07:26:59 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/646f0ada0205...35b7a8e539fa
1692020-02-11T07:26:59 <bitcoin-git> bitcoin/master 0e0fa27 Pieter Wuille: Get rid of VARINT default argument
1702020-02-11T07:27:00 <bitcoin-git> bitcoin/master 35b7a8e fanquake: Merge #18087: Get rid of VARINT default argument
1712020-02-11T07:27:08 *** bitcoin-git has left #bitcoin-core-dev
1722020-02-11T07:27:23 *** bitcoin-git has joined #bitcoin-core-dev
1732020-02-11T07:27:23 <bitcoin-git> [bitcoin] fanquake merged pull request #18087: Get rid of VARINT default argument (master...202002_novarintvarmacro) https://github.com/bitcoin/bitcoin/pull/18087
1742020-02-11T07:27:24 *** bitcoin-git has left #bitcoin-core-dev
1752020-02-11T07:31:24 *** turbo_choo has quit IRC
1762020-02-11T07:34:16 *** turbo_choo has joined #bitcoin-core-dev
1772020-02-11T07:43:43 *** vasild has quit IRC
1782020-02-11T07:45:16 *** vasild has joined #bitcoin-core-dev
1792020-02-11T07:48:34 *** manantial has joined #bitcoin-core-dev
1802020-02-11T08:03:37 *** coucou_bot has joined #bitcoin-core-dev
1812020-02-11T08:03:37 *** coucou_bot has left #bitcoin-core-dev
1822020-02-11T08:03:48 *** morcos has quit IRC
1832020-02-11T08:04:42 *** ddustin has quit IRC
1842020-02-11T08:07:30 <sipa> jaheller: ask on bitcoin.stackexchange.com
1852020-02-11T08:07:41 *** morcos has joined #bitcoin-core-dev
1862020-02-11T08:10:01 *** rockhouse has quit IRC
1872020-02-11T08:10:01 *** victorSN has quit IRC
1882020-02-11T08:10:50 *** rockhouse has joined #bitcoin-core-dev
1892020-02-11T08:11:14 *** victorSN has joined #bitcoin-core-dev
1902020-02-11T08:16:09 *** promag has joined #bitcoin-core-dev
1912020-02-11T08:17:29 *** marcoagner has joined #bitcoin-core-dev
1922020-02-11T08:18:57 *** ddustin has joined #bitcoin-core-dev
1932020-02-11T08:21:15 *** bitcoin-git has joined #bitcoin-core-dev
1942020-02-11T08:21:15 <bitcoin-git> [bitcoin] hebasto opened pull request #18116: depends: Use clang for Ubuntu 16.04 (master...20200211-clang-ubuntu) https://github.com/bitcoin/bitcoin/pull/18116
1952020-02-11T08:21:26 *** bitcoin-git has left #bitcoin-core-dev
1962020-02-11T08:24:01 *** ddustin has quit IRC
1972020-02-11T08:24:15 <jaheller> sipa Done, thanks.
1982020-02-11T08:32:48 *** bitcoin-git has joined #bitcoin-core-dev
1992020-02-11T08:32:49 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/35b7a8e539fa...98264e2ccb17
2002020-02-11T08:32:50 <bitcoin-git> bitcoin/master fa55a25 MarcoFalke: depends: Remove reference to win32
2012020-02-11T08:32:51 <bitcoin-git> bitcoin/master fae9084 MarcoFalke: build: Skip i686 build by default in guix and gitian
2022020-02-11T08:32:52 <bitcoin-git> bitcoin/master 98264e2 fanquake: Merge #18104: build: Skip i686 build by default in guix and gitian
2032020-02-11T08:32:53 *** bitcoin-git has left #bitcoin-core-dev
2042020-02-11T08:33:08 *** bitcoin-git has joined #bitcoin-core-dev
2052020-02-11T08:33:09 <bitcoin-git> [bitcoin] fanquake merged pull request #18104: build: Skip i686 build by default in guix and gitian (master...2002-i686NoBuildByDefault) https://github.com/bitcoin/bitcoin/pull/18104
2062020-02-11T08:33:10 *** bitcoin-git has left #bitcoin-core-dev
2072020-02-11T08:44:43 *** jaheller has quit IRC
2082020-02-11T08:59:03 *** Guyver2 has joined #bitcoin-core-dev
2092020-02-11T09:00:01 *** ButterflyOfFire has quit IRC
2102020-02-11T09:04:28 *** jarthur has joined #bitcoin-core-dev
2112020-02-11T09:05:54 *** rex4539 has quit IRC
2122020-02-11T09:08:39 *** rex4539 has joined #bitcoin-core-dev
2132020-02-11T09:09:28 *** jarthur has quit IRC
2142020-02-11T09:18:07 *** Kmos has joined #bitcoin-core-dev
2152020-02-11T09:19:45 *** promag has quit IRC
2162020-02-11T09:25:23 *** promag has joined #bitcoin-core-dev
2172020-02-11T09:38:37 *** rex4539 has joined #bitcoin-core-dev
2182020-02-11T09:38:54 *** rex4539 has joined #bitcoin-core-dev
2192020-02-11T09:39:28 *** rex4539 has joined #bitcoin-core-dev
2202020-02-11T09:40:09 *** rex4539 has joined #bitcoin-core-dev
2212020-02-11T09:41:07 *** rex4539 has joined #bitcoin-core-dev
2222020-02-11T09:41:39 *** rex4539 has joined #bitcoin-core-dev
2232020-02-11T09:41:57 *** rex4539 has joined #bitcoin-core-dev
2242020-02-11T09:42:24 *** rex4539 has joined #bitcoin-core-dev
2252020-02-11T09:47:37 *** rex4539 has quit IRC
2262020-02-11T09:52:11 *** tecnecio_ has joined #bitcoin-core-dev
2272020-02-11T09:53:57 *** manantial has quit IRC
2282020-02-11T09:56:07 *** AaronvanW has joined #bitcoin-core-dev
2292020-02-11T09:58:47 *** Kmos has quit IRC
2302020-02-11T10:06:52 <elichai2> j #regex
2312020-02-11T10:06:54 <elichai2> ops
2322020-02-11T10:08:04 *** Guyver2 has quit IRC
2332020-02-11T10:22:09 *** bitcoin-git has joined #bitcoin-core-dev
2342020-02-11T10:22:09 <bitcoin-git> [bitcoin] hebasto opened pull request #18117: build: Fix Qt link issue for macOS target with DEBUG=1 (master...20200211-macos-debug) https://github.com/bitcoin/bitcoin/pull/18117
2352020-02-11T10:22:10 *** bitcoin-git has left #bitcoin-core-dev
2362020-02-11T10:27:12 *** jcoe has joined #bitcoin-core-dev
2372020-02-11T10:31:28 *** turbo_choo has quit IRC
2382020-02-11T10:39:12 *** timothy has joined #bitcoin-core-dev
2392020-02-11T10:42:39 *** jaqque1 has joined #bitcoin-core-dev
2402020-02-11T10:45:15 *** promag has quit IRC
2412020-02-11T10:45:59 *** promag has joined #bitcoin-core-dev
2422020-02-11T10:46:51 *** jaqque1 has quit IRC
2432020-02-11T10:48:30 *** anon_ribit has quit IRC
2442020-02-11T10:48:49 *** anon_ribit has joined #bitcoin-core-dev
2452020-02-11T11:03:58 *** Delbert71Koelpin has joined #bitcoin-core-dev
2462020-02-11T11:05:54 *** jarthur has joined #bitcoin-core-dev
2472020-02-11T11:07:29 *** rex4539 has joined #bitcoin-core-dev
2482020-02-11T11:10:42 *** jarthur has quit IRC
2492020-02-11T11:10:44 *** mterwoord has joined #bitcoin-core-dev
2502020-02-11T11:12:33 *** rex4539 has quit IRC
2512020-02-11T11:19:10 *** ddustin has joined #bitcoin-core-dev
2522020-02-11T11:19:29 *** rex4539 has joined #bitcoin-core-dev
2532020-02-11T11:23:57 *** ddustin has quit IRC
2542020-02-11T11:24:43 *** turbo_choo has joined #bitcoin-core-dev
2552020-02-11T11:54:53 *** Delbert71Koelpin has quit IRC
2562020-02-11T12:00:02 *** mterwoord has quit IRC
2572020-02-11T12:05:44 *** filchef has joined #bitcoin-core-dev
2582020-02-11T12:14:09 *** ghost43 has quit IRC
2592020-02-11T12:18:01 *** guilhermeblanco has joined #bitcoin-core-dev
2602020-02-11T12:30:58 *** Zenton has quit IRC
2612020-02-11T12:34:18 *** Zenton has joined #bitcoin-core-dev
2622020-02-11T13:06:53 *** jarthur has joined #bitcoin-core-dev
2632020-02-11T13:09:18 *** Highway61 has joined #bitcoin-core-dev
2642020-02-11T13:11:27 *** jarthur has quit IRC
2652020-02-11T13:19:23 *** sdaftuar has quit IRC
2662020-02-11T13:22:36 *** abrissbi1ne is now known as abrissbirne
2672020-02-11T13:24:38 *** ghost43 has joined #bitcoin-core-dev
2682020-02-11T13:25:00 *** rex4539 has quit IRC
2692020-02-11T13:29:05 <wumpus> newer boost::test output is nicely colorful
2702020-02-11T13:29:10 *** promag has quit IRC
2712020-02-11T13:29:24 *** promag has joined #bitcoin-core-dev
2722020-02-11T13:49:53 *** pabed____ has joined #bitcoin-core-dev
2732020-02-11T13:57:19 *** mol has quit IRC
2742020-02-11T14:04:39 *** PaulTroon has quit IRC
2752020-02-11T14:09:55 *** belcher has joined #bitcoin-core-dev
2762020-02-11T14:12:01 *** vasild_ has joined #bitcoin-core-dev
2772020-02-11T14:12:23 *** vasild has quit IRC
2782020-02-11T14:24:21 *** AaronvanW has quit IRC
2792020-02-11T14:40:17 *** PaulTroon has joined #bitcoin-core-dev
2802020-02-11T14:41:42 *** emilengler has joined #bitcoin-core-dev
2812020-02-11T14:51:29 *** AaronvanW has joined #bitcoin-core-dev
2822020-02-11T14:56:55 *** qwerty has joined #bitcoin-core-dev
2832020-02-11T14:59:06 *** qwerty has quit IRC
2842020-02-11T15:00:01 *** guilhermeblanco has quit IRC
2852020-02-11T15:07:31 *** EagleTM has joined #bitcoin-core-dev
2862020-02-11T15:07:37 *** jarthur has joined #bitcoin-core-dev
2872020-02-11T15:12:03 *** EagleTM has quit IRC
2882020-02-11T15:12:07 *** jarthur has quit IRC
2892020-02-11T15:14:48 *** promag has quit IRC
2902020-02-11T15:18:20 *** SAnnaBot has joined #bitcoin-core-dev
2912020-02-11T15:21:07 *** ddustin has joined #bitcoin-core-dev
2922020-02-11T15:25:15 *** ddustin has quit IRC
2932020-02-11T15:32:52 *** andrewtoth has joined #bitcoin-core-dev
2942020-02-11T15:39:51 *** jarthur has joined #bitcoin-core-dev
2952020-02-11T15:44:44 *** turbo_choo has quit IRC
2962020-02-11T15:48:17 *** mdunnio has joined #bitcoin-core-dev
2972020-02-11T15:48:57 *** goatpig has quit IRC
2982020-02-11T15:49:07 *** jonatack has quit IRC
2992020-02-11T15:57:56 *** ghost43 has quit IRC
3002020-02-11T15:58:46 *** ghost43 has joined #bitcoin-core-dev
3012020-02-11T16:04:06 *** jonatack has joined #bitcoin-core-dev
3022020-02-11T16:06:51 *** cubancorona has joined #bitcoin-core-dev
3032020-02-11T16:11:23 *** jarthur has quit IRC
3042020-02-11T16:13:43 *** goatpig has joined #bitcoin-core-dev
3052020-02-11T16:16:15 *** Highway61 has quit IRC
3062020-02-11T16:28:18 *** andrewtoth has quit IRC
3072020-02-11T16:28:40 *** andrewtoth has joined #bitcoin-core-dev
3082020-02-11T16:29:11 *** pabed____ has quit IRC
3092020-02-11T16:36:15 *** dviola has joined #bitcoin-core-dev
3102020-02-11T16:41:22 *** ghost43 has quit IRC
3112020-02-11T16:42:06 *** ghost43 has joined #bitcoin-core-dev
3122020-02-11T16:43:27 <jb55> sipa: do we know how slow passing around vector of vectors is in script eval? its the one thing I noticed when writing my own script interpreter, that can't be good for overall perf? or does it not matter much.
3132020-02-11T16:46:22 <sipa> jb55: where specifically?
3142020-02-11T16:46:35 <jb55> sipa: I'm working from memory, sec I'll look
3152020-02-11T16:48:53 <jb55> sipa: the stack, first argument to EvalScript
3162020-02-11T16:51:46 <sipa> that one is passed bt reference
3172020-02-11T16:51:51 <sipa> *by
3182020-02-11T16:52:41 <jb55> sipa: like, is vector moving contiguous chunks of memory on each operations, or just pointers to chunks?
3192020-02-11T16:52:50 <jb55> talking about the inner vector in stack
3202020-02-11T16:53:34 <sipa> that depends on the operation
3212020-02-11T16:53:45 <sipa> hard to say without a specific case to talk about
3222020-02-11T17:00:52 <jb55> I think I just misunderstood the memory layout... looks like its all points to dynamically allocated memory, so my concern wasn't really valid, modulo you could probably come up with something more cache friendly.
3232020-02-11T17:02:08 <sipa> oh, you definitely can
3242020-02-11T17:02:30 <sipa> but most stack affecting operations only happen once during script execution
3252020-02-11T17:03:03 <sipa> one crazy one is OP_ROLL that can cause a huge amount of memory operations
3262020-02-11T17:03:09 *** emilengler has quit IRC
3272020-02-11T17:04:40 *** Talkless has joined #bitcoin-core-dev
3282020-02-11T17:05:19 <jb55> but alas, consensus code. probably won't be able to make drastic changes to that just for a slight perf increase
3292020-02-11T17:14:51 <sipa> well, if it doesn't hurt it's also not worth optimizing :)
3302020-02-11T17:15:27 *** promag has joined #bitcoin-core-dev
3312020-02-11T17:19:51 *** promag has quit IRC
3322020-02-11T17:32:39 *** ddustin has joined #bitcoin-core-dev
3332020-02-11T17:40:28 *** ddustin has quit IRC
3342020-02-11T18:00:02 *** SAnnaBot has quit IRC
3352020-02-11T18:16:06 *** Zao_ has joined #bitcoin-core-dev
3362020-02-11T18:24:36 <jeremyrubin> you could imagine making everything COW non atomic shared pointers
3372020-02-11T18:25:07 <sipa> that wouldn't help with OP_ROLL actually
3382020-02-11T18:25:14 <jeremyrubin> hang on
3392020-02-11T18:28:54 *** jarthur has joined #bitcoin-core-dev
3402020-02-11T18:29:06 <jeremyrubin> had a phone call come up was going to suggest not doing this
3412020-02-11T18:49:27 <jeremyrubin> anyways my point was going to be that it would help with things like OP_PICK but not OP_ROLL because any time you're moving something it has to move a lot of pointers on the stack.
3422020-02-11T18:51:35 <jeremyrubin> doing this plus a double linked list would be the space/time tradeoff you'd want to make
3432020-02-11T18:51:53 <jeremyrubin> (maybe single works too...)
3442020-02-11T18:52:08 <jeremyrubin> Then you could detach a node and rotate it without having to do O(n) moves
3452020-02-11T18:53:01 <jeremyrubin> But, then you would have to walk the entire list for a lot of operations which could be just as bad
3462020-02-11T18:53:07 <aj> i think a deque instead of a vector would fix ROLL for very large stacks on some implementations
3472020-02-11T18:53:23 <jeremyrubin> not quite
3482020-02-11T18:53:50 <jeremyrubin> deque remove is O(N)
3492020-02-11T18:54:55 <aj> http://www.cplusplus.com/reference/deque/deque/erase/ -- only linear in remaining elements on some implementations
3502020-02-11T18:55:07 <jeremyrubin> which is the same as std::vector no?
3512020-02-11T18:55:36 <aj> it's a vector of vectors instead sometimes apparently
3522020-02-11T18:56:08 <jeremyrubin> OP_DEPTH OP_ROLL gets you the last thing on the stack (or OP_DEPTH OP_1 OP_ROLL...)
3532020-02-11T18:56:35 <jeremyrubin> aj: I mean that remove from vector is also linear in remaining elements
3542020-02-11T18:56:56 <jeremyrubin> but you can use some efficient backshifting thing IIRC
3552020-02-11T18:57:44 <jeremyrubin> The benefit of the deque is just at best a 1/2 improvement
3562020-02-11T18:57:58 *** dviola has quit IRC
3572020-02-11T18:58:00 <aj> http://www.cplusplus.com/reference/vector/vector/erase/ -- vector is always linear in subsequent elements, deque can be more efficient
3582020-02-11T18:58:15 <jeremyrubin> It's at most 1/2
3592020-02-11T18:58:54 <jeremyrubin> err I guess you're saying if it is a vector<vector<T>> then you can be better...
3602020-02-11T18:58:56 <jeremyrubin> I see
3612020-02-11T18:59:03 <jeremyrubin> depending on the bucket size
3622020-02-11T18:59:20 <aj> bucket size is a constant factor, so you ignore that with O notation
3632020-02-11T18:59:34 <aj> but probably means it's worse for every real script
3642020-02-11T18:59:40 <jeremyrubin> well ~kinda. If the bucket size is > max stack...
3652020-02-11T19:00:14 <jeremyrubin> Then for big O we can ignore, but for our intepreter we're already at the maximally bad thing
3662020-02-11T19:00:18 <jeremyrubin> Buckets are what? 128?
3672020-02-11T19:00:33 <jeremyrubin> (in normal implementations)
3682020-02-11T19:01:56 <jeremyrubin> it seems implementations vary widely
3692020-02-11T19:02:23 <jeremyrubin> something like 200 stack elements
3702020-02-11T19:02:51 <jeremyrubin> MAX_STACK_SIZE = 1000
3712020-02-11T19:08:11 <jeremyrubin> (I think it'd be better to stick with something that has more regular implementations so that there isn't divergent performance characteristics)
3722020-02-11T19:11:43 <sipa> as long as the max stack size isn't increased there is no reason to worry about any of this
3732020-02-11T19:18:00 *** sdaftuar has joined #bitcoin-core-dev
3742020-02-11T19:18:20 <sdaftuar> jeremyrubin: around?
3752020-02-11T19:18:43 <jeremyrubin> ya
3762020-02-11T19:19:05 *** kristapsk has joined #bitcoin-core-dev
3772020-02-11T19:19:26 <jeremyrubin> So I thought of a hybrid approach you might like
3782020-02-11T19:19:28 <sdaftuar> i thought it might be easier to talk about your very detailed comment here rather than go back and forth on your PR
3792020-02-11T19:19:43 <sdaftuar> first observation: you make a good point about memory blowup
3802020-02-11T19:19:43 <jeremyrubin> Keep the cache, but only store it if it is larger than 32 elements or something
3812020-02-11T19:20:01 * jeremyrubin listening mode
3822020-02-11T19:20:48 <sdaftuar> i have not quite worked through your picture examples involving N/2 parents and N/2 children yet, but i had a question for you about your linear example-
3832020-02-11T19:21:26 <jeremyrubin> ask away!
3842020-02-11T19:21:28 <sdaftuar> in the linear case, aren't we doing N^2 lookups into GetMempoolChildren, versus something much smaller if we use a cache?
3852020-02-11T19:21:43 *** DeanGuss has quit IRC
3862020-02-11T19:21:44 <sdaftuar> I think N
3872020-02-11T19:21:49 <jeremyrubin> Good question.
3882020-02-11T19:22:23 <jeremyrubin> At node M (M < N), we look at the cache below us and do (N-M) lookups
3892020-02-11T19:22:43 <sdaftuar> it's just one lookup?
3902020-02-11T19:22:54 <sdaftuar> the cache is built from bottom to top
3912020-02-11T19:22:55 <jeremyrubin> but what's the length of the cache!
3922020-02-11T19:23:13 <jeremyrubin> We need to iterate over that cache to "read it"
3932020-02-11T19:23:25 <jeremyrubin> So maybe I'm confusing you when I say lookup
3942020-02-11T19:23:26 *** cubancorona has quit IRC
3952020-02-11T19:23:32 <sdaftuar> well, it's one map lookup, and then we read N-M elements i guess
3962020-02-11T19:23:36 <jeremyrubin> Yes
3972020-02-11T19:23:41 <jeremyrubin> That's the point I'm making
3982020-02-11T19:24:00 <jeremyrubin> Reading those N - M elements also requires visiting them for de-duplication
3992020-02-11T19:24:07 <jeremyrubin> Pre epochs, this was... really bad
4002020-02-11T19:24:32 <jeremyrubin> (well in the linear case not so bad, but in general n log n to merge into our set)
4012020-02-11T19:24:41 <sdaftuar> oh right
4022020-02-11T19:24:56 <jeremyrubin> Post epochs, you just iterate and visit
4032020-02-11T19:25:02 <sdaftuar> yeah so if your point is we're already doing N^2 work in this pathological case, that doing a little more N^2 work isn't asymptotically worse
4042020-02-11T19:25:09 <sdaftuar> then maybe that's a good point
4052020-02-11T19:25:10 <jeremyrubin> We could maybe make an optimization where if you only have one child we do something smart
4062020-02-11T19:25:32 <jeremyrubin> sdaftuar: yeah that's my point
4072020-02-11T19:25:33 <sdaftuar> i wonder if we should be doing something else altogether in these pathological cases
4082020-02-11T19:25:52 <jeremyrubin> evict everything and reinsert isn't too bad
4092020-02-11T19:25:54 <sdaftuar> hmm, ok i will give this more thought, thanks for the clarification
4102020-02-11T19:26:37 <jeremyrubin> I think the case I'm concerned about most is a -> b -> c....-> {big tree of things}
4112020-02-11T19:27:09 <jeremyrubin> because if the first part is N/2 and the big tree of things is (N/2)^2, it can get kind of annoying
4122020-02-11T19:27:15 <jeremyrubin> and then you really do want a cache
4132020-02-11T19:27:50 <sdaftuar> you're saying there's a sweet spot where the memory tradeoff is worth the cpu benefit?
4142020-02-11T19:27:55 <jeremyrubin> which might be why only caching when you have more than X things not in the cache could be nice
4152020-02-11T19:28:30 <jeremyrubin> Yeah. essentially any time you are running and you trigger some traversal limit excluding things in the cache, you make a new cache entry
4162020-02-11T19:28:45 <jeremyrubin> right now we work this way, but the limit is 1
4172020-02-11T19:29:44 <jeremyrubin> you could imagine preferring to traverse until our traversal is having a poor hit rate and is big. E.g., we traversed 10000 things, but we only saw 100 things uniquely, so we should create a cache line for this sub-unit
4182020-02-11T19:30:01 <sdaftuar> if i understand you correctly -- something like this is just a constant factor benefit at best, fundamentally we're pretty screwed by pathological chains in reorged blocks, right?
4192020-02-11T19:30:11 <jeremyrubin> Yeah
4202020-02-11T19:30:28 <jeremyrubin> But we can maybe make the constants large enough so that the pathological case is bounded
4212020-02-11T19:30:34 <sdaftuar> so that is disappointing :) i mean, i feel like we need to do something just much smarter
4222020-02-11T19:30:39 <jeremyrubin> maybe goes from N^3 to N^2
4232020-02-11T19:30:50 <sdaftuar> N here is the number of transactions in a block though
4242020-02-11T19:30:56 <jeremyrubin> But overall my opinion is I expect the map lookups and insertions (using ordered or not) to dominate just not using a map
4252020-02-11T19:30:57 <sdaftuar> which is way too big for even N^2 i think
4262020-02-11T19:31:22 <jeremyrubin> Well so that's what I did the math on, or tried to
4272020-02-11T19:31:32 <jeremyrubin> smallest txn is 61 bytes
4282020-02-11T19:32:09 <sdaftuar> yeah well the memory blowup there is certainly bad, but the cpu blowup is something that is more fundamentally broken i think?
4292020-02-11T19:32:23 <sdaftuar> i mean, we can take your advice and get rid of the cache to avoid OOM
4302020-02-11T19:32:33 <jeremyrubin> also fundamentally a memory blowup implies a CPU blowup
4312020-02-11T19:32:35 <sdaftuar> but we need to rearchitect what happens on a reorg to get rid of the CPU DoS
4322020-02-11T19:32:41 <jeremyrubin> because you need to touch the memory anywasy
4332020-02-11T19:32:50 <sdaftuar> sure
4342020-02-11T19:32:54 <jeremyrubin> it only matters if the memory blowup is less than the CPU blowup
4352020-02-11T19:33:40 <jeremyrubin> But I agree
4362020-02-11T19:33:56 <jeremyrubin> We're talking about something very slow to deal with
4372020-02-11T19:35:25 <jeremyrubin> how long do we think traversal takes?
4382020-02-11T19:35:38 <jeremyrubin> Because another option is to parallelize it
4392020-02-11T19:36:22 <sdaftuar> i think maybe the best option is to evict things that have too many descendants? or come up with some lazily updating data structures
4402020-02-11T19:37:16 <sdaftuar> not sure exactly how to do either of those ideas
4412020-02-11T19:37:24 <jeremyrubin> Or maybe we run a thread which times out the reorg
4422020-02-11T19:37:32 <jeremyrubin> and evicts everything if it took too long to update
4432020-02-11T19:37:56 <jeremyrubin> E.g., optimistically this should be simple. But if it takes too long, do the dumb thing
4442020-02-11T19:38:03 <sdaftuar> the fundamental problem is that we need to get the mempool back in a consistent state, ideally with some useful fee-paying transactions, so that we can produce a new block template as quickly as possible
4452020-02-11T19:39:12 <jeremyrubin> Maybe we should spend the effort to time some "worst case" blocks?
4462020-02-11T19:39:15 <sdaftuar> so evicting everything is nice for consistency, but not really the right thing in the long run
4472020-02-11T19:39:40 <sdaftuar> yeah i will try to do that. after giving this more thought and reading your writeup, i'm not optimistic about the results
4482020-02-11T19:39:55 <jeremyrubin> sdaftuar: hence do the right thing optimistically (e.g., 10 seconds? 100 seconds?) and otherwise evict 50% and repeat?
4492020-02-11T19:39:57 <sdaftuar> but maybe you're right that we're within a constant factor of workable
4502020-02-11T19:40:11 <sdaftuar> small constant factor*
4512020-02-11T19:40:27 <jeremyrubin> (100 seconds/((1e6/61)**2)) == 370 ns
4522020-02-11T19:41:26 <jeremyrubin> but it's actual n-1*n/2 so
4532020-02-11T19:41:35 <jeremyrubin> 750 ns
4542020-02-11T19:42:59 <jeremyrubin> We can parallelize traversals (let's assume this helps us by at most a factor of 2 because of concurrency overhead)
4552020-02-11T19:43:02 <sdaftuar> if you want to be a bit more depressed, we're not bounded by the size of a block here
4562020-02-11T19:43:11 <jeremyrubin> Ah is it mempool bounded?
4572020-02-11T19:43:18 <jeremyrubin> I thought we were block bounded
4582020-02-11T19:43:37 <jeremyrubin> I guess we're updating descendents in mempool?
4592020-02-11T19:43:38 <sdaftuar> in a multi-block reorg, i think we will process a big batch of transactions in this way
4602020-02-11T19:43:43 *** vasild_ has quit IRC
4612020-02-11T19:43:53 <sdaftuar> and yes we can have an unbounded number of descendants in mempool
4622020-02-11T19:44:00 <jeremyrubin> Well in multi-block reorg we should definitely go block by block not all at once
4632020-02-11T19:44:10 <jeremyrubin> But in multi-block I guess we can then get unbounded?
4642020-02-11T19:44:17 <jeremyrubin> I thought we have a 25 limit presently?
4652020-02-11T19:44:27 <sdaftuar> the 25 limit does not apply in the case of a reorg
4662020-02-11T19:44:31 <jeremyrubin> Ah
4672020-02-11T19:44:47 *** ddustin has joined #bitcoin-core-dev
4682020-02-11T19:44:49 <jeremyrubin> So in multi block it might not be that bad to at a certain point evict everything and resubmit to mempool
4692020-02-11T19:44:51 <sdaftuar> the issue is that our main code path for accepting a new transaction to the mempool implicitly assumes no in-mempool descendants
4702020-02-11T19:45:17 *** vasild has joined #bitcoin-core-dev
4712020-02-11T19:45:22 <sdaftuar> jeremyrubin: i think conceptually that is corret
4722020-02-11T19:45:24 <jeremyrubin> because then we're at least guaranteed to not have too much N^2 stuff
4732020-02-11T19:45:39 <jeremyrubin> But it still is sucky
4742020-02-11T19:46:40 <sdaftuar> architecting it might be a bit messy, but maybe the right intuition is to build the mempool from scratch by reinserting things from disconnected blocks in-order for just as long as you need to produce a reasonable new fee-paying block
4752020-02-11T19:46:48 <sdaftuar> and then let the mining code run, and go back to inserting more stuff, etc
4762020-02-11T19:47:04 *** Highway61 has joined #bitcoin-core-dev
4772020-02-11T19:47:13 <sdaftuar> i think we should have some alternative to the whole thing hanging if we get some messy blocks reorged out, anyway
4782020-02-11T19:48:11 <jeremyrubin> I guess as a sidebar, if we know that reorging is already *yikes* I see a few paths forward for this PR: 1) drop entirely because review not worth if we're going to need to re-do it all 2) Accept, if we can show that it's better/not worse 3) Accept half and keep cache so we at least preserve the same failure modes 4) Accept both, knowing we have new/different failure modes 5) time out after 100 seconds, switch algorithms, try
4792020-02-11T19:48:12 <jeremyrubin> again for unbounded with caching?
4802020-02-11T19:48:55 <jeremyrubin> the switching between algorithms with some exponential backing on time isn't actually that dumb.
4812020-02-11T19:49:12 <sdaftuar> i think either 2/4 or 3 are the most likely outcomes IMO? but i want to do some more benchmarking to get a sense of how bad things acn be
4822020-02-11T19:49:16 <aj> a 100 second "stall" sounds horrible?
4832020-02-11T19:49:17 <jeremyrubin> Because you would need to have an attack against both the memory version and the time version which maybe we can prove is impossible
4842020-02-11T19:49:37 <jeremyrubin> aj: scylla charbidis
4852020-02-11T19:50:06 <jeremyrubin> This isn't a problem that we're introducing, the existing algorithms can already be wicked slow
4862020-02-11T19:50:28 <jeremyrubin> the 100 second switch is *in the hopes* that a different algorithm could be faster for this reorg
4872020-02-11T19:50:54 <jeremyrubin> We could measure historical reorg times (e.g., if it's 10s per block, do 20, and then switch back and forth doubling)
4882020-02-11T19:51:46 <jeremyrubin> The idea is just to time a give up point and switch to a different algorithm (for the rest of the block that is, we're still making monotonic progress)
4892020-02-11T19:53:02 <aj> if we've got a different algorithm that goes faster, seems better to do that from the start i guess
4902020-02-11T19:53:08 <jeremyrubin> aj we don't
4912020-02-11T19:53:14 <jeremyrubin> you can review the problem here
4922020-02-11T19:53:22 <jeremyrubin> #18063
4932020-02-11T19:53:23 <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
4942020-02-11T19:54:01 <jeremyrubin> The algorithms we have with or without caching have different worst cases
4952020-02-11T19:54:14 <jeremyrubin> And caching opens up to memory based attackers
4962020-02-11T19:54:32 <jeremyrubin> so short of no new magic bullet, getting rid of caching reduces attack surface to just time based DoS
4972020-02-11T19:54:33 <aj> all we really need is to from {reorged blocks} + {old mempool} to 4 to 8 megaweight of highish-value txs in a new mempool as quickly as possible
4982020-02-11T19:54:51 *** ddustin has quit IRC
4992020-02-11T19:54:52 <sdaftuar> aj: agreed
5002020-02-11T19:55:59 <jeremyrubin> we could filter the to_reorg set by feerate
5012020-02-11T19:56:37 <jeremyrubin> with a max 8 megaweight ordered map, dropping anything else
5022020-02-11T19:57:07 <jeremyrubin> Then, we could process the updates for just that max feerate list
5032020-02-11T19:58:06 <jeremyrubin> But then the descendants could still be unbounded.
5042020-02-11T19:59:51 *** jarthur_ has joined #bitcoin-core-dev
5052020-02-11T20:00:02 *** sdaftuar has quit IRC
5062020-02-11T20:00:21 <jeremyrubin> didn't even say bye :'(
5072020-02-11T20:00:25 *** sdaftuar has joined #bitcoin-core-dev
5082020-02-11T20:00:31 <jeremyrubin> ragequit
5092020-02-11T20:00:37 <aj> ragerejoin
5102020-02-11T20:00:45 <sdaftuar> maybe i quit in disgust at this problem
5112020-02-11T20:01:02 <sdaftuar> (or maybe my internet is flaky)
5122020-02-11T20:01:34 <jeremyrubin> hah
5132020-02-11T20:02:15 <jeremyrubin> Anyways... maybe I should abandon #18603 for the "fast track" and open up some more obvious mempool wins (like eliminating mapLinks)?
5142020-02-11T20:02:16 <gribble> https://github.com/bitcoin/bitcoin/issues/18603 | HTTP Error 404: Not Found
5152020-02-11T20:02:27 <jeremyrubin> #18063
5162020-02-11T20:02:29 <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
5172020-02-11T20:02:53 <jeremyrubin> It seems like it's going to take some time to ensure we're doing the right thing.
5182020-02-11T20:03:10 <aj> yay for easy wins?
5192020-02-11T20:03:14 <sdaftuar> hmm, i think if we're not getting rid of cachemap, it should be the case that your patch is strictly better. i think i need to do a little more work to determine whether removing the cache is strictly better, probably better overall but maybe not strictly better, or somehow worse
5202020-02-11T20:03:32 *** jarthur has quit IRC
5212020-02-11T20:03:35 <sdaftuar> but eg the first commit seems like a no-brainer?
5222020-02-11T20:04:01 <jeremyrubin> ok why don't I open up a new PR with just the no-brainer one?
5232020-02-11T20:04:26 <jeremyrubin> We can keep the broader discussion going on 18063
5242020-02-11T20:04:33 <sdaftuar> sure, that's fine with me
5252020-02-11T20:04:59 <jeremyrubin> And then we can keep progress up on fixing all the other hot mess in the mempool ;)
5262020-02-11T20:05:02 <aj> sdaftuar: did you get a chance to look at https://github.com/ajtowns/bitcoin/commit/43528b17e88ec5b8378c923106053561c909a7e5 ?
5272020-02-11T20:05:49 <aj> sdaftuar: does an O( peers * log(txs_announced) ) lookup to retry NOTFOUNDs
5282020-02-11T20:05:51 <sdaftuar> oh, i did look at it briefly -- my immediate reaction was a small amount of concern at iterating over all peers whenever there's a NOTFOUND
5292020-02-11T20:07:08 <sdaftuar> because we coudl get up to 100 at once, i think, in one message -- so that's like 10k map lookups?
5302020-02-11T20:07:59 <sdaftuar> if we spaced out processing though then i think that would be fine, or maybe it's fast enough as-is and i just need to benchmark it to convince myself
5312020-02-11T20:09:00 <aj> hmm, 100 is also the max in flight from a peer
5322020-02-11T20:09:36 <sdaftuar> right, that's why i figure we could get 100 at once
5332020-02-11T20:10:29 <sdaftuar> (we coudl get more from a malicious peer, but we filter out things that weren't in-flight, so 100 should be the right max)
5342020-02-11T20:10:39 <aj> txs_announced maxes out at 100k
5352020-02-11T20:10:54 <sdaftuar> oh, right
5362020-02-11T20:10:58 *** bitcoin-git has joined #bitcoin-core-dev
5372020-02-11T20:10:58 <bitcoin-git> [bitcoin] JeremyRubin opened pull request #18120: Change UpdateForDescendants to use Epochs (master...epoch-mempool-clean-split-updatefordescendants-pt1) https://github.com/bitcoin/bitcoin/pull/18120
5382020-02-11T20:10:59 *** bitcoin-git has left #bitcoin-core-dev
5392020-02-11T20:11:47 <jeremyrubin> ok feel free to review just that chunk (same as the commit from the other branch)
5402020-02-11T20:11:54 <sdaftuar> jeremyrubin: will do
5412020-02-11T20:11:59 <aj> jeremyrubin: ack
5422020-02-11T20:12:12 <aj> hmm, maybe that's ambiguous :)
5432020-02-11T20:12:17 <sdaftuar> ready for merge!
5442020-02-11T20:12:25 <jeremyrubin> lgtm
5452020-02-11T20:12:50 <jeremyrubin> sdaftuar: good catch with the grandchild it thing btw earlier
5462020-02-11T20:12:57 <jeremyrubin> We should probably have a test for that...
5472020-02-11T20:13:15 <sdaftuar> agreed, that code is definitely undertested
5482020-02-11T20:14:30 <sdaftuar> oh! i misremembered how chain limits get applied in the case of a reorg
5492020-02-11T20:15:15 <sdaftuar> so there are an unbounded number of in-mempool descendants, but there is a bound on chain limits with respect to what is in the block(s)
5502020-02-11T20:15:16 <jeremyrubin> I was just thinking more about that
5512020-02-11T20:15:19 *** owowo has quit IRC
5522020-02-11T20:15:34 <sdaftuar> so the worst-case scenarios we were talking about are not quite right
5532020-02-11T20:15:47 <jeremyrubin> The issue with the unbounded in-mempool descendants is also that the cache entries can get HUGE
5542020-02-11T20:15:55 <jeremyrubin> e.g., the entire mempool
5552020-02-11T20:15:56 <sdaftuar> yes
5562020-02-11T20:16:13 <jeremyrubin> so we should definitely get rid of the cache IMO, even if our runtime goes up
5572020-02-11T20:16:25 <jeremyrubin> because the entire mempool * N is bad
5582020-02-11T20:17:20 <jeremyrubin> like maybe even brick the network today with a few blocks bad
5592020-02-11T20:17:26 <sdaftuar> well, one alternative is to memory cap it instead?
5602020-02-11T20:17:33 <jeremyrubin> Or LRU cache
5612020-02-11T20:17:37 <sdaftuar> right
5622020-02-11T20:18:33 <jeremyrubin> IIRC the philosophy that BCash deals with this is not... awful?
5632020-02-11T20:18:43 <jeremyrubin> step 1: clone the mempool
5642020-02-11T20:18:50 <jeremyrubin> step 2: fork the reorging
5652020-02-11T20:18:54 <sdaftuar> it's starting to make more sense to me though that if what is in the mempool is bounded in some reasonable-ish way, and what gets added back from blocks is bounded in some way, that we could get comfortable with some kind of CPU bound on the combination and be comfortable dropping the cache
5662020-02-11T20:19:04 <jeremyrubin> step3: continue mining on the non-reorg chain
5672020-02-11T20:19:12 <jeremyrubin> step4; if reorg finishes, switch
5682020-02-11T20:20:02 <jeremyrubin> if the reorg never finishes then it was done by a malicious miner, so it's not economically good anyways maybe
5692020-02-11T20:20:10 <sdaftuar> not sure that really makes sense, as until we return a new block template, mining on the old chain is almost certainly what the default behavior of miners would be regardless
5702020-02-11T20:20:20 <sdaftuar> so i think our job is to make it so that we can produce a valid new block on the new chain as fast as possible
5712020-02-11T20:20:37 <jeremyrubin> Fair point
5722020-02-11T20:21:48 <jeremyrubin> I wonder if a randomized algorithm can also help here
5732020-02-11T20:21:49 *** owowo has joined #bitcoin-core-dev
5742020-02-11T20:22:01 <jeremyrubin> The attacker is exploiting some specific structures
5752020-02-11T20:22:22 <jeremyrubin> I wonder if there's an algorithm with a random order that can prevent them from exposing some of the worst case stuff
5762020-02-11T20:22:33 <jeremyrubin> but being on average much slower maybe
5772020-02-11T20:23:01 *** Talkless has quit IRC
5782020-02-11T20:25:57 *** jarthur_ has quit IRC
5792020-02-11T20:26:12 *** jarthur has joined #bitcoin-core-dev
5802020-02-11T20:38:04 *** PaulTroon has quit IRC
5812020-02-11T20:44:18 *** Guyver2 has joined #bitcoin-core-dev
5822020-02-11T20:44:45 *** bitcoin-git has joined #bitcoin-core-dev
5832020-02-11T20:44:45 <bitcoin-git> [bitcoin] hebasto opened pull request #18121: gui: Throttle GUI update pace when -reindex (master...20200211-reindex-gui) https://github.com/bitcoin/bitcoin/pull/18121
5842020-02-11T20:44:46 *** bitcoin-git has left #bitcoin-core-dev
5852020-02-11T21:00:02 *** Zao_ has quit IRC
5862020-02-11T21:00:28 *** goatpig has quit IRC
5872020-02-11T21:03:45 *** timothy has quit IRC
5882020-02-11T21:10:21 *** Highway61 has quit IRC
5892020-02-11T21:12:58 *** Victorsueca has quit IRC
5902020-02-11T21:13:19 *** Victorsueca has joined #bitcoin-core-dev
5912020-02-11T21:15:10 *** bsm1175321 has joined #bitcoin-core-dev
5922020-02-11T21:18:05 *** Khaytsus1 has joined #bitcoin-core-dev
5932020-02-11T21:18:22 *** jonatack has quit IRC
5942020-02-11T21:27:43 *** DeanGuss has joined #bitcoin-core-dev
5952020-02-11T21:27:53 *** PaulTroon has joined #bitcoin-core-dev
5962020-02-11T21:32:27 *** PaulTroon has quit IRC
5972020-02-11T21:43:42 *** jonatack has joined #bitcoin-core-dev
5982020-02-11T21:51:30 *** morcos has quit IRC
5992020-02-11T21:51:49 *** morcos has joined #bitcoin-core-dev
6002020-02-11T21:58:12 *** ddustin has joined #bitcoin-core-dev
6012020-02-11T22:09:32 *** tecnecio_ has quit IRC
6022020-02-11T22:11:09 *** ddustin has quit IRC
6032020-02-11T22:15:57 *** promag has joined #bitcoin-core-dev
6042020-02-11T22:19:31 *** michagogo has joined #bitcoin-core-dev
6052020-02-11T22:20:19 *** promag has quit IRC
6062020-02-11T22:20:46 *** bitcoin-git has joined #bitcoin-core-dev
6072020-02-11T22:20:47 <bitcoin-git> [bitcoin] theStack opened pull request #18122: rpc: update validateaddress RPCExamples to bech32 (master...20200211-rpc-update-validateaddress-rpcexamples-to-bech32) https://github.com/bitcoin/bitcoin/pull/18122
6082020-02-11T22:20:48 *** bitcoin-git has left #bitcoin-core-dev
6092020-02-11T22:28:48 *** bitcoin-git has joined #bitcoin-core-dev
6102020-02-11T22:28:48 <bitcoin-git> [bitcoin] ryanofsky opened pull request #18123: gui: Fix race in WalletModel::pollBalanceChanged (master...pr/pollbug) https://github.com/bitcoin/bitcoin/pull/18123
6112020-02-11T22:28:50 *** bitcoin-git has left #bitcoin-core-dev
6122020-02-11T22:31:14 *** filchef has quit IRC
6132020-02-11T22:33:05 *** bitcoin-git has joined #bitcoin-core-dev
6142020-02-11T22:33:05 <bitcoin-git> [bitcoin] practicalswift opened pull request #18124: init: Clarify C and C++ locale assumptions. Add locale sanity check to verify assumptions at run-time. (master...LocaleSanityCheck) https://github.com/bitcoin/bitcoin/pull/18124
6152020-02-11T22:33:16 *** bitcoin-git has left #bitcoin-core-dev
6162020-02-11T22:33:27 *** andrewtoth has quit IRC
6172020-02-11T22:33:54 *** andrewtoth has joined #bitcoin-core-dev
6182020-02-11T22:36:10 *** dviola has joined #bitcoin-core-dev
6192020-02-11T23:00:14 *** mol has joined #bitcoin-core-dev
6202020-02-11T23:03:23 *** Highway61 has joined #bitcoin-core-dev
6212020-02-11T23:07:28 *** DeanGuss has quit IRC
6222020-02-11T23:07:50 *** DeanGuss has joined #bitcoin-core-dev
6232020-02-11T23:09:25 *** jcoe has quit IRC
6242020-02-11T23:10:33 *** mdunnio has quit IRC
6252020-02-11T23:15:17 *** Guyver2 has quit IRC
6262020-02-11T23:18:54 *** EagleTM has joined #bitcoin-core-dev
6272020-02-11T23:43:13 *** hirish_ has quit IRC
6282020-02-11T23:56:59 *** Zenton has quit IRC