1 2018-06-01T00:03:56  *** niska has quit IRC
  2 2018-06-01T00:09:45  *** lxer has quit IRC
  3 2018-06-01T00:17:18  *** niska has joined #bitcoin-core-dev
  4 2018-06-01T00:18:20  *** goatpig has quit IRC
  5 2018-06-01T00:53:38  *** Randolf has joined #bitcoin-core-dev
  6 2018-06-01T00:58:49  *** Krellan has joined #bitcoin-core-dev
  7 2018-06-01T01:07:35  *** jtimon has quit IRC
  8 2018-06-01T01:26:57  *** Randolf has quit IRC
  9 2018-06-01T01:29:02  *** Randolf has joined #bitcoin-core-dev
 10 2018-06-01T01:37:59  *** jhfrontz has quit IRC
 11 2018-06-01T01:50:29  *** meshcollider has quit IRC
 12 2018-06-01T02:06:03  *** Krellan has quit IRC
 13 2018-06-01T02:06:31  *** Krellan has joined #bitcoin-core-dev
 14 2018-06-01T02:10:36  *** Krellan has quit IRC
 15 2018-06-01T02:34:42  *** Aaronvan_ has joined #bitcoin-core-dev
 16 2018-06-01T02:34:52  *** Aaronvan_ has quit IRC
 17 2018-06-01T02:37:57  *** AaronvanW has quit IRC
 18 2018-06-01T02:42:27  *** TheV01d has quit IRC
 19 2018-06-01T02:47:08  *** TheV01d has joined #bitcoin-core-dev
 20 2018-06-01T02:51:16  *** jhfrontz has joined #bitcoin-core-dev
 21 2018-06-01T03:09:56  *** fanquake has joined #bitcoin-core-dev
 22 2018-06-01T03:12:15  *** fanquake has quit IRC
 23 2018-06-01T03:44:45  *** luke-jr has quit IRC
 24 2018-06-01T03:44:45  *** vicenteH has quit IRC
 25 2018-06-01T03:44:46  *** kinlo has quit IRC
 26 2018-06-01T03:44:46  *** wallet42 has quit IRC
 27 2018-06-01T03:44:46  *** gaf_ has quit IRC
 28 2018-06-01T03:44:46  *** exit70 has quit IRC
 29 2018-06-01T03:44:46  *** rubensayshi_ has quit IRC
 30 2018-06-01T03:44:46  *** CryptAxe has quit IRC
 31 2018-06-01T03:44:46  *** pindarhk_ has quit IRC
 32 2018-06-01T03:44:46  *** bosma has quit IRC
 33 2018-06-01T03:44:46  *** rockhouse has quit IRC
 34 2018-06-01T03:44:46  *** Eliel has quit IRC
 35 2018-06-01T03:44:46  *** delpa^ has quit IRC
 36 2018-06-01T03:44:46  *** cncr04s has quit IRC
 37 2018-06-01T04:36:20  *** Jackpot1136 has joined #bitcoin-core-dev
 38 2018-06-01T04:43:10  *** Jackpot1136 has quit IRC
 39 2018-06-01T04:51:57  *** bitconner has quit IRC
 40 2018-06-01T04:53:40  *** luke-jr has joined #bitcoin-core-dev
 41 2018-06-01T05:12:23  <kallewoof> I'm a bit surprised at the concerns with people running distros from 2007 not being able to run the latest & greatest version of bitcoin core. Does such a person actually exist?
 42 2018-06-01T05:13:55  <kallewoof> Also amazed at how long RHEL support lasts. :O
 43 2018-06-01T05:20:21  <mryandao> enterprise would be running the oldest version of bitcoin possible
 44 2018-06-01T05:21:31  *** tryphe has joined #bitcoin-core-dev
 45 2018-06-01T05:24:17  *** tryphe_ has quit IRC
 46 2018-06-01T05:40:32  *** SopaXorzTaker has joined #bitcoin-core-dev
 47 2018-06-01T05:42:05  *** bitconner has joined #bitcoin-core-dev
 48 2018-06-01T05:53:32  <kallewoof> mryandao: Yeah, so even if RHEL 8 was released with C++14 support it wouldn't really matter cause its users would be running bitcoin core 0.3 or something, anyway...
 49 2018-06-01T05:55:05  *** harrymm has quit IRC
 50 2018-06-01T06:08:56  *** harrymm has joined #bitcoin-core-dev
 51 2018-06-01T06:24:08  <jonasschnelli> sipa: Yes. Possible,... but seems like we re-inventing a description language like JSON. :)
 52 2018-06-01T06:24:41  <jonasschnelli> I like such compact forms though,.. but they tend to fail once extended to the max
 53 2018-06-01T06:25:39  <jonasschnelli> Maybe it makes more sense to use JSON as the container/desciption format rather then inventing a custom CSV
 54 2018-06-01T06:26:14  <jonasschnelli> not sure though,.. the compact string format would be used at various places,.. like importmulti, etc.
 55 2018-06-01T06:26:25  <jonasschnelli> We just need to make sure it works for all possible extensions
 56 2018-06-01T06:41:20  <sipa> jonasschnelli: i'm worrier about introducing too many formats
 57 2018-06-01T06:48:21  <sipa> jonasschnelli: my idea is that the "records" that eventually will constitute a wallet will consist of a) a descriptor of script(s) and (b) birthdate (c) watchonly or not (d) private key optionally
 58 2018-06-01T06:48:47  <jonasschnelli> Yes. I think that is a very good idea..
 59 2018-06-01T06:48:51  <sipa> the (a) part is something that should be shared with scanutxo and perhaps some other things
 60 2018-06-01T06:48:54  <jonasschnelli> My concerns are more about the format
 61 2018-06-01T06:49:25  <sipa> so it would be nice of it's a nice and self contained thing
 62 2018-06-01T06:49:31  <sipa> it could be json
 63 2018-06-01T06:49:45  <sipa> that was what i was thinking too... but it's kind of unwieldy too
 64 2018-06-01T06:49:52  <jonasschnelli> Not sure what would make more sense...
 65 2018-06-01T06:49:54  <sipa> so i'm considering a single string thing
 66 2018-06-01T06:50:07  <jonasschnelli> If the use cases are beyond JSON RPC, then I think a "new" format may make sense
 67 2018-06-01T06:50:38  <jonasschnelli> JSON is very extensible...
 68 2018-06-01T06:51:00  <sipa> dump files
 69 2018-06-01T06:51:21  <jonasschnelli> Yes...
 70 2018-06-01T06:51:26  * jonasschnelli thinking...
 71 2018-06-01T06:52:13  <jonasschnelli> The whole dump file is another things... I'm currently not sure what the purpose of a dump file is, and if it is "a backup", if it is the right format
 72 2018-06-01T06:52:26  *** SopaXorzTaker has quit IRC
 73 2018-06-01T06:52:50  <jonasschnelli> But I kinda like a string based descriptor,... lets do that
 74 2018-06-01T06:53:29  <jonasschnelli> sipa: have you done a short spec on it already?
 75 2018-06-01T06:53:45  *** SopaXorzTaker has joined #bitcoin-core-dev
 76 2018-06-01T06:54:28  <jonasschnelli> Would it be k/v or fix order/index? Would the xpub ckd range also be possible to describe?
 77 2018-06-01T06:54:50  <sipa> yes, it needs to be
 78 2018-06-01T06:55:02  <jonasschnelli> What is "(c) watchonly or not"?
 79 2018-06-01T06:55:08  <sipa> jonasschnelli: read my.gist
 80 2018-06-01T06:55:17  <sipa> i've linked to it many times :)
 81 2018-06-01T06:55:31  <jonasschnelli> heh.. okay. I shoud re-read you wallet gist, yes.
 82 2018-06-01T06:56:08  <sipa> jonasschnelli: the idea is that watchonly should not be tied to whether or not you happen to ha e the private key
 83 2018-06-01T06:56:08  <jonasschnelli> We should that probably stick to the channel topic. :)
 84 2018-06-01T06:56:30  <jonasschnelli> hmm...
 85 2018-06-01T06:56:53  <jonasschnelli> But I guess senseless for primitive scripts like P2WPKH?
 86 2018-06-01T06:56:59  <sipa> no
 87 2018-06-01T06:57:10  <sipa> for example if your private key is in a hardware wallet
 88 2018-06-01T06:57:17  <sipa> that shouldn't be treated as watchonly
 89 2018-06-01T06:57:19  <sipa> it is yours
 90 2018-06-01T06:57:41  <jonasschnelli> Aha... you look at it from an overall perspective... I was looking from a pure "wallet" perspective
 91 2018-06-01T06:57:42  <sipa> watchonly is for multisig things that you participate in, but don't want counted towards your balance
 92 2018-06-01T06:58:19  <sipa> so my view is that private key or not should be independent from "counted towards balance" ("watch only") or not
 93 2018-06-01T06:58:33  <jonasschnelli> So then there would be 3 categories, hot keys (default), non-private-key-keys (HWW) and watch only?
 94 2018-06-01T06:59:27  <sipa> no, there are "yours" records and "non-yours records" ("watch only")
 95 2018-06-01T06:59:50  <jonasschnelli> When I did a primitive PoC with Core and the Bitbox, I came to the conclusion that three categories may make sense...
 96 2018-06-01T06:59:50  <sipa> in addition, you have private keys... in various places; some can be in your wallet, some are not
 97 2018-06-01T07:00:04  <sipa> the wallet should not care about whether it has the private key or not
 98 2018-06-01T07:00:08  <jonasschnelli> But since multiwallet, this is no longer necesarry I gues
 99 2018-06-01T07:00:11  <jonasschnelli> *s
100 2018-06-01T07:00:19  <sipa> please, read my gist :)
101 2018-06-01T07:00:33  <jonasschnelli> Yes. I see. Makes sense to me...
102 2018-06-01T07:00:44  <jonasschnelli> Yes. I should read your gist every morning...
103 2018-06-01T07:00:49  <jonasschnelli> amen. :)
104 2018-06-01T07:04:42  *** lxer has joined #bitcoin-core-dev
105 2018-06-01T07:27:51  *** bitconner has quit IRC
106 2018-06-01T07:31:35  *** bitconner has joined #bitcoin-core-dev
107 2018-06-01T07:33:34  *** fanquake has joined #bitcoin-core-dev
108 2018-06-01T07:34:03  <fanquake> wumpus got a 6.3 vm setup, will get through those bsd PRs
109 2018-06-01T07:45:15  *** ghost43 has quit IRC
110 2018-06-01T07:47:26  *** vicenteH has joined #bitcoin-core-dev
111 2018-06-01T07:47:26  *** kinlo has joined #bitcoin-core-dev
112 2018-06-01T07:47:26  *** wallet42 has joined #bitcoin-core-dev
113 2018-06-01T07:47:26  *** gaf_ has joined #bitcoin-core-dev
114 2018-06-01T07:47:26  *** exit70 has joined #bitcoin-core-dev
115 2018-06-01T07:47:26  *** rubensayshi_ has joined #bitcoin-core-dev
116 2018-06-01T07:47:26  *** CryptAxe has joined #bitcoin-core-dev
117 2018-06-01T07:47:26  *** pindarhk_ has joined #bitcoin-core-dev
118 2018-06-01T07:47:26  *** bosma has joined #bitcoin-core-dev
119 2018-06-01T07:47:26  *** rockhouse has joined #bitcoin-core-dev
120 2018-06-01T07:47:26  *** Eliel has joined #bitcoin-core-dev
121 2018-06-01T07:47:26  *** delpa^ has joined #bitcoin-core-dev
122 2018-06-01T07:47:26  *** cncr04s has joined #bitcoin-core-dev
123 2018-06-01T07:47:41  *** exit70 has quit IRC
124 2018-06-01T07:49:43  *** exit70 has joined #bitcoin-core-dev
125 2018-06-01T08:00:41  <wumpus> fanquake: great!
126 2018-06-01T08:03:25  *** Cory has quit IRC
127 2018-06-01T08:05:26  <fanquake> #13355 fixes running gmake check
128 2018-06-01T08:05:28  <gribble> https://github.com/bitcoin/bitcoin/issues/13355 | Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling by practicalswift · Pull Request #13355 · bitcoin/bitcoin · GitHub
129 2018-06-01T08:06:32  <wumpus> thanks for checking, it seems about time to merge it
130 2018-06-01T08:09:38  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87a9d03c0c1e...0b1c0c462eda
131 2018-06-01T08:09:38  <bitcoin-git> bitcoin/master db56755 practicalswift: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling
132 2018-06-01T08:09:39  <bitcoin-git> bitcoin/master 0b1c0c4 Wladimir J. van der Laan: Merge #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling...
133 2018-06-01T08:09:44  *** Pasha has joined #bitcoin-core-dev
134 2018-06-01T08:10:31  <bitcoin-git> [bitcoin] laanwj closed pull request #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (master...openbsd-gmake-check) https://github.com/bitcoin/bitcoin/pull/13355
135 2018-06-01T08:10:32  <fanquake> Obviously 13294 was submitted without running any tests, seeing as they would have been broken at the time.. ? Bit scary given the changes
136 2018-06-01T08:11:26  *** setpill has joined #bitcoin-core-dev
137 2018-06-01T08:11:54  *** aaa_ has joined #bitcoin-core-dev
138 2018-06-01T08:12:08  <aaa_> join
139 2018-06-01T08:12:11  <aaa_> ??
140 2018-06-01T08:12:17  *** aaa_ is now known as Guest15263
141 2018-06-01T08:12:34  <Guest15263> 11111
142 2018-06-01T08:12:34  *** timothy has joined #bitcoin-core-dev
143 2018-06-01T08:12:56  *** Pasha is now known as Cory
144 2018-06-01T08:13:06  <Guest15263> 31232321
145 2018-06-01T08:13:08  <Guest15263> adad
146 2018-06-01T08:13:08  <Guest15263> ad
147 2018-06-01T08:13:08  <Guest15263> d
148 2018-06-01T08:13:08  <Guest15263> d
149 2018-06-01T08:13:09  <Guest15263> d
150 2018-06-01T08:13:09  <Guest15263> d
151 2018-06-01T08:13:09  <Guest15263> d
152 2018-06-01T08:13:09  <Guest15263> d
153 2018-06-01T08:13:10  <Guest15263> d
154 2018-06-01T08:13:10  <Guest15263> d
155 2018-06-01T08:13:11  <Guest15263> d
156 2018-06-01T08:13:11  <Guest15263> d
157 2018-06-01T08:13:12  <Guest15263> d
158 2018-06-01T08:13:14  <fanquake> Please stop.
159 2018-06-01T08:14:35  <Guest15263> Why no one speaks?Is this a bitcore channel?
160 2018-06-01T08:15:25  <fanquake> This channel is for Core Development discussion. Generally there are always hundreds of people idling/watching. Actually discussion happens sporadically.
161 2018-06-01T08:15:53  <fanquake> *actual
162 2018-06-01T08:16:43  <Guest15263> soga
163 2018-06-01T08:17:05  *** drizztbsd has joined #bitcoin-core-dev
164 2018-06-01T08:17:23  *** timothy has quit IRC
165 2018-06-01T08:26:08  <wumpus> fanquake: #13294 duplicates too much of the ifdef forest for my taste, Maybe empact's idea of just pre-declaring the function instead would result in less mess.
166 2018-06-01T08:26:11  <gribble> https://github.com/bitcoin/bitcoin/issues/13294 | Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 by practicalswift · Pull Request #13294 · bitcoin/bitcoin · GitHub
167 2018-06-01T08:28:14  *** ghost43 has joined #bitcoin-core-dev
168 2018-06-01T08:29:04  <wumpus> I think there should be a limit to how much logic to add just to avoid a compiler warning, we're at the point again where the avoidance of warnings becomes a goal in itself instead of an indication of potential problems.
169 2018-06-01T08:30:48  <wumpus> I mean at least in #13349 I also solved an issue, while removing the warning.
170 2018-06-01T08:30:51  <gribble> https://github.com/bitcoin/bitcoin/issues/13349 | bench: Dont return a bool from main by laanwj · Pull Request #13349 · bitcoin/bitcoin · GitHub
171 2018-06-01T08:32:31  <fanquake> wumpus I agree. Should find out what the test plan was to ensure that no behaviour changed for any of the platforms affected by that forrest, just to silence a warning.
172 2018-06-01T08:32:41  <fanquake> That feels like exactly the kind of place you'd subtly break something.
173 2018-06-01T08:33:37  <wumpus> woule be a very bad place to break something too, and hard todetect
174 2018-06-01T08:47:13  <bitcoin-git> [bitcoin] jonasschnelli pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b1c0c462eda...343d4e44ef4d
175 2018-06-01T08:47:14  <bitcoin-git> bitcoin/master 9421317 John Newbery: [wallet] [rpc] Add `createwallet` RPC...
176 2018-06-01T08:47:14  <bitcoin-git> bitcoin/master 32167e8 John Newbery: [wallet] [tests] Add tests for `createwallet` RPC.
177 2018-06-01T08:47:15  <bitcoin-git> bitcoin/master f7e153e John Newbery: [wallets] [docs] Add release notes for createwallet RPC.
178 2018-06-01T08:47:46  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #13058: [wallet] `createwallet` RPC - create new wallet at runtime (master...create_wallet) https://github.com/bitcoin/bitcoin/pull/13058
179 2018-06-01T08:52:04  *** Guest15263 has quit IRC
180 2018-06-01T08:52:47  <fanquake> wumpus #13353 looks ok
181 2018-06-01T08:52:49  <gribble> https://github.com/bitcoin/bitcoin/issues/13353 | qa: Fixup setting of PATH env var by MarcoFalke · Pull Request #13353 · bitcoin/bitcoin · GitHub
182 2018-06-01T09:05:00  <wumpus> yes
183 2018-06-01T09:05:11  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/343d4e44ef4d...d4f6dac9abf8
184 2018-06-01T09:05:12  <bitcoin-git> bitcoin/master fa26cf0 MarcoFalke: qa: Fixup setting of PATH env var
185 2018-06-01T09:05:12  <bitcoin-git> bitcoin/master d4f6dac Wladimir J. van der Laan: Merge #13353: qa: Fixup setting of PATH env var...
186 2018-06-01T09:06:06  <bitcoin-git> [bitcoin] laanwj closed pull request #13353: qa: Fixup setting of PATH env var (master...Mf1806-qaPathBitcoind) https://github.com/bitcoin/bitcoin/pull/13353
187 2018-06-01T09:16:11  <kewde[m]> https://github.com/bitcoin/bitcoin/blob/0.16/src/qt/locale/bitcoin_ru.ts#L65
188 2018-06-01T09:16:41  <kewde[m]> What a weird translation - seems like the Russian language is adopting bitcoin addresses as new vocabulary.
189 2018-06-01T09:17:13  <wumpus> kewde[m]: yuck
190 2018-06-01T09:17:30  <fanquake> kewde[m] heh. Could you report it upstream? https://www.transifex.com/bitcoin/bitcoin/
191 2018-06-01T09:17:31  <wumpus> kewde[m]: thanks for noticing
192 2018-06-01T09:17:44  <wumpus> fanquake: I'm just going to nuke the message
193 2018-06-01T09:17:51  <wumpus> (on transfex)
194 2018-06-01T09:17:57  <fanquake> wumpus np
195 2018-06-01T09:18:04  <kewde[m]> I can't take credit for noticing it - just passing along the message.
196 2018-06-01T09:18:28  <wumpus> good that it was caught in a rc at least
197 2018-06-01T09:19:27  <wumpus> fanquake: maybe delete the entire Russian translation to teach them a lesson :p
198 2018-06-01T09:19:34  <kewde[m]> https://insight.bitpay.com/address/12Ny5wkrQ5d5bVk2LANAx5R3wcMT9HLFz9
199 2018-06-01T09:20:09  <fanquake> wumpus heh, poor translators
200 2018-06-01T09:20:42  <wumpus> I think this is the first time this was ever tried, or at least reported. I'll change the import translations script to check for this.
201 2018-06-01T09:21:11  <kewde[m]> It hasn't received any funds recently - but there is a tx from 2017 O_o
202 2018-06-01T09:22:01  <wumpus> kewde[m]: bizarre
203 2018-06-01T09:23:43  *** ken2812221 has quit IRC
204 2018-06-01T09:24:50  <wumpus> I reverted the message on transifex (they keep a history, thankfully). https://www.transifex.com/user/profile/IVAN6015/ is the person that added the address.
205 2018-06-01T09:24:59  *** ken2812221 has joined #bitcoin-core-dev
206 2018-06-01T09:25:39  <wumpus> looks like they did no other damage at least in RU
207 2018-06-01T09:28:06  <fanquake> wumpus good to know
208 2018-06-01T09:28:17  <fanquake> I'm heading out, will get some more review done tomorrow.
209 2018-06-01T09:28:54  *** fanquake has quit IRC
210 2018-06-01T09:29:46  *** ken2812221 has quit IRC
211 2018-06-01T09:38:16  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/4ea3e8ef070417ccc22007407d78fa0a41949bee
212 2018-06-01T09:38:16  <bitcoin-git> bitcoin/0.16 4ea3e8e Wladimir J. van der Laan: qt: Periodic translations update...
213 2018-06-01T09:39:26  <wumpus> the address will be gone in next rc
214 2018-06-01T09:42:47  <wumpus> created issue #13363
215 2018-06-01T09:42:48  <gribble> https://github.com/bitcoin/bitcoin/issues/13363 | Make update-translations.py script check for (valid) bitcoin addresses · Issue #13363 · bitcoin/bitcoin · GitHub
216 2018-06-01T09:43:58  <wumpus> (might have a stab at this myself later, but if someone else wants to, you're very welcome)
217 2018-06-01T09:47:47  *** Guyver2 has joined #bitcoin-core-dev
218 2018-06-01T09:52:17  *** ghost43 has quit IRC
219 2018-06-01T09:52:18  *** intcat has quit IRC
220 2018-06-01T09:54:33  *** intcat has joined #bitcoin-core-dev
221 2018-06-01T10:07:35  *** ghost43 has joined #bitcoin-core-dev
222 2018-06-01T10:24:24  *** AaronvanW has joined #bitcoin-core-dev
223 2018-06-01T10:30:23  <bitcoin-git> [bitcoin] mess110 opened pull request #13364: update transifex doc links (master...fix_transifex_client_config_link) https://github.com/bitcoin/bitcoin/pull/13364
224 2018-06-01T10:40:24  *** drizztbsd is now known as timothy
225 2018-06-01T10:42:02  *** Aaronvan_ has joined #bitcoin-core-dev
226 2018-06-01T10:44:41  *** AaronvanW has quit IRC
227 2018-06-01T10:46:44  *** AaronvanW has joined #bitcoin-core-dev
228 2018-06-01T10:50:22  *** Aaronvan_ has quit IRC
229 2018-06-01T11:04:12  *** mess110 has joined #bitcoin-core-dev
230 2018-06-01T11:05:05  *** bitconner has quit IRC
231 2018-06-01T11:05:25  <mess110> hi
232 2018-06-01T11:05:57  <mess110> can I please get a rebuild for https://github.com/bitcoin/bitcoin/pull/13364 ? I updated some doc links but some test failed
233 2018-06-01T11:09:16  *** timothy has quit IRC
234 2018-06-01T11:10:48  *** timothy has joined #bitcoin-core-dev
235 2018-06-01T11:15:05  *** timothy has quit IRC
236 2018-06-01T11:15:27  *** timothy has joined #bitcoin-core-dev
237 2018-06-01T11:18:16  *** timothy has quit IRC
238 2018-06-01T11:25:34  *** timothy has joined #bitcoin-core-dev
239 2018-06-01T11:30:02  *** drizztbsd has joined #bitcoin-core-dev
240 2018-06-01T11:30:59  *** timothy has quit IRC
241 2018-06-01T11:34:49  *** bitconner has joined #bitcoin-core-dev
242 2018-06-01T11:39:27  *** bitconner has quit IRC
243 2018-06-01T11:46:44  *** bitconner has joined #bitcoin-core-dev
244 2018-06-01T11:53:42  *** bitconner has quit IRC
245 2018-06-01T12:01:06  <wumpus> mess110: I've triggered the failed build
246 2018-06-01T12:01:48  <wumpus> going to merge #13352 as it's anoying that travis fails all the time
247 2018-06-01T12:01:50  *** bitconner has joined #bitcoin-core-dev
248 2018-06-01T12:01:51  <gribble> https://github.com/bitcoin/bitcoin/issues/13352 | qa: Avoid checking reject code for now by MarcoFalke · Pull Request #13352 · bitcoin/bitcoin · GitHub
249 2018-06-01T12:03:33  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4f6dac9abf8...e24bf1ce184b
250 2018-06-01T12:03:33  <bitcoin-git> bitcoin/master faac7a2 MarcoFalke: qa: Avoid checking reject code for now...
251 2018-06-01T12:03:34  <bitcoin-git> bitcoin/master e24bf1c Wladimir J. van der Laan: Merge #13352: qa: Avoid checking reject code for now...
252 2018-06-01T12:04:16  <bitcoin-git> [bitcoin] laanwj closed pull request #13352: qa: Avoid checking reject code for now (master...Mf1806-qaRejectCode) https://github.com/bitcoin/bitcoin/pull/13352
253 2018-06-01T12:06:19  *** bitconner has quit IRC
254 2018-06-01T12:07:27  <bitcoin-git> [bitcoin] yuntai opened pull request #13365: RPC/REST/ZMQ: Set label with importprivkey only requested. #13087 (master...master) https://github.com/bitcoin/bitcoin/pull/13365
255 2018-06-01T12:17:32  *** bitconner has joined #bitcoin-core-dev
256 2018-06-01T12:18:12  *** niu has joined #bitcoin-core-dev
257 2018-06-01T12:18:17  *** AaronvanW has quit IRC
258 2018-06-01T12:21:17  *** niu has quit IRC
259 2018-06-01T12:22:05  *** bitconner has quit IRC
260 2018-06-01T12:23:36  *** jtimon has joined #bitcoin-core-dev
261 2018-06-01T12:23:49  *** AaronvanW has joined #bitcoin-core-dev
262 2018-06-01T12:26:22  *** bitconner has joined #bitcoin-core-dev
263 2018-06-01T12:28:45  *** goatpig has joined #bitcoin-core-dev
264 2018-06-01T12:31:30  *** laurentmt has joined #bitcoin-core-dev
265 2018-06-01T12:33:31  *** bitconner has quit IRC
266 2018-06-01T12:33:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
267 2018-06-01T12:40:49  *** bitconner has joined #bitcoin-core-dev
268 2018-06-01T12:41:25  *** qu4ku has joined #bitcoin-core-dev
269 2018-06-01T12:42:43  *** Krellan has joined #bitcoin-core-dev
270 2018-06-01T12:44:06  *** AaronvanW has quit IRC
271 2018-06-01T12:44:16  *** fanquake has joined #bitcoin-core-dev
272 2018-06-01T12:44:42  *** AaronvanW has joined #bitcoin-core-dev
273 2018-06-01T12:45:35  *** bitconner has quit IRC
274 2018-06-01T12:47:26  *** Krellan has quit IRC
275 2018-06-01T12:49:08  *** AaronvanW has quit IRC
276 2018-06-01T12:49:43  *** qu4ku has joined #bitcoin-core-dev
277 2018-06-01T12:50:04  *** bitconner has joined #bitcoin-core-dev
278 2018-06-01T12:51:20  *** AaronvanW has joined #bitcoin-core-dev
279 2018-06-01T12:54:48  *** bitconner has quit IRC
280 2018-06-01T12:55:29  <bitcoin-git> [bitcoin] giulio92 opened pull request #13366: Docs: Rename “OS X” to the newer “macOS” convention (master...osx-renaming) https://github.com/bitcoin/bitcoin/pull/13366
281 2018-06-01T13:02:21  *** bitconner has joined #bitcoin-core-dev
282 2018-06-01T13:02:57  *** Chris_Stewart_5 has quit IRC
283 2018-06-01T13:07:13  *** bitconner has quit IRC
284 2018-06-01T13:07:35  *** setpill has quit IRC
285 2018-06-01T13:13:55  *** bitconner has joined #bitcoin-core-dev
286 2018-06-01T13:14:06  <jonasschnelli> sipa: what do you think about "address:<addr>/b<timestamp_uint64>/w|p<pkey_wif>" or "script:<script_hex>" or "p2wpkh:<pub|xpub>/r0-2000/..."?
287 2018-06-01T13:15:26  <jonasschnelli> pub/xpub is autodetect, first char r | b | w | p is for (r)ange, (b)irthday, (w)atchonly, (p)rivatekey
288 2018-06-01T13:16:55  <jonasschnelli> we could avoid the first "key-char" and detect the type an the length and characteristics (8byte int == birthday, <num>–<num> == range, etc.)
289 2018-06-01T13:17:10  <jonasschnelli> But it smells after voodoo... so unsure
290 2018-06-01T13:19:26  *** bitconner has quit IRC
291 2018-06-01T13:21:08  *** bitconner has joined #bitcoin-core-dev
292 2018-06-01T13:25:57  *** bitconner has quit IRC
293 2018-06-01T13:28:59  *** bitconner has joined #bitcoin-core-dev
294 2018-06-01T13:30:04  *** gojo has joined #bitcoin-core-dev
295 2018-06-01T13:31:17  <gojo> Hi, I'm experienced developer Blockchain, C/C++, reverse engineering, compilers, drivers, GPU/OpenCL, Cryptography, Python, NodeJS, Linux, Windows, Web, mobile, embedded and more. Urgent! I'm looking for important job!
296 2018-06-01T13:33:38  *** bitconner has quit IRC
297 2018-06-01T13:36:21  *** qu4ku has quit IRC
298 2018-06-01T13:36:59  <jonasschnelli> gojo: no jobs here...
299 2018-06-01T13:37:16  *** bitconner has joined #bitcoin-core-dev
300 2018-06-01T13:41:51  *** bitconner has quit IRC
301 2018-06-01T13:42:46  *** cryptapus has quit IRC
302 2018-06-01T13:43:11  *** cryptapus has joined #bitcoin-core-dev
303 2018-06-01T13:43:29  *** drizztbsd is now known as timothy
304 2018-06-01T13:47:13  *** bitconner has joined #bitcoin-core-dev
305 2018-06-01T13:49:01  <TheCharlatan> Picking up from yesterday's back compat question, I'm having the same problems with gcc-7 as ken2812221 in #12511 using same configure and environment flags as in the gitian linux descriptor. I'm not sure if there is a simple fix available for this, like currently with aliasing memcpy.
306 2018-06-01T13:49:03  <gribble> https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
307 2018-06-01T13:51:26  *** laurentmt has quit IRC
308 2018-06-01T13:52:07  *** bitconner has quit IRC
309 2018-06-01T13:59:11  *** bitconner has joined #bitcoin-core-dev
310 2018-06-01T14:04:38  *** bitconner has quit IRC
311 2018-06-01T14:05:33  *** bitconner has joined #bitcoin-core-dev
312 2018-06-01T14:06:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
313 2018-06-01T14:10:25  *** bitconner has quit IRC
314 2018-06-01T14:15:55  *** bitconner has joined #bitcoin-core-dev
315 2018-06-01T14:20:27  *** bitconner has quit IRC
316 2018-06-01T14:25:32  <wumpus> I've made a start with the addrv2 BIP spec: https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1
317 2018-06-01T14:29:52  *** bitconner has joined #bitcoin-core-dev
318 2018-06-01T14:34:36  *** bitconner has quit IRC
319 2018-06-01T14:37:45  *** bitconner has joined #bitcoin-core-dev
320 2018-06-01T14:39:52  * jonasschnelli reading addrv2 BIP
321 2018-06-01T14:41:40  <jonasschnelli> wumpus: nice.
322 2018-06-01T14:41:50  <jonasschnelli> I like the backward compatible way (only >128bit use v2)
323 2018-06-01T14:42:16  <jonasschnelli> Not sure about the name addrv2 (versioning of protocol commands)
324 2018-06-01T14:42:32  <jonasschnelli> or it should be something like addr32
325 2018-06-01T14:42:43  *** bitconner has quit IRC
326 2018-06-01T14:44:20  <wumpus> yes the name is completely contingent, I don't care
327 2018-06-01T14:44:54  <wumpus> as for the backwards compatibility, I think I prefer a new network version that simply uses addrv2 only, this will allow moving away from legacy addr messages at some point completely
328 2018-06-01T14:45:30  <wumpus> I think the only advantage of the backward compatible approach is that it doesn't require a new network version, but I'm not sure how important that is
329 2018-06-01T14:45:37  <jonasschnelli> Yes. It is a cleaner cut
330 2018-06-01T14:46:28  <wumpus> we could even *not* rename the message, with the new protocol version, but that introduces some fragility I'm not happy with
331 2018-06-01T14:47:11  *** vicenteH has quit IRC
332 2018-06-01T14:47:45  *** vicenteH has joined #bitcoin-core-dev
333 2018-06-01T14:47:53  <jonasschnelli> I guess using a varint for services is probably an unnecessary optimization? It would save 33% for a IPv4 addr
334 2018-06-01T14:48:04  <jonasschnelli> (with the current used service bits)
335 2018-06-01T14:48:09  <jonasschnelli> AFAIK
336 2018-06-01T14:48:57  <jonasschnelli> wumpus: I guess not using a new command would probably make a lot of stupid light clients crash. :)
337 2018-06-01T14:49:30  *** bitconner has joined #bitcoin-core-dev
338 2018-06-01T14:49:32  <wumpus> jonasschnelli: that's an interesting proposal
339 2018-06-01T14:49:57  <wumpus> jonasschnelli: I like it, don't see a reason why not
340 2018-06-01T14:50:27  <jonasschnelli> Yes. I think its worth it.
341 2018-06-01T14:50:35  <wumpus> jonasschnelli: even beter, it's future-proof
342 2018-06-01T14:50:40  <jonasschnelli> Especially since the addrv2 is already varlen
343 2018-06-01T14:50:44  <wumpus> (I guess, in a way)
344 2018-06-01T14:51:03  <jonasschnelli> >8byte service bits?!... not sure if we ever reach that limit :)
345 2018-06-01T14:51:10  <wumpus> yes, decided on varlen because padding everything to 32 bytes would be crazy, and I like not wasting space for v4 addresses
346 2018-06-01T14:51:23  <jonasschnelli> Yes. Good point.
347 2018-06-01T14:52:01  <jonasschnelli> Another redundant byte is the std::vector<uint8_t> varlen byte
348 2018-06-01T14:52:17  <jonasschnelli> But I guess that serialization property we can't change
349 2018-06-01T14:52:55  <jonasschnelli> (since the length is indirectly defined by the networkID)
350 2018-06-01T14:53:11  *** brianhoffman has left #bitcoin-core-dev
351 2018-06-01T14:54:14  *** bitconner has quit IRC
352 2018-06-01T15:01:55  *** m8tion has joined #bitcoin-core-dev
353 2018-06-01T15:02:08  *** bitconner has joined #bitcoin-core-dev
354 2018-06-01T15:05:24  <luke-jr> wumpus: it might be a good idea to include port in addr
355 2018-06-01T15:05:44  <luke-jr> hidden services don't have ports IIRC, and non-TCP protocols might not either -  or might have 64-bit ports or smth
356 2018-06-01T15:06:40  <luke-jr> 32-bit times seem to be dying, but we probably will end up with a new addr message before 2038 I guess
357 2018-06-01T15:06:54  <luke-jr> especially if services isn't revised now
358 2018-06-01T15:07:20  *** bitconner has quit IRC
359 2018-06-01T15:07:21  <jonasschnelli> makes sense to me: putting port into the addr part
360 2018-06-01T15:08:52  *** bitconner has joined #bitcoin-core-dev
361 2018-06-01T15:13:35  <wumpus> hidden services have ports
362 2018-06-01T15:13:50  <wumpus> luke-jr: we could use a VARINT for the time too
363 2018-06-01T15:14:07  *** bitconner has quit IRC
364 2018-06-01T15:15:26  *** fanquake has quit IRC
365 2018-06-01T15:15:34  *** bitconner has joined #bitcoin-core-dev
366 2018-06-01T15:15:50  <wumpus> luke-jr: another option would be to lower precision
367 2018-06-01T15:16:03  <luke-jr> hmm
368 2018-06-01T15:16:05  <luke-jr> or both
369 2018-06-01T15:16:31  <luke-jr> epoch 2009 with 1 hour resolution seems plenty
370 2018-06-01T15:17:16  <luke-jr> or 90 minutes to be tonal-correct :D
371 2018-06-01T15:18:16  *** jhfrontz has quit IRC
372 2018-06-01T15:19:06  <wumpus> luke-jr: jonasschnelli: changed them both to VARINT, thanks for the comments
373 2018-06-01T15:20:33  *** bitconner has quit IRC
374 2018-06-01T15:23:06  *** ken2812221 has joined #bitcoin-core-dev
375 2018-06-01T15:24:29  <wumpus> I've added the concern about lowering time precision as well as rolling the port into address into a "considerations" section, I'm not sure about those
376 2018-06-01T15:24:56  *** bitconner has joined #bitcoin-core-dev
377 2018-06-01T15:29:37  *** bitconner has quit IRC
378 2018-06-01T15:29:40  <luke-jr> well, like I said, it's unlikely we'll still be using this BIP in 2038 if it doesn't improve the services field, so 32-bit time probably is fine
379 2018-06-01T15:30:08  <luke-jr> and unsigned 32-bit time is actually even 2106, not 2038
380 2018-06-01T15:31:58  <wumpus> having always been angry at the people that decided to use two-digit years and gave us the Y2K nonsense, I'm very happy to make it 2038-proof
381 2018-06-01T15:33:35  *** bitconner has joined #bitcoin-core-dev
382 2018-06-01T15:38:21  *** bitconner has quit IRC
383 2018-06-01T15:44:24  *** bitconner has joined #bitcoin-core-dev
384 2018-06-01T15:45:23  *** Randolf has quit IRC
385 2018-06-01T15:50:27  <gmaxwell> wumpus: cool!
386 2018-06-01T15:50:55  *** AaronvanW has quit IRC
387 2018-06-01T15:52:09  <gmaxwell> So would this also accomidate I2P?  I don't really recall what I2P needed, but I vaguely recall its addresses were 512 bits-ish... though it isn't unlikely that I'm mistaken.
388 2018-06-01T15:52:50  *** bitconner has quit IRC
389 2018-06-01T15:53:21  <luke-jr> I think that's the goal
390 2018-06-01T15:54:04  <gmaxwell> oh nevermind I see there is a section, don't see how I missed it on the first pass.
391 2018-06-01T15:54:47  *** cncr04s has quit IRC
392 2018-06-01T15:55:55  <wumpus> gmaxwell: yep - I2P is 256 bits
393 2018-06-01T15:56:07  *** cncr04s has joined #bitcoin-core-dev
394 2018-06-01T15:57:13  <wumpus> (could trivially extend the max length to 512 bits if that turns out to be needed for something, but I like the strict length requirement as it bounds the maximum size of addr messages)
395 2018-06-01T15:57:21  <gmaxwell> wumpus: some ideas circulating for nodes that store some fraction of the blockchain (e.g. some FEC slice, as in taek's post, or some range of blocks) need a bit of signaling to encode what is there.  With 64 bits of 'services' it could be stuffed there, but I'm not sure if thats what you'd want?
396 2018-06-01T15:57:35  <gmaxwell> yes, I like strict length checking too.
397 2018-06-01T15:58:18  *** bitconner has joined #bitcoin-core-dev
398 2018-06-01T15:58:20  <gmaxwell> wumpus: so would we want to addrv3 for those things, user service bits, or add some opional field mechenism(s)?
399 2018-06-01T15:58:37  <luke-jr> gmaxwell: services currently apply an | to the bits, so not useful for multi-bit stuff sadly
400 2018-06-01T15:58:39  <wumpus> gmaxwell: that was brought up in the meeting yesterday as well, by sdaftuar , but I'm not sure what that would imply in practice
401 2018-06-01T15:59:02  <wumpus> e.g. gossiping block ranges directly would not be useful as the information is outdated by time someone gets it
402 2018-06-01T15:59:24  <luke-jr> wumpus: just a seed that nodes can deterministically calculate block numbers from
403 2018-06-01T15:59:28  <gmaxwell> wumpus: these wouldn't be outdated by construction.
404 2018-06-01T15:59:32  <gmaxwell> as luke-jr says.
405 2018-06-01T15:59:37  <wumpus> but if it's some other kind of descriptor, sure, it could be added
406 2018-06-01T15:59:41  <gmaxwell> (also, FEC slice proposals don't have that issue)
407 2018-06-01T15:59:45  <wumpus> how many bits per address?
408 2018-06-01T16:00:24  <gmaxwell> I haven't seen any ideas that need more than 32 bits, most probably need 8-16 bits.  Perhaps just stick in a 32 bit field which has a "service flag specific interpertation" ?
409 2018-06-01T16:00:28  <luke-jr> there might be a fingerprinting risk here with too many bits, but too few might be an issue for storage too
410 2018-06-01T16:00:34  <wumpus> an optional field mechanism could work, but otoh, I'm a bit afraid of overdesign (also: it still has to be bounded)
411 2018-06-01T16:00:50  <gmaxwell> luke-jr: yes but leave that problem to the other proposals.
412 2018-06-01T16:01:17  <luke-jr> ah, true
413 2018-06-01T16:01:45  <wumpus> ah, an optional 32-bit field per service bit?
414 2018-06-01T16:02:29  <luke-jr> then I can make a 2k addr message.. :/
415 2018-06-01T16:02:33  <gmaxwell> If you care about space time field could be reduced to 16 bits easily.  Turn it into a "time ago seen" quantized to 1 hour precision. (IIRC we quantize times to 2hrs regardless).
416 2018-06-01T16:03:03  <gmaxwell> wumpus: oh I wasn't thinking of that, I was just thinking of 32 bits whos meaning is defined as "depends on the service bits".
417 2018-06-01T16:03:22  <gmaxwell> (e.g. just to take specifying its content out of scope for this BIP)
418 2018-06-01T16:03:27  *** bitconner has quit IRC
419 2018-06-01T16:04:43  <gmaxwell> having a field per service bit would be nice but unfortunately would allow huge messages.
420 2018-06-01T16:06:53  <luke-jr> I suppose nodes could policy-drop the extra data if they don't comprehend it?
421 2018-06-01T16:07:05  <gmaxwell> wumpus: is there any particular reason why you have a potentially irrelevant port field, rather than encoding the port in the low bytes of the address as relevant for the service type?
422 2018-06-01T16:07:40  <gmaxwell> luke-jr: then you need a mechenism to encode which extra data is there.
423 2018-06-01T16:07:53  <luke-jr> gmaxwell: you need that anyway if it's optional?
424 2018-06-01T16:08:22  <luke-jr> and it wouldn't make sense to have extra data for most of the current service bits
425 2018-06-01T16:08:36  <gmaxwell> luke-jr: right well if we didn't care about size we could just define that every service bit set gets 32 bits of flags. :)
426 2018-06-01T16:10:48  <gmaxwell> if we want optional flags. I guess the best thing would just be a byte to include the count of them, then a byte "type" for each one where the type also encodes if the payload is 0/8/16/32 bits. (using the two MSB of the type to encode the length).  And then bound the count of them so that the total is still reasonably sized.
427 2018-06-01T16:11:13  <gmaxwell> And then define nodes should strip ones they don't understand.
428 2018-06-01T16:11:24  <gmaxwell> or something along those lines.
429 2018-06-01T16:11:39  *** bitconner has joined #bitcoin-core-dev
430 2018-06-01T16:12:23  <wumpus> gmaxwell: yes, making the port optinal or rolling it into addr was mentioned by luke-jr, it's under "considerations", I'm not sure
431 2018-06-01T16:12:26  <gmaxwell> If that kind of mechenism existed there might be less argument to make service flags anything but 32 bits?
432 2018-06-01T16:13:04  <gmaxwell> wumpus: I don't care one way or another, it would save two bytes when not used, and perhaps eliminate some stupidity of what happens when it's non-zero for I2P or whatever doesn't use it.
433 2018-06-01T16:13:06  <wumpus> gmaxwell: at least currently all the mechanisms have a concept of port
434 2018-06-01T16:14:04  *** Randolf has joined #bitcoin-core-dev
435 2018-06-01T16:14:12  <gmaxwell> My memory of I2P is really bad then.
436 2018-06-01T16:14:18  <wumpus> 32 bits "depending on the service bits" would be ok, although it leaves some difficulty if multiple service bits want to use it
437 2018-06-01T16:15:25  <wumpus> same here, I intend to run this by one of the I2P devs before publishing it anyhow
438 2018-06-01T16:15:30  *** brianhoffman has joined #bitcoin-core-dev
439 2018-06-01T16:16:26  <gmaxwell> Beyond node-flavors for striping, another thing we might want more payload for is alternative ports for other transports. E.g. if later we define a bitcoin-over-udp we might want to signal the ports for that instead of sending two addr messages for the two endpoints.  I'm not currently remembering any other service flag things where we've wanted other payload.
440 2018-06-01T16:16:40  <gmaxwell> but I'm sure we could come up with other ones.
441 2018-06-01T16:16:47  *** bitconner has quit IRC
442 2018-06-01T16:17:40  <gmaxwell> I don't feel that strongly about any of this of course, if we're too limited it's not like it's a big deal to define an addr3.
443 2018-06-01T16:18:12  <wumpus> we already send multiple addr messages when listening to multiple interfaces
444 2018-06-01T16:18:36  *** bitconner has joined #bitcoin-core-dev
445 2018-06-01T16:19:35  <wumpus> but indeed there's a lot of reasons adding service-specfic information to gossiping would potentiall be useful, even though we have none at the moment
446 2018-06-01T16:19:39  <gmaxwell> yes though it would be really inefficient if almost every node were doing it.
447 2018-06-01T16:19:54  <gmaxwell> (sending a whole seperate addr just to give another 16 bit port number)
448 2018-06-01T16:20:05  <wumpus> yes
449 2018-06-01T16:23:13  <wumpus> there's risk of combinatorial blowup there
450 2018-06-01T16:23:32  <wumpus> that's a good argument for encoding the port separately though
451 2018-06-01T16:23:51  <wumpus> that extends better to having multiple ports
452 2018-06-01T16:24:02  *** bitconner has quit IRC
453 2018-06-01T16:24:03  <gmaxwell> one could use the above mechenism of a <type/length> byte followed by payload to do the port.
454 2018-06-01T16:24:37  <wumpus> yes
455 2018-06-01T16:26:40  <wumpus> that's a good idea, I think
456 2018-06-01T16:27:24  <wumpus> though it increases the average size, port is only 2 bytes, making it a 'data item' will by definition be larger
457 2018-06-01T16:28:20  <gmaxwell> Yes, though it's two bytes overhead assuming you used my above suggestion and had no other data items.
458 2018-06-01T16:28:21  *** bitconner has joined #bitcoin-core-dev
459 2018-06-01T16:28:42  <gmaxwell> One byte overhead if you had other data items.
460 2018-06-01T16:29:00  <wumpus> true, I just mean in practice, everything will be sending a port
461 2018-06-01T16:29:08  <gmaxwell> And I think if the data item mechenism existed service bits could stay 32 bits, saving a byte.
462 2018-06-01T16:30:06  <gmaxwell> or you keep the port field (or merge into the variable length addresses) for the primary port to get that savings.
463 2018-06-01T16:30:32  <wumpus> aren't service bits 64 bits right now?
464 2018-06-01T16:30:49  <gmaxwell> oh. hm! I thought they were 32bits!
465 2018-06-01T16:31:02  <gmaxwell> nope, 64.
466 2018-06-01T16:31:06  <wumpus> I thought so too yesterday
467 2018-06-01T16:31:28  <wumpus> that's why Jonas proposed turning it into a VARINT, which I did
468 2018-06-01T16:32:42  <sipa> they're 64 bits now
469 2018-06-01T16:33:47  *** bitconner has quit IRC
470 2018-06-01T16:36:21  <wumpus> I wonder if CJDNS should get its own network id, the reason I'm not sure is because they're explicitly IPv6 addresses
471 2018-06-01T16:37:38  *** arubi has quit IRC
472 2018-06-01T16:38:43  *** Victorsueca has quit IRC
473 2018-06-01T16:38:44  <gmaxwell> I suspect it should, since you can't reach them unless you use CJDNS? so it's like onion embedded tor?
474 2018-06-01T16:39:08  *** arubi has joined #bitcoin-core-dev
475 2018-06-01T16:39:54  *** Victorsueca has joined #bitcoin-core-dev
476 2018-06-01T16:40:44  <sipa> yeah, i good criterion for separate networks would be whether they need separate routing
477 2018-06-01T16:41:29  <wumpus> gmaxwell: that's true; the differece is that cjdns runs as a network interface, so from the viewpoint of the application it's simply IPv6 networking. OTOH it's possible to set up the firewall to do the same with TOr, so I'm not sure it's a useful distinction for this.
478 2018-06-01T16:41:52  *** bitconner has joined #bitcoin-core-dev
479 2018-06-01T16:41:58  <wumpus> so yes, better to just add a n ID, they're cheap
480 2018-06-01T16:46:40  *** bitconner has quit IRC
481 2018-06-01T16:47:44  *** bitconner has joined #bitcoin-core-dev
482 2018-06-01T16:47:59  *** Dizzle has joined #bitcoin-core-dev
483 2018-06-01T16:52:35  *** bitconner has quit IRC
484 2018-06-01T16:55:03  *** bitconner has joined #bitcoin-core-dev
485 2018-06-01T16:59:50  *** bitconner has quit IRC
486 2018-06-01T17:03:12  *** jhfrontz has joined #bitcoin-core-dev
487 2018-06-01T17:09:27  *** bitconner has joined #bitcoin-core-dev
488 2018-06-01T17:13:57  *** bitconner has quit IRC
489 2018-06-01T17:15:58  *** justan0theruser has quit IRC
490 2018-06-01T17:22:22  *** justan0theruser has joined #bitcoin-core-dev
491 2018-06-01T17:24:26  *** bitconner has joined #bitcoin-core-dev
492 2018-06-01T17:26:51  <wumpus> I guess we could save 6 bytes per Tor v2 address by not doing the onioncat thing (otoh, who's going to care about that going forward)
493 2018-06-01T17:28:56  <gmaxwell> ah, just don't onioncat embed them. that would be nice.  though who cares much about tor v2.
494 2018-06-01T17:29:47  *** bitconner has quit IRC
495 2018-06-01T17:31:03  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13367: qa: Increase includeconf test coverage (master...Mf1806-qaIncludeconf) https://github.com/bitcoin/bitcoin/pull/13367
496 2018-06-01T17:31:51  <gmaxwell> I assume that within a couple years we'll stop forwarding torv2 completely.
497 2018-06-01T17:32:49  *** vicenteH has quit IRC
498 2018-06-01T17:36:13  <sipa> wumpus: for simplicity, i think it makes sense to put tor v2 in a separate class
499 2018-06-01T17:36:18  <sipa> it needs separate routing after all
500 2018-06-01T17:36:52  <wumpus> sipa: that's what I've done, I just kept the onioncat wrapping (so addresses are 16 bytes not 10)
501 2018-06-01T17:37:02  *** bitconner has joined #bitcoin-core-dev
502 2018-06-01T17:37:28  <wumpus> gmaxwell: exactly my point, we don't really want to encourage torv2 after this work we're doing to support torv3 which is better in any way
503 2018-06-01T17:37:49  <sipa> wumpus: sorry, i should read first
504 2018-06-01T17:41:38  *** bitconner has quit IRC
505 2018-06-01T17:45:24  *** timothy has quit IRC
506 2018-06-01T17:51:58  *** bitconner has joined #bitcoin-core-dev
507 2018-06-01T17:56:59  *** bitconner has quit IRC
508 2018-06-01T18:04:29  *** bitconner has joined #bitcoin-core-dev
509 2018-06-01T18:08:31  <bitcoin-git> [bitcoin] achow101 opened pull request #13368: Update gitian-build.sh for docker (master...gitian-docker) https://github.com/bitcoin/bitcoin/pull/13368
510 2018-06-01T18:08:57  *** bitconner has quit IRC
511 2018-06-01T18:14:08  *** bitconner has joined #bitcoin-core-dev
512 2018-06-01T18:21:25  *** bitconner has quit IRC
513 2018-06-01T18:25:28  <bitcoin-git> [bitcoin] mess110 closed pull request #13364: update transifex doc links (master...fix_transifex_client_config_link) https://github.com/bitcoin/bitcoin/pull/13364
514 2018-06-01T18:27:05  *** bitconner has joined #bitcoin-core-dev
515 2018-06-01T18:28:33  <bitcoin-git> [bitcoin] mess110 opened pull request #13369: [docs] update transifex doc link (master...fix_transifex_doc_link) https://github.com/bitcoin/bitcoin/pull/13369
516 2018-06-01T18:31:02  <echeveria> wumpus: cjd is pretty much exclusively ipv6 in their own range.
517 2018-06-01T18:31:27  <echeveria> it's really kind of its own net because you can't reach any of the peers any other way.
518 2018-06-01T18:31:45  *** bitconner has quit IRC
519 2018-06-01T18:33:53  <wumpus> echeveria: indeed, there are no 'exit nodes'
520 2018-06-01T18:36:23  *** bitconner has joined #bitcoin-core-dev
521 2018-06-01T18:41:10  *** bitconner has quit IRC
522 2018-06-01T18:41:57  *** mess110 has quit IRC
523 2018-06-01T18:48:41  *** bitconner has joined #bitcoin-core-dev
524 2018-06-01T18:51:01  *** HFRadical has joined #bitcoin-core-dev
525 2018-06-01T18:51:03  *** HFRadical has quit IRC
526 2018-06-01T18:53:46  *** bitconner has quit IRC
527 2018-06-01T18:55:32  *** bitconner has joined #bitcoin-core-dev
528 2018-06-01T19:00:10  *** bitconner has quit IRC
529 2018-06-01T19:02:33  *** bitconner has joined #bitcoin-core-dev
530 2018-06-01T19:07:15  *** bitconner has quit IRC
531 2018-06-01T19:07:33  *** bitconner has joined #bitcoin-core-dev
532 2018-06-01T19:10:42  *** bitconner has quit IRC
533 2018-06-01T19:14:15  *** Randolf has quit IRC
534 2018-06-01T19:15:54  *** Randolf has joined #bitcoin-core-dev
535 2018-06-01T19:17:42  *** promag_ has joined #bitcoin-core-dev
536 2018-06-01T19:18:36  *** promag has joined #bitcoin-core-dev
537 2018-06-01T19:19:09  *** bitconner has joined #bitcoin-core-dev
538 2018-06-01T19:19:33  *** promag has quit IRC
539 2018-06-01T19:20:13  <gmaxwell> cfields: re: the 4/8-way sse/avx hash calculator, one of the reasons why txid computation is a little less interesting other than the complication, is that it's not in the critical path for HB block relay, but tree computation is.
540 2018-06-01T19:20:50  *** Randolf has quit IRC
541 2018-06-01T19:21:03  <gmaxwell> and so sipa's PR drops HB relay about 5ms per hop, which is a pretty large fraction of the total processing time.
542 2018-06-01T19:21:09  *** promag has joined #bitcoin-core-dev
543 2018-06-01T19:22:05  *** promag_ has quit IRC
544 2018-06-01T19:22:28  *** Randolf has joined #bitcoin-core-dev
545 2018-06-01T19:23:39  *** promag__ has joined #bitcoin-core-dev
546 2018-06-01T19:25:27  *** promag has quit IRC
547 2018-06-01T19:25:29  *** promag__ has quit IRC
548 2018-06-01T19:27:40  *** Victorsueca has quit IRC
549 2018-06-01T19:28:48  *** Victorsueca has joined #bitcoin-core-dev
550 2018-06-01T19:30:35  *** bitconner has quit IRC
551 2018-06-01T19:30:44  *** bitconner has joined #bitcoin-core-dev
552 2018-06-01T19:43:38  *** drexl has joined #bitcoin-core-dev
553 2018-06-01T19:46:17  *** bitconner has quit IRC
554 2018-06-01T19:46:39  *** bitconner has joined #bitcoin-core-dev
555 2018-06-01T19:47:28  *** SopaXorzTaker has quit IRC
556 2018-06-01T19:55:21  *** bitconner has quit IRC
557 2018-06-01T19:56:10  *** bitconner has joined #bitcoin-core-dev
558 2018-06-01T19:58:27  *** domble has joined #bitcoin-core-dev
559 2018-06-01T20:04:34  *** bitconner has quit IRC
560 2018-06-01T20:05:09  *** bitconner has joined #bitcoin-core-dev
561 2018-06-01T20:05:49  *** laurentmt has joined #bitcoin-core-dev
562 2018-06-01T20:06:52  *** AaronvanW has joined #bitcoin-core-dev
563 2018-06-01T20:11:42  *** laurentmt has quit IRC
564 2018-06-01T20:11:57  *** bitconner has quit IRC
565 2018-06-01T21:03:23  *** luke-jr has quit IRC
566 2018-06-01T21:03:32  *** luke-jr has joined #bitcoin-core-dev
567 2018-06-01T21:06:14  *** justan0theruser has quit IRC
568 2018-06-01T21:07:00  *** justanotheruser has joined #bitcoin-core-dev
569 2018-06-01T21:26:14  *** promag has joined #bitcoin-core-dev
570 2018-06-01T21:34:51  *** Guyver2 has quit IRC
571 2018-06-01T21:46:58  <sipa> wumpus: thanks, read the BIP draft now
572 2018-06-01T21:47:40  <sipa> it seems strange to use the onioncat embedded for tor v2, if there is a separate network type anyway (it just burdens clients to add/strip/check it )
573 2018-06-01T21:48:08  <sipa> varint for 64-bit services... it saves a bit, but they're already 64 bits, and varint can't actually encode anything longer than 64 bits
574 2018-06-01T21:48:13  *** vicenteH has joined #bitcoin-core-dev
575 2018-06-01T21:52:44  <promag> should unloadwallet PR include UI support so that unloaded wallets are removed?
576 2018-06-01T21:57:37  *** bitconner has joined #bitcoin-core-dev
577 2018-06-01T21:57:58  <gojo> What tools you are using for debug view uint256?
578 2018-06-01T21:59:33  <sipa> it has a GetHex() method for converting to a string
579 2018-06-01T22:01:14  <gojo> I mean inside gdb UI
580 2018-06-01T22:01:38  <gojo> i use GetHex() method for debug txdb my fork bugs
581 2018-06-01T22:02:24  <gojo> I join my own live logging tool for structured logs for fix complex bugs
582 2018-06-01T22:02:37  <gojo> I can share my code if needed
583 2018-06-01T22:04:07  <gojo> I looking for another way with gdbgui React debug widget
584 2018-06-01T22:04:55  <sipa> print pindexBestHeader->phashBlock->GetHex()
585 2018-06-01T22:05:11  <sipa> $3 = '0' <repeats 18 times>, "2521d8eb85294864f937918dcbdcc33f42ab0c55c5d5b9"
586 2018-06-01T22:06:21  <gojo> Not very optimal with hidden bugs in 100k blocks. I'm looking for something more easy
587 2018-06-01T22:06:33  <sipa> i'm not sure what you're asking for
588 2018-06-01T22:07:23  <gojo> 1. gdb vars view is wrong for uint256
589 2018-06-01T22:07:55  <gojo> 2. gdbgui require React dev for uint256, reason, but not much time for that
590 2018-06-01T22:08:16  <sipa> i don't understand that
591 2018-06-01T22:08:27  <sipa> what is react?
592 2018-06-01T22:08:33  <gojo> 3. my own logging solution is very slow when txdb has bug in 100k+ blocks
593 2018-06-01T22:08:47  <gojo> do you know gdbgui?
594 2018-06-01T22:08:50  <sipa> no
595 2018-06-01T22:09:06  <gojo> https://github.com/cs01/gdbgui
596 2018-06-01T22:09:19  <sipa> but what are you trying to achieve?
597 2018-06-01T22:09:35  <gojo> well customized browser frontend for gdb
598 2018-06-01T22:09:52  <sipa> i know uint256's internal view doesn't match the normal human readable form (your point 1), but i gave you the solution (use print ....GetHex())
599 2018-06-01T22:09:54  <gojo> i need for debug my fork step by step each line for 100k blocks
600 2018-06-01T22:10:03  <sipa> good luck then
601 2018-06-01T22:10:15  <gojo> thanks
602 2018-06-01T22:10:37  <gojo> i'm have solution that maybe helps someone
603 2018-06-01T22:10:41  *** Chris_Stewart_5 has quit IRC
604 2018-06-01T22:11:07  <gojo> i made several forks for Dash, Komodo etc
605 2018-06-01T22:11:16  <sipa> off topic here
606 2018-06-01T22:11:30  <gojo> btc-core is not offtopic
607 2018-06-01T22:11:42  <gojo> i have a logging system for bitcoin-core
608 2018-06-01T22:11:52  <gojo> i want to share it for made life easier
609 2018-06-01T22:11:56  <sipa> ok
610 2018-06-01T22:12:09  <gojo> but maybe someone has better solution
611 2018-06-01T22:12:19  <sipa> feel free to open a pull request to improve logging, if you have useful code
612 2018-06-01T22:12:22  <sipa> that sounds very welcome
613 2018-06-01T22:13:25  <gojo> ok, understand, thanks
614 2018-06-01T22:30:43  *** bitconner has quit IRC
615 2018-06-01T22:32:09  *** bitconner has joined #bitcoin-core-dev
616 2018-06-01T22:42:26  *** lxer has quit IRC
617 2018-06-01T22:53:55  *** Victorsueca has quit IRC
618 2018-06-01T22:55:26  *** Victorsueca has joined #bitcoin-core-dev
619 2018-06-01T22:57:41  *** Randolf has quit IRC
620 2018-06-01T23:01:23  *** AaronvanW has quit IRC
621 2018-06-01T23:08:51  *** jhfrontz has quit IRC
622 2018-06-01T23:10:29  *** lobo_ has joined #bitcoin-core-dev
623 2018-06-01T23:11:50  *** lobo_ has quit IRC
624 2018-06-01T23:12:04  *** AaronvanW has joined #bitcoin-core-dev
625 2018-06-01T23:17:01  *** AaronvanW has quit IRC
626 2018-06-01T23:17:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
627 2018-06-01T23:20:50  *** gojo has quit IRC
628 2018-06-01T23:32:04  *** AaronvanW has joined #bitcoin-core-dev
629 2018-06-01T23:33:05  *** Dizzle has quit IRC
630 2018-06-01T23:34:35  *** promag has quit IRC
631 2018-06-01T23:36:25  *** roidster has joined #bitcoin-core-dev