1 2019-03-07T00:22:13  *** fanquake has joined #bitcoin-core-dev
  2 2019-03-07T00:29:50  *** bitcoin-git has joined #bitcoin-core-dev
  3 2019-03-07T00:29:50  <bitcoin-git> [bitcoin] fanquake closed pull request #15544: Comment typo "iff" (master...master) https://github.com/bitcoin/bitcoin/pull/15544
  4 2019-03-07T00:29:51  *** bitcoin-git has left #bitcoin-core-dev
  5 2019-03-07T00:53:13  <wumpus> cfields_: thanks!
  6 2019-03-07T00:55:33  <gwillen> does anybody with QT magic want to talk to me about the label used for alerts in overviewpage.ui
  7 2019-03-07T00:55:53  <gwillen> I want something similar (a label that appears when I want to put text in it, and disappears otherwise)
  8 2019-03-07T00:56:10  <gwillen> and I can't really figure out how you did it, and also when I try to edit the label in QT creator it gets ... glitchy, so I wonder if you edited the XML.
  9 2019-03-07T00:57:22  *** captjakk has quit IRC
 10 2019-03-07T00:57:57  *** captjakk has joined #bitcoin-core-dev
 11 2019-03-07T01:02:07  *** captjakk has quit IRC
 12 2019-03-07T01:06:11  *** AaronvanW has quit IRC
 13 2019-03-07T01:10:14  *** zhangzf has joined #bitcoin-core-dev
 14 2019-03-07T01:18:22  *** dgenr8 has joined #bitcoin-core-dev
 15 2019-03-07T01:25:59  *** makey40 has quit IRC
 16 2019-03-07T01:26:15  <promag_> gwillen: what's the purpose?
 17 2019-03-07T01:26:24  *** makey40 has joined #bitcoin-core-dev
 18 2019-03-07T01:28:30  <gwillen> hmm, maybe I should just use a modal instead
 19 2019-03-07T01:28:58  <gwillen> I think I am being too web-influenced
 20 2019-03-07T01:29:16  <gwillen> (this is for messages like "successfully signed" and "successfully broadcast"
 21 2019-03-07T01:30:51  <achow101> gwillen: wouldn't a dialog box work better for that?
 22 2019-03-07T01:34:58  <gwillen> like I said, perhaps I am being too web-influenced
 23 2019-03-07T01:40:39  <promag_> agree :)
 24 2019-03-07T01:41:58  <gwillen> I think the web-influenced version is _nicer_
 25 2019-03-07T01:42:06  <gwillen> but it's not really in keeping with the bitcoin-qt aesthetic
 26 2019-03-07T01:44:44  *** echeveria has quit IRC
 27 2019-03-07T01:48:02  *** echeveria has joined #bitcoin-core-dev
 28 2019-03-07T01:49:37  *** promag has quit IRC
 29 2019-03-07T01:50:51  *** promag_ has quit IRC
 30 2019-03-07T01:51:06  *** alexalex has joined #bitcoin-core-dev
 31 2019-03-07T01:52:32  *** EagleTM has quit IRC
 32 2019-03-07T02:01:39  *** alexalex has quit IRC
 33 2019-03-07T02:03:39  *** pinheadmz has quit IRC
 34 2019-03-07T02:19:32  *** millerti has quit IRC
 35 2019-03-07T02:21:34  *** promag has joined #bitcoin-core-dev
 36 2019-03-07T02:26:07  *** promag has quit IRC
 37 2019-03-07T02:28:27  *** justanotheruser has quit IRC
 38 2019-03-07T02:44:00  *** justanotheruser has joined #bitcoin-core-dev
 39 2019-03-07T02:59:33  *** pinheadmz has joined #bitcoin-core-dev
 40 2019-03-07T03:10:32  *** fcc977 has joined #bitcoin-core-dev
 41 2019-03-07T03:13:49  *** fcc977 has quit IRC
 42 2019-03-07T03:14:35  *** pinheadmz has quit IRC
 43 2019-03-07T03:21:09  *** pinheadmz has joined #bitcoin-core-dev
 44 2019-03-07T03:24:00  *** mn9495881 has joined #bitcoin-core-dev
 45 2019-03-07T03:24:09  *** rafalcpp has quit IRC
 46 2019-03-07T03:25:43  *** rafalcpp has joined #bitcoin-core-dev
 47 2019-03-07T03:39:42  *** pinheadmz has quit IRC
 48 2019-03-07T03:44:13  *** pinheadmz has joined #bitcoin-core-dev
 49 2019-03-07T04:00:35  *** pinheadmz has quit IRC
 50 2019-03-07T04:06:36  *** DeanWeen has quit IRC
 51 2019-03-07T04:07:06  *** DeanWeen has joined #bitcoin-core-dev
 52 2019-03-07T04:26:32  *** Sentineo has quit IRC
 53 2019-03-07T04:26:32  *** cryptapus has quit IRC
 54 2019-03-07T04:26:32  *** rockhouse has quit IRC
 55 2019-03-07T04:26:32  *** bashco has quit IRC
 56 2019-03-07T04:26:32  *** jimpo has quit IRC
 57 2019-03-07T04:26:32  *** nodweber2 has quit IRC
 58 2019-03-07T04:26:32  *** BGL has quit IRC
 59 2019-03-07T04:26:33  *** molz has quit IRC
 60 2019-03-07T04:26:33  *** gwillen has quit IRC
 61 2019-03-07T04:26:33  *** eenoch has quit IRC
 62 2019-03-07T04:26:33  *** sturles has quit IRC
 63 2019-03-07T04:26:33  *** da2ce7 has quit IRC
 64 2019-03-07T04:28:32  *** gwillen has joined #bitcoin-core-dev
 65 2019-03-07T04:29:08  *** BlueMatt has quit IRC
 66 2019-03-07T04:31:43  *** BlueMatt has joined #bitcoin-core-dev
 67 2019-03-07T04:32:12  *** hebasto has quit IRC
 68 2019-03-07T04:36:15  *** irc_viewer_test has joined #bitcoin-core-dev
 69 2019-03-07T04:41:06  *** pinheadmz has joined #bitcoin-core-dev
 70 2019-03-07T04:44:03  *** irc_viewer_test has quit IRC
 71 2019-03-07T04:44:29  *** DeanWeen has quit IRC
 72 2019-03-07T04:53:15  *** promag has joined #bitcoin-core-dev
 73 2019-03-07T04:53:37  *** Sentineo has joined #bitcoin-core-dev
 74 2019-03-07T04:53:37  *** cryptapus has joined #bitcoin-core-dev
 75 2019-03-07T04:53:37  *** rockhouse has joined #bitcoin-core-dev
 76 2019-03-07T04:53:37  *** bashco has joined #bitcoin-core-dev
 77 2019-03-07T04:53:37  *** jimpo has joined #bitcoin-core-dev
 78 2019-03-07T04:53:37  *** nodweber2 has joined #bitcoin-core-dev
 79 2019-03-07T04:53:37  *** BGL has joined #bitcoin-core-dev
 80 2019-03-07T04:53:37  *** molz has joined #bitcoin-core-dev
 81 2019-03-07T04:53:37  *** eenoch has joined #bitcoin-core-dev
 82 2019-03-07T04:53:37  *** sturles has joined #bitcoin-core-dev
 83 2019-03-07T04:53:37  *** da2ce7 has joined #bitcoin-core-dev
 84 2019-03-07T04:58:00  *** promag has quit IRC
 85 2019-03-07T05:08:51  *** pinheadmz has quit IRC
 86 2019-03-07T05:09:57  *** pinheadmz has joined #bitcoin-core-dev
 87 2019-03-07T05:21:02  *** rh0nj has quit IRC
 88 2019-03-07T05:22:07  *** rh0nj has joined #bitcoin-core-dev
 89 2019-03-07T05:30:23  *** cubancorona has quit IRC
 90 2019-03-07T05:30:42  *** cubancorona has joined #bitcoin-core-dev
 91 2019-03-07T05:42:29  *** DeanWeen has joined #bitcoin-core-dev
 92 2019-03-07T05:46:05  *** promag has joined #bitcoin-core-dev
 93 2019-03-07T06:15:20  *** pinheadmz has quit IRC
 94 2019-03-07T06:17:57  *** nullptr| has quit IRC
 95 2019-03-07T06:25:41  *** nullptr| has joined #bitcoin-core-dev
 96 2019-03-07T06:49:07  *** spinza has quit IRC
 97 2019-03-07T06:49:13  *** promag has quit IRC
 98 2019-03-07T07:09:04  <luke-jr>            ├─sshd(941)─┬─sshd(3366)───bash(3459)───apt-get(3464)───dpkg(6288)───linux-firmware.(9226)───update-initramf(9227)───update-initramf(17424)───m+
 99 2019-03-07T07:09:13  <luke-jr> wumpus: ^ what is slowing the gitian system update for me
100 2019-03-07T07:09:18  <gmaxwell>  /join #bitcoin
101 2019-03-07T07:23:09  *** d_t has quit IRC
102 2019-03-07T07:24:24  *** mildly_risky has joined #bitcoin-core-dev
103 2019-03-07T07:25:07  *** spinza has joined #bitcoin-core-dev
104 2019-03-07T07:27:19  *** mildly_risky has quit IRC
105 2019-03-07T07:27:44  *** mildly_risky has joined #bitcoin-core-dev
106 2019-03-07T07:32:01  *** mildly_risky has quit IRC
107 2019-03-07T07:44:13  *** fanquake has quit IRC
108 2019-03-07T08:02:28  *** bluelee has joined #bitcoin-core-dev
109 2019-03-07T08:10:58  *** bluelee has quit IRC
110 2019-03-07T08:18:47  *** jungly has joined #bitcoin-core-dev
111 2019-03-07T08:35:05  *** fanquake has joined #bitcoin-core-dev
112 2019-03-07T09:09:15  *** setpill has joined #bitcoin-core-dev
113 2019-03-07T09:17:18  *** timothy has joined #bitcoin-core-dev
114 2019-03-07T09:29:53  *** Guest20 has joined #bitcoin-core-dev
115 2019-03-07T09:31:21  *** rafalcpp has quit IRC
116 2019-03-07T09:31:48  *** rafalcpp has joined #bitcoin-core-dev
117 2019-03-07T09:33:59  *** promag has joined #bitcoin-core-dev
118 2019-03-07T09:46:21  *** jonatack has quit IRC
119 2019-03-07T09:51:33  *** Guest20 has quit IRC
120 2019-03-07T09:54:48  *** CoffeeElixir has joined #bitcoin-core-dev
121 2019-03-07T10:02:09  *** kexkey has quit IRC
122 2019-03-07T10:10:25  <fanquake> Looks like we've got 6 sets of signed sigs for macOS and Windows rc1 builds.
123 2019-03-07T10:10:57  <fanquake> No "new" builders yet
124 2019-03-07T10:11:26  *** rex4539 has joined #bitcoin-core-dev
125 2019-03-07T10:20:25  *** spinza has quit IRC
126 2019-03-07T10:27:00  *** EagleTM has joined #bitcoin-core-dev
127 2019-03-07T10:30:05  *** bitcoin-git has joined #bitcoin-core-dev
128 2019-03-07T10:30:06  <bitcoin-git> [bitcoin] cisba opened pull request #15554: docs: binary tar improvement (master...improve-tar) https://github.com/bitcoin/bitcoin/pull/15554
129 2019-03-07T10:30:09  *** bitcoin-git has left #bitcoin-core-dev
130 2019-03-07T10:37:32  *** spinza has joined #bitcoin-core-dev
131 2019-03-07T10:45:19  *** IGHOR has quit IRC
132 2019-03-07T10:46:53  *** IGHOR has joined #bitcoin-core-dev
133 2019-03-07T10:50:56  *** setpill has quit IRC
134 2019-03-07T10:52:05  *** zhangzf has quit IRC
135 2019-03-07T10:52:20  *** zhangzf has joined #bitcoin-core-dev
136 2019-03-07T10:52:51  *** setpill has joined #bitcoin-core-dev
137 2019-03-07T10:57:35  *** jonatack_ has joined #bitcoin-core-dev
138 2019-03-07T10:59:33  *** EagleTM has quit IRC
139 2019-03-07T10:59:55  <CoffeeElixir> Hi, where can I find the changelog of 0.18.0?
140 2019-03-07T11:01:36  <wumpus> PSA 0.18.0rc1 binaries up https://bitcoincore.org/bin/bitcoin-core-0.18.0/test.rc1/
141 2019-03-07T11:02:47  <wumpus> CoffeeElixir: preliminary changelog is at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
142 2019-03-07T11:03:46  <CoffeeElixir> wumpus thank you!
143 2019-03-07T11:04:30  *** EagleTM has joined #bitcoin-core-dev
144 2019-03-07T11:23:04  <wumpus> yw
145 2019-03-07T11:25:02  *** DeanWeen has quit IRC
146 2019-03-07T11:42:10  *** DeanWeen has joined #bitcoin-core-dev
147 2019-03-07T11:50:03  *** AaronvanW has joined #bitcoin-core-dev
148 2019-03-07T11:52:09  <wumpus> whoa at least the wumpus-announce list (i mean, bitcoin-core-dev) is still working
149 2019-03-07T11:55:19  <luke-jr> wumpus: the main one seems to be as well for the moment
150 2019-03-07T11:55:59  <wumpus> oh nice!
151 2019-03-07T12:08:58  *** zhangzf has joined #bitcoin-core-dev
152 2019-03-07T12:14:08  *** CoffeeElixir has quit IRC
153 2019-03-07T12:28:05  *** jonatack_ has quit IRC
154 2019-03-07T12:40:53  *** keymone has quit IRC
155 2019-03-07T12:45:43  *** keymone has joined #bitcoin-core-dev
156 2019-03-07T12:53:23  *** b10c has joined #bitcoin-core-dev
157 2019-03-07T13:06:06  *** promag has quit IRC
158 2019-03-07T13:09:28  *** zhangzf has quit IRC
159 2019-03-07T13:12:10  *** fanquake has quit IRC
160 2019-03-07T13:34:12  *** CoffeeElixir has joined #bitcoin-core-dev
161 2019-03-07T13:44:30  *** CoffeeElixir has quit IRC
162 2019-03-07T13:50:17  *** zhangzf has joined #bitcoin-core-dev
163 2019-03-07T14:03:51  *** mmgen has joined #bitcoin-core-dev
164 2019-03-07T14:05:49  *** promag has joined #bitcoin-core-dev
165 2019-03-07T14:10:11  *** CoffeeElixir has joined #bitcoin-core-dev
166 2019-03-07T14:10:26  *** promag has quit IRC
167 2019-03-07T14:26:33  *** Deinogalerix21 has joined #bitcoin-core-dev
168 2019-03-07T14:30:47  *** promag has joined #bitcoin-core-dev
169 2019-03-07T14:33:01  *** promag_ has joined #bitcoin-core-dev
170 2019-03-07T14:33:45  *** Bullit has quit IRC
171 2019-03-07T14:34:17  *** Bullit has joined #bitcoin-core-dev
172 2019-03-07T14:35:31  *** arubi has quit IRC
173 2019-03-07T14:37:32  *** promag_ has quit IRC
174 2019-03-07T14:41:14  *** Deinogalerix21 has quit IRC
175 2019-03-07T14:41:17  *** Emcy has quit IRC
176 2019-03-07T14:41:47  *** Emcy has joined #bitcoin-core-dev
177 2019-03-07T14:42:44  *** arubi has joined #bitcoin-core-dev
178 2019-03-07T14:59:00  *** setpill has quit IRC
179 2019-03-07T15:08:24  *** wolfspraul has quit IRC
180 2019-03-07T15:08:32  *** wolfspraul has joined #bitcoin-core-dev
181 2019-03-07T15:11:43  *** hebasto has joined #bitcoin-core-dev
182 2019-03-07T15:23:36  *** d_t has joined #bitcoin-core-dev
183 2019-03-07T15:27:00  *** zhangzf has quit IRC
184 2019-03-07T15:34:10  *** pinheadmz has joined #bitcoin-core-dev
185 2019-03-07T15:41:38  *** anome has joined #bitcoin-core-dev
186 2019-03-07T15:46:43  <promag> please give your ack/nak in #15493
187 2019-03-07T15:46:44  <gribble> https://github.com/bitcoin/bitcoin/issues/15493 | rfc: Add -printconfig arg to bitcoind by promag · Pull Request #15493 · bitcoin/bitcoin · GitHub
188 2019-03-07T15:51:47  *** CoffeeElixir has quit IRC
189 2019-03-07T15:52:26  <wumpus> heh everyone is retweeting the 0.18.0 rc1 announcement, thought i was sneaky enough to only post it on the ML and mastodon... well hope that people realize it's for testing and not a final release
190 2019-03-07T15:53:47  *** b10c has quit IRC
191 2019-03-07T15:54:11  *** ap4lmtree has quit IRC
192 2019-03-07T15:54:30  *** ap4lmtree has joined #bitcoin-core-dev
193 2019-03-07T15:56:42  *** b10c has joined #bitcoin-core-dev
194 2019-03-07T15:57:41  *** b10c has quit IRC
195 2019-03-07T16:14:44  *** Guyver2 has joined #bitcoin-core-dev
196 2019-03-07T16:16:29  *** shesek has joined #bitcoin-core-dev
197 2019-03-07T16:16:29  *** shesek has joined #bitcoin-core-dev
198 2019-03-07T16:18:20  *** bitcoin-git has joined #bitcoin-core-dev
199 2019-03-07T16:18:20  <bitcoin-git> [bitcoin] laanwj closed pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
200 2019-03-07T16:18:31  *** bitcoin-git has left #bitcoin-core-dev
201 2019-03-07T16:19:16  *** captjakk has joined #bitcoin-core-dev
202 2019-03-07T16:20:55  *** bitcoin-git has joined #bitcoin-core-dev
203 2019-03-07T16:20:55  <bitcoin-git> [bitcoin] laanwj reopened pull request #15549: gitian: Improve error handling (master...2019_03_gitian_error_handling) https://github.com/bitcoin/bitcoin/pull/15549
204 2019-03-07T16:20:56  *** bitcoin-git has left #bitcoin-core-dev
205 2019-03-07T16:27:26  *** spinza has quit IRC
206 2019-03-07T16:31:22  *** kexkey has joined #bitcoin-core-dev
207 2019-03-07T16:35:08  *** jarthur has joined #bitcoin-core-dev
208 2019-03-07T16:35:45  *** bitcoin-git has joined #bitcoin-core-dev
209 2019-03-07T16:35:45  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3515612e069e...726d0668ff78
210 2019-03-07T16:35:46  <bitcoin-git> bitcoin/master faebd2e MarcoFalke: doc: Move wallet lock annotations to header
211 2019-03-07T16:35:46  <bitcoin-git> bitcoin/master 726d066 MarcoFalke: Merge #15530: doc: Move wallet lock annotations to header
212 2019-03-07T16:35:50  *** bitcoin-git has left #bitcoin-core-dev
213 2019-03-07T16:36:40  *** bitcoin-git has joined #bitcoin-core-dev
214 2019-03-07T16:36:40  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15530: doc: Move wallet lock annotations to header (master...Mf1902-walletLocks) https://github.com/bitcoin/bitcoin/pull/15530
215 2019-03-07T16:36:41  *** bitcoin-git has left #bitcoin-core-dev
216 2019-03-07T16:41:25  *** bitcoin-git has joined #bitcoin-core-dev
217 2019-03-07T16:41:26  <bitcoin-git> [bitcoin] laanwj pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/726d0668ff78...3db0cc394730
218 2019-03-07T16:41:27  <bitcoin-git> bitcoin/master 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
219 2019-03-07T16:41:28  <bitcoin-git> bitcoin/master 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
220 2019-03-07T16:41:28  *** EagleTM has quit IRC
221 2019-03-07T16:41:29  <bitcoin-git> bitcoin/master 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
222 2019-03-07T16:41:30  *** bitcoin-git has left #bitcoin-core-dev
223 2019-03-07T16:42:07  *** bitcoin-git has joined #bitcoin-core-dev
224 2019-03-07T16:42:08  <bitcoin-git> [bitcoin] laanwj merged pull request #15402: Granular invalidateblock and RewindBlockIndex (master...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15402
225 2019-03-07T16:42:10  *** bitcoin-git has left #bitcoin-core-dev
226 2019-03-07T16:42:27  *** bitcoin-git has joined #bitcoin-core-dev
227 2019-03-07T16:42:28  <bitcoin-git> [bitcoin] laanwj pushed 12 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/71ac4ebe4893...0fd3632868e2
228 2019-03-07T16:42:29  <bitcoin-git> bitcoin/0.18 9d6dcc5 Pieter Wuille: Abstract EraseBlockData out of RewindBlockIndex
229 2019-03-07T16:42:30  <bitcoin-git> bitcoin/0.18 32b2696 Pieter Wuille: Move erasure of non-active blocks to a separate loop in RewindBlockIndex
230 2019-03-07T16:42:31  <bitcoin-git> bitcoin/0.18 1d34287 Pieter Wuille: Merge the disconnection and erasing loops in RewindBlockIndex
231 2019-03-07T16:42:35  *** bitcoin-git has left #bitcoin-core-dev
232 2019-03-07T16:42:52  *** bitcoin-git has joined #bitcoin-core-dev
233 2019-03-07T16:42:53  <bitcoin-git> [bitcoin] laanwj merged pull request #15552: 0.18: Granular invalidateblock and RewindBlockIndex (0.18...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15552
234 2019-03-07T16:42:58  *** bitcoin-git has left #bitcoin-core-dev
235 2019-03-07T16:48:23  <michagogo> Quick question: was looking at the release notes and saw this: you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).
236 2019-03-07T16:48:37  <michagogo> Isn’t the normal port specification “-p 8332:8332”?
237 2019-03-07T16:49:14  <michagogo> If you’re looking to bind to localhost, what you’re adding is the address
238 2019-03-07T16:49:53  *** jonatack has joined #bitcoin-core-dev
239 2019-03-07T16:52:08  *** spinza has joined #bitcoin-core-dev
240 2019-03-07T16:58:48  *** Aaronvan_ has joined #bitcoin-core-dev
241 2019-03-07T17:01:14  *** AaronvanW has quit IRC
242 2019-03-07T17:02:35  *** anome has quit IRC
243 2019-03-07T17:03:23  *** anome has joined #bitcoin-core-dev
244 2019-03-07T17:06:14  *** ghost43 has quit IRC
245 2019-03-07T17:06:34  *** ghost43 has joined #bitcoin-core-dev
246 2019-03-07T17:12:14  *** bitcoin-git has joined #bitcoin-core-dev
247 2019-03-07T17:12:15  <bitcoin-git> [bitcoin] Empact opened pull request #15556:  build: Optionally enable -Wthread-safety-attributes (master...wthread-safety-attributes) https://github.com/bitcoin/bitcoin/pull/15556
248 2019-03-07T17:12:15  *** bitcoin-git has left #bitcoin-core-dev
249 2019-03-07T17:19:06  <DeanWeen> michagogo: where are these release notes?
250 2019-03-07T17:19:06  *** hebasto has quit IRC
251 2019-03-07T17:28:03  *** hebasto has joined #bitcoin-core-dev
252 2019-03-07T17:35:57  *** jungly has quit IRC
253 2019-03-07T17:40:06  *** Aaronvan_ is now known as AaronvanW
254 2019-03-07T17:40:57  *** dviola has joined #bitcoin-core-dev
255 2019-03-07T17:42:31  <instagibbs> can someone remind me the current Core restriction on rbf input sourcing? ie can a transaction rbf another transaction with unconfirmed inputs?
256 2019-03-07T17:44:04  <instagibbs> ah, got it I think "replacement-adds-unconfirmed" error
257 2019-03-07T17:52:45  *** anome has quit IRC
258 2019-03-07T17:59:31  *** anome has joined #bitcoin-core-dev
259 2019-03-07T18:07:42  *** jb55 has quit IRC
260 2019-03-07T18:08:00  *** Emcy has quit IRC
261 2019-03-07T18:12:28  *** bitcoin-git has joined #bitcoin-core-dev
262 2019-03-07T18:12:28  <bitcoin-git> [bitcoin] instagibbs opened pull request #15557: Enhance `bumpfee` to include inputs when targeting a feerate (master...bumpall) https://github.com/bitcoin/bitcoin/pull/15557
263 2019-03-07T18:12:31  *** bitcoin-git has left #bitcoin-core-dev
264 2019-03-07T18:16:19  <michagogo> DeanWeen: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft
265 2019-03-07T18:18:43  <instagibbs> 15557 should be of interest to some people ^
266 2019-03-07T18:19:12  <instagibbs> finally sat down and just did it, very few loc, and I could delete a bunch more if we get rid of totalFee option for bumping :P
267 2019-03-07T18:19:36  <promag> what's total fee?
268 2019-03-07T18:21:03  <gmaxwell> <3
269 2019-03-07T18:23:09  <instagibbs> promag, you say how much more, in satoshis, you want to give the tx
270 2019-03-07T18:23:15  <instagibbs> it's... questionable imo
271 2019-03-07T18:23:21  <instagibbs> but hey no need to delete :)
272 2019-03-07T18:23:44  <promag> what is the reason to create a separate function?
273 2019-03-07T18:23:54  <instagibbs> i found the previous one very hard to read tbh
274 2019-03-07T18:23:58  <instagibbs> the flow is completely different
275 2019-03-07T18:24:19  <instagibbs> it's doing manual surgery based on introspection of the old tx, rather than just trying to make a new tx
276 2019-03-07T18:25:35  <instagibbs> *very manual*
277 2019-03-07T18:27:59  <promag> maybe you should move the if (totalFee > 0) {} else {} to a function in feebumper.h?
278 2019-03-07T18:28:30  <promag> otherwise you have the same check in interfaces/wallet and rpcwallet
279 2019-03-07T18:28:39  <gmaxwell> I think the absolute fee bump amount wasn't well considered and could go away...
280 2019-03-07T18:29:00  <gmaxwell> esp as part of an improvement that made bump much more useful...
281 2019-03-07T18:29:37  <promag> gmaxwell: you suggest removing that in a different pr first?
282 2019-03-07T18:30:22  <gmaxwell> no well, I'm suggesting that if someone making bumpfee better wants to remove it, then they should be empowered to make that call.
283 2019-03-07T18:31:02  <gmaxwell> I don't think we should feel too obligated by prior decisions there-- as it stands bumpfee's usability is kinda so/so.
284 2019-03-07T18:31:09  <dongcarl> cfields_ phantomcircuit: You guys online? Let's talk about libevent for node socket handling
285 2019-03-07T18:31:46  <gmaxwell> why?
286 2019-03-07T18:31:54  <promag> dongcarl: wanna ditch libevent?
287 2019-03-07T18:32:30  <dongcarl> Mostly thinking about picking up #11227 again
288 2019-03-07T18:32:32  <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
289 2019-03-07T18:33:11  <dongcarl> promag: It seems that we rely on libevent for torcontrol and httpserver correct?
290 2019-03-07T18:33:24  <promag> dongcarl: yes
291 2019-03-07T18:35:03  <phantomcircuit> dongcarl, yes
292 2019-03-07T18:35:08  <dongcarl> Well I think we should use it for node socket handling as well, and wanted to talk about what people's thoughts are on that
293 2019-03-07T18:35:13  <instagibbs> gmaxwell, the type of power-user can can use the totalFee option can already probably do it manually using pythong
294 2019-03-07T18:35:21  <instagibbs> python* heh
295 2019-03-07T18:36:01  <phantomcircuit> so one thing to consider, we currently do one connection at a time in another thread, there should be an fConnected flag so that doesn't need special handling
296 2019-03-07T18:36:57  <dongcarl> phantomcircuit: fConnected flag on CNode?
297 2019-03-07T18:37:22  <dongcarl> Could you point me to code?
298 2019-03-07T18:40:16  <phantomcircuit> dongcarl, most of the stuff in netbase.{h,cpp}
299 2019-03-07T18:40:33  <phantomcircuit> specifically ConnectSocketDirectly
300 2019-03-07T18:40:46  <phantomcircuit> the annoying thing is is means building a SOCKS5 state machine
301 2019-03-07T18:41:21  *** Aaronvan_ has joined #bitcoin-core-dev
302 2019-03-07T18:41:44  <dongcarl> phantomcircuit: oooof that doesn't sound great
303 2019-03-07T18:41:49  * dongcarl reading
304 2019-03-07T18:42:50  <cfields_> dongcarl: sorry, screwed up time zones
305 2019-03-07T18:43:00  <dongcarl> Haha hey no worries
306 2019-03-07T18:43:05  <dongcarl> Glad you're here
307 2019-03-07T18:43:44  <cfields_> dongcarl: After wrestling with about 20 different rewrites of the net code with libevent, it's hard to recommend...
308 2019-03-07T18:43:55  <cfields_> You definitely end up fighting it more than using it.
309 2019-03-07T18:44:20  <dongcarl> cfields_: Really? What kind of fights are you talking about?
310 2019-03-07T18:44:22  *** AaronvanW has quit IRC
311 2019-03-07T18:45:20  <cfields_> contexts, mainly. It expects you to feed a single pointer in for callbacks. C style. But you almost always want a callback into a function instance, meaning that you have to make weird 2xpointer mallocs all over the place
312 2019-03-07T18:45:46  <cfields_> The threading model is also non-intuitive and error-prone
313 2019-03-07T18:46:04  <cfields_> I'm happy to point you to the rewrites, I have lots of em :)
314 2019-03-07T18:46:22  <phantomcircuit> cfields_, function instance?
315 2019-03-07T18:46:33  <cfields_> phantomcircuit: sorry, class function
316 2019-03-07T18:46:42  *** gkrizek has quit IRC
317 2019-03-07T18:46:48  <phantomcircuit> cfields_, iirc all the libevent callbacks have a user data field basically for that purpose
318 2019-03-07T18:46:51  <cfields_> All that said, I obviously wouldn't be opposed to someone else giving it a try.
319 2019-03-07T18:47:00  <cfields_> phantomcircuit: yes, a single field.
320 2019-03-07T18:47:01  <echeveria> dongcarl: #11227
321 2019-03-07T18:47:05  <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
322 2019-03-07T18:47:32  * dongcarl taking notes
323 2019-03-07T18:47:36  <cfields_> I also wrote an abstraction layer around libevent with the intention of plugging it into bitcoind
324 2019-03-07T18:47:38  <cfields_> sec
325 2019-03-07T18:47:41  <echeveria> #10285
326 2019-03-07T18:47:41  *** DeanWeen has quit IRC
327 2019-03-07T18:47:42  <gmaxwell> we've already held back improvmenets of the p2p protocol for years because of vaguely motivated aspirational rewrites.
328 2019-03-07T18:47:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
329 2019-03-07T18:48:25  <cfields_> dongcarl: https://github.com/theuni/libbtcnet
330 2019-03-07T18:49:40  <cfields_> yeah, 10285 does a good job of showing how awkward it is imo. I struggled to come up with something reviewable, without too much spaghetti. And since it wasn't merged, apparently I didn't do so great :)
331 2019-03-07T18:49:47  <dongcarl> cfields_: I haven't dove fully into it, but I know that libev is a lot simpler than libevent (~1 order of magnitude LOC) and claims to have a good interface
332 2019-03-07T18:49:56  <dongcarl> http://software.schmorp.de/pkg/libev.html
333 2019-03-07T18:50:53  <cfields_> dongcarl: Last time I looked, IIRC I decided that libev would've been a better choice. But grass is always greener. And it'd be a new dep. So I didn't go down that path.
334 2019-03-07T18:51:18  <gmaxwell> What problem is any of this supposted to be solving?
335 2019-03-07T18:52:37  <dongcarl> gmaxwell: "These changes remove our old select() loop for socket handling in favor of libevent, which uses epoll/kqueue/etc. as a back-end. In addition to being faster and more efficient, this allows us to drop some annoying restrictions, namely that select can only handle 1024 sockets in practice on most systems."
336 2019-03-07T18:52:53  <cfields_> gmaxwell: more async, and more performant due to epoll/kqueue/etc.
337 2019-03-07T18:53:34  <gmaxwell> dongcarl: we no longer have the 1024 socket restriction, because we switched to using poll.
338 2019-03-07T18:54:05  <gmaxwell> (when finally people were convinced to stop waiting for a rewrite.)
339 2019-03-07T18:56:08  <dongcarl> Do non-Linux kernels have the 1024 socket restriction? Or does poll solve it for all the ones we support? (genuinely asking)
340 2019-03-07T18:56:32  <gmaxwell> dongcarl: windows select doesn't have a 1024 restriction (at it uses a linked list instead of a bitmap)
341 2019-03-07T18:56:32  <cfields_> 1024 is an issue with select()
342 2019-03-07T18:56:41  <wumpus> 1024 restriction is specific to UNIX implementations of select()
343 2019-03-07T18:56:44  <wumpus> not only Linux
344 2019-03-07T18:56:53  <cfields_> and not always 1024 :)
345 2019-03-07T18:57:12  <gmaxwell> cfields_: more performant in what measuresable respect?  At most we handle just hundreds of waiting sockets and benchmarks I've seen show essentially equivilent (fast) performance beween all alternatives at this level: https://monkey.org/~provos/libevent/libevent-benchmark2.jpg
346 2019-03-07T18:57:16  * rafalcpp screams in Finnish
347 2019-03-07T18:57:18  <wumpus> poll() doesn't have any such restriction on any (AFAIK) OS
348 2019-03-07T18:57:30  <dongcarl> We enable poll for BSD?
349 2019-03-07T18:57:35  <cfields_> gmaxwell: we've had this discussion endless times.
350 2019-03-07T18:57:37  <wumpus> yes, only not on windows
351 2019-03-07T18:57:55  <gmaxwell> cfields_: yes, and it screwed the protocol development for years.
352 2019-03-07T18:58:07  <cfields_> gmaxwell: guess you were right, then.
353 2019-03-07T18:59:34  <phantomcircuit> so my interest is in doing very small changes
354 2019-03-07T18:59:51  <phantomcircuit> i think the issue we've had in the past was having a grand plan
355 2019-03-07T18:59:51  <gmaxwell> The cost right now to going back on this would likely be to delay development of p2p encryption/authentication for another year plus. If thats the case I think it would be an awful tradeoff.
356 2019-03-07T18:59:57  <phantomcircuit> instead of doing smaller fixes
357 2019-03-07T19:00:13  <sipa> gmaxwell: i think we indeed had an instance a while ago where some
358 2019-03-07T19:00:21  <phantomcircuit> i brought up the connect stuff cause that did actually slow me down on changing  poll()
359 2019-03-07T19:00:25  <sipa> gmaxwell: i think we indeed had an instance a while ago where some things were delayed because of an upcoming refactor which didn't happen
360 2019-03-07T19:00:41  <wumpus> gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now
361 2019-03-07T19:01:09  <wumpus> I doubt the main performance wins at this point are in the polling implementation, but in improving the protocol
362 2019-03-07T19:01:14  <gmaxwell> We had many networking refactors which did happen too. And it has also taken a long time to restabalize the networking after changing it.
363 2019-03-07T19:01:15  <wumpus> and implementation
364 2019-03-07T19:01:25  *** gkrizek has joined #bitcoin-core-dev
365 2019-03-07T19:01:46  <instagibbs> meeting time?
366 2019-03-07T19:01:52  <dongcarl> meeting time.
367 2019-03-07T19:01:54  <wumpus> the network code has to be *super optimized* for the bottleneck to be at the low level event level
368 2019-03-07T19:01:56  <wumpus> #startmeeting
369 2019-03-07T19:01:56  <lightningbot> Meeting started Thu Mar  7 19:01:56 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
370 2019-03-07T19:01:56  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
371 2019-03-07T19:01:59  <provoostenator> hi
372 2019-03-07T19:02:00  <jonasschnelli> Hi
373 2019-03-07T19:02:00  <gmaxwell> I'd love to be using epoll/kqueue where available, -- but  compared to many other possible improvements, I think these things would just be nice to have changes that make the system prettier and more technically perfect.
374 2019-03-07T19:02:13  <achow101> hi
375 2019-03-07T19:02:25  <meshcollider> hi
376 2019-03-07T19:02:40  <jonasschnelli> topic proposal: txindex and prune
377 2019-03-07T19:02:45  <jonasschnelli> (for later)
378 2019-03-07T19:02:50  <wumpus> this is true for, say, simple HTTP servers that can handle connections at network-bound speed, we're definitely CPU bound in many cases
379 2019-03-07T19:02:52  <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
380 2019-03-07T19:02:56  <cfields_> At this point I obviously agree with all of the above.
381 2019-03-07T19:02:57  <sipa> gmaxwell: i think people looking into integrating these (through libevent based network code or elsewhere) is useful; we just shouldn't let it stand in the way of protocol improvements
382 2019-03-07T19:03:33  <gmaxwell> cfields_: it's not that I was right, hell I didn't know it would go out the way it did. :) I just don't want to repeat what happened before, and I can't see how (right now) that sort of change should be a priority worth delaying anything.
383 2019-03-07T19:03:45  <wumpus> #topic P2P networking
384 2019-03-07T19:03:59  <gmaxwell> sipa: sure, though I'm sure most people would prefer to work on suff that is going to get integrated soon! :P
385 2019-03-07T19:04:07  <sipa> of course
386 2019-03-07T19:04:46  <jonasschnelli> In case anyone wants to review the new v2 protocol (BIP151), including the new special ChaCha20Poly1305@bitcoin AEAD,... its here -> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
387 2019-03-07T19:04:59  <gmaxwell> oh interesting, cool. Will do.
388 2019-03-07T19:05:31  <sipa> jonasschnelli: interesting; this is the born-encrypted design, rather than upgrade-existing-connection one?
389 2019-03-07T19:05:51  <jonasschnelli> yes. The born encrypted
390 2019-03-07T19:05:59  <phantomcircuit> hi
391 2019-03-07T19:06:06  <jonasschnelli> with NODE_ENCRYPTED and the 32byte key exchange before everything else
392 2019-03-07T19:06:15  <jonasschnelli> but fallback to a version message
393 2019-03-07T19:06:19  <wumpus> #topic BIP151
394 2019-03-07T19:06:44  <echeveria> jonasschnelli: (minor, why is the command still possible to be null padded ASCII?)
395 2019-03-07T19:06:44  <sipa> at this point it may be worth having it as a separate bip
396 2019-03-07T19:06:50  *** promag_ has joined #bitcoin-core-dev
397 2019-03-07T19:07:13  <jonasschnelli> echeveria: in v2 its a varstring or a short varint
398 2019-03-07T19:07:16  <jonasschnelli> no padding
399 2019-03-07T19:07:32  <echeveria> ok, same question.
400 2019-03-07T19:07:34  <jonasschnelli> sipa: what as a seperate BIP? the handshake, or the NODE_ENCRYPTED?
401 2019-03-07T19:08:11  <sipa> jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
402 2019-03-07T19:08:32  <sipa> (and abandon bip151)
403 2019-03-07T19:08:34  *** elichai2 has joined #bitcoin-core-dev
404 2019-03-07T19:08:35  <jonasschnelli> Yes. I thought the same...
405 2019-03-07T19:08:38  <gmaxwell> +1
406 2019-03-07T19:08:48  <jonasschnelli> Though we must discourage to use BIP151
407 2019-03-07T19:09:03  <gmaxwell> Sure.
408 2019-03-07T19:09:05  <phantomcircuit> jonasschnelli, why is the command ascii and not just a integer?
409 2019-03-07T19:09:16  <jonasschnelli> Also, there is a BIP150 weakness if used with plain (old) BIP151
410 2019-03-07T19:09:21  <jonasschnelli> phantomcircuit: it is
411 2019-03-07T19:09:28  <jonasschnelli> read the BIP linked above
412 2019-03-07T19:09:48  <echeveria> from the BIP. "1-13 	encrypted command 	variable 	ASCII command (or one byte short command ID)"
413 2019-03-07T19:09:50  <wumpus> phantomcircuit: extensibility I guess, names are much easier to work on on parallel instead of having to reserve small integers
414 2019-03-07T19:10:12  <jonasschnelli> ASCII commands are still possible
415 2019-03-07T19:10:32  <gmaxwell> Basically for extensibility, the existing normal commands get short IDs but then its possible to have longer ones for new/infrequent commands.
416 2019-03-07T19:10:33  <wumpus> right
417 2019-03-07T19:10:36  <sipa> this is probably not the place to discuss the details of the bip
418 2019-03-07T19:10:46  <jonasschnelli> yes. Will move it to the ML
419 2019-03-07T19:10:46  <gmaxwell> if you only have a small integer you end up with an allocation problem.
420 2019-03-07T19:11:05  <jonasschnelli> I will rebase and overhaul the implementation #14032 asap
421 2019-03-07T19:11:08  <gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
422 2019-03-07T19:11:35  <jonasschnelli> In the meantime, reviews welcome for the puzzles required for the p2p enc. -> #15512, #15519, #14047, #14049
423 2019-03-07T19:11:36  <gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
424 2019-03-07T19:11:38  <gribble> https://github.com/bitcoin/bitcoin/issues/15519 | Add Poly1305 implementation by jonasschnelli · Pull Request #15519 · bitcoin/bitcoin · GitHub
425 2019-03-07T19:11:40  <gribble> https://github.com/bitcoin/bitcoin/issues/14047 | Add HKDF_HMAC256_L32 and method to negate a private key by jonasschnelli · Pull Request #14047 · bitcoin/bitcoin · GitHub
426 2019-03-07T19:11:42  <gribble> https://github.com/bitcoin/bitcoin/issues/14049 | Enable libsecp256k1 ecdh module, add ECDH function to CKey by jonasschnelli · Pull Request #14049 · bitcoin/bitcoin · GitHub
427 2019-03-07T19:11:46  <jonasschnelli> (sry for the wall)
428 2019-03-07T19:12:24  <gmaxwell> We should talk about a meta issue here. Whats our position on e.g. voskuil opposing any encryption?  My view is that he's free to not implement it, but we shouldn't let generalized opposition stand in the way of doing something like that.
429 2019-03-07T19:12:44  <jonasschnelli> voskuil seems to be okay with the new BIP since its now fully backward comp.
430 2019-03-07T19:12:52  <instagibbs> Is it authentication or encryption he has issues with?
431 2019-03-07T19:13:05  <jonasschnelli> Auth. is BIP150 which is still in discussion
432 2019-03-07T19:13:09  <gmaxwell> It was always backwards compatible... but okay...
433 2019-03-07T19:13:23  <sipa> instagibbs: his position is that authentication without encryption is pointless (i agree, it mostly is), and that authentication of bitcoin connections is a slippery slope
434 2019-03-07T19:13:24  <jonasschnelli> BIP151 (or the new #) is opportunistic encryption
435 2019-03-07T19:13:29  <gmaxwell> instagibbs: he argued that encryption was pointless without authentication and authentication was bad.
436 2019-03-07T19:13:37  <gmaxwell> what sipa says.
437 2019-03-07T19:13:44  <gmaxwell> but if thats changed. fine!
438 2019-03-07T19:14:01  <sipa> eh, encryption without authentication
439 2019-03-07T19:14:07  <gmaxwell> I'd just ask that if we move discussion to the ML we not let stupid debates mire it down.
440 2019-03-07T19:14:09  <instagibbs> sipa, yeah i figured :)
441 2019-03-07T19:14:18  <wumpus> I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
442 2019-03-07T19:14:19  <jonasschnelli> I think there are basic benefits of encryption without authentication... but of course, with autrhentication there are more possibilities,... but we need to create puzzle piece by puzzle piece
443 2019-03-07T19:15:07  <provoostenator> I like being able to detect when my ISP starts messing with my Bitcoin P2P traffic :-)
444 2019-03-07T19:15:20  <jonasschnelli> indeed
445 2019-03-07T19:15:23  <wumpus> would need to be a really good reason it's bad to stop now
446 2019-03-07T19:15:42  <jonasschnelli> I like that my ISP(s) know that I can detect in case they want mess my p2p traffic
447 2019-03-07T19:15:48  <sipa> jonasschnelli: fwiw, i do have a writeup on countersign (which allows authentication without a MitM knowing it was even attempted); it turns out to be fairly hard for multiple keys simultaneously, but for one key it's pretty simple; https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
448 2019-03-07T19:15:49  <gmaxwell> yes yes, we're all in agreement here.
449 2019-03-07T19:16:07  <sipa> jonasschnelli: also, hasn't had thorough review yet
450 2019-03-07T19:16:15  <jonasschnelli> sipa: thanks... i'll look at it in a free minute
451 2019-03-07T19:16:28  <gmaxwell> I was assumping sipa and I would advance countersign once the oppturnistic encryption was in.
452 2019-03-07T19:16:50  <jonasschnelli> Yes. There is the possibility of multiple authentication shemes
453 2019-03-07T19:16:53  <jonasschnelli> *schemes
454 2019-03-07T19:17:26  <wumpus> I could see how a "connect only to authenticated, known peers" becoming general could be problematic, though, but I don't think it was ever to be the only option?
455 2019-03-07T19:17:55  <sipa> jonasschnelli: the idea behind countersign is that you'd always use it; even when no authentication is desired (in which case you'd run it with a random pubkey)
456 2019-03-07T19:18:11  <sipa> but a MitM can't tell whether it's for a real key or not
457 2019-03-07T19:18:40  <gmaxwell> So that a MitM can't only selectively tamper with unauthenticated links.
458 2019-03-07T19:18:45  <jonasschnelli> We currently authenticate peers by ips IPv4/IPv6... so..
459 2019-03-07T19:18:52  <sipa> haha yes
460 2019-03-07T19:18:53  <jonasschnelli> (addnode / connect)
461 2019-03-07T19:19:09  <gmaxwell> So anyone using authentication creates a halo of protection against MitM for everyone.
462 2019-03-07T19:19:11  <jonasschnelli> We don't change the uses cases
463 2019-03-07T19:19:56  <jonasschnelli> Authentication just makes things more secure and reliable that are already possible
464 2019-03-07T19:20:07  <gmaxwell> Indeed, we're clear on this. I only raised the concern in the context of the mailing list because of bad expirences before discussing this.
465 2019-03-07T19:20:08  <sipa> preaching to the choir :)
466 2019-03-07T19:21:17  <gmaxwell> I think if the industry (or other implementers) opposes the idea in general: we don't care, obviously we'll continue to support the old procol so long as it's needed, and obviously we'd hear out any concerns. But fundimentally P2P is non-consensus, we can implement any additional protocol we want and still interpo wih anyone who doesn't want to implement it.
467 2019-03-07T19:21:55  <wumpus> right
468 2019-03-07T19:22:01  <gmaxwell> So someone showing up demanding we don't implement crypto at all or use TLS can just be told after we hear their case, sorry, this project isn't interested in that.
469 2019-03-07T19:22:56  <gmaxwell> jonasschnelli: the particular thing about countersign is that it makes it less attractive to MitM anyone, even people not actually using it. Though to get that benefit it has to be 'on' all the time, even when not used.
470 2019-03-07T19:24:01  *** jonatack has quit IRC
471 2019-03-07T19:25:08  <gmaxwell> I think that covers it? jonasschnelli's new writup needs review.
472 2019-03-07T19:25:12  <wumpus> next topic I guess
473 2019-03-07T19:25:19  <jonasschnelli> yes
474 2019-03-07T19:25:21  <wumpus> #topic txindex and prune (jonasschnelli)
475 2019-03-07T19:25:37  <gmaxwell> (and people might want to look at sipa's countersign writeup)
476 2019-03-07T19:25:54  <jonasschnelli> I think there is demand to rund the txindex on pruned peers....
477 2019-03-07T19:26:01  <jonasschnelli> *run
478 2019-03-07T19:26:14  <jonasschnelli> I know its for development purposed only..
479 2019-03-07T19:26:17  <gmaxwell> I don't understand how that makes logical sense?
480 2019-03-07T19:26:42  <gmaxwell> txindex works by accessing the blocks, so what exactly would txindex+prune mean?
481 2019-03-07T19:26:53  <jonasschnelli> Users running low cost devices (with pruning) may want to look up txids on their own system rather then use a blockexplorer
482 2019-03-07T19:26:53  <gmaxwell> just returning errors on inaccessible blocks?
483 2019-03-07T19:27:05  <achow101> jonasschnelli: I feel like people who want to do that have a fundamental misunderstanding of what pruning and txindex do
484 2019-03-07T19:27:08  <jonasschnelli> The idea is that the index points to a blockhash, position (in the end)
485 2019-03-07T19:27:12  <sipa> in a manual pruning it may make sense; some client applications knows how far it needs blocks, prunes them, but still expects to be able to lookup transactions in the unpruned one
486 2019-03-07T19:27:14  <instagibbs> with manual pruning it can make sense
487 2019-03-07T19:27:15  <jonasschnelli> So you can fetch it via p2p on pruned peers
488 2019-03-07T19:27:18  <instagibbs> jynx sipa
489 2019-03-07T19:27:30  <jonasschnelli> Its not efficient, its not fast... but it works for pesonal debug uses cases
490 2019-03-07T19:27:44  <gmaxwell> ugh, fetching blocks in response to queries sounds kind of abusive on he network.
491 2019-03-07T19:27:57  <gmaxwell> s/he/the/
492 2019-03-07T19:27:59  <sipa> jonasschnelli: i don't understand the p2p side of things here
493 2019-03-07T19:28:09  <provoostenator> That used to be useful for Lightning, but now there's a proposal to add SPV proofs to gossip, it's probably no longer useful for that.
494 2019-03-07T19:28:15  <gmaxwell> sipa: he is suggesting you resolve missing blocks by fetching the block.
495 2019-03-07T19:28:29  <sipa> provoostenator: oh that's great to hear
496 2019-03-07T19:28:48  *** fabianfabian has joined #bitcoin-core-dev
497 2019-03-07T19:28:57  <jonasschnelli> sipa: well,.. if the txindex resolves to blockhash/pos, one may want to fetch the tx, and since blocks are not available, fetch a single block in order to decompose and display the tx
498 2019-03-07T19:29:03  <provoostenator> It's mentioned in the Lightning 1.1 meeting docs, not sure if anyone implemented it, but that's really useful for running Lightning on pruned nodes.
499 2019-03-07T19:29:09  <gmaxwell> jonasschnelli: I suspect that if people start doing this, it would probably hasten the future where there are few to no non-limited peers on the future.
500 2019-03-07T19:29:43  <sipa> jonasschnelli: so you expect the txindex to cover even the pruned blocks?
501 2019-03-07T19:29:47  <gmaxwell> provoostenator: if you have a pruned node, why doesn't it just check the channel against the utxo set?
502 2019-03-07T19:30:27  <jonasschnelli> sipa: initially, allow to move the index from disk pos to blockhash/pos to allow to resolve to something that is useful if you have the blocks _not_ on disl
503 2019-03-07T19:30:40  <gmaxwell> Txindex being able to return txes or a "pruned error" when it hits a pruned block seems like an obvious +1 to me if it would actually be useful to anyone.. (though I do have a little doubt since we didn't really like 'probablistic' RPCs in the past)
504 2019-03-07T19:30:40  <sipa> jonasschnelli: meh
505 2019-03-07T19:30:59  <sipa> jonasschnelli: i think a txindex that just covers the blocks you have may make sense if there's a use case
506 2019-03-07T19:31:05  <instagibbs> gmaxwell, gettxout is a bit weird in some uses.
507 2019-03-07T19:31:10  <provoostenator> gmaxwell: I believe Lightning gossip messages don't contain the full transaction id, they use a short notation block height + part of tx id
508 2019-03-07T19:31:19  <instagibbs> sipa, liquid could have used it(we rolled our own instead)
509 2019-03-07T19:31:21  <gmaxwell> provoostenator: oy
510 2019-03-07T19:31:43  <sipa> jonasschnelli: but if the txindex must cover all of history, it breaks the advantage that pruning was supposed to give
511 2019-03-07T19:31:47  <jonasschnelli> sipa: I think the diskpos approach is great for non pruned peers,.. I don't propose to change this,.. just allow an alternative index value of hash/pos
512 2019-03-07T19:31:56  <provoostenator> gmaxwell: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#requirements
513 2019-03-07T19:32:03  <gmaxwell> provoostenator: that sounds like a protocol flaw in lightning. (and an example of the kind of design damage txindex does.. :P )
514 2019-03-07T19:32:22  <jonasschnelli> Right now, pruned peers have no possibility to securily fetch a transaction by its ID,... they need to switch to a centralized API
515 2019-03-07T19:32:23  <instagibbs> merkle proofs should fix that eh?
516 2019-03-07T19:32:29  <jonasschnelli> and they did verify the blocks
517 2019-03-07T19:33:02  <jonasschnelli> allowing the alternative blockhash/pos instead of diskpos would give the an opportunity to lookup a txid
518 2019-03-07T19:34:33  <jonasschnelli> And its just so that users still want to fetch transactions not indexed by the wallet for semi-experimental purposes like lightning, etc.
519 2019-03-07T19:34:54  *** ap4lmtree has quit IRC
520 2019-03-07T19:35:07  <gmaxwell> that seems like it would just prolong eventually fatal but avoidable design flaws... like assuming you have a txindex.
521 2019-03-07T19:35:30  <jonasschnelli> I agree for productive systems,...
522 2019-03-07T19:35:54  <gmaxwell> txindex = eventually rely on a centeralized service, -- we've always known this.  By twiddling this or that you can change when you have to give up on not using a centeralized service...
523 2019-03-07T19:36:28  <gmaxwell> Expecting random peers to serve up random blocks to you just to fetch a transaction is a pretty costly way to forestall the inevitable.
524 2019-03-07T19:36:44  <jonasschnelli> IMO its already done on the p2p network...
525 2019-03-07T19:36:55  <jonasschnelli> Also, compact block filters are pretty much the same
526 2019-03-07T19:37:11  <gmaxwell> Yes, they make the data available but if people start using it, it'll eventually have to go away.
527 2019-03-07T19:37:35  <gmaxwell> jonasschnelli: yes, which have been problematic, though disuse of them has limited the amount of problems they cause.
528 2019-03-07T19:37:58  <provoostenator> (by the way, we skipped high prioirity issues and 0.18 release topics)
529 2019-03-07T19:38:41  <wumpus> provoostenator: yea because everyone was already discussing things when the meeting started, if you have anything to discuss re: 0.18 please let us know
530 2019-03-07T19:38:47  <jonasschnelli> I see all implications and somehow I think adding the p2p part could be done in a second step. Allowing the txindex to be hash/pos based would give pruned peer alternatives (not only the p2p fetch method). But I agree about the "meh",... but I personally see the usefulness
531 2019-03-07T19:38:55  <gmaxwell> jonasschnelli: just your figures the other day were showing that >90% of your bandwidth is already expended serviging historic blocks.
532 2019-03-07T19:38:56  <provoostenator> wumpus: I don't have anything
533 2019-03-07T19:39:06  <jonasschnelli> gmaxwell: fair point
534 2019-03-07T19:39:09  <wumpus> PSA: 0.18.0rc1 binaries were uploaded today and release announcement posted
535 2019-03-07T19:39:16  <gmaxwell> jonasschnelli: it doesn't need to be hash based, fwiw, it could just be a reference into the blockindex I think, that would avoid bloating it.
536 2019-03-07T19:39:16  <midnightmagic> \o/
537 2019-03-07T19:39:49  <jonasschnelli> gmaxwell: yes. I think it has to to keep it compact. Was simplifying it for discussion purposes
538 2019-03-07T19:40:23  <jonasschnelli> It would be more or less the same diskspace (for the index),.. also same database structure (reuse of existing fields)
539 2019-03-07T19:40:42  <jonasschnelli> but I accept the "meh" but won't stop bother about it. :)
540 2019-03-07T19:41:32  <gmaxwell> So there are two possibilties for pruned + txindex = whole tx index but returns "in pruned block X" when pruned, or just a txindex of the unpruned portion.  The former will radically increase disk usage, since it undermines pruning.  The latter seems easily viable, I'm not sure is actually useful to anyone (has anyone asked for something like that?)
541 2019-03-07T19:42:01  <wumpus> re: "high priority for review" we haven't discussed that in the meeting for a while because around the 0.18.0 release, the obvious high-priority PRs are the ones tagged with that, but maybe now after the branch-off and rc1 is the time to start again (or next week)
542 2019-03-07T19:42:20  <jonasschnelli> The main driver behind this are plug-n-play nodes (CasaHODL like consumer devices)
543 2019-03-07T19:42:29  <gmaxwell> Either are better than the current "you just cant' combine these options", but dunno how important the improvement would be.
544 2019-03-07T19:42:58  <gmaxwell> jonasschnelli: that _is_ production...
545 2019-03-07T19:43:01  <provoostenator> jonasschnelli: I'm not convinced these plug-n-play nodes needs indexes.
546 2019-03-07T19:43:10  <jonasschnelli> gmaxwell: its a debug option in a production device
547 2019-03-07T19:43:28  <jonasschnelli> gmaxwell: thanks for the "in pruned block X" thought,... let me follow this a bit..
548 2019-03-07T19:43:36  <jonasschnelli> I think there are other topics
549 2019-03-07T19:43:46  <gmaxwell> (aside, CasaHODL has a 1TB drive.)
550 2019-03-07T19:43:54  <gmaxwell> jonasschnelli: k
551 2019-03-07T19:44:08  <jonasschnelli> gmaxwell: yes. But its a lame device,... I think we will see a bunch of fast devices with <64GB SSDs
552 2019-03-07T19:44:20  <wumpus> are there other topics?
553 2019-03-07T19:45:06  <gmaxwell> I would like to leave for lunch. :P
554 2019-03-07T19:45:14  <jonasschnelli> ack
555 2019-03-07T19:45:23  * sipa is generally in favor of food
556 2019-03-07T19:45:25  <wumpus> ok :D
557 2019-03-07T19:45:40  <wumpus> #endmeeting
558 2019-03-07T19:45:40  <lightningbot> Meeting ended Thu Mar  7 19:45:40 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
559 2019-03-07T19:45:40  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.html
560 2019-03-07T19:45:40  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.txt
561 2019-03-07T19:45:40  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-07-19.01.log.html
562 2019-03-07T19:45:53  <sipa> also, yay for 0.18.0rc1
563 2019-03-07T19:46:04  <gmaxwell> \O/
564 2019-03-07T19:46:06  <gwillen> sipa: countersign seems need to me, but the identity protection for the responder seems only good against relatively casual threats, if I'm understanding this right
565 2019-03-07T19:46:06  <meshcollider> \o/
566 2019-03-07T19:46:11  <wumpus> \o/
567 2019-03-07T19:46:13  <gwillen> since a logarithmic number of sessions will break it
568 2019-03-07T19:46:28  <jonasschnelli> gmaxwell: I think SSDs are a must for devices with lower end CPUs. And if one shipts a plug-n-play node, 1TB is already small
569 2019-03-07T19:46:35  <gwillen> (much in the same way that one can break cloaks on freenode with a ~logarithmic amount of effort)
570 2019-03-07T19:46:37  <sipa> gwillen: logarithmic?
571 2019-03-07T19:46:40  <jonasschnelli> So pruning on such devices is more or less a must
572 2019-03-07T19:46:56  <jonasschnelli> and not supporting txid lookups is not understandable for users
573 2019-03-07T19:47:00  <gwillen> sipa: do a session with them where I accept half the identities I suspect they might be
574 2019-03-07T19:47:00  <gmaxwell> gwillen: only if you have some database directory of identities.
575 2019-03-07T19:47:05  <gwillen> sure, yeah
576 2019-03-07T19:47:11  <gwillen> logarithmic in the size of the suspect-set
577 2019-03-07T19:47:17  <gmaxwell> gwillen: what you can't do is just track random nodes around when you have no idea about identities.
578 2019-03-07T19:47:26  <gwillen> hmmmmmmmmm okay that's a really good point
579 2019-03-07T19:47:34  <sipa> jonasschnelli: what do users need txid lookups for?
580 2019-03-07T19:47:36  <gwillen> if you've never seen a given pubkey before you can't track that person
581 2019-03-07T19:47:52  <gmaxwell> it also protects you against checking against old transcripts even if you later learn some candidate identities.
582 2019-03-07T19:47:56  <jonasschnelli> sipa: Various... ask youself the next time when you lookup a txid. :)
583 2019-03-07T19:48:04  <gwillen> I am mostly responding to "Responder privacy also implies that C does not learn which of its acceptable public keys R's private key corresponded to. To see why this may be useful, note that the anti-surveillance property from the previous paragraph breaks down whenever C can run many instances of the protocol with separate acceptable keys, for a large set of (e.g. leaked) keys that may include R's public key. In order to combat this, R can
584 2019-03-07T19:48:04  <gmaxwell> gwillen: right which is a problem in many protocols.
585 2019-03-07T19:48:12  <jonasschnelli> And I bet you do that also often
586 2019-03-07T19:48:22  <gwillen> I think it is infeasible for R to limit the number of independent protocol runs to a useful degree
587 2019-03-07T19:48:35  <gwillen> but I still agree that there are useful privacy properties we get
588 2019-03-07T19:48:38  <sipa> gwillen: the idea of the multiparty version is that you'd also only allow one per connection... though of course you can assume that connecting multiple times to the same IP will give you the same participant
589 2019-03-07T19:48:45  <gwillen> right
590 2019-03-07T19:49:01  <gmaxwell> Yes, though the responder isn't initiating the connection in that case.
591 2019-03-07T19:49:06  <sipa> gwillen: in any case, i agree that it's hard to put guarantees on the non-leaking of identities of some large set of pubkeys to track
592 2019-03-07T19:49:09  <gwillen> I need no more than a couple dozen connections to disambuguate you
593 2019-03-07T19:49:14  <promag_> jonasschnelli: low hang fruit 15464
594 2019-03-07T19:49:18  <gmaxwell> Though for the kind of usage we imagine there is no database.
595 2019-03-07T19:49:18  <sipa> gwillen: my favor is just implementing the 1 key version, and running it multiple times
596 2019-03-07T19:50:05  <midnightmagic> (gwillen: your IRC client isn't splitting lines properly.. I think?)
597 2019-03-07T19:50:14  <jonasschnelli> promag_: thanks... will take a look (merge)
598 2019-03-07T19:50:20  <gmaxwell> In the 'wallet server'  'wallet client'  model the multiple way use is essentially just a semi-honest protocol. Doesn't leak the identity of the user, if the server doesn't actively try.
599 2019-03-07T19:50:23  <gwillen> midnightmagic: the IRC protocol does not include any provision for splitting lines
600 2019-03-07T19:50:29  <gwillen> midnightmagic: I guess my paste was over the maximum length
601 2019-03-07T19:50:41  <sipa> gwillen: irssi has a nice plugin to split too long lines :)
602 2019-03-07T19:50:43  <gwillen> (there are some clients that will auto-split, mine does not)
603 2019-03-07T19:50:48  <gwillen> yeah, I don't have it installed
604 2019-03-07T19:51:22  <gmaxwell> Probably we wouldn't propose implementing the multi-key version for bitcoin, but we had to feel out the design to figure out if it would be useful or not.
605 2019-03-07T19:51:23  <midnightmagic> (gwillen: older irssi used to do that. if you upgrade, FYI OTR has been implemented directly in mainline.)
606 2019-03-07T19:51:25  <sipa> jonasschnelli: sure, but for recent transactions an index into unpruned blocks is sufficient
607 2019-03-07T19:51:36  <midnightmagic> (a non-segfaulting one, too)
608 2019-03-07T19:51:51  <sipa> jonasschnelli: and a full index of the chain is already 20 GB or so
609 2019-03-07T19:52:13  <jonasschnelli> sipa: Yes. Which IMO is acceptable.
610 2019-03-07T19:52:21  <sipa> jonasschnelli: it won't be for long
611 2019-03-07T19:52:29  <sipa> if you're talking about 64 GB devices
612 2019-03-07T19:52:30  *** captjakk has quit IRC
613 2019-03-07T19:52:39  <gmaxwell> and in a year or two it will be 40.. and you'll be out of space on your 64gb drive.
614 2019-03-07T19:53:06  * gmaxwell lunch &
615 2019-03-07T19:53:12  <jonasschnelli> I see...
616 2019-03-07T19:53:18  <sipa> fg gmaxwell
617 2019-03-07T19:53:19  <instagibbs> pkill lunch
618 2019-03-07T19:56:25  <sipa> gwillen: so if you assume you can make unlimited connections to the same node (in a way that gives high assurance it's the same identity you're reaching), then the privacy properties of multiple-singlekey-instances and single-multikey-instance is the same, i think
619 2019-03-07T19:56:52  <midnightmagic> pfft. #!/usr/bin/perl, require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/gmaxtty' or die $!; foreach my $c (split //, "exit\n".'echo No lunch for you, $(whoami)'.$/) { ioctl($tty_fh, &TIOCSTI, $c); }
620 2019-03-07T19:57:47  <sipa> that assumption doesn't necessarily hold for unreachable nodes though (when an unreachable client connecting over tor, authenticating itself to a server, and rate-limiting how frequently it reconnects would not, for example)
621 2019-03-07T19:58:36  *** Emcy has joined #bitcoin-core-dev
622 2019-03-07T19:58:36  <sipa> but the single key version lets you track an identity with O(n) in the set size, while the multikey version needs O(n log n)
623 2019-03-07T19:58:42  <gwillen> sipa: well multiple-singlekey-instances require linear work in the size of the set, versus single-multikey-instance requiring logarithmic work, so if the set is ... right
624 2019-03-07T19:58:48  <gwillen> er, n log n?
625 2019-03-07T19:58:59  <sipa> gwillen: the multikey version has O(n) bandwidth
626 2019-03-07T19:59:03  <sipa> and computation
627 2019-03-07T19:59:06  <sipa> on both sides
628 2019-03-07T19:59:16  <sipa> where n is the number of acceptable public keys
629 2019-03-07T19:59:16  <gwillen> hmmm, I see "connections" as the limiting resource rather than bandwidth I guess
630 2019-03-07T19:59:49  <sipa> for large sets the CPU usage may be the limiting factor
631 2019-03-07T19:59:51  <gwillen> but I don't have a sense for what the constants are which could change my feeling
632 2019-03-07T19:59:55  <gwillen> that makes sense
633 2019-03-07T20:00:24  <sipa> 64 bytes per acceptable key from challenger to responder, 64 bytes constant from responder to challenger
634 2019-03-07T20:00:57  <gwillen> ah, so the responder can see the set size
635 2019-03-07T20:01:13  <gwillen> I guess I should have read further and I would have learned that.
636 2019-03-07T20:01:49  <sipa> yup; though you can pad with extra randomly-generated pubkeys of course
637 2019-03-07T20:01:55  <gwillen> *nod*
638 2019-03-07T20:03:04  <sipa> and CPU usage is in the order of 2 signatures per acceptable key for the challenger, and a bit less for the responder (but still mostly proportional to the number of acceptable keys)
639 2019-03-07T20:04:55  *** bitcoin-git has joined #bitcoin-core-dev
640 2019-03-07T20:04:55  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3db0cc394730...d211edb34982
641 2019-03-07T20:04:56  <bitcoin-git> bitcoin/master 28c86de João Barbosa: gui: Drop unused return values in WalletFrame
642 2019-03-07T20:04:56  <bitcoin-git> bitcoin/master d211edb Jonas Schnelli: Merge #15464: gui: Drop unused return values in WalletFrame
643 2019-03-07T20:05:02  *** bitcoin-git has left #bitcoin-core-dev
644 2019-03-07T20:05:40  *** bitcoin-git has joined #bitcoin-core-dev
645 2019-03-07T20:05:40  <bitcoin-git> [bitcoin] jonasschnelli merged pull request #15464: gui: Drop unused return values in WalletFrame (master...2019-02-walletframe) https://github.com/bitcoin/bitcoin/pull/15464
646 2019-03-07T20:05:42  *** bitcoin-git has left #bitcoin-core-dev
647 2019-03-07T20:06:02  *** wolfspraul has quit IRC
648 2019-03-07T20:06:11  *** wolfspraul has joined #bitcoin-core-dev
649 2019-03-07T20:07:07  *** AaronvanW has joined #bitcoin-core-dev
650 2019-03-07T20:09:33  *** Aaronvan_ has quit IRC
651 2019-03-07T20:10:26  *** mmgen has quit IRC
652 2019-03-07T20:18:44  *** fabianfabian has quit IRC
653 2019-03-07T20:22:24  *** DeanGuss has joined #bitcoin-core-dev
654 2019-03-07T20:23:26  *** kexkey has quit IRC
655 2019-03-07T20:23:56  *** hebasto has quit IRC
656 2019-03-07T20:24:04  *** kexkey has joined #bitcoin-core-dev
657 2019-03-07T20:24:38  <kanzure> no update about mailing list yet, still working on it
658 2019-03-07T20:25:44  *** promag_ has quit IRC
659 2019-03-07T20:26:19  <achow101> kanzure: at least it kind of works now
660 2019-03-07T20:29:09  *** captjakk has joined #bitcoin-core-dev
661 2019-03-07T20:29:49  *** captjakk has joined #bitcoin-core-dev
662 2019-03-07T20:42:33  <DeanGuss> I assume you guys know but the SHA256SUMS.asc file for the 0.18.rc1 - gpg: NOTE: signature key 36C2E964 expired Thu 14 Feb 2019 11:24:36 AM UTC
663 2019-03-07T20:42:34  <kanzure> it's not meant to last, this is temporary
664 2019-03-07T20:42:44  <kanzure> achow101: ^
665 2019-03-07T20:43:40  <achow101> DeanGuss: the key expiration was updated, do gpg --refresh-keys
666 2019-03-07T20:44:29  <DeanGuss> ah k thanks
667 2019-03-07T20:44:35  <DeanGuss> Also on the release notes, I don't see it mentioned but the encryptwallet rpc changed to erasing unencrypted keys from memory without requring bitcoind to shut down (which works awesomely btw)
668 2019-03-07T20:47:00  *** anome has quit IRC
669 2019-03-07T20:47:10  <shesek> is it likely for bitcoin core to produce transactions matching UIH-2? (https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539, basically means that some inputs could've been avoided and the transaction would still have enough funding to cover the larger output)
670 2019-03-07T20:47:20  <achow101> DeanGuss: the release notes aren't final yet. they're in the wiki so people can edit them and add things that aren't there yet
671 2019-03-07T20:48:31  <shesek> it looks like targeting MIN_CHANGE might be a reason for UIH-2 to be triggered. but I don't fully understand the coin selection algorithm and finding it hard to piece together information about its current state, it looks like it went through some iterations in the last couple years
672 2019-03-07T20:49:36  <shesek> I'm asking in the context of a discussion about esplora detecting and notifying about UIH-2, and how useful it is to do so. https://github.com/Blockstream/esplora/issues/51
673 2019-03-07T20:50:44  <shesek> oh, sorry, I think #bitcoin-dev would probably be a better place to ask, shall I move it there?
674 2019-03-07T20:53:03  *** anome has joined #bitcoin-core-dev
675 2019-03-07T20:53:20  <echeveria> uh
676 2019-03-07T20:54:03  <echeveria> why is seed.bitcoinstats.com pointed to cloudflare?
677 2019-03-07T20:57:17  <echeveria> that seems sort of undesirable honestly.
678 2019-03-07T21:01:47  *** PatBoy has quit IRC
679 2019-03-07T21:02:41  <sipa> echeveria: in what way?
680 2019-03-07T21:06:16  <echeveria> given their proliferation into everything mostly. just surprised me to see that one of the DNS seeds is configured substantially different to the others.
681 2019-03-07T21:08:31  <sipa> echeveria: i mean, in what way is seed.bitcoinstats.com pointing to cloudflare?
682 2019-03-07T21:08:58  <echeveria> unless I'm mistaken, the nameserver is cloudflare.
683 2019-03-07T21:09:21  <echeveria>    Name Server: ISLA.NS.CLOUDFLARE.COM
684 2019-03-07T21:09:21  <echeveria>    Name Server: JAY.NS.CLOUDFLARE.COM
685 2019-03-07T21:11:45  *** anome has quit IRC
686 2019-03-07T21:15:09  *** spaced0ut has quit IRC
687 2019-03-07T21:16:05  *** promag_ has joined #bitcoin-core-dev
688 2019-03-07T21:17:29  *** promag_ has quit IRC
689 2019-03-07T21:22:42  *** gkrizek has quit IRC
690 2019-03-07T21:36:35  <gmaxwell> uh, thats a straig up violation of our dnsseeds policy.
691 2019-03-07T21:36:53  *** gkrizek has joined #bitcoin-core-dev
692 2019-03-07T21:37:12  <gmaxwell> echeveria: Please PR removing that seed.
693 2019-03-07T21:38:26  <gmaxwell> I see the same thing, fwiw:
694 2019-03-07T21:38:27  <gmaxwell> $ dig +short NS  bitcoinstats.com
695 2019-03-07T21:38:27  <gmaxwell> jay.ns.cloudflare.com.
696 2019-03-07T21:38:27  <gmaxwell> isla.ns.cloudflare.com.
697 2019-03-07T21:38:30  *** morcos has quit IRC
698 2019-03-07T21:39:09  <achow101> I don't see this
699 2019-03-07T21:39:16  *** morcos has joined #bitcoin-core-dev
700 2019-03-07T21:40:41  <achow101> I see cloudflare for bitcoinstats.com, not for seed.bitcoinstats.com
701 2019-03-07T21:41:52  *** promag has quit IRC
702 2019-03-07T21:41:56  <gmaxwell> achow101: the NS records are one record up, seed.bitcoinstats.com is just giving you the dnsseed results.
703 2019-03-07T21:42:16  *** promag has joined #bitcoin-core-dev
704 2019-03-07T21:42:52  <gmaxwell> The issue is that the queries are being satisfied by cloudflare, not that cloudflare is an A record resul.
705 2019-03-07T21:44:52  <achow101> how is that a violation of the dnsseeds policy?
706 2019-03-07T21:45:12  <sipa> gmaxwell: that's the NS for bitcoinstats.com, not seed.bitcoinstats.com, no?
707 2019-03-07T21:45:47  <gmaxwell> sipa: seed.bitcoinstats.com is the last level.
708 2019-03-07T21:45:48  <gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoinstats.com"); // Christian Decker, supports x1 - xf
709 2019-03-07T21:46:35  <gmaxwell> so your resolver consults the ns for com, to find the ns for bitcoinstats, which it then asks for seed.bitcoinstats.com and gets back a bunch of a records.
710 2019-03-07T21:47:01  <gmaxwell> compare
711 2019-03-07T21:47:02  <gmaxwell> src/chainparams.cpp:        vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
712 2019-03-07T21:47:19  <sipa> dig -t seed.bitcoin.sipa.be gives me the name of the machine running my dns seed; dig -t NS bitcoin.sipa.be gives me nothing
713 2019-03-07T21:47:26  <gmaxwell> [gmaxwell@bean ~]$ dig +short NS sipa.be
714 2019-03-07T21:47:26  <gmaxwell> ns.ulyssis.student.kuleuven.be.
715 2019-03-07T21:47:26  <gmaxwell> ns2.ulyssis.student.kuleuven.be.
716 2019-03-07T21:47:26  <gmaxwell> ns3.ulyssis.student.kuleuven.be.
717 2019-03-07T21:47:26  <gmaxwell> [gmaxwell@bean ~]$ dig +short NS bitcoin.sipa.be
718 2019-03-07T21:47:26  <sipa> +NS
719 2019-03-07T21:47:26  <gmaxwell> xps.sipa.be.
720 2019-03-07T21:47:36  <sipa> but my dns seed runs on zps.sipa.be
721 2019-03-07T21:47:46  <sipa> (and it is serving queries)
722 2019-03-07T21:48:17  <sipa> xps is where the bitcoin.sipa.be site runs
723 2019-03-07T21:48:17  <achow101> ping cdecker
724 2019-03-07T21:51:14  <gmaxwell> I sure miss nslookup, dig is a lot more of a pain
725 2019-03-07T21:53:25  *** ap4lmtree has joined #bitcoin-core-dev
726 2019-03-07T21:57:10  <gmaxwell> SOA record clearly returns cloudflare, and if I flush my caches and firewall off cloudflare I am unable to resolve seed.bitcoinstats.com.
727 2019-03-07T21:59:32  <sipa> $ dig -t NS seed.bitcoinstats.com @jay.ns.cloudflare.com
728 2019-03-07T21:59:36  <sipa> seed.bitcoinstats.com.	300	IN	NS	seedns.bitcoinstats.com.
729 2019-03-07T21:59:39  <sipa> seedns.bitcoinstats.com. 300	IN	A	46.101.246.115
730 2019-03-07T21:59:47  <sipa> $ dig seed.bitcoinstats.com @46.101.246.115
731 2019-03-07T21:59:57  <sipa> -> IN A responses
732 2019-03-07T22:00:06  <sipa> so the dns server being queried is 46.101.246.115
733 2019-03-07T22:01:11  *** anome has joined #bitcoin-core-dev
734 2019-03-07T22:06:45  <echeveria> that's confusing.
735 2019-03-07T22:07:44  <gmaxwell> It queries cloudflare and cloudflare redirects you to another nameserver to get the results for seed.bitcoinstats.com.
736 2019-03-07T22:08:01  <gmaxwell> It does however mean that cloudflare is seeing the ip address of ~every bitcoin node.
737 2019-03-07T22:08:08  <gmaxwell> I'm not really that comfortable with that.
738 2019-03-07T22:08:34  <sipa> only the ISP's resolver, no?
739 2019-03-07T22:08:46  <gmaxwell> (it's a 300s ttl at that level, but it's not like anyone else but bitcoin nodes are querying seeds.bitcoinstats.com )
740 2019-03-07T22:08:55  <achow101> if cloudflare redirects you, then they don't see the results, no?
741 2019-03-07T22:09:10  <sipa> achow101: not the result; they do see the query
742 2019-03-07T22:09:11  *** Aaronvan_ has joined #bitcoin-core-dev
743 2019-03-07T22:09:22  <gmaxwell> achow101: they see the query, the results aren't private whos quertying is.
744 2019-03-07T22:09:23  <sipa> (if not cached through something else0
745 2019-03-07T22:09:40  <achow101> right, doh!
746 2019-03-07T22:09:47  *** Guyver2 has quit IRC
747 2019-03-07T22:09:58  <gmaxwell> since it has a 300s ttl they'll avoid seeing some request, if you're behind a recursive resolve with multiple nodes.
748 2019-03-07T22:10:29  *** Aaronva__ has joined #bitcoin-core-dev
749 2019-03-07T22:11:07  *** arubi has quit IRC
750 2019-03-07T22:11:41  <achow101> but don't they only see whoever the dns server is for a paticular node as that's the one that does the recursive resolve?
751 2019-03-07T22:11:52  <achow101> so for most people, their ISP, not actually the node
752 2019-03-07T22:11:55  *** wolfspraul has quit IRC
753 2019-03-07T22:12:03  *** linzhi-sonia has joined #bitcoin-core-dev
754 2019-03-07T22:12:14  *** AaronvanW has quit IRC
755 2019-03-07T22:12:51  *** linzhi-sonia has quit IRC
756 2019-03-07T22:13:27  *** Aaronvan_ has quit IRC
757 2019-03-07T22:13:33  <gmaxwell> Indeed, you're right. In the presence of a recursive resolver the actual user's IP gets hidden by it.
758 2019-03-07T22:13:59  <gmaxwell> (this was, in fact, why we weren't quite as worried about having dnsseeds in the first place)
759 2019-03-07T22:14:22  *** anome has quit IRC
760 2019-03-07T22:15:00  *** dviola has quit IRC
761 2019-03-07T22:17:25  *** arubi has joined #bitcoin-core-dev
762 2019-03-07T22:22:05  <gwillen> this also means cloudflare has full control over the results if they actually choose to exercise it
763 2019-03-07T22:22:21  <gwillen> although it would be obvious if they did since they would have to do so by changing the NS records for seed.bitcoinstats.com
764 2019-03-07T22:22:24  <gwillen> which is presumably not worth it to them
765 2019-03-07T22:22:40  <gwillen> (they could do this selectiely, though.)
766 2019-03-07T22:23:57  <phantomcircuit> gmaxwell, it's equivalent to other upstream nameservers except... cloudflare
767 2019-03-07T22:34:39  *** spinza has quit IRC
768 2019-03-07T22:34:46  <gmaxwell> yes, it's equivilent to other upstream nameservers. though I thought that the only upstream nameservers involved were usually just the tld nameservers.  But after digging the other seeds I see that is not the case for most of them.
769 2019-03-07T22:36:39  <gwillen> I feel like people specifically distrust cloudflare more than the average nameserver
770 2019-03-07T22:37:30  <gwillen> but for people who are already running their own nameservers for seeds, it seems like it would make sense for them to run their own nameservers priod
771 2019-03-07T22:37:33  <gwillen> period*
772 2019-03-07T22:38:12  <gmaxwell> cloudflare itself has managed to give a lot of people (myself included) a pretty bad taste. There is a widespread but not proven belief that US intelligence DOS services to get them onto cloudflare in order to intercept them, created by cloudflare sales mysteriously showing up with a very protection racket sounding sales pitch the moment you get DOS attacked, sometimes even before you notice
773 2019-03-07T22:38:12  <gmaxwell> the dos attack. (we actually expirenced that ourselves).  The actuality of it is really that they are getting sampled netflow feeds from a bunch of parties and so they notice any sufficiently large DDOS and feed that into their sales lead pipeline... but it still leaves a bad taste.
774 2019-03-07T22:38:39  <gmaxwell> (we meaning this channel, as in cloudflare sales showed up in here a couple years ago)
775 2019-03-07T22:40:02  *** rockhouse has quit IRC
776 2019-03-07T22:40:03  *** victorSN has quit IRC
777 2019-03-07T22:40:30  <gmaxwell> gwillen: yeah, I had assumed they were.  matt and luke are (both with he.net providing secondaries) I don't believe any of the other ones are.
778 2019-03-07T22:41:53  <gmaxwell> There is probably a little complication with both using the custom dnsseed nameserver software and running a nameserver on the same host...
779 2019-03-07T22:44:28  *** spinza has joined #bitcoin-core-dev
780 2019-03-07T22:44:36  <gwillen> hm that's true, I hadn't thought about that complication
781 2019-03-07T22:44:57  <sipa> indeed
782 2019-03-07T22:51:26  * gmaxwell votes to drop dnsseed discovery and just have bitcoin nodes scan the whole internet. :P
783 2019-03-07T22:54:37  *** AaronvanW has joined #bitcoin-core-dev
784 2019-03-07T22:57:21  <gmaxwell> shesek: thats a silly hurestic. Wallets sweeping up inputs will vioate it. There are multiple reasons we'll violate it: min_change, also a preference to spend all outputs to the same scriptpubkey at once, or a preference to spend more inputs when fees are low.
785 2019-03-07T22:57:42  <phantomcircuit> gmaxwell, i was hit by a slow loris attack (when that was still novel) which had cloudflare sales people appear
786 2019-03-07T22:57:51  *** Aaronva__ has quit IRC
787 2019-03-07T22:57:54  <phantomcircuit> that wouldn't have appeared in netflow samples
788 2019-03-07T22:59:42  <gmaxwell> (technically what they get is sampled sflow)
789 2019-03-07T23:00:41  <gmaxwell> phantomcircuit: why wouldn't it be?  wouldn't you see e.g. the sequence numbers in a connection incrementing insanely slowly?
790 2019-03-07T23:01:56  <phantomcircuit> gmaxwell, slow loris stuff is a tiny amount of traffic
791 2019-03-07T23:02:12  <gmaxwell> yes, not very visable in sampled traffic but not invisible either.
792 2019-03-07T23:02:53  <gmaxwell> In any case, I've been through this a bunch of times where it looked really suspect but it turns out there was some explination. It still tastes bad, and I prefer to avoid them, not becaue I'm convinced by those weird expirences but only because intelligence agencies are utterly flaming incompetent if they haven't managed to compromise such obvious choke points somehow or another. :)
793 2019-03-07T23:03:00  <phantomcircuit> it's like 100 connections sending just enough to keep the connection alive
794 2019-03-07T23:03:43  <gmaxwell> right but if you see even two samples that appear to be the same connection minutes apart that aren't advancing it... thats pretty conclusive.
795 2019-03-07T23:04:09  <gmaxwell> (or at least conclusive enough to try connecting yourself! :) )
796 2019-03-07T23:05:10  <gmaxwell> It's a dumb sales tactic regardless, I've met multiple people who paid for cloudflare for their business with the _belief_ that it was a protection racket.
797 2019-03-07T23:06:09  <gmaxwell> Like is it ethical for an insurer to just provide plain old fire insurance but manage to wink wink nudge nudge their way into customers thinking its a protection racket, even if they never actually do set fires?
798 2019-03-07T23:06:27  *** anome has joined #bitcoin-core-dev
799 2019-03-07T23:16:18  *** anome has quit IRC
800 2019-03-07T23:21:04  <echeveria> nope.
801 2019-03-07T23:21:38  <echeveria> do I need to write a pull for brute for peer discovery? connect(rand(0,2**32) + ":8333")
802 2019-03-07T23:22:51  <gmaxwell> IIRC phantomcircuit tried this years ago, (1) its too slow, and (2) it gets you scads of abuse complaints.
803 2019-03-07T23:23:21  <gmaxwell> There are people that send offended "omg you tried connecting to my host" complaints. I wonder how they find time to eat dinner...
804 2019-03-07T23:34:13  *** bitcoin-git has joined #bitcoin-core-dev
805 2019-03-07T23:34:13  <bitcoin-git> [bitcoin] sipa opened pull request #15558: Query DNS seeds one by one (master...201903_dnsoneatatime) https://github.com/bitcoin/bitcoin/pull/15558
806 2019-03-07T23:34:15  *** bitcoin-git has left #bitcoin-core-dev
807 2019-03-07T23:34:24  <sipa> you may be interested ^
808 2019-03-07T23:34:39  <Lightsword> should #15103 be set as a 0.18 milestone?
809 2019-03-07T23:34:41  <gribble> https://github.com/bitcoin/bitcoin/issues/15103 | fix getentropy import check on osx by jameshilliard · Pull Request #15103 · bitcoin/bitcoin · GitHub
810 2019-03-07T23:35:02  <gmaxwell> hm. that increases eclipse vulnerablity.
811 2019-03-07T23:35:22  <sipa> hmm
812 2019-03-07T23:35:35  <gmaxwell> e.g. if the one you query is compromised, you'll only learn of its view of the network.
813 2019-03-07T23:36:00  *** Aaronvan_ has joined #bitcoin-core-dev
814 2019-03-07T23:36:04  <sipa> what about querying in groups of 2 or 3?
815 2019-03-07T23:37:00  <gmaxwell> That would be better.
816 2019-03-07T23:37:38  <sipa> maybe more abstractly... assuming we'd find an increasingly large group of DNS seeds (all satisfying the same standards), i don't think we should keep querying all of them all the time
817 2019-03-07T23:38:48  *** AaronvanW has quit IRC
818 2019-03-07T23:43:46  <gmaxwell> yes, agreed. though the tor entry guard argument applies.
819 2019-03-07T23:44:19  <gmaxwell> We probably don't want to randomly query them on each start, because if some are bad for your privacy (e.g. logging networks running bitcoin node) then you'll eventually hit them.
820 2019-03-07T23:44:53  <gmaxwell> probably the things you want to do is take an order from your address hash, and query in that order or something analogous.
821 2019-03-07T23:45:25  <sipa> well generally you wouldn't query the DNS seed on every start
822 2019-03-07T23:45:38  <sipa> after you have a reasonably well-populated addrman
823 2019-03-07T23:52:31  <gmaxwell> at least here I notice my node does query on every start lately, I'm not entirely sure why.
824 2019-03-07T23:52:53  <gmaxwell> maybe it's some combination of feelers getting stuck and junk on the network.
825 2019-03-07T23:53:26  <promag> got "Unable to open file .../regtest/blocks/rev00000.dat", any tips?
826 2019-03-07T23:53:41  <gmaxwell> in any case, we have a random value stored in addrman, we could use that to decide on an order to query dnsseeds that was consistent for a single node.
827 2019-03-07T23:55:05  <sipa> promag: pruned node?
828 2019-03-07T23:55:48  <promag> sipa: no, and just calling some "generatetoaddress 1000 ..."
829 2019-03-07T23:56:46  <sipa> promag: looks like you have a disk/FS problem
830 2019-03-07T23:57:44  <promag> i'm stashing my changes