1 2020-04-16T00:00:01  *** Frost1 has quit IRC
  2 2020-04-16T00:12:18  *** mol_ has quit IRC
  3 2020-04-16T00:13:05  *** mol has joined #bitcoin-core-dev
  4 2020-04-16T00:18:29  *** AaronvanW has quit IRC
  5 2020-04-16T00:21:49  *** jscarmona1 has joined #bitcoin-core-dev
  6 2020-04-16T00:40:02  *** bitcoin-git has joined #bitcoin-core-dev
  7 2020-04-16T00:40:03  <bitcoin-git> [bitcoin] saahilshangle opened pull request #18663: doc: Adding hyperlink to INSTALL.md in README.md (master...readme-build-instructions) https://github.com/bitcoin/bitcoin/pull/18663
  8 2020-04-16T00:40:03  *** bitcoin-git has left #bitcoin-core-dev
  9 2020-04-16T00:53:07  *** promag__ has quit IRC
 10 2020-04-16T00:53:35  *** promag has quit IRC
 11 2020-04-16T00:54:29  *** bitdex has joined #bitcoin-core-dev
 12 2020-04-16T01:03:26  *** infernix has joined #bitcoin-core-dev
 13 2020-04-16T01:08:34  *** DeanWeen has quit IRC
 14 2020-04-16T01:14:46  *** DeanWeen has joined #bitcoin-core-dev
 15 2020-04-16T01:16:28  *** Chris_Stewart_5 has quit IRC
 16 2020-04-16T01:18:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 17 2020-04-16T01:20:12  *** AaronvanW has joined #bitcoin-core-dev
 18 2020-04-16T01:27:44  *** promag has joined #bitcoin-core-dev
 19 2020-04-16T01:32:37  *** mol_ has joined #bitcoin-core-dev
 20 2020-04-16T01:32:44  *** promag has quit IRC
 21 2020-04-16T01:33:31  *** lightlike has quit IRC
 22 2020-04-16T01:33:43  *** mol has quit IRC
 23 2020-04-16T01:46:03  *** unruly247 has joined #bitcoin-core-dev
 24 2020-04-16T01:54:12  *** AaronvanW has quit IRC
 25 2020-04-16T01:57:34  *** Highway61 has quit IRC
 26 2020-04-16T02:03:36  *** captjakk has quit IRC
 27 2020-04-16T02:08:03  *** bitdex has quit IRC
 28 2020-04-16T02:08:10  *** captjakk has joined #bitcoin-core-dev
 29 2020-04-16T02:08:12  *** captjakk has quit IRC
 30 2020-04-16T02:08:24  *** captjakk has joined #bitcoin-core-dev
 31 2020-04-16T02:08:28  *** bitdex has joined #bitcoin-core-dev
 32 2020-04-16T02:16:23  *** owowo has quit IRC
 33 2020-04-16T02:20:54  *** Deacyde has joined #bitcoin-core-dev
 34 2020-04-16T02:21:12  *** owowo has joined #bitcoin-core-dev
 35 2020-04-16T02:27:56  *** unruly247 has quit IRC
 36 2020-04-16T02:29:44  *** unruly247 has joined #bitcoin-core-dev
 37 2020-04-16T02:53:00  <meshcollider> So #18572 and #18550 are talking about being included in 0.20, but they're obviously not in rc1, so what exactly is happening there?
 38 2020-04-16T02:53:02  <gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
 39 2020-04-16T02:53:03  <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
 40 2020-04-16T03:00:02  *** jscarmona1 has quit IRC
 41 2020-04-16T03:14:13  *** go1111111 has quit IRC
 42 2020-04-16T03:22:01  *** frank001 has joined #bitcoin-core-dev
 43 2020-04-16T03:22:04  *** Eagle[TM] has joined #bitcoin-core-dev
 44 2020-04-16T03:24:21  *** EagleTM has quit IRC
 45 2020-04-16T03:36:11  *** BlueMatt has quit IRC
 46 2020-04-16T03:36:29  *** BlueMatt has joined #bitcoin-core-dev
 47 2020-04-16T03:37:26  *** BlueMatt has quit IRC
 48 2020-04-16T03:37:44  *** BlueMatt has joined #bitcoin-core-dev
 49 2020-04-16T03:39:14  *** promag has joined #bitcoin-core-dev
 50 2020-04-16T03:43:55  *** promag has quit IRC
 51 2020-04-16T03:50:45  *** AaronvanW has joined #bitcoin-core-dev
 52 2020-04-16T03:58:05  *** Chris_Stewart_5 has quit IRC
 53 2020-04-16T04:24:02  *** AaronvanW has quit IRC
 54 2020-04-16T04:29:37  *** jarthur_ has joined #bitcoin-core-dev
 55 2020-04-16T04:33:12  *** jarthur has quit IRC
 56 2020-04-16T04:49:58  *** Talkless has joined #bitcoin-core-dev
 57 2020-04-16T04:50:43  *** Talkless has quit IRC
 58 2020-04-16T05:08:05  *** robot-visions has joined #bitcoin-core-dev
 59 2020-04-16T05:14:22  *** jorijn has quit IRC
 60 2020-04-16T05:15:02  *** robot-visions has quit IRC
 61 2020-04-16T05:15:07  *** jorijn has joined #bitcoin-core-dev
 62 2020-04-16T05:29:59  *** MarcoFalke has quit IRC
 63 2020-04-16T05:30:18  *** MarcoFalke has joined #bitcoin-core-dev
 64 2020-04-16T05:38:56  *** captjakk has quit IRC
 65 2020-04-16T05:39:30  *** captjakk has joined #bitcoin-core-dev
 66 2020-04-16T05:43:53  *** captjakk has quit IRC
 67 2020-04-16T05:48:51  *** vincenzopalazzo has quit IRC
 68 2020-04-16T06:00:02  *** frank001 has quit IRC
 69 2020-04-16T06:04:48  *** niska has quit IRC
 70 2020-04-16T06:12:06  *** niska has joined #bitcoin-core-dev
 71 2020-04-16T06:19:29  *** captjakk has joined #bitcoin-core-dev
 72 2020-04-16T06:21:10  *** nighmi has joined #bitcoin-core-dev
 73 2020-04-16T06:21:33  *** AaronvanW has joined #bitcoin-core-dev
 74 2020-04-16T06:21:34  *** nighmi is now known as Guest89944
 75 2020-04-16T06:24:27  *** captjakk has quit IRC
 76 2020-04-16T06:24:28  *** DeanWeen has quit IRC
 77 2020-04-16T06:24:55  *** DeanWeen has joined #bitcoin-core-dev
 78 2020-04-16T06:29:52  *** amsudeep has joined #bitcoin-core-dev
 79 2020-04-16T06:36:34  *** gwillen has quit IRC
 80 2020-04-16T06:37:44  *** gwillen has joined #bitcoin-core-dev
 81 2020-04-16T06:49:53  *** Guyver2 has joined #bitcoin-core-dev
 82 2020-04-16T06:54:02  *** AaronvanW has quit IRC
 83 2020-04-16T07:00:53  *** promag has joined #bitcoin-core-dev
 84 2020-04-16T07:10:23  *** captjakk has joined #bitcoin-core-dev
 85 2020-04-16T07:15:26  *** captjakk has quit IRC
 86 2020-04-16T07:21:16  *** AaronvanW has joined #bitcoin-core-dev
 87 2020-04-16T07:44:43  *** vasild has quit IRC
 88 2020-04-16T07:46:14  *** vasild has joined #bitcoin-core-dev
 89 2020-04-16T07:46:43  <ryanofsky> meshcollider: i think both prs should be dropped, but first pr is basically harmless, only second pr has bad side effects
 90 2020-04-16T07:56:29  *** AaronvanW has quit IRC
 91 2020-04-16T07:56:45  *** AaronvanW has joined #bitcoin-core-dev
 92 2020-04-16T08:04:48  *** promag has quit IRC
 93 2020-04-16T08:07:38  *** brakmic has joined #bitcoin-core-dev
 94 2020-04-16T08:11:56  *** brakmic has quit IRC
 95 2020-04-16T08:12:34  *** brakmic has joined #bitcoin-core-dev
 96 2020-04-16T08:14:00  *** brakmic_ has joined #bitcoin-core-dev
 97 2020-04-16T08:17:16  *** brakmic has quit IRC
 98 2020-04-16T08:20:47  *** marcoagner has joined #bitcoin-core-dev
 99 2020-04-16T08:28:50  *** Kiminuo has quit IRC
100 2020-04-16T08:37:19  *** emilengler has joined #bitcoin-core-dev
101 2020-04-16T08:43:04  *** promag has joined #bitcoin-core-dev
102 2020-04-16T08:43:08  *** promag_ has joined #bitcoin-core-dev
103 2020-04-16T09:00:02  *** Guest89944 has quit IRC
104 2020-04-16T09:00:59  *** Eagle[TM] has quit IRC
105 2020-04-16T09:07:03  *** jonatack has quit IRC
106 2020-04-16T09:09:09  *** jonatack has joined #bitcoin-core-dev
107 2020-04-16T09:11:17  *** captjakk has joined #bitcoin-core-dev
108 2020-04-16T09:16:17  *** captjakk has quit IRC
109 2020-04-16T09:22:03  *** Mikaku1 has joined #bitcoin-core-dev
110 2020-04-16T09:26:50  *** timothy has joined #bitcoin-core-dev
111 2020-04-16T09:34:11  *** murray_ has joined #bitcoin-core-dev
112 2020-04-16T09:34:21  *** murrayn has quit IRC
113 2020-04-16T09:34:55  *** murray_ has left #bitcoin-core-dev
114 2020-04-16T09:35:57  *** murrayn has joined #bitcoin-core-dev
115 2020-04-16T09:44:25  <wumpus> meshcollider: the logic is like: *IF* we need a rc2, might as well include them, I think
116 2020-04-16T09:44:34  <wumpus> I don't think they necessiate a rc2 by themselves
117 2020-04-16T09:45:01  <wumpus> but generally for major releases we have around 4-5 rcs so ok
118 2020-04-16T09:45:03  *** brakmic_ has quit IRC
119 2020-04-16T09:45:24  *** brakmic has joined #bitcoin-core-dev
120 2020-04-16T09:46:36  <wumpus> but we could remove the milestone from it if people prefer that (especially if they have bad side effects), or generally if they don't get enough ACKs
121 2020-04-16T09:54:13  *** jonatack has quit IRC
122 2020-04-16T09:55:06  *** jonatack has joined #bitcoin-core-dev
123 2020-04-16T09:55:32  *** jonatack has joined #bitcoin-core-dev
124 2020-04-16T09:59:06  *** justanotheruser has quit IRC
125 2020-04-16T10:04:01  *** Celine59Mann has joined #bitcoin-core-dev
126 2020-04-16T10:09:05  *** promag__ has joined #bitcoin-core-dev
127 2020-04-16T10:09:11  *** promag_ has quit IRC
128 2020-04-16T10:11:03  *** vasild has quit IRC
129 2020-04-16T10:16:29  *** vasild has joined #bitcoin-core-dev
130 2020-04-16T10:17:46  *** pinheadmz_ has joined #bitcoin-core-dev
131 2020-04-16T10:18:48  <meshcollider> I don't think they've even got the milestone, it was just mentioned in the OP
132 2020-04-16T10:19:28  <meshcollider> First PR is harmless but also pointless
133 2020-04-16T10:20:34  *** pinheadmz has quit IRC
134 2020-04-16T10:20:34  *** pinheadmz_ is now known as pinheadmz
135 2020-04-16T10:23:23  <jonatack> meshcollider: fwiw #17824 has acks by kallewoof and myself and review by instagibbs and achow101
136 2020-04-16T10:23:26  <gribble> https://github.com/bitcoin/bitcoin/issues/17824 | wallet: Prefer full destination groups in coin selection by fjahr · Pull Request #17824 · bitcoin/bitcoin · GitHub
137 2020-04-16T10:23:52  <jonatack> it's a bugfix for #17603
138 2020-04-16T10:23:53  <gribble> https://github.com/bitcoin/bitcoin/issues/17603 | partial spend avoidance makes partial spends and getbalances doesnt notice · Issue #17603 · bitcoin/bitcoin · GitHub
139 2020-04-16T10:25:55  *** Celine59Mann has quit IRC
140 2020-04-16T10:26:25  <meshcollider> jonatack: cool thanks, I'll look at it first thing tomorrow morning, it's getting late here :)
141 2020-04-16T10:27:33  <jonatack> meshcollider: 👍
142 2020-04-16T10:29:15  <meshcollider> ryanofsky: After reading through your comments, I agree with you, I'll close both the PRs
143 2020-04-16T10:29:48  <meshcollider> If Luke has a strong argument that we are missing, we can discuss in the meeting tomorrow
144 2020-04-16T10:31:39  *** bitcoin-git has joined #bitcoin-core-dev
145 2020-04-16T10:31:39  <bitcoin-git> [bitcoin] meshcollider closed pull request #18550: Store destdata for change in separate key for backward compatibility (master...changedata) https://github.com/bitcoin/bitcoin/pull/18550
146 2020-04-16T10:31:40  *** bitcoin-git has left #bitcoin-core-dev
147 2020-04-16T10:32:54  *** bitcoin-git has joined #bitcoin-core-dev
148 2020-04-16T10:32:54  <bitcoin-git> [bitcoin] meshcollider closed pull request #18572: Wallet: Accept "changedata" db key as an alias to "destdata" (master...changedata_forwardcompat) https://github.com/bitcoin/bitcoin/pull/18572
149 2020-04-16T10:32:55  *** bitcoin-git has left #bitcoin-core-dev
150 2020-04-16T10:34:33  <jonatack> Next wallet meeting is April 24 (in 8 days) if not mistaken
151 2020-04-16T10:35:03  <jonatack> (we did one last week)
152 2020-04-16T10:36:47  <aj> on this side of the world, regular meeting is tomorrow
153 2020-04-16T10:47:05  <fanquake> aj: tossing a coin on attendance
154 2020-04-16T10:57:01  <meshcollider> Yeah sorry I mean the regular meeting which is "today"
155 2020-04-16T11:13:34  *** IGHOR has quit IRC
156 2020-04-16T11:26:40  *** DeanWeen has quit IRC
157 2020-04-16T11:28:03  *** DeanWeen has joined #bitcoin-core-dev
158 2020-04-16T11:28:52  *** bitcoin-git has joined #bitcoin-core-dev
159 2020-04-16T11:28:53  <bitcoin-git> [bitcoin] jonatack opened pull request #18664: fuzz: fix unused variable compiler warning (master...fix-unused-variable-warning) https://github.com/bitcoin/bitcoin/pull/18664
160 2020-04-16T11:28:53  *** bitcoin-git has left #bitcoin-core-dev
161 2020-04-16T11:29:32  *** timothy has quit IRC
162 2020-04-16T11:35:17  *** amsudeep has quit IRC
163 2020-04-16T11:35:35  *** amsudeep has joined #bitcoin-core-dev
164 2020-04-16T11:42:14  *** mytwocentimes has quit IRC
165 2020-04-16T11:42:57  *** mytwocentimes has joined #bitcoin-core-dev
166 2020-04-16T11:43:01  *** jonatack has quit IRC
167 2020-04-16T11:47:24  *** captjakk has joined #bitcoin-core-dev
168 2020-04-16T11:47:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
169 2020-04-16T11:51:35  *** mol_ has quit IRC
170 2020-04-16T11:52:23  *** captjakk has quit IRC
171 2020-04-16T11:55:02  *** Kiminuo has joined #bitcoin-core-dev
172 2020-04-16T11:56:39  *** jonatack has joined #bitcoin-core-dev
173 2020-04-16T11:58:08  *** mol has joined #bitcoin-core-dev
174 2020-04-16T12:00:02  *** Mikaku1 has quit IRC
175 2020-04-16T12:22:15  *** Dantman has joined #bitcoin-core-dev
176 2020-04-16T12:31:12  *** Highway61 has joined #bitcoin-core-dev
177 2020-04-16T12:33:06  *** bitcoin-git has joined #bitcoin-core-dev
178 2020-04-16T12:33:06  <bitcoin-git> [bitcoin] hebasto opened pull request #18665: Do not expose -logthreadnames when it does not work (master...200416-logthreads) https://github.com/bitcoin/bitcoin/pull/18665
179 2020-04-16T12:33:07  *** bitcoin-git has left #bitcoin-core-dev
180 2020-04-16T12:33:50  *** mytwocentimes has quit IRC
181 2020-04-16T12:34:05  *** mytwocentimes has joined #bitcoin-core-dev
182 2020-04-16T12:44:48  *** fengling has quit IRC
183 2020-04-16T12:54:05  *** bitcoin-git has joined #bitcoin-core-dev
184 2020-04-16T12:54:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/544709763e1f...e16718a8b3db
185 2020-04-16T12:54:06  <bitcoin-git> bitcoin/master f63dec1 Pieter Wuille: [REFACTOR] Initialize PrecomputedTransactionData in CheckInputScripts
186 2020-04-16T12:54:06  <bitcoin-git> bitcoin/master e16718a MarcoFalke: Merge #18401: Refactor: Initialize PrecomputedTransactionData in CheckInpu...
187 2020-04-16T12:54:07  *** bitcoin-git has left #bitcoin-core-dev
188 2020-04-16T12:54:30  *** bitcoin-git has joined #bitcoin-core-dev
189 2020-04-16T12:54:30  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18401: Refactor: Initialize PrecomputedTransactionData in CheckInputScripts (master...2020-03-precomputedtransactiondata) https://github.com/bitcoin/bitcoin/pull/18401
190 2020-04-16T12:54:33  *** bitcoin-git has left #bitcoin-core-dev
191 2020-04-16T13:30:58  *** timothy has joined #bitcoin-core-dev
192 2020-04-16T13:48:16  *** captjakk has joined #bitcoin-core-dev
193 2020-04-16T13:52:44  *** captjakk has quit IRC
194 2020-04-16T14:01:30  *** bitcoin-git has joined #bitcoin-core-dev
195 2020-04-16T14:01:30  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e16718a8b3db...79b0459648e3
196 2020-04-16T14:01:31  <bitcoin-git> bitcoin/master a95af77 practicalswift: qt: Make bitcoin.ico non-executable
197 2020-04-16T14:01:31  <bitcoin-git> bitcoin/master 79b0459 MarcoFalke: Merge #18650: qt: Make bitcoin.ico non-executable
198 2020-04-16T14:01:33  *** bitcoin-git has left #bitcoin-core-dev
199 2020-04-16T14:01:50  *** bitcoin-git has joined #bitcoin-core-dev
200 2020-04-16T14:01:50  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18650: qt: Make bitcoin.ico non-executable (master...bitcoin.ico-executable-flag) https://github.com/bitcoin/bitcoin/pull/18650
201 2020-04-16T14:01:51  *** bitcoin-git has left #bitcoin-core-dev
202 2020-04-16T14:08:02  *** IGHOR has joined #bitcoin-core-dev
203 2020-04-16T14:11:03  *** bitcoin-git has joined #bitcoin-core-dev
204 2020-04-16T14:11:03  <bitcoin-git> [bitcoin] hebasto opened pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
205 2020-04-16T14:11:04  *** bitcoin-git has left #bitcoin-core-dev
206 2020-04-16T14:11:39  *** kristapsk has quit IRC
207 2020-04-16T14:12:04  *** kristapsk has joined #bitcoin-core-dev
208 2020-04-16T14:13:24  *** bitcoin-git has joined #bitcoin-core-dev
209 2020-04-16T14:13:24  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/79b0459648e3...661e8df1b63b
210 2020-04-16T14:13:25  <bitcoin-git> bitcoin/master 727b67e Jon Atack: test: add coverage for bitcoin-cli -rpcwait
211 2020-04-16T14:13:26  <bitcoin-git> bitcoin/master becc8b9 Jon Atack: test: verify bitcoin-cli -version with node stopped
212 2020-04-16T14:13:27  <bitcoin-git> bitcoin/master bb13f46 Jon Atack: test: verify cli.getwalletinfo in wallet section
213 2020-04-16T14:13:36  *** bitcoin-git has left #bitcoin-core-dev
214 2020-04-16T14:13:53  *** bitcoin-git has joined #bitcoin-core-dev
215 2020-04-16T14:13:54  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18653:  test: add coverage for bitcoin-cli -rpcwait (master...rpcwait-test-coverage) https://github.com/bitcoin/bitcoin/pull/18653
216 2020-04-16T14:13:54  *** bitcoin-git has left #bitcoin-core-dev
217 2020-04-16T14:14:16  *** fibo has joined #bitcoin-core-dev
218 2020-04-16T14:14:35  *** fibo has quit IRC
219 2020-04-16T14:15:01  *** fizo has joined #bitcoin-core-dev
220 2020-04-16T14:28:36  *** fizo has quit IRC
221 2020-04-16T14:39:36  *** theStack has joined #bitcoin-core-dev
222 2020-04-16T14:40:46  *** dviola has quit IRC
223 2020-04-16T14:56:36  *** Talkless has joined #bitcoin-core-dev
224 2020-04-16T15:00:01  *** Dantman has quit IRC
225 2020-04-16T15:02:20  *** TheRec_ has quit IRC
226 2020-04-16T15:08:49  *** per is now known as wsm
227 2020-04-16T15:14:27  *** bitcoin-git has joined #bitcoin-core-dev
228 2020-04-16T15:14:27  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18669: log: Use Join() helper when listing log categories (master...2004-logJoin) https://github.com/bitcoin/bitcoin/pull/18669
229 2020-04-16T15:14:29  *** bitcoin-git has left #bitcoin-core-dev
230 2020-04-16T15:15:33  *** captjakk has joined #bitcoin-core-dev
231 2020-04-16T15:20:15  *** bitcoin-git has joined #bitcoin-core-dev
232 2020-04-16T15:20:15  <bitcoin-git> [bitcoin] theStack opened pull request #18670: refactor: Remove unused method CBloomFilter::reset() (master...20200416-refactor-remove-unused-bloom-filter-reset) https://github.com/bitcoin/bitcoin/pull/18670
233 2020-04-16T15:20:16  *** bitcoin-git has left #bitcoin-core-dev
234 2020-04-16T15:20:41  *** kik1 has joined #bitcoin-core-dev
235 2020-04-16T15:30:33  <theStack> i have a linking problem on the fuzz test http_request:
236 2020-04-16T15:30:35  <theStack> /home/honeybadger/buidl/bitcoin_fuzz/src/test/fuzz/http_request.cpp:34: undefined reference to `evhttp_parse_firstline_'
237 2020-04-16T15:31:10  <theStack> i found out though that i have libevent version 2.0.21, but the minimum required version is 2.0.22 (according to doc/dependencies.md)
238 2020-04-16T15:31:24  <theStack> shouldn't the build process check for all minimum required versions?
239 2020-04-16T15:32:06  <theStack> (without fuzzing enabled, everything compiles fine on master branch)
240 2020-04-16T15:33:06  *** jarthur has joined #bitcoin-core-dev
241 2020-04-16T15:43:34  *** unruly247 has quit IRC
242 2020-04-16T15:44:31  *** unruly247 has joined #bitcoin-core-dev
243 2020-04-16T15:45:41  *** unruly247 has quit IRC
244 2020-04-16T15:46:10  *** bitcoin-git has joined #bitcoin-core-dev
245 2020-04-16T15:46:11  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/661e8df1b63b...f4c0ad4aefe0
246 2020-04-16T15:46:11  <bitcoin-git> bitcoin/master 9986608 Russell Yanofsky: test: Verify findCommonAncestor always initializes outputs
247 2020-04-16T15:46:12  <bitcoin-git> bitcoin/master f4c0ad4 MarcoFalke: Merge #18660: test: Verify findCommonAncestor always initializes outputs
248 2020-04-16T15:46:14  *** bitcoin-git has left #bitcoin-core-dev
249 2020-04-16T15:46:20  *** unruly247 has joined #bitcoin-core-dev
250 2020-04-16T15:46:31  *** bitcoin-git has joined #bitcoin-core-dev
251 2020-04-16T15:46:31  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18660: test: Verify findCommonAncestor always initializes outputs (master...pr/commoninit) https://github.com/bitcoin/bitcoin/pull/18660
252 2020-04-16T15:46:32  *** bitcoin-git has left #bitcoin-core-dev
253 2020-04-16T15:46:54  *** unruly247 has quit IRC
254 2020-04-16T15:49:34  *** unruly247 has joined #bitcoin-core-dev
255 2020-04-16T15:52:56  *** TheRec has joined #bitcoin-core-dev
256 2020-04-16T15:52:56  *** TheRec has joined #bitcoin-core-dev
257 2020-04-16T15:54:12  *** andrewtoth has quit IRC
258 2020-04-16T15:54:26  *** andrewtoth has joined #bitcoin-core-dev
259 2020-04-16T15:56:59  *** captjakk has quit IRC
260 2020-04-16T15:57:15  *** captjakk has joined #bitcoin-core-dev
261 2020-04-16T16:01:08  *** Emcy has quit IRC
262 2020-04-16T16:01:50  *** Emcy has joined #bitcoin-core-dev
263 2020-04-16T16:03:37  *** bitcoin-git has joined #bitcoin-core-dev
264 2020-04-16T16:03:37  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18671: wallet: Add BlockUntilSyncedToCurrentChain to dumpwallet (master...2004-walletDumpChain) https://github.com/bitcoin/bitcoin/pull/18671
265 2020-04-16T16:03:38  *** bitcoin-git has left #bitcoin-core-dev
266 2020-04-16T16:26:30  *** Emcy has quit IRC
267 2020-04-16T16:27:04  *** Emcy has joined #bitcoin-core-dev
268 2020-04-16T16:29:52  *** mol_ has joined #bitcoin-core-dev
269 2020-04-16T16:31:45  *** Emcy has quit IRC
270 2020-04-16T16:32:20  *** Emcy has joined #bitcoin-core-dev
271 2020-04-16T16:33:20  *** mol has quit IRC
272 2020-04-16T16:36:30  *** alko89 has joined #bitcoin-core-dev
273 2020-04-16T16:38:13  *** emilengler has quit IRC
274 2020-04-16T16:41:14  *** jarthur has quit IRC
275 2020-04-16T16:41:42  *** jarthur has joined #bitcoin-core-dev
276 2020-04-16T16:42:35  *** andrewtoth has quit IRC
277 2020-04-16T16:43:18  *** andrewtoth has joined #bitcoin-core-dev
278 2020-04-16T16:43:52  *** emilengler has joined #bitcoin-core-dev
279 2020-04-16T16:54:58  *** captjakk has quit IRC
280 2020-04-16T16:55:30  *** captjakk has joined #bitcoin-core-dev
281 2020-04-16T16:58:51  *** bitcoin-git has joined #bitcoin-core-dev
282 2020-04-16T16:58:52  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f4c0ad4aefe0...d8dfcea5d956
283 2020-04-16T16:58:52  <bitcoin-git> bitcoin/master bee88b8 James O'Beirne: tests: have coins simulation test also use CCoinsViewDB
284 2020-04-16T16:58:53  <bitcoin-git> bitcoin/master d8dfcea MarcoFalke: Merge #17669: tests: have coins simulation test also use CCoinsViewDB
285 2020-04-16T16:58:56  *** bitcoin-git has left #bitcoin-core-dev
286 2020-04-16T16:59:41  *** bitcoin-git has joined #bitcoin-core-dev
287 2020-04-16T16:59:41  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
288 2020-04-16T16:59:42  *** bitcoin-git has left #bitcoin-core-dev
289 2020-04-16T17:00:03  *** captjakk has quit IRC
290 2020-04-16T17:07:42  *** bitcoin-git has joined #bitcoin-core-dev
291 2020-04-16T17:07:43  <bitcoin-git> [bitcoin] theStack opened pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672
292 2020-04-16T17:07:43  *** bitcoin-git has left #bitcoin-core-dev
293 2020-04-16T17:09:24  *** molz_ has joined #bitcoin-core-dev
294 2020-04-16T17:12:51  *** mol_ has quit IRC
295 2020-04-16T17:13:27  *** mol has joined #bitcoin-core-dev
296 2020-04-16T17:15:47  *** bitcoin-git has joined #bitcoin-core-dev
297 2020-04-16T17:15:47  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #18673: scripted-diff: Sort test includes (master...2004-testSortIncludes) https://github.com/bitcoin/bitcoin/pull/18673
298 2020-04-16T17:15:48  *** bitcoin-git has left #bitcoin-core-dev
299 2020-04-16T17:16:24  *** molz_ has quit IRC
300 2020-04-16T17:36:10  *** Kiminuo has quit IRC
301 2020-04-16T17:36:52  *** Kiminuo has joined #bitcoin-core-dev
302 2020-04-16T17:37:47  *** mytwocentimes has quit IRC
303 2020-04-16T17:39:21  *** mytwocentimes has joined #bitcoin-core-dev
304 2020-04-16T17:46:15  *** captjakk has joined #bitcoin-core-dev
305 2020-04-16T17:48:17  *** luke-jr has joined #bitcoin-core-dev
306 2020-04-16T17:54:44  <MarcoFalke> theStack: Maybe file an issue?
307 2020-04-16T18:00:02  *** kik1 has quit IRC
308 2020-04-16T18:05:14  *** andrewtoth_ has joined #bitcoin-core-dev
309 2020-04-16T18:06:23  *** andrewtoth has quit IRC
310 2020-04-16T18:08:42  *** justanotheruser has joined #bitcoin-core-dev
311 2020-04-16T18:11:03  *** andrewtoth_ has quit IRC
312 2020-04-16T18:14:49  *** berndj has quit IRC
313 2020-04-16T18:15:52  *** captjakk has quit IRC
314 2020-04-16T18:16:26  *** captjakk has joined #bitcoin-core-dev
315 2020-04-16T18:16:46  *** mytwocentimes has quit IRC
316 2020-04-16T18:16:59  *** mytwocentimes has joined #bitcoin-core-dev
317 2020-04-16T18:21:15  *** captjakk_ has joined #bitcoin-core-dev
318 2020-04-16T18:22:15  *** mikeyman77 has joined #bitcoin-core-dev
319 2020-04-16T18:22:55  *** captjakk_ has quit IRC
320 2020-04-16T18:23:57  *** captjakk_ has joined #bitcoin-core-dev
321 2020-04-16T18:23:59  *** captjakk_ has quit IRC
322 2020-04-16T18:24:13  *** captjakk_ has joined #bitcoin-core-dev
323 2020-04-16T18:25:45  *** berndj has joined #bitcoin-core-dev
324 2020-04-16T18:26:02  *** captjakk has quit IRC
325 2020-04-16T18:28:18  *** DeanWeen has quit IRC
326 2020-04-16T18:30:04  *** mol has quit IRC
327 2020-04-16T18:30:26  *** DeanWeen has joined #bitcoin-core-dev
328 2020-04-16T18:32:27  *** amsudeep has quit IRC
329 2020-04-16T18:33:13  <wumpus> checking the minimum libevent version in configure would make sense
330 2020-04-16T18:34:19  <wumpus> the build system has historically not checked minimum versions at all as far as I know, but it'd be a good thing to do, bigger chance that someone will figure out what is the problem in that way than having to check a separate documentation file
331 2020-04-16T18:35:05  <wumpus> libevent 2.0.21 is *ancient* though
332 2020-04-16T18:35:26  <wumpus> 8 years old now
333 2020-04-16T18:35:35  *** berndj has quit IRC
334 2020-04-16T18:36:07  <wumpus> things move on and we can't support old software forever, that's just not realistic
335 2020-04-16T18:37:40  <luke-jr> the old version isn't what matters for such questions IMO
336 2020-04-16T18:37:49  <luke-jr> but rather, how old/widespread is the new minimum?
337 2020-04-16T18:37:55  *** mol has joined #bitcoin-core-dev
338 2020-04-16T18:38:45  <wumpus> there is no new minimum
339 2020-04-16T18:39:05  <wumpus> this is about enforcing the current minimum in configure.ac
340 2020-04-16T18:39:46  *** berndj has joined #bitcoin-core-dev
341 2020-04-16T18:40:34  *** brakmic has quit IRC
342 2020-04-16T18:41:09  <wumpus> which has been 2.0.22 pretty much forever
343 2020-04-16T18:41:30  <luke-jr> afaik that's pretty easy
344 2020-04-16T18:41:34  <MarcoFalke> I don't understand how Bitcoin Core compiles fine, but the fuzz tests don't
345 2020-04-16T18:41:53  *** kvaciral has joined #bitcoin-core-dev
346 2020-04-16T18:43:46  <wumpus> I don't, either, but please just use a newer libevent version, many bugs have been fixed since
347 2020-04-16T18:55:06  *** captjakk_ has quit IRC
348 2020-04-16T18:55:42  *** captjakk has joined #bitcoin-core-dev
349 2020-04-16T19:00:17  *** captjakk has quit IRC
350 2020-04-16T19:00:35  <MarcoFalke> Yeah, fuzzing old libevent isn't that helpful
351 2020-04-16T19:01:41  <meshcollider> Meeting?
352 2020-04-16T19:02:25  <luke-jr> (let's get to the wallet issue this time)
353 2020-04-16T19:03:39  <achow101> meeting?
354 2020-04-16T19:03:58  <wumpus> #startmeeting
355 2020-04-16T19:03:58  <lightningbot> Meeting started Thu Apr 16 19:03:58 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
356 2020-04-16T19:03:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
357 2020-04-16T19:03:59  *** jb55 has quit IRC
358 2020-04-16T19:04:01  <jonasschnelli> hi
359 2020-04-16T19:04:03  <sipa> hi
360 2020-04-16T19:04:06  <achow101> hi
361 2020-04-16T19:04:08  <amiti> hi
362 2020-04-16T19:04:10  <meshcollider> hi
363 2020-04-16T19:04:13  <jonatack> hi
364 2020-04-16T19:04:22  <cfields> hi
365 2020-04-16T19:04:24  *** jb55 has joined #bitcoin-core-dev
366 2020-04-16T19:04:28  <kanzure> hi
367 2020-04-16T19:04:34  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
368 2020-04-16T19:04:36  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
369 2020-04-16T19:04:39  <dongcarl> hi
370 2020-04-16T19:04:51  <elichai2> Hi
371 2020-04-16T19:04:53  <jb55> hi
372 2020-04-16T19:05:14  <wumpus> one proposed topic: experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
373 2020-04-16T19:05:22  <MarcoFalke> hi
374 2020-04-16T19:05:30  <luke-jr> wumpus: I proposed one last week.. which really should get addressed before 0.20
375 2020-04-16T19:05:40  <phantomcircuit> hi
376 2020-04-16T19:05:44  <jkczyz> hi
377 2020-04-16T19:05:51  <fjahr> hi
378 2020-04-16T19:05:56  <cfields> I know fanquake really wants to be part of the multiprocess conversation but he can't make the meeting today.
379 2020-04-16T19:05:57  <hebasto> hi
380 2020-04-16T19:06:19  <cfields> maybe we can introduce the issue here and pick it up on the PR?
381 2020-04-16T19:07:31  <wumpus> luke-jr: can you be more specific? the last topic suggestion from you that I see is the PPA URL and we've spent half a meeting on that
382 2020-04-16T19:07:43  <wumpus> #topic High priority for review
383 2020-04-16T19:07:54  <luke-jr> wumpus: right now, the wallet implementation is still broken, and if we don't address it before 0.20, it complicates backward compatibility
384 2020-04-16T19:08:05  <sipa> can i haz #185512
385 2020-04-16T19:08:06  <gribble> https://github.com/bitcoin/bitcoin/issues/185512 | HTTP Error 404: Not Found
386 2020-04-16T19:08:07  <jonasschnelli> may I add #18242 to the hp list?
387 2020-04-16T19:08:08  <sipa> can i haz #18512
388 2020-04-16T19:08:08  <midnight> hi!
389 2020-04-16T19:08:11  <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
390 2020-04-16T19:08:14  <gribble> https://github.com/bitcoin/bitcoin/issues/18512 | Improve asmap checks and add sanity check by sipa · Pull Request #18512 · bitcoin/bitcoin · GitHub
391 2020-04-16T19:08:21  <luke-jr> re #18192, #18550, #18572, and #18608
392 2020-04-16T19:08:24  <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
393 2020-04-16T19:08:25  <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
394 2020-04-16T19:08:26  <gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
395 2020-04-16T19:08:27  <gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
396 2020-04-16T19:08:37  <wumpus> uhmm slow down a bit please
397 2020-04-16T19:08:44  <jonasschnelli> ;-)
398 2020-04-16T19:09:11  <luke-jr> (my list is not for high-prio-for-review topic)
399 2020-04-16T19:10:53  <achow101> #18598 for 0.20 tag and backport (or merge now)
400 2020-04-16T19:10:55  <gribble> https://github.com/bitcoin/bitcoin/issues/18598 | gitian: Add missing automake package to gitian-win-signer.yml by achow101 · Pull Request #18598 · bitcoin/bitcoin · GitHub
401 2020-04-16T19:10:56  <wumpus> jonasschnelli: sipa  added
402 2020-04-16T19:11:03  <jonasschnelli> thanks
403 2020-04-16T19:11:46  <MarcoFalke> achow101: Assigned milestone. I think this will be dealt with in rc2
404 2020-04-16T19:12:13  <wumpus> yes, if it's required for windows signing on some environments it definitely needs to go into the next rc
405 2020-04-16T19:12:24  <wumpus> I didn't need it for LXC fwiw
406 2020-04-16T19:12:34  <jonasschnelli> me2
407 2020-04-16T19:12:37  <MarcoFalke> happens only on docker/podman
408 2020-04-16T19:12:42  <hebasto> yes, lxc does need it
409 2020-04-16T19:12:58  <achow101> yeah, seems to be a virutaliation specific issue
410 2020-04-16T19:13:12  <achow101> just wanted to make sure no one forgot about it
411 2020-04-16T19:13:29  <hebasto> achow101: mind specify it in pr description?
412 2020-04-16T19:13:32  <wumpus> yes, good point
413 2020-04-16T19:13:51  <jonatack> i think i ran into it when win gitian signing with docker
414 2020-04-16T19:14:17  <achow101> hebasto: done
415 2020-04-16T19:14:19  <wumpus> makes sense
416 2020-04-16T19:15:46  <wumpus> luke-jr: I think there have been some disagreements about your PRs, meshcollider was concerned about #18550 for example
417 2020-04-16T19:15:47  <gribble> https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
418 2020-04-16T19:16:11  <wumpus> it's probably too late in the release cycle to do changes like that
419 2020-04-16T19:16:14  <luke-jr> wumpus: are we changing to that topic now? I can wait a bit
420 2020-04-16T19:16:32  <luke-jr> it's a bugfix
421 2020-04-16T19:17:24  <MarcoFalke> What bug is it fixing? You didn't include any regression tests
422 2020-04-16T19:17:33  <meshcollider> ryanofsky should really be here for this discussion too
423 2020-04-16T19:17:41  <ryanofsky> here
424 2020-04-16T19:17:46  <luke-jr> MarcoFalke: I don't see how to make tests for this kind of thing
425 2020-04-16T19:18:14  <ryanofsky> My summary of the destdata issue is https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
426 2020-04-16T19:18:16  <wumpus> so is it a regression in 0.20?
427 2020-04-16T19:18:41  <MarcoFalke> Is this a bug that users can observe or is it only a developer issue?
428 2020-04-16T19:19:09  <luke-jr> it's a wallet format issue
429 2020-04-16T19:19:21  <luke-jr> if we don't fix it now, it complicates backward compatibility when we do fix it later
430 2020-04-16T19:19:26  <wumpus> yes, if it's hard to write a test for and it's not a GUI issue that usually means it's very hard to observe
431 2020-04-16T19:19:40  <luke-jr> it's hard to write a test, because the breaking is backward compatibility
432 2020-04-16T19:19:49  <luke-jr> so we'd need a way to run an old version
433 2020-04-16T19:20:06  <MarcoFalke> the python tests can do that
434 2020-04-16T19:20:08  <meshcollider> It's not a new issue, the actual issue itself was fixed in #18192
435 2020-04-16T19:20:10  <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
436 2020-04-16T19:20:11  <luke-jr> "destdata" was added in a manner that it only supported non-change
437 2020-04-16T19:20:20  <ryanofsky> Luke, I'm not sure what the exact issue you are concerned about, your PR changes behavior in lots of ways, most of them bad
438 2020-04-16T19:20:26  <luke-jr> but now we suddenly need to support it for change too
439 2020-04-16T19:20:28  <wumpus> destdata has been in there since 2012 or so isn't it
440 2020-04-16T19:20:37  <luke-jr> the problem remaining is that the fix in #18192 breaks compatibility
441 2020-04-16T19:20:40  <gribble> https://github.com/bitcoin/bitcoin/issues/18192 | Bugfix: Wallet: Safely deal with change in the address book by luke-jr · Pull Request #18192 · bitcoin/bitcoin · GitHub
442 2020-04-16T19:20:53  <sipa> luke-jr: can you give an exact scenario for reproducing the issue?
443 2020-04-16T19:20:55  <luke-jr> wumpus: yes, 0.9
444 2020-04-16T19:21:14  <luke-jr> sipa: set a destdata on change, then use the wallet in an older version
445 2020-04-16T19:21:18  <sipa> assuming no further changes related to the topic go into 0.20
446 2020-04-16T19:21:25  <wumpus> why does it now suddenly need to be changed before 0.20
447 2020-04-16T19:21:31  <sipa> what does a user do to cause "set a destdata on change" ?
448 2020-04-16T19:21:33  <ryanofsky> luke-jr, that is a pre-existing bug in 0.19
449 2020-04-16T19:21:54  <luke-jr> sipa: currently, it is possible only be using an avoid-reuse wallet
450 2020-04-16T19:21:55  <ryanofsky> it already sets destdata on change and then starts treating it as nonchange
451 2020-04-16T19:21:58  <luke-jr> only by*
452 2020-04-16T19:22:07  <achow101> luke-jr: IMO it isn't worth trying to fix this display bug with users who upgrade then downgrade
453 2020-04-16T19:22:22  <MarcoFalke> I'd say that anything that is not a regression can wait for 0.20.1 or 0.21.0
454 2020-04-16T19:22:24  <luke-jr> achow101: it will come back when downgrading 0.21 to 0.20
455 2020-04-16T19:22:27  <ryanofsky> it'd be easy to backport a trivial fix for that issue in the 0.19 branch, but this PR only makes the bug and introduces other bugs
456 2020-04-16T19:22:27  <achow101> because it's already an issue for those users using the old software, this isn't a regression
457 2020-04-16T19:22:32  *** andrewtoth_ has joined #bitcoin-core-dev
458 2020-04-16T19:22:34  <luke-jr> unless we specifically exclude "used" from the fix in 0.21
459 2020-04-16T19:22:38  <ryanofsky> *masks the bug
460 2020-04-16T19:22:49  <sipa> what is the impact? is it just the change address showing up in the address book, or more?
461 2020-04-16T19:23:06  <luke-jr> sipa: just that, I think
462 2020-04-16T19:23:18  <luke-jr> (which can be serious IMO)\
463 2020-04-16T19:23:23  <achow101> sipa: it may have an effect on coin selection
464 2020-04-16T19:23:30  *** ossifrage has quit IRC
465 2020-04-16T19:23:33  <achow101> in particular trusted change vs untrusted non-change
466 2020-04-16T19:23:38  <luke-jr> achow101: well, if it's spent…
467 2020-04-16T19:24:01  <sipa> my understanding is that it does not affect IsChange, unless a user also goes to set an explicit label on one of those (now shown) change addresses?
468 2020-04-16T19:24:09  <wumpus> who uses the address book for receiving addresses anyhow
469 2020-04-16T19:24:10  <luke-jr> sipa: it does
470 2020-04-16T19:24:20  <luke-jr> sipa: when the change is used, it gets a "" label
471 2020-04-16T19:24:27  <sipa> i see
472 2020-04-16T19:24:29  <luke-jr> wumpus: uh, everyone?
473 2020-04-16T19:25:00  <sipa> i certainly don't, but i don't think that's an important question; if we have an address book, it should work
474 2020-04-16T19:25:02  <wumpus> luke-jr: I must admit I haven't used the address book *at all* for years, but last time I did it was to check an address I sent to
475 2020-04-16T19:25:09  <luke-jr> sipa: this gets worse if we add any new features using destdata - for example, marking which destination are actually used to provide warnings on reuse
476 2020-04-16T19:25:10  <ryanofsky> this is right but it's a preexisting bug, 0.19 already marks addresses used and has the same bug
477 2020-04-16T19:25:17  <achow101> CAddressBook effects more than just the address book IIRC
478 2020-04-16T19:25:27  <luke-jr> wumpus: how do you even receive without using it now?
479 2020-04-16T19:25:35  <sipa> it affecting IsChange is more concerning to me
480 2020-04-16T19:25:47  <wumpus> luke-jr: create new receiving address in the receive tab, give it out
481 2020-04-16T19:25:54  <luke-jr> wumpus: that uses the address book..
482 2020-04-16T19:26:09  <wumpus> no, it doesn't, the 'payment request' table is separate
483 2020-04-16T19:26:18  <sipa> ok, this is a semantics discussion; this is not productive
484 2020-04-16T19:26:28  <MarcoFalke> we should just remove the wallet and gui. Doesn't that solve the problem?
485 2020-04-16T19:26:34  <luke-jr> -.-
486 2020-04-16T19:26:54  <luke-jr> ryanofsky was proposing removing destdata entirely, but that breaks compatibility in new ways, and loses a big feature IMO
487 2020-04-16T19:26:57  *** jarthur_ has joined #bitcoin-core-dev
488 2020-04-16T19:27:08  <ryanofsky> no, that is not my proposal
489 2020-04-16T19:27:21  <ryanofsky> my proposal is a refactoring that does not change behavior in any way
490 2020-04-16T19:27:33  *** Landryl has joined #bitcoin-core-dev
491 2020-04-16T19:27:36  <ryanofsky> and is meant to prevent bugs like this in the future, but it's basically orthogonal to what we are talking about
492 2020-04-16T19:27:39  <achow101> I think the question is whether we will try to fix this in the future in a way that allows downgrading to 0.19
493 2020-04-16T19:27:51  <ryanofsky> i described the bug https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
494 2020-04-16T19:27:51  <luke-jr> achow101: to 0.20*
495 2020-04-16T19:27:54  <sipa> so am i correct that this triggers only if a user on 0.19 has avoid-reuse on, and then uses 0.19 or 0.20?
496 2020-04-16T19:27:57  <ryanofsky> and have 3 solutions for dealing with it
497 2020-04-16T19:27:58  <wumpus> destdata was mainly introduced to store payment request data and such, if it's no longer needed it should be removed
498 2020-04-16T19:27:59  <wumpus> but not for 0.20
499 2020-04-16T19:28:07  <ryanofsky> my PR is separate and compatible with all 3 approaches
500 2020-04-16T19:28:21  <sipa> or also when they use 0.20 and then downgrades in certain cases?
501 2020-04-16T19:28:27  <luke-jr> sipa: it's unfixable for already-released 0.19; my hope is to fix it so downgrading to 0.20 works
502 2020-04-16T19:28:40  <luke-jr> wumpus: it's still needed
503 2020-04-16T19:28:59  <luke-jr> destdata is nice because you don't need to upgrade wallets to get features using new metadata
504 2020-04-16T19:29:07  <achow101> to be clear, is the issue *only* with downgrading?
505 2020-04-16T19:29:22  <luke-jr> achow101: yes, which is something we've always tried to support for wallets
506 2020-04-16T19:29:23  <tryphe> address book should be removed outright imo, metadeta that can be modified in a locked wallet is kind of silly
507 2020-04-16T19:29:30  <achow101> If we didn't care about dowgrading at all, this would not be an issue?
508 2020-04-16T19:29:34  <ryanofsky> the issue is not only with downgrading, but the fix only deals with downgrading, and is only partial
509 2020-04-16T19:29:46  *** jarthur has quit IRC
510 2020-04-16T19:29:58  <ryanofsky> and it introduces other bug of avoding-reuse feature in 0.19 being broken
511 2020-04-16T19:30:12  *** bitcoin-git has joined #bitcoin-core-dev
512 2020-04-16T19:30:13  <bitcoin-git> [bitcoin] jnewbery opened pull request #18675: tests: Don't initialize PrecomputedTransactionData in txvalidationcache tests (master...2020-04-precomputedtransactiondata-txvalidationcache) https://github.com/bitcoin/bitcoin/pull/18675
513 2020-04-16T19:30:13  *** bitcoin-git has left #bitcoin-core-dev
514 2020-04-16T19:30:27  <achow101> ryanofsky: what's your pr?
515 2020-04-16T19:30:39  <sipa> can someone give me an exact user scenario that results in a user observing something incorrect, where they start with 0.20.0rc1 as we have now (and then do thing, or downgrade, or ...)
516 2020-04-16T19:31:23  <ryanofsky> again my pr is orthogonal, refactoring only #18608, comptaible with any dataformat we chose now or in the future
517 2020-04-16T19:31:23  <wumpus> tryphe: I think that's unrelated; wallet encryption in bitcoin core only protects private keys, nothing more. Labels and such are not part of that either and should definitely be kept.
518 2020-04-16T19:31:24  <gribble> https://github.com/bitcoin/bitcoin/issues/18608 | refactor: Remove CAddressBookData::destdata by ryanofsky · Pull Request #18608 · bitcoin/bitcoin · GitHub
519 2020-04-16T19:31:25  *** jarthur_ has quit IRC
520 2020-04-16T19:32:07  <luke-jr> sipa: create avoid-reuse wallet; send a transaction that has change; spend that change; suddenly that change is no longer change
521 2020-04-16T19:32:08  <ryanofsky> the scenario is just a change address gets used, and 0.19 software treats all addresses marked as used as nonchange
522 2020-04-16T19:32:21  <ryanofsky> this is a pre-existing scenario that has been around since 0.19
523 2020-04-16T19:32:29  <ryanofsky> and the only way to fix it reliably is with backports
524 2020-04-16T19:32:30  <luke-jr> sipa: the last step is only in 0.19
525 2020-04-16T19:32:34  <luke-jr> (the result)
526 2020-04-16T19:32:53  <luke-jr> sipa: but if we fix this in 0.21, 0.20 would no longer see the "used" flag unless we special-case it
527 2020-04-16T19:33:06  <sipa> luke-jr: that very much depends on how it is fixed
528 2020-04-16T19:33:14  <ryanofsky> luke's pr is a partial fix for the the issue because it stops marking addresses as used in a way 0.19 understands, and marks them used in a different way it is blind to
529 2020-04-16T19:33:17  <sipa> my concern right now is behavior that is observable with 0.20
530 2020-04-16T19:33:28  <ryanofsky> there are 0 bugs observable with 0.20
531 2020-04-16T19:33:29  <luke-jr> I don't see a way to fix it later, without special-casing 0.20 support
532 2020-04-16T19:34:03  <wumpus> tbh if it's only a minor backwards compatibility issue that is only apparent in downgrading, I wouldn't want to do things substantially different because of it
533 2020-04-16T19:34:05  <tryphe> wumpus, mostly agree, although allowing modification of metadata of someone's wallet while in cold storage that they might assume stays constant opens up a lot of doors for bad actors
534 2020-04-16T19:34:06  *** captjakk has joined #bitcoin-core-dev
535 2020-04-16T19:34:09  <achow101> How about we revert the "fix" in 0.20 and try again for 0.21? It seems like ~no one has complained about this bug in 0.19
536 2020-04-16T19:34:26  <ryanofsky> the fix in 0.20 is correct and causes no backwards compatiability issues
537 2020-04-16T19:34:29  <meshcollider> I don't think that's a good idea, the fix is still an improvement
538 2020-04-16T19:34:29  <sipa> luke-jr: if after that scenario (create avoid-reuse in 0.20; create change in 0.20; spend change in 0.20; downgrade to 0.19; do things), the user upgrades again to 0.20, is the issue resolved, or might it persist?
539 2020-04-16T19:34:39  <luke-jr> achow101: leaving it as-is now is strictly less bad than reverting I think
540 2020-04-16T19:34:43  <sipa> tryphe: please stay on topic
541 2020-04-16T19:34:44  <wumpus> tryphe: if that's your concern, encrypt the entire wallet file or store it on an encrypted file system, it's not something bitcoin core's wallet encyrption solves
542 2020-04-16T19:34:46  <ryanofsky> the fix causes no issues whatsoever
543 2020-04-16T19:34:57  *** jarthur has joined #bitcoin-core-dev
544 2020-04-16T19:35:07  <ryanofsky> i mean the fix that's already been merged causes no issues, the new fix proposed is a different story
545 2020-04-16T19:35:14  <luke-jr> sipa: the issue remains resolved in 0.20, provided the user doesn't see it in 0.19 and set a label or something
546 2020-04-16T19:35:29  <sipa> luke-jr: thank you
547 2020-04-16T19:35:57  <luke-jr> (in fact, I think 0.19 making the broken state itself, would also appear correct in 0.20)
548 2020-04-16T19:36:07  <wumpus> okay
549 2020-04-16T19:36:08  <sipa> that's good to hear as well
550 2020-04-16T19:36:16  <wumpus> yes, that's good to hear
551 2020-04-16T19:36:54  <sipa> i think we should document the issue in the release notes, with the point that if the issue appears, upgrading (again) to 0.20 will fix things unless a user manually set a label on an errorneously-shown address in 0.19
552 2020-04-16T19:37:03  <luke-jr> my biggest "end result" concern, is that I don't think users should need to -upgradewallet to get address reuse warnings when we finally merge that ; but that's a few steps into the future
553 2020-04-16T19:37:29  <sipa> for 0.21, we can discuss solutions - whether those involved -upgradewallet or special-casing the 0.20 behavior
554 2020-04-16T19:37:30  <achow101> luke-jr: with what is currently merged, why is changing the fix necessary?
555 2020-04-16T19:37:55  <achow101> as in why is your proposed 0.21 fix necessary
556 2020-04-16T19:38:04  <luke-jr> achow101: it's one thing to break compatibility with <0.19 only for avoid-reuse wallets>, another entirely to break compatibiltiy with <normal wallets going back forever>
557 2020-04-16T19:38:25  <luke-jr> achow101: since "used" destdata is only in avoid-reuse, we have the former situation right now
558 2020-04-16T19:38:35  <luke-jr> but as soon as we add destdata for change on normal wallets, we get the latter
559 2020-04-16T19:38:43  *** captjakk has quit IRC
560 2020-04-16T19:39:02  <achow101> are we adding destdata for change on normal wallets?
561 2020-04-16T19:39:12  <luke-jr> achow101: that's my plan for address reuse warnings
562 2020-04-16T19:39:23  <ryanofsky> achow101, yes, we've been doing that since kallewoof implemented avoidreuse
563 2020-04-16T19:39:32  <wumpus> just a reminder that we have to reserve some time for MarcoFalke's topic as well
564 2020-04-16T19:39:39  <jonatack> i agree with sipa's proposals (and with meshcollider and ryanofsky that it's better to keep fix in luke-jr's merged pr)
565 2020-04-16T19:39:41  <luke-jr> that's how it can avoid needing a -walletupgrade
566 2020-04-16T19:39:53  <achow101> ryanofsky: that's only for avoid reuse
567 2020-04-16T19:40:00  <achow101> luke-jr: i see, so what if we don't do that?
568 2020-04-16T19:40:06  <achow101> and just don't change it
569 2020-04-16T19:40:18  <luke-jr> achow101: I don't understand what you mean
570 2020-04-16T19:40:32  <luke-jr> if we don't add address reuse warnigns, we don't have address reuse warnings..
571 2020-04-16T19:40:46  <achow101> why do we have to add destdata on change for normal wallets
572 2020-04-16T19:40:55  <luke-jr> to mark the change address as used
573 2020-04-16T19:41:01  <achow101> if the wallet doesn't signal avoidreuse, then there's no need?
574 2020-04-16T19:41:11  *** vasild_ has joined #bitcoin-core-dev
575 2020-04-16T19:41:16  <luke-jr> address reuse warnings are for all wallets
576 2020-04-16T19:41:36  <sipa> yeah, address reuse warnings != avoidreuse behavior
577 2020-04-16T19:41:46  <achow101> ok i see
578 2020-04-16T19:41:48  <sipa> but can't that be done with a different db record instead?
579 2020-04-16T19:41:50  <achow101> there's the context I'm missing :)
580 2020-04-16T19:41:58  <luke-jr> sipa: that's a wallet format change, and needs -upgradewallet
581 2020-04-16T19:41:59  <ryanofsky> sipa, yes
582 2020-04-16T19:42:11  <sipa> luke-jr: why? old wallets would just ignore the record
583 2020-04-16T19:42:24  <ryanofsky> from https://github.com/bitcoin/bitcoin/pull/18550#issuecomment-612672886
584 2020-04-16T19:42:31  <ryanofsky> option 1 is keep using "destdata" record
585 2020-04-16T19:42:40  <ryanofsky> option 2 is switch to "changedata" record
586 2020-04-16T19:42:45  <sipa> also, can't the usage data be computed at runtime from other wallet data?
587 2020-04-16T19:42:45  <ryanofsky> option 3 is "useddata" record
588 2020-04-16T19:43:00  <luke-jr> sipa: historical best practice?
589 2020-04-16T19:43:07  <sipa> ?
590 2020-04-16T19:43:16  <luke-jr> sipa: maybe in this case (I haven't looked into that option yet, but I plan to), but this will probably come up again either way
591 2020-04-16T19:43:23  <meshcollider> Using a different record would be fine, only a minor code complication
592 2020-04-16T19:43:33  <luke-jr> sipa: we've always tried to not change wallet format outside of an explicit -upgradewallet
593 2020-04-16T19:43:34  <meshcollider> I dont think it would come up again luke-jr
594 2020-04-16T19:43:49  <luke-jr> meshcollider: tax metadata for example
595 2020-04-16T19:43:53  <sipa> luke-jr: it sounds to me like no wallet format change is needed *at all* for this functionality
596 2020-04-16T19:44:01  <meshcollider> Again use a different record, not destdata
597 2020-04-16T19:44:12  <luke-jr> meshcollider: what different record?
598 2020-04-16T19:44:43  <sipa> i think this is taking us too far
599 2020-04-16T19:44:43  *** vasild has quit IRC
600 2020-04-16T19:44:44  *** vasild_ is now known as vasild
601 2020-04-16T19:44:51  <luke-jr> meshcollider: adding a new one is a wallet format change..
602 2020-04-16T19:45:06  <sipa> so be it?
603 2020-04-16T19:45:09  <achow101> luke-jr: we've added/changed records before without needing upgradewallet
604 2020-04-16T19:45:16  <wumpus> please wrap up this topic
605 2020-04-16T19:45:19  <meshcollider> In a backwards compatible way if it's new
606 2020-04-16T19:45:26  <sipa> if it's a record old wallets can just ignore, no need for upgradewallet
607 2020-04-16T19:45:28  <luke-jr> achow101: we have?
608 2020-04-16T19:45:29  <sipa> otherwise, use it
609 2020-04-16T19:45:34  <luke-jr> ok then
610 2020-04-16T19:45:42  <meshcollider> Yes the topic is done, the PRs are closed as noone else concept ACKs the change
611 2020-04-16T19:45:48  <achow101> luke-jr: see UpgradeKeyMetadata
612 2020-04-16T19:45:53  <wumpus> #topic experimental libmultiprocess, next steps for multiprocess in general (MarcoFalke)
613 2020-04-16T19:45:55  <MarcoFalke> Background is that libmultiprocess has been added to ./depends , and libmultiprocess compile and link flags have been added to our makefile. Everything was opt-in but after merge discussion concluded that it was too early to do this step, so the change has been reverted. I (and ryanofsky) would like to hear and discuss everyone's concerns about libmultiprocess as part of the meeting for brainstorming.
614 2020-04-16T19:46:09  <MarcoFalke> cc cfields
615 2020-04-16T19:46:16  <cfields> ^^
616 2020-04-16T19:46:22  <MarcoFalke> cc fanquake (probably sleeping)
617 2020-04-16T19:46:34  <sipa> my impression is that we should only merge changes for this if the plan is that eventually this will end up in release binaries
618 2020-04-16T19:46:52  <sipa> it's not clear to me if that's the case
619 2020-04-16T19:46:57  <cfields> fanquake listed a bunch of really good questions, and ryanofsky has given good answers to on #18588.
620 2020-04-16T19:46:58  <gribble> https://github.com/bitcoin/bitcoin/issues/18588 | Revert "Merge #16367: Multiprocess build support" by MarcoFalke · Pull Request #18588 · bitcoin/bitcoin · GitHub
621 2020-04-16T19:46:59  <MarcoFalke> sipa: Eventually that was the goal (at least as I understood it)
622 2020-04-16T19:47:12  <ryanofsky> that is the goal as far as i know
623 2020-04-16T19:47:14  <MarcoFalke> sipa: Though, there was no timeline for it
624 2020-04-16T19:47:22  <cfields> sipa: yes, that was exactly my concern as well. The path forward isn't clear enough to be merging it in in-parts, imo.
625 2020-04-16T19:47:23  <wumpus> sipa: yes, I think that's obvious
626 2020-04-16T19:48:05  <sipa> i haven't paid that much attention to the multiprocess project as i don't really care about it (and kind of dread pulling in extra dependencies like capnproto), but i assumed that it was something lots of people wanted - which is fine
627 2020-04-16T19:48:15  <wumpus> though it's probably ok to have it experimental for a while before it ends up in release binaries
628 2020-04-16T19:48:33  <ryanofsky> maybe relevant: it builds new binaries
629 2020-04-16T19:48:34  <sipa> wumpus: sure
630 2020-04-16T19:49:06  <wumpus> I'm not really sure I like importing capnproto either, just now we got rid of google serialization thing
631 2020-04-16T19:49:14  <ryanofsky> so a theoretical release could include existing binaries, alongside new multiprocess binaries that let you start and stop node/gui/wallet separately and connect each other
632 2020-04-16T19:49:35  <wumpus> then again it's probably better than hand-rolling everything
633 2020-04-16T19:49:50  <MarcoFalke> The multiprocess and capnproto will stay opt-in unless it is decided to change it that
634 2020-04-16T19:50:06  <luke-jr> ryanofsky: can the same binary do single-process and multiprocess?
635 2020-04-16T19:50:23  <MarcoFalke> luke-jr: No, they are two binaries
636 2020-04-16T19:50:30  <luke-jr> I mean hypothetically
637 2020-04-16T19:50:42  <wumpus> ryanofsky: I'm not sure I like that solution, couldn't we emulate the old way using the new binaries without shipping everything twice?
638 2020-04-16T19:50:47  <ryanofsky> yes, I just didn't add the option
639 2020-04-16T19:50:56  <ryanofsky> there is lots of flexibility here
640 2020-04-16T19:51:09  <wumpus> with the static builds we do that's expensive
641 2020-04-16T19:51:15  <ryanofsky> I just built separate binaries because i meant I had to run ./configure less often
642 2020-04-16T19:51:38  <ryanofsky> If we want unified binaries with a runtime options, that's easy too
643 2020-04-16T19:51:52  <wumpus> ah yes like busybox
644 2020-04-16T19:52:02  <luke-jr> eg, bitcoin-qt gets what we have now; bitcoin-qt -process=foo gets just the foo part in MP mode
645 2020-04-16T19:52:34  <wumpus> that kinda makes sense
646 2020-04-16T19:53:29  <ryanofsky> these are really just packaging questions, my question is how to make progress on getting code reviewed
647 2020-04-16T19:53:53  <wumpus> well, 'just packaging questions' are kind of important to do this, I think
648 2020-04-16T19:53:55  <luke-jr> review club? :P
649 2020-04-16T19:54:12  <wumpus> if you split up things people are going to ask how to re-bundle them :)
650 2020-04-16T19:54:28  <ryanofsky> i mean, packaging questions are the things you would be deciding on last, and maybe changing with trial and error
651 2020-04-16T19:55:00  <cfields> ryanofsky: some of those packaging questions come down to language choices though, those things need to be decided on much earlier.
652 2020-04-16T19:55:02  <ryanofsky> 99% of the code stays the same regardless
653 2020-04-16T19:55:11  <wumpus> in any case if you want concept ACK on multiprocess, concept ACK, I think it's a good thing in the longer run
654 2020-04-16T19:55:20  *** jarthur_ has joined #bitcoin-core-dev
655 2020-04-16T19:55:27  <ryanofsky> cfields ?
656 2020-04-16T19:55:50  <wumpus> security-wise process isloation is a good start as well
657 2020-04-16T19:56:21  <cfields> ryanofsky: I'm curious to know, for example, what the downside of using the c++11 version libmultiprocess you've mentioned?
658 2020-04-16T19:56:26  <jonasschnelli> looking forward to wireguard-tunnel the GUI to a remote node.
659 2020-04-16T19:56:29  <cfields> does that mean dragging boost back in?
660 2020-04-16T19:57:01  <wumpus> so maybe the packaging details is the only thing we can disagree on :)
661 2020-04-16T19:57:01  <jonasschnelli> (but I guess that needs much more)
662 2020-04-16T19:57:01  <ryanofsky> cfields, no downside, i can revert the vasild pr and replace std::optional with boost::optional again
663 2020-04-16T19:57:33  <wumpus> wait, why?
664 2020-04-16T19:57:58  <MarcoFalke> In about 6 months we'll have C++17
665 2020-04-16T19:57:59  <ryanofsky> jonasschnelli, not too much, you can kind of do it with my existing branch if you use socat (existing branch only create UNIX socket)
666 2020-04-16T19:57:59  <cfields> wumpus: I'm just trying to understand our options.
667 2020-04-16T19:58:02  <wumpus> how can we be using std::optional in the first place we haven''t switched to C++17 yet right?
668 2020-04-16T19:58:18  *** jarthur has quit IRC
669 2020-04-16T19:58:20  <sipa> wumpus: libmultiprocess is using std::optional, but we're not using libmultiprocess yet
670 2020-04-16T19:58:33  <ryanofsky> wumpus, we are not, libmultiprocess used it internally because vasild submitted a pr to get rid of boost, and i thought it was nice
671 2020-04-16T19:58:51  <wumpus> I think the idea was to have 0.21 still c++11 compatible then go full c++17 for 0.22
672 2020-04-16T19:58:52  <MarcoFalke> wumpus: libmultiprocess is compiled with c++14 flags in depends
673 2020-04-16T19:58:55  <sipa> if it's just std::optional or boost::optional... that sounds like something we can just decide whenever it's merged
674 2020-04-16T19:58:58  <wumpus> c++14??!
675 2020-04-16T19:59:04  <wumpus> nooo
676 2020-04-16T19:59:23  <MarcoFalke> s/is/was/
677 2020-04-16T19:59:26  <luke-jr> do we need to fork upstream to get C++11 support?
678 2020-04-16T19:59:27  <sipa> if multiprocess integration only lands with 0.22, we'd be fine
679 2020-04-16T19:59:38  <ryanofsky> it works fine now...
680 2020-04-16T19:59:42  <sipa> otherwise, it seems it can easily be turned into c++11 compatible
681 2020-04-16T19:59:43  <MarcoFalke> sipa: Yes, that was my thinking
682 2020-04-16T19:59:46  <wumpus> I doubt that has to depend on using boost::optional or std::optional they're kind of the same right?
683 2020-04-16T19:59:51  <luke-jr> ryanofsky: with a non-C++14 compiler?
684 2020-04-16T19:59:54  <wumpus> could use a wrapper or something like we do for fs.h
685 2020-04-16T19:59:57  *** brakmic has joined #bitcoin-core-dev
686 2020-04-16T20:00:07  <wumpus> but we intentionally skipped over C++14, we're not going to do that now
687 2020-04-16T20:00:14  <achow101> don't we have an Optional wrapper already?
688 2020-04-16T20:00:18  <luke-jr> yes
689 2020-04-16T20:00:23  <wumpus> achow101: lol yes we do
690 2020-04-16T20:00:30  <ryanofsky> i'm not sure what's not supposed to work here
691 2020-04-16T20:01:19  <wumpus> in any case I agree these are all small details?
692 2020-04-16T20:01:22  <MarcoFalke> I think boost::optional vs std::optional should be the least of our concerns in regard to multiprocess. This is just a sylistic issue
693 2020-04-16T20:01:28  <MarcoFalke> wumpus: jup
694 2020-04-16T20:01:30  <jonatack> ryanofsky: why not add the PR to blockers?
695 2020-04-16T20:01:32  <wumpus> let's go forward with multiprocess imo
696 2020-04-16T20:01:50  <wumpus> my biggest gripe is really the serialization lib dependency not boost
697 2020-04-16T20:01:53  *** jarthur has joined #bitcoin-core-dev
698 2020-04-16T20:02:13  <wumpus> everyone wants to get rid of boost but also not get rid of boost it's not going to happen any time soon
699 2020-04-16T20:02:16  <ryanofsky> jonatack, #16367 has been in high priority list, and was even merged (then got reverted)
700 2020-04-16T20:02:18  <gribble> https://github.com/bitcoin/bitcoin/issues/16367 | Multiprocess build support by ryanofsky · Pull Request #16367 · bitcoin/bitcoin · GitHub
701 2020-04-16T20:02:49  <MarcoFalke> So I think people don't want a half-merged multiprocess? In which case we should focus on the main pr
702 2020-04-16T20:03:04  <wumpus> we should wrap up the meeting btw
703 2020-04-16T20:03:11  <wumpus> sorry for only leaving so little time for this
704 2020-04-16T20:03:12  <cfields> MarcoFalke: I didn't want a half-decided multiprocess. If we've decided to move forward on defaulting it, I have no issue with the merge.
705 2020-04-16T20:03:23  <luke-jr> it would be nice if there was a standard interface involved here, but lacking that, why not just use serialization.h?
706 2020-04-16T20:03:24  <ryanofsky> wumpus, it's a valid concern. as much as possible I tried to make framework agnostic to serializtion and allow substituting in other implementations later
707 2020-04-16T20:03:41  <jb55> wumpus: I've also ran into build issues with changing capnproto versions. is there a plan to rework that branch without capnproto?
708 2020-04-16T20:03:46  <luke-jr> cfields: why do we need to default it?
709 2020-04-16T20:04:00  <cfields> luke-jr: ship the binaries by default, sorry.
710 2020-04-16T20:04:06  <luke-jr> ah
711 2020-04-16T20:04:12  <wumpus> jb55: so the thing is, I think, that our own serialization framework is not powerful enough
712 2020-04-16T20:04:17  <sipa> for the wallet<->node communication my big hope was that the protocol would be Bitcoin P2P, so that it can be substituted with whatever on either side... but it doesn't seem anyone's working on that
713 2020-04-16T20:04:28  <jonatack> ryanofsky: yes; a re-opened PR when it's ready (since you mentioned review)
714 2020-04-16T20:04:34  *** jarthur_ has quit IRC
715 2020-04-16T20:04:58  <wumpus> jb55: also using consensus serialization for other things might not be the best idea, so people have used something else
716 2020-04-16T20:05:02  <ryanofsky> sipa, we're maybe getting closer that that with ariard's prs
717 2020-04-16T20:05:08  <sipa> ryanofsky: okay
718 2020-04-16T20:05:11  <wumpus> but yes what particular library to use, no idea
719 2020-04-16T20:05:17  <ryanofsky> he's stripping down the node/wallet interface so it's something more akin to p2p
720 2020-04-16T20:05:22  *** Talkless has quit IRC
721 2020-04-16T20:05:27  <MarcoFalke> sipa: Wouldn't that be dangerous to accidentally connect to a malicious remote p2p node?
722 2020-04-16T20:05:28  <wumpus> ryanofsky: oh that's nice!
723 2020-04-16T20:05:28  <jb55> what pr is that
724 2020-04-16T20:05:48  <luke-jr> just to be clear: we're not planning on making the interfaces backward/forward compatible, right?
725 2020-04-16T20:05:49  <sipa> MarcoFalke: well you'd have SPV security - which may be even desirable
726 2020-04-16T20:06:08  <sipa> ryanofsky: (i didn't mean that as a "you shouldn't do what you're doing" - they're orthogonal ways of separating things; a P2P-protocol based one is just what i'm more interested in)
727 2020-04-16T20:06:13  <ryanofsky> jb55, i think he only has locking PRs open now that make node/wallet more asynhrnous, but he has branches to do things like store block info in wallet i believe
728 2020-04-16T20:06:41  <wumpus> but for an experimental thing it might be OK to rely on capnproto
729 2020-04-16T20:06:46  <wumpus> I don't want to stand in the way of that
730 2020-04-16T20:06:52  <ryanofsky> sipa, yes, I know that, that's the way I look at it too
731 2020-04-16T20:07:11  <wumpus> we've often enough delayed things before some 'perfect solutoin' would appear which then would never happen
732 2020-04-16T20:07:16  <sipa> agreed
733 2020-04-16T20:07:21  <jb55> so experimental with plans to replace it eventually?
734 2020-04-16T20:07:28  <wumpus> yess
735 2020-04-16T20:07:34  <jb55> I'm ok with that
736 2020-04-16T20:07:45  <sipa> ryanofsky: what specifically does capnproto offer that's hard to do in our own serialization.h?
737 2020-04-16T20:07:48  <cfields> sgtm
738 2020-04-16T20:07:56  <sipa> or is it just avoiding lots of boilerplate code
739 2020-04-16T20:08:05  <sipa> (which may be a valid reason too)
740 2020-04-16T20:08:11  <wumpus> boilerplate I think
741 2020-04-16T20:08:17  *** timothy has quit IRC
742 2020-04-16T20:08:19  <wumpus> capnproto autogenerates a lot
743 2020-04-16T20:08:19  <ryanofsky> sipa, it's a whole io framework, more than just serialization
744 2020-04-16T20:08:42  <ryanofsky> it's higher level even than things like grpc and thrift, it gives you object handles and supports callbacks
745 2020-04-16T20:09:25  <wumpus> right, it's a real RPC mechanism, not just serialization
746 2020-04-16T20:09:30  <sipa> i see
747 2020-04-16T20:09:42  <wumpus> it goes further than protobuf in that regard
748 2020-04-16T20:09:45  <ryanofsky> and i've found it just very nice to work with, but I've tried to make everything around it as flexible as possible so it could be swapped with something else
749 2020-04-16T20:10:00  <luke-jr> so might be more apt to compare it to bitcoind's RPC server..
750 2020-04-16T20:10:03  <wumpus> also it doesn't need to be compatible between differnt verisons
751 2020-04-16T20:10:12  <wumpus> as it's only used for internal communication
752 2020-04-16T20:10:16  <jb55> if its in in-tree as an experimental maybe we can get more people working on it... status has been ambiguous for so long
753 2020-04-16T20:10:20  <wumpus> between components of the same release
754 2020-04-16T20:10:30  <wumpus> luke-jr: nononono it's *NOT* an official API
755 2020-04-16T20:10:40  <ryanofsky> wumpus, yes that is true, though capnproto does have same nice versioning / compatibility features as protobufs
756 2020-04-16T20:10:44  <luke-jr> wumpus: I mean technically comparable, not supported the same
757 2020-04-16T20:10:51  <wumpus> luke-jr: ok :)
758 2020-04-16T20:11:10  <wumpus> agreed in that case
759 2020-04-16T20:11:10  <luke-jr> wumpus: I too would be against a stable interface for this right now :P
760 2020-04-16T20:11:20  <luke-jr> (unless we literally made it use bitcoind RPC maybe)
761 2020-04-16T20:11:29  <wumpus> yes, maybe in the future
762 2020-04-16T20:11:34  <wumpus> ok, let's wrap up the meeting
763 2020-04-16T20:11:34  <cfields> Thanks for the discussion :)
764 2020-04-16T20:11:38  <wumpus> thank you too
765 2020-04-16T20:11:39  <ryanofsky> yes, the interfaces is just the headers in src/interfaces/, changes very often
766 2020-04-16T20:11:39  <sipa> it's certainly hard to agree on a stable interface 2 major releases before we plan to have it available :p
767 2020-04-16T20:11:49  <wumpus> sipa: lol exactly
768 2020-04-16T20:12:09  <wumpus> #endmeeting
769 2020-04-16T20:12:09  <lightningbot> Meeting ended Thu Apr 16 20:12:09 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
770 2020-04-16T20:12:09  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.html
771 2020-04-16T20:12:09  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.txt
772 2020-04-16T20:12:09  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-04-16-19.03.log.html
773 2020-04-16T20:12:29  *** jarthur_ has joined #bitcoin-core-dev
774 2020-04-16T20:12:32  *** bitcoin-git has joined #bitcoin-core-dev
775 2020-04-16T20:12:32  <bitcoin-git> [bitcoin] hebasto opened pull request #18676: build: Check libevent minimum version in configure script (master...200416-libevent) https://github.com/bitcoin/bitcoin/pull/18676
776 2020-04-16T20:12:33  *** bitcoin-git has left #bitcoin-core-dev
777 2020-04-16T20:14:14  *** owowo has quit IRC
778 2020-04-16T20:14:16  *** jarthur has quit IRC
779 2020-04-16T20:14:29  <wumpus> ^^ thanks hebasto
780 2020-04-16T20:14:42  *** bitcoin-git has joined #bitcoin-core-dev
781 2020-04-16T20:14:42  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d8dfcea5d956...447f8676b2e9
782 2020-04-16T20:14:43  <bitcoin-git> bitcoin/master 0c63187 Hennadii Stepanov: ci: Limit cache size regardless of NO_DEPENDS
783 2020-04-16T20:14:43  <bitcoin-git> bitcoin/master 447f867 MarcoFalke: Merge #18667: ci: Limit cache size regardless of NO_DEPENDS
784 2020-04-16T20:14:45  *** bitcoin-git has left #bitcoin-core-dev
785 2020-04-16T20:15:02  *** bitcoin-git has joined #bitcoin-core-dev
786 2020-04-16T20:15:02  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18667: ci: Limit cache size regardless of NO_DEPENDS (master...200416-ci-cache) https://github.com/bitcoin/bitcoin/pull/18667
787 2020-04-16T20:15:03  *** bitcoin-git has left #bitcoin-core-dev
788 2020-04-16T20:15:10  <MarcoFalke> PSA: I will probably clear all travis caches now, because of this bug in the ci scripts ^
789 2020-04-16T20:15:31  *** berndj has quit IRC
790 2020-04-16T20:16:13  *** captjakk has joined #bitcoin-core-dev
791 2020-04-16T20:19:12  <sipa> i forgot to bring it up again in the meeting, but i'd like some opinions on how to move forward with asmap... 0.20 will have (experimental?) support for it, but the user is responsible for constructing/finding/... the map file somewhere
792 2020-04-16T20:20:41  <sipa> i have #18573 that adds a binary for constructing/decoding these map files, which is an approach i like, but perhaps it's better to keep this out of bitcoin core's scope for now, unsure
793 2020-04-16T20:20:43  <gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
794 2020-04-16T20:21:31  *** berndj has joined #bitcoin-core-dev
795 2020-04-16T20:22:01  *** owowo has joined #bitcoin-core-dev
796 2020-04-16T20:23:17  <wumpus> sipa: I'm not sure, on one hand it's useful to have encoding and decoding in one place, on the other I don't really like adding more and more binaries to the distribution
797 2020-04-16T20:23:27  <wumpus> MarcoFalke: SGTM
798 2020-04-16T20:24:19  <wumpus> sipa: we've intentionally kept all kinds of developer tools in bitcoin-maintainer-tools repo instead, but if you think this is something a lot of users are going to need we could ship it with bitcoin core itself sure
799 2020-04-16T20:25:05  <wumpus> I mean, if everyone is going to generate their own asmap instead of downloading a pre-generated one
800 2020-04-16T20:25:25  <wumpus> but that's your question I guess
801 2020-04-16T20:26:00  <sipa> wumpus: or being able to verify a shipped one
802 2020-04-16T20:27:39  <sipa> but yes, things depend on how these things get used, how distribution is handled, what expectations people have around the process...
803 2020-04-16T20:28:08  <wumpus> right
804 2020-04-16T20:28:23  *** bitcoin-git has joined #bitcoin-core-dev
805 2020-04-16T20:28:23  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/447f8676b2e9...8f2497941ef1
806 2020-04-16T20:28:24  <bitcoin-git> bitcoin/master e44aeef Andrew Chow: gitian: Add missing automake package to gitian-win-signer.yml
807 2020-04-16T20:28:25  <bitcoin-git> bitcoin/master 8f24979 Wladimir J. van der Laan: Merge #18598: gitian: Add missing automake package to gitian-win-signer.ym...
808 2020-04-16T20:28:26  *** bitcoin-git has left #bitcoin-core-dev
809 2020-04-16T20:28:43  *** bitcoin-git has joined #bitcoin-core-dev
810 2020-04-16T20:28:43  <bitcoin-git> [bitcoin] laanwj merged pull request #18598: gitian: Add missing automake package to gitian-win-signer.yml (master...fix-gitian-win-signer) https://github.com/bitcoin/bitcoin/pull/18598
811 2020-04-16T20:28:44  *** bitcoin-git has left #bitcoin-core-dev
812 2020-04-16T20:33:16  <luke-jr> sipa: ideally we should keep it separate IMO - but does it need to share a lot of code?
813 2020-04-16T20:33:47  <luke-jr> I hope the multiprocess eventually leads to a separate wallet/GUI repos too ☺
814 2020-04-16T20:33:53  <sipa> luke-jr: i think the primary advantage is that it allows testing/fuzzing the encoder together with the exact code bitcoin core is using for lookups
815 2020-04-16T20:34:16  <luke-jr> sipa: no reason we can't test across repos?
816 2020-04-16T20:34:49  <sipa> it could be a separate repository that's subtreed or otherwise included in the build of course
817 2020-04-16T20:34:57  <sipa> but that's not really my question
818 2020-04-16T20:35:36  <luke-jr> nah, just pull it in for QA?
819 2020-04-16T20:36:09  <luke-jr> like Python
820 2020-04-16T20:36:17  <sipa> i'm confused
821 2020-04-16T20:36:46  *** jarthur_ is now known as jarthur
822 2020-04-16T20:37:25  <luke-jr> sipa: we only need Python to run tests, not to build
823 2020-04-16T20:37:46  <sipa> sure
824 2020-04-16T20:37:47  <luke-jr> if bitcoin-asmap is available, we can use it for tests too, but still separate from the main repo
825 2020-04-16T20:37:59  <luke-jr> no?
826 2020-04-16T20:38:09  <sipa> luke-jr: you mean if the binary is available?
827 2020-04-16T20:38:14  <luke-jr> sure
828 2020-04-16T20:38:19  <sipa> that'd be extremely slow
829 2020-04-16T20:38:23  <luke-jr> ?
830 2020-04-16T20:38:29  <sipa> if you'd need to invoke the binary for every test case
831 2020-04-16T20:38:59  <sipa> my fuzz test right now generates random inputs to the encoder function used by bitcoin-asmap directly
832 2020-04-16T20:39:06  <sipa> that's orders of magnitude faster
833 2020-04-16T20:39:17  <luke-jr> hmm
834 2020-04-16T20:39:29  <sipa> and verifies them against the interpreter code used for lookup
835 2020-04-16T20:39:42  *** bitcoin-git has joined #bitcoin-core-dev
836 2020-04-16T20:39:43  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/8f2497941ef1...969ee8549496
837 2020-04-16T20:39:43  <bitcoin-git> bitcoin/master fa2bc41 MarcoFalke: tools: Add unused argsman to bench_bitcoin
838 2020-04-16T20:39:44  <bitcoin-git> bitcoin/master fa46aeb MarcoFalke: scripted-diff: Replace gArgs with local argsman in bench
839 2020-04-16T20:39:45  <bitcoin-git> bitcoin/master fae00a7 MarcoFalke: bench: Remove unused argsman.ClearArgs
840 2020-04-16T20:39:46  *** bitcoin-git has left #bitcoin-core-dev
841 2020-04-16T20:39:53  <luke-jr> maybe encode+lookup should be a library? :x
842 2020-04-16T20:40:02  *** bitcoin-git has joined #bitcoin-core-dev
843 2020-04-16T20:40:02  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18662: test: Replace gArgs with local argsman in bench (master...2004-toolsArgsman) https://github.com/bitcoin/bitcoin/pull/18662
844 2020-04-16T20:40:02  <luke-jr> or pair of libraries sharing a repo
845 2020-04-16T20:40:03  *** bitcoin-git has left #bitcoin-core-dev
846 2020-04-16T20:40:11  <sipa> yes, that's a possibility
847 2020-04-16T20:40:27  <sipa> it's a bunch of overhead though
848 2020-04-16T20:40:43  <sipa> as in, process/maintenance overhead
849 2020-04-16T20:41:00  <sipa> if it's something that's more widely interesting, perhaps it makes sense
850 2020-04-16T20:41:10  <luke-jr> it does sound potentially useful outside Bitcoin Core too
851 2020-04-16T20:41:10  <sipa> i'm not sure to what extent it is
852 2020-04-16T20:41:15  <sipa> i agree
853 2020-04-16T20:42:04  <luke-jr> in fact, I think BitTorrent clients do something similar for banning copyright trolls?
854 2020-04-16T20:42:11  <sipa> no idea
855 2020-04-16T20:42:58  *** BlueMatt has quit IRC
856 2020-04-16T20:44:14  *** BlueMatt has joined #bitcoin-core-dev
857 2020-04-16T20:44:54  *** bitcoin-git has joined #bitcoin-core-dev
858 2020-04-16T20:44:55  <bitcoin-git> [bitcoin] ryanofsky opened pull request #18677: Multiprocess build support (master...pr/ipc-build2) https://github.com/bitcoin/bitcoin/pull/18677
859 2020-04-16T20:44:56  *** bitcoin-git has left #bitcoin-core-dev
860 2020-04-16T20:45:35  *** TheRec has quit IRC
861 2020-04-16T20:46:05  *** TheRec has joined #bitcoin-core-dev
862 2020-04-16T20:46:06  *** TheRec has joined #bitcoin-core-dev
863 2020-04-16T20:55:46  <jb55> sipa: is there a writeup about the asmap stuff somewhere? what's problems its trying to solve, how and why I need to generate those files, etc. as one of the people who maintains the bitcoin package on nixos, would I need to generate that and package it for users, etc?
864 2020-04-16T20:56:42  <sipa> jb55: we really don't know
865 2020-04-16T20:57:10  <sipa> it's a binary blob you can load into bitcoin core that affects how it selects outgoing peers and prioritizes incoming connections
866 2020-04-16T20:57:16  <sipa> that's all there is for 0.20
867 2020-04-16T20:58:00  <sipa> i have a repo with some python scripts that can generate the file (sipa/asmap), and there is a rust project that can take BGP dump files and produce input for those python scripts
868 2020-04-16T20:58:42  <sipa> right now it's just an experimental feature as we don't really know what the process for distribution/generation will look like
869 2020-04-16T20:59:24  *** emilengler has quit IRC
870 2020-04-16T20:59:28  <sipa> maybe at some point it becomes part of gitian builds, or something similar
871 2020-04-16T20:59:39  <sipa> maybe some day it's built into the binary even
872 2020-04-16T20:59:41  <jb55> it's not much work for package maintainers to pull a signed binary blob from somewhere and include it as an option, or even generate it ourselves from the tools
873 2020-04-16T21:00:02  <sipa> yes, but who would you trust to sign it
874 2020-04-16T21:00:02  *** mikeyman77 has quit IRC
875 2020-04-16T21:00:21  <jb55> if it was signed with the same key we're using for verifying bitcoin releases for instance
876 2020-04-16T21:00:48  <sipa> ideally you verify gitian signatures :)
877 2020-04-16T21:01:04  <sipa> so it's not a single party you're trusting
878 2020-04-16T21:01:47  <sipa> but if we're talking about the entire process for building these map files... it's not deterministic, as the source material is BGP dumps that come from... somewhere
879 2020-04-16T21:01:53  <sipa> and they change constantly
880 2020-04-16T21:02:14  <sipa> so it's not really something that can be gitian-verified
881 2020-04-16T21:02:18  <jb55> could those be poisoned somehow?
882 2020-04-16T21:02:24  <jb55> don't know much about bgp
883 2020-04-16T21:02:51  <sipa> well you need be your own ISP to have access to BGP dumps, and even then you only see "your view" of the internet
884 2020-04-16T21:03:05  <sipa> you can download BGP dumps from various locations of course
885 2020-04-16T21:04:09  <jb55> would a typical user want to generate these themselves? how would they verify they are legit? Is the point to prevent eclispe like attacks?
886 2020-04-16T21:04:26  <sipa> and an attacker supplying you with an asmap file definitely would make eclipse attacks easier for them
887 2020-04-16T21:04:36  <jb55> right
888 2020-04-16T21:04:41  <sipa> jb55: better partition resistance, ... too
889 2020-04-16T21:05:16  <sipa> jb55: i have more questions than answers about the correct procedure :)
890 2020-04-16T21:05:46  <jb55> could you be attacked during the process of generating the maps? just trying to understand possible attacks here wrt. generating them on the package distro side
891 2020-04-16T21:07:24  <sipa> so the process is (bgp dumps) -> mapping (currently, using gleb's rust tool); mapping -> asmap file (currently using some python scripts, or the bitcoin-asmap tool i'm adding in 18573)
892 2020-04-16T21:08:52  <sipa> brb, lunch
893 2020-04-16T21:08:59  <jb55> sipa: cool I'll take a look
894 2020-04-16T21:16:37  *** SiAnDoG_ has quit IRC
895 2020-04-16T21:17:05  *** brakmic_ has joined #bitcoin-core-dev
896 2020-04-16T21:17:10  *** SiAnDoG_ has joined #bitcoin-core-dev
897 2020-04-16T21:19:01  *** jarthur_ has joined #bitcoin-core-dev
898 2020-04-16T21:20:27  *** brakmic has quit IRC
899 2020-04-16T21:20:43  *** SiAnDoG_ has quit IRC
900 2020-04-16T21:20:59  *** SiAnDoG_ has joined #bitcoin-core-dev
901 2020-04-16T21:21:30  *** [42]1 has joined #bitcoin-core-dev
902 2020-04-16T21:23:03  *** jarthur has quit IRC
903 2020-04-16T21:23:39  *** SiAnDoG_ has quit IRC
904 2020-04-16T21:24:01  *** SiAnDoG_ has joined #bitcoin-core-dev
905 2020-04-16T21:36:12  *** brakmic_ has quit IRC
906 2020-04-16T21:36:52  *** brakmic has joined #bitcoin-core-dev
907 2020-04-16T21:39:43  <jonatack> jb55: there's an extensive review club writeup
908 2020-04-16T21:40:30  <jonatack> jb55: https://bitcoincore.reviews/16702
909 2020-04-16T21:40:37  <jb55> jonatack: thanks
910 2020-04-16T21:42:44  *** AaronvanW has quit IRC
911 2020-04-16T21:44:35  *** Emcy has quit IRC
912 2020-04-16T21:45:16  *** AaronvanW has joined #bitcoin-core-dev
913 2020-04-16T21:46:10  *** Emcy has joined #bitcoin-core-dev
914 2020-04-16T21:47:36  <jonatack> jb55: fwiw i've been running a node with -asmap pointing to the file in a git cloned sipa/asmap repo since last December, you can see the ASN mappings via either getpeerinfo ("mapped_as") or in the GUI peers window ("Mapped AS")
915 2020-04-16T21:49:34  <jb55> I assume you don't have to worry about this stuff if you run onlynet=onion?
916 2020-04-16T21:50:33  <sipa> jb55: if you're reachable on public IPv4/IPv6 you may
917 2020-04-16T21:50:49  <sipa> (onlynet only controls outgoing connections, iirc)
918 2020-04-16T21:50:57  <jb55> ah
919 2020-04-16T21:54:46  <jonatack> yes, as per doc/tor.md, incoming connections are not affected by onlynet=onion
920 2020-04-16T21:54:48  *** DeanWeen has quit IRC
921 2020-04-16T21:55:08  *** DeanWeen has joined #bitcoin-core-dev
922 2020-04-16T21:55:33  <sipa> to clarify: asmap affects two things independently: the choice of outgoing connections to make, and prioritization of incoming connections when the max connection count is reached
923 2020-04-16T21:55:45  <sipa> with onlynet=tor the first one disappears of course
924 2020-04-16T22:00:50  *** ossifrage has joined #bitcoin-core-dev
925 2020-04-16T22:01:15  *** Chris_Stewart_5 has quit IRC
926 2020-04-16T22:01:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
927 2020-04-16T22:01:39  <phantomcircuit> sipa, ip<->asn lookup is definitely something that would be useful outside of bitcoin, i've tried myself to do it in the past but without an active bgp session it's basically impossible to get the map at all
928 2020-04-16T22:02:06  <sipa> that's good to know
929 2020-04-16T22:02:08  <jonatack> sipa: that's a good point, and i didn't discuss inbounds in the writeup... may update it
930 2020-04-16T22:03:41  <sipa> jonatack: i think the outbound selection is certainly the more impactful change
931 2020-04-16T22:04:23  *** DeanWeen has quit IRC
932 2020-04-16T22:04:25  <sipa> phantomcircuit: though asmap is really about efficiently encoding the map, *once you have a mapping* - i don't think there is a clear-cut optimal solution for building those maps
933 2020-04-16T22:05:27  *** DeanWeen has joined #bitcoin-core-dev
934 2020-04-16T22:08:17  <sipa> FWIW, the map with data from asmap-rs (sourced from RIPE NCC data) a week or two ago, with my latest optimized encoder, is 1210027 bytes
935 2020-04-16T22:08:28  *** filchef has joined #bitcoin-core-dev
936 2020-04-16T22:10:42  <sipa> however, we certainly don't want to go encourage everyone to go download from RIPE independently... i doubt they're set up for that
937 2020-04-16T22:10:45  <BlueMatt> note that you probably want to preprocess the ripe ris data feed a bit - it includes a bunch of nonsense paths
938 2020-04-16T22:10:56  <sipa> maybe we should ask them to publish hashes of their dumps
939 2020-04-16T22:11:00  <wumpus> I do think this could be useful for other projects, on the other hand, making a library out of it before any other project expressed concrete interest might be scope creep
940 2020-04-16T22:11:22  <sipa> BlueMatt: i've indeed noticed some bogus stuff in there
941 2020-04-16T22:11:40  <sipa> fd58:9520:1361:6800::/126 AS136168
942 2020-04-16T22:11:47  *** Guyver2 has quit IRC
943 2020-04-16T22:11:52  <BlueMatt> heh, thats mild
944 2020-04-16T22:11:54  <BlueMatt> but, ye
945 2020-04-16T22:11:54  <BlueMatt> a
946 2020-04-16T22:13:00  <sipa> BlueMatt: if you have ideas for some useful filtering, please open an issue on https://github.com/0ii/asmap-rs or so
947 2020-04-16T22:13:19  <sipa> maybe it already does some processing, don't know
948 2020-04-16T22:13:48  <BlueMatt> hmm, probably a) < /24 /48 v6, b) gotta compare with others, probably
949 2020-04-16T22:13:57  <BlueMatt> would have to look at differences to figure out whts really broken
950 2020-04-16T22:14:52  *** jarthur_ is now known as jarthur
951 2020-04-16T22:34:19  <sipa> another reason for keeping asmap inline for now is that the format is really designed for the specific use case we have (it's only really efficient when you're allowed to remap unused ranges arbitrarily) and isn't super extensible (only AS numbers up to 2^25 i think)
952 2020-04-16T22:34:39  <sipa> if the codebase is kept in one place it's probably easier to introduce changes
953 2020-04-16T22:34:47  *** brakmic has quit IRC
954 2020-04-16T22:41:13  *** marcoagner has quit IRC
955 2020-04-16T22:42:40  *** jarthur has quit IRC
956 2020-04-16T22:58:01  <wumpus> agree, though 'as part of the bitcoin core project' is in one place, more or less, it doesn't necessarily mean one repository
957 2020-04-16T23:16:40  *** captjakk has quit IRC
958 2020-04-16T23:17:14  *** captjakk has joined #bitcoin-core-dev
959 2020-04-16T23:19:31  *** captjakk has quit IRC
960 2020-04-16T23:19:44  *** captjakk has joined #bitcoin-core-dev
961 2020-04-16T23:21:57  *** tryphe has quit IRC
962 2020-04-16T23:22:23  *** tryphe has joined #bitcoin-core-dev
963 2020-04-16T23:24:07  *** bitcoin-git has joined #bitcoin-core-dev
964 2020-04-16T23:24:07  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
965 2020-04-16T23:24:08  *** bitcoin-git has left #bitcoin-core-dev
966 2020-04-16T23:24:27  *** bitcoin-git has joined #bitcoin-core-dev
967 2020-04-16T23:24:27  <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #18612: script: Remove undocumented and unused operator+ (master...2004-scriptNoAdd) https://github.com/bitcoin/bitcoin/pull/18612
968 2020-04-16T23:24:28  *** bitcoin-git has left #bitcoin-core-dev
969 2020-04-16T23:31:22  <sipa> wumpus: yeah
970 2020-04-16T23:32:19  <fanquake> monorepo is the way
971 2020-04-16T23:40:06  *** shaunsun has joined #bitcoin-core-dev
972 2020-04-16T23:58:39  *** rjected has quit IRC
973 2020-04-16T23:58:43  *** mytwocentimes has quit IRC
974 2020-04-16T23:59:18  *** mytwocentimes has joined #bitcoin-core-dev
975 2020-04-16T23:59:32  *** rjected has joined #bitcoin-core-dev