1 2018-06-01 05:11:22	0|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?
  2 2018-06-01 05:12:55	0|kallewoof|Also amazed at how long RHEL support lasts. :O
  3 2018-06-01 05:19:20	0|mryandao|enterprise would be running the oldest version of bitcoin possible
  4 2018-06-01 05:52:31	0|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...
  5 2018-06-01 06:23:07	0|jonasschnelli|sipa: Yes. Possible,... but seems like we re-inventing a description language like JSON. :)
  6 2018-06-01 06:23:40	0|jonasschnelli|I like such compact forms though,.. but they tend to fail once extended to the max
  7 2018-06-01 06:24:38	0|jonasschnelli|Maybe it makes more sense to use JSON as the container/desciption format rather then inventing a custom CSV
  8 2018-06-01 06:25:13	0|jonasschnelli|not sure though,.. the compact string format would be used at various places,.. like importmulti, etc.
  9 2018-06-01 06:25:24	0|jonasschnelli|We just need to make sure it works for all possible extensions
 10 2018-06-01 06:40:20	0|sipa|jonasschnelli: i'm worrier about introducing too many formats
 11 2018-06-01 06:47:20	0|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
 12 2018-06-01 06:47:46	0|jonasschnelli|Yes. I think that is a very good idea..
 13 2018-06-01 06:47:50	0|sipa|the (a) part is something that should be shared with scanutxo and perhaps some other things
 14 2018-06-01 06:47:53	0|jonasschnelli|My concerns are more about the format
 15 2018-06-01 06:48:24	0|sipa|so it would be nice of it's a nice and self contained thing
 16 2018-06-01 06:48:30	0|sipa|it could be json
 17 2018-06-01 06:48:44	0|sipa|that was what i was thinking too... but it's kind of unwieldy too
 18 2018-06-01 06:48:52	0|jonasschnelli|Not sure what would make more sense...
 19 2018-06-01 06:48:53	0|sipa|so i'm considering a single string thing
 20 2018-06-01 06:49:06	0|jonasschnelli|If the use cases are beyond JSON RPC, then I think a "new" format may make sense
 21 2018-06-01 06:49:37	0|jonasschnelli|JSON is very extensible...
 22 2018-06-01 06:49:59	0|sipa|dump files
 23 2018-06-01 06:50:20	0|jonasschnelli|Yes...
 24 2018-06-01 06:51:12	0|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
 25 2018-06-01 06:51:49	0|jonasschnelli|But I kinda like a string based descriptor,... lets do that
 26 2018-06-01 06:52:28	0|jonasschnelli|sipa: have you done a short spec on it already?
 27 2018-06-01 06:53:28	0|jonasschnelli|Would it be k/v or fix order/index? Would the xpub ckd range also be possible to describe?
 28 2018-06-01 06:53:49	0|sipa|yes, it needs to be
 29 2018-06-01 06:54:01	0|jonasschnelli|What is "(c) watchonly or not"?
 30 2018-06-01 06:54:07	0|sipa|jonasschnelli: read my.gist
 31 2018-06-01 06:54:16	0|sipa|i've linked to it many times :)
 32 2018-06-01 06:54:30	0|jonasschnelli|heh.. okay. I shoud re-read you wallet gist, yes.
 33 2018-06-01 06:55:07	0|jonasschnelli|We should that probably stick to the channel topic. :)
 34 2018-06-01 06:55:07	0|sipa|jonasschnelli: the idea is that watchonly should not be tied to whether or not you happen to ha e the private key
 35 2018-06-01 06:55:29	0|jonasschnelli|hmm...
 36 2018-06-01 06:55:52	0|jonasschnelli|But I guess senseless for primitive scripts like P2WPKH?
 37 2018-06-01 06:55:58	0|sipa|no
 38 2018-06-01 06:56:09	0|sipa|for example if your private key is in a hardware wallet
 39 2018-06-01 06:56:16	0|sipa|that shouldn't be treated as watchonly
 40 2018-06-01 06:56:18	0|sipa|it is yours
 41 2018-06-01 06:56:40	0|jonasschnelli|Aha... you look at it from an overall perspective... I was looking from a pure "wallet" perspective
 42 2018-06-01 06:56:42	0|sipa|watchonly is for multisig things that you participate in, but don't want counted towards your balance
 43 2018-06-01 06:57:18	0|sipa|so my view is that private key or not should be independent from "counted towards balance" ("watch only") or not
 44 2018-06-01 06:57:32	0|jonasschnelli|So then there would be 3 categories, hot keys (default), non-private-key-keys (HWW) and watch only?
 45 2018-06-01 06:58:26	0|sipa|no, there are "yours" records and "non-yours records" ("watch only")
 46 2018-06-01 06:58:49	0|jonasschnelli|When I did a primitive PoC with Core and the Bitbox, I came to the conclusion that three categories may make sense...
 47 2018-06-01 06:58:49	0|sipa|in addition, you have private keys... in various places; some can be in your wallet, some are not
 48 2018-06-01 06:59:03	0|sipa|the wallet should not care about whether it has the private key or not
 49 2018-06-01 06:59:07	0|jonasschnelli|But since multiwallet, this is no longer necesarry I gues
 50 2018-06-01 06:59:10	0|jonasschnelli|*s
 51 2018-06-01 06:59:19	0|sipa|please, read my gist :)
 52 2018-06-01 06:59:32	0|jonasschnelli|Yes. I see. Makes sense to me...
 53 2018-06-01 06:59:43	0|jonasschnelli|Yes. I should read your gist every morning...
 54 2018-06-01 06:59:48	0|jonasschnelli|amen. :)
 55 2018-06-01 07:33:02	0|fanquake|wumpus got a 6.3 vm setup, will get through those bsd PRs
 56 2018-06-01 07:59:40	0|wumpus|fanquake: great!
 57 2018-06-01 08:04:25	0|fanquake|#13355 fixes running gmake check
 58 2018-06-01 08:04:27	0|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
 59 2018-06-01 08:05:31	0|wumpus|thanks for checking, it seems about time to merge it
 60 2018-06-01 08:08:37	0|bitcoin-git|13bitcoin/06master 14db56755 15practicalswift: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling
 61 2018-06-01 08:08:37	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/87a9d03c0c1e...0b1c0c462eda
 62 2018-06-01 08:08:38	0|bitcoin-git|13bitcoin/06master 140b1c0c4 15Wladimir J. van der Laan: Merge #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling...
 63 2018-06-01 08:09:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (06master...06openbsd-gmake-check) 02https://github.com/bitcoin/bitcoin/pull/13355
 64 2018-06-01 08:09:32	0|fanquake|Obviously 13294 was submitted without running any tests, seeing as they would have been broken at the time.. ? Bit scary given the changes
 65 2018-06-01 08:11:07	0|aaa_|join
 66 2018-06-01 08:11:10	0|aaa_|??
 67 2018-06-01 08:11:33	0|Guest15263|11111
 68 2018-06-01 08:12:05	0|Guest15263|31232321
 69 2018-06-01 08:12:07	0|Guest15263|ad
 70 2018-06-01 08:12:07	0|Guest15263|adad
 71 2018-06-01 08:12:07	0|Guest15263|d
 72 2018-06-01 08:12:07	0|Guest15263|d
 73 2018-06-01 08:12:08	0|Guest15263|d
 74 2018-06-01 08:12:08	0|Guest15263|d
 75 2018-06-01 08:12:08	0|Guest15263|d
 76 2018-06-01 08:12:08	0|Guest15263|d
 77 2018-06-01 08:12:09	0|Guest15263|d
 78 2018-06-01 08:12:09	0|Guest15263|d
 79 2018-06-01 08:12:10	0|Guest15263|d
 80 2018-06-01 08:12:10	0|Guest15263|d
 81 2018-06-01 08:12:11	0|Guest15263|d
 82 2018-06-01 08:12:14	0|fanquake|Please stop.
 83 2018-06-01 08:13:34	0|Guest15263|Why no one speaks?Is this a bitcore channel?
 84 2018-06-01 08:14:24	0|fanquake|This channel is for Core Development discussion. Generally there are always hundreds of people idling/watching. Actually discussion happens sporadically.
 85 2018-06-01 08:14:52	0|fanquake|*actual
 86 2018-06-01 08:15:42	0|Guest15263|soga
 87 2018-06-01 08:25:07	0|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.
 88 2018-06-01 08:25:10	0|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
 89 2018-06-01 08:28:03	0|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.
 90 2018-06-01 08:29:48	0|wumpus|I mean at least in #13349 I also solved an issue, while removing the warning.
 91 2018-06-01 08:29:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/13349 | bench: Dont return a bool from main by laanwj · Pull Request #13349 · bitcoin/bitcoin · GitHub
 92 2018-06-01 08:31:30	0|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.
 93 2018-06-01 08:31:40	0|fanquake|That feels like exactly the kind of place you'd subtly break something.
 94 2018-06-01 08:32:36	0|wumpus|woule be a very bad place to break something too, and hard todetect
 95 2018-06-01 08:46:12	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0b1c0c462eda...343d4e44ef4d
 96 2018-06-01 08:46:13	0|bitcoin-git|13bitcoin/06master 1432167e8 15John Newbery: [wallet] [tests] Add tests for `createwallet` RPC.
 97 2018-06-01 08:46:13	0|bitcoin-git|13bitcoin/06master 149421317 15John Newbery: [wallet] [rpc] Add `createwallet` RPC...
 98 2018-06-01 08:46:14	0|bitcoin-git|13bitcoin/06master 14f7e153e 15John Newbery: [wallets] [docs] Add release notes for createwallet RPC.
 99 2018-06-01 08:46:45	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #13058: [wallet] `createwallet` RPC - create new wallet at runtime (06master...06create_wallet) 02https://github.com/bitcoin/bitcoin/pull/13058
100 2018-06-01 08:51:46	0|fanquake|wumpus #13353 looks ok
101 2018-06-01 08:51:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/13353 | qa: Fixup setting of PATH env var by MarcoFalke · Pull Request #13353 · bitcoin/bitcoin · GitHub
102 2018-06-01 09:03:59	0|wumpus|yes
103 2018-06-01 09:04:10	0|bitcoin-git|13bitcoin/06master 14fa26cf0 15MarcoFalke: qa: Fixup setting of PATH env var
104 2018-06-01 09:04:10	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/343d4e44ef4d...d4f6dac9abf8
105 2018-06-01 09:04:11	0|bitcoin-git|13bitcoin/06master 14d4f6dac 15Wladimir J. van der Laan: Merge #13353: qa: Fixup setting of PATH env var...
106 2018-06-01 09:05:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13353: qa: Fixup setting of PATH env var (06master...06Mf1806-qaPathBitcoind) 02https://github.com/bitcoin/bitcoin/pull/13353
107 2018-06-01 09:15:10	0|kewde[m]|https://github.com/bitcoin/bitcoin/blob/0.16/src/qt/locale/bitcoin_ru.ts#L65
108 2018-06-01 09:15:40	0|kewde[m]|What a weird translation - seems like the Russian language is adopting bitcoin addresses as new vocabulary.
109 2018-06-01 09:16:12	0|wumpus|kewde[m]: yuck
110 2018-06-01 09:16:29	0|fanquake|kewde[m] heh. Could you report it upstream? https://www.transifex.com/bitcoin/bitcoin/
111 2018-06-01 09:16:31	0|wumpus|kewde[m]: thanks for noticing
112 2018-06-01 09:16:43	0|wumpus|fanquake: I'm just going to nuke the message
113 2018-06-01 09:16:50	0|wumpus|(on transfex)
114 2018-06-01 09:16:56	0|fanquake|wumpus np
115 2018-06-01 09:17:04	0|kewde[m]|I can't take credit for noticing it - just passing along the message.
116 2018-06-01 09:17:27	0|wumpus|good that it was caught in a rc at least
117 2018-06-01 09:18:26	0|wumpus|fanquake: maybe delete the entire Russian translation to teach them a lesson :p
118 2018-06-01 09:18:33	0|kewde[m]|https://insight.bitpay.com/address/12Ny5wkrQ5d5bVk2LANAx5R3wcMT9HLFz9
119 2018-06-01 09:19:08	0|fanquake|wumpus heh, poor translators
120 2018-06-01 09:19:41	0|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.
121 2018-06-01 09:20:10	0|kewde[m]|It hasn't received any funds recently - but there is a tx from 2017 O_o
122 2018-06-01 09:21:00	0|wumpus|kewde[m]: bizarre
123 2018-06-01 09:23:49	0|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.
124 2018-06-01 09:24:38	0|wumpus|looks like they did no other damage at least in RU
125 2018-06-01 09:27:05	0|fanquake|wumpus good to know
126 2018-06-01 09:27:16	0|fanquake|I'm heading out, will get some more review done tomorrow.
127 2018-06-01 09:37:15	0|bitcoin-git|13bitcoin/060.16 144ea3e8e 15Wladimir J. van der Laan: qt: Periodic translations update...
128 2018-06-01 09:37:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.16: 02https://github.com/bitcoin/bitcoin/commit/4ea3e8ef070417ccc22007407d78fa0a41949bee
129 2018-06-01 09:38:25	0|wumpus|the address will be gone in next rc
130 2018-06-01 09:41:46	0|wumpus|created issue #13363
131 2018-06-01 09:41:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/13363 | Make update-translations.py script check for (valid) bitcoin addresses · Issue #13363 · bitcoin/bitcoin · GitHub
132 2018-06-01 09:42:57	0|wumpus|(might have a stab at this myself later, but if someone else wants to, you're very welcome)
133 2018-06-01 10:29:22	0|bitcoin-git|[13bitcoin] 15mess110 opened pull request #13364: update transifex doc links (06master...06fix_transifex_client_config_link) 02https://github.com/bitcoin/bitcoin/pull/13364
134 2018-06-01 11:04:24	0|mess110|hi
135 2018-06-01 11:04:56	0|mess110|can I please get a rebuild for https://github.com/bitcoin/bitcoin/pull/13364 ? I updated some doc links but some test failed
136 2018-06-01 12:00:05	0|wumpus|mess110: I've triggered the failed build
137 2018-06-01 12:00:47	0|wumpus|going to merge #13352 as it's anoying that travis fails all the time
138 2018-06-01 12:00:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/13352 | qa: Avoid checking reject code for now by MarcoFalke · Pull Request #13352 · bitcoin/bitcoin · GitHub
139 2018-06-01 12:02:32	0|bitcoin-git|13bitcoin/06master 14faac7a2 15MarcoFalke: qa: Avoid checking reject code for now...
140 2018-06-01 12:02:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d4f6dac9abf8...e24bf1ce184b
141 2018-06-01 12:02:33	0|bitcoin-git|13bitcoin/06master 14e24bf1c 15Wladimir J. van der Laan: Merge #13352: qa: Avoid checking reject code for now...
142 2018-06-01 12:03:15	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13352: qa: Avoid checking reject code for now (06master...06Mf1806-qaRejectCode) 02https://github.com/bitcoin/bitcoin/pull/13352
143 2018-06-01 12:06:26	0|bitcoin-git|[13bitcoin] 15yuntai opened pull request #13365: RPC/REST/ZMQ: Set label with importprivkey only requested. #13087 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/13365
144 2018-06-01 12:54:28	0|bitcoin-git|[13bitcoin] 15giulio92 opened pull request #13366: Docs: Rename “OS X” to the newer “macOS” convention (06master...06osx-renaming) 02https://github.com/bitcoin/bitcoin/pull/13366
145 2018-06-01 13:13:05	0|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/..."?
146 2018-06-01 13:14:25	0|jonasschnelli|pub/xpub is autodetect, first char r | b | w | p is for (r)ange, (b)irthday, (w)atchonly, (p)rivatekey
147 2018-06-01 13:15:54	0|jonasschnelli|we could avoid the first "key-char" and detect the type an the length and characteristics (8byte int == birthday, <num>–<num> == range, etc.)
148 2018-06-01 13:16:09	0|jonasschnelli|But it smells after voodoo... so unsure
149 2018-06-01 13:30:16	0|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!
150 2018-06-01 13:35:57	0|jonasschnelli|gojo: no jobs here...
151 2018-06-01 13:48:00	0|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.
152 2018-06-01 13:48:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/12511 | Switch to Ubuntu 18.04 for gitian building · Issue #12511 · bitcoin/bitcoin · GitHub
153 2018-06-01 14:24:31	0|wumpus|I've made a start with the addrv2 BIP spec: https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1
154 2018-06-01 14:40:38	0|jonasschnelli|wumpus: nice.
155 2018-06-01 14:40:49	0|jonasschnelli|I like the backward compatible way (only >128bit use v2)
156 2018-06-01 14:41:15	0|jonasschnelli|Not sure about the name addrv2 (versioning of protocol commands)
157 2018-06-01 14:41:31	0|jonasschnelli|or it should be something like addr32
158 2018-06-01 14:43:19	0|wumpus|yes the name is completely contingent, I don't care
159 2018-06-01 14:43:53	0|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
160 2018-06-01 14:44:28	0|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
161 2018-06-01 14:44:36	0|jonasschnelli|Yes. It is a cleaner cut
162 2018-06-01 14:45:27	0|wumpus|we could even *not* rename the message, with the new protocol version, but that introduces some fragility I'm not happy with
163 2018-06-01 14:46:52	0|jonasschnelli|I guess using a varint for services is probably an unnecessary optimization? It would save 33% for a IPv4 addr
164 2018-06-01 14:47:02	0|jonasschnelli|(with the current used service bits)
165 2018-06-01 14:47:08	0|jonasschnelli|AFAIK
166 2018-06-01 14:47:56	0|jonasschnelli|wumpus: I guess not using a new command would probably make a lot of stupid light clients crash. :)
167 2018-06-01 14:48:31	0|wumpus|jonasschnelli: that's an interesting proposal
168 2018-06-01 14:48:56	0|wumpus|jonasschnelli: I like it, don't see a reason why not
169 2018-06-01 14:49:26	0|jonasschnelli|Yes. I think its worth it.
170 2018-06-01 14:49:34	0|wumpus|jonasschnelli: even beter, it's future-proof
171 2018-06-01 14:49:39	0|jonasschnelli|Especially since the addrv2 is already varlen
172 2018-06-01 14:49:43	0|wumpus|(I guess, in a way)
173 2018-06-01 14:50:01	0|jonasschnelli|>8byte service bits?!... not sure if we ever reach that limit :)
174 2018-06-01 14:50:09	0|wumpus|yes, decided on varlen because padding everything to 32 bytes would be crazy, and I like not wasting space for v4 addresses
175 2018-06-01 14:50:21	0|jonasschnelli|Yes. Good point.
176 2018-06-01 14:51:00	0|jonasschnelli|Another redundant byte is the std::vector<uint8_t> varlen byte
177 2018-06-01 14:51:15	0|jonasschnelli|But I guess that serialization property we can't change
178 2018-06-01 14:51:54	0|jonasschnelli|(since the length is indirectly defined by the networkID)
179 2018-06-01 15:04:23	0|luke-jr|wumpus: it might be a good idea to include port in addr
180 2018-06-01 15:04:43	0|luke-jr|hidden services don't have ports IIRC, and non-TCP protocols might not either -  or might have 64-bit ports or smth
181 2018-06-01 15:05:39	0|luke-jr|32-bit times seem to be dying, but we probably will end up with a new addr message before 2038 I guess
182 2018-06-01 15:05:53	0|luke-jr|especially if services isn't revised now
183 2018-06-01 15:06:20	0|jonasschnelli|makes sense to me: putting port into the addr part
184 2018-06-01 15:12:34	0|wumpus|hidden services have ports
185 2018-06-01 15:12:49	0|wumpus|luke-jr: we could use a VARINT for the time too
186 2018-06-01 15:14:49	0|wumpus|luke-jr: another option would be to lower precision
187 2018-06-01 15:15:02	0|luke-jr|hmm
188 2018-06-01 15:15:04	0|luke-jr|or both
189 2018-06-01 15:15:30	0|luke-jr|epoch 2009 with 1 hour resolution seems plenty
190 2018-06-01 15:16:15	0|luke-jr|or 90 minutes to be tonal-correct :D
191 2018-06-01 15:18:05	0|wumpus|luke-jr: jonasschnelli: changed them both to VARINT, thanks for the comments
192 2018-06-01 15:23:28	0|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
193 2018-06-01 15:28:39	0|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
194 2018-06-01 15:29:07	0|luke-jr|and unsigned 32-bit time is actually even 2106, not 2038
195 2018-06-01 15:30:56	0|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
196 2018-06-01 15:49:25	0|gmaxwell|wumpus: cool!
197 2018-06-01 15:51:08	0|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.
198 2018-06-01 15:52:20	0|luke-jr|I think that's the goal
199 2018-06-01 15:53:02	0|gmaxwell|oh nevermind I see there is a section, don't see how I missed it on the first pass.
200 2018-06-01 15:54:54	0|wumpus|gmaxwell: yep - I2P is 256 bits
201 2018-06-01 15:56:12	0|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)
202 2018-06-01 15:56:20	0|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?
203 2018-06-01 15:56:34	0|gmaxwell|yes, I like strict length checking too.
204 2018-06-01 15:57:18	0|gmaxwell|wumpus: so would we want to addrv3 for those things, user service bits, or add some opional field mechenism(s)?
205 2018-06-01 15:57:36	0|luke-jr|gmaxwell: services currently apply an | to the bits, so not useful for multi-bit stuff sadly
206 2018-06-01 15:57:37	0|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
207 2018-06-01 15:58:01	0|wumpus|e.g. gossiping block ranges directly would not be useful as the information is outdated by time someone gets it
208 2018-06-01 15:58:23	0|luke-jr|wumpus: just a seed that nodes can deterministically calculate block numbers from
209 2018-06-01 15:58:26	0|gmaxwell|wumpus: these wouldn't be outdated by construction.
210 2018-06-01 15:58:30	0|gmaxwell|as luke-jr says.
211 2018-06-01 15:58:36	0|wumpus|but if it's some other kind of descriptor, sure, it could be added
212 2018-06-01 15:58:39	0|gmaxwell|(also, FEC slice proposals don't have that issue)
213 2018-06-01 15:58:43	0|wumpus|how many bits per address?
214 2018-06-01 15:59:22	0|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" ?
215 2018-06-01 15:59:27	0|luke-jr|there might be a fingerprinting risk here with too many bits, but too few might be an issue for storage too
216 2018-06-01 15:59:32	0|wumpus|an optional field mechanism could work, but otoh, I'm a bit afraid of overdesign (also: it still has to be bounded)
217 2018-06-01 15:59:49	0|gmaxwell|luke-jr: yes but leave that problem to the other proposals.
218 2018-06-01 16:00:16	0|luke-jr|ah, true
219 2018-06-01 16:00:44	0|wumpus|ah, an optional 32-bit field per service bit?
220 2018-06-01 16:01:28	0|luke-jr|then I can make a 2k addr message.. :/
221 2018-06-01 16:01:32	0|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).
222 2018-06-01 16:02:02	0|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".
223 2018-06-01 16:02:20	0|gmaxwell|(e.g. just to take specifying its content out of scope for this BIP)
224 2018-06-01 16:03:42	0|gmaxwell|having a field per service bit would be nice but unfortunately would allow huge messages.
225 2018-06-01 16:05:52	0|luke-jr|I suppose nodes could policy-drop the extra data if they don't comprehend it?
226 2018-06-01 16:06:04	0|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?
227 2018-06-01 16:06:39	0|gmaxwell|luke-jr: then you need a mechenism to encode which extra data is there.
228 2018-06-01 16:06:52	0|luke-jr|gmaxwell: you need that anyway if it's optional?
229 2018-06-01 16:07:21	0|luke-jr|and it wouldn't make sense to have extra data for most of the current service bits
230 2018-06-01 16:07:35	0|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. :)
231 2018-06-01 16:09:47	0|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.
232 2018-06-01 16:10:12	0|gmaxwell|And then define nodes should strip ones they don't understand.
233 2018-06-01 16:10:23	0|gmaxwell|or something along those lines.
234 2018-06-01 16:11:21	0|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
235 2018-06-01 16:11:25	0|gmaxwell|If that kind of mechenism existed there might be less argument to make service flags anything but 32 bits?
236 2018-06-01 16:12:03	0|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.
237 2018-06-01 16:12:04	0|wumpus|gmaxwell: at least currently all the mechanisms have a concept of port
238 2018-06-01 16:13:10	0|gmaxwell|My memory of I2P is really bad then.
239 2018-06-01 16:13:17	0|wumpus|32 bits "depending on the service bits" would be ok, although it leaves some difficulty if multiple service bits want to use it
240 2018-06-01 16:14:24	0|wumpus|same here, I intend to run this by one of the I2P devs before publishing it anyhow
241 2018-06-01 16:15:25	0|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.
242 2018-06-01 16:15:39	0|gmaxwell|but I'm sure we could come up with other ones.
243 2018-06-01 16:16:39	0|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.
244 2018-06-01 16:17:11	0|wumpus|we already send multiple addr messages when listening to multiple interfaces
245 2018-06-01 16:18:33	0|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
246 2018-06-01 16:18:37	0|gmaxwell|yes though it would be really inefficient if almost every node were doing it.
247 2018-06-01 16:18:53	0|gmaxwell|(sending a whole seperate addr just to give another 16 bit port number)
248 2018-06-01 16:19:04	0|wumpus|yes
249 2018-06-01 16:22:11	0|wumpus|there's risk of combinatorial blowup there
250 2018-06-01 16:22:30	0|wumpus|that's a good argument for encoding the port separately though
251 2018-06-01 16:22:49	0|wumpus|that extends better to having multiple ports
252 2018-06-01 16:23:02	0|gmaxwell|one could use the above mechenism of a <type/length> byte followed by payload to do the port.
253 2018-06-01 16:23:36	0|wumpus|yes
254 2018-06-01 16:25:39	0|wumpus|that's a good idea, I think
255 2018-06-01 16:26:23	0|wumpus|though it increases the average size, port is only 2 bytes, making it a 'data item' will by definition be larger
256 2018-06-01 16:27:19	0|gmaxwell|Yes, though it's two bytes overhead assuming you used my above suggestion and had no other data items.
257 2018-06-01 16:27:40	0|gmaxwell|One byte overhead if you had other data items.
258 2018-06-01 16:27:59	0|wumpus|true, I just mean in practice, everything will be sending a port
259 2018-06-01 16:28:06	0|gmaxwell|And I think if the data item mechenism existed service bits could stay 32 bits, saving a byte.
260 2018-06-01 16:29:05	0|gmaxwell|or you keep the port field (or merge into the variable length addresses) for the primary port to get that savings.
261 2018-06-01 16:29:30	0|wumpus|aren't service bits 64 bits right now?
262 2018-06-01 16:29:48	0|gmaxwell|oh. hm! I thought they were 32bits!
263 2018-06-01 16:30:00	0|gmaxwell|nope, 64.
264 2018-06-01 16:30:05	0|wumpus|I thought so too yesterday
265 2018-06-01 16:30:26	0|wumpus|that's why Jonas proposed turning it into a VARINT, which I did
266 2018-06-01 16:31:41	0|sipa|they're 64 bits now
267 2018-06-01 16:35:20	0|wumpus|I wonder if CJDNS should get its own network id, the reason I'm not sure is because they're explicitly IPv6 addresses
268 2018-06-01 16:37:43	0|gmaxwell|I suspect it should, since you can't reach them unless you use CJDNS? so it's like onion embedded tor?
269 2018-06-01 16:39:43	0|sipa|yeah, i good criterion for separate networks would be whether they need separate routing
270 2018-06-01 16:40:28	0|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.
271 2018-06-01 16:40:56	0|wumpus|so yes, better to just add a n ID, they're cheap
272 2018-06-01 17:25:49	0|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)
273 2018-06-01 17:27:54	0|gmaxwell|ah, just don't onioncat embed them. that would be nice.  though who cares much about tor v2.
274 2018-06-01 17:30:02	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13367: qa: Increase includeconf test coverage (06master...06Mf1806-qaIncludeconf) 02https://github.com/bitcoin/bitcoin/pull/13367
275 2018-06-01 17:30:49	0|gmaxwell|I assume that within a couple years we'll stop forwarding torv2 completely.
276 2018-06-01 17:35:12	0|sipa|wumpus: for simplicity, i think it makes sense to put tor v2 in a separate class
277 2018-06-01 17:35:17	0|sipa|it needs separate routing after all
278 2018-06-01 17:35:51	0|wumpus|sipa: that's what I've done, I just kept the onioncat wrapping (so addresses are 16 bytes not 10)
279 2018-06-01 17:36:27	0|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
280 2018-06-01 17:36:47	0|sipa|wumpus: sorry, i should read first
281 2018-06-01 18:07:30	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #13368: Update gitian-build.sh for docker (06master...06gitian-docker) 02https://github.com/bitcoin/bitcoin/pull/13368
282 2018-06-01 18:24:27	0|bitcoin-git|[13bitcoin] 15mess110 closed pull request #13364: update transifex doc links (06master...06fix_transifex_client_config_link) 02https://github.com/bitcoin/bitcoin/pull/13364
283 2018-06-01 18:27:32	0|bitcoin-git|[13bitcoin] 15mess110 opened pull request #13369: [docs] update transifex doc link (06master...06fix_transifex_doc_link) 02https://github.com/bitcoin/bitcoin/pull/13369
284 2018-06-01 18:30:01	0|echeveria|wumpus: cjd is pretty much exclusively ipv6 in their own range.
285 2018-06-01 18:30:26	0|echeveria|it's really kind of its own net because you can't reach any of the peers any other way.
286 2018-06-01 18:32:51	0|wumpus|echeveria: indeed, there are no 'exit nodes'
287 2018-06-01 19:19:12	0|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.
288 2018-06-01 19:20:01	0|gmaxwell|and so sipa's PR drops HB relay about 5ms per hop, which is a pretty large fraction of the total processing time.
289 2018-06-01 21:45:56	0|sipa|wumpus: thanks, read the BIP draft now
290 2018-06-01 21:46:38	0|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 )
291 2018-06-01 21:47:07	0|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
292 2018-06-01 21:51:43	0|promag|should unloadwallet PR include UI support so that unloaded wallets are removed?
293 2018-06-01 21:56:57	0|gojo|What tools you are using for debug view uint256?
294 2018-06-01 21:58:32	0|sipa|it has a GetHex() method for converting to a string
295 2018-06-01 22:00:12	0|gojo|I mean inside gdb UI
296 2018-06-01 22:00:37	0|gojo|i use GetHex() method for debug txdb my fork bugs
297 2018-06-01 22:01:22	0|gojo|I join my own live logging tool for structured logs for fix complex bugs
298 2018-06-01 22:01:36	0|gojo|I can share my code if needed
299 2018-06-01 22:03:05	0|gojo|I looking for another way with gdbgui React debug widget
300 2018-06-01 22:03:53	0|sipa|print pindexBestHeader->phashBlock->GetHex()
301 2018-06-01 22:04:09	0|sipa|$3 = '0' <repeats 18 times>, "2521d8eb85294864f937918dcbdcc33f42ab0c55c5d5b9"
302 2018-06-01 22:05:20	0|gojo|Not very optimal with hidden bugs in 100k blocks. I'm looking for something more easy
303 2018-06-01 22:05:32	0|sipa|i'm not sure what you're asking for
304 2018-06-01 22:06:22	0|gojo|1. gdb vars view is wrong for uint256
305 2018-06-01 22:06:54	0|gojo|2. gdbgui require React dev for uint256, reason, but not much time for that
306 2018-06-01 22:07:15	0|sipa|i don't understand that
307 2018-06-01 22:07:26	0|sipa|what is react?
308 2018-06-01 22:07:32	0|gojo|3. my own logging solution is very slow when txdb has bug in 100k+ blocks
309 2018-06-01 22:07:46	0|gojo|do you know gdbgui?
310 2018-06-01 22:07:48	0|sipa|no
311 2018-06-01 22:08:04	0|gojo|https://github.com/cs01/gdbgui
312 2018-06-01 22:08:18	0|sipa|but what are you trying to achieve?
313 2018-06-01 22:08:33	0|gojo|well customized browser frontend for gdb
314 2018-06-01 22:08:51	0|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())
315 2018-06-01 22:08:53	0|gojo|i need for debug my fork step by step each line for 100k blocks
316 2018-06-01 22:09:02	0|sipa|good luck then
317 2018-06-01 22:09:14	0|gojo|thanks
318 2018-06-01 22:09:35	0|gojo|i'm have solution that maybe helps someone
319 2018-06-01 22:10:06	0|gojo|i made several forks for Dash, Komodo etc
320 2018-06-01 22:10:14	0|sipa|off topic here
321 2018-06-01 22:10:29	0|gojo|btc-core is not offtopic
322 2018-06-01 22:10:41	0|gojo|i have a logging system for bitcoin-core
323 2018-06-01 22:10:51	0|gojo|i want to share it for made life easier
324 2018-06-01 22:10:55	0|sipa|ok
325 2018-06-01 22:11:07	0|gojo|but maybe someone has better solution
326 2018-06-01 22:11:17	0|sipa|feel free to open a pull request to improve logging, if you have useful code
327 2018-06-01 22:11:21	0|sipa|that sounds very welcome
328 2018-06-01 22:12:24	0|gojo|ok, understand, thanks