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