1 2018-05-31 00:36:49	0|MarcoFalke|sipa: Yes, see #13171
  2 2018-05-31 00:36:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/13171 | [WIP] Change gitian-descriptors to use bionic instead by ken2812221 · Pull Request #13171 · bitcoin/bitcoin · GitHub
  3 2018-05-31 00:37:06	0|sipa|ah, yes!
  4 2018-05-31 00:37:07	0|sipa|thanks
  5 2018-05-31 00:37:14	0|sipa|so, c++14 soon? ;)
  6 2018-05-31 00:37:31	0|sipa|i'll bring it up in the meeting
  7 2018-05-31 04:57:46	0|mryandao|looking at removing boost::chronos, would there be any downsides to unifying all the usage of GetTimeMillis/Micros to just std::chronos::nanoseconds instead?
  8 2018-05-31 04:58:30	0|mryandao|and also changing int64_t types for time to std::chronos::nanoseconds for better semantics
  9 2018-05-31 05:00:44	0|mryandao|in the TODO, it did ask for a typesafe type, so I'm guessing the usage of chronos::nanoseconds would kill all birds in 1 stone?
 10 2018-05-31 05:10:03	0|sipa|kallewoof: not all that much; c++14 is mostly seen as a small fixup/extension of the things added in 11
 11 2018-05-31 05:10:15	0|sipa|better constexpr, better auto, better lambdas
 12 2018-05-31 05:24:28	0|kallewoof|sipa: Yeah I just read through a summary. Not really important but 0b is nice :)
 13 2018-05-31 05:24:48	0|kallewoof|And better auto/lambda looks nice yeah.
 14 2018-05-31 06:02:32	0|fanquake|mryandao If you haven't see already cfields has been working on that as well https://github.com/bitcoin/bitcoin/pull/9566
 15 2018-05-31 06:05:44	0|fanquake|wumpus very trendy code :p
 16 2018-05-31 06:12:47	0|wumpus|fanquake: thanks :p
 17 2018-05-31 06:13:30	0|wumpus|(let's try again...)
 18 2018-05-31 06:17:19	0|wumpus|#13337 is strange, did OpenBSD 5.3 really break grep somehow?
 19 2018-05-31 06:17:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/13337 | OpenBSD 6.3 build: test/arith_uint256_tests.cpp complains about missing argument · Issue #13337 · bitcoin/bitcoin · GitHub
 20 2018-05-31 06:17:32	0|wumpus|s/5.3/6.3
 21 2018-05-31 06:18:25	0|wumpus|kallewoof feels the need to to read up on what's new in c++14 <- I'm not over the c++11 future-shock yet
 22 2018-05-31 06:20:07	0|sipa|wumpus: ha
 23 2018-05-31 06:20:14	0|wumpus|sipa: to be serious, I guess the main thing I'd like to know is - how does this shift the set of linux distributions it's possible to build on. The embedded developer in me balks a bit at requiring ever more recent compilers.
 24 2018-05-31 06:20:22	0|fanquake|wumpus I thought practicalswift had tested on 6.3, #13294, thought they might have picked that up?
 25 2018-05-31 06:20:24	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
 26 2018-05-31 06:20:53	0|fanquake|Also looks like arowser_ still needs blocking
 27 2018-05-31 06:21:21	0|sipa|wumpus: gcc 5 or clang 3.4, which is in ubuntu 16.04
 28 2018-05-31 06:21:27	0|mryandao|there's a ##fix_your_connection ban redirection so the user gets informed to fix their connection
 29 2018-05-31 06:21:40	0|mryandao|the mods in #bitcoin do that.
 30 2018-05-31 06:21:50	0|wumpus|sipa: but what about debian :(
 31 2018-05-31 06:21:52	0|sipa|wumpus: on the other hand - c++14 doesn't add all that much either
 32 2018-05-31 06:22:34	0|wumpus|sipa: something we could do that is almost completely uncontroversial is: use c++14 features when avilable, fall back to something else otherwise
 33 2018-05-31 06:22:36	0|sipa|sigh... debian only has gcc 5 in unstande :(
 34 2018-05-31 06:22:41	0|sipa|*unstable
 35 2018-05-31 06:22:46	0|wumpus|not *require* it
 36 2018-05-31 06:23:08	0|sipa|debian jessie has clang 3.4 though
 37 2018-05-31 06:23:08	0|wumpus|could always drop support for c++11 only compilers at some point later
 38 2018-05-31 06:23:55	0|wumpus|and could be as simple as removing some ifdef-ed code
 39 2018-05-31 06:24:22	0|wumpus|fanquake: we should ask him if he ran 'gmake check'
 40 2018-05-31 06:24:37	0|sipa|wumpus: seems almost not worth it
 41 2018-05-31 06:24:49	0|fanquake|wumpus Can do
 42 2018-05-31 06:27:15	0|wumpus|bumping the required compiler versions should have a very good motivation, such as 'clearly safer, easier to review code', 'potential better perfromance'. for c++11 this was clear at least.
 43 2018-05-31 06:27:41	0|sipa|yes, i agree - i didn't expect it would hurt debian so much
 44 2018-05-31 06:27:55	0|fanquake|Have we ever bumped before. I think we've just defined minimums?
 45 2018-05-31 06:28:03	0|fanquake|*fairly recently
 46 2018-05-31 06:28:19	0|sipa|the switch to c++11 made us require gcc 4.7
 47 2018-05-31 06:29:19	0|wumpus|yep, and there were complaints about users about that
 48 2018-05-31 06:29:20	0|fanquake|4.8+ i think?
 49 2018-05-31 06:29:23	0|wumpus|from users
 50 2018-05-31 06:29:58	0|fanquake|#11732
 51 2018-05-31 06:29:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/11732 | RFC: bump GCC requirement to 4.8 · Issue #11732 · bitcoin/bitcoin · GitHub
 52 2018-05-31 06:30:08	0|sipa|i think the most useful things in c++14 for us may be support for shared_lock
 53 2018-05-31 06:31:32	0|sipa|oh, no, that's c++17
 54 2018-05-31 06:31:33	0|sipa|pff :)
 55 2018-05-31 06:32:03	0|sipa|wikipedia is wrong!
 56 2018-05-31 06:33:30	0|jonasschnelli|sipa: re https://github.com/bitcoin/bitcoin/pull/12196#discussion_r189396442, did you accidentally left away pubkeys for the API? We have to derive various script types anyways with xpubs, right?
 57 2018-05-31 06:34:20	0|sipa|jonasschnelli: pubkeys are not scripts
 58 2018-05-31 06:34:27	0|sipa|so no
 59 2018-05-31 06:34:37	0|jonasschnelli|But how would xpubs be different?
 60 2018-05-31 06:34:54	0|jonasschnelli|If we accept xpubs, whats the rational not not accept pubkeys?
 61 2018-05-31 06:35:00	0|sipa|ah, sorry
 62 2018-05-31 06:35:13	0|jonasschnelli|Either we derive different script types or not I guess
 63 2018-05-31 06:35:16	0|sipa|you could have xpub+derivation type, or pub+derivation type, or script, or address
 64 2018-05-31 06:35:41	0|jonasschnelli|so avoid to derive various types,... yeah. makes sense.
 65 2018-05-31 06:35:52	0|jonasschnelli|Could accept n derivation types per pubkey
 66 2018-05-31 06:35:53	0|sipa|jonasschnelli: you want me to write up a prototype of what that could look like?
 67 2018-05-31 06:35:58	0|sipa|i've been wanting to do that for a while
 68 2018-05-31 06:36:12	0|jonasschnelli|sipa: Please do if you want,.. i'm currently rewriting the API
 69 2018-05-31 06:38:16	0|sipa|wumpus: ah, i'm wrong... c++14 has shared_lock and shared_timed_mutex; c++17 adds shared_mutex
 70 2018-05-31 06:38:36	0|jonasschnelli|I would say [ {"address": <addr>, "pubkey" : { "pubkey" : <pubkey>, "derivation": ["P2PKH", "P2SH-P2WPKH", ...]}, "script" : <script>, "xpub" : { "xpub" : <xpub>,  "derivation":  [], "lookupwindow": [0, 1000]}, [...]}
 71 2018-05-31 06:38:49	0|jonasschnelli|(hard to read JSON on IRC)
 72 2018-05-31 06:39:30	0|sipa|jonasschnelli: also needs birthdate, ranges, ...
 73 2018-05-31 06:39:57	0|wumpus|sipa: it's like boost::shared_mutex?
 74 2018-05-31 06:40:02	0|sipa|wumpus: yup
 75 2018-05-31 06:40:03	0|jonasschnelli|sipa: why birthdate? what ranges? (for other purposes then scantxoutset)?
 76 2018-05-31 06:40:30	0|sipa|jonasschnelli: i guess for scantxoutset birthdates don't matter, but for the wallet they will :)
 77 2018-05-31 06:40:50	0|jonasschnelli|Yes. Ah. I see. You want to specify a generic format.
 78 2018-05-31 06:41:15	0|sipa|jonasschnelli: my goal is making the entire wallet a list of such records (plus private keys, labels) and cached data (transactions, keypools)
 79 2018-05-31 06:41:19	0|jonasschnelli|sipa: do you mean the xpub derive range with "ranges"?
 80 2018-05-31 06:41:27	0|sipa|jonasschnelli: yes
 81 2018-05-31 06:41:42	0|jonasschnelli|okay. The JSON above has the "loopupwindow" 2 size array.
 82 2018-05-31 06:42:42	0|jonasschnelli|Maybe add something to you gist and we can build new RPC APIs (and migrate old ones if possible) according that parameter object.
 83 2018-05-31 06:42:55	0|sipa|will do tomorrow
 84 2018-05-31 06:42:56	0|wumpus|sipa: right, that's useful, didn't know we were already using it in sigcache
 85 2018-05-31 06:43:01	0|jonasschnelli|sure. Thanks!
 86 2018-05-31 06:46:11	0|sipa|wumpus: but not worth breaking building on debian for
 87 2018-05-31 06:47:03	0|wumpus|sipa: I agree. We can already use it from boost. If this turns out to be ever the last point hinging us to boost::thread we could make an optional wrapper allowing boost-less build with a c++14 supporting compiler.
 88 2018-05-31 06:47:13	0|sipa|oh, i misread
 89 2018-05-31 06:47:19	0|sipa|debian stable has gcc 6
 90 2018-05-31 06:48:14	0|wumpus|stable has gcc 6? that sounds unlikely
 91 2018-05-31 06:48:27	0|sipa|https://packages.debian.org/stretch/gcc-6
 92 2018-05-31 06:49:13	0|wumpus|I see. Now I'm confused.
 93 2018-05-31 06:49:49	0|sipa|i was confused by https://packages.debian.org/stretch/gcc having prefix "4:"
 94 2018-05-31 06:49:50	0|wumpus|with debian stable having a more recent compiler than even ubuntu 16.04
 95 2018-05-31 06:50:23	0|sipa|debian stable was released in june 2017
 96 2018-05-31 06:50:42	0|sipa|which is a year after ubuntu 16.04
 97 2018-05-31 06:52:03	0|sipa|jessie, the previous stable has gcc 4.9
 98 2018-05-31 06:52:42	0|wumpus|so a distortion caused by the fact that debian stable was branched relatively recently - interesting, wel lthat seems to remove the biggest obstacle then
 99 2018-05-31 06:56:25	0|wumpus|I don't think I have any others. Let's discuss this at the meeting anyway (I'm interested in hearing cfields's opinion on this too)
100 2018-05-31 07:01:25	0|fanquake|cfields likely to tell us why it can't happen for another few years heh
101 2018-05-31 07:01:35	0|Randolf|I'm using Ubuntu 18.04 LTS on some systems already.  Might it have a more updated compiler?  Or is it the same as 16.04?
102 2018-05-31 07:03:10	0|wumpus|fanquake: cfields and me take turns at being bad cop
103 2018-05-31 07:04:04	0|wumpus|Randolf: 16.04 has "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609", 18.04 has "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0"
104 2018-05-31 07:04:53	0|wumpus|FreeBSD 11.1 has "FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)" that seems like more of a problem
105 2018-05-31 07:05:39	0|wumpus|OpenBSD 5.2 too "OpenBSD clang version 4.0.0 (tags/RELEASE_400/final) (based on LLVM 4.0.0)". What is it with BSDs and their clang4 obessesion.
106 2018-05-31 07:07:10	0|sipa|clang4 has c++14
107 2018-05-31 07:07:12	0|wumpus|<sipa> wumpus: gcc 5 or clang 3.4    ohh
108 2018-05-31 07:07:14	0|wumpus|right.
109 2018-05-31 07:07:36	0|sipa|also, fwiw, our code compiles with c++14 without changes (haven't tested)
110 2018-05-31 07:07:56	0|wumpus|c++14 is consistently older, version-wise, than I expect
111 2018-05-31 07:08:32	0|sipa|so c++11 took ages after standardization before it was available in compilers
112 2018-05-31 07:08:46	0|sipa|c++14 was a small change, and pretty much implemented before the spec was published
113 2018-05-31 07:10:10	0|wumpus|it shows
114 2018-05-31 07:10:39	0|sipa|18 months between c++11 published and gcc fully supporting it
115 2018-05-31 07:11:03	0|sipa|4 months between c++14 published and gcc fully supporting it
116 2018-05-31 07:11:59	0|sipa|c++17 will take longer again (it's already 5 months, and gcc only has experimental support)
117 2018-05-31 07:22:17	0|fanquake|Decent speedups in #13309. Few ACKs if you want to take a look wumpus
118 2018-05-31 07:22:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub
119 2018-05-31 07:30:42	0|wumpus|fanquake: yes I need to have a look at that one, it seemed quite tricky,but agree it's probably worth it
120 2018-05-31 07:31:58	0|wumpus|sipa: running c++14 experiments, on clang 7.0 the build passes with -std=c++14, no changes necessary
121 2018-05-31 07:33:55	0|fanquake|At least we'd only have to bump Clang to 3.4 (from 3.3) for ++14 support
122 2018-05-31 07:34:26	0|wumpus|(that's my straight-from-git build environment though, let's wait for openbsd clang4 results...)
123 2018-05-31 07:46:18	0|wumpus|(passed too)
124 2018-05-31 07:48:15	0|wumpus|fanquake: I wonder if we can get anyone to test with clang/llvm 3.4
125 2018-05-31 07:48:32	0|wumpus|I don't seem to have that installed anywhere
126 2018-05-31 07:49:56	0|wumpus|in an case, this is the trivial build system patch for building with c++14: https://gist.github.com/laanwj/e84d17412a5811ef4b7bd7512218c01a
127 2018-05-31 07:51:07	0|wumpus|building with c++17 does give some errors, last time I tried, although if that support is still experimental it's not clear that should be our problem or the compiler's
128 2018-05-31 07:51:59	0|sipa|configure or compile errors?
129 2018-05-31 07:52:11	0|sipa|that CXX version script does not support c++17 yet
130 2018-05-31 07:52:37	0|wumpus|I had updated that - yes, compile errors
131 2018-05-31 07:58:09	0|wumpus|some fairly silly stuff, I can't find the patch stack right now
132 2018-05-31 08:01:47	0|sipa|well, we're not going to adopt c++17 so who cares
133 2018-05-31 08:02:40	0|wumpus|exactly
134 2018-05-31 08:02:58	0|fanquake|fwiw That's the first error error I see passing in c++17 https://gist.github.com/fanquake/2342c585c43f945428d0f20eb1d8a1d6
135 2018-05-31 08:04:19	0|wumpus|that random_shuffle wasn't even there yet when experimented with c++17 last year
136 2018-05-31 08:05:52	0|fanquake|Looks like it was deprecated, in c++ 14, must have been removed in ++17
137 2018-05-31 08:06:31	0|wumpus|tfw you learn that a function exists in the C++ library and it's already deprecated
138 2018-05-31 08:11:31	0|wumpus|at least it's not as bad as with rust
139 2018-05-31 08:14:52	0|wumpus|(or *cringe* swift... nice that you just wrote this software, here's a new major release of your language, you can basically just throw away everything and start over)
140 2018-05-31 08:15:08	0|fanquake|wumpus your patch + stdcxx m4 changes all that was required to make check with c++14
141 2018-05-31 08:16:05	0|fanquake|Don't bring up swift here, btc dev is one place I don't have to deal with that :p
142 2018-05-31 08:16:17	0|wumpus|sorry
143 2018-05-31 08:17:54	0|wumpus|just trying to put c++ in perspective, that the process they follow for changes is quite reasonable
144 2018-05-31 08:20:24	0|fanquake|Reasonable, but is it really "disruptive/10x/webscale" enough?
145 2018-05-31 08:21:40	0|sipa|we need an deep learning blockchain in the cloud
146 2018-05-31 08:22:09	0|wumpus|fanquake: hah, the kind of words that make you know for sure you want to avoid something
147 2018-05-31 08:23:11	0|wumpus|machine learning developments are going too fast, we need a block chain to anchor them down and make them less efficient
148 2018-05-31 08:24:26	0|fanquake|They'd just figure out how to escape the blockchain. Probably solve the oracle problem while they are at it.
149 2018-05-31 08:26:23	0|wumpus|heh, right, just a matter of the right incentives. If they figure out how to escape the blockchain so we can follow :)
150 2018-05-31 08:31:49	0|bitcoin-git|[13bitcoin] 15practicalswift opened 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
151 2018-05-31 08:33:14	0|wumpus|fanquake: unless I've somehow messed up my methodology, #13309 takes test_bitcoin from 1m10.831s to 0m39.323s here
152 2018-05-31 08:33:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub
153 2018-05-31 08:33:59	0|fanquake|wumpus isn't that what is expected?
154 2018-05-31 08:34:12	0|fanquake|Or just more speed up than you thought?
155 2018-05-31 08:34:27	0|wumpus|it's more than I thought
156 2018-05-31 08:34:48	0|sipa|"sorry, NACK, this makes the tests too fast"
157 2018-05-31 08:35:28	0|wumpus|exactly :)
158 2018-05-31 08:36:50	0|wumpus|just like with cryptography, tests need to be slow to convince it's being done properly
159 2018-05-31 08:39:50	0|bitcoin-git|13bitcoin/06master 146b8b63a 15Martin Ankerl: Generic TransactionSignatureCreator works with both CTransaction and CMutableTransaction...
160 2018-05-31 08:39:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/472fe8a2ce9f...36fc8052f62b
161 2018-05-31 08:39:51	0|bitcoin-git|13bitcoin/06master 1436fc805 15Wladimir J. van der Laan: Merge #13309: Directly operate with CMutableTransaction in SignSignature...
162 2018-05-31 08:40:40	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13309: Directly operate with CMutableTransaction in SignSignature (06master...06SignSignature-with-CMutableTransaction) 02https://github.com/bitcoin/bitcoin/pull/13309
163 2018-05-31 08:46:46	0|fanquake|Opened #13356 for some C++14 thoughts. Will add some more info shortly.
164 2018-05-31 08:46:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub
165 2018-05-31 08:50:28	0|wumpus|fanquake: awesome!
166 2018-05-31 08:54:54	0|wumpus|it's really useful to create tracking issues for things like this
167 2018-05-31 08:56:58	0|fanquake|Yes, easy for useful info to get lost in multiple different discussions
168 2018-05-31 08:57:24	0|fanquake|pkg_add autoconf
169 2018-05-31 08:57:35	0|wumpus|looks like wikipedia has an ok overview of what is new in c++14, maybe useful to link too: https://en.wikipedia.org/wiki/C%2B%2B14, and mention that we already use the shared mutex
170 2018-05-31 09:02:49	0|fanquake|Added. Will link to code soon.
171 2018-05-31 09:08:09	0|wumpus|I vaguely remember there are plans to use more shared mutexes in more places, from BlueMatt probably
172 2018-05-31 09:11:53	0|wumpus|"Tuple addressing via type" some of these have a high risk of obfuscating code when used irresponsibly
173 2018-05-31 09:16:07	0|wumpus|std::exchange and std::make_unique seem nice, small things
174 2018-05-31 09:16:35	0|bitcoin-git|13bitcoin/06master 1424f7011 15MarcoFalke: Merge #13349: bench: Don't return a bool from main...
175 2018-05-31 09:16:35	0|bitcoin-git|13bitcoin/06master 14493a166 15Wladimir J. van der Laan: bench: Don't return a bool from main...
176 2018-05-31 09:16:35	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/36fc8052f62b...24f70118414f
177 2018-05-31 09:17:30	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13349: bench: Don't return a bool from main (06master...062017_05_bench_warning) 02https://github.com/bitcoin/bitcoin/pull/13349
178 2018-05-31 09:22:55	0|bitcoin-git|13bitcoin/06master 14fa2d83e 15MarcoFalke: travis: Skip cache for lint stage
179 2018-05-31 09:22:55	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/24f70118414f...87a9d03c0c1e
180 2018-05-31 09:22:56	0|bitcoin-git|13bitcoin/06master 1487a9d03 15MarcoFalke: Merge #13347: travis: Skip cache for lint stage...
181 2018-05-31 09:23:37	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13347: travis: Skip cache for lint stage (06master...06Mf1806-travisLintNoCache) 02https://github.com/bitcoin/bitcoin/pull/13347
182 2018-05-31 11:15:10	0|bitcoin-git|[13bitcoin] 15jl2012 opened pull request #13357: Accurately determine the use of SIGHASH_SINGLE in signing (06master...06signsingle) 02https://github.com/bitcoin/bitcoin/pull/13357
183 2018-05-31 14:17:34	0|MarcoFalke|jonasschnelli: I can see my review on https://github.com/bitcoin/bitcoin/pull/12196/files#diff-2497f9b95fc934233daa9cb4a45a9df2
184 2018-05-31 15:07:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13359: wallet: Directly operate with CMutableTransaction (06master...06Mf1806-avoidTxConstuctor) 02https://github.com/bitcoin/bitcoin/pull/13359
185 2018-05-31 15:12:46	0|bitcoin-git|[13bitcoin] 15jl2012 opened pull request #13360: [Policy] Reject SIGHASH_SINGLE with output out of bound (06master...06insecure_single) 02https://github.com/bitcoin/bitcoin/pull/13360
186 2018-05-31 15:39:32	0|Chris_Stewart_5|can miners set their own sequence number in their coinbase input?
187 2018-05-31 15:47:49	0|echeveria|Chris_Stewart_5: yes, there's no restriction on that.
188 2018-05-31 16:05:52	0|wumpus|Chris_Stewart_5: there's no requirement on the coinbase data except for BIP34 afaik
189 2018-05-31 16:07:18	0|Chris_Stewart_5|Thanks guys
190 2018-05-31 16:09:41	0|sipa|also the length of the coinbase scriptSig is between 2 and 100 bytes
191 2018-05-31 16:09:59	0|sipa|that's also a consensus rule; no idea why it's there
192 2018-05-31 16:11:01	0|wumpus|oh!
193 2018-05-31 16:16:06	0|echeveria|sipa isn't it more than 2 now with BIP30?
194 2018-05-31 16:16:30	0|TheCharlatan|How is glibc, for example libm.so, back-compatibility for a normal 64bit Linux binary achieved, if the gitian builder is updated to Ubuntu 18.04? A standard 64 bit static build on 18.04 for example does not seem compatible with anything below.
195 2018-05-31 16:18:43	0|cfields|TheCharlatan: symbols must be added for glibc funtions introduced since our minimum version
196 2018-05-31 16:23:22	0|sipa|echeveria: you mean BIP34 i assume; yes, except for the first few blocks
197 2018-05-31 16:24:27	0|wumpus|TheCharlatan: indeed, see src/compat/glibc_compat.cpp
198 2018-05-31 16:25:35	0|wumpus|it's a matter of not using symbols that have been defined since, we have a symbol checker script under contrib/devtools to check that
199 2018-05-31 16:25:56	0|wumpus|(glibc symbols are versioned)
200 2018-05-31 16:40:06	0|TheCharlatan|so future gitian Bionic builds will all have to be configure with --enable-glibc-back-compat ?
201 2018-05-31 16:54:18	0|wumpus|all linux gitian builds have always been built with thta
202 2018-05-31 16:55:30	0|wumpus|(well, to be correct, since 0.9.2)
203 2018-05-31 17:14:45	0|wumpus|the gitian linux build even calls the symbol checker and fails if there are unexpected symbols
204 2018-05-31 17:15:05	0|wumpus|it should be pretty fool-proof
205 2018-05-31 18:13:15	0|jonasschnelli|Thanks MarcoFalke, found it
206 2018-05-31 19:00:50	0|luke-jr|don't die on us, jonasschnelli
207 2018-05-31 19:01:10	0|jonasschnelli|heh.. meeting?
208 2018-05-31 19:01:19	0|lightningbot|Meeting started Thu May 31 19:02:19 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
209 2018-05-31 19:01:19	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
210 2018-05-31 19:01:19	0|wumpus|#startmeeting
211 2018-05-31 19:01:27	0|jonasschnelli|hi
212 2018-05-31 19:01:36	0|promag|hi
213 2018-05-31 19:01:40	0|cfields|hi
214 2018-05-31 19:01:47	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
215 2018-05-31 19:01:51	0|wumpus|chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
216 2018-05-31 19:02:35	0|wumpus|proposed topics?
217 2018-05-31 19:03:44	0|sipa|c++14
218 2018-05-31 19:03:56	0|kanzure|hi.
219 2018-05-31 19:03:59	0|sipa|high-priority prs
220 2018-05-31 19:04:02	0|MarcoFalke|Is the rc1 out with an email?
221 2018-05-31 19:04:11	0|cfields|MarcoFalke: yes
222 2018-05-31 19:04:14	0|wumpus|I have one of my own: new "addr" P2P message to support 256-bit addresses, for TorV3 and I2P
223 2018-05-31 19:04:41	0|wumpus|yes, rc1 is out with email to bitcoin-core-dev mailing list
224 2018-05-31 19:05:04	0|wumpus|#topic High priority for review
225 2018-05-31 19:05:29	0|sipa|i'd like #13026 on the list
226 2018-05-31 19:05:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/13026 | Fix include comment in src/interfaces/wallet.h by promag · Pull Request #13026 · bitcoin/bitcoin · GitHub
227 2018-05-31 19:05:31	0|sipa|eh
228 2018-05-31 19:05:35	0|sipa|#13062
229 2018-05-31 19:05:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
230 2018-05-31 19:05:40	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
231 2018-05-31 19:06:07	0|wumpus|sipa: added
232 2018-05-31 19:06:11	0|sipa|dank
233 2018-05-31 19:06:23	0|jonasschnelli|+e
234 2018-05-31 19:06:37	0|wumpus|anything/anyone else?
235 2018-05-31 19:06:53	0|promag|#13111
236 2018-05-31 19:06:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
237 2018-05-31 19:06:55	0|promag|please
238 2018-05-31 19:07:11	0|wumpus|ok
239 2018-05-31 19:07:17	0|promag|1 per developer right?
240 2018-05-31 19:07:18	0|luke-jr|I'm trying to rebase rwconf today
241 2018-05-31 19:07:22	0|wumpus|promag: yes
242 2018-05-31 19:07:30	0|luke-jr|that seems like it's desirable, so we can get the GUI pruning in
243 2018-05-31 19:07:44	0|jonasschnelli|Thanks luke-jr
244 2018-05-31 19:07:51	0|wumpus|luke-jr: nice
245 2018-05-31 19:08:11	0|luke-jr|#11082 IIRC
246 2018-05-31 19:08:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
247 2018-05-31 19:08:37	0|jonasschnelli|#13058 is a quick review (in high prio), has already two tested ACKs. Plz anyone.
248 2018-05-31 19:08:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/13058 | [wallet] `createwallet` RPC - create new wallet at runtime by jnewbery · Pull Request #13058 · bitcoin/bitcoin · GitHub
249 2018-05-31 19:08:54	0|jonasschnelli|This opens the door for a lot of things
250 2018-05-31 19:10:24	0|wumpus|luke-jr: yes, that one needs rebase
251 2018-05-31 19:11:05	0|wumpus|but added, also jnewbery's 13058
252 2018-05-31 19:11:17	0|wumpus|I think that's enough for this week :)
253 2018-05-31 19:11:36	0|wumpus|#topic C++14 (sipa)
254 2018-05-31 19:11:40	0|jonasschnelli|13058 is already there.. just wanted to make people aware that its a easy review
255 2018-05-31 19:12:35	0|sipa|given that travis, and soon gitian, will be built on bionic, that may open the door to using more modern compilers, which support c++14
256 2018-05-31 19:12:44	0|sipa|gcc 5 and clang 3.4 fully implement it
257 2018-05-31 19:13:06	0|sipa|debian stable and ubuntu 16.04+ have gcc 5 - though as luke-jr points out, RHEL does not yet
258 2018-05-31 19:13:14	0|wumpus|ref: #13356, as well as earlier discussion on IRC today
259 2018-05-31 19:13:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub
260 2018-05-31 19:13:18	0|gmaxwell|Any idea when RHEL will?
261 2018-05-31 19:13:27	0|sipa|RHEL 8 will ship with GCC 7
262 2018-05-31 19:13:35	0|sipa|but when...?
263 2018-05-31 19:13:38	0|gmaxwell|I mean we basically have a half year lag on major versions...
264 2018-05-31 19:13:55	0|wumpus|yes so this would be 0.18 at soonest
265 2018-05-31 19:14:07	0|MarcoFalke|Agree with wumpus
266 2018-05-31 19:14:09	0|sipa|yeah, true - which would be released... march 2019?
267 2018-05-31 19:14:56	0|wumpus|sipa: yes. that's the 0.17 planned release date + 6 months
268 2018-05-31 19:15:13	0|sipa|by that time probably most distro limitation concerns will have disappeared
269 2018-05-31 19:15:14	0|gmaxwell|also, whats in RHEL7 ? does it support enough of C++14 to cover the features we want?
270 2018-05-31 19:15:33	0|sipa|gmaxwell: RHEL7 has gcc 4.9... which barely supports c++11
271 2018-05-31 19:16:13	0|cfields|looks like 4.9 doesn't have relaxed constexpr, which is one of the big features
272 2018-05-31 19:16:27	0|cfields|generally though, +1 for c++14 as soon as reasonably possible. It's mostly a cleanup of c++11, and used for development of lots of dev tools themselves. Also the default now for gcc/clang.
273 2018-05-31 19:16:39	0|wumpus|yep
274 2018-05-31 19:17:17	0|ajtowns[m]|Ugh, did lightningbot die on me?
275 2018-05-31 19:17:30	0|wumpus|ajtowns[m]: don't die on us during the meeting!
276 2018-05-31 19:18:10	0|luke-jr|wumpus: (re rwconf, I'll ping you after I rebase it for the flag)
277 2018-05-31 19:18:29	0|wumpus|ok, so I think everyone agrees C++14 is a good thing for 0.18 (given RHEL at the time)?
278 2018-05-31 19:19:04	0|gmaxwell|I think we saw with the move to C++11 that basically people seemed to fall into two groups: No problem (e.g. they'd upgrade or use binaryies compiled on another system), or completely unreasonable and basically looking for an excuse to not run newer software.
279 2018-05-31 19:19:41	0|luke-jr|gmaxwell: well, that was after waiting for C++11 to be reasonably available ofc
280 2018-05-31 19:19:43	0|ajtowns[m]|No seems like matrix is just not seeing everything so flowing the meeting on my phone will be hopeless :(
281 2018-05-31 19:19:48	0|wumpus|yes, I was especially worried about debian stable, but apparently that's no problem this time
282 2018-05-31 19:20:04	0|luke-jr|btw, should we concern with CentOS or other RHEL respins?
283 2018-05-31 19:20:15	0|luke-jr|if RHEL 8 is just barely out, they might lag..
284 2018-05-31 19:20:25	0|gmaxwell|luke-jr: yes but even where it wasn't most people just solved it with binaries built on another system.
285 2018-05-31 19:20:32	0|cfields|gmaxwell: the second group also included many who refused to _run_ a c++11 binary, despite -static-libstdc++ negating abi issues.
286 2018-05-31 19:20:47	0|wumpus|debian stable has gcc *6* which is very good
287 2018-05-31 19:21:02	0|luke-jr|gmaxwell: I'm not sure that's viable for GUI
288 2018-05-31 19:21:16	0|BlueMatt|wait, when does previous rhel stop getting support?
289 2018-05-31 19:21:17	0|wumpus|08:49 < sipa> https://packages.debian.org/stretch/gcc-6
290 2018-05-31 19:21:25	0|luke-jr|BlueMatt: a long long time AFAIK
291 2018-05-31 19:21:30	0|BlueMatt|I dont think we can force people to upgrade, though I also doubt we have almost any rhel users
292 2018-05-31 19:21:51	0|luke-jr|BlueMatt: even RHEL 5 from 2007 still has support
293 2018-05-31 19:22:00	0|BlueMatt|how long is opensuse supported?
294 2018-05-31 19:22:02	0|wumpus|luke-jr: -static-libstdc++ works fine if you link qt statically as well.
295 2018-05-31 19:22:05	0|BlueMatt|we may actually have opensuse users
296 2018-05-31 19:22:10	0|wumpus|luke-jr: (which is the default for depends builds)
297 2018-05-31 19:22:15	0|luke-jr|wumpus: but that breaks platform plugins?
298 2018-05-31 19:22:20	0|wumpus|luke-jr: who cares
299 2018-05-31 19:22:44	0|wumpus|luke-jr: we already ignore this, with building gitian qt executables statically against qt
300 2018-05-31 19:23:04	0|luke-jr|but people shouldn't be using those ideally
301 2018-05-31 19:23:23	0|luke-jr|BlueMatt: RHEL 5 support ends in 2020
302 2018-05-31 19:23:31	0|gmaxwell|when we made the c++11 upgrade anyone I encountered using old RHEL just used binaries built elsewhere.
303 2018-05-31 19:23:33	0|wumpus|luke-jr: and anyhow the only major user of that was ubuntu unity, which supported qt4 well only...
304 2018-05-31 19:23:48	0|sipa|RHEL 7 support is until 2024
305 2018-05-31 19:23:52	0|gmaxwell|The only people that were an issue were running two version old outdated debian stable, and just refused to deal with it.
306 2018-05-31 19:24:00	0|luke-jr|I don't think it's realistic to wait on "oldest supported RHEL"
307 2018-05-31 19:24:06	0|BlueMatt|gmaxwell: lol sounds like debian users
308 2018-05-31 19:24:12	0|wumpus|gmaxwell: I doubt c++14 will be more of a problem to them than c++11
309 2018-05-31 19:24:18	0|BlueMatt|luke-jr: no, I dont think it is either, was just asking
310 2018-05-31 19:24:22	0|wumpus|anyhow this is almost a year away
311 2018-05-31 19:24:48	0|sipa|there are rumors about RHEL 8 beta this month
312 2018-05-31 19:24:49	0|BlueMatt|is supported-ubuntu or supported-debian still not gonna support c++14 for 0.18?
313 2018-05-31 19:24:51	0|gmaxwell|So basically what I was arguing was that for C++11 it seemed most people that had isuses were fine using binaries built elsewhere (either by us or elsewhere)... so it's fine. It just needs to be good enough to not exclude developers.
314 2018-05-31 19:24:54	0|BlueMatt|it does seem a bit premature imho
315 2018-05-31 19:25:12	0|wumpus|clang4 is the most common on BSDs, and it supports C++14 already  now
316 2018-05-31 19:25:40	0|BlueMatt|do we mostly just want it for shared mutex?
317 2018-05-31 19:25:54	0|BlueMatt|seems like we can do a mutex-wrapped shared_mutex pretty easily?
318 2018-05-31 19:25:54	0|luke-jr|gmaxwell: I don't agree with the conclusion. If we relax the criteria, we may (hopefully!) find users who didn't have a problem now do
319 2018-05-31 19:25:59	0|wumpus|I was really surprised about that and that caused me to drop all my reservations about it
320 2018-05-31 19:27:21	0|cfields|iirc there are also several handy container cleanups. Like try_emplace().
321 2018-05-31 19:27:34	0|wumpus|BlueMatt: we can use shared mutex right now through boost - optional c++14 support would be a possibility too, but sipa was not sure it's worth it
322 2018-05-31 19:28:06	0|luke-jr|something to consider if it really is worth it, we could release 0.18.0 requiring it, and then if there's trouble, a 0.18.1 not needing it
323 2018-05-31 19:28:12	0|sipa|yeah, we're not going to write code where one version uses a generic lambda, and then have a longer additional version for pre-c++14 systems
324 2018-05-31 19:28:21	0|luke-jr|it's not a big deal if people can't update right away..
325 2018-05-31 19:28:33	0|wumpus|so we can just move this to 0.19
326 2018-05-31 19:28:37	0|morcos|another 10 months seems long enough to me...  we can't always be all things to all people
327 2018-05-31 19:28:38	0|wumpus|if 0.18 is controversial.
328 2018-05-31 19:28:47	0|sipa|how about we see after 0.17 branches off
329 2018-05-31 19:28:52	0|wumpus|yes
330 2018-05-31 19:28:57	0|sipa|or even later in the 0.18 cycle
331 2018-05-31 19:29:04	0|BlueMatt|yea
332 2018-05-31 19:29:04	0|wumpus|that was my proposal too, let's make it depend on RHEL
333 2018-05-31 19:29:05	0|BlueMatt|agreed
334 2018-05-31 19:29:07	0|luke-jr|I expect it won't be controversial
335 2018-05-31 19:29:15	0|sipa|there's nothing we can decide here right now - just bringing up potential issues is good in advance
336 2018-05-31 19:29:20	0|luke-jr|we're almost there already
337 2018-05-31 19:29:35	0|BlueMatt|well I dunno about depending on rhel, certainly if there's no version of rhel that supports c++14 we shoudlnt do it, but its more than that
338 2018-05-31 19:29:37	0|wumpus|in any case I tried building with -std=c++14 on various platforms today, works without any compile issues.
339 2018-05-31 19:29:44	0|BlueMatt|its also a question of people running like one-version-back distro X
340 2018-05-31 19:29:46	0|wumpus|so there's really nothing to be done there
341 2018-05-31 19:29:49	0|BlueMatt|and if that breaks that'd be bad
342 2018-05-31 19:29:53	0|BlueMatt|cause shitloads of people do that
343 2018-05-31 19:30:14	0|luke-jr|BlueMatt: trusty isn't just one version back, is it?
344 2018-05-31 19:30:29	0|sipa|last *two* ubuntu LTSs are fine
345 2018-05-31 19:30:29	0|wumpus|with that reasoning, we shouldn't even require c++11 yet
346 2018-05-31 19:30:45	0|BlueMatt|I dont really care about tursty anymore, it was released in fucking 2014
347 2018-05-31 19:30:47	0|wumpus|there's no end to that - why not rewrite bitcoin core in C89 while you're at it :)
348 2018-05-31 19:30:51	0|BlueMatt|it would be nice to support xenial
349 2018-05-31 19:30:58	0|wumpus|it supports xenial
350 2018-05-31 19:31:07	0|BlueMatt|I mean I was mostly worried about debian anyway
351 2018-05-31 19:31:08	0|wumpus|xenial is gcc 5.4.0
352 2018-05-31 19:31:09	0|BlueMatt|but, yea
353 2018-05-31 19:31:20	0|sipa|debian oldstable is 4.8
354 2018-05-31 19:31:30	0|BlueMatt|when does debian oldstable stop?
355 2018-05-31 19:31:34	0|BlueMatt|like 1.5 years or something?
356 2018-05-31 19:31:41	0|sipa|when there is a new stable
357 2018-05-31 19:31:43	0|luke-jr|BlueMatt: Debian has an oldoldstable now :P
358 2018-05-31 19:31:46	0|wumpus|I even *tried* building c++14 bitcoin core on xenial today, it worked
359 2018-05-31 19:31:57	0|wumpus|let alone in march 2019...
360 2018-05-31 19:31:59	0|BlueMatt|luke-jr: yea, ok, fuck oldoldstable
361 2018-05-31 19:32:06	0|luke-jr|:D
362 2018-05-31 19:32:08	0|BlueMatt|sipa: yea, that was my question
363 2018-05-31 19:32:17	0|sipa|anyway, next topic?
364 2018-05-31 19:32:30	0|BlueMatt|mid-2019
365 2018-05-31 19:32:34	0|BlueMatt|which would imply like 0.19
366 2018-05-31 19:32:37	0|BlueMatt|depending on timeline
367 2018-05-31 19:33:05	0|sipa|i'm fine with not being able to *build* on debian oldstable
368 2018-05-31 19:33:12	0|wumpus|yes...
369 2018-05-31 19:33:37	0|BlueMatt|I'm not a fan of it, unless we have a super huge win we want right away, though if its like "debian oldstable will be eol in like a month after release" its a rather moot point
370 2018-05-31 19:33:46	0|cfields|any update on github unicorns? I don't remember seeing any this week, though something about my browser must make them rare for me.
371 2018-05-31 19:33:51	0|sipa|cfields: they're fixed
372 2018-05-31 19:34:02	0|cfields|woohoo!
373 2018-05-31 19:34:08	0|wumpus|github unicorns seem to be fixed
374 2018-05-31 19:34:15	0|wumpus|haven't encountered any this week, I think
375 2018-05-31 19:34:28	0|sipa|don't remember who commented about it here, but they received a mail from github saying they did some software updated that added caching
376 2018-05-31 19:34:29	0|jonasschnelli|Yes. They wrote back that they have deployed a fix
377 2018-05-31 19:34:37	0|sipa|ah, it was mr schnelli
378 2018-05-31 19:34:46	0|wumpus|cool.
379 2018-05-31 19:35:19	0|cfields|jonasschnelli: thanks for nagging :)
380 2018-05-31 19:35:22	0|sipa|wumpus: you had a topic?
381 2018-05-31 19:35:23	0|wumpus|#topic new "addr" P2P message to support 256-bit addresses (wumpus)
382 2018-05-31 19:35:29	0|wumpus|so I'd like to work on this
383 2018-05-31 19:35:30	0|sipa|concept ack
384 2018-05-31 19:35:52	0|BlueMatt|for new-style tor services, I presume?
385 2018-05-31 19:35:54	0|luke-jr|is 256- bit enough?
386 2018-05-31 19:35:56	0|BlueMatt|sounds like a good idea to me
387 2018-05-31 19:36:01	0|roasbeef|wumpus: +1
388 2018-05-31 19:36:02	0|wumpus|first a BIP, of course. Anything special I should take into account? my idea would be to introduce a new ADDR message with more space for the network address, simply.
389 2018-05-31 19:36:09	0|wumpus|this is to support I2P
390 2018-05-31 19:36:15	0|wumpus|and the new TorV3 hidden services
391 2018-05-31 19:36:16	0|luke-jr|256+8 seems better for future-proofing (8 bits to select a network schema)
392 2018-05-31 19:36:20	0|wumpus|yes, both use 256 bit
393 2018-05-31 19:36:24	0|wumpus|luke-jr: yes
394 2018-05-31 19:36:31	0|wumpus|that's my idea, also have a network id
395 2018-05-31 19:36:34	0|sipa|256 bit + network class byte
396 2018-05-31 19:36:39	0|luke-jr|sgtm
397 2018-05-31 19:36:44	0|BlueMatt|+ port? I know they dont need them but other things...who knows?
398 2018-05-31 19:36:47	0|sipa|so we can stop using onioncat embedding in ipv6
399 2018-05-31 19:36:50	0|BlueMatt|I mean whats an extra 4 bytes
400 2018-05-31 19:36:53	0|jonasschnelli|Not sure what plans sipa and gmaxwell may have with authentication.. not sure if that is overlapping with addr
401 2018-05-31 19:36:55	0|BlueMatt|err 2 bytes
402 2018-05-31 19:36:58	0|sipa|jonasschnelli: no overlap
403 2018-05-31 19:37:01	0|roasbeef|idk where bip 151 (and it's auth companion) is at atm, but could also use it to propagate pubkeys as well so initial conn handshake can be fully encrypted
404 2018-05-31 19:37:01	0|wumpus|BlueMatt: yes, the port should still be there, good point
405 2018-05-31 19:37:05	0|luke-jr|could do a variable length :P
406 2018-05-31 19:37:14	0|jonasschnelli|Yes. I mean what roasbeef just said
407 2018-05-31 19:37:18	0|jonasschnelli|*meant
408 2018-05-31 19:37:18	0|sipa|roasbeef: that seems to defeat the purpose :(
409 2018-05-31 19:37:27	0|roasbeef|how so?
410 2018-05-31 19:37:27	0|wumpus|roasbeef: should that be gossiped?
411 2018-05-31 19:37:34	0|roasbeef|depends...
412 2018-05-31 19:37:36	0|sipa|that leaks identity
413 2018-05-31 19:37:38	0|sdaftuar|could this overlap with NODE_NETWORK_LIMITED etc to gossip block ranges that nodes might store and serve to the network?
414 2018-05-31 19:37:39	0|cfields|wumpus: any changes to serviceflags logic while you're at it?
415 2018-05-31 19:37:44	0|wumpus|cfields: no
416 2018-05-31 19:37:46	0|luke-jr|wumpus: please add multi-bit service flags
417 2018-05-31 19:37:48	0|wumpus|(preferably not)
418 2018-05-31 19:37:51	0|luke-jr|:x
419 2018-05-31 19:37:55	0|wumpus|I don't want too much scope creep
420 2018-05-31 19:37:56	0|cfields|heh
421 2018-05-31 19:38:06	0|sipa|roasbeef, jonasschnelli: oh!
422 2018-05-31 19:38:18	0|sipa|wait, are you just saying a bit to indicate "this peer supports encryption"?
423 2018-05-31 19:38:23	0|sipa|or rumouring pubkeys?
424 2018-05-31 19:38:23	0|wumpus|cfields: at least not as in "extend the service flags to arbitrary text" or something like that
425 2018-05-31 19:38:31	0|sipa|(i'm in favor of the first, against the latter)
426 2018-05-31 19:38:31	0|wumpus|cfields: if you need some more bits there, sure
427 2018-05-31 19:38:41	0|jonasschnelli|sdaftuar: don't we already pass around the service bits? Or can you be more specific about the NODE_NETWORK_LIMITED flag?
428 2018-05-31 19:38:42	0|roasbeef|i was saying rumouring pubkeys
429 2018-05-31 19:38:47	0|sipa|yeah, no
430 2018-05-31 19:38:51	0|roasbeef|how do you stop MiTM otherwise?
431 2018-05-31 19:38:54	0|BlueMatt|roasbeef: nooooo, we dont want to leak identity
432 2018-05-31 19:39:00	0|wumpus|cfields: the data to be gossiped should be fairly compact, after all
433 2018-05-31 19:39:04	0|sipa|roasbeef: out of band
434 2018-05-31 19:39:06	0|jonasschnelli|roasbeef: manual pairing only for now
435 2018-05-31 19:39:07	0|wumpus|cfields: but I'm interested in hearing your ideas
436 2018-05-31 19:39:23	0|luke-jr|jonasschnelli: there was an issue with NNL defining the 2-3 bits as having 2^N meanings due to nodes combining the set bits
437 2018-05-31 19:39:55	0|jonasschnelli|?
438 2018-05-31 19:39:56	0|sipa|roasbeef: most connections don't need MitM protection, as there is no identity of the peer they're connecting yo
439 2018-05-31 19:40:13	0|roasbeef|true, and the ones that do can use an ssh like auth_keys structure i guess
440 2018-05-31 19:40:15	0|luke-jr|might be good to add a node seed of some sort; eg, so we can do a deterministic "don't prune these blocks"
441 2018-05-31 19:40:18	0|sipa|only situations where you're connecting to a friend's peer or a node you run yourself need authentication
442 2018-05-31 19:40:21	0|wumpus|sdaftuar: seems like something that will get outdated really soon
443 2018-05-31 19:40:23	0|cfields|wumpus: I was just curious as now would be the obvious time to make improvements. Can't really think of anything off the top of my head though.
444 2018-05-31 19:40:35	0|luke-jr|sipa: well, keys can ensure the age of your peers, so the ISP can't MITM *everything*
445 2018-05-31 19:40:38	0|wumpus|sdaftuar: what you'd want to gossip is block storage policy, not range, I think
446 2018-05-31 19:41:08	0|luke-jr|sipa: eg, if you're on an untrusted wifi, it'd be nice to know you have peers you found at home
447 2018-05-31 19:41:29	0|jimpo|Wouldn't Tor v3 address leak identity?
448 2018-05-31 19:41:32	0|wumpus|cfields: ok well if you have any ideas, feel free to let me know, but I think there's danger in trying to do too much at once
449 2018-05-31 19:41:39	0|roasbeef|jimpo: no more than tor v2
450 2018-05-31 19:41:41	0|wumpus|cfields: I really just want to support torv3 and I2P asap :)
451 2018-05-31 19:41:42	0|jonasschnelli|luke-jr: but how could you make sure those peers are trustworthy? They could even sell their auth-key, etc.
452 2018-05-31 19:41:46	0|sdaftuar|wumpus: yes, this is premature but i had imagined that we might store block heights % N or something, and communicate that
453 2018-05-31 19:41:49	0|sipa|jimpo: as much as IP addresses are an identity, yes
454 2018-05-31 19:42:03	0|cfields|wumpus: one potential improvement would be filtering based on specified nets. I don't think we can do that now, can we?
455 2018-05-31 19:42:21	0|jonasschnelli|sdaftuar, wumpus: do we have stats (impossible) how deep pruned peers do prune?
456 2018-05-31 19:42:21	0|luke-jr|jonasschnelli: you can't in any case; it just ensures some wifi access point isn't sybil'ing you
457 2018-05-31 19:42:26	0|jimpo|That seems similar to IP + BIP 151 pubkey then?
458 2018-05-31 19:42:26	0|wumpus|cfields: no, I don't think so
459 2018-05-31 19:42:28	0|cfields|(obviously we can/do after receipt)
460 2018-05-31 19:42:29	0|sipa|jimpo: the issue is being able to correlate multiple IP addresses belonging to the same node
461 2018-05-31 19:42:48	0|sdaftuar|jonasschnelli: for something like this i think we'd first need a new pruning mode where instead of just keeping the last 2 days of blocks, you keep some fraction of all blocks
462 2018-05-31 19:42:52	0|wumpus|cfields: clients use some weird heuristic to determine what peers to send AFAIK
463 2018-05-31 19:42:56	0|jimpo|Could BIP 151 blind pubkeys with the hash of the IP/port?
464 2018-05-31 19:43:06	0|luke-jr|sdaftuar: that was my idea with the seed
465 2018-05-31 19:43:30	0|jonasschnelli|jimpo: BIP 151 has no authentication
466 2018-05-31 19:43:35	0|sipa|jimpo: that's one possibility, yes - but even better is a technique that doesn't reveal pubkeys at all
467 2018-05-31 19:43:57	0|wumpus|issue for this is #2091
468 2018-05-31 19:43:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/2091 | Binding to multiple anonymous networks (esp. I2P) · Issue #2091 · bitcoin/bitcoin · GitHub
469 2018-05-31 19:44:05	0|cfields|sipa: speaking of which, any updates on the scheme you're scheming?
470 2018-05-31 19:44:20	0|sipa|cfields: no, sorry
471 2018-05-31 19:44:27	0|cfields|np
472 2018-05-31 19:44:39	0|sipa|jimpo: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b has some arguments in favor
473 2018-05-31 19:45:16	0|jonasschnelli|however, to not distract, the 256+bit addr proposal should be written and discussion should continued on the ML
474 2018-05-31 19:45:23	0|sipa|agree
475 2018-05-31 19:45:32	0|wumpus|jonasschnelli: yes
476 2018-05-31 19:45:35	0|sipa|but it's something i've wanted to do since 2012 :)
477 2018-05-31 19:45:41	0|wumpus|jonasschnelli: I was just asking for ideas.
478 2018-05-31 19:46:05	0|wumpus|any other topics?
479 2018-05-31 19:46:53	0|jonasschnelli|Maybe a quick dive into seeder hardening?
480 2018-05-31 19:47:11	0|wumpus|#topic Seeder hardening (jonasschnelli)
481 2018-05-31 19:47:20	0|jonasschnelli|It seems like that most active DNS seeds pass around ABC/BCash peers...
482 2018-05-31 19:47:33	0|jonasschnelli|It's a cat and mouse game... but we could tighten the screws
483 2018-05-31 19:47:51	0|jonasschnelli|By checking for a recent block during crawling (expansive) or avoid protocol version >80000
484 2018-05-31 19:48:05	0|cfields|jonasschnelli: didn't they change magic?
485 2018-05-31 19:48:23	0|jonasschnelli|cfields: not sure,... maybe, but then there are still some zombies around.
486 2018-05-31 19:48:24	0|wumpus|it's kind of a difficult compromise, on one hand you want a cheap heuristic, on the other hand it should be expensive to work around
487 2018-05-31 19:48:52	0|wumpus|having to run a bitcoind on seeder nodes sounds like prohibitively expensive
488 2018-05-31 19:48:54	0|jonasschnelli|But if they are dishonest, they will just serve the correct block to the all-known seeder ips, and cheat with all other IPs
489 2018-05-31 19:49:03	0|jonasschnelli|wumpus: yeah.. I dislike that as well
490 2018-05-31 19:49:12	0|sipa|my seeder node has a bitcoind... i'm more worried about the bandwidth increase from asking for blocks
491 2018-05-31 19:49:19	0|jonasschnelli|Maybe we should just keep an eye on it and start to form some thoughts
492 2018-05-31 19:49:22	0|sipa|asking for headers may be better
493 2018-05-31 19:49:30	0|wumpus|sipa: good point.
494 2018-05-31 19:49:48	0|sipa|i don't seem to have many ABC nodes
495 2018-05-31 19:49:53	0|jonasschnelli|Yeah. Bandwith... although you could disconnect after the header+a couple of txns
496 2018-05-31 19:50:01	0|sipa|30 in my top 100k IPs
497 2018-05-31 19:50:11	0|wumpus|jonasschnelli: but how would you verify, if you don't actually receive the data?
498 2018-05-31 19:50:12	0|sipa|13 in my top 10k
499 2018-05-31 19:50:22	0|wumpus|jonasschnelli: also it increases load on the nodes you're probing
500 2018-05-31 19:50:23	0|sipa|1 in my top 1000
501 2018-05-31 19:50:59	0|jonasschnelli|Okay. Yes. That is a different image...
502 2018-05-31 19:51:30	0|jonasschnelli|Well,.. then nm..
503 2018-05-31 19:51:46	0|wumpus|jonasschnelli: the difference is strange
504 2018-05-31 19:52:10	0|jonasschnelli|I need to check my mainnet seed. I played with some options on the testnet seed... there its def. worse
505 2018-05-31 19:52:17	0|wumpus|jonasschnelli: you should probably check what your configuration differences with sipa are
506 2018-05-31 19:52:24	0|jonasschnelli|Indeed
507 2018-05-31 19:52:43	0|jonasschnelli|or if someone is trying to sybil my crawler. :)
508 2018-05-31 19:53:07	0|wumpus|hehe, probe through tor :)
509 2018-05-31 19:53:36	0|jonasschnelli|I guess that is the difference... my provider stoped my seeder a couple of times because it tested some invalid IP ranges a lot
510 2018-05-31 19:53:45	0|jonasschnelli|since then I mostly crawl via tor
511 2018-05-31 19:53:56	0|wumpus|ohh maybe they're sybilling tor exit nodes then
512 2018-05-31 19:54:04	0|jonasschnelli|however, I double check and report back IF it is an issue
513 2018-05-31 19:54:17	0|jonasschnelli|wumpus: or that, yeah.
514 2018-05-31 19:54:25	0|wumpus|though I somehow doubt that would take the form of ... more ABC nodes
515 2018-05-31 19:54:43	0|cfields|jonasschnelli: you're filtering out non-segwit?
516 2018-05-31 19:55:36	0|jonasschnelli|cfields: I use the standard parameters of an up to date version of sipa seeder... I don't think it filters out non SW peers if a client don't ask for it via x<filer>.seed
517 2018-05-31 19:55:48	0|BlueMatt|my seeder has /always/ asked for one block
518 2018-05-31 19:56:02	0|BlueMatt|(but does not need a full node)
519 2018-05-31 19:56:08	0|sipa|BlueMatt: nice
520 2018-05-31 19:56:24	0|wumpus|BlueMatt: the only reason it would need a node is to ask for a recent one
521 2018-05-31 19:56:28	0|jonasschnelli|BlueMatt: hopefully your not asking for the genesis. :)
522 2018-05-31 19:56:37	0|BlueMatt|wumpus: I mean its an spv client so it does ask for a recent one
523 2018-05-31 19:56:43	0|wumpus|but asking after the ABC and gold forks it would be ok I guess
524 2018-05-31 19:57:01	0|jonasschnelli|BlueMatt: nice.
525 2018-05-31 19:57:42	0|wumpus|yes
526 2018-05-31 19:58:05	0|jonasschnelli|cat dnsseed.dump | grep "Bitcoin ABC" | grep "  1   " | wc -l
527 2018-05-31 19:58:10	0|jonasschnelli|207 ips
528 2018-05-31 19:58:23	0|sipa|and: cat dnsseed.dump | head -n 1000 | grep ABC | wc ?
529 2018-05-31 19:58:43	0|jonasschnelli|58     762    9526
530 2018-05-31 19:58:52	0|sipa|significantly more than for me
531 2018-05-31 19:59:01	0|sipa|(i have 1 with that command line)
532 2018-05-31 19:59:09	0|jonasschnelli|Strange... just checked... I don't crawl anymore via tor
533 2018-05-31 19:59:17	0|sipa|well, time's up
534 2018-05-31 19:59:19	0|wumpus|#endmeeting
535 2018-05-31 19:59:20	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.log.html
536 2018-05-31 19:59:20	0|lightningbot|Meeting ended Thu May 31 20:00:20 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
537 2018-05-31 19:59:20	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.html
538 2018-05-31 19:59:20	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.txt
539 2018-05-31 19:59:41	0|jonasschnelli|however,.. I'll investigate. If sipas seeder "is clean", then I guess its handable.
540 2018-05-31 19:59:56	0|wumpus|it's really strange
541 2018-05-31 20:01:03	0|jonasschnelli|Would removing the database and "give-it-a-fresh-start" may help?
542 2018-05-31 20:01:53	0|achow101|can someone help me fix travis for #12136. I can't replicate its failure locally and the log for it makes no sense to me as to why it is failing
543 2018-05-31 20:01:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
544 2018-05-31 20:02:06	0|jonasschnelli|doneing..
545 2018-05-31 20:02:35	0|aj|wumpus: so matrix was managing to show me what you were saying, but nothing from anyone else
546 2018-05-31 20:05:06	0|cfields|achow101: the logs were nuked when the build was restarted. got a copy?
547 2018-05-31 20:05:54	0|achow101|No, but the first error was about TransactionSignatureCreator at sign.cpp:48
548 2018-05-31 20:06:03	0|achow101|it couldn't find TransactionSignatureCreator
549 2018-05-31 20:08:03	0|achow101|cfields: well all of the builds are still failing, so you have the logs now
550 2018-05-31 20:08:19	0|wumpus|aj: lol, weird, maybe becuase I have +o?
551 2018-05-31 20:08:22	0|cfields|ah, there we go
552 2018-05-31 20:09:22	0|wumpus|aj: can I be invisible too now?
553 2018-05-31 20:10:51	0|MarcoFalke|achow101: Fails locally for me as well
554 2018-05-31 20:11:08	0|achow101|oh
555 2018-05-31 20:11:36	0|ajtowns[m]|Wumpus: nope your words still cross the ethereal boundaries
556 2018-05-31 20:11:54	0|achow101|MarcoFalke: works fine for me, and it worked fine before the changes I made, and those didn't touch the code that travis says the error is on
557 2018-05-31 20:12:25	0|wumpus|ajtowns[m]: darn!
558 2018-05-31 20:12:53	0|MarcoFalke|achow101: Note that you have to rebase
559 2018-05-31 20:13:01	0|aj|wumpus: promag also makes it through, so you're not totally special fwiw
560 2018-05-31 20:13:05	0|MarcoFalke|This is a merge conflict (silent)
561 2018-05-31 20:13:22	0|MarcoFalke|travis always runs against merge(master, pull)
562 2018-05-31 20:13:32	0|achow101|MarcoFalke: I thought I rebased. maybe I didn't rebase far enough
563 2018-05-31 20:13:45	0|MarcoFalke|heh
564 2018-05-31 20:14:05	0|MarcoFalke|git rebase 36fc8052f62b87b11b0366fefee5f38dc886aefd
565 2018-05-31 20:14:20	0|cfields|achow101: wow, that's a lot of inheritance. Try calling the parent instead of great-grandparent?
566 2018-05-31 20:15:55	0|achow101|ok, now I see the problem.
567 2018-05-31 20:16:17	0|achow101|cfields: originall TransactionSignatureCreator was the parent..
568 2018-05-31 20:16:22	0|achow101|*originally
569 2018-05-31 20:16:57	0|cfields|achow101: I haven't really looked, but could you possibly inherit directly from the interface instead?
570 2018-05-31 20:17:24	0|achow101|cfields: the problem is that someone got rid of TransactionSignatureCreator in master and I hadn't rebased to that
571 2018-05-31 20:17:35	0|cfields|ah, ok
572 2018-05-31 20:45:17	0|echeveria|2018-05-31 19:45:07.675057 Potential stale tip detected, will try using extra outbound peer (last tip update: 2128 seconds ago)
573 2018-05-31 20:45:22	0|echeveria|this seems pretty eager
574 2018-05-31 20:46:25	0|wumpus|ok wrote a post on the new addr message discussion: https://github.com/bitcoin/bitcoin/issues/2091#issuecomment-393673952
575 2018-05-31 20:46:38	0|wumpus|echeveria: on the other hand adding an extra outbound peer is not exactly a drastic measure
576 2018-05-31 20:48:21	0|echeveria|true.
577 2018-05-31 21:32:20	0|sipa|jonasschnelli: any reasons why the "address/script/xpub/derivation" descriptor can't be a single string?
578 2018-05-31 21:33:25	0|sipa|something like "address:..." or "script:..." or "p2wpkh:xpub..../0-2000"