12018-05-31T00:04:39 *** Randolf has joined #bitcoin-core-dev
22018-05-31T00:16:20 *** karimofthecrop has quit IRC
32018-05-31T00:28:56 *** jhfrontz1 has joined #bitcoin-core-dev
42018-05-31T00:32:15 *** jhfrontz has quit IRC
52018-05-31T00:37:49 <MarcoFalke> sipa: Yes, see #13171
62018-05-31T00:37:51 <gribble> https://github.com/bitcoin/bitcoin/issues/13171 | [WIP] Change gitian-descriptors to use bionic instead by ken2812221 · Pull Request #13171 · bitcoin/bitcoin · GitHub
72018-05-31T00:38:05 <sipa> ah, yes!
82018-05-31T00:38:07 <sipa> thanks
92018-05-31T00:38:13 <sipa> so, c++14 soon? ;)
102018-05-31T00:38:30 <sipa> i'll bring it up in the meeting
112018-05-31T00:43:04 *** rex4539 has quit IRC
122018-05-31T00:47:47 *** TheRec has joined #bitcoin-core-dev
132018-05-31T00:50:47 *** murrayn has quit IRC
142018-05-31T00:50:59 *** murrayn has joined #bitcoin-core-dev
152018-05-31T00:56:51 *** AaronvanW has joined #bitcoin-core-dev
162018-05-31T01:01:58 *** AaronvanW has quit IRC
172018-05-31T01:34:41 *** ula has quit IRC
182018-05-31T01:59:14 *** Victorsueca has quit IRC
192018-05-31T02:00:32 *** Victorsueca has joined #bitcoin-core-dev
202018-05-31T02:52:51 *** ken2812221 has quit IRC
212018-05-31T02:53:37 *** ken2812221 has joined #bitcoin-core-dev
222018-05-31T02:53:51 *** zivl has quit IRC
232018-05-31T02:57:43 *** AaronvanW has joined #bitcoin-core-dev
242018-05-31T03:02:25 *** AaronvanW has quit IRC
252018-05-31T03:25:54 *** AaronvanW has joined #bitcoin-core-dev
262018-05-31T03:30:13 *** AaronvanW has quit IRC
272018-05-31T03:36:57 *** Randolf has quit IRC
282018-05-31T03:37:43 *** Randolf has joined #bitcoin-core-dev
292018-05-31T03:57:53 *** berndj has quit IRC
302018-05-31T03:58:35 *** tryphe_ has quit IRC
312018-05-31T04:03:29 *** drizztbsd has joined #bitcoin-core-dev
322018-05-31T04:06:57 *** timothy has quit IRC
332018-05-31T04:11:00 *** bitconner has quit IRC
342018-05-31T04:11:25 *** zivl has joined #bitcoin-core-dev
352018-05-31T04:11:46 *** tryphe has joined #bitcoin-core-dev
362018-05-31T04:14:53 *** berndj has joined #bitcoin-core-dev
372018-05-31T04:43:09 *** bitconner has joined #bitcoin-core-dev
382018-05-31T04:45:52 * kallewoof feels the need to to read up on what's new in c++14
392018-05-31T04:57:32 *** bitconner has quit IRC
402018-05-31T04:58:46 <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?
412018-05-31T04:59:29 <mryandao> and also changing int64_t types for time to std::chronos::nanoseconds for better semantics
422018-05-31T05:01:44 <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?
432018-05-31T05:04:00 *** bitconner has joined #bitcoin-core-dev
442018-05-31T05:09:02 *** zivl has quit IRC
452018-05-31T05:11:02 <sipa> kallewoof: not all that much; c++14 is mostly seen as a small fixup/extension of the things added in 11
462018-05-31T05:11:14 <sipa> better constexpr, better auto, better lambdas
472018-05-31T05:12:50 *** Sinclair_ has quit IRC
482018-05-31T05:25:28 <kallewoof> sipa: Yeah I just read through a summary. Not really important but 0b is nice :)
492018-05-31T05:25:48 <kallewoof> And better auto/lambda looks nice yeah.
502018-05-31T05:26:36 *** AaronvanW has joined #bitcoin-core-dev
512018-05-31T05:30:57 *** AaronvanW has quit IRC
522018-05-31T05:51:03 *** tryphe_ has joined #bitcoin-core-dev
532018-05-31T05:54:53 *** tryphe has quit IRC
542018-05-31T05:57:37 *** rex4539 has joined #bitcoin-core-dev
552018-05-31T06:01:44 *** fanquake has joined #bitcoin-core-dev
562018-05-31T06:03:32 <fanquake> mryandao If you haven't see already cfields has been working on that as well https://github.com/bitcoin/bitcoin/pull/9566
572018-05-31T06:06:21 *** bitconner has quit IRC
582018-05-31T06:06:44 <fanquake> wumpus very trendy code :p
592018-05-31T06:08:56 *** bitconner has joined #bitcoin-core-dev
602018-05-31T06:11:34 *** jtimon has quit IRC
612018-05-31T06:13:47 <wumpus> fanquake: thanks :p
622018-05-31T06:14:24 *** wumpus sets mode: -b *!~arowser@45.32.248.113
632018-05-31T06:14:30 <wumpus> (let's try again...)
642018-05-31T06:16:31 *** arowser_ has joined #bitcoin-core-dev
652018-05-31T06:18:18 <wumpus> #13337 is strange, did OpenBSD 5.3 really break grep somehow?
662018-05-31T06:18:20 <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
672018-05-31T06:18:32 <wumpus> s/5.3/6.3
682018-05-31T06:19:24 <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
692018-05-31T06:20:28 *** arowser_ has quit IRC
702018-05-31T06:20:46 *** arowser_ has joined #bitcoin-core-dev
712018-05-31T06:21:07 <sipa> wumpus: ha
722018-05-31T06:21:14 <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.
732018-05-31T06:21:22 <fanquake> wumpus I thought practicalswift had tested on 6.3, #13294, thought they might have picked that up?
742018-05-31T06:21:24 <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
752018-05-31T06:21:53 <fanquake> Also looks like arowser_ still needs blocking
762018-05-31T06:22:21 <sipa> wumpus: gcc 5 or clang 3.4, which is in ubuntu 16.04
772018-05-31T06:22:27 <mryandao> there's a ##fix_your_connection ban redirection so the user gets informed to fix their connection
782018-05-31T06:22:40 <mryandao> the mods in #bitcoin do that.
792018-05-31T06:22:50 <wumpus> sipa: but what about debian :(
802018-05-31T06:22:52 <sipa> wumpus: on the other hand - c++14 doesn't add all that much either
812018-05-31T06:23:34 <wumpus> sipa: something we could do that is almost completely uncontroversial is: use c++14 features when avilable, fall back to something else otherwise
822018-05-31T06:23:36 <sipa> sigh... debian only has gcc 5 in unstande :(
832018-05-31T06:23:41 <sipa> *unstable
842018-05-31T06:23:46 <wumpus> not *require* it
852018-05-31T06:24:08 <wumpus> could always drop support for c++11 only compilers at some point later
862018-05-31T06:24:08 <sipa> debian jessie has clang 3.4 though
872018-05-31T06:24:55 <wumpus> and could be as simple as removing some ifdef-ed code
882018-05-31T06:25:22 <wumpus> fanquake: we should ask him if he ran 'gmake check'
892018-05-31T06:25:37 <sipa> wumpus: seems almost not worth it
902018-05-31T06:25:49 <fanquake> wumpus Can do
912018-05-31T06:27:46 *** arowser_ has quit IRC
922018-05-31T06:28:05 *** arowser_ has joined #bitcoin-core-dev
932018-05-31T06:28:15 <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.
942018-05-31T06:28:40 <sipa> yes, i agree - i didn't expect it would hurt debian so much
952018-05-31T06:28:42 *** wumpus sets mode: +b *!~arowser@45.32.248.113
962018-05-31T06:28:55 <fanquake> Have we ever bumped before. I think we've just defined minimums?
972018-05-31T06:29:02 <fanquake> *fairly recently
982018-05-31T06:29:19 <sipa> the switch to c++11 made us require gcc 4.7
992018-05-31T06:30:19 <wumpus> yep, and there were complaints about users about that
1002018-05-31T06:30:20 <fanquake> 4.8+ i think?
1012018-05-31T06:30:23 <wumpus> from users
1022018-05-31T06:30:58 <fanquake> #11732
1032018-05-31T06:30:59 <gribble> https://github.com/bitcoin/bitcoin/issues/11732 | RFC: bump GCC requirement to 4.8 · Issue #11732 · bitcoin/bitcoin · GitHub
1042018-05-31T06:31:08 <sipa> i think the most useful things in c++14 for us may be support for shared_lock
1052018-05-31T06:32:32 <sipa> oh, no, that's c++17
1062018-05-31T06:32:33 <sipa> pff :)
1072018-05-31T06:33:02 <sipa> wikipedia is wrong!
1082018-05-31T06:34:04 *** arowser_ has quit IRC
1092018-05-31T06:34:30 <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?
1102018-05-31T06:35:20 <sipa> jonasschnelli: pubkeys are not scripts
1112018-05-31T06:35:27 <sipa> so no
1122018-05-31T06:35:37 <jonasschnelli> But how would xpubs be different?
1132018-05-31T06:35:54 <jonasschnelli> If we accept xpubs, whats the rational not not accept pubkeys?
1142018-05-31T06:36:00 <sipa> ah, sorry
1152018-05-31T06:36:13 <jonasschnelli> Either we derive different script types or not I guess
1162018-05-31T06:36:15 <sipa> you could have xpub+derivation type, or pub+derivation type, or script, or address
1172018-05-31T06:36:41 <jonasschnelli> so avoid to derive various types,... yeah. makes sense.
1182018-05-31T06:36:52 <jonasschnelli> Could accept n derivation types per pubkey
1192018-05-31T06:36:52 <sipa> jonasschnelli: you want me to write up a prototype of what that could look like?
1202018-05-31T06:36:57 <sipa> i've been wanting to do that for a while
1212018-05-31T06:37:12 <jonasschnelli> sipa: Please do if you want,.. i'm currently rewriting the API
1222018-05-31T06:39:15 <sipa> wumpus: ah, i'm wrong... c++14 has shared_lock and shared_timed_mutex; c++17 adds shared_mutex
1232018-05-31T06:39:36 <jonasschnelli> I would say [ {"address": <addr>, "pubkey" : {Â "pubkey" : <pubkey>, "derivation": ["P2PKH", "P2SH-P2WPKH", ...]}, "script" : <script>, "xpub" : { "xpub" : <xpub>, "derivation": [], "lookupwindow": [0, 1000]}, [...]}
1242018-05-31T06:39:49 <jonasschnelli> (hard to read JSON on IRC)
1252018-05-31T06:40:30 <sipa> jonasschnelli: also needs birthdate, ranges, ...
1262018-05-31T06:40:57 <wumpus> sipa: it's like boost::shared_mutex?
1272018-05-31T06:41:02 <sipa> wumpus: yup
1282018-05-31T06:41:03 <jonasschnelli> sipa: why birthdate? what ranges? (for other purposes then scantxoutset)?
1292018-05-31T06:41:10 *** CubicEarths has joined #bitcoin-core-dev
1302018-05-31T06:41:30 <sipa> jonasschnelli: i guess for scantxoutset birthdates don't matter, but for the wallet they will :)
1312018-05-31T06:41:50 <jonasschnelli> Yes. Ah. I see. You want to specify a generic format.
1322018-05-31T06:42:14 <sipa> jonasschnelli: my goal is making the entire wallet a list of such records (plus private keys, labels) and cached data (transactions, keypools)
1332018-05-31T06:42:19 <jonasschnelli> sipa: do you mean the xpub derive range with "ranges"?
1342018-05-31T06:42:27 <sipa> jonasschnelli: yes
1352018-05-31T06:42:42 <jonasschnelli> okay. The JSON above has the "loopupwindow" 2 size array.
1362018-05-31T06:43:42 <jonasschnelli> Maybe add something to you gist and we can build new RPC APIs (and migrate old ones if possible) according that parameter object.
1372018-05-31T06:43:55 <sipa> will do tomorrow
1382018-05-31T06:43:56 <wumpus> sipa: right, that's useful, didn't know we were already using it in sigcache
1392018-05-31T06:44:01 <jonasschnelli> sure. Thanks!
1402018-05-31T06:47:10 <sipa> wumpus: but not worth breaking building on debian for
1412018-05-31T06:48:03 <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.
1422018-05-31T06:48:13 <sipa> oh, i misread
1432018-05-31T06:48:19 <sipa> debian stable has gcc 6
1442018-05-31T06:49:14 <wumpus> stable has gcc 6? that sounds unlikely
1452018-05-31T06:49:27 <sipa> https://packages.debian.org/stretch/gcc-6
1462018-05-31T06:50:13 <wumpus> I see. Now I'm confused.
1472018-05-31T06:50:48 <sipa> i was confused by https://packages.debian.org/stretch/gcc having prefix "4:"
1482018-05-31T06:50:50 <wumpus> with debian stable having a more recent compiler than even ubuntu 16.04
1492018-05-31T06:51:23 <sipa> debian stable was released in june 2017
1502018-05-31T06:51:41 <sipa> which is a year after ubuntu 16.04
1512018-05-31T06:53:02 <sipa> jessie, the previous stable has gcc 4.9
1522018-05-31T06:53:39 *** CubicEarths has quit IRC
1532018-05-31T06:53:42 <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
1542018-05-31T06:54:23 *** CubicEarths has joined #bitcoin-core-dev
1552018-05-31T06:57:25 <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)
1562018-05-31T07:02:09 *** lxer has joined #bitcoin-core-dev
1572018-05-31T07:02:25 <fanquake> cfields likely to tell us why it can't happen for another few years heh
1582018-05-31T07:02:34 <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?
1592018-05-31T07:04:10 <wumpus> fanquake: cfields and me take turns at being bad cop
1602018-05-31T07:05:04 <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"
1612018-05-31T07:05:53 <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
1622018-05-31T07:06:39 <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.
1632018-05-31T07:08:10 <sipa> clang4 has c++14
1642018-05-31T07:08:11 <wumpus> <sipa> wumpus: gcc 5 or clang 3.4 ohh
1652018-05-31T07:08:14 <wumpus> right.
1662018-05-31T07:08:36 <sipa> also, fwiw, our code compiles with c++14 without changes (haven't tested)
1672018-05-31T07:08:56 <wumpus> c++14 is consistently older, version-wise, than I expect
1682018-05-31T07:09:32 <sipa> so c++11 took ages after standardization before it was available in compilers
1692018-05-31T07:09:45 <sipa> c++14 was a small change, and pretty much implemented before the spec was published
1702018-05-31T07:11:10 <wumpus> it shows
1712018-05-31T07:11:39 <sipa> 18 months between c++11 published and gcc fully supporting it
1722018-05-31T07:12:03 <sipa> 4 months between c++14 published and gcc fully supporting it
1732018-05-31T07:12:59 <sipa> c++17 will take longer again (it's already 5 months, and gcc only has experimental support)
1742018-05-31T07:16:02 *** CubicEar_ has joined #bitcoin-core-dev
1752018-05-31T07:16:15 *** CubicEarths has quit IRC
1762018-05-31T07:16:15 *** CubicEar_ has quit IRC
1772018-05-31T07:16:53 *** CubicEarths has joined #bitcoin-core-dev
1782018-05-31T07:20:17 *** CubicEarths has quit IRC
1792018-05-31T07:23:16 <fanquake> Decent speedups in #13309. Few ACKs if you want to take a look wumpus
1802018-05-31T07:23:18 <gribble> https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub
1812018-05-31T07:27:24 *** AaronvanW has joined #bitcoin-core-dev
1822018-05-31T07:31:42 <wumpus> fanquake: yes I need to have a look at that one, it seemed quite tricky,but agree it's probably worth it
1832018-05-31T07:31:54 *** AaronvanW has quit IRC
1842018-05-31T07:32:57 <wumpus> sipa: running c++14 experiments, on clang 7.0 the build passes with -std=c++14, no changes necessary
1852018-05-31T07:34:55 <fanquake> At least we'd only have to bump Clang to 3.4 (from 3.3) for ++14 support
1862018-05-31T07:35:26 <wumpus> (that's my straight-from-git build environment though, let's wait for openbsd clang4 results...)
1872018-05-31T07:39:46 *** LeMiner has joined #bitcoin-core-dev
1882018-05-31T07:47:18 <wumpus> (passed too)
1892018-05-31T07:49:15 <wumpus> fanquake: I wonder if we can get anyone to test with clang/llvm 3.4
1902018-05-31T07:49:31 <wumpus> I don't seem to have that installed anywhere
1912018-05-31T07:50:56 <wumpus> in an case, this is the trivial build system patch for building with c++14: https://gist.github.com/laanwj/e84d17412a5811ef4b7bd7512218c01a
1922018-05-31T07:52:07 <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
1932018-05-31T07:52:58 <sipa> configure or compile errors?
1942018-05-31T07:53:11 <sipa> that CXX version script does not support c++17 yet
1952018-05-31T07:53:37 <wumpus> I had updated that - yes, compile errors
1962018-05-31T07:59:08 <wumpus> some fairly silly stuff, I can't find the patch stack right now
1972018-05-31T08:02:46 <sipa> well, we're not going to adopt c++17 so who cares
1982018-05-31T08:03:40 <wumpus> exactly
1992018-05-31T08:03:58 <fanquake> fwiw That's the first error error I see passing in c++17 https://gist.github.com/fanquake/2342c585c43f945428d0f20eb1d8a1d6
2002018-05-31T08:04:59 *** Victorsueca has quit IRC
2012018-05-31T08:05:19 <wumpus> that random_shuffle wasn't even there yet when experimented with c++17 last year
2022018-05-31T08:06:11 *** Victorsueca has joined #bitcoin-core-dev
2032018-05-31T08:06:52 <fanquake> Looks like it was deprecated, in c++ 14, must have been removed in ++17
2042018-05-31T08:07:31 <wumpus> tfw you learn that a function exists in the C++ library and it's already deprecated
2052018-05-31T08:12:31 <wumpus> at least it's not as bad as with rust
2062018-05-31T08:15:52 <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)
2072018-05-31T08:16:08 <fanquake> wumpus your patch + stdcxx m4 changes all that was required to make check with c++14
2082018-05-31T08:16:34 *** LeMiner has quit IRC
2092018-05-31T08:17:05 <fanquake> Don't bring up swift here, btc dev is one place I don't have to deal with that :p
2102018-05-31T08:17:17 <wumpus> sorry
2112018-05-31T08:18:54 <wumpus> just trying to put c++ in perspective, that the process they follow for changes is quite reasonable
2122018-05-31T08:21:24 <fanquake> Reasonable, but is it really "disruptive/10x/webscale" enough?
2132018-05-31T08:22:40 <sipa> we need an deep learning blockchain in the cloud
2142018-05-31T08:23:09 <wumpus> fanquake: hah, the kind of words that make you know for sure you want to avoid something
2152018-05-31T08:24:11 <wumpus> machine learning developments are going too fast, we need a block chain to anchor them down and make them less efficient
2162018-05-31T08:25:26 <fanquake> They'd just figure out how to escape the blockchain. Probably solve the oracle problem while they are at it.
2172018-05-31T08:27:23 <wumpus> heh, right, just a matter of the right incentives. If they figure out how to escape the blockchain so we can follow :)
2182018-05-31T08:32:49 <bitcoin-git> [bitcoin] practicalswift opened pull request #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (master...openbsd-gmake-check) https://github.com/bitcoin/bitcoin/pull/13355
2192018-05-31T08:34:14 <wumpus> fanquake: unless I've somehow messed up my methodology, #13309 takes test_bitcoin from 1m10.831s to 0m39.323s here
2202018-05-31T08:34:18 <gribble> https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub
2212018-05-31T08:34:52 *** promag has quit IRC
2222018-05-31T08:34:59 <fanquake> wumpus isn't that what is expected?
2232018-05-31T08:35:12 <fanquake> Or just more speed up than you thought?
2242018-05-31T08:35:27 <wumpus> it's more than I thought
2252018-05-31T08:35:48 <sipa> "sorry, NACK, this makes the tests too fast"
2262018-05-31T08:36:28 <wumpus> exactly :)
2272018-05-31T08:37:50 <wumpus> just like with cryptography, tests need to be slow to convince it's being done properly
2282018-05-31T08:40:50 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/472fe8a2ce9f...36fc8052f62b
2292018-05-31T08:40:50 <bitcoin-git> bitcoin/master 6b8b63a Martin Ankerl: Generic TransactionSignatureCreator works with both CTransaction and CMutableTransaction...
2302018-05-31T08:40:51 <bitcoin-git> bitcoin/master 36fc805 Wladimir J. van der Laan: Merge #13309: Directly operate with CMutableTransaction in SignSignature...
2312018-05-31T08:41:40 <bitcoin-git> [bitcoin] laanwj closed pull request #13309: Directly operate with CMutableTransaction in SignSignature (master...SignSignature-with-CMutableTransaction) https://github.com/bitcoin/bitcoin/pull/13309
2322018-05-31T08:47:46 <fanquake> Opened #13356 for some C++14 thoughts. Will add some more info shortly.
2332018-05-31T08:47:47 <gribble> https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub
2342018-05-31T08:51:01 *** b has joined #bitcoin-core-dev
2352018-05-31T08:51:24 *** b is now known as Guest47199
2362018-05-31T08:51:27 <wumpus> fanquake: awesome!
2372018-05-31T08:52:50 *** Guest47199 has quit IRC
2382018-05-31T08:55:54 <wumpus> it's really useful to create tracking issues for things like this
2392018-05-31T08:57:58 <fanquake> Yes, easy for useful info to get lost in multiple different discussions
2402018-05-31T08:58:24 <fanquake> pkg_add autoconf
2412018-05-31T08:58:34 <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
2422018-05-31T08:59:17 *** promag has joined #bitcoin-core-dev
2432018-05-31T09:03:49 <fanquake> Added. Will link to code soon.
2442018-05-31T09:09:09 <wumpus> I vaguely remember there are plans to use more shared mutexes in more places, from BlueMatt probably
2452018-05-31T09:10:00 *** promag has quit IRC
2462018-05-31T09:12:52 <wumpus> "Tuple addressing via type" some of these have a high risk of obfuscating code when used irresponsibly
2472018-05-31T09:17:07 <wumpus> std::exchange and std::make_unique seem nice, small things
2482018-05-31T09:17:34 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36fc8052f62b...24f70118414f
2492018-05-31T09:17:35 <bitcoin-git> bitcoin/master 493a166 Wladimir J. van der Laan: bench: Don't return a bool from main...
2502018-05-31T09:17:35 <bitcoin-git> bitcoin/master 24f7011 MarcoFalke: Merge #13349: bench: Don't return a bool from main...
2512018-05-31T09:18:17 *** rex4539 has quit IRC
2522018-05-31T09:18:29 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13349: bench: Don't return a bool from main (master...2017_05_bench_warning) https://github.com/bitcoin/bitcoin/pull/13349
2532018-05-31T09:19:01 *** ExtraCrispy has joined #bitcoin-core-dev
2542018-05-31T09:20:56 *** rex4539 has joined #bitcoin-core-dev
2552018-05-31T09:23:55 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/24f70118414f...87a9d03c0c1e
2562018-05-31T09:23:55 <bitcoin-git> bitcoin/master fa2d83e MarcoFalke: travis: Skip cache for lint stage
2572018-05-31T09:23:56 <bitcoin-git> bitcoin/master 87a9d03 MarcoFalke: Merge #13347: travis: Skip cache for lint stage...
2582018-05-31T09:24:37 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13347: travis: Skip cache for lint stage (master...Mf1806-travisLintNoCache) https://github.com/bitcoin/bitcoin/pull/13347
2592018-05-31T09:28:07 *** AaronvanW has joined #bitcoin-core-dev
2602018-05-31T09:32:41 *** BCBot_ has quit IRC
2612018-05-31T09:32:50 *** AaronvanW has quit IRC
2622018-05-31T09:33:11 *** BCBot has joined #bitcoin-core-dev
2632018-05-31T10:10:45 *** JackH has quit IRC
2642018-05-31T10:29:12 *** AaronvanW has joined #bitcoin-core-dev
2652018-05-31T10:33:27 *** AaronvanW has quit IRC
2662018-05-31T10:34:56 *** AaronvanW has joined #bitcoin-core-dev
2672018-05-31T10:42:47 *** Victorsueca has quit IRC
2682018-05-31T10:43:56 *** Victorsueca has joined #bitcoin-core-dev
2692018-05-31T10:49:30 *** AaronvanW has quit IRC
2702018-05-31T10:50:12 *** drizztbsd is now known as timothy
2712018-05-31T10:59:52 *** Krellan has quit IRC
2722018-05-31T11:00:36 *** Krellan has joined #bitcoin-core-dev
2732018-05-31T11:10:05 *** Randolf has quit IRC
2742018-05-31T11:11:24 *** Randolf has joined #bitcoin-core-dev
2752018-05-31T11:16:10 <bitcoin-git> [bitcoin] jl2012 opened pull request #13357: Accurately determine the use of SIGHASH_SINGLE in signing (master...signsingle) https://github.com/bitcoin/bitcoin/pull/13357
2762018-05-31T11:24:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2772018-05-31T11:24:49 *** jchysk has quit IRC
2782018-05-31T11:37:09 *** SopaXorzTaker has joined #bitcoin-core-dev
2792018-05-31T11:37:48 *** jchysk has joined #bitcoin-core-dev
2802018-05-31T11:49:47 *** keymone has joined #bitcoin-core-dev
2812018-05-31T11:56:54 *** bitconner has quit IRC
2822018-05-31T12:07:51 *** bitconner has joined #bitcoin-core-dev
2832018-05-31T12:08:54 *** zivl has joined #bitcoin-core-dev
2842018-05-31T12:12:03 *** bitconner has quit IRC
2852018-05-31T12:16:03 *** Chris_Stewart_5 has quit IRC
2862018-05-31T12:20:49 *** rex4539 has quit IRC
2872018-05-31T12:56:05 *** frog_ has joined #bitcoin-core-dev
2882018-05-31T13:03:23 *** zautomata has joined #bitcoin-core-dev
2892018-05-31T13:04:43 *** zautomata has quit IRC
2902018-05-31T13:04:43 *** zautomata has joined #bitcoin-core-dev
2912018-05-31T13:08:36 *** Krellan has quit IRC
2922018-05-31T13:09:25 *** Krellan has joined #bitcoin-core-dev
2932018-05-31T13:14:13 *** jtimon has joined #bitcoin-core-dev
2942018-05-31T13:14:39 *** frog_ has quit IRC
2952018-05-31T13:18:08 *** laurentmt has joined #bitcoin-core-dev
2962018-05-31T13:25:25 *** Guyver2 has joined #bitcoin-core-dev
2972018-05-31T13:26:27 *** laurentmt has quit IRC
2982018-05-31T13:31:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2992018-05-31T13:42:26 *** Emcy has quit IRC
3002018-05-31T13:43:52 *** fanquake has quit IRC
3012018-05-31T13:55:44 *** Emcy has joined #bitcoin-core-dev
3022018-05-31T14:04:21 *** AaronvanW has joined #bitcoin-core-dev
3032018-05-31T14:18:35 <MarcoFalke> jonasschnelli: I can see my review on https://github.com/bitcoin/bitcoin/pull/12196/files#diff-2497f9b95fc934233daa9cb4a45a9df2
3042018-05-31T14:23:30 *** m8tion has joined #bitcoin-core-dev
3052018-05-31T14:44:25 *** Sinclair6 has joined #bitcoin-core-dev
3062018-05-31T14:54:50 *** sunitram has joined #bitcoin-core-dev
3072018-05-31T14:59:39 *** sunitram has quit IRC
3082018-05-31T14:59:47 *** tripleslash has quit IRC
3092018-05-31T15:06:46 *** tripleslash has joined #bitcoin-core-dev
3102018-05-31T15:08:34 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13359: wallet: Directly operate with CMutableTransaction (master...Mf1806-avoidTxConstuctor) https://github.com/bitcoin/bitcoin/pull/13359
3112018-05-31T15:13:46 <bitcoin-git> [bitcoin] jl2012 opened pull request #13360: [Policy] Reject SIGHASH_SINGLE with output out of bound (master...insecure_single) https://github.com/bitcoin/bitcoin/pull/13360
3122018-05-31T15:16:52 *** Krellan has quit IRC
3132018-05-31T15:17:32 *** tripleslash has quit IRC
3142018-05-31T15:17:56 *** Krellan has joined #bitcoin-core-dev
3152018-05-31T15:30:27 *** tripleslash has joined #bitcoin-core-dev
3162018-05-31T15:32:14 *** timothy has quit IRC
3172018-05-31T15:32:53 *** luke-jr has quit IRC
3182018-05-31T15:36:43 *** timothy has joined #bitcoin-core-dev
3192018-05-31T15:40:32 <Chris_Stewart_5> can miners set their own sequence number in their coinbase input?
3202018-05-31T15:41:57 *** timothy has quit IRC
3212018-05-31T15:42:10 *** timothy has joined #bitcoin-core-dev
3222018-05-31T15:43:53 *** Randolf has quit IRC
3232018-05-31T15:46:02 *** luke-jr has joined #bitcoin-core-dev
3242018-05-31T15:48:49 <echeveria> Chris_Stewart_5: yes, there's no restriction on that.
3252018-05-31T15:49:56 *** Aaronvan_ has joined #bitcoin-core-dev
3262018-05-31T15:53:03 *** AaronvanW has quit IRC
3272018-05-31T15:53:22 *** Dizzle has joined #bitcoin-core-dev
3282018-05-31T16:01:45 *** AaronvanW has joined #bitcoin-core-dev
3292018-05-31T16:01:46 *** SopaXorzTaker has quit IRC
3302018-05-31T16:05:04 *** Aaronvan_ has quit IRC
3312018-05-31T16:06:53 <wumpus> Chris_Stewart_5: there's no requirement on the coinbase data except for BIP34 afaik
3322018-05-31T16:07:17 *** SopaXorzTaker has joined #bitcoin-core-dev
3332018-05-31T16:08:16 *** laurentmt has joined #bitcoin-core-dev
3342018-05-31T16:08:18 <Chris_Stewart_5> Thanks guys
3352018-05-31T16:10:41 <sipa> also the length of the coinbase scriptSig is between 2 and 100 bytes
3362018-05-31T16:10:59 <sipa> that's also a consensus rule; no idea why it's there
3372018-05-31T16:11:25 *** nekotribal has quit IRC
3382018-05-31T16:11:42 *** zivl has quit IRC
3392018-05-31T16:12:02 <wumpus> oh!
3402018-05-31T16:12:32 *** rex4539 has joined #bitcoin-core-dev
3412018-05-31T16:13:37 *** Randolf has joined #bitcoin-core-dev
3422018-05-31T16:16:35 *** jhfrontz1 has quit IRC
3432018-05-31T16:17:07 <echeveria> sipa isn't it more than 2 now with BIP30?
3442018-05-31T16:17:30 <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.
3452018-05-31T16:19:43 <cfields> TheCharlatan: symbols must be added for glibc funtions introduced since our minimum version
3462018-05-31T16:24:23 <sipa> echeveria: you mean BIP34 i assume; yes, except for the first few blocks
3472018-05-31T16:25:27 <wumpus> TheCharlatan: indeed, see src/compat/glibc_compat.cpp
3482018-05-31T16:26:35 <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
3492018-05-31T16:26:57 <wumpus> (glibc symbols are versioned)
3502018-05-31T16:29:32 *** nekotribal has joined #bitcoin-core-dev
3512018-05-31T16:31:16 *** ExtraCrispy has quit IRC
3522018-05-31T16:34:22 *** lnostdal has quit IRC
3532018-05-31T16:35:35 *** Randolf has quit IRC
3542018-05-31T16:41:06 <TheCharlatan> so future gitian Bionic builds will all have to be configure with --enable-glibc-back-compat ?
3552018-05-31T16:41:37 *** dcousens has quit IRC
3562018-05-31T16:42:51 *** dcousens has joined #bitcoin-core-dev
3572018-05-31T16:44:42 *** Krellan has quit IRC
3582018-05-31T16:54:51 *** Randolf has joined #bitcoin-core-dev
3592018-05-31T16:55:18 <wumpus> all linux gitian builds have always been built with thta
3602018-05-31T16:56:31 <wumpus> (well, to be correct, since 0.9.2)
3612018-05-31T16:56:36 *** jhfrontz has joined #bitcoin-core-dev
3622018-05-31T17:00:22 *** bitconner has joined #bitcoin-core-dev
3632018-05-31T17:05:12 *** bitconner has quit IRC
3642018-05-31T17:15:46 <wumpus> the gitian linux build even calls the symbol checker and fails if there are unexpected symbols
3652018-05-31T17:16:06 <wumpus> it should be pretty fool-proof
3662018-05-31T17:24:19 *** jtimon has quit IRC
3672018-05-31T17:25:38 *** brianhoffman has joined #bitcoin-core-dev
3682018-05-31T17:27:26 *** goatpig has joined #bitcoin-core-dev
3692018-05-31T17:30:00 *** m8tion has quit IRC
3702018-05-31T17:38:38 *** timothy has quit IRC
3712018-05-31T17:41:00 *** jhfrontz has quit IRC
3722018-05-31T17:45:47 *** jhfrontz has joined #bitcoin-core-dev
3732018-05-31T18:08:27 *** drexl has joined #bitcoin-core-dev
3742018-05-31T18:08:55 *** wumpus sets mode: -b *!~arowser@45.32.248.113
3752018-05-31T18:09:51 *** arowser_ has joined #bitcoin-core-dev
3762018-05-31T18:10:33 *** lnostdal has joined #bitcoin-core-dev
3772018-05-31T18:10:57 *** zivl has joined #bitcoin-core-dev
3782018-05-31T18:12:47 *** arowser_ has quit IRC
3792018-05-31T18:13:08 *** arowser_ has joined #bitcoin-core-dev
3802018-05-31T18:13:15 *** Krellan has joined #bitcoin-core-dev
3812018-05-31T18:14:05 *** lnostdal has quit IRC
3822018-05-31T18:14:15 <jonasschnelli> Thanks MarcoFalke, found it
3832018-05-31T18:16:04 *** arowser_ has quit IRC
3842018-05-31T18:16:14 *** lnostdal has joined #bitcoin-core-dev
3852018-05-31T18:16:23 *** arowser_ has joined #bitcoin-core-dev
3862018-05-31T18:18:18 *** arowser_ has quit IRC
3872018-05-31T18:18:37 *** arowser_ has joined #bitcoin-core-dev
3882018-05-31T18:20:29 *** jhfrontz has quit IRC
3892018-05-31T18:21:33 *** arowser_ has quit IRC
3902018-05-31T18:21:52 *** arowser_ has joined #bitcoin-core-dev
3912018-05-31T18:23:47 *** arowser_ has quit IRC
3922018-05-31T18:24:05 *** arowser_ has joined #bitcoin-core-dev
3932018-05-31T18:26:01 *** arowser_ has quit IRC
3942018-05-31T18:26:04 *** wumpus sets mode: +b *!~arowser@45.32.248.113
3952018-05-31T18:32:50 *** Randolf has quit IRC
3962018-05-31T18:38:09 *** jhfrontz has joined #bitcoin-core-dev
3972018-05-31T18:38:10 *** Randolf has joined #bitcoin-core-dev
3982018-05-31T18:42:49 *** promag has joined #bitcoin-core-dev
3992018-05-31T18:42:57 *** nmnkgl has joined #bitcoin-core-dev
4002018-05-31T18:47:37 *** Randolf has quit IRC
4012018-05-31T18:55:58 *** clarkmoody has joined #bitcoin-core-dev
4022018-05-31T19:01:20 * jonasschnelli *cough*
4032018-05-31T19:01:50 <luke-jr> don't die on us, jonasschnelli
4042018-05-31T19:01:54 * sipa *sneeze*
4052018-05-31T19:02:10 <jonasschnelli> heh.. meeting?
4062018-05-31T19:02:19 <wumpus> #startmeeting
4072018-05-31T19:02:19 <lightningbot> Meeting started Thu May 31 19:02:19 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4082018-05-31T19:02:19 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4092018-05-31T19:02:28 <jonasschnelli> hi
4102018-05-31T19:02:36 <promag> hi
4112018-05-31T19:02:40 <cfields> hi
4122018-05-31T19:02:47 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
4132018-05-31T19:02:51 <wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
4142018-05-31T19:03:35 <wumpus> proposed topics?
4152018-05-31T19:04:45 <sipa> c++14
4162018-05-31T19:04:56 <kanzure> hi.
4172018-05-31T19:05:00 <sipa> high-priority prs
4182018-05-31T19:05:02 <MarcoFalke> Is the rc1 out with an email?
4192018-05-31T19:05:11 <cfields> MarcoFalke: yes
4202018-05-31T19:05:14 <wumpus> I have one of my own: new "addr" P2P message to support 256-bit addresses, for TorV3 and I2P
4212018-05-31T19:05:41 <wumpus> yes, rc1 is out with email to bitcoin-core-dev mailing list
4222018-05-31T19:06:05 <wumpus> #topic High priority for review
4232018-05-31T19:06:29 <sipa> i'd like #13026 on the list
4242018-05-31T19:06:31 <gribble> https://github.com/bitcoin/bitcoin/issues/13026 | Fix include comment in src/interfaces/wallet.h by promag · Pull Request #13026 · bitcoin/bitcoin · GitHub
4252018-05-31T19:06:32 <sipa> eh
4262018-05-31T19:06:36 <sipa> #13062
4272018-05-31T19:06:38 <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
4282018-05-31T19:06:40 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
4292018-05-31T19:07:08 <wumpus> sipa: added
4302018-05-31T19:07:12 <sipa> dank
4312018-05-31T19:07:24 <jonasschnelli> +e
4322018-05-31T19:07:38 <wumpus> anything/anyone else?
4332018-05-31T19:07:53 <promag> #13111
4342018-05-31T19:07:55 <gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
4352018-05-31T19:07:56 <promag> please
4362018-05-31T19:08:12 <wumpus> ok
4372018-05-31T19:08:18 <promag> 1 per developer right?
4382018-05-31T19:08:18 <luke-jr> I'm trying to rebase rwconf today
4392018-05-31T19:08:22 <wumpus> promag: yes
4402018-05-31T19:08:30 <luke-jr> that seems like it's desirable, so we can get the GUI pruning in
4412018-05-31T19:08:44 <jonasschnelli> Thanks luke-jr
4422018-05-31T19:08:51 <wumpus> luke-jr: nice
4432018-05-31T19:09:11 <luke-jr> #11082 IIRC
4442018-05-31T19:09:13 <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
4452018-05-31T19:09:37 *** Nun has joined #bitcoin-core-dev
4462018-05-31T19:09:37 <jonasschnelli> #13058 is a quick review (in high prio), has already two tested ACKs. Plz anyone.
4472018-05-31T19:09:40 <gribble> https://github.com/bitcoin/bitcoin/issues/13058 | [wallet] `createwallet` RPC - create new wallet at runtime by jnewbery · Pull Request #13058 · bitcoin/bitcoin · GitHub
4482018-05-31T19:09:54 <jonasschnelli> This opens the door for a lot of things
4492018-05-31T19:10:08 *** Kvaciral has joined #bitcoin-core-dev
4502018-05-31T19:10:19 *** grubles has joined #bitcoin-core-dev
4512018-05-31T19:10:23 *** Emcy has quit IRC
4522018-05-31T19:11:25 <wumpus> luke-jr: yes, that one needs rebase
4532018-05-31T19:11:47 *** Nun has quit IRC
4542018-05-31T19:12:06 <wumpus> but added, also jnewbery's 13058
4552018-05-31T19:12:17 <wumpus> I think that's enough for this week :)
4562018-05-31T19:12:37 <wumpus> #topic C++14 (sipa)
4572018-05-31T19:12:40 <jonasschnelli> 13058 is already there.. just wanted to make people aware that its a easy review
4582018-05-31T19:13:35 <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
4592018-05-31T19:13:37 *** wintercooled has joined #bitcoin-core-dev
4602018-05-31T19:13:45 <sipa> gcc 5 and clang 3.4 fully implement it
4612018-05-31T19:14:06 <sipa> debian stable and ubuntu 16.04+ have gcc 5 - though as luke-jr points out, RHEL does not yet
4622018-05-31T19:14:12 *** promag has quit IRC
4632018-05-31T19:14:14 <wumpus> ref: #13356, as well as earlier discussion on IRC today
4642018-05-31T19:14:16 <gribble> https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub
4652018-05-31T19:14:19 <gmaxwell> Any idea when RHEL will?
4662018-05-31T19:14:27 <sipa> RHEL 8 will ship with GCC 7
4672018-05-31T19:14:35 <sipa> but when...?
4682018-05-31T19:14:39 <gmaxwell> I mean we basically have a half year lag on major versions...
4692018-05-31T19:14:56 <wumpus> yes so this would be 0.18 at soonest
4702018-05-31T19:15:07 <MarcoFalke> Agree with wumpus
4712018-05-31T19:15:09 <sipa> yeah, true - which would be released... march 2019?
4722018-05-31T19:15:13 *** AaronvanW has quit IRC
4732018-05-31T19:15:57 <wumpus> sipa: yes. that's the 0.17 planned release date + 6 months
4742018-05-31T19:16:13 <sipa> by that time probably most distro limitation concerns will have disappeared
4752018-05-31T19:16:14 <gmaxwell> also, whats in RHEL7 ? does it support enough of C++14 to cover the features we want?
4762018-05-31T19:16:34 <sipa> gmaxwell: RHEL7 has gcc 4.9... which barely supports c++11
4772018-05-31T19:17:13 <cfields> looks like 4.9 doesn't have relaxed constexpr, which is one of the big features
4782018-05-31T19:17:17 *** retrop99 has joined #bitcoin-core-dev
4792018-05-31T19:17:27 <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.
4802018-05-31T19:17:39 <wumpus> yep
4812018-05-31T19:17:48 *** promag_ has joined #bitcoin-core-dev
4822018-05-31T19:18:17 <ajtowns[m]> Ugh, did lightningbot die on me?
4832018-05-31T19:18:30 <wumpus> ajtowns[m]: don't die on us during the meeting!
4842018-05-31T19:19:11 <luke-jr> wumpus: (re rwconf, I'll ping you after I rebase it for the flag)
4852018-05-31T19:19:30 <wumpus> ok, so I think everyone agrees C++14 is a good thing for 0.18 (given RHEL at the time)?
4862018-05-31T19:20:05 <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.
4872018-05-31T19:20:42 <luke-jr> gmaxwell: well, that was after waiting for C++11 to be reasonably available ofc
4882018-05-31T19:20:44 <ajtowns[m]> No seems like matrix is just not seeing everything so flowing the meeting on my phone will be hopeless :(
4892018-05-31T19:20:49 <wumpus> yes, I was especially worried about debian stable, but apparently that's no problem this time
4902018-05-31T19:21:04 <luke-jr> btw, should we concern with CentOS or other RHEL respins?
4912018-05-31T19:21:16 <luke-jr> if RHEL 8 is just barely out, they might lag..
4922018-05-31T19:21:25 <gmaxwell> luke-jr: yes but even where it wasn't most people just solved it with binaries built on another system.
4932018-05-31T19:21:32 <cfields> gmaxwell: the second group also included many who refused to _run_ a c++11 binary, despite -static-libstdc++ negating abi issues.
4942018-05-31T19:21:47 <wumpus> debian stable has gcc *6* which is very good
4952018-05-31T19:22:02 <luke-jr> gmaxwell: I'm not sure that's viable for GUI
4962018-05-31T19:22:16 <BlueMatt> wait, when does previous rhel stop getting support?
4972018-05-31T19:22:18 <wumpus> 08:49 < sipa> https://packages.debian.org/stretch/gcc-6
4982018-05-31T19:22:26 <luke-jr> BlueMatt: a long long time AFAIK
4992018-05-31T19:22:30 <BlueMatt> I dont think we can force people to upgrade, though I also doubt we have almost any rhel users
5002018-05-31T19:22:51 <luke-jr> BlueMatt: even RHEL 5 from 2007 still has support
5012018-05-31T19:23:01 <BlueMatt> how long is opensuse supported?
5022018-05-31T19:23:02 <wumpus> luke-jr: -static-libstdc++ works fine if you link qt statically as well.
5032018-05-31T19:23:06 <BlueMatt> we may actually have opensuse users
5042018-05-31T19:23:11 <wumpus> luke-jr: (which is the default for depends builds)
5052018-05-31T19:23:16 <luke-jr> wumpus: but that breaks platform plugins?
5062018-05-31T19:23:21 <wumpus> luke-jr: who cares
5072018-05-31T19:23:45 <wumpus> luke-jr: we already ignore this, with building gitian qt executables statically against qt
5082018-05-31T19:24:04 <luke-jr> but people shouldn't be using those ideally
5092018-05-31T19:24:23 <luke-jr> BlueMatt: RHEL 5 support ends in 2020
5102018-05-31T19:24:31 <gmaxwell> when we made the c++11 upgrade anyone I encountered using old RHEL just used binaries built elsewhere.
5112018-05-31T19:24:33 <wumpus> luke-jr: and anyhow the only major user of that was ubuntu unity, which supported qt4 well only...
5122018-05-31T19:24:49 <sipa> RHEL 7 support is until 2024
5132018-05-31T19:24:52 <gmaxwell> The only people that were an issue were running two version old outdated debian stable, and just refused to deal with it.
5142018-05-31T19:25:00 <luke-jr> I don't think it's realistic to wait on "oldest supported RHEL"
5152018-05-31T19:25:06 <BlueMatt> gmaxwell: lol sounds like debian users
5162018-05-31T19:25:12 <wumpus> gmaxwell: I doubt c++14 will be more of a problem to them than c++11
5172018-05-31T19:25:19 <BlueMatt> luke-jr: no, I dont think it is either, was just asking
5182018-05-31T19:25:23 <wumpus> anyhow this is almost a year away
5192018-05-31T19:25:49 <sipa> there are rumors about RHEL 8 beta this month
5202018-05-31T19:25:50 <BlueMatt> is supported-ubuntu or supported-debian still not gonna support c++14 for 0.18?
5212018-05-31T19:25:52 <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.
5222018-05-31T19:25:55 <BlueMatt> it does seem a bit premature imho
5232018-05-31T19:26:12 <wumpus> clang4 is the most common on BSDs, and it supports C++14 already now
5242018-05-31T19:26:40 <BlueMatt> do we mostly just want it for shared mutex?
5252018-05-31T19:26:54 <BlueMatt> seems like we can do a mutex-wrapped shared_mutex pretty easily?
5262018-05-31T19:26:55 <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
5272018-05-31T19:26:59 <wumpus> I was really surprised about that and that caused me to drop all my reservations about it
5282018-05-31T19:27:04 * cfields wants generic lambdas and relaxed constexpr
5292018-05-31T19:28:21 <cfields> iirc there are also several handy container cleanups. Like try_emplace().
5302018-05-31T19:28:34 <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
5312018-05-31T19:29:06 <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
5322018-05-31T19:29:10 *** Krellan has quit IRC
5332018-05-31T19:29:13 <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
5342018-05-31T19:29:21 <luke-jr> it's not a big deal if people can't update right away..
5352018-05-31T19:29:34 <wumpus> so we can just move this to 0.19
5362018-05-31T19:29:37 <morcos> another 10 months seems long enough to me... we can't always be all things to all people
5372018-05-31T19:29:39 <wumpus> if 0.18 is controversial.
5382018-05-31T19:29:47 <sipa> how about we see after 0.17 branches off
5392018-05-31T19:29:52 <wumpus> yes
5402018-05-31T19:29:57 <sipa> or even later in the 0.18 cycle
5412018-05-31T19:30:05 <wumpus> that was my proposal too, let's make it depend on RHEL
5422018-05-31T19:30:05 <BlueMatt> yea
5432018-05-31T19:30:06 <BlueMatt> agreed
5442018-05-31T19:30:08 <luke-jr> I expect it won't be controversial
5452018-05-31T19:30:16 <sipa> there's nothing we can decide here right now - just bringing up potential issues is good in advance
5462018-05-31T19:30:20 <luke-jr> we're almost there already
5472018-05-31T19:30:36 <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
5482018-05-31T19:30:38 <wumpus> in any case I tried building with -std=c++14 on various platforms today, works without any compile issues.
5492018-05-31T19:30:44 <BlueMatt> its also a question of people running like one-version-back distro X
5502018-05-31T19:30:46 <wumpus> so there's really nothing to be done there
5512018-05-31T19:30:50 <BlueMatt> and if that breaks that'd be bad
5522018-05-31T19:30:54 <BlueMatt> cause shitloads of people do that
5532018-05-31T19:31:14 <luke-jr> BlueMatt: trusty isn't just one version back, is it?
5542018-05-31T19:31:29 <wumpus> with that reasoning, we shouldn't even require c++11 yet
5552018-05-31T19:31:29 <sipa> last *two* ubuntu LTSs are fine
5562018-05-31T19:31:46 <BlueMatt> I dont really care about tursty anymore, it was released in fucking 2014
5572018-05-31T19:31:47 <wumpus> there's no end to that - why not rewrite bitcoin core in C89 while you're at it :)
5582018-05-31T19:31:51 <BlueMatt> it would be nice to support xenial
5592018-05-31T19:31:58 <wumpus> it supports xenial
5602018-05-31T19:32:08 <BlueMatt> I mean I was mostly worried about debian anyway
5612018-05-31T19:32:08 <wumpus> xenial is gcc 5.4.0
5622018-05-31T19:32:09 <BlueMatt> but, yea
5632018-05-31T19:32:21 <sipa> debian oldstable is 4.8
5642018-05-31T19:32:30 <BlueMatt> when does debian oldstable stop?
5652018-05-31T19:32:34 <BlueMatt> like 1.5 years or something?
5662018-05-31T19:32:41 <sipa> when there is a new stable
5672018-05-31T19:32:44 <luke-jr> BlueMatt: Debian has an oldoldstable now :P
5682018-05-31T19:32:47 <wumpus> I even *tried* building c++14 bitcoin core on xenial today, it worked
5692018-05-31T19:32:58 <wumpus> let alone in march 2019...
5702018-05-31T19:33:00 <BlueMatt> luke-jr: yea, ok, fuck oldoldstable
5712018-05-31T19:33:06 <luke-jr> :D
5722018-05-31T19:33:08 <BlueMatt> sipa: yea, that was my question
5732018-05-31T19:33:17 <sipa> anyway, next topic?
5742018-05-31T19:33:30 <BlueMatt> mid-2019
5752018-05-31T19:33:35 <BlueMatt> which would imply like 0.19
5762018-05-31T19:33:37 <BlueMatt> depending on timeline
5772018-05-31T19:34:05 <sipa> i'm fine with not being able to *build* on debian oldstable
5782018-05-31T19:34:12 <wumpus> yes...
5792018-05-31T19:34:37 <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
5802018-05-31T19:34:46 <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.
5812018-05-31T19:34:51 <sipa> cfields: they're fixed
5822018-05-31T19:35:02 <cfields> woohoo!
5832018-05-31T19:35:09 <wumpus> github unicorns seem to be fixed
5842018-05-31T19:35:16 <wumpus> haven't encountered any this week, I think
5852018-05-31T19:35:28 <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
5862018-05-31T19:35:29 <jonasschnelli> Yes. They wrote back that they have deployed a fix
5872018-05-31T19:35:37 <sipa> ah, it was mr schnelli
5882018-05-31T19:35:46 <wumpus> cool.
5892018-05-31T19:36:19 <cfields> jonasschnelli: thanks for nagging :)
5902018-05-31T19:36:22 <sipa> wumpus: you had a topic?
5912018-05-31T19:36:24 <wumpus> #topic new "addr" P2P message to support 256-bit addresses (wumpus)
5922018-05-31T19:36:29 <wumpus> so I'd like to work on this
5932018-05-31T19:36:31 <sipa> concept ack
5942018-05-31T19:36:53 <BlueMatt> for new-style tor services, I presume?
5952018-05-31T19:36:54 <luke-jr> is 256- bit enough?
5962018-05-31T19:36:57 <BlueMatt> sounds like a good idea to me
5972018-05-31T19:37:02 <roasbeef> wumpus: +1
5982018-05-31T19:37:03 <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.
5992018-05-31T19:37:10 <wumpus> this is to support I2P
6002018-05-31T19:37:16 <wumpus> and the new TorV3 hidden services
6012018-05-31T19:37:16 <luke-jr> 256+8 seems better for future-proofing (8 bits to select a network schema)
6022018-05-31T19:37:20 <wumpus> yes, both use 256 bit
6032018-05-31T19:37:25 <wumpus> luke-jr: yes
6042018-05-31T19:37:32 <wumpus> that's my idea, also have a network id
6052018-05-31T19:37:34 <sipa> 256 bit + network class byte
6062018-05-31T19:37:39 <luke-jr> sgtm
6072018-05-31T19:37:44 <BlueMatt> + port? I know they dont need them but other things...who knows?
6082018-05-31T19:37:47 <sipa> so we can stop using onioncat embedding in ipv6
6092018-05-31T19:37:51 <BlueMatt> I mean whats an extra 4 bytes
6102018-05-31T19:37:53 <jonasschnelli> Not sure what plans sipa and gmaxwell may have with authentication.. not sure if that is overlapping with addr
6112018-05-31T19:37:56 <BlueMatt> err 2 bytes
6122018-05-31T19:37:58 <sipa> jonasschnelli: no overlap
6132018-05-31T19:38:01 <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
6142018-05-31T19:38:01 <wumpus> BlueMatt: yes, the port should still be there, good point
6152018-05-31T19:38:05 <luke-jr> could do a variable length :P
6162018-05-31T19:38:15 <jonasschnelli> Yes. I mean what roasbeef just said
6172018-05-31T19:38:18 <jonasschnelli> *meant
6182018-05-31T19:38:19 <sipa> roasbeef: that seems to defeat the purpose :(
6192018-05-31T19:38:27 <wumpus> roasbeef: should that be gossiped?
6202018-05-31T19:38:28 <roasbeef> how so?
6212018-05-31T19:38:34 <roasbeef> depends...
6222018-05-31T19:38:36 <sipa> that leaks identity
6232018-05-31T19:38:38 <sdaftuar> could this overlap with NODE_NETWORK_LIMITED etc to gossip block ranges that nodes might store and serve to the network?
6242018-05-31T19:38:40 <cfields> wumpus: any changes to serviceflags logic while you're at it?
6252018-05-31T19:38:45 <wumpus> cfields: no
6262018-05-31T19:38:47 <luke-jr> wumpus: please add multi-bit service flags
6272018-05-31T19:38:48 <wumpus> (preferably not)
6282018-05-31T19:38:52 <luke-jr> :x
6292018-05-31T19:38:56 <wumpus> I don't want too much scope creep
6302018-05-31T19:38:56 <cfields> heh
6312018-05-31T19:39:06 <sipa> roasbeef, jonasschnelli: oh!
6322018-05-31T19:39:19 <sipa> wait, are you just saying a bit to indicate "this peer supports encryption"?
6332018-05-31T19:39:23 <sipa> or rumouring pubkeys?
6342018-05-31T19:39:24 <wumpus> cfields: at least not as in "extend the service flags to arbitrary text" or something like that
6352018-05-31T19:39:31 <wumpus> cfields: if you need some more bits there, sure
6362018-05-31T19:39:32 <sipa> (i'm in favor of the first, against the latter)
6372018-05-31T19:39:41 <jonasschnelli> sdaftuar: don't we already pass around the service bits? Or can you be more specific about the NODE_NETWORK_LIMITED flag?
6382018-05-31T19:39:43 <roasbeef> i was saying rumouring pubkeys
6392018-05-31T19:39:47 <sipa> yeah, no
6402018-05-31T19:39:51 <roasbeef> how do you stop MiTM otherwise?
6412018-05-31T19:39:55 <BlueMatt> roasbeef: nooooo, we dont want to leak identity
6422018-05-31T19:40:01 <wumpus> cfields: the data to be gossiped should be fairly compact, after all
6432018-05-31T19:40:04 <sipa> roasbeef: out of band
6442018-05-31T19:40:07 <jonasschnelli> roasbeef: manual pairing only for now
6452018-05-31T19:40:07 <wumpus> cfields: but I'm interested in hearing your ideas
6462018-05-31T19:40:24 <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
6472018-05-31T19:40:55 <jonasschnelli> ?
6482018-05-31T19:40:56 <sipa> roasbeef: most connections don't need MitM protection, as there is no identity of the peer they're connecting yo
6492018-05-31T19:41:14 <roasbeef> true, and the ones that do can use an ssh like auth_keys structure i guess
6502018-05-31T19:41:16 <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"
6512018-05-31T19:41:19 <sipa> only situations where you're connecting to a friend's peer or a node you run yourself need authentication
6522018-05-31T19:41:21 <wumpus> sdaftuar: seems like something that will get outdated really soon
6532018-05-31T19:41:24 <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.
6542018-05-31T19:41:35 <luke-jr> sipa: well, keys can ensure the age of your peers, so the ISP can't MITM *everything*
6552018-05-31T19:41:38 <wumpus> sdaftuar: what you'd want to gossip is block storage policy, not range, I think
6562018-05-31T19:42:09 <luke-jr> sipa: eg, if you're on an untrusted wifi, it'd be nice to know you have peers you found at home
6572018-05-31T19:42:29 <jimpo> Wouldn't Tor v3 address leak identity?
6582018-05-31T19:42:33 <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
6592018-05-31T19:42:40 <roasbeef> jimpo: no more than tor v2
6602018-05-31T19:42:41 <wumpus> cfields: I really just want to support torv3 and I2P asap :)
6612018-05-31T19:42:42 <jonasschnelli> luke-jr: but how could you make sure those peers are trustworthy? They could even sell their auth-key, etc.
6622018-05-31T19:42:47 <sdaftuar> wumpus: yes, this is premature but i had imagined that we might store block heights % N or something, and communicate that
6632018-05-31T19:42:50 <sipa> jimpo: as much as IP addresses are an identity, yes
6642018-05-31T19:43:03 <cfields> wumpus: one potential improvement would be filtering based on specified nets. I don't think we can do that now, can we?
6652018-05-31T19:43:21 <luke-jr> jonasschnelli: you can't in any case; it just ensures some wifi access point isn't sybil'ing you
6662018-05-31T19:43:21 <jonasschnelli> sdaftuar, wumpus: do we have stats (impossible) how deep pruned peers do prune?
6672018-05-31T19:43:26 <wumpus> cfields: no, I don't think so
6682018-05-31T19:43:26 <jimpo> That seems similar to IP + BIP 151 pubkey then?
6692018-05-31T19:43:29 <cfields> (obviously we can/do after receipt)
6702018-05-31T19:43:30 <sipa> jimpo: the issue is being able to correlate multiple IP addresses belonging to the same node
6712018-05-31T19:43:42 *** jtimon has joined #bitcoin-core-dev
6722018-05-31T19:43:49 <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
6732018-05-31T19:43:53 <wumpus> cfields: clients use some weird heuristic to determine what peers to send AFAIK
6742018-05-31T19:43:57 <jimpo> Could BIP 151 blind pubkeys with the hash of the IP/port?
6752018-05-31T19:44:07 <luke-jr> sdaftuar: that was my idea with the seed
6762018-05-31T19:44:30 <jonasschnelli> jimpo: BIP 151 has no authentication
6772018-05-31T19:44:35 <sipa> jimpo: that's one possibility, yes - but even better is a technique that doesn't reveal pubkeys at all
6782018-05-31T19:44:57 <wumpus> issue for this is #2091
6792018-05-31T19:44:58 *** AaronvanW has joined #bitcoin-core-dev
6802018-05-31T19:44:59 <gribble> https://github.com/bitcoin/bitcoin/issues/2091 | Binding to multiple anonymous networks (esp. I2P) · Issue #2091 · bitcoin/bitcoin · GitHub
6812018-05-31T19:45:05 <cfields> sipa: speaking of which, any updates on the scheme you're scheming?
6822018-05-31T19:45:16 *** bitconner has joined #bitcoin-core-dev
6832018-05-31T19:45:21 <sipa> cfields: no, sorry
6842018-05-31T19:45:27 <cfields> np
6852018-05-31T19:45:40 <sipa> jimpo: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b has some arguments in favor
6862018-05-31T19:46:16 <jonasschnelli> however, to not distract, the 256+bit addr proposal should be written and discussion should continued on the ML
6872018-05-31T19:46:23 <sipa> agree
6882018-05-31T19:46:33 <wumpus> jonasschnelli: yes
6892018-05-31T19:46:36 <sipa> but it's something i've wanted to do since 2012 :)
6902018-05-31T19:46:41 <wumpus> jonasschnelli: I was just asking for ideas.
6912018-05-31T19:47:06 <wumpus> any other topics?
6922018-05-31T19:47:54 <jonasschnelli> Maybe a quick dive into seeder hardening?
6932018-05-31T19:48:12 <wumpus> #topic Seeder hardening (jonasschnelli)
6942018-05-31T19:48:20 <jonasschnelli> It seems like that most active DNS seeds pass around ABC/BCash peers...
6952018-05-31T19:48:33 <jonasschnelli> It's a cat and mouse game... but we could tighten the screws
6962018-05-31T19:48:52 <jonasschnelli> By checking for a recent block during crawling (expansive) or avoid protocol version >80000
6972018-05-31T19:49:06 <cfields> jonasschnelli: didn't they change magic?
6982018-05-31T19:49:24 <jonasschnelli> cfields: not sure,... maybe, but then there are still some zombies around.
6992018-05-31T19:49:24 <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
7002018-05-31T19:49:49 *** bitconner has quit IRC
7012018-05-31T19:49:53 <wumpus> having to run a bitcoind on seeder nodes sounds like prohibitively expensive
7022018-05-31T19:49:54 <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
7032018-05-31T19:50:04 <jonasschnelli> wumpus: yeah.. I dislike that as well
7042018-05-31T19:50:13 <sipa> my seeder node has a bitcoind... i'm more worried about the bandwidth increase from asking for blocks
7052018-05-31T19:50:20 <jonasschnelli> Maybe we should just keep an eye on it and start to form some thoughts
7062018-05-31T19:50:22 <sipa> asking for headers may be better
7072018-05-31T19:50:31 <wumpus> sipa: good point.
7082018-05-31T19:50:49 <sipa> i don't seem to have many ABC nodes
7092018-05-31T19:50:54 <jonasschnelli> Yeah. Bandwith... although you could disconnect after the header+a couple of txns
7102018-05-31T19:51:02 <sipa> 30 in my top 100k IPs
7112018-05-31T19:51:11 <wumpus> jonasschnelli: but how would you verify, if you don't actually receive the data?
7122018-05-31T19:51:12 <sipa> 13 in my top 10k
7132018-05-31T19:51:22 <wumpus> jonasschnelli: also it increases load on the nodes you're probing
7142018-05-31T19:51:23 <sipa> 1 in my top 1000
7152018-05-31T19:52:00 <jonasschnelli> Okay. Yes. That is a different image...
7162018-05-31T19:52:30 <jonasschnelli> Well,.. then nm..
7172018-05-31T19:52:46 <wumpus> jonasschnelli: the difference is strange
7182018-05-31T19:53:11 <jonasschnelli> I need to check my mainnet seed. I played with some options on the testnet seed... there its def. worse
7192018-05-31T19:53:17 <wumpus> jonasschnelli: you should probably check what your configuration differences with sipa are
7202018-05-31T19:53:25 <jonasschnelli> Indeed
7212018-05-31T19:53:44 <jonasschnelli> or if someone is trying to sybil my crawler. :)
7222018-05-31T19:54:07 <wumpus> hehe, probe through tor :)
7232018-05-31T19:54:37 <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
7242018-05-31T19:54:45 <jonasschnelli> since then I mostly crawl via tor
7252018-05-31T19:54:56 <wumpus> ohh maybe they're sybilling tor exit nodes then
7262018-05-31T19:55:04 <jonasschnelli> however, I double check and report back IF it is an issue
7272018-05-31T19:55:18 <jonasschnelli> wumpus: or that, yeah.
7282018-05-31T19:55:25 <wumpus> though I somehow doubt that would take the form of ... more ABC nodes
7292018-05-31T19:55:43 <cfields> jonasschnelli: you're filtering out non-segwit?
7302018-05-31T19:56:36 <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
7312018-05-31T19:56:49 <BlueMatt> my seeder has /always/ asked for one block
7322018-05-31T19:57:03 <BlueMatt> (but does not need a full node)
7332018-05-31T19:57:09 <sipa> BlueMatt: nice
7342018-05-31T19:57:24 <wumpus> BlueMatt: the only reason it would need a node is to ask for a recent one
7352018-05-31T19:57:28 <jonasschnelli> BlueMatt: hopefully your not asking for the genesis. :)
7362018-05-31T19:57:37 <BlueMatt> wumpus: I mean its an spv client so it does ask for a recent one
7372018-05-31T19:57:44 <wumpus> but asking after the ABC and gold forks it would be ok I guess
7382018-05-31T19:58:02 <jonasschnelli> BlueMatt: nice.
7392018-05-31T19:58:43 <wumpus> yes
7402018-05-31T19:59:06 <jonasschnelli> cat dnsseed.dump | grep "Bitcoin ABC" | grep " 1 " | wc -l
7412018-05-31T19:59:10 <jonasschnelli> 207 ips
7422018-05-31T19:59:24 <sipa> and: cat dnsseed.dump | head -n 1000 | grep ABC | wc ?
7432018-05-31T19:59:44 <jonasschnelli> 58 762 9526
7442018-05-31T19:59:53 <sipa> significantly more than for me
7452018-05-31T20:00:01 <sipa> (i have 1 with that command line)
7462018-05-31T20:00:10 <jonasschnelli> Strange... just checked... I don't crawl anymore via tor
7472018-05-31T20:00:17 <sipa> well, time's up
7482018-05-31T20:00:20 <wumpus> #endmeeting
7492018-05-31T20:00:20 <lightningbot> Meeting ended Thu May 31 20:00:20 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7502018-05-31T20:00:20 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.html
7512018-05-31T20:00:20 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.txt
7522018-05-31T20:00:20 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.log.html
7532018-05-31T20:00:42 <jonasschnelli> however,.. I'll investigate. If sipas seeder "is clean", then I guess its handable.
7542018-05-31T20:00:56 <wumpus> it's really strange
7552018-05-31T20:01:20 *** nmnkgl has quit IRC
7562018-05-31T20:02:04 <jonasschnelli> Would removing the database and "give-it-a-fresh-start" may help?
7572018-05-31T20:02:12 *** Victorsueca has quit IRC
7582018-05-31T20:02:53 <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
7592018-05-31T20:02:59 <gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
7602018-05-31T20:03:06 <jonasschnelli> doneing..
7612018-05-31T20:03:27 *** Victorsueca has joined #bitcoin-core-dev
7622018-05-31T20:03:35 <aj> wumpus: so matrix was managing to show me what you were saying, but nothing from anyone else
7632018-05-31T20:04:20 *** SopaXorzTaker has quit IRC
7642018-05-31T20:06:07 <cfields> achow101: the logs were nuked when the build was restarted. got a copy?
7652018-05-31T20:06:54 <achow101> No, but the first error was about TransactionSignatureCreator at sign.cpp:48
7662018-05-31T20:07:04 <achow101> it couldn't find TransactionSignatureCreator
7672018-05-31T20:08:57 *** grubles has quit IRC
7682018-05-31T20:09:04 <achow101> cfields: well all of the builds are still failing, so you have the logs now
7692018-05-31T20:09:20 <wumpus> aj: lol, weird, maybe becuase I have +o?
7702018-05-31T20:09:22 <cfields> ah, there we go
7712018-05-31T20:10:01 *** ChanServ sets mode: -o wumpus
7722018-05-31T20:10:23 <wumpus> aj: can I be invisible too now?
7732018-05-31T20:11:51 <MarcoFalke> achow101: Fails locally for me as well
7742018-05-31T20:12:09 <achow101> oh
7752018-05-31T20:12:36 <ajtowns[m]> Wumpus: nope your words still cross the ethereal boundaries
7762018-05-31T20:12:55 <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
7772018-05-31T20:13:26 <wumpus> ajtowns[m]: darn!
7782018-05-31T20:13:53 <MarcoFalke> achow101: Note that you have to rebase
7792018-05-31T20:14:02 <aj> wumpus: promag also makes it through, so you're not totally special fwiw
7802018-05-31T20:14:06 <MarcoFalke> This is a merge conflict (silent)
7812018-05-31T20:14:23 <MarcoFalke> travis always runs against merge(master, pull)
7822018-05-31T20:14:32 <achow101> MarcoFalke: I thought I rebased. maybe I didn't rebase far enough
7832018-05-31T20:14:45 <MarcoFalke> heh
7842018-05-31T20:14:56 *** Emcy has joined #bitcoin-core-dev
7852018-05-31T20:15:06 <MarcoFalke> git rebase 36fc8052f62b87b11b0366fefee5f38dc886aefd
7862018-05-31T20:15:20 <cfields> achow101: wow, that's a lot of inheritance. Try calling the parent instead of great-grandparent?
7872018-05-31T20:16:16 *** bitconner has joined #bitcoin-core-dev
7882018-05-31T20:16:55 <achow101> ok, now I see the problem.
7892018-05-31T20:17:17 <achow101> cfields: originall TransactionSignatureCreator was the parent..
7902018-05-31T20:17:23 <achow101> *originally
7912018-05-31T20:17:57 <cfields> achow101: I haven't really looked, but could you possibly inherit directly from the interface instead?
7922018-05-31T20:18:24 <achow101> cfields: the problem is that someone got rid of TransactionSignatureCreator in master and I hadn't rebased to that
7932018-05-31T20:18:35 <cfields> ah, ok
7942018-05-31T20:25:40 *** Lauda has joined #bitcoin-core-dev
7952018-05-31T20:29:05 *** Lauda_ has quit IRC
7962018-05-31T20:30:09 *** Krellan has joined #bitcoin-core-dev
7972018-05-31T20:30:29 *** Guyver2 has quit IRC
7982018-05-31T20:41:15 *** retrop99 has quit IRC
7992018-05-31T20:42:37 *** luke-jr has quit IRC
8002018-05-31T20:42:50 *** luke-jr has joined #bitcoin-core-dev
8012018-05-31T20:46:17 <echeveria> 2018-05-31 19:45:07.675057 Potential stale tip detected, will try using extra outbound peer (last tip update: 2128 seconds ago)
8022018-05-31T20:46:23 <echeveria> this seems pretty eager
8032018-05-31T20:47:03 *** luke-jr has quit IRC
8042018-05-31T20:47:13 *** luke-jr has joined #bitcoin-core-dev
8052018-05-31T20:47:25 <wumpus> ok wrote a post on the new addr message discussion: https://github.com/bitcoin/bitcoin/issues/2091#issuecomment-393673952
8062018-05-31T20:47:39 <wumpus> echeveria: on the other hand adding an extra outbound peer is not exactly a drastic measure
8072018-05-31T20:49:22 <echeveria> true.
8082018-05-31T21:04:44 *** clarkmoody has quit IRC
8092018-05-31T21:17:41 *** Aaronvan_ has joined #bitcoin-core-dev
8102018-05-31T21:17:50 *** promag_ has quit IRC
8112018-05-31T21:19:29 *** AaronvanW has quit IRC
8122018-05-31T21:26:15 *** wintercooled has quit IRC
8132018-05-31T21:33:21 <sipa> jonasschnelli: any reasons why the "address/script/xpub/derivation" descriptor can't be a single string?
8142018-05-31T21:34:25 <sipa> something like "address:..." or "script:..." or "p2wpkh:xpub..../0-2000"
8152018-05-31T21:36:05 *** AaronvanW has joined #bitcoin-core-dev
8162018-05-31T21:39:12 *** Aaronvan_ has quit IRC
8172018-05-31T21:40:51 *** Chris_Stewart_5 has quit IRC
8182018-05-31T21:47:23 *** laurentmt has quit IRC
8192018-05-31T22:01:04 *** echonaut7 has quit IRC
8202018-05-31T22:01:21 *** echonaut has joined #bitcoin-core-dev
8212018-05-31T22:04:17 *** Aaronvan_ has joined #bitcoin-core-dev
8222018-05-31T22:06:50 *** AaronvanW has quit IRC
8232018-05-31T22:07:45 *** Aaronvan_ has quit IRC
8242018-05-31T22:10:35 *** AaronvanW has joined #bitcoin-core-dev
8252018-05-31T22:20:51 *** AaronvanW has quit IRC
8262018-05-31T22:28:54 *** Joqer has joined #bitcoin-core-dev
8272018-05-31T22:31:33 *** AaronvanW has joined #bitcoin-core-dev
8282018-05-31T22:35:57 *** AaronvanW has quit IRC
8292018-05-31T22:37:02 *** rex4539 has quit IRC
8302018-05-31T22:45:23 *** AaronvanW has joined #bitcoin-core-dev
8312018-05-31T22:48:23 *** promag has joined #bitcoin-core-dev
8322018-05-31T22:49:21 *** zivl has quit IRC
8332018-05-31T22:54:24 *** grubles has joined #bitcoin-core-dev
8342018-05-31T22:57:05 *** Krellan has quit IRC
8352018-05-31T23:09:59 *** Joqer has quit IRC
8362018-05-31T23:21:12 *** Dizzle has quit IRC
8372018-05-31T23:28:41 *** Soligor has quit IRC
8382018-05-31T23:29:28 *** drexl has quit IRC
8392018-05-31T23:31:39 *** Soligor has joined #bitcoin-core-dev
8402018-05-31T23:33:44 *** promag has quit IRC
8412018-05-31T23:34:35 *** lxer has quit IRC
8422018-05-31T23:37:45 *** lxer has joined #bitcoin-core-dev
8432018-05-31T23:37:57 *** promag has joined #bitcoin-core-dev
8442018-05-31T23:39:03 *** promag_ has joined #bitcoin-core-dev
8452018-05-31T23:40:43 *** meshcollider has joined #bitcoin-core-dev
8462018-05-31T23:42:44 *** promag has quit IRC
8472018-05-31T23:43:55 *** promag_ has quit IRC
8482018-05-31T23:51:06 *** murrayn has quit IRC
8492018-05-31T23:52:00 *** murrayn has joined #bitcoin-core-dev