12020-11-03T00:00:02 *** d_ed1 <d_ed1!~d_ed@84.39.117.57> has quit IRC
22020-11-03T00:21:49 *** bruceadams <bruceadams!~bruceadam@139.28.218.148> has joined #bitcoin-core-dev
32020-11-03T00:21:52 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
42020-11-03T00:21:57 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
52020-11-03T00:22:11 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
62020-11-03T00:27:25 *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
72020-11-03T00:29:26 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
82020-11-03T01:21:58 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
92020-11-03T01:22:12 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
102020-11-03T01:40:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
112020-11-03T01:40:03 <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/ca1886056325...8387f832d693
122020-11-03T01:40:04 <bitcoin-git> bitcoin/master daf5553 Suhas Daftuar: Avoid calling CAddrMan::Connected() on block-relay-only peer addresses
132020-11-03T01:40:05 <bitcoin-git> bitcoin/master 4fe338a Suhas Daftuar: Call CAddrMan::Good() on block-relay-only peer addresses
142020-11-03T01:40:06 <bitcoin-git> bitcoin/master e8b215a Suhas Daftuar: Refactor test for existing peer connection into own function
152020-11-03T01:40:07 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
162020-11-03T01:40:22 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
172020-11-03T01:40:22 <bitcoin-git> [bitcoin] fanquake merged pull request #20187: Addrman: test-before-evict bugfix and improvements for block-relay-only peers (master...2020-10-addrman-block-relay) https://github.com/bitcoin/bitcoin/pull/20187
182020-11-03T01:40:23 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
192020-11-03T01:53:44 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
202020-11-03T01:54:27 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
212020-11-03T02:17:11 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
222020-11-03T02:17:13 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
232020-11-03T02:19:07 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
242020-11-03T02:21:58 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
252020-11-03T02:22:12 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
262020-11-03T02:28:47 *** Squidicc <Squidicc!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has joined #bitcoin-core-dev
272020-11-03T02:29:53 *** Squidicuz <Squidicuz!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has quit IRC
282020-11-03T02:30:42 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
292020-11-03T02:37:51 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC
302020-11-03T02:38:16 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
312020-11-03T02:40:43 *** Klox0480931863 <Klox0480931863!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC
322020-11-03T02:42:58 *** Klox0480931863 <Klox0480931863!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
332020-11-03T03:00:01 *** bruceadams <bruceadams!~bruceadam@139.28.218.148> has quit IRC
342020-11-03T03:16:05 *** bosch-0 <bosch-0!7a94fe5f@122-148-254-95.sta.wbroadband.net.au> has joined #bitcoin-core-dev
352020-11-03T03:16:33 <bosch-0> Yo
362020-11-03T03:16:47 <bosch-0> Want to have a read of my project before I submit it? https://github.com/Bosch-0/Project-Muggle/blob/master/README.md
372020-11-03T03:16:50 <bosch-0> If ya not too busy
382020-11-03T03:21:57 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
392020-11-03T03:22:11 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
402020-11-03T03:22:25 *** jMCg <jMCg!~jMCg@84.39.117.57> has joined #bitcoin-core-dev
412020-11-03T03:27:10 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
422020-11-03T03:34:04 *** pinheadm_ <pinheadm_!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC
432020-11-03T03:42:41 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
442020-11-03T03:49:35 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
452020-11-03T04:06:21 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
462020-11-03T04:09:53 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
472020-11-03T04:11:03 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
482020-11-03T04:15:02 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
492020-11-03T04:21:58 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
502020-11-03T04:22:12 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
512020-11-03T04:25:47 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
522020-11-03T04:25:50 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
532020-11-03T04:31:19 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
542020-11-03T04:33:58 *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
552020-11-03T04:34:55 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
562020-11-03T04:37:12 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
572020-11-03T04:38:32 *** molz_ <molz_!~mol@unaffiliated/molly> has quit IRC
582020-11-03T04:56:00 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
592020-11-03T04:57:44 *** justan0theruser <justan0theruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
602020-11-03T04:58:04 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC
612020-11-03T05:00:30 <S3RK> question about fuzzing. we use regtest chain params, but in corups for src/test/fuzz/descriptor_parse.cpp I see xprv keys. As a result fuzzing don't cover code paths with valid keys for bip32 decriptors. I tried to add initial seeds with tprv, but fuzzer doesn't detect any new edges covered. What do I miss?
622020-11-03T05:26:57 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
632020-11-03T05:27:11 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
642020-11-03T06:00:02 *** jMCg <jMCg!~jMCg@84.39.117.57> has quit IRC
652020-11-03T06:10:08 *** justan0theruser <justan0theruser!~justanoth@unaffiliated/justanotheruser> has quit IRC
662020-11-03T06:11:25 *** IGHOR <IGHOR!~quassel@176.121.4.135> has quit IRC
672020-11-03T06:17:32 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
682020-11-03T06:21:26 *** IGHOR <IGHOR!~quassel@176.121.4.135> has joined #bitcoin-core-dev
692020-11-03T06:21:31 *** bosch-0 <bosch-0!7a94fe5f@122-148-254-95.sta.wbroadband.net.au> has quit IRC
702020-11-03T06:22:00 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
712020-11-03T06:22:14 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
722020-11-03T06:22:18 *** secdragon <secdragon!~secdragon@178.162.209.171> has joined #bitcoin-core-dev
732020-11-03T06:29:28 *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@195.214.157.34> has joined #bitcoin-core-dev
742020-11-03T06:47:41 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
752020-11-03T06:48:21 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
762020-11-03T06:52:50 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
772020-11-03T06:54:56 *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
782020-11-03T07:20:47 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
792020-11-03T07:21:57 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
802020-11-03T07:22:11 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
812020-11-03T07:37:16 *** kexkey <kexkey!~kexkey@static-198-54-132-134.cust.tzulo.com> has quit IRC
822020-11-03T07:41:45 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
832020-11-03T07:42:04 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
842020-11-03T07:56:10 *** Cory <Cory!~Cory@unaffiliated/cory> has quit IRC
852020-11-03T08:03:28 *** Cory <Cory!~Cory@unaffiliated/cory> has joined #bitcoin-core-dev
862020-11-03T08:18:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
872020-11-03T08:18:43 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8387f832d693...5174b534da57
882020-11-03T08:18:43 <bitcoin-git> bitcoin/master c2cf8a1 practicalswift: fuzz: Check for addrv1 compatibility before using addrv1 serializer on CSe...
892020-11-03T08:18:44 <bitcoin-git> bitcoin/master 5174b53 MarcoFalke: Merge #20289: fuzz: Check for addrv1 compatibility before using addrv1 ser...
902020-11-03T08:18:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
912020-11-03T08:18:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
922020-11-03T08:18:58 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20289: fuzz: Check for addrv1 compatibility before using addrv1 serializer/deserializer on CService (master...fuzzers-service_deserialize-addrv2) https://github.com/bitcoin/bitcoin/pull/20289
932020-11-03T08:18:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
942020-11-03T08:21:58 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
952020-11-03T08:22:11 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
962020-11-03T08:24:53 *** sr_gi <sr_gi!~sr_gi@static-77-88-225-77.ipcom.comunitel.net> has quit IRC
972020-11-03T08:25:33 *** sr_gi <sr_gi!~sr_gi@static-77-88-225-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
982020-11-03T08:32:24 *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
992020-11-03T08:32:36 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC
1002020-11-03T08:51:27 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1012020-11-03T08:51:27 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5174b534da57...218fe60d91a9
1022020-11-03T08:51:28 <bitcoin-git> bitcoin/master 28f8cb1 practicalswift: fuzz: Fix DecodeHexTx fuzzing harness issue
1032020-11-03T08:51:28 <bitcoin-git> bitcoin/master 218fe60 MarcoFalke: Merge #20290: fuzz: Fix DecodeHexTx fuzzing harness issue
1042020-11-03T08:51:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1052020-11-03T08:51:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1062020-11-03T08:51:42 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20290: fuzz: Fix DecodeHexTx fuzzing harness issue (master...fuzzers-decode_tx-fixup) https://github.com/bitcoin/bitcoin/pull/20290
1072020-11-03T08:51:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1082020-11-03T08:53:23 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
1092020-11-03T08:57:31 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
1102020-11-03T09:00:02 *** secdragon <secdragon!~secdragon@178.162.209.171> has quit IRC
1112020-11-03T09:10:01 *** promag_ <promag_!~promag@188.251.225.32> has joined #bitcoin-core-dev
1122020-11-03T09:13:16 <MarcoFalke> the meeting topics link in the IRC topic of this channel is no longer being updated. I created a wiki entry to collect meeting topics: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/General-IRC-meeting
1132020-11-03T09:14:39 <jonatack> MarcoFalke: http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
1142020-11-03T09:15:43 <MarcoFalke> jonatack: Oh thanks. Didn't know this existed
1152020-11-03T09:16:05 <jonatack> MarcoFalke: same, I saw achow101 mention it a couple weeks ago
1162020-11-03T09:16:08 <MarcoFalke> Well, could make sense to adjust the link for that then ;)
1172020-11-03T09:16:53 <jonatack> MarcoFalke: maybe add http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt too
1182020-11-03T09:19:56 <MarcoFalke> anyone know who can edit the IRC topic? ping wumpus sipa
1192020-11-03T09:20:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1202020-11-03T09:20:59 <bitcoin-git> [bitcoin] jnewbery opened pull request #20291: [net] Consolidate logic around calling CAddrMan::Connected() (master...2020-11-consolidate-addrman-connect) https://github.com/bitcoin/bitcoin/pull/20291
1212020-11-03T09:21:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1222020-11-03T09:21:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1232020-11-03T09:21:50 <bitcoin-git> [bitcoin] jonatack closed pull request #20288: script, doc: contrib/seeds updates (master...contrib-seeds-fixups) https://github.com/bitcoin/bitcoin/pull/20288
1242020-11-03T09:21:51 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1252020-11-03T09:21:53 *** superfly1 <superfly1!~superfly@84.39.116.180> has joined #bitcoin-core-dev
1262020-11-03T09:38:46 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
1272020-11-03T09:45:49 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
1282020-11-03T10:00:13 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
1292020-11-03T10:06:30 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
1302020-11-03T10:08:31 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1312020-11-03T10:11:43 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
1322020-11-03T10:11:44 *** vasild_ is now known as vasild
1332020-11-03T10:20:34 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC
1342020-11-03T10:23:43 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
1352020-11-03T10:27:26 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
1362020-11-03T10:35:19 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
1372020-11-03T10:39:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1382020-11-03T10:39:43 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20292: test: Fix intermittent feature_taproot issue (master...2011-testFixes) https://github.com/bitcoin/bitcoin/pull/20292
1392020-11-03T10:39:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1402020-11-03T10:39:56 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
1412020-11-03T10:41:01 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
1422020-11-03T10:41:49 *** promag_ <promag_!~promag@188.251.225.32> has quit IRC
1432020-11-03T10:52:47 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
1442020-11-03T10:54:55 *** jonasschnelli <jonasschnelli!~jonasschn@2a01:4f9:2a:2510::2> has quit IRC
1452020-11-03T10:54:55 *** jonasschnelli <jonasschnelli!~jonasschn@unaffiliated/jonasschnelli> has joined #bitcoin-core-dev
1462020-11-03T10:55:27 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
1472020-11-03T10:55:50 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
1482020-11-03T11:04:31 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
1492020-11-03T11:10:46 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
1502020-11-03T11:18:28 *** Gunner5Pollich <Gunner5Pollich!~Gunner5Po@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1512020-11-03T11:21:30 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
1522020-11-03T11:39:55 *** dviola <dviola!~diego@unaffiliated/dviola> has quit IRC
1532020-11-03T11:40:25 *** Gunner5Pollich <Gunner5Pollich!~Gunner5Po@static.57.1.216.95.clients.your-server.de> has quit IRC
1542020-11-03T11:42:09 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
1552020-11-03T11:47:26 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
1562020-11-03T11:52:02 *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
1572020-11-03T11:52:39 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has joined #bitcoin-core-dev
1582020-11-03T11:55:10 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC
1592020-11-03T12:00:01 *** superfly1 <superfly1!~superfly@84.39.116.180> has quit IRC
1602020-11-03T12:06:02 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC
1612020-11-03T12:14:54 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1622020-11-03T12:14:54 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20294: ci: Run more ci configs on cirrus (master...2011-ciCirrus) https://github.com/bitcoin/bitcoin/pull/20294
1632020-11-03T12:14:55 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1642020-11-03T12:18:54 *** Kiminuo <Kiminuo!~mix@141.98.103.76> has joined #bitcoin-core-dev
1652020-11-03T12:21:29 *** mdrjr1 <mdrjr1!~mdrjr@195.140.213.38> has joined #bitcoin-core-dev
1662020-11-03T13:00:19 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1672020-11-03T13:01:43 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
1682020-11-03T13:13:16 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
1692020-11-03T13:18:30 *** rich <rich!rich@2600:3c00::f03c:92ff:fe8e:dce6> has left #bitcoin-core-dev
1702020-11-03T13:19:23 *** PaulTroon <PaulTroon!rich@2600:3c00::f03c:92ff:fe8e:dce6> has joined #bitcoin-core-dev
1712020-11-03T13:21:35 *** belcher_ is now known as belcher
1722020-11-03T13:31:19 *** ctrlbreak <ctrlbreak!~ctrlbreak@159.2.182.106> has quit IRC
1732020-11-03T13:31:43 *** ctrlbreak <ctrlbreak!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
1742020-11-03T13:33:14 *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-fnmzdyejosltdszp> has joined #bitcoin-core-dev
1752020-11-03T13:37:29 *** filchef <filchef!~filchef@212.104.97.177> has quit IRC
1762020-11-03T13:39:41 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1772020-11-03T13:39:41 <bitcoin-git> [bitcoin] Sjors opened pull request #20295: rpc: getblockfrompeer (master...2020/11/getblockfrompeer) https://github.com/bitcoin/bitcoin/pull/20295
1782020-11-03T13:39:41 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1792020-11-03T13:43:11 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
1802020-11-03T13:43:35 <wumpus> MarcoFalke: I can, what would you like to change?
1812020-11-03T13:49:18 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
1822020-11-03T13:56:32 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
1832020-11-03T14:04:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1842020-11-03T14:04:45 <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/218fe60d91a9...95bde34a7186
1852020-11-03T14:04:45 <bitcoin-git> bitcoin/master 36e875b RandyMcMillan: contrib: Add new versions to makeseeds.py and update gitignore
1862020-11-03T14:04:46 <bitcoin-git> bitcoin/master 6866259 Wladimir J. van der Laan: net: Hardcoded seeds update for 0.21
1872020-11-03T14:04:47 <bitcoin-git> bitcoin/master 95bde34 Wladimir J. van der Laan: Merge #20237: net: Hardcoded seeds update for 0.21
1882020-11-03T14:04:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1892020-11-03T14:05:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1902020-11-03T14:05:08 <bitcoin-git> [bitcoin] laanwj merged pull request #20237: net: Hardcoded seeds update for 0.21 (master...2020_10_seeds_update) https://github.com/bitcoin/bitcoin/pull/20237
1912020-11-03T14:05:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1922020-11-03T14:11:46 *** kexkey <kexkey!~kexkey@static-198-54-132-118.cust.tzulo.com> has joined #bitcoin-core-dev
1932020-11-03T14:23:03 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
1942020-11-03T14:24:48 *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
1952020-11-03T14:28:10 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
1962020-11-03T14:33:00 <MarcoFalke> wumpus: replace https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a with http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
1972020-11-03T14:33:42 <wumpus> ok
1982020-11-03T14:33:51 *** ChanServ sets mode: +o wumpus
1992020-11-03T14:34:25 <jnewbery> Hi folks. Reminder that we have a P2P irc meeting in just under half an hour. Proposed topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#03-nov-2020
2002020-11-03T14:34:28 <gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
2012020-11-03T14:37:20 *** ChanServ changes topic to "Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt"
2022020-11-03T14:37:45 *** ChanServ sets mode: -o wumpus
2032020-11-03T14:44:07 <MarcoFalke> thanks
2042020-11-03T14:47:00 *** nickler <nickler!~nickler@static.219.205.69.159.clients.your-server.de> has quit IRC
2052020-11-03T14:47:08 *** nickler <nickler!~nickler@static.219.205.69.159.clients.your-server.de> has joined #bitcoin-core-dev
2062020-11-03T14:54:53 *** TheV01d <TheV01d!thev01d@2001:19c0:1:801:851:ff00:1:6> has quit IRC
2072020-11-03T14:54:53 *** corollari__ <corollari__!sid405633@gateway/web/irccloud.com/x-mmtqtinsxduvodfk> has quit IRC
2082020-11-03T14:56:00 *** TheV01d <TheV01d!thev01d@2001:19c0:1:801:851:ff00:1:6> has joined #bitcoin-core-dev
2092020-11-03T14:56:00 *** corollari__ <corollari__!sid405633@gateway/web/irccloud.com/x-mmtqtinsxduvodfk> has joined #bitcoin-core-dev
2102020-11-03T14:57:26 *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-bbpxarfwoqwpngyc> has quit IRC
2112020-11-03T14:59:27 *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-cjjnwfskkjjjiccx> has quit IRC
2122020-11-03T15:00:01 *** sdaftuar_ is now known as sdaftuar
2132020-11-03T15:00:02 *** mdrjr1 <mdrjr1!~mdrjr@195.140.213.38> has quit IRC
2142020-11-03T15:00:05 <sdaftuar> hi
2152020-11-03T15:00:05 *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-ngiqrfyaklwgnpqv> has quit IRC
2162020-11-03T15:00:09 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-psjyqsyrkhlykggg> has quit IRC
2172020-11-03T15:00:15 *** lightlike <lightlike!~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
2182020-11-03T15:00:18 *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-sbfuejevikgxhirq> has quit IRC
2192020-11-03T15:00:26 <jnewbery> #startmeeting
2202020-11-03T15:00:26 <lightningbot> Meeting started Tue Nov 3 15:00:26 2020 UTC. The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
2212020-11-03T15:00:26 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2222020-11-03T15:00:33 <jnewbery> #bitcoin-core-dev P2P 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
2232020-11-03T15:00:35 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tfhrfhquwmimigoi> has quit IRC
2242020-11-03T15:00:36 <vasild> hi
2252020-11-03T15:00:40 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
2262020-11-03T15:00:42 <phantomcircuit> hi
2272020-11-03T15:00:52 <emzy> hi
2282020-11-03T15:01:01 <aj> hi
2292020-11-03T15:01:12 <jnewbery> that ping thing is like a blockchain. It only gets longer, never shorter
2302020-11-03T15:01:18 <ariard> hi
2312020-11-03T15:01:23 <lightlike> hi
2322020-11-03T15:01:34 <wumpus> hi
2332020-11-03T15:01:37 <jonatack> hi
2342020-11-03T15:01:44 <kanzure> hi
2352020-11-03T15:01:54 <jnewbery> proposed topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#03-nov-2020
2362020-11-03T15:01:56 <gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
2372020-11-03T15:02:11 <jnewbery> Does anyone have any more topics that they want to propose now, or any general updates they want to give?
2382020-11-03T15:02:37 <sdaftuar> i just wanted to review beg #19858
2392020-11-03T15:02:42 <gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
2402020-11-03T15:03:00 <sdaftuar> i've started to now page that PR out of my memory, so would like to make progress before i totally forget what ti is :)
2412020-11-03T15:03:35 <jnewbery> I think we haven't branched 0.21 yet, so we're still in feature freeze, right?
2422020-11-03T15:03:46 <wumpus> right
2432020-11-03T15:03:50 <aj> branch is due pretty soon though?
2442020-11-03T15:03:52 <sdaftuar> i assume so -- but i think if we collect acks now it could merge shortly after?
2452020-11-03T15:03:59 <amiti> hi
2462020-11-03T15:04:01 <luke-jr> kinda curious about the status of p2p encryption
2472020-11-03T15:04:05 <luke-jr> but jonas isn't here
2482020-11-03T15:04:19 <ariard> noted, I'll reack it
2492020-11-03T15:04:31 <jonatack> #18242 was just rebased and it builds cleanly
2502020-11-03T15:04:33 <wumpus> yes, feature freeze is only about what is merged, not what is reviewed :)
2512020-11-03T15:04:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
2522020-11-03T15:04:45 <aj> "2020-11-01 split off 0.21" per 18947
2532020-11-03T15:04:53 <jonatack> (would be good to move it forward for 0.22)
2542020-11-03T15:04:54 <jnewbery> wumpus: while you're here, what's your expectation for when 0.21 will be branched?
2552020-11-03T15:05:48 <wumpus> there's still quite a list of PRs tagged with 0.21.0, these either need to be merged or removed from the milestone first https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
2562020-11-03T15:06:13 <wumpus> but I hope some time next week
2572020-11-03T15:06:33 <jnewbery> thanks!
2582020-11-03T15:06:38 <wumpus> next general meeting we should go over the list
2592020-11-03T15:06:46 <jnewbery> ok, onto the topics
2602020-11-03T15:06:57 <jnewbery> #topic addrman file versioning
2612020-11-03T15:07:01 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has quit IRC
2622020-11-03T15:08:00 <vasild> jnewbery: how did you suddenly come to the realization that old versions are not guaranteed to fail the parsing, out of the blue?
2632020-11-03T15:08:08 <jnewbery> #19954 meant that in future it won't be possible to do forwards-compatible changes to the peers.dat format. #20284 is suggested as a way to allow that again.
2642020-11-03T15:08:13 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
2652020-11-03T15:08:14 <gribble> https://github.com/bitcoin/bitcoin/issues/20284 | addrman: ensure old versions dont parse peers.dat by vasild · Pull Request #20284 · bitcoin/bitcoin · GitHub
2662020-11-03T15:08:34 <jnewbery> vasild: I hadn't reviewed 19954 before
2672020-11-03T15:08:54 <jnewbery> I started looking at the addrman code this weekend
2682020-11-03T15:09:09 <vasild> actually in the future it will be possible to make forward-compatible changes, but the format version must not be incremented
2692020-11-03T15:09:13 <sdaftuar> forwards compatible? do you mean backwards compatible?
2702020-11-03T15:09:26 <sdaftuar> i'm confused why we can't write future code to parse whatever we need to
2712020-11-03T15:09:33 <vasild> backward compatible
2722020-11-03T15:09:46 <jnewbery> sdaftuar: I mean forwards compatible, i.e. you can upgrade, make changes to peers.dat and then downgrade and still parse peers.dat
2732020-11-03T15:10:03 <sdaftuar> that really sounds like backwards compatible to me, but thanks for clarifying what you mean
2742020-11-03T15:10:08 <jnewbery> I believe we generally want to allow people to downgrade at least one version, right? So people can back out upgrades
2752020-11-03T15:10:13 <vasild> the current code supports maximum format=3 and if it sees format=4 it will refuse to parse it
2762020-11-03T15:10:28 <hebasto> hi
2772020-11-03T15:10:35 <jnewbery> I think backwards compatible would mean that we're able to read old versions of peers.dat, which obviously we can always guarantee
2782020-11-03T15:10:52 <jnewbery> forwards compatible means that we're flexible with future peers.dat formatting
2792020-11-03T15:11:58 <jonatack> jnewbery: yes, i was reporting issues with that (upgrading, then downgrading) in 19954 iirc
2802020-11-03T15:11:59 <jnewbery> vasild: right, so the current code on master is not forwards compatible with formats > 4
2812020-11-03T15:12:10 <vasild> >= 4
2822020-11-03T15:12:23 <jnewbery> sorry yes, >= 4
2832020-11-03T15:12:28 *** bosch-0 <bosch-0!~igloo@122-148-254-95.sta.wbroadband.net.au> has joined #bitcoin-core-dev
2842020-11-03T15:12:41 <vasild> yes, if changes are made to the format it must stay at format=3 if we want 0.21 to parse it
2852020-11-03T15:12:55 <vasild> (as of the current master)
2862020-11-03T15:13:03 <luke-jr> it would be annoying if users lost their addrman upgrading or downgrading
2872020-11-03T15:13:10 <vasild> pr20284 changes that
2882020-11-03T15:13:43 *** joerodgers <joerodgers!~joerodger@86.106.121.56> has joined #bitcoin-core-dev
2892020-11-03T15:13:52 <jnewbery> luke-jr: they already lost part of their addrman upgrading to 0.20 because of https://github.com/bitcoin/bitcoin/pull/16702#discussion_r515608294, but I guess no-one noticed
2902020-11-03T15:13:57 <luke-jr> :/
2912020-11-03T15:15:28 <vasild> pr20284 makes it possible to say in peers.dat "this is format=5, but anybody who can read format=3 can also read this one"
2922020-11-03T15:16:29 <luke-jr> maybe the filename should just be changed if that's not the case, in the future?
2932020-11-03T15:16:30 <jnewbery> vasild: yes, that's the functionality we want before the 0.21 release. Just want to make sure people are happy with repurposing nKeySize for versioning.
2942020-11-03T15:17:03 <sdaftuar> jnewbery: sorry if this is a digression, but i might be misunderstanding the issue in #16702 -- it looks like the version check there just causes potential rebucketing, not losing addresses?
2952020-11-03T15:17:07 <gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
2962020-11-03T15:17:42 <wumpus> I think it's a hack but also a clever way of doing so, and he also introduces a real versioning mechanism for next time, so it's only for once
2972020-11-03T15:17:48 <sdaftuar> so the issue that does appear to be there is that downgrading after running 0.20 may be a problem
2982020-11-03T15:18:06 <jnewbery> sdaftuar: it means that entries in new tables can only appear in one new table (or even zero if there's a collision)
2992020-11-03T15:18:11 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
3002020-11-03T15:18:17 <wumpus> definitely don't have any alternative proposals
3012020-11-03T15:18:36 <jnewbery> the point of the serialization format is that entries can appear in multiple new tables
3022020-11-03T15:18:43 *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
3032020-11-03T15:18:44 <vasild> luke-jr: right, filename change is another option
3042020-11-03T15:18:44 <sdaftuar> wumpus: we could rename the peers.dat file for 0.21, and migrate data from the old file to the new one?
3052020-11-03T15:19:23 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
3062020-11-03T15:19:39 <wumpus> sdaftuar: that's a good suggestion too
3072020-11-03T15:19:39 <sdaftuar> jnewbery: hmm i need to read that more carefully then.
3082020-11-03T15:19:59 <jnewbery> sdaftuar: that would definitely prevent being able to keep your addrman data over a downgrade
3092020-11-03T15:20:06 <wumpus> though it'd require updating a lot of documentation all over the place describing bitcoin core's files
3102020-11-03T15:20:18 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
3112020-11-03T15:20:21 <wumpus> everyone is used to "peers.dat"
3122020-11-03T15:20:38 <luke-jr> how often does anyone mess with peers.dat directly?
3132020-11-03T15:20:56 <wumpus> I have no idea
3142020-11-03T15:21:06 <vasild> btw, I did consider the file name change, but preferred the versioning inside the file, instead of using the filesystem for versioning
3152020-11-03T15:21:28 <wumpus> yes, I slightly prefer this as well
3162020-11-03T15:21:51 *** jackgassett <jackgassett!~jackgasse@185.163.110.116> has joined #bitcoin-core-dev
3172020-11-03T15:21:51 <sdaftuar> i think it's okay if once in a while we have to give users annoying instructions for downgrading.
3182020-11-03T15:21:52 <luke-jr> IMO it depends on compatibility
3192020-11-03T15:22:16 <luke-jr> if downgrading doesn't lose the address book, same filename is good; otherwise, a new name avoids losing the old addrman for the old ver
3202020-11-03T15:22:35 <jnewbery> what would the annoying instructions be?
3212020-11-03T15:22:37 <sdaftuar> we could add a tool that either converts formats, or an RPC or something
3222020-11-03T15:22:38 <luke-jr> ^
3232020-11-03T15:22:41 <wumpus> sdaftuar: as I understand older versions will just ignore the incompatible peers.dat, and create a new empty one. But yes I agree. Downgrading is quite a rare event anyhow.
3242020-11-03T15:22:42 <luke-jr> ew
3252020-11-03T15:23:00 *** bosch-0 <bosch-0!~igloo@122-148-254-95.sta.wbroadband.net.au> has quit IRC
3262020-11-03T15:23:06 <sdaftuar> what did we do the last time we changed block file name conventions?
3272020-11-03T15:23:09 <wumpus> sdaftuar: no one is going to go through that much work for their peers table
3282020-11-03T15:23:28 <luke-jr> sdaftuar: iirc hard linked
3292020-11-03T15:23:42 <sdaftuar> luke-jr: that doesn't sound backwards compatible?
3302020-11-03T15:23:46 <luke-jr> why not?
3312020-11-03T15:24:07 <jonatack> I must have lost my peers.dat a couple dozen times while testing the addrv2 PRs. within the next year, anyone still using tor v2 will be forced to upgrade to 0.21 anyway.
3322020-11-03T15:24:11 <sdaftuar> oh we hardlinked new and old filenames together, i see
3332020-11-03T15:24:23 <wumpus> I'm not sure it makes sense to extensively describe alternatives here, we have vasild's work, unless someone really strongly disagrees with it let's review it and get it merged asap
3342020-11-03T15:24:26 <jonatack> unless they don't use tor
3352020-11-03T15:24:42 <jnewbery> I don't think there's any need to change file names. It should be perfectly possible to have internal versioning for changes that are forwards compatible and not forwards compatible. I think that's what 20284 does, but I haven't reviewed it yet.
3362020-11-03T15:25:06 <wumpus> assuming this really needs to go in for 0.21.0-otherwise there's no hurry
3372020-11-03T15:25:18 <aj> afaics, for forwards compatible changes, we just don't bump the version number?
3382020-11-03T15:25:43 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
3392020-11-03T15:25:58 <sipa> argh, timezones
3402020-11-03T15:26:07 <vasild> I started a 0.20.1 node on my new peers.dat and it parsed it without emitting errors, so it is not just "theoretical"
3412020-11-03T15:26:26 <vasild> surely it parsed everything as garbage
3422020-11-03T15:26:56 <wumpus> it's definitely not theoretical
3432020-11-03T15:27:14 <vasild> I don't know why during testing of that change, some weeks ago I always got some read/parse error, which fooled me that old versions fail to parse always
3442020-11-03T15:27:30 <jonatack> vasild: same
3452020-11-03T15:27:37 <vasild> :-D
3462020-11-03T15:28:35 <jnewbery> aj: I think there needs to be versioning to show that there are semantic changes, even if they are forwards compatible
3472020-11-03T15:28:39 <wumpus> garbage addresses would be kind of nasty, especially if they might also be gossiped and thus pollute the rest of the network too
3482020-11-03T15:28:55 <luke-jr> jnewbery: point being if it isn't forwards compatible, the rename keeps the old file for the old version if you downgrade
3492020-11-03T15:29:43 <jnewbery> luke-jr: that's a good point
3502020-11-03T15:30:07 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
3512020-11-03T15:30:17 <jnewbery> So the action is to review 20284, unless anyone has anything important to add
3522020-11-03T15:31:07 <jnewbery> #topic I2P support, some background at vasild/bitcoin/wiki/I2P-connectivity (vasild)
3532020-11-03T15:31:07 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has joined #bitcoin-core-dev
3542020-11-03T15:31:31 <jonatack> When you lose your peers.dat, a new one doesn't seem to take very long to get up to a decent size (40-50k peers)
3552020-11-03T15:31:47 <vasild> https://github.com/vasild/bitcoin/wiki/I2P-connectivity
3562020-11-03T15:32:03 <jnewbery> jonatack: it probably takes longer for your tried tables to get populated
3572020-11-03T15:32:06 <sdaftuar> jonatack: the whole network losing their peers.dat in the event of downgarde might be a scary idea though (imagine a bug in 0.21, say)
3582020-11-03T15:32:21 <sipa> jonatack: that may be deceptive though; just because you have a lot of rumoured IP addresses, they aren't necessarily good
3592020-11-03T15:32:29 <jonatack> good points, thanks
3602020-11-03T15:32:49 *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt> has joined #bitcoin-core-dev
3612020-11-03T15:32:57 <aj> jnewbery: if you bump the version from 5 to 6 (eg), and 6 is "unknown" it will be treated as non-supported, so won't be forward compatible. you need major/minor versions if you want to do that
3622020-11-03T15:33:29 <jnewbery> aj: I think that's effectively what 20284 does
3632020-11-03T15:33:52 <sipa> can we imagine any backward but not forward compatible change?
3642020-11-03T15:33:58 <vasild> aj:
3652020-11-03T15:34:00 <vasild> 16:15 < vasild> pr20284 makes it possible to say in peers.dat "this is format=5, but anybody who can
3662020-11-03T15:34:04 <vasild> read format=3 can also read this one"
3672020-11-03T15:34:44 <aj> vasild, jnewbery: i believe you're both mistaken... it just supports a range: "this code supports versions 3..5". introducing version 6 won't make old code support it
3682020-11-03T15:34:54 <jnewbery> sipa: after #19954, all changes are not forward compatible (because 0.21 onwards will reject any version greater than the one they know)
3692020-11-03T15:34:59 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
3702020-11-03T15:35:02 *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has quit IRC
3712020-11-03T15:35:08 <aj> sipa: backward compatible is easy: if version == 4: ... elif version == 5: ...
3722020-11-03T15:35:17 <jnewbery> aj: +1
3732020-11-03T15:35:26 <sipa> jnewbery: yes, i mean semantically
3742020-11-03T15:35:59 <sipa> is there any change we can imagine to peers.dat that would remain readable by new versions?
3752020-11-03T15:36:17 <aj> sipa: readable by old code, you mean?
3762020-11-03T15:36:29 <sipa> oh
3772020-11-03T15:36:38 * sdaftuar is super confused
3782020-11-03T15:36:38 *** Kiminuo <Kiminuo!~mix@141.98.103.76> has quit IRC
3792020-11-03T15:36:39 <sipa> do i have my forward/backward mixed up?
3802020-11-03T15:36:59 <aj> new code, old peers.dat == backwards compatible
3812020-11-03T15:36:59 *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
3822020-11-03T15:37:01 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz> has joined #bitcoin-core-dev
3832020-11-03T15:37:05 <sdaftuar> sipa: i thought john has his forward/backward mixed up, for what it's worth. and maybe aj too.
3842020-11-03T15:37:05 <aj> old code, new peers.dat == forwards compatible
3852020-11-03T15:37:16 <vasild> awkward
3862020-11-03T15:37:28 <sdaftuar> vasild: +1
3872020-11-03T15:37:31 <aj> "the format is ___ compatible" is how i'm interpreting it
3882020-11-03T15:37:34 *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap> has joined #bitcoin-core-dev
3892020-11-03T15:37:46 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp> has joined #bitcoin-core-dev
3902020-11-03T15:37:47 <sipa> the goal here is to make sure that new versions can keep reading old files?
3912020-11-03T15:38:00 <jnewbery> sdaftuar: wikipedia seems to agree with our definitions: Backward compatibility (sometimes known as backwards compatibility) is a property of a system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system
3922020-11-03T15:38:02 <vasild> no
3932020-11-03T15:38:13 <jnewbery> where the input here is peers.dat
3942020-11-03T15:38:16 <vasild> sipa: new code can always read old files
3952020-11-03T15:38:28 <jnewbery> old peers.dat, new addrman is backwards compatibility
3962020-11-03T15:38:46 <jnewbery> new peers.dat, old addrman is forwards compatibility
3972020-11-03T15:38:47 <sipa> ok so this is about new files being readable by old code? can we imagine a change where that's useful?
3982020-11-03T15:38:58 <sdaftuar> sipa: it's about being able to downgrade
3992020-11-03T15:39:05 <sdaftuar> and not losing all your data
4002020-11-03T15:39:13 <jnewbery> i.e. you right the code in a way that it can handle future changes to format that you don't know about, which is potentially important for downgrades
4012020-11-03T15:40:00 <sipa> sdaftuar: yes, my question is: can we imagine any change to peers.dat where that's even feasible?
4022020-11-03T15:40:23 <luke-jr> sipa: if you don't use Tor, this change is?
4032020-11-03T15:40:31 <sdaftuar> sipa: well it depends on what's on the table? eg if we wrote out the old format for the addresses that are supported by the old format in a file that is readable by old software, then sure
4042020-11-03T15:40:33 <jnewbery> yes, for example the change from 0 to 1 and 1 to 2 both allowed old versions to read new files
4052020-11-03T15:41:05 <sipa> jnewbery: ah, indeed!
4062020-11-03T15:41:18 <sipa> thanks
4072020-11-03T15:41:26 <vasild> sipa: you authored that! :-)
4082020-11-03T15:41:35 <luke-jr> hmm, we could in theory even split a peers-torv3.dat for those, and keep peers.dat as-is and compatibel?
4092020-11-03T15:41:36 <sipa> vasild: it's early
4102020-11-03T15:42:03 <sdaftuar> luke-jr: interesting idea
4112020-11-03T15:42:04 <aj> or put the torv3 addresses as an add-on at the end of the file or something?
4122020-11-03T15:42:30 <wumpus> where does that stop, though... would we have peers-i2p.dat as well?
4132020-11-03T15:42:35 <jonatack> if anyone following along is wondering, we're talking about enum class Format in addrman.h::L269
4142020-11-03T15:42:58 <luke-jr> wumpus: why not?
4152020-11-03T15:43:09 <sipa> this seems hard
4162020-11-03T15:43:10 <luke-jr> is there a reason to throw it all in the same file?
4172020-11-03T15:43:10 <jnewbery> jonatack: well more generally about the Serialize and Unserialize methods for CAddrMan
4182020-11-03T15:43:12 <sdaftuar> wumpus: perhaps eventually files get merged, once old software no longer is a plausible downgrade target?
4192020-11-03T15:43:34 <sipa> peers.dat files aren't just lists of addresses
4202020-11-03T15:43:47 <sipa> they dump the tables and their layout too
4212020-11-03T15:43:47 <jnewbery> we could replace peers.dat with sqlite :)
4222020-11-03T15:43:53 <wumpus> I'm really not sure this is worth so much worrying about, if we're really worried about people downgrading why not make a backup at first run with 0.21.0?
4232020-11-03T15:44:05 <wumpus> then if people downgrade they can restore the backup and *shrug*
4242020-11-03T15:44:07 <sipa> if you split the file in two, you can't just merge them back without losing informatiom
4252020-11-03T15:44:10 <luke-jr> jnewbery: that might not be a bad idea
4262020-11-03T15:44:24 <sdaftuar> wumpus: yes i agree with that type of suggestion too, along the lines of "sometimes it can be annoying to downgrade"
4272020-11-03T15:44:38 <luke-jr> wumpus: how is that different from just using a new filename, except requiring an extra step to downgrade?
4282020-11-03T15:45:00 <wumpus> luke-jr: it keeps the filename the same for the bulk of the users
4292020-11-03T15:45:23 <wumpus> the non-downgrading path is likely be far most popular, or at least one'd hope :)
4302020-11-03T15:45:50 <wumpus> in any case, we needa solution here fairly quickly
4312020-11-03T15:46:21 <jnewbery> wumpus: I agree that it's more likely, but I think we should strive to make downgrades across a single version seamless, just in case we ship a bad bug and need people to roll back
4322020-11-03T15:46:36 <jnewbery> *upgrading is the more likely path than downgrading
4332020-11-03T15:46:55 <jnewbery> ok, we're running out of time and there are a couple more topics, so perhaps we should move on
4342020-11-03T15:46:56 <wumpus> I'm not sure last-minute changes lke 'sort peers.dat per network' or other complete changes to handling peers database
4352020-11-03T15:47:04 *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt> has quit IRC
4362020-11-03T15:47:06 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz> has quit IRC
4372020-11-03T15:47:09 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp> has quit IRC
4382020-11-03T15:47:11 *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap> has quit IRC
4392020-11-03T15:47:17 <sipa> wumpus: agree
4402020-11-03T15:47:29 <jnewbery> vasild: did you have anything you wanted to add about I2P support?
4412020-11-03T15:47:49 <ariard> jnewbery: I'm fine to report mine next time
4422020-11-03T15:48:20 <jnewbery> ariard: thanks. Maybe a good idea so people have some time to think about it before the meeting
4432020-11-03T15:48:25 <vasild> Anybody interested in I2P support - see https://github.com/vasild/bitcoin/wiki/I2P-connectivity and discuss here, I guess after the meeting or anytime
4442020-11-03T15:48:55 <sdaftuar> i've got a question about i2p (applies to any new exotic network, even tor stuff that we're doing) - what is our undestanding for how these addresses get gossiped to peers that support the network type?
4452020-11-03T15:48:59 <wumpus> jnewbery: yes, agree, it's kind of nasty that this issue comes up so last minute
4462020-11-03T15:49:38 <sipa> sdaftuar: i2p/cjdns do not get rumoured by the current code, at all
4472020-11-03T15:50:14 <vasild> sipa: no, they would get rumored if the node has connectivity to i2p
4482020-11-03T15:50:26 <vasild> or am I mistaken...
4492020-11-03T15:50:28 <wumpus> cjdns not because it uses IPv6 addresses in a range we consider local / unroutable?
4502020-11-03T15:50:34 <sipa> vasild: which isn't possible.on the current code :)
4512020-11-03T15:50:40 <sipa> see #20119
4522020-11-03T15:50:41 <gribble> https://github.com/bitcoin/bitcoin/issues/20119 | BIP155 follow-ups by sipa · Pull Request #20119 · bitcoin/bitcoin · GitHub
4532020-11-03T15:50:54 <sdaftuar> so the basic idea is that if we know how to reach a network, we'll rumor it to 2 peers or so
4542020-11-03T15:51:18 <sdaftuar> and if we don't, it still goes to 1 i think? is that correct?
4552020-11-03T15:51:30 <sipa> sdaftuar: there are classes now
4562020-11-03T15:51:34 <vasild> sdaftuar: yes
4572020-11-03T15:51:34 <jnewbery> sdaftuar: 1.5 now I think
4582020-11-03T15:51:50 <sipa> 1) reachable networks get rumoured 2x
4592020-11-03T15:51:55 <vasild> sdaftuar: see RelayAddress() in the case fReachable==true
4602020-11-03T15:52:09 <sipa> 2) unreachable ipv4/ipv6/torv2/torv3 get rumoured 1.5x
4612020-11-03T15:52:18 <jonatack> see #19728
4622020-11-03T15:52:20 <gribble> https://github.com/bitcoin/bitcoin/issues/19728 | Increase the ip address relay branching factor for unreachable networks by sipa · Pull Request #19728 · bitcoin/bitcoin · GitHub
4632020-11-03T15:52:24 <sipa> 3) unreachable others do not get rumoured at all
4642020-11-03T15:52:43 <vasild> #20254 makes i2p reachable
4652020-11-03T15:52:45 <gribble> https://github.com/bitcoin/bitcoin/issues/20254 | Add I2P support using statically configured destinations by vasild · Pull Request #20254 · bitcoin/bitcoin · GitHub
4662020-11-03T15:54:41 <vasild> btw, in I2P we can see the peer's address and be sure data comes from him (the address is a hash of his public key)
4672020-11-03T15:54:43 <sdaftuar> sipa: thanks. one more question, how do we decide what address to advertise ourselves as, if we're reachable in multiple ways?
4682020-11-03T15:54:57 <luke-jr> vasild: same for Tor? :p
4692020-11-03T15:55:31 <vasild> luke-jr: no, in Tor we don't see the address of the peer that connected to us
4702020-11-03T15:55:47 <luke-jr> oh, right
4712020-11-03T15:55:59 <sipa> "tor has no from address"
4722020-11-03T15:56:03 <luke-jr> XD
4732020-11-03T15:56:07 <wumpus> heh
4742020-11-03T15:56:12 <vasild> so in I2P we have P2P encryption by default :-)
4752020-11-03T15:56:25 <jnewbery> sdaftuar: that logic is in AdvertiseLocal() in net.cpp
4762020-11-03T15:56:35 <sipa> vasild: with public identities, though :(
4772020-11-03T15:56:48 <vasild> yes
4782020-11-03T15:57:04 <luke-jr> kinda by design in i2p?
4792020-11-03T15:57:16 <vasild> yes
4802020-11-03T15:57:39 <sipa> sdaftuar: among the local addresses compatible with that peer, the one that has received the most mentions in incomimg version messages
4812020-11-03T15:58:07 <sipa> which reminds me: we can't put torv3/i2p/cjdns in version messages, so those will never receive any mentions
4822020-11-03T15:58:09 <sdaftuar> sipa: it seems like for something like adding a new newtork type, sometimes we'll want to advertise our i2p address instead right?
4832020-11-03T15:58:40 <sdaftuar> sipa: oh taht seems important
4842020-11-03T15:58:59 <jnewbery> do we need a new version version? :)
4852020-11-03T15:59:14 <sdaftuar> jnewbery: i think we can just add data on to the end and no one will mind
4862020-11-03T15:59:33 *** Pasta[m] <Pasta[m]!pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw> has joined #bitcoin-core-dev
4872020-11-03T15:59:55 <sipa> i'm not sure this is useful for those networks
4882020-11-03T16:00:08 <sipa> as there isn't any useful compatibility matrix for them
4892020-11-03T16:00:10 *** Pasta[m] <Pasta[m]!pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw> has quit IRC
4902020-11-03T16:00:15 <jnewbery> that's time!
4912020-11-03T16:00:18 <jnewbery> #endmeeting
4922020-11-03T16:00:18 <lightningbot> Meeting ended Tue Nov 3 16:00:18 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4932020-11-03T16:00:18 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-03-15.00.html
4942020-11-03T16:00:18 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-03-15.00.txt
4952020-11-03T16:00:18 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-03-15.00.log.html
4962020-11-03T16:00:20 <sdaftuar> sipa: address rumoring isn't useful, or something else?
4972020-11-03T16:00:47 <jonasschnelli> oh.. I missed the meeting.
4982020-11-03T16:00:48 <wumpus> sipa: there was the idea to add that address in the 'sendaddrv2' message
4992020-11-03T16:00:50 <vasild> I guess sipa means the "voting"
5002020-11-03T16:00:58 <sdaftuar> ah
5012020-11-03T16:01:04 <vasild> or how many times the address receives "mentions"
5022020-11-03T16:01:04 <aj> zzz
5032020-11-03T16:01:07 * luke-jr gives jonasschnelli the mic
5042020-11-03T16:01:10 <jonasschnelli> I wanted to ask about BIP324's rekeying
5052020-11-03T16:01:11 <sipa> sdaftuar: scoring your local addresses using incoming version mentions isn't useful for these separate networls
5062020-11-03T16:01:24 <sipa> jonasschnelli: ongoing discussion, it seems!
5072020-11-03T16:01:25 <sdaftuar> yeah i was thinking that if we are trying to bootstratp a new type of address, we need to proactively advertise that address even to peers who don't understand it
5082020-11-03T16:01:26 <jonasschnelli> sipa: may you have 10 minutes for discussion the 1s rekey approach
5092020-11-03T16:01:33 <sdaftuar> so that eventually peers that do support it, receive it
5102020-11-03T16:01:56 <sipa> sdaftuar: that's a good point
5112020-11-03T16:01:56 <wumpus> sipa: (which would be easier to add new things to than the version message, and is relevant to the same functionality)
5122020-11-03T16:02:30 <vasild> sdaftuar: my thought exactly, but we decided to not relay i2p addresses by nodes that are not connected to i2p; at least in 0.21
5132020-11-03T16:02:33 <jonasschnelli> sipa: indeed... its ongoing. But assume a 1s rekeying interval would imply some sort of a rekey-message,.. right?
5142020-11-03T16:02:34 <sipa> jonasschnelli: my current thinking is that doing rekeying at the key stream level is super cheap and simple
5152020-11-03T16:03:09 <jonasschnelli> rekey on every ping/pong would be less complicated to implement (rather then time based)
5162020-11-03T16:03:09 <sipa> jonasschnelli: and i see no reason to have it at the application level as well if we do that
5172020-11-03T16:03:23 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
5182020-11-03T16:03:31 <sipa> jonasschnelli: i absolutely don't suggest rekeying every secomd :)
5192020-11-03T16:04:09 <jonasschnelli> sipa: at stream level would be something like basically rekey on after message?
5202020-11-03T16:04:21 <vasild> there is already one bitcoin node listening at yfsvsy467mt5xafaq7zaukkjyzehvmew445yaaejvrwpk53acejq.b32.i2p (irc gossip :-D)
5212020-11-03T16:04:22 <jonasschnelli> "after every message
5222020-11-03T16:04:25 <sipa> jonasschnelli: no, every X bytes
5232020-11-03T16:04:35 <sdaftuar> vasild: nice :)
5242020-11-03T16:04:51 <jonasschnelli> sipa: okay. What we have now.. but probably smaller than 1GB
5252020-11-03T16:04:58 <sipa> jonasschnelli: no!
5262020-11-03T16:05:07 <sipa> it's currently done at the layer above
5272020-11-03T16:05:19 <sipa> this would let you just build it inside chacha
5282020-11-03T16:05:21 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
5292020-11-03T16:05:29 <jonasschnelli> ah. Built into the AEAD
5302020-11-03T16:05:30 <ariard> jonasschnelli: I think you can pick up a value based on blocks frequency if you want something to happen every Y period of time?
5312020-11-03T16:05:35 <sipa> without having a bit to signal rekeying or so
5322020-11-03T16:05:51 <sipa> ariard: that's just as hard
5332020-11-03T16:06:22 <sipa> jonasschnelli: this would give you forward secrecy (also a weird term
5342020-11-03T16:06:35 <jonasschnelli> What if the byte limit hits in the middle of a message payload?
5352020-11-03T16:06:40 <sipa> for ~free, at the byte level if you wanted to
5362020-11-03T16:06:45 <sipa> jonasschnelli: yes, so what?
5372020-11-03T16:06:59 <sipa> the stream cipher does it automatically
5382020-11-03T16:07:06 <ariard> sipa: do you mean byte-accounting is hard to get right?
5392020-11-03T16:07:18 <sipa> ariard: no, byte-accounting is trivial
5402020-11-03T16:07:23 <jonasschnelli> sipa: hmm... but the mAC?
5412020-11-03T16:07:35 <sipa> jonasschnelli: the mac keys don't cycle
5422020-11-03T16:07:45 <sipa> only the encryption keys
5432020-11-03T16:08:47 <jonasschnelli> but the current MAC key is derived from the chacha20 stream
5442020-11-03T16:09:19 <sipa> jonasschnelli: yes that'll need to change
5452020-11-03T16:09:24 *** lightlike <lightlike!~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de> has quit IRC
5462020-11-03T16:09:31 <jonasschnelli> sipa: hmm...
5472020-11-03T16:09:35 <sipa> have a separate stream where the mac keys are drawn from, for example
5482020-11-03T16:10:14 <sipa> but it means you can drop the signalling of rekeying etc
5492020-11-03T16:10:31 <sipa> and concerns about peers not doing it, or doing it too often
5502020-11-03T16:12:03 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
5512020-11-03T16:12:37 *** kljasdfvv <kljasdfvv!~flack@p200300d46f24de007887c37597c774bc.dip0.t-ipconnect.de> has quit IRC
5522020-11-03T16:13:52 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
5532020-11-03T16:14:14 <sipa> as long as we don't worry about secrecy in the other direction (which the current bip324 writeup doesn't, afaik), i think this is very much preferable
5542020-11-03T16:14:17 <jonasschnelli> sipa: do the benefits of this justify further deviation from the "well tested" ChaCha20Poly1305@openssh?
5552020-11-03T16:14:28 <sipa> jonasschnelli: we're already deviating from it
5562020-11-03T16:14:37 <jonasschnelli> sipa: but in a pretty minor way
5572020-11-03T16:15:19 *** Kiminuo <Kiminuo!~mix@141.98.103.76> has joined #bitcoin-core-dev
5582020-11-03T16:15:57 <sipa> jonasschnelli: maybe superficially... but openssh rekeys by redoing DH, no?
5592020-11-03T16:16:01 <jonasschnelli> sipa: what do you think are the benefits over a rekeying signal (where we can detect DoS or exceeded limits)?
5602020-11-03T16:16:19 <jonasschnelli> sipa: probably... haven't looked at their rekeying.
5612020-11-03T16:16:39 <jonasschnelli> but the AEAD has no rekeying (@openssh and @Bitcoin)
5622020-11-03T16:17:00 <sipa> so doing rekeying by redoing DH makes sense, as it gives you secrecy in both directions
5632020-11-03T16:17:59 <jonasschnelli> Yes. Our rekeying does a independent rekey per direction,... whenever the limits are reached.
5642020-11-03T16:18:01 <sipa> rekeying by hashing only gives you forward secrecy, not the other direction
5652020-11-03T16:18:39 <sipa> but as long as we only care about forward secrecy... doing the whole signalling thing is kind of overkill
5662020-11-03T16:18:43 <jonasschnelli> I see
5672020-11-03T16:18:53 <jonasschnelli> I see what you mean with direction noew
5682020-11-03T16:18:55 <jonasschnelli> *now
5692020-11-03T16:19:05 <sipa> you can get cheap forward secrecy at the byte level, instead of at the 1 GB level
5702020-11-03T16:19:55 <sipa> (by generating 4096 bytes of stream cipher ahead of time, rekeying, and then throwing the stream cipher bytes away as they get used)
5712020-11-03T16:20:23 <sipa> you can't do that with 1 GB of material, and can't do that if you don't know when the other party is going to reky
5722020-11-03T16:21:20 <sipa> anyway, my point is: not redoing DH is already a big conceptual departure from the existing protocol
5732020-11-03T16:21:23 <jonasschnelli> I think I understand this... I'm just unsure about the MAC construct... and concerned about complication of the implementation (with its risks)
5742020-11-03T16:22:38 <sipa> yeah
5752020-11-03T16:23:06 <sipa> to be honest, i habe difficulty remember the exact way the stream/keys are constructed now too
5762020-11-03T16:23:26 <sipa> this may simplify it...
5772020-11-03T16:23:29 <jonasschnelli> sipa: we rekey with SHA256(SHA256(session ID || old_symmetric_cipher_key))... wouldn't an attacker stealing the symmetric be unable to go in both directions?
5782020-11-03T16:23:45 <jonasschnelli> since the "session ID" requires the ECDH key
5792020-11-03T16:23:58 <sipa> jonasschnelli: if an attacker knows the old key, they can also apply the hashing
5802020-11-03T16:24:08 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
5812020-11-03T16:24:23 <jonasschnelli> sipa: the attacked doesn't know the session ID, right?
5822020-11-03T16:24:33 <sipa> well in this scenario they do!
5832020-11-03T16:24:36 *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has joined #bitcoin-core-dev
5842020-11-03T16:25:33 <jonasschnelli> sipa: So the scenario is that ECDH is broken?
5852020-11-03T16:25:51 <sipa> jonasschnelli: or they broke into your machine and dumped its memory
5862020-11-03T16:26:29 <sipa> forward secrecy protects against that case... if an attacker does that, they *still* can't decrypt old messages
5872020-11-03T16:27:16 <jonasschnelli> okay.. got it
5882020-11-03T16:27:19 <sipa> but the other direction... you can't prevent an attacker who read your RAM from decrypting future messages, unless you redo DH
5892020-11-03T16:27:41 <jonasschnelli> including re-generation of emphemeral keys,.. right?
5902020-11-03T16:27:55 <sipa> yes, that's what DH does
5912020-11-03T16:28:03 <jonasschnelli> indeed. :)
5922020-11-03T16:28:44 *** tralfaz <tralfaz!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
5932020-11-03T16:29:08 <jonasschnelli> and you think that backward secrecy (probably called different) can be achived by altering the AEAD and including a deterministic rekeying?
5942020-11-03T16:29:27 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
5952020-11-03T16:29:40 *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
5962020-11-03T16:29:47 *** tralfaz is now known as davterra
5972020-11-03T16:30:07 <jonasschnelli> or has the AEAD-inner-rekeyng nothing to do with the secrecy directions?
5982020-11-03T16:30:43 <sipa> that only provides forward secrecy
5992020-11-03T16:30:51 <sipa> but it can do it at the byte level
6002020-11-03T16:31:07 <jonasschnelli> more elegant but same level of security as the current proposal?
6012020-11-03T16:31:13 <sipa> indeed
6022020-11-03T16:31:33 <jonasschnelli> okay... got it.
6032020-11-03T16:31:50 <sipa> perhaps we want some affordance for redoing DH too, but we can probably just disconnect and reconnect for that...
6042020-11-03T16:32:00 <jonasschnelli> I haven't seen BIP324 discussion about the missing backward secrecy of the current rekeying approach.
6052020-11-03T16:32:18 <sipa> i think it's less of a concern
6062020-11-03T16:32:27 <sipa> but i'll try to summerize
6072020-11-03T16:32:34 <sipa> on githun
6082020-11-03T16:32:40 <jonasschnelli> great,... thanks.
6092020-11-03T16:33:07 <jonasschnelli> I'd like to not loose to much momentum on the implementation. But also,... not urging to stop improving the protocol. :)
6102020-11-03T16:34:09 *** Pavlenex <Pavlenex!~Thunderbi@141.98.103.251> has quit IRC
6112020-11-03T16:34:12 <jonasschnelli> However... thanks sipa for explaining!
6122020-11-03T16:34:56 *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-tiujvomwsqovicqc> has joined #bitcoin-core-dev
6132020-11-03T16:34:56 *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-sctramrejhkepioh> has joined #bitcoin-core-dev
6142020-11-03T16:34:56 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-uxpvzzgmfufkdehc> has joined #bitcoin-core-dev
6152020-11-03T16:34:56 *** TheFuzzStone[m] <TheFuzzStone[m]!thefuzzsto@gateway/shell/matrix.org/x-fdqmwngbisvjvofx> has joined #bitcoin-core-dev
6162020-11-03T16:34:56 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-zawdlorjbkpbblko> has joined #bitcoin-core-dev
6172020-11-03T16:34:56 *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-bpoimagdjgyeoxrb> has joined #bitcoin-core-dev
6182020-11-03T16:35:02 *** tianshi[m] <tianshi[m]!tianshimat@gateway/shell/matrix.org/x-mpipzilseonjtdcn> has joined #bitcoin-core-dev
6192020-11-03T16:35:02 *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-soiqapnxaxpgdwts> has joined #bitcoin-core-dev
6202020-11-03T16:39:04 *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has quit IRC
6212020-11-03T16:45:40 *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
6222020-11-03T16:46:12 *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
6232020-11-03T16:53:59 *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has quit IRC
6242020-11-03T16:57:29 *** spinza <spinza!~spin@102.132.245.16> has quit IRC
6252020-11-03T16:58:07 *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
6262020-11-03T16:59:27 *** spinza <spinza!~spin@102.132.245.16> has joined #bitcoin-core-dev
6272020-11-03T17:20:56 *** pergaminho <pergaminho!~Cleber@189.26.121.248> has joined #bitcoin-core-dev
6282020-11-03T17:25:46 *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has joined #bitcoin-core-dev
6292020-11-03T17:28:25 <wumpus> vasild: here is already one bitcoin node listening at yfsvsy467mt5xafaq7zaukkjyze hvmew445yaaejvrwpk53acejq.b32.i2p (irc gossip :-D) <- good to know, i'll have a look at setting up I2P too
6302020-11-03T17:29:55 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
6312020-11-03T17:35:01 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
6322020-11-03T17:35:41 *** spinza <spinza!~spin@102.132.245.16> has quit IRC
6332020-11-03T17:37:28 *** spinza <spinza!~spin@102.132.245.16> has joined #bitcoin-core-dev
6342020-11-03T17:42:15 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
6352020-11-03T17:56:30 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
6362020-11-03T18:00:01 *** jackgassett <jackgassett!~jackgasse@185.163.110.116> has quit IRC
6372020-11-03T18:10:16 *** promag_ <promag_!~promag@188.250.84.129> has joined #bitcoin-core-dev
6382020-11-03T18:14:55 *** promag_ <promag_!~promag@188.250.84.129> has quit IRC
6392020-11-03T18:19:15 *** kristapsk_ is now known as kristapsk
6402020-11-03T18:20:19 *** hardaker <hardaker!~hardaker@139.28.218.148> has joined #bitcoin-core-dev
6412020-11-03T18:31:55 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC
6422020-11-03T18:36:40 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has joined #bitcoin-core-dev
6432020-11-03T18:41:46 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
6442020-11-03T18:46:25 *** jesseposner <jesseposner!~jesse@98.37.146.62> has quit IRC
6452020-11-03T18:53:31 *** joerodgers <joerodgers!~joerodger@86.106.121.56> has quit IRC
6462020-11-03T18:55:19 *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
6472020-11-03T19:02:46 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
6482020-11-03T19:03:01 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
6492020-11-03T19:10:56 *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has quit IRC
6502020-11-03T19:21:23 *** jesseposner <jesseposner!~jesse@98.37.146.62> has joined #bitcoin-core-dev
6512020-11-03T19:32:31 *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
6522020-11-03T19:33:25 *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
6532020-11-03T19:35:01 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC
6542020-11-03T19:39:17 *** lightlike <lightlike!~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
6552020-11-03T19:44:44 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
6562020-11-03T19:47:56 *** mol <mol!~mol@unaffiliated/molly> has quit IRC
6572020-11-03T20:08:05 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC
6582020-11-03T20:16:26 *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has joined #bitcoin-core-dev
6592020-11-03T20:32:11 *** lightlike <lightlike!~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de> has quit IRC
6602020-11-03T21:00:02 *** hardaker <hardaker!~hardaker@139.28.218.148> has quit IRC
6612020-11-03T21:03:18 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
6622020-11-03T21:13:28 *** pergaminho <pergaminho!~Cleber@189.26.121.248> has quit IRC
6632020-11-03T21:20:18 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC
6642020-11-03T21:21:35 *** zelazny <zelazny!~zelazny@178.162.209.171> has joined #bitcoin-core-dev
6652020-11-03T21:28:23 <jonatack> vasild: i think i'm connected to your i2p peer
6662020-11-03T21:28:52 *** robert_spigler[m <robert_spigler[m!robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr> has joined #bitcoin-core-dev
6672020-11-03T21:30:06 *** promag <promag!~promag@188.250.84.129> has quit IRC
6682020-11-03T21:33:44 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC
6692020-11-03T21:45:12 *** justanotheruser is now known as mrdulus
6702020-11-03T21:45:35 *** robert_spigler[m <robert_spigler[m!robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr> has left #bitcoin-core-dev
6712020-11-03T21:46:23 *** mrdulus is now known as justan0theruser
6722020-11-03T21:51:39 *** mdunnio <mdunnio!~mdunnio@208.59.170.5> has joined #bitcoin-core-dev
6732020-11-03T21:56:29 <amiti> hi! does anyone actively use `-loadblock` / have current use cases?
6742020-11-03T21:57:57 *** tryphe_ is now known as tryphe
6752020-11-03T21:58:17 <sipa> amiti: did yiu see my response on the issue?
6762020-11-03T21:58:34 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
6772020-11-03T21:59:12 <amiti> yeah, you said "I don't know if those see much use still", so I thought I'd ask more people :)
6782020-11-03T21:59:38 <sipa> amiti: right
6792020-11-03T21:59:42 <amiti> (for anyone wondering, #19594)
6802020-11-03T21:59:44 <gribble> https://github.com/bitcoin/bitcoin/issues/19594 | refactor: Make mapBlocksUnknownParent local, and rename it by hebasto · Pull Request #19594 · bitcoin/bitcoin · GitHub
6812020-11-03T22:00:18 <sipa> i mean: it was intended for supporting bootstrap.dat, and i think that's the only use case
6822020-11-03T22:00:30 <sipa> if there is anyone actively relying on that feature i don't know
6832020-11-03T22:00:47 <amiti> gotcha. ok maybe I could rephrase the question as- does anyone actively use bootstrap.dat?
6842020-11-03T22:02:18 <luke-jr> it's not even maintained anymore
6852020-11-03T22:03:09 <sipa> not by us
6862020-11-03T22:03:18 <sipa> though some sites provide them
6872020-11-03T22:04:07 <luke-jr> updated? O.o
6882020-11-03T22:04:22 <sipa> since the improved block download logic in 0.10 there is much less use for it, as just syncing from random peers is likely faster than downloading + processing in sequence
6892020-11-03T22:04:35 <sipa> https://flo.sh/download-bitcoin-blockchain-bootstrap/ apparently has a fairly recent one
6902020-11-03T22:04:50 <luke-jr> TIL
6912020-11-03T22:05:03 <luke-jr> I suppose it might be handy for people syncing offline PCs
6922020-11-03T22:05:55 <sipa> TIL also
6932020-11-03T22:06:33 <luke-jr> hmm, I should probably stop parsing my entire debug.log every hour
6942020-11-03T22:06:42 <luke-jr> it's getting behind XD
6952020-11-03T22:07:23 *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
6962020-11-03T22:08:28 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
6972020-11-03T22:10:07 *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has joined #bitcoin-core-dev
6982020-11-03T22:10:38 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc> has joined #bitcoin-core-dev
6992020-11-03T22:12:03 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
7002020-11-03T22:12:04 *** vasild_ is now known as vasild
7012020-11-03T22:12:55 <amiti> do I understand correctly: the idea of bootstrap.dat / loadblock is that you input a file with the sequential blocks to process. in the current state, what are the differences from importing the datadir and reindexing? / would there be any advantage? (ofc one difference is that loadblock requires the blocks to be in order)
7022020-11-03T22:13:37 <sipa> i expect you can just rename a bootstrap.dat file to be blk00000.dat, and run -reindex
7032020-11-03T22:14:26 <sipa> amiti: i think part is that you don't want to encourage people copying entire datadirs, as chainstates don't get re-verified
7042020-11-03T22:15:00 <sipa> and anything that involves manually messing with the datadir is probably reserved for people who know what they're doing anyway
7052020-11-03T22:16:03 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
7062020-11-03T22:17:15 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc> has left #bitcoin-core-dev
7072020-11-03T22:18:17 *** filchef <filchef!~filchef@212.104.97.177> has quit IRC
7082020-11-03T22:19:16 <amiti> oh I see, so loadblock does more verification than reindexing? ok I'm not super familiar with reindexing so I'll go learn more
7092020-11-03T22:19:35 <luke-jr> loadblock just treats the file as an untrusted peer
7102020-11-03T22:20:24 <sipa> amiti: no, it's exactly the same
7112020-11-03T22:20:49 <sipa> amiti: but if you copy a *chainstate* from someone (not just block files), they don't get re-verified (because your node wouldn't know it's operating on an imported copy)
7122020-11-03T22:20:59 <amiti> ahhhh I see
7132020-11-03T22:22:02 <sipa> still, i don't have a good answer for whether it's worth supporting -loadblock if it is a burden to maintain... i suspect not
7142020-11-03T22:22:11 <sipa> i also don't think it's a large burden, thoug
7152020-11-03T22:23:05 * midnight makes use of loadblocks still fwiw
7162020-11-03T22:23:12 <sipa> good to know!
7172020-11-03T22:23:17 <amiti> yeah, for me the first question is "is it still useful". then the next question is "is it a higher burden to maintain, or to remove?"
7182020-11-03T22:23:41 <sipa> i don't think i've personally used it for many years
7192020-11-03T22:23:57 <amiti> midnight: ooo, willing to tell us more about how/why you use it?
7202020-11-03T22:32:39 <midnight> sure. I use it as a way of explicitly migrating block data between machines; also occasionally to (expensively) explore early blocks and early large-block-number reorgs. Mostly as a way to ensure migrated block data is reverified with modern versions as my node instances are typically very long-lived.
7212020-11-03T22:33:37 <midnight> I'd be completely fine with just a network-based block injector if it exists.
7222020-11-03T22:35:06 <amiti> okay gotcha. thanks!
7232020-11-03T22:35:47 <midnight> \o I wouldn't be too broken-up about it being removed, as long as it's still possible for me to help seed my friends with a copy of current block data from my own nodes somehow.
7242020-11-03T22:36:02 <midnight> (so, I test it first before handing it to them)
7252020-11-03T22:36:57 *** Kiminuo <Kiminuo!~mix@141.98.103.76> has quit IRC
7262020-11-03T22:41:24 <amiti> ð
7272020-11-03T22:53:04 *** quijote_ <quijote_!~dqx@unaffiliated/dqx> has quit IRC
7282020-11-03T22:53:51 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-njtrdildhtememmh> has joined #bitcoin-core-dev
7292020-11-03T22:55:28 *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
7302020-11-03T22:57:30 *** mdunnio <mdunnio!~mdunnio@208.59.170.5> has quit IRC
7312020-11-03T22:58:58 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
7322020-11-03T23:03:19 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
7332020-11-03T23:04:27 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has joined #bitcoin-core-dev
7342020-11-03T23:09:57 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
7352020-11-03T23:10:34 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
7362020-11-03T23:13:24 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
7372020-11-03T23:15:10 *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
7382020-11-03T23:16:13 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
7392020-11-03T23:20:25 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
7402020-11-03T23:23:35 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
7412020-11-03T23:24:19 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
7422020-11-03T23:28:07 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
7432020-11-03T23:28:25 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
7442020-11-03T23:29:10 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has quit IRC
7452020-11-03T23:29:25 *** kexkey <kexkey!~kexkey@static-198-54-132-118.cust.tzulo.com> has quit IRC
7462020-11-03T23:33:38 *** flag <flag!~flag@net-93-66-105-239.cust.vodafonedsl.it> has quit IRC
7472020-11-03T23:39:30 *** windsok_ <windsok_!~windsok@rarepepe.cash> has quit IRC
7482020-11-03T23:39:30 *** windsok_ <windsok_!~windsok@unaffiliated/windsok> has joined #bitcoin-core-dev
7492020-11-03T23:39:45 *** windsok_ is now known as windsok