1 2020-11-03T00:00:02  *** d_ed1 <d_ed1!~d_ed@> has quit IRC
  2 2020-11-03T00:21:49  *** bruceadams <bruceadams!~bruceadam@> has joined #bitcoin-core-dev
  3 2020-11-03T00:21:52  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
  4 2020-11-03T00:21:57  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
  5 2020-11-03T00:22:11  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
  6 2020-11-03T00:27:25  *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
  7 2020-11-03T00:29:26  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
  8 2020-11-03T01:21:58  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
  9 2020-11-03T01:22:12  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 10 2020-11-03T01:40:02  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 11 2020-11-03T01:40:03  <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/ca1886056325...8387f832d693
 12 2020-11-03T01:40:04  <bitcoin-git> bitcoin/master daf5553 Suhas Daftuar: Avoid calling CAddrMan::Connected() on block-relay-only peer addresses
 13 2020-11-03T01:40:05  <bitcoin-git> bitcoin/master 4fe338a Suhas Daftuar: Call CAddrMan::Good() on block-relay-only peer addresses
 14 2020-11-03T01:40:06  <bitcoin-git> bitcoin/master e8b215a Suhas Daftuar: Refactor test for existing peer connection into own function
 15 2020-11-03T01:40:07  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 16 2020-11-03T01:40:22  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 17 2020-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
 18 2020-11-03T01:40:23  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 19 2020-11-03T01:53:44  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
 20 2020-11-03T01:54:27  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
 21 2020-11-03T02:17:11  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
 22 2020-11-03T02:17:13  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 23 2020-11-03T02:19:07  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
 24 2020-11-03T02:21:58  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 25 2020-11-03T02:22:12  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 26 2020-11-03T02:28:47  *** Squidicc <Squidicc!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has joined #bitcoin-core-dev
 27 2020-11-03T02:29:53  *** Squidicuz <Squidicuz!~squid@pool-72-74-34-120.bstnma.fios.verizon.net> has quit IRC
 28 2020-11-03T02:30:42  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
 29 2020-11-03T02:37:51  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC
 30 2020-11-03T02:38:16  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
 31 2020-11-03T02:40:43  *** Klox0480931863 <Klox0480931863!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC
 32 2020-11-03T02:42:58  *** Klox0480931863 <Klox0480931863!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
 33 2020-11-03T03:00:01  *** bruceadams <bruceadams!~bruceadam@> has quit IRC
 34 2020-11-03T03:16:05  *** bosch-0 <bosch-0!7a94fe5f@122-148-254-95.sta.wbroadband.net.au> has joined #bitcoin-core-dev
 35 2020-11-03T03:16:33  <bosch-0> Yo
 36 2020-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
 37 2020-11-03T03:16:50  <bosch-0> If ya not too busy
 38 2020-11-03T03:21:57  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 39 2020-11-03T03:22:11  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 40 2020-11-03T03:22:25  *** jMCg <jMCg!~jMCg@> has joined #bitcoin-core-dev
 41 2020-11-03T03:27:10  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
 42 2020-11-03T03:34:04  *** pinheadm_ <pinheadm_!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC
 43 2020-11-03T03:42:41  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 44 2020-11-03T03:49:35  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
 45 2020-11-03T04:06:21  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 46 2020-11-03T04:09:53  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
 47 2020-11-03T04:11:03  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
 48 2020-11-03T04:15:02  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
 49 2020-11-03T04:21:58  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 50 2020-11-03T04:22:12  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 51 2020-11-03T04:25:47  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
 52 2020-11-03T04:25:50  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 53 2020-11-03T04:31:19  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 54 2020-11-03T04:33:58  *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 55 2020-11-03T04:34:55  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
 56 2020-11-03T04:37:12  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
 57 2020-11-03T04:38:32  *** molz_ <molz_!~mol@unaffiliated/molly> has quit IRC
 58 2020-11-03T04:56:00  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 59 2020-11-03T04:57:44  *** justan0theruser <justan0theruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 60 2020-11-03T04:58:04  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC
 61 2020-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?
 62 2020-11-03T05:26:57  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 63 2020-11-03T05:27:11  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 64 2020-11-03T06:00:02  *** jMCg <jMCg!~jMCg@> has quit IRC
 65 2020-11-03T06:10:08  *** justan0theruser <justan0theruser!~justanoth@unaffiliated/justanotheruser> has quit IRC
 66 2020-11-03T06:11:25  *** IGHOR <IGHOR!~quassel@> has quit IRC
 67 2020-11-03T06:17:32  *** jesseposner <jesseposner!~jesse@> has quit IRC
 68 2020-11-03T06:21:26  *** IGHOR <IGHOR!~quassel@> has joined #bitcoin-core-dev
 69 2020-11-03T06:21:31  *** bosch-0 <bosch-0!7a94fe5f@122-148-254-95.sta.wbroadband.net.au> has quit IRC
 70 2020-11-03T06:22:00  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 71 2020-11-03T06:22:14  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 72 2020-11-03T06:22:18  *** secdragon <secdragon!~secdragon@> has joined #bitcoin-core-dev
 73 2020-11-03T06:29:28  *** AdulrunaRedviva <AdulrunaRedviva!c3d69d22@> has joined #bitcoin-core-dev
 74 2020-11-03T06:47:41  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 75 2020-11-03T06:48:21  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
 76 2020-11-03T06:52:50  *** jesseposner <jesseposner!~jesse@> has quit IRC
 77 2020-11-03T06:54:56  *** filchef <filchef!~filchef@> has joined #bitcoin-core-dev
 78 2020-11-03T07:20:47  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
 79 2020-11-03T07:21:57  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 80 2020-11-03T07:22:11  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 81 2020-11-03T07:37:16  *** kexkey <kexkey!~kexkey@static-198-54-132-134.cust.tzulo.com> has quit IRC
 82 2020-11-03T07:41:45  *** jesseposner <jesseposner!~jesse@> has quit IRC
 83 2020-11-03T07:42:04  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
 84 2020-11-03T07:56:10  *** Cory <Cory!~Cory@unaffiliated/cory> has quit IRC
 85 2020-11-03T08:03:28  *** Cory <Cory!~Cory@unaffiliated/cory> has joined #bitcoin-core-dev
 86 2020-11-03T08:18:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 87 2020-11-03T08:18:43  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8387f832d693...5174b534da57
 88 2020-11-03T08:18:43  <bitcoin-git> bitcoin/master c2cf8a1 practicalswift: fuzz: Check for addrv1 compatibility before using addrv1 serializer on CSe...
 89 2020-11-03T08:18:44  <bitcoin-git> bitcoin/master 5174b53 MarcoFalke: Merge #20289: fuzz: Check for addrv1 compatibility before using addrv1 ser...
 90 2020-11-03T08:18:45  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 91 2020-11-03T08:18:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 92 2020-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
 93 2020-11-03T08:18:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 94 2020-11-03T08:21:58  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
 95 2020-11-03T08:22:11  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
 96 2020-11-03T08:24:53  *** sr_gi <sr_gi!~sr_gi@static-77-88-225-77.ipcom.comunitel.net> has quit IRC
 97 2020-11-03T08:25:33  *** sr_gi <sr_gi!~sr_gi@static-77-88-225-77.ipcom.comunitel.net> has joined #bitcoin-core-dev
 98 2020-11-03T08:32:24  *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
 99 2020-11-03T08:32:36  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC
100 2020-11-03T08:51:27  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
101 2020-11-03T08:51:27  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5174b534da57...218fe60d91a9
102 2020-11-03T08:51:28  <bitcoin-git> bitcoin/master 28f8cb1 practicalswift: fuzz: Fix DecodeHexTx fuzzing harness issue
103 2020-11-03T08:51:28  <bitcoin-git> bitcoin/master 218fe60 MarcoFalke: Merge #20290: fuzz: Fix DecodeHexTx fuzzing harness issue
104 2020-11-03T08:51:30  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
105 2020-11-03T08:51:42  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
106 2020-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
107 2020-11-03T08:51:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
108 2020-11-03T08:53:23  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
109 2020-11-03T08:57:31  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
110 2020-11-03T09:00:02  *** secdragon <secdragon!~secdragon@> has quit IRC
111 2020-11-03T09:10:01  *** promag_ <promag_!~promag@> has joined #bitcoin-core-dev
112 2020-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
113 2020-11-03T09:14:39  <jonatack> MarcoFalke: http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
114 2020-11-03T09:15:43  <MarcoFalke> jonatack: Oh thanks. Didn't know this existed
115 2020-11-03T09:16:05  <jonatack> MarcoFalke: same, I saw achow101 mention it a couple weeks ago
116 2020-11-03T09:16:08  <MarcoFalke> Well, could make sense to adjust the link for that then ;)
117 2020-11-03T09:16:53  <jonatack> MarcoFalke: maybe add http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt too
118 2020-11-03T09:19:56  <MarcoFalke> anyone know who can edit the IRC topic? ping wumpus sipa
119 2020-11-03T09:20:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
120 2020-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
121 2020-11-03T09:21:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
122 2020-11-03T09:21:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
123 2020-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
124 2020-11-03T09:21:51  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
125 2020-11-03T09:21:53  *** superfly1 <superfly1!~superfly@> has joined #bitcoin-core-dev
126 2020-11-03T09:38:46  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
127 2020-11-03T09:45:49  *** jesseposner <jesseposner!~jesse@> has quit IRC
128 2020-11-03T10:00:13  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
129 2020-11-03T10:06:30  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
130 2020-11-03T10:08:31  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
131 2020-11-03T10:11:43  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
132 2020-11-03T10:11:44  *** vasild_ is now known as vasild
133 2020-11-03T10:20:34  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC
134 2020-11-03T10:23:43  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
135 2020-11-03T10:27:26  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
136 2020-11-03T10:35:19  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
137 2020-11-03T10:39:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
138 2020-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
139 2020-11-03T10:39:44  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
140 2020-11-03T10:39:56  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
141 2020-11-03T10:41:01  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
142 2020-11-03T10:41:49  *** promag_ <promag_!~promag@> has quit IRC
143 2020-11-03T10:52:47  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
144 2020-11-03T10:54:55  *** jonasschnelli <jonasschnelli!~jonasschn@2a01:4f9:2a:2510::2> has quit IRC
145 2020-11-03T10:54:55  *** jonasschnelli <jonasschnelli!~jonasschn@unaffiliated/jonasschnelli> has joined #bitcoin-core-dev
146 2020-11-03T10:55:27  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
147 2020-11-03T10:55:50  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
148 2020-11-03T11:04:31  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
149 2020-11-03T11:10:46  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
150 2020-11-03T11:18:28  *** Gunner5Pollich <Gunner5Pollich!~Gunner5Po@static.> has joined #bitcoin-core-dev
151 2020-11-03T11:21:30  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
152 2020-11-03T11:39:55  *** dviola <dviola!~diego@unaffiliated/dviola> has quit IRC
153 2020-11-03T11:40:25  *** Gunner5Pollich <Gunner5Pollich!~Gunner5Po@static.> has quit IRC
154 2020-11-03T11:42:09  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
155 2020-11-03T11:47:26  *** jesseposner <jesseposner!~jesse@> has quit IRC
156 2020-11-03T11:52:02  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
157 2020-11-03T11:52:39  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has joined #bitcoin-core-dev
158 2020-11-03T11:55:10  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC
159 2020-11-03T12:00:01  *** superfly1 <superfly1!~superfly@> has quit IRC
160 2020-11-03T12:06:02  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC
161 2020-11-03T12:14:54  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
162 2020-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
163 2020-11-03T12:14:55  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
164 2020-11-03T12:18:54  *** Kiminuo <Kiminuo!~mix@> has joined #bitcoin-core-dev
165 2020-11-03T12:21:29  *** mdrjr1 <mdrjr1!~mdrjr@> has joined #bitcoin-core-dev
166 2020-11-03T13:00:19  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
167 2020-11-03T13:01:43  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
168 2020-11-03T13:13:16  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
169 2020-11-03T13:18:30  *** rich <rich!rich@2600:3c00::f03c:92ff:fe8e:dce6> has left #bitcoin-core-dev
170 2020-11-03T13:19:23  *** PaulTroon <PaulTroon!rich@2600:3c00::f03c:92ff:fe8e:dce6> has joined #bitcoin-core-dev
171 2020-11-03T13:21:35  *** belcher_ is now known as belcher
172 2020-11-03T13:31:19  *** ctrlbreak <ctrlbreak!~ctrlbreak@> has quit IRC
173 2020-11-03T13:31:43  *** ctrlbreak <ctrlbreak!~ctrlbreak@> has joined #bitcoin-core-dev
174 2020-11-03T13:33:14  *** glozow <glozow!uid453516@gateway/web/irccloud.com/x-fnmzdyejosltdszp> has joined #bitcoin-core-dev
175 2020-11-03T13:37:29  *** filchef <filchef!~filchef@> has quit IRC
176 2020-11-03T13:39:41  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
177 2020-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
178 2020-11-03T13:39:41  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
179 2020-11-03T13:43:11  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
180 2020-11-03T13:43:35  <wumpus> MarcoFalke: I can, what would you like to change?
181 2020-11-03T13:49:18  *** jesseposner <jesseposner!~jesse@> has quit IRC
182 2020-11-03T13:56:32  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
183 2020-11-03T14:04:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
184 2020-11-03T14:04:45  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/218fe60d91a9...95bde34a7186
185 2020-11-03T14:04:45  <bitcoin-git> bitcoin/master 36e875b RandyMcMillan: contrib: Add new versions to makeseeds.py and update gitignore
186 2020-11-03T14:04:46  <bitcoin-git> bitcoin/master 6866259 Wladimir J. van der Laan: net: Hardcoded seeds update for 0.21
187 2020-11-03T14:04:47  <bitcoin-git> bitcoin/master 95bde34 Wladimir J. van der Laan: Merge #20237: net: Hardcoded seeds update for 0.21
188 2020-11-03T14:04:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
189 2020-11-03T14:05:08  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
190 2020-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
191 2020-11-03T14:05:09  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
192 2020-11-03T14:11:46  *** kexkey <kexkey!~kexkey@static-198-54-132-118.cust.tzulo.com> has joined #bitcoin-core-dev
193 2020-11-03T14:23:03  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
194 2020-11-03T14:24:48  *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
195 2020-11-03T14:28:10  *** jesseposner <jesseposner!~jesse@> has quit IRC
196 2020-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
197 2020-11-03T14:33:42  <wumpus> ok
198 2020-11-03T14:33:51  *** ChanServ sets mode: +o wumpus
199 2020-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
200 2020-11-03T14:34:28  <gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
201 2020-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"
202 2020-11-03T14:37:45  *** ChanServ sets mode: -o wumpus
203 2020-11-03T14:44:07  <MarcoFalke> thanks
204 2020-11-03T14:47:00  *** nickler <nickler!~nickler@static.> has quit IRC
205 2020-11-03T14:47:08  *** nickler <nickler!~nickler@static.> has joined #bitcoin-core-dev
206 2020-11-03T14:54:53  *** TheV01d <TheV01d!thev01d@2001:19c0:1:801:851:ff00:1:6> has quit IRC
207 2020-11-03T14:54:53  *** corollari__ <corollari__!sid405633@gateway/web/irccloud.com/x-mmtqtinsxduvodfk> has quit IRC
208 2020-11-03T14:56:00  *** TheV01d <TheV01d!thev01d@2001:19c0:1:801:851:ff00:1:6> has joined #bitcoin-core-dev
209 2020-11-03T14:56:00  *** corollari__ <corollari__!sid405633@gateway/web/irccloud.com/x-mmtqtinsxduvodfk> has joined #bitcoin-core-dev
210 2020-11-03T14:57:26  *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-bbpxarfwoqwpngyc> has quit IRC
211 2020-11-03T14:59:27  *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-cjjnwfskkjjjiccx> has quit IRC
212 2020-11-03T15:00:01  *** sdaftuar_ is now known as sdaftuar
213 2020-11-03T15:00:02  *** mdrjr1 <mdrjr1!~mdrjr@> has quit IRC
214 2020-11-03T15:00:05  <sdaftuar> hi
215 2020-11-03T15:00:05  *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-ngiqrfyaklwgnpqv> has quit IRC
216 2020-11-03T15:00:09  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-psjyqsyrkhlykggg> has quit IRC
217 2020-11-03T15:00:15  *** lightlike <lightlike!~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
218 2020-11-03T15:00:18  *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-sbfuejevikgxhirq> has quit IRC
219 2020-11-03T15:00:26  <jnewbery> #startmeeting
220 2020-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.
221 2020-11-03T15:00:26  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
222 2020-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
223 2020-11-03T15:00:35  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tfhrfhquwmimigoi> has quit IRC
224 2020-11-03T15:00:36  <vasild> hi
225 2020-11-03T15:00:40  <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
226 2020-11-03T15:00:42  <phantomcircuit> hi
227 2020-11-03T15:00:52  <emzy> hi
228 2020-11-03T15:01:01  <aj> hi
229 2020-11-03T15:01:12  <jnewbery> that ping thing is like a blockchain. It only gets longer, never shorter
230 2020-11-03T15:01:18  <ariard> hi
231 2020-11-03T15:01:23  <lightlike> hi
232 2020-11-03T15:01:34  <wumpus> hi
233 2020-11-03T15:01:37  <jonatack> hi
234 2020-11-03T15:01:44  <kanzure> hi
235 2020-11-03T15:01:54  <jnewbery> proposed topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#03-nov-2020
236 2020-11-03T15:01:56  <gribble> https://github.com/bitcoin/bitcoin/issues/03 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
237 2020-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?
238 2020-11-03T15:02:37  <sdaftuar> i just wanted to review beg #19858
239 2020-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
240 2020-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 :)
241 2020-11-03T15:03:35  <jnewbery> I think we haven't branched 0.21 yet, so we're still in feature freeze, right?
242 2020-11-03T15:03:46  <wumpus> right
243 2020-11-03T15:03:50  <aj> branch is due pretty soon though?
244 2020-11-03T15:03:52  <sdaftuar> i assume so -- but i think if we collect acks now it could merge shortly after?
245 2020-11-03T15:03:59  <amiti> hi
246 2020-11-03T15:04:01  <luke-jr> kinda curious about the status of p2p encryption
247 2020-11-03T15:04:05  <luke-jr> but jonas isn't here
248 2020-11-03T15:04:19  <ariard> noted, I'll reack it
249 2020-11-03T15:04:31  <jonatack> #18242 was just rebased and it builds cleanly
250 2020-11-03T15:04:33  <wumpus> yes, feature freeze is only about what is merged, not what is reviewed :)
251 2020-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
252 2020-11-03T15:04:45  <aj> "2020-11-01 split off 0.21" per 18947
253 2020-11-03T15:04:53  <jonatack> (would be good to move it forward for 0.22)
254 2020-11-03T15:04:54  <jnewbery> wumpus: while you're here, what's your expectation for when 0.21 will be branched?
255 2020-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
256 2020-11-03T15:06:13  <wumpus> but I hope some time next week
257 2020-11-03T15:06:33  <jnewbery> thanks!
258 2020-11-03T15:06:38  <wumpus> next general meeting we should go over the list
259 2020-11-03T15:06:46  <jnewbery> ok, onto the topics
260 2020-11-03T15:06:57  <jnewbery> #topic addrman file versioning
261 2020-11-03T15:07:01  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has quit IRC
262 2020-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?
263 2020-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.
264 2020-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
265 2020-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
266 2020-11-03T15:08:34  <jnewbery> vasild: I hadn't reviewed 19954 before
267 2020-11-03T15:08:54  <jnewbery> I started looking at the addrman code this weekend
268 2020-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
269 2020-11-03T15:09:13  <sdaftuar> forwards compatible? do you mean backwards compatible?
270 2020-11-03T15:09:26  <sdaftuar> i'm confused why we can't write future code to parse whatever we need to
271 2020-11-03T15:09:33  <vasild> backward compatible
272 2020-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
273 2020-11-03T15:10:03  <sdaftuar> that really sounds like backwards compatible to me, but thanks for clarifying what you mean
274 2020-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
275 2020-11-03T15:10:13  <vasild> the current code supports maximum format=3 and if it sees format=4 it will refuse to parse it
276 2020-11-03T15:10:28  <hebasto> hi
277 2020-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
278 2020-11-03T15:10:52  <jnewbery> forwards compatible means that we're flexible with future peers.dat formatting
279 2020-11-03T15:11:58  <jonatack> jnewbery: yes, i was reporting issues with that (upgrading, then downgrading) in 19954 iirc
280 2020-11-03T15:11:59  <jnewbery> vasild: right, so the current code on master is not forwards compatible with formats > 4
281 2020-11-03T15:12:10  <vasild> >= 4
282 2020-11-03T15:12:23  <jnewbery> sorry yes, >= 4
283 2020-11-03T15:12:28  *** bosch-0 <bosch-0!~igloo@122-148-254-95.sta.wbroadband.net.au> has joined #bitcoin-core-dev
284 2020-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
285 2020-11-03T15:12:55  <vasild> (as of the current master)
286 2020-11-03T15:13:03  <luke-jr> it would be annoying if users lost their addrman upgrading or downgrading
287 2020-11-03T15:13:10  <vasild> pr20284 changes that
288 2020-11-03T15:13:43  *** joerodgers <joerodgers!~joerodger@> has joined #bitcoin-core-dev
289 2020-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
290 2020-11-03T15:13:57  <luke-jr> :/
291 2020-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"
292 2020-11-03T15:16:29  <luke-jr> maybe the filename should just be changed if that's not the case, in the future?
293 2020-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.
294 2020-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?
295 2020-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
296 2020-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
297 2020-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
298 2020-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)
299 2020-11-03T15:18:11  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
300 2020-11-03T15:18:17  <wumpus> definitely don't have any alternative proposals
301 2020-11-03T15:18:36  <jnewbery> the point of the serialization format is that entries can appear in multiple new tables
302 2020-11-03T15:18:43  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
303 2020-11-03T15:18:44  <vasild> luke-jr: right, filename change is another option
304 2020-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?
305 2020-11-03T15:19:23  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
306 2020-11-03T15:19:39  <wumpus> sdaftuar: that's a good suggestion too
307 2020-11-03T15:19:39  <sdaftuar> jnewbery: hmm i need to read that more carefully then.
308 2020-11-03T15:19:59  <jnewbery> sdaftuar: that would definitely prevent being able to keep your addrman data over a downgrade
309 2020-11-03T15:20:06  <wumpus> though it'd require updating a lot of documentation all over the place describing bitcoin core's files
310 2020-11-03T15:20:18  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
311 2020-11-03T15:20:21  <wumpus> everyone is used to "peers.dat"
312 2020-11-03T15:20:38  <luke-jr> how often does anyone mess with peers.dat directly?
313 2020-11-03T15:20:56  <wumpus> I have no idea
314 2020-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
315 2020-11-03T15:21:28  <wumpus> yes, I slightly prefer this as well
316 2020-11-03T15:21:51  *** jackgassett <jackgassett!~jackgasse@> has joined #bitcoin-core-dev
317 2020-11-03T15:21:51  <sdaftuar> i think it's okay if once in a while we have to give users annoying instructions for downgrading.
318 2020-11-03T15:21:52  <luke-jr> IMO it depends on compatibility
319 2020-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
320 2020-11-03T15:22:35  <jnewbery> what would the annoying instructions be?
321 2020-11-03T15:22:37  <sdaftuar> we could add a tool that either converts formats, or an RPC or something
322 2020-11-03T15:22:38  <luke-jr> ^
323 2020-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.
324 2020-11-03T15:22:42  <luke-jr> ew
325 2020-11-03T15:23:00  *** bosch-0 <bosch-0!~igloo@122-148-254-95.sta.wbroadband.net.au> has quit IRC
326 2020-11-03T15:23:06  <sdaftuar> what did we do the last time we changed block file name conventions?
327 2020-11-03T15:23:09  <wumpus> sdaftuar: no one is going to go through that much work for their peers table
328 2020-11-03T15:23:28  <luke-jr> sdaftuar: iirc hard linked
329 2020-11-03T15:23:42  <sdaftuar> luke-jr: that doesn't sound backwards compatible?
330 2020-11-03T15:23:46  <luke-jr> why not?
331 2020-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.
332 2020-11-03T15:24:11  <sdaftuar> oh we hardlinked new and old filenames together, i see
333 2020-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
334 2020-11-03T15:24:26  <jonatack> unless they don't use tor
335 2020-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.
336 2020-11-03T15:25:06  <wumpus> assuming this really needs to go in for 0.21.0-otherwise there's no hurry
337 2020-11-03T15:25:18  <aj> afaics, for forwards compatible changes, we just don't bump the version number?
338 2020-11-03T15:25:43  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
339 2020-11-03T15:25:58  <sipa> argh, timezones
340 2020-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"
341 2020-11-03T15:26:26  <vasild> surely it parsed everything as garbage
342 2020-11-03T15:26:56  <wumpus> it's definitely not theoretical
343 2020-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
344 2020-11-03T15:27:30  <jonatack> vasild: same
345 2020-11-03T15:27:37  <vasild> :-D
346 2020-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
347 2020-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
348 2020-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
349 2020-11-03T15:29:43  <jnewbery> luke-jr: that's a good point
350 2020-11-03T15:30:07  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
351 2020-11-03T15:30:17  <jnewbery> So the action is to review 20284, unless anyone has anything important to add
352 2020-11-03T15:31:07  <jnewbery> #topic I2P support, some background at vasild/bitcoin/wiki/I2P-connectivity (vasild)
353 2020-11-03T15:31:07  *** Pavlenex <Pavlenex!~Thunderbi@> has joined #bitcoin-core-dev
354 2020-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)
355 2020-11-03T15:31:47  <vasild> https://github.com/vasild/bitcoin/wiki/I2P-connectivity
356 2020-11-03T15:32:03  <jnewbery> jonatack: it probably takes longer for your tried tables to get populated
357 2020-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)
358 2020-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
359 2020-11-03T15:32:29  <jonatack> good points, thanks
360 2020-11-03T15:32:49  *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt> has joined #bitcoin-core-dev
361 2020-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
362 2020-11-03T15:33:29  <jnewbery> aj: I think that's effectively what 20284 does
363 2020-11-03T15:33:52  <sipa> can we imagine any backward but not forward compatible change?
364 2020-11-03T15:33:58  <vasild> aj:
365 2020-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
366 2020-11-03T15:34:04  <vasild>                 read format=3 can also read this one"
367 2020-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
368 2020-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)
369 2020-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
370 2020-11-03T15:35:02  *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has quit IRC
371 2020-11-03T15:35:08  <aj> sipa: backward compatible is easy: if version == 4: ... elif version == 5: ...
372 2020-11-03T15:35:17  <jnewbery> aj: +1
373 2020-11-03T15:35:26  <sipa> jnewbery: yes, i mean semantically
374 2020-11-03T15:35:59  <sipa> is there any change we can imagine to peers.dat that would remain readable by new versions?
375 2020-11-03T15:36:17  <aj> sipa: readable by old code, you mean?
376 2020-11-03T15:36:29  <sipa> oh
377 2020-11-03T15:36:38  * sdaftuar is super confused
378 2020-11-03T15:36:38  *** Kiminuo <Kiminuo!~mix@> has quit IRC
379 2020-11-03T15:36:39  <sipa> do i have my forward/backward mixed up?
380 2020-11-03T15:36:59  <aj> new code, old peers.dat == backwards compatible
381 2020-11-03T15:36:59  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
382 2020-11-03T15:37:01  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz> has joined #bitcoin-core-dev
383 2020-11-03T15:37:05  <sdaftuar> sipa: i thought john has his forward/backward mixed up, for what it's worth.  and maybe aj too.
384 2020-11-03T15:37:05  <aj> old code, new peers.dat == forwards compatible
385 2020-11-03T15:37:16  <vasild> awkward
386 2020-11-03T15:37:28  <sdaftuar> vasild: +1
387 2020-11-03T15:37:31  <aj> "the format is ___ compatible" is how i'm interpreting it
388 2020-11-03T15:37:34  *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap> has joined #bitcoin-core-dev
389 2020-11-03T15:37:46  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp> has joined #bitcoin-core-dev
390 2020-11-03T15:37:47  <sipa> the goal here is to make sure that new versions can keep reading old files?
391 2020-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
392 2020-11-03T15:38:02  <vasild> no
393 2020-11-03T15:38:13  <jnewbery> where the input here is peers.dat
394 2020-11-03T15:38:16  <vasild> sipa: new code can always read old files
395 2020-11-03T15:38:28  <jnewbery> old peers.dat, new addrman is backwards compatibility
396 2020-11-03T15:38:46  <jnewbery> new peers.dat, old addrman is forwards compatibility
397 2020-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?
398 2020-11-03T15:38:58  <sdaftuar> sipa: it's about being able to downgrade
399 2020-11-03T15:39:05  <sdaftuar> and not losing all your data
400 2020-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
401 2020-11-03T15:40:00  <sipa> sdaftuar: yes, my question is: can we imagine any change to peers.dat where that's even feasible?
402 2020-11-03T15:40:23  <luke-jr> sipa: if you don't use Tor, this change is?
403 2020-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
404 2020-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
405 2020-11-03T15:41:05  <sipa> jnewbery: ah, indeed!
406 2020-11-03T15:41:18  <sipa> thanks
407 2020-11-03T15:41:26  <vasild> sipa: you authored that! :-)
408 2020-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?
409 2020-11-03T15:41:36  <sipa> vasild: it's early
410 2020-11-03T15:42:03  <sdaftuar> luke-jr: interesting idea
411 2020-11-03T15:42:04  <aj> or put the torv3 addresses as an add-on at the end of the file or something?
412 2020-11-03T15:42:30  <wumpus> where does that stop, though... would we have peers-i2p.dat as well?
413 2020-11-03T15:42:35  <jonatack> if anyone following along is wondering, we're talking about enum class Format in addrman.h::L269
414 2020-11-03T15:42:58  <luke-jr> wumpus: why not?
415 2020-11-03T15:43:09  <sipa> this seems hard
416 2020-11-03T15:43:10  <luke-jr> is there a reason to throw it all in the same file?
417 2020-11-03T15:43:10  <jnewbery> jonatack: well more generally about the Serialize and Unserialize methods for CAddrMan
418 2020-11-03T15:43:12  <sdaftuar> wumpus: perhaps eventually files get merged, once old software no longer is a plausible downgrade target?
419 2020-11-03T15:43:34  <sipa> peers.dat files aren't just lists of addresses
420 2020-11-03T15:43:47  <sipa> they dump the tables and their layout too
421 2020-11-03T15:43:47  <jnewbery> we could replace peers.dat with sqlite :)
422 2020-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?
423 2020-11-03T15:44:05  <wumpus> then if people downgrade they can restore the backup and *shrug*
424 2020-11-03T15:44:07  <sipa> if you split the file in two, you can't just merge them back without losing informatiom
425 2020-11-03T15:44:10  <luke-jr> jnewbery: that might not be a bad idea
426 2020-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"
427 2020-11-03T15:44:38  <luke-jr> wumpus: how is that different from just using a new filename, except requiring an extra step to downgrade?
428 2020-11-03T15:45:00  <wumpus> luke-jr: it keeps the filename the same for the bulk of the users
429 2020-11-03T15:45:23  <wumpus> the non-downgrading path is likely be far most popular, or at least one'd hope :)
430 2020-11-03T15:45:50  <wumpus> in any case, we needa solution here fairly quickly
431 2020-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
432 2020-11-03T15:46:36  <jnewbery> *upgrading is the more likely path than downgrading
433 2020-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
434 2020-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
435 2020-11-03T15:47:04  *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-nmqjpumkebfumgzt> has quit IRC
436 2020-11-03T15:47:06  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-tawsjbyfoxfwvssz> has quit IRC
437 2020-11-03T15:47:09  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-tpifxrmkoneyrnwp> has quit IRC
438 2020-11-03T15:47:11  *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-inttwipmaihlkdap> has quit IRC
439 2020-11-03T15:47:17  <sipa> wumpus: agree
440 2020-11-03T15:47:29  <jnewbery> vasild: did you have anything you wanted to add about I2P support?
441 2020-11-03T15:47:49  <ariard> jnewbery: I'm fine to report mine next time
442 2020-11-03T15:48:20  <jnewbery> ariard: thanks. Maybe a good idea so people have some time to think about it before the meeting
443 2020-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
444 2020-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?
445 2020-11-03T15:48:59  <wumpus> jnewbery: yes, agree, it's kind of nasty that this issue comes up so last minute
446 2020-11-03T15:49:38  <sipa> sdaftuar: i2p/cjdns do not get rumoured by the current code, at all
447 2020-11-03T15:50:14  <vasild> sipa: no, they would get rumored if the node has connectivity to i2p
448 2020-11-03T15:50:26  <vasild> or am I mistaken...
449 2020-11-03T15:50:28  <wumpus> cjdns not because it uses IPv6 addresses in a range we consider local / unroutable?
450 2020-11-03T15:50:34  <sipa> vasild: which isn't possible.on the current code :)
451 2020-11-03T15:50:40  <sipa> see #20119
452 2020-11-03T15:50:41  <gribble> https://github.com/bitcoin/bitcoin/issues/20119 | BIP155 follow-ups by sipa · Pull Request #20119 · bitcoin/bitcoin · GitHub
453 2020-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
454 2020-11-03T15:51:18  <sdaftuar> and if we don't, it still goes to 1 i think? is that correct?
455 2020-11-03T15:51:30  <sipa> sdaftuar: there are classes now
456 2020-11-03T15:51:34  <vasild> sdaftuar: yes
457 2020-11-03T15:51:34  <jnewbery> sdaftuar: 1.5 now I think
458 2020-11-03T15:51:50  <sipa> 1) reachable networks get rumoured 2x
459 2020-11-03T15:51:55  <vasild> sdaftuar: see RelayAddress() in the case fReachable==true
460 2020-11-03T15:52:09  <sipa> 2) unreachable ipv4/ipv6/torv2/torv3 get rumoured 1.5x
461 2020-11-03T15:52:18  <jonatack> see #19728
462 2020-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
463 2020-11-03T15:52:24  <sipa> 3) unreachable others do not get rumoured at all
464 2020-11-03T15:52:43  <vasild> #20254 makes i2p reachable
465 2020-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
466 2020-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)
467 2020-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?
468 2020-11-03T15:54:57  <luke-jr> vasild: same for Tor? :p
469 2020-11-03T15:55:31  <vasild> luke-jr: no, in Tor we don't see the address of the peer that connected to us
470 2020-11-03T15:55:47  <luke-jr> oh, right
471 2020-11-03T15:55:59  <sipa> "tor has no from address"
472 2020-11-03T15:56:03  <luke-jr> XD
473 2020-11-03T15:56:07  <wumpus> heh
474 2020-11-03T15:56:12  <vasild> so in I2P we have P2P encryption by default :-)
475 2020-11-03T15:56:25  <jnewbery> sdaftuar: that logic is in AdvertiseLocal() in net.cpp
476 2020-11-03T15:56:35  <sipa> vasild: with public identities, though :(
477 2020-11-03T15:56:48  <vasild> yes
478 2020-11-03T15:57:04  <luke-jr> kinda by design in i2p?
479 2020-11-03T15:57:16  <vasild> yes
480 2020-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
481 2020-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
482 2020-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?
483 2020-11-03T15:58:40  <sdaftuar> sipa: oh taht seems important
484 2020-11-03T15:58:59  <jnewbery> do we need a new version version? :)
485 2020-11-03T15:59:14  <sdaftuar> jnewbery: i think we can just add data on to the end and no one will mind
486 2020-11-03T15:59:33  *** Pasta[m] <Pasta[m]!pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw> has joined #bitcoin-core-dev
487 2020-11-03T15:59:55  <sipa> i'm not sure this is useful for those networks
488 2020-11-03T16:00:08  <sipa> as there isn't any useful compatibility matrix for them
489 2020-11-03T16:00:10  *** Pasta[m] <Pasta[m]!pastapas1@gateway/shell/matrix.org/x-kjhgribcrumcadtw> has quit IRC
490 2020-11-03T16:00:15  <jnewbery> that's time!
491 2020-11-03T16:00:18  <jnewbery> #endmeeting
492 2020-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)
493 2020-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
494 2020-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
495 2020-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
496 2020-11-03T16:00:20  <sdaftuar> sipa: address rumoring isn't useful, or something else?
497 2020-11-03T16:00:47  <jonasschnelli> oh.. I missed the meeting.
498 2020-11-03T16:00:48  <wumpus> sipa: there was the idea to add that address in the 'sendaddrv2' message
499 2020-11-03T16:00:50  <vasild> I guess sipa means the "voting"
500 2020-11-03T16:00:58  <sdaftuar> ah
501 2020-11-03T16:01:04  <vasild> or how many times the address receives "mentions"
502 2020-11-03T16:01:04  <aj> zzz
503 2020-11-03T16:01:07  * luke-jr gives jonasschnelli the mic
504 2020-11-03T16:01:10  <jonasschnelli> I wanted to ask about BIP324's rekeying
505 2020-11-03T16:01:11  <sipa> sdaftuar: scoring your local addresses using incoming version mentions isn't useful for these separate networls
506 2020-11-03T16:01:24  <sipa> jonasschnelli: ongoing discussion, it seems!
507 2020-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
508 2020-11-03T16:01:26  <jonasschnelli> sipa: may you have 10 minutes for discussion the 1s rekey approach
509 2020-11-03T16:01:33  <sdaftuar> so that eventually peers that do support it, receive it
510 2020-11-03T16:01:56  <sipa> sdaftuar: that's a good point
511 2020-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)
512 2020-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
513 2020-11-03T16:02:33  <jonasschnelli> sipa: indeed... its ongoing. But assume a 1s rekeying interval would imply some sort of a rekey-message,.. right?
514 2020-11-03T16:02:34  <sipa> jonasschnelli: my current thinking is that doing rekeying at the key stream level is super cheap and simple
515 2020-11-03T16:03:09  <jonasschnelli> rekey on every ping/pong would be less complicated to implement (rather then time based)
516 2020-11-03T16:03:09  <sipa> jonasschnelli: and i see no reason to have it at the application level as well if we do that
517 2020-11-03T16:03:23  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
518 2020-11-03T16:03:31  <sipa> jonasschnelli: i absolutely don't suggest rekeying every secomd :)
519 2020-11-03T16:04:09  <jonasschnelli> sipa: at stream level would be something like basically rekey on after message?
520 2020-11-03T16:04:21  <vasild> there is already one bitcoin node listening at yfsvsy467mt5xafaq7zaukkjyzehvmew445yaaejvrwpk53acejq.b32.i2p (irc gossip :-D)
521 2020-11-03T16:04:22  <jonasschnelli> "after every message
522 2020-11-03T16:04:25  <sipa> jonasschnelli: no, every X bytes
523 2020-11-03T16:04:35  <sdaftuar> vasild: nice :)
524 2020-11-03T16:04:51  <jonasschnelli> sipa: okay. What we have now.. but probably smaller than 1GB
525 2020-11-03T16:04:58  <sipa> jonasschnelli: no!
526 2020-11-03T16:05:07  <sipa> it's currently done at the layer above
527 2020-11-03T16:05:19  <sipa> this would let you just build it inside chacha
528 2020-11-03T16:05:21  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
529 2020-11-03T16:05:29  <jonasschnelli> ah. Built into the AEAD
530 2020-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?
531 2020-11-03T16:05:35  <sipa> without having a bit to signal rekeying or so
532 2020-11-03T16:05:51  <sipa> ariard: that's just as hard
533 2020-11-03T16:06:22  <sipa> jonasschnelli: this would give you forward secrecy (also a weird term
534 2020-11-03T16:06:35  <jonasschnelli> What if the byte limit hits in the middle of a message payload?
535 2020-11-03T16:06:40  <sipa> for ~free, at the byte level if you wanted to
536 2020-11-03T16:06:45  <sipa> jonasschnelli: yes, so what?
537 2020-11-03T16:06:59  <sipa> the stream cipher does it automatically
538 2020-11-03T16:07:06  <ariard> sipa: do you mean byte-accounting is hard to get right?
539 2020-11-03T16:07:18  <sipa> ariard: no, byte-accounting is trivial
540 2020-11-03T16:07:23  <jonasschnelli> sipa: hmm... but the mAC?
541 2020-11-03T16:07:35  <sipa> jonasschnelli: the mac keys don't cycle
542 2020-11-03T16:07:45  <sipa> only the encryption keys
543 2020-11-03T16:08:47  <jonasschnelli> but the current MAC key is derived from the chacha20 stream
544 2020-11-03T16:09:19  <sipa> jonasschnelli: yes that'll need to change
545 2020-11-03T16:09:24  *** lightlike <lightlike!~lightlike@p200300c7ef1af100fc8fbb65fc69f44f.dip0.t-ipconnect.de> has quit IRC
546 2020-11-03T16:09:31  <jonasschnelli> sipa: hmm...
547 2020-11-03T16:09:35  <sipa> have a separate stream where the mac keys are drawn from, for example
548 2020-11-03T16:10:14  <sipa> but it means you can drop the signalling of rekeying etc
549 2020-11-03T16:10:31  <sipa> and concerns about peers not doing it, or doing it too often
550 2020-11-03T16:12:03  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
551 2020-11-03T16:12:37  *** kljasdfvv <kljasdfvv!~flack@p200300d46f24de007887c37597c774bc.dip0.t-ipconnect.de> has quit IRC
552 2020-11-03T16:13:52  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
553 2020-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
554 2020-11-03T16:14:17  <jonasschnelli> sipa: do the benefits of this justify further deviation from the "well tested" ChaCha20Poly1305@openssh?
555 2020-11-03T16:14:28  <sipa> jonasschnelli: we're already deviating from it
556 2020-11-03T16:14:37  <jonasschnelli> sipa: but in a pretty minor way
557 2020-11-03T16:15:19  *** Kiminuo <Kiminuo!~mix@> has joined #bitcoin-core-dev
558 2020-11-03T16:15:57  <sipa> jonasschnelli: maybe superficially... but openssh rekeys by redoing DH, no?
559 2020-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)?
560 2020-11-03T16:16:19  <jonasschnelli> sipa: probably... haven't looked at their rekeying.
561 2020-11-03T16:16:39  <jonasschnelli> but the AEAD has no rekeying (@openssh and @Bitcoin)
562 2020-11-03T16:17:00  <sipa> so doing rekeying by redoing DH makes sense, as it gives you secrecy in both directions
563 2020-11-03T16:17:59  <jonasschnelli> Yes. Our rekeying does a independent rekey per direction,... whenever the limits are reached.
564 2020-11-03T16:18:01  <sipa> rekeying by hashing only gives you forward secrecy, not the other direction
565 2020-11-03T16:18:39  <sipa> but as long as we only care about forward secrecy... doing the whole signalling thing is kind of overkill
566 2020-11-03T16:18:43  <jonasschnelli> I see
567 2020-11-03T16:18:53  <jonasschnelli> I see what you mean with direction noew
568 2020-11-03T16:18:55  <jonasschnelli> *now
569 2020-11-03T16:19:05  <sipa> you can get cheap forward secrecy at the byte level, instead of at the 1 GB level
570 2020-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)
571 2020-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
572 2020-11-03T16:21:20  <sipa> anyway, my point is: not redoing DH is already a big conceptual departure from the existing protocol
573 2020-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)
574 2020-11-03T16:22:38  <sipa> yeah
575 2020-11-03T16:23:06  <sipa> to be honest, i habe difficulty remember the exact way the stream/keys are constructed now too
576 2020-11-03T16:23:26  <sipa> this may simplify it...
577 2020-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?
578 2020-11-03T16:23:45  <jonasschnelli> since the "session ID" requires the ECDH key
579 2020-11-03T16:23:58  <sipa> jonasschnelli: if an attacker knows the old key, they can also apply the hashing
580 2020-11-03T16:24:08  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
581 2020-11-03T16:24:23  <jonasschnelli> sipa: the attacked doesn't know the session ID, right?
582 2020-11-03T16:24:33  <sipa> well in this scenario they do!
583 2020-11-03T16:24:36  *** TheHoliestRoger <TheHoliestRoger!~TheHolies@unaffiliated/theholiestroger> has joined #bitcoin-core-dev
584 2020-11-03T16:25:33  <jonasschnelli> sipa: So the scenario is that ECDH is broken?
585 2020-11-03T16:25:51  <sipa> jonasschnelli: or they broke into your machine and dumped its memory
586 2020-11-03T16:26:29  <sipa> forward secrecy protects against that case... if an attacker does that, they *still* can't decrypt old messages
587 2020-11-03T16:27:16  <jonasschnelli> okay.. got it
588 2020-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
589 2020-11-03T16:27:41  <jonasschnelli> including re-generation of emphemeral keys,.. right?
590 2020-11-03T16:27:55  <sipa> yes, that's what DH does
591 2020-11-03T16:28:03  <jonasschnelli> indeed. :)
592 2020-11-03T16:28:44  *** tralfaz <tralfaz!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
593 2020-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?
594 2020-11-03T16:29:27  *** jesseposner <jesseposner!~jesse@> has quit IRC
595 2020-11-03T16:29:40  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
596 2020-11-03T16:29:47  *** tralfaz is now known as davterra
597 2020-11-03T16:30:07  <jonasschnelli> or has the AEAD-inner-rekeyng nothing to do with the secrecy directions?
598 2020-11-03T16:30:43  <sipa> that only provides forward secrecy
599 2020-11-03T16:30:51  <sipa> but it can do it at the byte level
600 2020-11-03T16:31:07  <jonasschnelli> more elegant but same level of security as the current proposal?
601 2020-11-03T16:31:13  <sipa> indeed
602 2020-11-03T16:31:33  <jonasschnelli> okay... got it.
603 2020-11-03T16:31:50  <sipa> perhaps we want some affordance for redoing DH too, but we can probably just disconnect and reconnect for that...
604 2020-11-03T16:32:00  <jonasschnelli> I haven't seen BIP324 discussion about the missing backward secrecy of the current rekeying approach.
605 2020-11-03T16:32:18  <sipa> i think it's less of a concern
606 2020-11-03T16:32:27  <sipa> but i'll try to summerize
607 2020-11-03T16:32:34  <sipa> on githun
608 2020-11-03T16:32:40  <jonasschnelli> great,... thanks.
609 2020-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. :)
610 2020-11-03T16:34:09  *** Pavlenex <Pavlenex!~Thunderbi@> has quit IRC
611 2020-11-03T16:34:12  <jonasschnelli> However... thanks sipa for explaining!
612 2020-11-03T16:34:56  *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-tiujvomwsqovicqc> has joined #bitcoin-core-dev
613 2020-11-03T16:34:56  *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-sctramrejhkepioh> has joined #bitcoin-core-dev
614 2020-11-03T16:34:56  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-uxpvzzgmfufkdehc> has joined #bitcoin-core-dev
615 2020-11-03T16:34:56  *** TheFuzzStone[m] <TheFuzzStone[m]!thefuzzsto@gateway/shell/matrix.org/x-fdqmwngbisvjvofx> has joined #bitcoin-core-dev
616 2020-11-03T16:34:56  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-zawdlorjbkpbblko> has joined #bitcoin-core-dev
617 2020-11-03T16:34:56  *** kyoo[m] <kyoo[m]!kyoomatrix@gateway/shell/matrix.org/x-bpoimagdjgyeoxrb> has joined #bitcoin-core-dev
618 2020-11-03T16:35:02  *** tianshi[m] <tianshi[m]!tianshimat@gateway/shell/matrix.org/x-mpipzilseonjtdcn> has joined #bitcoin-core-dev
619 2020-11-03T16:35:02  *** RaphalBentgeac[m <RaphalBentgeac[m!raphaelben@gateway/shell/matrix.org/x-soiqapnxaxpgdwts> has joined #bitcoin-core-dev
620 2020-11-03T16:39:04  *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has quit IRC
621 2020-11-03T16:45:40  *** greypw <greypw!~greypw@unaffiliated/greypw> has quit IRC
622 2020-11-03T16:46:12  *** greypw <greypw!~greypw@unaffiliated/greypw> has joined #bitcoin-core-dev
623 2020-11-03T16:53:59  *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has quit IRC
624 2020-11-03T16:57:29  *** spinza <spinza!~spin@> has quit IRC
625 2020-11-03T16:58:07  *** baldur <baldur!~baldur@pool-173-56-240-14.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
626 2020-11-03T16:59:27  *** spinza <spinza!~spin@> has joined #bitcoin-core-dev
627 2020-11-03T17:20:56  *** pergaminho <pergaminho!~Cleber@> has joined #bitcoin-core-dev
628 2020-11-03T17:25:46  *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has joined #bitcoin-core-dev
629 2020-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
630 2020-11-03T17:29:55  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
631 2020-11-03T17:35:01  *** jesseposner <jesseposner!~jesse@> has quit IRC
632 2020-11-03T17:35:41  *** spinza <spinza!~spin@> has quit IRC
633 2020-11-03T17:37:28  *** spinza <spinza!~spin@> has joined #bitcoin-core-dev
634 2020-11-03T17:42:15  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
635 2020-11-03T17:56:30  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
636 2020-11-03T18:00:01  *** jackgassett <jackgassett!~jackgasse@> has quit IRC
637 2020-11-03T18:10:16  *** promag_ <promag_!~promag@> has joined #bitcoin-core-dev
638 2020-11-03T18:14:55  *** promag_ <promag_!~promag@> has quit IRC
639 2020-11-03T18:19:15  *** kristapsk_ is now known as kristapsk
640 2020-11-03T18:20:19  *** hardaker <hardaker!~hardaker@> has joined #bitcoin-core-dev
641 2020-11-03T18:31:55  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has quit IRC
642 2020-11-03T18:36:40  *** owowo <owowo!~ovovo@unaffiliated/ovovo> has joined #bitcoin-core-dev
643 2020-11-03T18:41:46  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
644 2020-11-03T18:46:25  *** jesseposner <jesseposner!~jesse@> has quit IRC
645 2020-11-03T18:53:31  *** joerodgers <joerodgers!~joerodger@> has quit IRC
646 2020-11-03T18:55:19  *** filchef <filchef!~filchef@> has joined #bitcoin-core-dev
647 2020-11-03T19:02:46  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
648 2020-11-03T19:03:01  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
649 2020-11-03T19:10:56  *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has quit IRC
650 2020-11-03T19:21:23  *** jesseposner <jesseposner!~jesse@> has joined #bitcoin-core-dev
651 2020-11-03T19:32:31  *** DeanWeen <DeanWeen!~dean@gateway/tor-sasl/deanguss> has quit IRC
652 2020-11-03T19:33:25  *** DeanGuss <DeanGuss!~dean@gateway/tor-sasl/deanguss> has joined #bitcoin-core-dev
653 2020-11-03T19:35:01  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC
654 2020-11-03T19:39:17  *** lightlike <lightlike!~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
655 2020-11-03T19:44:44  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
656 2020-11-03T19:47:56  *** mol <mol!~mol@unaffiliated/molly> has quit IRC
657 2020-11-03T20:08:05  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC
658 2020-11-03T20:16:26  *** troygiorshev <troygiorshev!~troygiors@d67-193-140-136.home3.cgocable.net> has joined #bitcoin-core-dev
659 2020-11-03T20:32:11  *** lightlike <lightlike!~lightlike@p200300c7ef1af100d5d5bc5b312eacaf.dip0.t-ipconnect.de> has quit IRC
660 2020-11-03T21:00:02  *** hardaker <hardaker!~hardaker@> has quit IRC
661 2020-11-03T21:03:18  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
662 2020-11-03T21:13:28  *** pergaminho <pergaminho!~Cleber@> has quit IRC
663 2020-11-03T21:20:18  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC
664 2020-11-03T21:21:35  *** zelazny <zelazny!~zelazny@> has joined #bitcoin-core-dev
665 2020-11-03T21:28:23  <jonatack> vasild: i think i'm connected to your i2p peer
666 2020-11-03T21:28:52  *** robert_spigler[m <robert_spigler[m!robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr> has joined #bitcoin-core-dev
667 2020-11-03T21:30:06  *** promag <promag!~promag@> has quit IRC
668 2020-11-03T21:33:44  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC
669 2020-11-03T21:45:12  *** justanotheruser is now known as mrdulus
670 2020-11-03T21:45:35  *** robert_spigler[m <robert_spigler[m!robertspig@gateway/shell/matrix.org/x-uhbimzzqyjwxnyqr> has left #bitcoin-core-dev
671 2020-11-03T21:46:23  *** mrdulus is now known as justan0theruser
672 2020-11-03T21:51:39  *** mdunnio <mdunnio!~mdunnio@> has joined #bitcoin-core-dev
673 2020-11-03T21:56:29  <amiti> hi! does anyone actively use `-loadblock` / have current use cases?
674 2020-11-03T21:57:57  *** tryphe_ is now known as tryphe
675 2020-11-03T21:58:17  <sipa> amiti: did yiu see my response on the issue?
676 2020-11-03T21:58:34  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
677 2020-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 :)
678 2020-11-03T21:59:38  <sipa> amiti: right
679 2020-11-03T21:59:42  <amiti> (for anyone wondering, #19594)
680 2020-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
681 2020-11-03T22:00:18  <sipa> i mean: it was intended for supporting bootstrap.dat, and i think that's the only use case
682 2020-11-03T22:00:30  <sipa> if there is anyone actively relying on that feature i don't know
683 2020-11-03T22:00:47  <amiti> gotcha. ok maybe I could rephrase the question as- does anyone actively use bootstrap.dat?
684 2020-11-03T22:02:18  <luke-jr> it's not even maintained anymore
685 2020-11-03T22:03:09  <sipa> not by us
686 2020-11-03T22:03:18  <sipa> though some sites provide them
687 2020-11-03T22:04:07  <luke-jr> updated? O.o
688 2020-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
689 2020-11-03T22:04:35  <sipa> https://flo.sh/download-bitcoin-blockchain-bootstrap/ apparently has a fairly recent one
690 2020-11-03T22:04:50  <luke-jr> TIL
691 2020-11-03T22:05:03  <luke-jr> I suppose it might be handy for people syncing offline PCs
692 2020-11-03T22:05:55  <sipa> TIL also
693 2020-11-03T22:06:33  <luke-jr> hmm, I should probably stop parsing my entire debug.log every hour
694 2020-11-03T22:06:42  <luke-jr> it's getting behind XD
695 2020-11-03T22:07:23  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC
696 2020-11-03T22:08:28  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
697 2020-11-03T22:10:07  *** roconnor <roconnor!~roconnor@host-192.252-162-14.dyn.295.ca> has joined #bitcoin-core-dev
698 2020-11-03T22:10:38  *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc> has joined #bitcoin-core-dev
699 2020-11-03T22:12:03  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC
700 2020-11-03T22:12:04  *** vasild_ is now known as vasild
701 2020-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)
702 2020-11-03T22:13:37  <sipa> i expect you can just rename a bootstrap.dat file to be blk00000.dat, and run -reindex
703 2020-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
704 2020-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
705 2020-11-03T22:16:03  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
706 2020-11-03T22:17:15  *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-sbxxrzmtejfxourc> has left #bitcoin-core-dev
707 2020-11-03T22:18:17  *** filchef <filchef!~filchef@> has quit IRC
708 2020-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
709 2020-11-03T22:19:35  <luke-jr> loadblock just treats the file as an untrusted peer
710 2020-11-03T22:20:24  <sipa> amiti: no, it's exactly the same
711 2020-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)
712 2020-11-03T22:20:59  <amiti> ahhhh I see
713 2020-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
714 2020-11-03T22:22:11  <sipa> i also don't think it's a large burden, thoug
715 2020-11-03T22:23:05  * midnight makes use of loadblocks still fwiw
716 2020-11-03T22:23:12  <sipa> good to know!
717 2020-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?"
718 2020-11-03T22:23:41  <sipa> i don't think i've personally used it for many years
719 2020-11-03T22:23:57  <amiti> midnight: ooo, willing to tell us more about how/why you use it?
720 2020-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.
721 2020-11-03T22:33:37  <midnight> I'd be completely fine with just a network-based block injector if it exists.
722 2020-11-03T22:35:06  <amiti> okay gotcha. thanks!
723 2020-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.
724 2020-11-03T22:36:02  <midnight> (so, I test it first before handing it to them)
725 2020-11-03T22:36:57  *** Kiminuo <Kiminuo!~mix@> has quit IRC
726 2020-11-03T22:41:24  <amiti> 👍
727 2020-11-03T22:53:04  *** quijote_ <quijote_!~dqx@unaffiliated/dqx> has quit IRC
728 2020-11-03T22:53:51  *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-njtrdildhtememmh> has joined #bitcoin-core-dev
729 2020-11-03T22:55:28  *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
730 2020-11-03T22:57:30  *** mdunnio <mdunnio!~mdunnio@> has quit IRC
731 2020-11-03T22:58:58  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC
732 2020-11-03T23:03:19  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC
733 2020-11-03T23:04:27  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has joined #bitcoin-core-dev
734 2020-11-03T23:09:57  *** promag <promag!~promag@> has joined #bitcoin-core-dev
735 2020-11-03T23:10:34  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
736 2020-11-03T23:13:24  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
737 2020-11-03T23:15:10  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
738 2020-11-03T23:16:13  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
739 2020-11-03T23:20:25  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
740 2020-11-03T23:23:35  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
741 2020-11-03T23:24:19  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
742 2020-11-03T23:28:07  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
743 2020-11-03T23:28:25  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC
744 2020-11-03T23:29:10  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~textual@n11211935170.netvigator.com> has quit IRC
745 2020-11-03T23:29:25  *** kexkey <kexkey!~kexkey@static-198-54-132-118.cust.tzulo.com> has quit IRC
746 2020-11-03T23:33:38  *** flag <flag!~flag@net-93-66-105-239.cust.vodafonedsl.it> has quit IRC
747 2020-11-03T23:39:30  *** windsok_ <windsok_!~windsok@rarepepe.cash> has quit IRC
748 2020-11-03T23:39:30  *** windsok_ <windsok_!~windsok@unaffiliated/windsok> has joined #bitcoin-core-dev
749 2020-11-03T23:39:45  *** windsok_ is now known as windsok