12020-02-06T00:00:03 *** ggainey1 has quit IRC
22020-02-06T00:04:35 *** spinza has quit IRC
32020-02-06T00:10:33 *** manantial has quit IRC
42020-02-06T00:14:21 *** ccdle12_ has joined #bitcoin-core-dev
52020-02-06T00:15:11 *** PaulTroon has joined #bitcoin-core-dev
62020-02-06T00:16:05 *** schmidty_ has joined #bitcoin-core-dev
72020-02-06T00:16:23 *** nijynot has quit IRC
82020-02-06T00:17:07 *** paracyst has joined #bitcoin-core-dev
92020-02-06T00:18:06 *** cfields_ has joined #bitcoin-core-dev
102020-02-06T00:19:22 *** exhoplex has joined #bitcoin-core-dev
112020-02-06T00:19:38 *** wxss_ has joined #bitcoin-core-dev
122020-02-06T00:19:59 *** PaulTroon has quit IRC
132020-02-06T00:20:13 *** AaronvanW has quit IRC
142020-02-06T00:21:22 *** ccdle12_ has quit IRC
152020-02-06T00:21:28 *** ccdle12 has quit IRC
162020-02-06T00:21:28 *** schmidty has quit IRC
172020-02-06T00:21:29 *** nirved has quit IRC
182020-02-06T00:21:29 *** paracyst_ has quit IRC
192020-02-06T00:21:29 *** CubicEarth has quit IRC
202020-02-06T00:21:29 *** cfields has quit IRC
212020-02-06T00:21:29 *** spaced0ut has quit IRC
222020-02-06T00:21:29 *** BlueMatt has quit IRC
232020-02-06T00:21:30 *** exho has quit IRC
242020-02-06T00:21:30 *** ccook has quit IRC
252020-02-06T00:21:30 *** wxss has quit IRC
262020-02-06T00:21:30 *** schmidty_ is now known as schmidty
272020-02-06T00:22:27 *** ccook has joined #bitcoin-core-dev
282020-02-06T00:22:31 *** BlueMatt has joined #bitcoin-core-dev
292020-02-06T00:23:17 *** CubicEarth has joined #bitcoin-core-dev
302020-02-06T00:23:31 *** nirved has joined #bitcoin-core-dev
312020-02-06T00:24:30 *** arik__ has quit IRC
322020-02-06T00:24:31 *** fanquake has quit IRC
332020-02-06T00:24:47 *** arik__ has joined #bitcoin-core-dev
342020-02-06T00:25:01 *** pkr has joined #bitcoin-core-dev
352020-02-06T00:25:01 *** wallet42 has quit IRC
362020-02-06T00:25:16 *** eragmus has quit IRC
372020-02-06T00:25:17 *** petezz4 has quit IRC
382020-02-06T00:25:18 *** fjahr has quit IRC
392020-02-06T00:25:19 *** Lexyon___ has quit IRC
402020-02-06T00:25:19 *** amiti has quit IRC
412020-02-06T00:25:21 *** francisco_ has quit IRC
422020-02-06T00:25:21 *** neatnik has quit IRC
432020-02-06T00:25:23 *** Lightsword has quit IRC
442020-02-06T00:25:25 *** elichai2 has quit IRC
452020-02-06T00:25:25 *** nejon has quit IRC
462020-02-06T00:25:27 *** fjahr has joined #bitcoin-core-dev
472020-02-06T00:25:32 *** petezz4 has joined #bitcoin-core-dev
482020-02-06T00:25:34 *** francisco_ has joined #bitcoin-core-dev
492020-02-06T00:25:34 *** Lexyon___ has joined #bitcoin-core-dev
502020-02-06T00:25:41 *** eragmus has joined #bitcoin-core-dev
512020-02-06T00:25:42 *** Lightsword has joined #bitcoin-core-dev
522020-02-06T00:25:46 *** neatnik has joined #bitcoin-core-dev
532020-02-06T00:25:47 *** amiti has joined #bitcoin-core-dev
542020-02-06T00:25:48 *** wallet42 has joined #bitcoin-core-dev
552020-02-06T00:25:50 *** emzy has quit IRC
562020-02-06T00:26:14 *** elichai2 has joined #bitcoin-core-dev
572020-02-06T00:26:18 *** fanquake has joined #bitcoin-core-dev
582020-02-06T00:27:08 *** nejon has joined #bitcoin-core-dev
592020-02-06T00:27:21 *** ccdle12 has joined #bitcoin-core-dev
602020-02-06T00:27:29 *** helo has quit IRC
612020-02-06T00:27:37 *** helo has joined #bitcoin-core-dev
622020-02-06T00:27:48 *** ccdle12 has quit IRC
632020-02-06T00:28:02 *** ccdle12 has joined #bitcoin-core-dev
642020-02-06T00:28:10 *** emzy has joined #bitcoin-core-dev
652020-02-06T00:29:55 *** pkr has quit IRC
662020-02-06T00:30:38 *** real_or_random has quit IRC
672020-02-06T00:31:00 *** real_or_random has joined #bitcoin-core-dev
682020-02-06T00:48:12 *** furkanmustafa has joined #bitcoin-core-dev
692020-02-06T01:02:16 *** ccdle12 has quit IRC
702020-02-06T01:10:41 *** cornfeedhobo has quit IRC
712020-02-06T01:12:35 *** promag has quit IRC
722020-02-06T01:13:11 *** cornfeedhobo has joined #bitcoin-core-dev
732020-02-06T01:40:43 <luke-jr> fjahr: do we need #17843 in 0.19?
742020-02-06T01:40:48 <gribble> https://github.com/bitcoin/bitcoin/issues/17843 | wallet: Reset reused transactions cache by fjahr · Pull Request #17843 · bitcoin/bitcoin · GitHub
752020-02-06T02:06:21 *** hex17or has joined #bitcoin-core-dev
762020-02-06T02:12:21 *** francisco_ has quit IRC
772020-02-06T02:13:12 *** spinza has joined #bitcoin-core-dev
782020-02-06T02:17:48 *** Highway61 has quit IRC
792020-02-06T02:21:27 *** kristapsk has quit IRC
802020-02-06T02:21:40 *** kristapsk has joined #bitcoin-core-dev
812020-02-06T02:26:34 *** Highway61 has joined #bitcoin-core-dev
822020-02-06T02:31:31 *** Highway61 has quit IRC
832020-02-06T02:54:15 *** charlesz has joined #bitcoin-core-dev
842020-02-06T03:00:01 *** furkanmustafa has quit IRC
852020-02-06T03:01:13 *** abrissbirne has joined #bitcoin-core-dev
862020-02-06T03:04:41 *** abrissbi1ne has quit IRC
872020-02-06T03:08:10 *** charlesz has quit IRC
882020-02-06T03:17:49 *** ToBeFree has joined #bitcoin-core-dev
892020-02-06T03:18:13 *** ToBeFree is now known as Guest21723
902020-02-06T03:47:29 *** felixfoertsch has joined #bitcoin-core-dev
912020-02-06T03:48:21 *** felixfoertsch23 has quit IRC
922020-02-06T03:50:07 *** amiller has joined #bitcoin-core-dev
932020-02-06T03:57:59 *** pkr has joined #bitcoin-core-dev
942020-02-06T03:59:59 *** bitcoin-git has joined #bitcoin-core-dev
952020-02-06T03:59:59 <bitcoin-git> [bitcoin] fanquake opened pull request #18081: test: set a name for CI Docker containers (master...name_ci_docker_containers) https://github.com/bitcoin/bitcoin/pull/18081
962020-02-06T04:00:00 *** bitcoin-git has left #bitcoin-core-dev
972020-02-06T04:16:21 *** PaulTroon has joined #bitcoin-core-dev
982020-02-06T04:21:23 *** PaulTroon has quit IRC
992020-02-06T04:31:21 *** promag has joined #bitcoin-core-dev
1002020-02-06T04:32:50 *** pkr has quit IRC
1012020-02-06T04:41:33 *** bitcoin-git has joined #bitcoin-core-dev
1022020-02-06T04:41:33 <bitcoin-git> [bitcoin] fanquake opened pull request #18082: logging: enable thread_local usage on macOS (master...macos_thread_local) https://github.com/bitcoin/bitcoin/pull/18082
1032020-02-06T04:41:44 *** bitcoin-git has left #bitcoin-core-dev
1042020-02-06T04:44:43 *** turbo_choo has quit IRC
1052020-02-06T04:56:55 *** turbo_choo has joined #bitcoin-core-dev
1062020-02-06T04:57:57 *** Eagle[TM] has joined #bitcoin-core-dev
1072020-02-06T05:00:03 *** EagleTM has quit IRC
1082020-02-06T05:14:43 *** sipa has quit IRC
1092020-02-06T05:16:21 *** sipa has joined #bitcoin-core-dev
1102020-02-06T05:23:56 *** bitcoin-git has joined #bitcoin-core-dev
1112020-02-06T05:23:57 <bitcoin-git> [bitcoin] luke-jr opened pull request #18083: [0.19] wallet: Reset reused transactions cache (0.19...bugfix_reused_tx_cache-0.19.1) https://github.com/bitcoin/bitcoin/pull/18083
1122020-02-06T05:23:58 *** bitcoin-git has left #bitcoin-core-dev
1132020-02-06T05:29:51 *** fox2p has quit IRC
1142020-02-06T05:34:24 *** fox2p has joined #bitcoin-core-dev
1152020-02-06T05:42:46 *** ppisati has quit IRC
1162020-02-06T05:49:23 *** ppisati has joined #bitcoin-core-dev
1172020-02-06T05:57:55 *** r8921039 has joined #bitcoin-core-dev
1182020-02-06T05:58:56 *** DaleBewan has joined #bitcoin-core-dev
1192020-02-06T06:00:02 *** Guest21723 has quit IRC
1202020-02-06T06:06:22 *** DaleBewan has quit IRC
1212020-02-06T06:06:58 *** r8921039 has quit IRC
1222020-02-06T06:09:05 *** r8921039_ has joined #bitcoin-core-dev
1232020-02-06T06:11:58 *** gkrizek has quit IRC
1242020-02-06T06:13:42 *** r8921039_ has quit IRC
1252020-02-06T06:15:47 *** r8921039 has joined #bitcoin-core-dev
1262020-02-06T06:17:52 *** PaulTroon has joined #bitcoin-core-dev
1272020-02-06T06:18:37 *** Cotillion has joined #bitcoin-core-dev
1282020-02-06T06:20:42 *** r8921039 has quit IRC
1292020-02-06T06:21:51 *** r8921039 has joined #bitcoin-core-dev
1302020-02-06T06:22:35 *** PaulTroon has quit IRC
1312020-02-06T06:23:37 *** sturles has quit IRC
1322020-02-06T06:23:37 *** brikk has quit IRC
1332020-02-06T06:23:44 *** brikk has joined #bitcoin-core-dev
1342020-02-06T06:24:05 *** sturles has joined #bitcoin-core-dev
1352020-02-06T06:24:06 *** sturles has joined #bitcoin-core-dev
1362020-02-06T06:26:32 *** r8921039 has quit IRC
1372020-02-06T06:29:27 *** r8921039 has joined #bitcoin-core-dev
1382020-02-06T06:30:36 *** bitcoin-git has joined #bitcoin-core-dev
1392020-02-06T06:30:37 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8a56f79d4912...4d211c8da112
1402020-02-06T06:30:37 <bitcoin-git> bitcoin/master acd644b fanquake: build: remove --large-address-aware linker flag
1412020-02-06T06:30:38 <bitcoin-git> bitcoin/master 4d211c8 fanquake: Merge #18003: build: remove --large-address-aware linker flag
1422020-02-06T06:30:40 *** bitcoin-git has left #bitcoin-core-dev
1432020-02-06T06:30:56 *** bitcoin-git has joined #bitcoin-core-dev
1442020-02-06T06:30:56 <bitcoin-git> [bitcoin] fanquake merged pull request #18003: build: remove --large-address-aware linker flag (master...configure_large_address_aware) https://github.com/bitcoin/bitcoin/pull/18003
1452020-02-06T06:30:57 *** bitcoin-git has left #bitcoin-core-dev
1462020-02-06T06:34:07 *** r8921039 has quit IRC
1472020-02-06T06:39:28 *** r8921039 has joined #bitcoin-core-dev
1482020-02-06T06:41:54 *** kristapsk has quit IRC
1492020-02-06T06:42:55 *** r8921039_ has joined #bitcoin-core-dev
1502020-02-06T06:44:09 *** bitcoin-git has joined #bitcoin-core-dev
1512020-02-06T06:44:10 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4d211c8da112...23fab1a3dfe6
1522020-02-06T06:44:11 <bitcoin-git> bitcoin/master acf8abc João Barbosa: gui: Fix unintialized WalletView::progressDialog
1532020-02-06T06:44:11 <bitcoin-git> bitcoin/master 23fab1a fanquake: Merge #18062: gui: Fix unintialized WalletView::progressDialog
1542020-02-06T06:44:12 *** bitcoin-git has left #bitcoin-core-dev
1552020-02-06T06:44:13 *** r8921039 has quit IRC
1562020-02-06T06:44:30 *** bitcoin-git has joined #bitcoin-core-dev
1572020-02-06T06:44:30 <bitcoin-git> [bitcoin] fanquake merged pull request #18062: gui: Fix unintialized WalletView::progressDialog (master...2020-02-fix-unitialized-progressDialog) https://github.com/bitcoin/bitcoin/pull/18062
1582020-02-06T06:44:31 *** bitcoin-git has left #bitcoin-core-dev
1592020-02-06T06:47:12 *** r8921039_ has quit IRC
1602020-02-06T07:09:04 *** goatpig has joined #bitcoin-core-dev
1612020-02-06T07:19:50 *** r8921039_ has joined #bitcoin-core-dev
1622020-02-06T07:20:18 *** manantial has joined #bitcoin-core-dev
1632020-02-06T07:24:33 *** r8921039_ has quit IRC
1642020-02-06T07:28:32 *** r8921039 has joined #bitcoin-core-dev
1652020-02-06T07:29:26 *** r8921039_ has joined #bitcoin-core-dev
1662020-02-06T07:32:58 *** r8921039 has quit IRC
1672020-02-06T07:33:59 *** r8921039_ has quit IRC
1682020-02-06T07:42:42 *** PaulTroon has joined #bitcoin-core-dev
1692020-02-06T07:44:23 *** Eagle[TM] has quit IRC
1702020-02-06T07:44:54 *** r8921039 has joined #bitcoin-core-dev
1712020-02-06T07:49:00 <goatpig> hello
1722020-02-06T07:49:06 <goatpig> what's the current dust limit?
1732020-02-06T07:49:37 *** r8921039 has quit IRC
1742020-02-06T07:54:34 *** r8921039 has joined #bitcoin-core-dev
1752020-02-06T07:58:36 *** r8921039 has quit IRC
1762020-02-06T08:00:48 *** r8921039 has joined #bitcoin-core-dev
1772020-02-06T08:01:19 *** Highway61 has joined #bitcoin-core-dev
1782020-02-06T08:05:55 *** r8921039 has quit IRC
1792020-02-06T08:05:58 *** Highway61 has quit IRC
1802020-02-06T08:07:06 *** r8921039 has joined #bitcoin-core-dev
1812020-02-06T08:10:00 *** promag has quit IRC
1822020-02-06T08:12:07 *** r8921039 has quit IRC
1832020-02-06T08:14:05 *** michagogo has quit IRC
1842020-02-06T08:40:12 *** r8921039 has joined #bitcoin-core-dev
1852020-02-06T08:44:47 *** r8921039 has quit IRC
1862020-02-06T08:47:24 *** promag has joined #bitcoin-core-dev
1872020-02-06T08:52:09 *** promag has quit IRC
1882020-02-06T09:00:02 *** Cotillion has quit IRC
1892020-02-06T09:00:33 *** r8921039 has joined #bitcoin-core-dev
1902020-02-06T09:01:37 *** promag has joined #bitcoin-core-dev
1912020-02-06T09:01:57 *** promag_ has joined #bitcoin-core-dev
1922020-02-06T09:03:43 *** ghost43 has quit IRC
1932020-02-06T09:03:45 *** ghost43_ has joined #bitcoin-core-dev
1942020-02-06T09:05:27 *** r8921039 has quit IRC
1952020-02-06T09:12:13 *** r8921039 has joined #bitcoin-core-dev
1962020-02-06T09:16:52 *** r8921039 has quit IRC
1972020-02-06T09:18:08 *** shaunm has joined #bitcoin-core-dev
1982020-02-06T09:18:12 *** bitcoin-git has joined #bitcoin-core-dev
1992020-02-06T09:18:13 <bitcoin-git> [bitcoin] promag opened pull request #18084: 0.19: gui: Fix unintialized WalletView::progressDialog (0.19...2020-02-backport-18062) https://github.com/bitcoin/bitcoin/pull/18084
2002020-02-06T09:18:13 *** bitcoin-git has left #bitcoin-core-dev
2012020-02-06T09:30:38 *** r8921039 has joined #bitcoin-core-dev
2022020-02-06T09:35:13 *** r8921039 has quit IRC
2032020-02-06T09:38:23 *** timothy has joined #bitcoin-core-dev
2042020-02-06T10:25:26 *** andrewtoth_ has joined #bitcoin-core-dev
2052020-02-06T10:27:43 *** andrewtoth has quit IRC
2062020-02-06T10:30:32 *** timothy has quit IRC
2072020-02-06T10:31:34 *** AaronvanW has joined #bitcoin-core-dev
2082020-02-06T10:34:20 *** timothy has joined #bitcoin-core-dev
2092020-02-06T10:34:47 *** belcher has quit IRC
2102020-02-06T10:38:21 <jonasschnelli> goatpig: see DUST_RELAY_TX_FEE
2112020-02-06T10:38:30 <jonasschnelli> and -dustrelayfee= config value
2122020-02-06T10:38:57 <jonasschnelli> it's default is currently 3000sats in master AFAIK
2132020-02-06T10:39:32 <jonasschnelli> 3000sats/kB to be more precise
2142020-02-06T10:41:13 *** mryandao has quit IRC
2152020-02-06T10:43:11 *** mryandao has joined #bitcoin-core-dev
2162020-02-06T10:46:06 *** mryandao has quit IRC
2172020-02-06T10:48:03 *** mryandao has joined #bitcoin-core-dev
2182020-02-06T11:00:22 *** promag_ has quit IRC
2192020-02-06T11:00:37 *** promag_ has joined #bitcoin-core-dev
2202020-02-06T11:03:57 *** Cleora81Stehr has joined #bitcoin-core-dev
2212020-02-06T11:16:43 *** Cleora81Stehr has quit IRC
2222020-02-06T11:25:04 *** belcher has joined #bitcoin-core-dev
2232020-02-06T11:31:34 <wumpus> promag: I'm not aware of any plans to bump the minimum qt version again, if you want to propose that feel free to open a PR, make sure you check for various linux distributions, I don't think 5.10+ is realistic as ubuntu bionic (18.04) still has 5.9 and no doubt others
2242020-02-06T11:35:07 *** PaulTroon has quit IRC
2252020-02-06T11:47:48 *** jonatack has quit IRC
2262020-02-06T11:53:59 *** EagleTM has joined #bitcoin-core-dev
2272020-02-06T11:55:48 *** PaulTroon has joined #bitcoin-core-dev
2282020-02-06T12:00:01 *** shaunm has quit IRC
2292020-02-06T12:00:22 *** Liliaceae has quit IRC
2302020-02-06T12:08:28 *** Highway61 has joined #bitcoin-core-dev
2312020-02-06T12:11:24 *** bitcoin-git has joined #bitcoin-core-dev
2322020-02-06T12:11:24 <bitcoin-git> [bitcoin] laanwj closed pull request #17807: net: Remove unnecessary portability typedef (master...akh_socket_arg_type) https://github.com/bitcoin/bitcoin/pull/17807
2332020-02-06T12:11:25 *** bitcoin-git has left #bitcoin-core-dev
2342020-02-06T12:13:33 *** Highway61 has quit IRC
2352020-02-06T12:16:18 *** ccdle12 has joined #bitcoin-core-dev
2362020-02-06T12:18:53 *** ghost43_ has quit IRC
2372020-02-06T12:19:54 *** ghost43 has joined #bitcoin-core-dev
2382020-02-06T12:20:04 *** bitcoin-git has joined #bitcoin-core-dev
2392020-02-06T12:20:04 <bitcoin-git> [bitcoin] laanwj reopened pull request #16995: Fix gcc 9 warnings (master...2019_09_resolve_gcc_warnings) https://github.com/bitcoin/bitcoin/pull/16995
2402020-02-06T12:20:05 *** bitcoin-git has left #bitcoin-core-dev
2412020-02-06T12:28:40 *** sipsorcery has quit IRC
2422020-02-06T12:28:54 *** sipsorcery has joined #bitcoin-core-dev
2432020-02-06T12:30:14 *** Highway61 has joined #bitcoin-core-dev
2442020-02-06T12:31:51 *** r8921039 has joined #bitcoin-core-dev
2452020-02-06T12:32:26 *** jonatack has joined #bitcoin-core-dev
2462020-02-06T12:32:32 *** r8921039 has quit IRC
2472020-02-06T12:34:31 *** Highway61 has quit IRC
2482020-02-06T12:37:13 *** jonatack has quit IRC
2492020-02-06T12:37:14 *** afk11 has quit IRC
2502020-02-06T12:37:40 *** afk11 has joined #bitcoin-core-dev
2512020-02-06T12:44:34 *** ccdle12 has quit IRC
2522020-02-06T12:45:10 *** bitcoin-git has joined #bitcoin-core-dev
2532020-02-06T12:45:10 <bitcoin-git> [bitcoin] laanwj closed pull request #18053: Silence "redundant move in return statement" warning on GCC9 (master...gcc9-silence-redundant-move) https://github.com/bitcoin/bitcoin/pull/18053
2542020-02-06T12:45:21 *** bitcoin-git has left #bitcoin-core-dev
2552020-02-06T12:49:44 *** wimpunk has joined #bitcoin-core-dev
2562020-02-06T12:49:50 *** Highway61 has joined #bitcoin-core-dev
2572020-02-06T13:12:54 *** promag has quit IRC
2582020-02-06T13:13:18 *** promag_ has quit IRC
2592020-02-06T13:13:40 *** amiti has quit IRC
2602020-02-06T13:14:45 *** promag_ has joined #bitcoin-core-dev
2612020-02-06T13:19:03 *** aerth has quit IRC
2622020-02-06T13:19:09 *** bitcoin-git has joined #bitcoin-core-dev
2632020-02-06T13:19:10 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/755b0734bb50...7d53995ff2b4
2642020-02-06T13:19:11 <bitcoin-git> bitcoin/0.19 b4e5363 João Barbosa: gui: Fix unintialized WalletView::progressDialog
2652020-02-06T13:19:12 <bitcoin-git> bitcoin/0.19 7d53995 fanquake: Merge #18084: 0.19: gui: Fix unintialized WalletView::progressDialog
2662020-02-06T13:19:14 *** bitcoin-git has left #bitcoin-core-dev
2672020-02-06T13:19:25 *** promag_ has quit IRC
2682020-02-06T13:19:29 *** bitcoin-git has joined #bitcoin-core-dev
2692020-02-06T13:19:29 <bitcoin-git> [bitcoin] fanquake merged pull request #18084: 0.19: gui: Fix unintialized WalletView::progressDialog (0.19...2020-02-backport-18062) https://github.com/bitcoin/bitcoin/pull/18084
2702020-02-06T13:19:30 *** bitcoin-git has left #bitcoin-core-dev
2712020-02-06T13:19:32 *** vfP56jSe has quit IRC
2722020-02-06T13:19:32 *** arik__ has quit IRC
2732020-02-06T13:20:07 *** Isthmus has quit IRC
2742020-02-06T13:24:53 *** petezz4 has quit IRC
2752020-02-06T14:01:00 *** aerth has joined #bitcoin-core-dev
2762020-02-06T14:01:02 *** amiti has joined #bitcoin-core-dev
2772020-02-06T14:02:03 *** petezz4 has joined #bitcoin-core-dev
2782020-02-06T14:04:59 *** ccdle12 has joined #bitcoin-core-dev
2792020-02-06T14:05:23 *** Isthmus has joined #bitcoin-core-dev
2802020-02-06T14:06:56 <MarcoFalke> #proposedmeetingtopic (short topic) Remove i686 Linux download link from bitcoincore website
2812020-02-06T14:07:26 *** arik__ has joined #bitcoin-core-dev
2822020-02-06T14:08:19 *** ar1el has joined #bitcoin-core-dev
2832020-02-06T14:08:23 *** afk11 has quit IRC
2842020-02-06T14:09:05 *** vfP56jSe has joined #bitcoin-core-dev
2852020-02-06T14:09:27 *** afk11 has joined #bitcoin-core-dev
2862020-02-06T14:10:06 *** timothy has quit IRC
2872020-02-06T14:15:57 *** jonatack has joined #bitcoin-core-dev
2882020-02-06T14:25:57 *** gkrizek has joined #bitcoin-core-dev
2892020-02-06T14:27:18 *** setpill has joined #bitcoin-core-dev
2902020-02-06T14:29:16 *** timothy has joined #bitcoin-core-dev
2912020-02-06T14:31:41 *** promag has joined #bitcoin-core-dev
2922020-02-06T14:36:19 *** promag has quit IRC
2932020-02-06T14:38:03 *** ccdle12 has quit IRC
2942020-02-06T14:40:06 *** promag has joined #bitcoin-core-dev
2952020-02-06T14:41:30 <promag> wumpus: sure, too soon then, lets see next year
2962020-02-06T14:45:14 *** ccdle12 has joined #bitcoin-core-dev
2972020-02-06T14:51:58 *** ccdle12 has quit IRC
2982020-02-06T14:58:43 *** EagleTM has quit IRC
2992020-02-06T15:00:02 *** wimpunk has quit IRC
3002020-02-06T15:00:39 *** EagleTM has joined #bitcoin-core-dev
3012020-02-06T15:01:44 *** timothy has quit IRC
3022020-02-06T15:02:27 *** nijynot has joined #bitcoin-core-dev
3032020-02-06T15:05:02 *** timothy has joined #bitcoin-core-dev
3042020-02-06T15:06:28 *** Guyver2 has joined #bitcoin-core-dev
3052020-02-06T15:13:38 *** wumpus has quit IRC
3062020-02-06T15:19:16 *** wumpus has joined #bitcoin-core-dev
3072020-02-06T15:23:23 *** nijynot has quit IRC
3082020-02-06T15:26:22 *** spaced0ut has joined #bitcoin-core-dev
3092020-02-06T15:48:07 *** llamma1 has joined #bitcoin-core-dev
3102020-02-06T15:50:43 *** EagleTM has quit IRC
3112020-02-06T16:05:49 *** goatpig has quit IRC
3122020-02-06T16:08:14 *** mdunnio has joined #bitcoin-core-dev
3132020-02-06T16:10:33 *** shesek has quit IRC
3142020-02-06T16:11:01 *** shesek has joined #bitcoin-core-dev
3152020-02-06T16:13:43 *** Talkless has joined #bitcoin-core-dev
3162020-02-06T16:16:06 *** rafalcpp has joined #bitcoin-core-dev
3172020-02-06T16:22:15 *** jonatack has quit IRC
3182020-02-06T16:28:33 *** emzy has quit IRC
3192020-02-06T16:28:33 *** emzy has joined #bitcoin-core-dev
3202020-02-06T16:37:43 *** gkrizek has quit IRC
3212020-02-06T16:57:43 *** rafalcpp has quit IRC
3222020-02-06T17:03:28 *** spaced0ut has quit IRC
3232020-02-06T17:04:12 *** jonatack has joined #bitcoin-core-dev
3242020-02-06T17:05:11 *** Highway61 has quit IRC
3252020-02-06T17:07:05 *** SiAnDoG__ has joined #bitcoin-core-dev
3262020-02-06T17:13:24 *** promag has quit IRC
3272020-02-06T17:21:13 *** tryphe has joined #bitcoin-core-dev
3282020-02-06T17:22:02 *** promag has joined #bitcoin-core-dev
3292020-02-06T17:22:11 *** emilengler has joined #bitcoin-core-dev
3302020-02-06T17:23:38 *** tryphe_ has quit IRC
3312020-02-06T17:26:43 *** promag has quit IRC
3322020-02-06T17:32:32 *** Highway61 has joined #bitcoin-core-dev
3332020-02-06T17:33:39 *** kcalvinalvin has quit IRC
3342020-02-06T17:34:11 *** shesek has quit IRC
3352020-02-06T17:34:52 *** kcalvinalvin has joined #bitcoin-core-dev
3362020-02-06T17:36:02 *** shesek has joined #bitcoin-core-dev
3372020-02-06T17:39:42 *** nitrow has joined #bitcoin-core-dev
3382020-02-06T17:44:36 *** promag has joined #bitcoin-core-dev
3392020-02-06T17:48:00 *** setpill has quit IRC
3402020-02-06T17:49:32 *** promag has quit IRC
3412020-02-06T17:52:07 <jonatack> Would someone kindly restart Travis for #17812
3422020-02-06T17:52:09 <gribble> https://github.com/bitcoin/bitcoin/issues/17812 | config, net, test: asmap functional tests and feature refinements by jonatack · Pull Request #17812 · bitcoin/bitcoin · GitHub
3432020-02-06T17:52:52 *** timothy has quit IRC
3442020-02-06T17:54:48 *** nitrow has quit IRC
3452020-02-06T17:59:03 *** timothy has joined #bitcoin-core-dev
3462020-02-06T18:00:02 *** llamma1 has quit IRC
3472020-02-06T18:01:18 <luke-jr> jonatack: done
3482020-02-06T18:06:35 <jonatack> luke-jr: thank you
3492020-02-06T18:07:04 *** gkrizek has joined #bitcoin-core-dev
3502020-02-06T18:09:03 *** promag has joined #bitcoin-core-dev
3512020-02-06T18:12:02 *** ar1el has quit IRC
3522020-02-06T18:14:04 *** gkrizek has quit IRC
3532020-02-06T18:14:31 *** gkrizek has joined #bitcoin-core-dev
3542020-02-06T18:18:23 *** mota1 has joined #bitcoin-core-dev
3552020-02-06T18:26:01 *** goatpig has joined #bitcoin-core-dev
3562020-02-06T18:38:35 *** zivl has joined #bitcoin-core-dev
3572020-02-06T18:51:55 *** Highway61 has quit IRC
3582020-02-06T19:00:00 <wumpus> #startmeeting
3592020-02-06T19:00:00 <lightningbot> Meeting started Thu Feb 6 19:00:00 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3602020-02-06T19:00:00 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3612020-02-06T19:00:16 <MarcoFalke> ahoy
3622020-02-06T19:00:27 <wumpus> I don't expect many people to be here today with the London conference, but we can try...
3632020-02-06T19:00:28 * BlueMatt
3642020-02-06T19:00:32 <sipsorcery> hi
3652020-02-06T19:00:42 <sipa> hi
3662020-02-06T19:00:46 <jonasschnelli> hi
3672020-02-06T19:00:46 <emilengler> hi
3682020-02-06T19:00:49 <amiti> hi
3692020-02-06T19:01:01 <hebasto> hi
3702020-02-06T19:01:09 * BlueMatt
3712020-02-06T19:01:15 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
3722020-02-06T19:01:17 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
3732020-02-06T19:01:45 <fjahr> hi
3742020-02-06T19:01:51 <wumpus> one proposed topic on https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a: Remove i686 Linux download link from bitcoincore website (MarcoFalke)
3752020-02-06T19:01:56 <aj> hi
3762020-02-06T19:01:58 <wumpus> any last minute topic proposals?
3772020-02-06T19:02:03 <jeremyrubin> hi
3782020-02-06T19:02:23 <jeremyrubin> proposed topic: mempool project update
3792020-02-06T19:02:30 <jonatack> hi
3802020-02-06T19:02:39 <wumpus> jeremyrubin: ack
3812020-02-06T19:02:41 <moneyball> hi
3822020-02-06T19:02:42 <kanzure> hi
3832020-02-06T19:02:53 <jkczyz> hi
3842020-02-06T19:02:54 <kanzure> proposed topic: more topic selection (or actually, how about topics you don't want to hear about for march)
3852020-02-06T19:02:56 <promag> hi
3862020-02-06T19:03:02 <emilengler> proposed topic: the library for #17950, even if to use a library?
3872020-02-06T19:03:05 <gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler · Pull Request #17950 · bitcoin/bitcoin · GitHub
3882020-02-06T19:03:26 *** molz_ has joined #bitcoin-core-dev
3892020-02-06T19:03:35 <wumpus> #topic High priority for review
3902020-02-06T19:04:00 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 -> 6 blockers, 1 bugfix, 6 chasing concept ACK
3912020-02-06T19:04:09 <wumpus> anything to add / remove or almost ready for merge?
3922020-02-06T19:04:48 <meshcollider> hi
3932020-02-06T19:04:59 <wumpus> hi
3942020-02-06T19:05:18 <MarcoFalke> The cs_main cs_wallet thing needs rebase and has something proposed by ryanofsky as a preparation pull request. Should these be exchanged?
3952020-02-06T19:05:48 * luke-jr glances at some chirping crickets
3962020-02-06T19:05:49 <wumpus> MarcoFalke: I suppose that makes sense, if the other one is a blocker for this one
3972020-02-06T19:05:58 <wumpus> either that or add it too
3982020-02-06T19:06:16 <MarcoFalke> #17954 is the prep I think
3992020-02-06T19:06:18 <gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
4002020-02-06T19:06:34 <jonasschnelli> half of the PR in high-prio do fail CI
4012020-02-06T19:06:51 <MarcoFalke> jonasschnelli: travis s390x?
4022020-02-06T19:07:04 <wumpus> ok, added
4032020-02-06T19:07:10 <luke-jr> maybe we should disable the s390x temporarily?
4042020-02-06T19:07:12 <ryanofsky> MarcoFalke, yes my preference would be to do 17954 first
4052020-02-06T19:07:23 <jonasschnelli> MarcoFalke: I don't know but makes people ignore CI (which is a QA issue in the long run
4062020-02-06T19:07:45 <MarcoFalke> Yes, maybe we should disable it on travis for now
4072020-02-06T19:07:51 <MarcoFalke> I do run it locally
4082020-02-06T19:08:02 <hebasto> How valuable is s390x tests?
4092020-02-06T19:08:03 * jonasschnelli think the CI should be less fragile
4102020-02-06T19:08:12 <wumpus> hebasto: big-endian testing
4112020-02-06T19:08:15 *** morcos has quit IRC
4122020-02-06T19:08:33 <MarcoFalke> jonasschnelli: travis is the only one that offers s390x native
4132020-02-06T19:08:45 <wumpus> that's basically the only reason s390x testinig is valuable
4142020-02-06T19:08:52 <luke-jr> too bad Travis doesn't have ppc64be
4152020-02-06T19:08:54 <jonasschnelli> I think its very valuable
4162020-02-06T19:08:55 <wumpus> no one runs bitcoind on that platfor mas far as I'm aware
4172020-02-06T19:09:03 *** morcos has joined #bitcoin-core-dev
4182020-02-06T19:09:07 <wumpus> so any other big-endian platform would do as well
4192020-02-06T19:09:43 <sipa> yeah, even if we expect literally noone ever to use bitcoin core in production on s390x, variety in test platforms can often expose bugs present but undetectable on other platforms
4202020-02-06T19:09:50 <MarcoFalke> I do run it, but it is through qemu
4212020-02-06T19:10:05 <MarcoFalke> sipa: It did find a bug in the tests :)
4222020-02-06T19:10:17 <sipa> MarcoFalke: the best kind of bug
4232020-02-06T19:10:25 <MarcoFalke> +1
4242020-02-06T19:10:31 <wumpus> especially for serialization changes it's very useful to test big endian correctness
4252020-02-06T19:10:31 <jonasschnelli> Maybe its not ready for a per branch update/PR base but as a manual check?
4262020-02-06T19:10:47 <jonatack> jonasschnelli: btw thank you for https://bitcoinbuilds.org. it is the first place i look for CI results.
4272020-02-06T19:11:07 <jonasschnelli> jonatack: It's running again smoothly.. but no native s390x supper...
4282020-02-06T19:11:24 <jonasschnelli> could try to get a qemu be env up. But I guess it will be too slow
4292020-02-06T19:11:51 <sipa> may be useful to run s390x qemu on master on a regular basis, but not on every PR?
4302020-02-06T19:12:04 <wumpus> power can can be big-endian as well, though, it's fairly rare (and travis doesn't offer that)
4312020-02-06T19:12:05 <jonasschnelli> +1
4322020-02-06T19:12:14 <MarcoFalke> If someone is knowledged in docker, #18016 is the problem we need fixed
4332020-02-06T19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small · Issue #18016 · bitcoin/bitcoin · GitHub
4342020-02-06T19:12:16 <wumpus> agree sipa
4352020-02-06T19:12:36 <luke-jr> wumpus: not so rare; but can't be a simple chroot :/
4362020-02-06T19:12:55 <MarcoFalke> So I think #action is to either fix #18016 or remove it and run locally?
4372020-02-06T19:12:57 <gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small · Issue #18016 · bitcoin/bitcoin · GitHub
4382020-02-06T19:13:15 <wumpus> I don't think we can fix "disk too small" so that leaves removing it for now
4392020-02-06T19:13:29 *** promag has quit IRC
4402020-02-06T19:13:55 <MarcoFalke> It can be fixed with some docker settings and restarting docker, but I don't know anything about this "docker" thing
4412020-02-06T19:14:14 <wumpus> me neither, I've always managed to avoid it
4422020-02-06T19:14:47 <MarcoFalke> There is a disk large enough in /var/snap/lxd/... on travis
4432020-02-06T19:14:57 <MarcoFalke> Anyway, next topic?
4442020-02-06T19:15:07 <wumpus> #topic Remove i686 Linux download link from bitcoincore website (MarcoFalke)
4452020-02-06T19:15:20 <wumpus> yes, let's do it
4462020-02-06T19:15:24 <jonasschnelli> ack
4472020-02-06T19:15:26 *** Highway61 has joined #bitcoin-core-dev
4482020-02-06T19:15:31 <MarcoFalke> So based on a twitter poll, a mailing list post, we only found one confrimed user of i686 #17504
4492020-02-06T19:15:33 <gribble> https://github.com/bitcoin/bitcoin/issues/17504 | Should we still ship 32-bit x86 Linux binaries? · Issue #17504 · bitcoin/bitcoin · GitHub
4502020-02-06T19:15:54 <wumpus> https://github.com/bitcoin-core/bitcoincore.org/pull/695
4512020-02-06T19:15:54 <MarcoFalke> So as a first step it could make sense to remove the i686 download link from the website
4522020-02-06T19:16:06 <emilengler> Shouldn't we wait until we don't produce any i686 anymore
4532020-02-06T19:16:29 <MarcoFalke> emilengler: Removing the link first gives everyone another chance to notice it
4542020-02-06T19:16:32 <luke-jr> ^
4552020-02-06T19:16:32 <emilengler> I think it's a better approach to add a note on the website and remove the link once the new version got released
4562020-02-06T19:16:42 <luke-jr> I'd like to be sure this doesn't turn into the Win32 situation
4572020-02-06T19:16:49 <MarcoFalke> emilengler: The i686 bin will still be uploaded for now
4582020-02-06T19:16:58 <luke-jr> the plan there afaik was simply to stop making binaries, but now we're removing the ability to even compile it
4592020-02-06T19:17:14 <MarcoFalke> luke-jr: That is not going to happen
4602020-02-06T19:17:22 <wumpus> we need to support 32 bit for self-compiles, period
4612020-02-06T19:17:24 <luke-jr> k
4622020-02-06T19:17:31 <MarcoFalke> luke-jr: We have a i686 centos build in ci, that is not going to be removed
4632020-02-06T19:17:43 <wumpus> ARM 32 bit is not dead, and neither is RISC-V 32 bit, and some others
4642020-02-06T19:18:32 <jonasschnelli> Indeed. There are a lot of Odroid in the field (Cortex A15).
4652020-02-06T19:18:37 <wumpus> I think I've been very clear everywhere that this is about the shipped binaries
4662020-02-06T19:18:49 <wumpus> for x86 32 bit
4672020-02-06T19:18:53 <luke-jr> wumpus: right, but that was true for Win32 too
4682020-02-06T19:19:23 <wumpus> win32 is really dead anyhow
4692020-02-06T19:20:11 <emilengler> The topic was to remove it from the website and nothing else. I feel this discussion drives a bit away to a more general topic about x86 in general. Could we come back to the original point?
4702020-02-06T19:20:18 <hebasto> even not all libs are available for x86
4712020-02-06T19:20:31 <luke-jr> hebasto: â
4722020-02-06T19:20:50 <harding> Removing it from the website to see if anyone complains while it's still easy to add it back makes sense to me.
4732020-02-06T19:20:50 <hebasto> see Centos 32-bit repo
4742020-02-06T19:21:20 <luke-jr> hebasto: that's too vague to mean anything to me
4752020-02-06T19:21:52 <wumpus> yes, so let's remove it from the website, but still build x86_32 binaries for 0.19.1
4762020-02-06T19:22:00 <MarcoFalke> +1
4772020-02-06T19:22:03 <luke-jr> sgtm
4782020-02-06T19:22:10 <wumpus> then for 0.20 stop building them
4792020-02-06T19:22:44 <emilengler> ack
4802020-02-06T19:22:55 <wumpus> #topic Mempool project update (jeremyrubin)
4812020-02-06T19:23:02 <jeremyrubin> hola
4822020-02-06T19:23:15 <jeremyrubin> So the first PR of the epoch mempool series has been merged
4832020-02-06T19:23:37 <wumpus> congrats!
4842020-02-06T19:23:42 <jeremyrubin> Thanks!
4852020-02-06T19:23:44 <jeremyrubin> I've opened up the next step, which gets rid of this big cache we built during reorgs
4862020-02-06T19:23:56 <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/18063
4872020-02-06T19:24:35 <jeremyrubin> Amiti's testing framework changes are making progress & seem good to go IMO
4882020-02-06T19:24:38 <wumpus> good to know
4892020-02-06T19:25:41 <jeremyrubin> It seems like there's been not too much attention on nanobench stuff, would be good to "just do it IMO" but I don't have many downstream toolchains
4902020-02-06T19:25:43 <wumpus> which PR is that?
4912020-02-06T19:25:51 <jeremyrubin> sorry scrambling for links...
4922020-02-06T19:25:57 <wumpus> (Amiti's changes, I mean)
4932020-02-06T19:25:59 <jeremyrubin> #18037
4942020-02-06T19:26:02 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
4952020-02-06T19:26:12 <jeremyrubin> and #18011
4962020-02-06T19:26:14 <gribble> https://github.com/bitcoin/bitcoin/issues/18011 | Replace current benchmarking framework with nanobench by martinus · Pull Request #18011 · bitcoin/bitcoin · GitHub
4972020-02-06T19:26:46 <jeremyrubin> Amiti has also opened up a new PR that carves out a good chunk of functionality for rebroadcasting
4982020-02-06T19:26:54 <jeremyrubin> is amiti here? I can ping her
4992020-02-06T19:26:57 <amiti> ya Im here
5002020-02-06T19:26:58 <jeremyrubin> #18037
5012020-02-06T19:27:01 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
5022020-02-06T19:27:21 *** PaulTroon has quit IRC
5032020-02-06T19:27:23 <wumpus> ok so add #18037 to high priority for review?
5042020-02-06T19:27:24 <jeremyrubin> amiti: should people be taking a look at 18037 now?
5052020-02-06T19:27:25 <amiti> #18038 is the rebroadcast subset
5062020-02-06T19:27:25 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
5072020-02-06T19:27:26 <gribble> https://github.com/bitcoin/bitcoin/issues/18038 | P2P: Mempool tracks locally submitted transactions to improve privacy by amitiuttarwar · Pull Request #18038 · bitcoin/bitcoin · GitHub
5082020-02-06T19:27:46 <jeremyrubin> Ah right sorry
5092020-02-06T19:28:07 <amiti> if 18038 builds on 18037, so if 18037 gets merged in current state then 18038 is ready for review
5102020-02-06T19:28:30 <jeremyrubin> yes so I think 18037 is hi prio and can be merged with another ack or two (it's just testing stuff)
5112020-02-06T19:28:53 <jeremyrubin> And then we can pull some ears (not yet hi-prio) for 18038
5122020-02-06T19:29:32 <jonatack> jeremyrubin: perhaps add #18044 to your mempool dashboard? https://github.com/bitcoin/bitcoin/projects/14
5132020-02-06T19:29:34 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
5142020-02-06T19:29:37 <wumpus> ok
5152020-02-06T19:29:38 <jeremyrubin> Same goes for #18063 -- once I get a reviewer or two I'd like to put it high priority so that progress can keep moving
5162020-02-06T19:29:40 <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-06T19:30:12 <jeremyrubin> is 18044 needed for package relay?
5182020-02-06T19:30:49 <jonatack> no, part of it changes the mempool, up to you
5192020-02-06T19:30:55 <jeremyrubin> is sdaftuar here and can talk more about it?
5202020-02-06T19:31:22 <jeremyrubin> I'll add it but from what I can tell this one requires a BIP to move forward?
5212020-02-06T19:31:41 <jonatack> yes, there is a wip bip draft for now
5222020-02-06T19:31:43 <sipa> i believe sdaftuar is working on one
5232020-02-06T19:32:27 <jeremyrubin> Ok great. I'll add it to the package relay track since that's mostly sdaftuar right now anyways, but I think logically it seems more on rebroadcasting
5242020-02-06T19:32:41 <jeremyrubin> amiti do you have any thoughts on that? Can you review 18044?
5252020-02-06T19:32:58 <jonatack> WIP BIP draft https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki
5262020-02-06T19:33:02 <amiti> yeah I've started taking a look, its more about initial broadcast than rebroadcast
5272020-02-06T19:33:36 <jeremyrubin> (and then I think we're good on mempool project unless anyone has any questions -- please see https://github.com/bitcoin/bitcoin/projects/14 to get references for what to review & look at)
5282020-02-06T19:34:23 *** afk11 has quit IRC
5292020-02-06T19:34:48 *** afk11 has joined #bitcoin-core-dev
5302020-02-06T19:34:56 <luke-jr> â¦
5312020-02-06T19:35:06 <jeremyrubin> ?
5322020-02-06T19:35:16 <wumpus> #topic the library for #17950 (emilengler)
5332020-02-06T19:35:18 <gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler · Pull Request #17950 · bitcoin/bitcoin · GitHub
5342020-02-06T19:35:33 <wumpus> I *really* do not like introducing a dependency for this
5352020-02-06T19:35:35 <emilengler> thanks
5362020-02-06T19:35:42 <emilengler> I agree with wumpus
5372020-02-06T19:36:00 <jonasschnelli> Yes. Please no dependency for a gimmick feature
5382020-02-06T19:36:05 <wumpus> it's somewhat nice to display a measure of password strength (if people can ever agree on one), but it's not worth large changes to our build process for
5392020-02-06T19:36:09 <sipa> i feel that anything that self-written is going to be too ad-hoc to be useful
5402020-02-06T19:36:10 <wumpus> exactly
5412020-02-06T19:36:10 <jonasschnelli> It is already handholding...
5422020-02-06T19:36:24 <sipa> so either it's depending on a well-maintained library, or we don't do it at all
5432020-02-06T19:36:24 <jeremyrubin> I think i'd rather just *suggest* a strong password
5442020-02-06T19:36:25 <luke-jr> there's conceptual problems in the first place
5452020-02-06T19:36:47 <wumpus> maybe it's a bad idea in the first place, thinking of it, we don't want to encourage a specific kind of password scheme, this only reduces security
5462020-02-06T19:36:52 <luke-jr> this shouldn't be a "strong" password, it should be a memorable one
5472020-02-06T19:36:56 <jeremyrubin> e.g., here are 12 random words
5482020-02-06T19:37:04 <wumpus> that, too
5492020-02-06T19:37:13 <luke-jr> encrypted wallets won't stop malware, just little brother
5502020-02-06T19:37:30 <luke-jr> the risk of losing access outweighs the benefits of a string passphrase here
5512020-02-06T19:37:32 <jonasschnelli> Can we just have a short text to help people do the right thing? Or a link (less likely)?
5522020-02-06T19:37:32 <wumpus> it's not a brainwallet, not the entire internet can attack it, the security needed depends on how secure the wallet file is kept
5532020-02-06T19:37:46 <gwillen> it is very hard to make a password-strength indicator that is not at least sometimes very misleading
5542020-02-06T19:37:56 <wumpus> making it too strong might cause people to forgt it
5552020-02-06T19:38:00 <MarcoFalke> I think more people have lost coins due to forgetting too strong passwords than first getting their wallet stolen, but not their password, and then got their password cracked offline
5562020-02-06T19:38:02 <wumpus> which is much worse
5572020-02-06T19:38:11 <jonasschnelli> Indeed
5582020-02-06T19:38:11 <sipa> gwillen: zxcvbn seems pretty sophisticated already
5592020-02-06T19:38:14 <sipa> *actually
5602020-02-06T19:38:15 <wumpus> MarcoFalke: agree
5612020-02-06T19:38:30 <sipa> it's very hard because users probably don't have a good intuition for what the requirements are
5622020-02-06T19:38:30 <wumpus> what would be nice is a feature that makes people write down their HD seed
5632020-02-06T19:38:39 <wumpus> aid recovery, not make it worse
5642020-02-06T19:38:45 <jeremyrubin> (I'm actually recovering a wallet for someone who forgot their password, so I agree)
5652020-02-06T19:38:45 <MarcoFalke> yeah
5662020-02-06T19:39:01 <wumpus> a lot of people lose their coins either by losing their wallet or paspphrase
5672020-02-06T19:39:01 <sipa> if the wallet.dat file leaking is an attack vector you want to protect against, the password needs to be *far* stronger than common recommendations for website login passwords
5682020-02-06T19:39:03 <jonasschnelli> wumpus: you mean adding BIP39 support?
5692020-02-06T19:39:06 <jeremyrubin> * attempting that is, let's hope the fragments are good enough
5702020-02-06T19:39:28 <gwillen> sipa: as such things go, it's pretty sophisticated, but it does not know your dog's name, or your mother's maiden name, or your birthday, or your favorite book you're quoting from, or any of a number of stupid things users do that lower effective entropy
5712020-02-06T19:39:40 <gwillen> while not lowering apparent entropy relative to the tool's model
5722020-02-06T19:39:41 <luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
5732020-02-06T19:39:45 <wumpus> jonasschnelli: yes I suppose
5742020-02-06T19:39:53 <sipa> gwillen: of course it can only give an upper bound
5752020-02-06T19:40:00 <gwillen> it's never presented that way, though
5762020-02-06T19:40:12 <sipa> anyway
5772020-02-06T19:40:25 <sipa> i'm in favor of just not pursuing that feature
5782020-02-06T19:40:31 <jeremyrubin> luke-jr: disagree with those priors
5792020-02-06T19:40:35 <sipa> it's too hard to do right
5802020-02-06T19:40:35 <luke-jr> jeremyrubin: ?
5812020-02-06T19:40:48 <jeremyrubin> [11:39] <luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
5822020-02-06T19:40:48 <MarcoFalke> Yeah, we should recommend users use a shorter password, if anything
5832020-02-06T19:40:51 <sipa> luke-jr: wallet.dat files get backed up
5842020-02-06T19:40:59 <wumpus> luke-jr: they might copy it to a cloud service or something
5852020-02-06T19:41:00 <sipa> MarcoFalke: i disagree with that as well
5862020-02-06T19:41:02 <luke-jr> sipa: hopefully encrypted!
5872020-02-06T19:41:04 <jeremyrubin> I think it's relatively likely you leak your file but don't get a keylogger
5882020-02-06T19:41:13 <sipa> luke-jr: right, but in that case, the passphrase needs to be strong
5892020-02-06T19:41:25 <luke-jr> sipa: no, I mean encrpying the file itself
5902020-02-06T19:41:26 <jeremyrubin> e.g., keeping backups on thumb drives
5912020-02-06T19:41:36 *** timothy has quit IRC
5922020-02-06T19:42:01 <sipa> luke-jr: it's hard to assume that people will use a strong password for an encrypted backup, but then not one inside the file?
5932020-02-06T19:42:15 <luke-jr> perhaps we should put a suggestion to that effect somewhere
5942020-02-06T19:42:16 <wumpus> in any case, there's no disagreement about whether the wallet encryption is useful or not, that's not the topic
5952020-02-06T19:42:17 <sipa> i disagree that in general we should advise weak passwords
5962020-02-06T19:42:33 <wumpus> no, we shouldn't advise that
5972020-02-06T19:42:45 <MarcoFalke> ok, we shouldn't advise on weak passwords, but we might want to explain the tradeoffs
5982020-02-06T19:42:53 <sipa> MarcoFalke: yes
5992020-02-06T19:42:59 <wumpus> that would make sense, yes
6002020-02-06T19:43:02 <wumpus> add an explanation
6012020-02-06T19:43:03 <MarcoFalke> I.e. what the password protects against and what it does not protect against
6022020-02-06T19:43:07 <sipa> "Losing this password will make your funds irrecoverably lost"
6032020-02-06T19:43:28 <jeremyrubin> I think also saying "writing down the password in a notebook is probably better than not having one"
6042020-02-06T19:43:36 <jonatack> https://www.xkcd.com/936/
6052020-02-06T19:43:37 <jeremyrubin> Or something to that effect
6062020-02-06T19:43:38 <jonasschnelli> I'm all for informing (text based) rather then applying rules that only works for certain use cases
6072020-02-06T19:43:48 <luke-jr> jeremyrubin: it really depends on your risk exposure
6082020-02-06T19:43:53 <jeremyrubin> I think people don't know that the password is not a seed
6092020-02-06T19:44:14 <jeremyrubin> if you just write down the password but they don't have the wallet.dat it's fine
6102020-02-06T19:44:44 <wumpus> jeremyrubin: yep, some people are confused by that
6112020-02-06T19:44:45 <jeremyrubin> luke-jr: if someone remote compromises your computer but you have a sticky note with a long password on your screen you're "fine"
6122020-02-06T19:45:06 <wumpus> because most wallets work with seeds nowadays
6132020-02-06T19:45:07 <jeremyrubin> (until you type it in, but let's assume read only compromise)
6142020-02-06T19:45:09 <jonasschnelli> The wallet encryption should be better explained. I would not wonder if some users encrypt their watch only wallets in the hope to not leak metadata to computer wide text pattern searches, etc.
6152020-02-06T19:45:21 <wumpus> agree with jonasschnelli on adding explanation text
6162020-02-06T19:45:38 <luke-jr> you can't encrypt watch-only I thought?
6172020-02-06T19:45:44 <emilengler> I think it may be a good way to add a way to encrypt the wallet in the intro dialog
6182020-02-06T19:45:45 <jonasschnelli> Can't you?
6192020-02-06T19:45:46 <hebasto> explanation is good
6202020-02-06T19:46:05 <wumpus> only private keys are encrypted, so encrypting watch-only would be a no-op
6212020-02-06T19:46:07 <luke-jr> jonasschnelli: what would it even do?
6222020-02-06T19:46:07 <sipa> jonasschnelli: of course not
6232020-02-06T19:46:10 <jonasschnelli> luke-jr: I guess you can because its mostly a mixed situation
6242020-02-06T19:46:13 <sipa> what would there be to encrypt?
6252020-02-06T19:46:25 <jonasschnelli> sipa: thats exactly the problem
6262020-02-06T19:46:32 <jonasschnelli> people expect things are encrypted
6272020-02-06T19:46:41 <wumpus> the metadata is never encrypted
6282020-02-06T19:46:47 <jonasschnelli> while we only encrypt the keys
6292020-02-06T19:46:52 <jonasschnelli> Yes. But we don't tell that to users
6302020-02-06T19:47:01 <sipa> jonasschnelli: a no-key wallet can't be encrypted, i think?
6312020-02-06T19:47:04 <luke-jr> it's obvious?
6322020-02-06T19:47:12 <jonasschnelli> So,.. IRS grabs wallet.dat file and reads transaction comments
6332020-02-06T19:47:16 <wumpus> this is why software needs documentation I guess
6342020-02-06T19:47:22 <sipa> luke-jr: don't assume things are obvious
6352020-02-06T19:47:22 <jeremyrubin> luke-jr: how is it obvious?
6362020-02-06T19:47:31 <jeremyrubin> That they can open the wallet and see stuff and only pw to sign?
6372020-02-06T19:47:35 <jonasschnelli> It's not obvious to most users
6382020-02-06T19:47:37 <luke-jr> you open Bitcoin Core and see your metadata, without entry of passphrase
6392020-02-06T19:47:51 <wumpus> jonasschnelli: well it doesn't ask th password at startup, only when you send
6402020-02-06T19:47:52 <jonasschnelli> encryption means for most users data can't be read by someone no knowing the secret
6412020-02-06T19:47:53 <jeremyrubin> Actually that sounds like a 2 birds one stone thing
6422020-02-06T19:48:08 <jonasschnelli> wumpus: sure. But novice users don't understand that either
6432020-02-06T19:48:15 <jeremyrubin> If people have to put their password in more often maybe they're less likely to forget it ;)
6442020-02-06T19:48:23 <luke-jr> jeremyrubin: hmm!
6452020-02-06T19:49:00 <jonasschnelli> I think adding more explanations on how the encryption work would be great in general
6462020-02-06T19:49:05 <jonasschnelli> works
6472020-02-06T19:49:21 <MarcoFalke> Opened an issue #18085
6482020-02-06T19:49:22 <gribble> https://github.com/bitcoin/bitcoin/issues/18085 | doc: Explain what the wallet password does · Issue #18085 · bitcoin/bitcoin · GitHub
6492020-02-06T19:49:28 <jonasschnelli> Nice
6502020-02-06T19:49:37 <wumpus> thanks
6512020-02-06T19:49:46 <jeremyrubin> I think there's also a lot of room for improvements in what users have available, e.g. shamir's secret shares
6522020-02-06T19:49:52 <jonasschnelli> We don't encrypt the wallet, we encrypt the keys
6532020-02-06T19:50:29 <jonatack> I sense new options/config args in our future here
6542020-02-06T19:50:32 <jeremyrubin> Even though we know multisig is better, user's are really struggling to do anything better than a plaintext wallet
6552020-02-06T19:51:13 <luke-jr> not sure it makes sense to put any effort into pre-Taproot multisig at this point?
6562020-02-06T19:51:16 <sipa> jeremyrubin: that's not really an option in a model where a wallet is a file and not a seed
6572020-02-06T19:51:17 <wumpus> we should be careful only to add features that are actually used and useful though, don't want to end up with some GPG-like tool that does a zillion things but with a lot of pitfalls
6582020-02-06T19:51:30 <jeremyrubin> Maybe organizing some discussion at coredev.tech would be good about conducting some user research to improve things.
6592020-02-06T19:51:52 <kanzure> i'll add that to the list then.
6602020-02-06T19:51:57 <kanzure> empirical user testing would be interesting
6612020-02-06T19:51:59 <sipa> luke-jr: multisig support at this point means improving PSBT integration, i think
6622020-02-06T19:52:02 <jeremyrubin> Can ask some of the ideo people to come by since they've been doing key managment UXs with a lot of projects
6632020-02-06T19:52:08 <sipa> luke-jr: which we should definitely work on
6642020-02-06T19:52:13 <luke-jr> good point
6652020-02-06T19:52:17 <kanzure> i'd prefer to forego ideo
6662020-02-06T19:52:20 <jeremyrubin> sipa: you can still do point-in-time non seed backups
6672020-02-06T19:52:35 <jeremyrubin> kanzure: Any specific reason?
6682020-02-06T19:53:09 <jonasschnelli> let's not sidetrack this topic. :)
6692020-02-06T19:53:21 <sipa> yes please
6702020-02-06T19:53:48 <wumpus> maybe more apprpriate for the wallet meeting, too
6712020-02-06T19:53:59 <sipa> yeah
6722020-02-06T19:54:34 <wumpus> not that we have any more topics for today
6732020-02-06T19:54:45 <sdaftuar> hi - i'm back, if anyone has questions about wtxid-relay i can discus
6742020-02-06T19:55:03 <jeremyrubin> yay! please do
6752020-02-06T19:55:04 <MarcoFalke> sdaftuar: There was a question whether it was needed for package relay
6762020-02-06T19:55:50 <sdaftuar> i think it's a nice-to-have, but non-essential
6772020-02-06T19:56:12 <sdaftuar> nice-to-have only because any tx-relay protocol change we make in the future (like erlay, or dandelion, etc) should be done on wtxid-based relay
6782020-02-06T19:56:17 <jeremyrubin> I guess more concretely where it fits into the https://github.com/bitcoin/bitcoin/projects/14 workflow and where you think it belongs timeline wise
6792020-02-06T19:56:56 <sdaftuar> well, i'm probably personally gated on it, as i don't want to work on more p2p relay things based on txid-relay at this point
6802020-02-06T19:57:04 <jeremyrubin> Like if new rebroadcasting stuff like what amiti is working on should be done on wtxids then do we try to slot this before it
6812020-02-06T19:57:08 <sdaftuar> barring some reason that wtxid-relay is a problem
6822020-02-06T19:57:18 <jeremyrubin> ah ok; so it slots before further package relay work for you
6832020-02-06T19:57:39 <luke-jr> I never really understood why we didn't do wtxid-relay from the start
6842020-02-06T19:57:51 <sdaftuar> luke-jr: we shoudl have! the second best time is now
6852020-02-06T19:57:53 <jeremyrubin> we didn't have wtxids before segwit
6862020-02-06T19:57:53 <luke-jr> (or if I did, I forgot)
6872020-02-06T19:58:01 <sdaftuar> it was just more work, and we were busy
6882020-02-06T19:58:22 <sdaftuar> but i think it's pretty straightforward, and we should do it, ideally before we make a standardness change to segwit transactions
6892020-02-06T19:58:31 <jonatack> ack
6902020-02-06T19:58:33 <sipa> i think initially it wasn't that clear that it was needed in the first place
6912020-02-06T19:58:49 <sipa> and when segwit was further along, it got pushed back to "later"
6922020-02-06T19:58:52 <sipa> seems later is now
6932020-02-06T19:58:55 <wumpus> 1 minute left
6942020-02-06T19:59:01 <sdaftuar> yeah i'm not sure how much anyone thought about it until petertodd pointed out the issues in #8279
6952020-02-06T19:59:03 <gribble> https://github.com/bitcoin/bitcoin/issues/8279 | Mempool DoS risk in segwit due to malleated transactions · Issue #8279 · bitcoin/bitcoin · GitHub
6962020-02-06T19:59:29 <jeremyrubin> My only concern looking at the code is that a new index in maptx kinda sucks
6972020-02-06T19:59:53 <sdaftuar> a bit more memory, but i don't see a way around it, and i think the tradeoff is well worth the benefit
6982020-02-06T20:00:03 <sipa> DING DONG
6992020-02-06T20:00:06 <wumpus> #endmeeting
7002020-02-06T20:00:06 <lightningbot> Meeting ended Thu Feb 6 20:00:06 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7012020-02-06T20:00:06 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.html
7022020-02-06T20:00:06 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.txt
7032020-02-06T20:00:06 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-02-06-19.00.log.html
7042020-02-06T20:00:06 <luke-jr> could we add both entries to the same index?
7052020-02-06T20:00:15 <hebasto> luke-jr: missed 32-bit packages in CentOS 7 repos - https://github.com/bitcoin/bitcoin/pull/17900#issuecomment-572697411
7062020-02-06T20:00:17 <luke-jr> maybe no benefit
7072020-02-06T20:00:19 <sdaftuar> luke-jr: we need to look up by both txid and wtxid
7082020-02-06T20:00:23 <sdaftuar> so two keys
7092020-02-06T20:00:31 <gwillen> so while people are here, and speaking of PSBT which got mentioned earlier -- I would love to see more reviews of 18027
7102020-02-06T20:00:34 <sdaftuar> we use the boost multiindex already, which i think is pretty efficient?
7112020-02-06T20:00:34 <gwillen> er, #18027
7122020-02-06T20:00:37 <gribble> https://github.com/bitcoin/bitcoin/issues/18027 | "PSBT Operations" dialog by gwillen · Pull Request #18027 · bitcoin/bitcoin · GitHub
7132020-02-06T20:00:49 <jonatack> (fwiw... did we finish the blockers/hi-prio part?)
7142020-02-06T20:01:05 <jeremyrubin> sdaftuar: you can actually reuse the saltedtxid hasher across both indexes I think
7152020-02-06T20:01:12 <sipa> sdaftuar: i need to revive my use-allocator-to-count-multiindex-memory-use stuff... i'm not sure how accurate we currently are
7162020-02-06T20:01:14 <luke-jr> hebasto: I would assume anyone building for 32-bit is using 32-bit to do it
7172020-02-06T20:01:24 <luke-jr> hebasto: and not everyone uses CentOS
7182020-02-06T20:02:02 <sdaftuar> sipa: ah yes i have no idea how to do that, if you can advise on how to update the memory calculation better than i did in the PR, please let me know
7192020-02-06T20:02:15 <jonatack> ^ +1
7202020-02-06T20:02:16 <sdaftuar> jeremyrubin: i don't think i follow
7212020-02-06T20:02:48 <sipa> sdaftuar: i have some WIP code that i can probably use to verify whether or current heuristic is accurate... actually replacing it is probably harder
7222020-02-06T20:03:24 <aj> is #14895 really still chasing concept ack?
7232020-02-06T20:03:26 <gribble> https://github.com/bitcoin/bitcoin/issues/14895 | Package relay design questions · Issue #14895 · bitcoin/bitcoin · GitHub
7242020-02-06T20:03:58 <jeremyrubin> sdaftuar: I need to think about it a little bit. Fundamentally you want to be able to index by either TXID or WTXID
7252020-02-06T20:04:34 *** EagleTM has joined #bitcoin-core-dev
7262020-02-06T20:04:51 <jeremyrubin> But because it's a hash table there's a lot of extra overhead (idk what load the boost table works well till)
7272020-02-06T20:05:04 <jeremyrubin> Just trying to think if there's a way to be able to index by either
7282020-02-06T20:06:57 <jeremyrubin> Do you envision that we ever remove the txid index?
7292020-02-06T20:07:08 <sdaftuar> we can't do that very easily
7302020-02-06T20:07:09 <jeremyrubin> Or you think it's there forever for compat
7312020-02-06T20:07:14 <sdaftuar> because transactions reference inputs by txid
7322020-02-06T20:07:22 <jeremyrubin> right
7332020-02-06T20:07:23 <sipa> jeremyrubin: UTXOs are indexed by txid
7342020-02-06T20:07:24 <luke-jr> hmm
7352020-02-06T20:07:25 <sdaftuar> so unless someone gave you a hint for what wtxid to look for, you're screwed
7362020-02-06T20:07:58 <luke-jr> sdaftuar: well, only for mempool-spending txs?
7372020-02-06T20:08:00 <jeremyrubin> OK I'm OK with it
7382020-02-06T20:08:03 <jeremyrubin> BUT
7392020-02-06T20:08:06 <sdaftuar> i think in the case of package relay though, i might imagine that we'll get those hints, but not in a generic enough way that we could ever git rid of the index
7402020-02-06T20:08:09 <sdaftuar> luke-jr: right
7412020-02-06T20:08:11 <jeremyrubin> You have to review my next two PRs first
7422020-02-06T20:08:20 <jeremyrubin> Because I get rid of mapTxLinks
7432020-02-06T20:08:22 <luke-jr> could hypothetically use wtxids in the tx structure there, and continue to use just the txids for signatures?
7442020-02-06T20:08:25 <jeremyrubin> which can pay for this new index ;)
7452020-02-06T20:08:34 <sdaftuar> luke-jr: that would be a big relay change though
7462020-02-06T20:08:48 <luke-jr> maybe worth it long-term
7472020-02-06T20:08:49 <sdaftuar> and it just seems like a lot of edge cases would break
7482020-02-06T20:08:56 <sdaftuar> yeah, i can't rule it out
7492020-02-06T20:09:01 <sipa> i don't understand what the point is
7502020-02-06T20:09:03 <luke-jr> gotta run
7512020-02-06T20:09:17 <sipa> not having wtxids in transactions is exactly what segwit made possible
7522020-02-06T20:09:28 <sdaftuar> yes :)
7532020-02-06T20:09:44 <sdaftuar> i think saving a little memory is not worth the effort here
7542020-02-06T20:10:18 <kanzure> i think the point was something about rebroadcast logic or first-seen issues?
7552020-02-06T20:10:25 <kanzure> right, bad witnesses or something?
7562020-02-06T20:10:30 <jeremyrubin> Yeah, I think given that we're going to kill mapTxLinks it's going to be fine (I just don't want people to have a reason not to upgrade to wtxid index)
7572020-02-06T20:10:43 <jeremyrubin> kanzure: anyone can malleate witnesses
7582020-02-06T20:10:56 <sdaftuar> jeremyrubin: i don't think this has anything to do with mapTxLinks though? i didn't need to touch it for the wtxid-relay PR
7592020-02-06T20:11:16 <jeremyrubin> sdaftuar: I'm saying that one of the PRs I pinged you on kills mapTxLinks
7602020-02-06T20:11:19 <sdaftuar> (unless i am missing something!)
7612020-02-06T20:11:25 <sdaftuar> right, i imagine that should be fine
7622020-02-06T20:11:45 <jeremyrubin> so the memory/hashing overhead going away there is probably the same as a new index
7632020-02-06T20:12:08 <sdaftuar> one way to think about this is that only the net_processing layer needs to be able to look things up in the mempool by wtxid
7642020-02-06T20:12:18 <sdaftuar> as that's the only place in our code where we need to deteremine whether we already have a wtxid someone is offering
7652020-02-06T20:12:21 <jeremyrubin> So I'm OK with not introducing a regression
7662020-02-06T20:12:29 <sdaftuar> anything internal to the mempool is unaffected by this change
7672020-02-06T20:12:30 <jeremyrubin> Because we have a way to pay for it
7682020-02-06T20:12:54 <sdaftuar> oh, you're saying that the extra memory is a wash with those other changes? even better :)
7692020-02-06T20:12:58 <jeremyrubin> Yes
7702020-02-06T20:13:03 <kanzure> sipa: i assume this https://github.com/bitcoin/bitcoin/pull/18044
7712020-02-06T20:13:25 <jeremyrubin> https://github.com/JeremyRubin/bitcoin/pull/7
7722020-02-06T20:13:32 <sipa> kanzure: yes that's what we're talking about
7732020-02-06T20:13:40 *** kristapsk has joined #bitcoin-core-dev
7742020-02-06T20:14:02 <sipa> jeremyrubin: seems completely unrelated; we need wtxid based relay i think, and even if the only way to do it is by adding memory, we should
7752020-02-06T20:14:32 <jeremyrubin> sdaftuar previously said it was nice ot have but not required
7762020-02-06T20:15:07 <sipa> and if we can get rid of mapTxLinks, we should, unrelated of wtxid based relay
7772020-02-06T20:15:19 <sdaftuar> jeremyrubin: that was for package relay
7782020-02-06T20:15:25 *** tryphe_ has joined #bitcoin-core-dev
7792020-02-06T20:15:26 <jeremyrubin> ah
7802020-02-06T20:15:27 <sdaftuar> i think package relay could be done with or without wtxid relay
7812020-02-06T20:15:36 <sdaftuar> but wtxid relay is required to solve some bandwidth-waste issues
7822020-02-06T20:15:37 <jeremyrubin> I thought you meant in general
7832020-02-06T20:15:58 <jeremyrubin> sipa: I just don't want there to be a reason for economic nodes to not upgrade that's all
7842020-02-06T20:16:13 <jeremyrubin> the changes are obviously independent
7852020-02-06T20:16:20 <sdaftuar> the issue we have with txid relay is that when a peer announces a segwit transaction that doesn't pass your policy checks, then you don't know whether another peer announcing the same txid has the same transactionr or not
7862020-02-06T20:16:26 <sdaftuar> because maybe just the witness was malleated
7872020-02-06T20:16:34 <jeremyrubin> But that we're not increasing overheads overall means we can not worry at all
7882020-02-06T20:16:39 <sdaftuar> so you have to download it (otherwise, an attacker could malleate transactions to interfere with relay)
7892020-02-06T20:17:01 <sdaftuar> and this is wasteful, particularly after a policy change to segwit-transaction-acceptance (eg taproot, or any other policy change)
7902020-02-06T20:17:15 <sdaftuar> when you would expect old nodes to reject a certain category of new transaction
7912020-02-06T20:17:55 *** tryphe has quit IRC
7922020-02-06T20:18:04 <sdaftuar> there's also a related CPU DoS issue with how we determine whether a transaction is witness-stripped, which will be alleviated in the future when we no longer need to worry about adding txid's for segwit transactions to our reject filter
7932020-02-06T20:18:54 *** alec has quit IRC
7942020-02-06T20:18:55 <sdaftuar> so i think we definitely need wtxid relay, even if we support txid-based-relay indefinitely to support old software
7952020-02-06T20:20:47 *** Talkless has quit IRC
7962020-02-06T20:21:04 <jeremyrubin> I guess it's not clear to me why this has to be a new mempool index rather than a fixed size separate cache only in net_proc
7972020-02-06T20:21:09 <jeremyrubin> will look more closely
7982020-02-06T20:21:28 <sdaftuar> jeremyrubin: i think code simplicity?
7992020-02-06T20:21:37 <sipa> jeremyrubin: for my current mempool, the extra index would be a 0.55% memory usage increase
8002020-02-06T20:22:05 <sdaftuar> maintaining a separate data structure just to shave a few bytes doesn't seem worth the effort to me. the mempool is probably already too big
8012020-02-06T20:22:07 <jeremyrubin> sipa: I'm concerned with hashing too, we're slowing down all inserts
8022020-02-06T20:22:16 <aj> yeah, extra indexes on multi_index are pretty cheap
8032020-02-06T20:22:43 <sdaftuar> inserts aren't in the critical path of block acceptance, i think they're small compared to transaction validation speeds
8042020-02-06T20:22:50 <sipa> yeah
8052020-02-06T20:23:14 <jeremyrubin> Cool -- these are all good things to document & measure in advocating this change
8062020-02-06T20:23:20 <sdaftuar> if you want to worry about CPU usage in transaction acceptance, we should reopen by parallel-script-check-thread PR for mempool acceptance
8072020-02-06T20:23:39 <sdaftuar> (i do worry about it, but i think the mempool data structures are far from our biggest concern)
8082020-02-06T20:23:49 <sipa> just assume all transactions are valid ethereum style
8092020-02-06T20:23:59 <sdaftuar> :)
8102020-02-06T20:24:00 *** Victorsueca has joined #bitcoin-core-dev
8112020-02-06T20:24:01 <jeremyrubin> sdaftuar: after I finish the 100th epoch mempool patch I'll do that
8122020-02-06T20:25:12 <sdaftuar> sipa: we could just have every node randomly sample transactions to run script checking on, and turn back on sending reject messages, and whenever you learn of a reject from a peer you validate it yourself
8132020-02-06T20:25:28 <sdaftuar> <runs away>
8142020-02-06T20:25:54 <sipa> haha
8152020-02-06T20:30:08 <jeremyrubin> sdaftuar: actually you do a ZKP over your mempool proving it has no invalid txns
8162020-02-06T20:30:35 <jeremyrubin> you do a interactive setup with each peer so it's trustless
8172020-02-06T20:30:44 <sipa> lol
8182020-02-06T20:31:22 <aj> jeremyrubin: and that uses less cpu, right?
8192020-02-06T20:31:41 <sipa> aj: you do it in the cloud
8202020-02-06T20:32:00 <aj> sipa: i don't trust the cloud, that makes it trustless, right?
8212020-02-06T20:32:02 <jeremyrubin> aj: you don't care who generates the proof for your setup string
8222020-02-06T20:32:42 <jeremyrubin> so you outsource proving batches of transactions correct to the miners, who get paid for getting them accepted, or the users whose txns it is
8232020-02-06T20:32:52 <jeremyrubin> maybe this is better for #wizards ;)
8242020-02-06T20:33:04 <sipa> yes
8252020-02-06T20:35:18 <aj> sdaftuar: did you see https://github.com/bitcoin/bitcoin/pull/17303#issuecomment-581363980 ? there's a patch there that's a different approach for #15505 ; worth trying? (seems silly to add wtxid for mapRelay if we could just get rid of mapRelay first instead)
8262020-02-06T20:35:22 <gribble> https://github.com/bitcoin/bitcoin/issues/15505 | p2p: Request NOTFOUND transactions immediately from other outbound peers, when possible by sdaftuar · Pull Request #15505 · bitcoin/bitcoin · GitHub
8272020-02-06T20:36:40 *** Victorsueca has quit IRC
8282020-02-06T20:37:32 <sdaftuar> aj: i would definitely prefer to get rid of mapRelay, but i think the additional memory i propose using in #18044 is very minor, it's just an extra key
8292020-02-06T20:37:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
8302020-02-06T20:37:56 <sdaftuar> and it should be easy to remove either before or after the wtxid-relay PR
8312020-02-06T20:38:10 <sdaftuar> (if we can get rid of mapRelay before, i can easily pull that commit out of my branch)
8322020-02-06T20:39:26 *** Victorsueca has joined #bitcoin-core-dev
8332020-02-06T20:39:41 <aj> sdaftuar: oh, yeah, not a meaningful criticism
8342020-02-06T20:40:50 <jeremyrubin> sdaftuar: btw can you re-run your reorg benchmark on #18063 for equal comparison to prior work?
8352020-02-06T20:40:52 <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
8362020-02-06T20:41:12 <sdaftuar> jeremyrubin: uh i will try to dig it up again :) thanks for reminding though, i'll take a look
8372020-02-06T20:41:47 <jeremyrubin> if you find it and can run it commit-by-commit that would help (there are only 2)
8382020-02-06T20:42:30 <sdaftuar> gotcha, will give it a try
8392020-02-06T20:51:42 *** bsm1175321 has quit IRC
8402020-02-06T20:51:55 *** bsm117532 has joined #bitcoin-core-dev
8412020-02-06T20:53:40 *** emilengler has quit IRC
8422020-02-06T21:00:02 *** mota1 has quit IRC
8432020-02-06T21:08:15 *** goatpig has quit IRC
8442020-02-06T21:18:42 *** mkrautz1 has joined #bitcoin-core-dev
8452020-02-06T21:19:17 *** Guyver2 has quit IRC
8462020-02-06T21:36:28 *** EagleTM has quit IRC
8472020-02-06T21:37:51 *** manantial has quit IRC
8482020-02-06T21:43:42 *** ccdle12 has joined #bitcoin-core-dev
8492020-02-06T22:04:07 *** promag has joined #bitcoin-core-dev
8502020-02-06T22:23:32 *** francisco_ has joined #bitcoin-core-dev
8512020-02-06T22:28:23 *** promag_ has joined #bitcoin-core-dev
8522020-02-06T22:34:07 *** promag_ has quit IRC
8532020-02-06T22:43:26 *** ccdle12 has quit IRC
8542020-02-06T22:56:08 *** Highway61 has quit IRC
8552020-02-06T22:57:42 *** EagleTM has joined #bitcoin-core-dev
8562020-02-06T22:58:13 *** PaulTroon has joined #bitcoin-core-dev
8572020-02-06T23:02:16 *** promag_ has joined #bitcoin-core-dev
8582020-02-06T23:06:51 *** promag_ has quit IRC
8592020-02-06T23:19:12 *** promag_ has joined #bitcoin-core-dev
8602020-02-06T23:23:57 *** promag_ has quit IRC
8612020-02-06T23:24:15 *** Highway61 has joined #bitcoin-core-dev
8622020-02-06T23:25:37 *** Zenton has quit IRC
8632020-02-06T23:29:34 *** EagleTM has quit IRC
8642020-02-06T23:35:15 *** molly has joined #bitcoin-core-dev
8652020-02-06T23:36:59 *** EagleTM has joined #bitcoin-core-dev
8662020-02-06T23:38:49 *** molz_ has quit IRC
8672020-02-06T23:56:51 *** mdunnio has quit IRC