< * kallewoof>
feels the need to to read up on what's new in c++14
< 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?
< mryandao>
and also changing int64_t types for time to std::chronos::nanoseconds for better semantics
< 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?
< sipa>
kallewoof: not all that much; c++14 is mostly seen as a small fixup/extension of the things added in 11
<@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
< sipa>
wumpus: ha
<@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.
< fanquake>
wumpus I thought practicalswift had tested on 6.3, #13294, thought they might have picked that up?
< 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
< fanquake>
Also looks like arowser_ still needs blocking
< sipa>
wumpus: gcc 5 or clang 3.4, which is in ubuntu 16.04
< mryandao>
there's a ##fix_your_connection ban redirection so the user gets informed to fix their connection
< mryandao>
the mods in #bitcoin do that.
<@wumpus>
sipa: but what about debian :(
< sipa>
wumpus: on the other hand - c++14 doesn't add all that much either
<@wumpus>
sipa: something we could do that is almost completely uncontroversial is: use c++14 features when avilable, fall back to something else otherwise
< sipa>
sigh... debian only has gcc 5 in unstande :(
< sipa>
*unstable
<@wumpus>
not *require* it
<@wumpus>
could always drop support for c++11 only compilers at some point later
< sipa>
debian jessie has clang 3.4 though
<@wumpus>
and could be as simple as removing some ifdef-ed code
<@wumpus>
fanquake: we should ask him if he ran 'gmake check'
< sipa>
wumpus: seems almost not worth it
< fanquake>
wumpus Can do
<@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.
< sipa>
yes, i agree - i didn't expect it would hurt debian so much
< fanquake>
Have we ever bumped before. I think we've just defined minimums?
< fanquake>
*fairly recently
< sipa>
the switch to c++11 made us require gcc 4.7
<@wumpus>
yep, and there were complaints about users about that
< sipa>
jonasschnelli: also needs birthdate, ranges, ...
<@wumpus>
sipa: it's like boost::shared_mutex?
< sipa>
wumpus: yup
< jonasschnelli>
sipa: why birthdate? what ranges? (for other purposes then scantxoutset)?
< sipa>
jonasschnelli: i guess for scantxoutset birthdates don't matter, but for the wallet they will :)
< jonasschnelli>
Yes. Ah. I see. You want to specify a generic format.
< sipa>
jonasschnelli: my goal is making the entire wallet a list of such records (plus private keys, labels) and cached data (transactions, keypools)
< jonasschnelli>
sipa: do you mean the xpub derive range with "ranges"?
< sipa>
jonasschnelli: yes
< jonasschnelli>
okay. The JSON above has the "loopupwindow" 2 size array.
< jonasschnelli>
Maybe add something to you gist and we can build new RPC APIs (and migrate old ones if possible) according that parameter object.
< sipa>
will do tomorrow
<@wumpus>
sipa: right, that's useful, didn't know we were already using it in sigcache
< jonasschnelli>
sure. Thanks!
< sipa>
wumpus: but not worth breaking building on debian for
<@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.
<@wumpus>
with debian stable having a more recent compiler than even ubuntu 16.04
< sipa>
debian stable was released in june 2017
< sipa>
which is a year after ubuntu 16.04
< sipa>
jessie, the previous stable has gcc 4.9
<@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
<@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)
< fanquake>
cfields likely to tell us why it can't happen for another few years heh
< 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?
<@wumpus>
fanquake: cfields and me take turns at being bad cop
<@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"
<@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
<@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.
< sipa>
clang4 has c++14
<@wumpus>
<sipa> wumpus: gcc 5 or clang 3.4 ohh
<@wumpus>
right.
< sipa>
also, fwiw, our code compiles with c++14 without changes (haven't tested)
<@wumpus>
c++14 is consistently older, version-wise, than I expect
< sipa>
so c++11 took ages after standardization before it was available in compilers
< sipa>
c++14 was a small change, and pretty much implemented before the spec was published
<@wumpus>
it shows
< sipa>
18 months between c++11 published and gcc fully supporting it
< sipa>
4 months between c++14 published and gcc fully supporting it
< sipa>
c++17 will take longer again (it's already 5 months, and gcc only has experimental support)
< fanquake>
Decent speedups in #13309. Few ACKs if you want to take a look wumpus
<@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
< sipa>
configure or compile errors?
< sipa>
that CXX version script does not support c++17 yet
<@wumpus>
I had updated that - yes, compile errors
<@wumpus>
some fairly silly stuff, I can't find the patch stack right now
< sipa>
well, we're not going to adopt c++17 so who cares
<@wumpus>
that random_shuffle wasn't even there yet when experimented with c++17 last year
< fanquake>
Looks like it was deprecated, in c++ 14, must have been removed in ++17
<@wumpus>
tfw you learn that a function exists in the C++ library and it's already deprecated
<@wumpus>
at least it's not as bad as with rust
<@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)
< fanquake>
wumpus your patch + stdcxx m4 changes all that was required to make check with c++14
< fanquake>
Don't bring up swift here, btc dev is one place I don't have to deal with that :p
<@wumpus>
sorry
<@wumpus>
just trying to put c++ in perspective, that the process they follow for changes is quite reasonable
< fanquake>
Reasonable, but is it really "disruptive/10x/webscale" enough?
< sipa>
we need an deep learning blockchain in the cloud
<@wumpus>
fanquake: hah, the kind of words that make you know for sure you want to avoid something
<@wumpus>
machine learning developments are going too fast, we need a block chain to anchor them down and make them less efficient
< fanquake>
They'd just figure out how to escape the blockchain. Probably solve the oracle problem while they are at it.
<@wumpus>
heh, right, just a matter of the right incentives. If they figure out how to escape the blockchain so we can follow :)
< 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
<@wumpus>
fanquake: unless I've somehow messed up my methodology, #13309 takes test_bitcoin from 1m10.831s to 0m39.323s here
<@wumpus>
it's really useful to create tracking issues for things like this
< fanquake>
Yes, easy for useful info to get lost in multiple different discussions
< fanquake>
pkg_add autoconf
<@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
< fanquake>
Added. Will link to code soon.
<@wumpus>
I vaguely remember there are plans to use more shared mutexes in more places, from BlueMatt probably
<@wumpus>
"Tuple addressing via type" some of these have a high risk of obfuscating code when used irresponsibly
<@wumpus>
std::exchange and std::make_unique seem nice, small things
< 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
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13359: wallet: Directly operate with CMutableTransaction (master...Mf1806-avoidTxConstuctor) https://github.com/bitcoin/bitcoin/pull/13359
< 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
< Chris_Stewart_5>
can miners set their own sequence number in their coinbase input?
< echeveria>
Chris_Stewart_5: yes, there's no restriction on that.
<@wumpus>
Chris_Stewart_5: there's no requirement on the coinbase data except for BIP34 afaik
< Chris_Stewart_5>
Thanks guys
< sipa>
also the length of the coinbase scriptSig is between 2 and 100 bytes
< sipa>
that's also a consensus rule; no idea why it's there
<@wumpus>
oh!
< echeveria>
sipa isn't it more than 2 now with BIP30?
< 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.
< cfields>
TheCharlatan: symbols must be added for glibc funtions introduced since our minimum version
< sipa>
echeveria: you mean BIP34 i assume; yes, except for the first few blocks
<@wumpus>
TheCharlatan: indeed, see src/compat/glibc_compat.cpp
<@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
<@wumpus>
(glibc symbols are versioned)
< TheCharlatan>
so future gitian Bionic builds will all have to be configure with --enable-glibc-back-compat ?
<@wumpus>
all linux gitian builds have always been built with thta
<@wumpus>
(well, to be correct, since 0.9.2)
<@wumpus>
the gitian linux build even calls the symbol checker and fails if there are unexpected symbols
<@wumpus>
it should be pretty fool-proof
< jonasschnelli>
Thanks MarcoFalke, found it
< * jonasschnelli>
*cough*
< luke-jr>
don't die on us, jonasschnelli
< * sipa>
*sneeze*
< jonasschnelli>
heh.. meeting?
<@wumpus>
#startmeeting
< lightningbot>
Meeting started Thu May 31 19:02:19 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< luke-jr>
that seems like it's desirable, so we can get the GUI pruning in
< jonasschnelli>
Thanks luke-jr
<@wumpus>
luke-jr: nice
< luke-jr>
#11082 IIRC
< 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
< jonasschnelli>
#13058 is a quick review (in high prio), has already two tested ACKs. Plz anyone.
< gmaxwell>
I mean we basically have a half year lag on major versions...
<@wumpus>
yes so this would be 0.18 at soonest
< MarcoFalke>
Agree with wumpus
< sipa>
yeah, true - which would be released... march 2019?
<@wumpus>
sipa: yes. that's the 0.17 planned release date + 6 months
< sipa>
by that time probably most distro limitation concerns will have disappeared
< gmaxwell>
also, whats in RHEL7 ? does it support enough of C++14 to cover the features we want?
< sipa>
gmaxwell: RHEL7 has gcc 4.9... which barely supports c++11
< cfields>
looks like 4.9 doesn't have relaxed constexpr, which is one of the big features
< 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.
<@wumpus>
yep
< ajtowns[m]>
Ugh, did lightningbot die on me?
<@wumpus>
ajtowns[m]: don't die on us during the meeting!
< luke-jr>
wumpus: (re rwconf, I'll ping you after I rebase it for the flag)
<@wumpus>
ok, so I think everyone agrees C++14 is a good thing for 0.18 (given RHEL at the time)?
< 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.
< luke-jr>
gmaxwell: well, that was after waiting for C++11 to be reasonably available ofc
< ajtowns[m]>
No seems like matrix is just not seeing everything so flowing the meeting on my phone will be hopeless :(
<@wumpus>
yes, I was especially worried about debian stable, but apparently that's no problem this time
< luke-jr>
btw, should we concern with CentOS or other RHEL respins?
< luke-jr>
if RHEL 8 is just barely out, they might lag..
< gmaxwell>
luke-jr: yes but even where it wasn't most people just solved it with binaries built on another system.
< cfields>
gmaxwell: the second group also included many who refused to _run_ a c++11 binary, despite -static-libstdc++ negating abi issues.
<@wumpus>
debian stable has gcc *6* which is very good
< luke-jr>
gmaxwell: I'm not sure that's viable for GUI
< BlueMatt>
wait, when does previous rhel stop getting support?
< BlueMatt>
I dont think we can force people to upgrade, though I also doubt we have almost any rhel users
< luke-jr>
BlueMatt: even RHEL 5 from 2007 still has support
< BlueMatt>
how long is opensuse supported?
<@wumpus>
luke-jr: -static-libstdc++ works fine if you link qt statically as well.
< BlueMatt>
we may actually have opensuse users
<@wumpus>
luke-jr: (which is the default for depends builds)
< luke-jr>
wumpus: but that breaks platform plugins?
<@wumpus>
luke-jr: who cares
<@wumpus>
luke-jr: we already ignore this, with building gitian qt executables statically against qt
< luke-jr>
but people shouldn't be using those ideally
< luke-jr>
BlueMatt: RHEL 5 support ends in 2020
< gmaxwell>
when we made the c++11 upgrade anyone I encountered using old RHEL just used binaries built elsewhere.
<@wumpus>
luke-jr: and anyhow the only major user of that was ubuntu unity, which supported qt4 well only...
< sipa>
RHEL 7 support is until 2024
< gmaxwell>
The only people that were an issue were running two version old outdated debian stable, and just refused to deal with it.
< luke-jr>
I don't think it's realistic to wait on "oldest supported RHEL"
< BlueMatt>
gmaxwell: lol sounds like debian users
<@wumpus>
gmaxwell: I doubt c++14 will be more of a problem to them than c++11
< BlueMatt>
luke-jr: no, I dont think it is either, was just asking
<@wumpus>
anyhow this is almost a year away
< sipa>
there are rumors about RHEL 8 beta this month
< BlueMatt>
is supported-ubuntu or supported-debian still not gonna support c++14 for 0.18?
< 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.
< BlueMatt>
it does seem a bit premature imho
<@wumpus>
clang4 is the most common on BSDs, and it supports C++14 already now
< BlueMatt>
do we mostly just want it for shared mutex?
< BlueMatt>
seems like we can do a mutex-wrapped shared_mutex pretty easily?
< 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
<@wumpus>
I was really surprised about that and that caused me to drop all my reservations about it
< * cfields>
wants generic lambdas and relaxed constexpr
< cfields>
iirc there are also several handy container cleanups. Like try_emplace().
<@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
< 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
< 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
< luke-jr>
it's not a big deal if people can't update right away..
<@wumpus>
so we can just move this to 0.19
< morcos>
another 10 months seems long enough to me... we can't always be all things to all people
<@wumpus>
if 0.18 is controversial.
< sipa>
how about we see after 0.17 branches off
<@wumpus>
yes
< sipa>
or even later in the 0.18 cycle
<@wumpus>
that was my proposal too, let's make it depend on RHEL
< BlueMatt>
yea
< BlueMatt>
agreed
< luke-jr>
I expect it won't be controversial
< sipa>
there's nothing we can decide here right now - just bringing up potential issues is good in advance
< luke-jr>
we're almost there already
< 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
<@wumpus>
in any case I tried building with -std=c++14 on various platforms today, works without any compile issues.
< BlueMatt>
its also a question of people running like one-version-back distro X
<@wumpus>
so there's really nothing to be done there
< BlueMatt>
and if that breaks that'd be bad
< BlueMatt>
cause shitloads of people do that
< luke-jr>
BlueMatt: trusty isn't just one version back, is it?
<@wumpus>
with that reasoning, we shouldn't even require c++11 yet
< sipa>
last *two* ubuntu LTSs are fine
< BlueMatt>
I dont really care about tursty anymore, it was released in fucking 2014
<@wumpus>
there's no end to that - why not rewrite bitcoin core in C89 while you're at it :)
< BlueMatt>
it would be nice to support xenial
<@wumpus>
it supports xenial
< BlueMatt>
I mean I was mostly worried about debian anyway
<@wumpus>
xenial is gcc 5.4.0
< BlueMatt>
but, yea
< sipa>
debian oldstable is 4.8
< BlueMatt>
when does debian oldstable stop?
< BlueMatt>
like 1.5 years or something?
< sipa>
when there is a new stable
< luke-jr>
BlueMatt: Debian has an oldoldstable now :P
<@wumpus>
I even *tried* building c++14 bitcoin core on xenial today, it worked
<@wumpus>
let alone in march 2019...
< BlueMatt>
luke-jr: yea, ok, fuck oldoldstable
< luke-jr>
:D
< BlueMatt>
sipa: yea, that was my question
< sipa>
anyway, next topic?
< BlueMatt>
mid-2019
< BlueMatt>
which would imply like 0.19
< BlueMatt>
depending on timeline
< sipa>
i'm fine with not being able to *build* on debian oldstable
<@wumpus>
yes...
< 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
< 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.
< sipa>
cfields: they're fixed
< cfields>
woohoo!
<@wumpus>
github unicorns seem to be fixed
<@wumpus>
haven't encountered any this week, I think
< 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
< jonasschnelli>
Yes. They wrote back that they have deployed a fix
< sipa>
ah, it was mr schnelli
<@wumpus>
cool.
< cfields>
jonasschnelli: thanks for nagging :)
< sipa>
wumpus: you had a topic?
<@wumpus>
#topic new "addr" P2P message to support 256-bit addresses (wumpus)
<@wumpus>
so I'd like to work on this
< sipa>
concept ack
< BlueMatt>
for new-style tor services, I presume?
< luke-jr>
is 256- bit enough?
< BlueMatt>
sounds like a good idea to me
< roasbeef>
wumpus: +1
<@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.
<@wumpus>
this is to support I2P
<@wumpus>
and the new TorV3 hidden services
< luke-jr>
256+8 seems better for future-proofing (8 bits to select a network schema)
<@wumpus>
yes, both use 256 bit
<@wumpus>
luke-jr: yes
<@wumpus>
that's my idea, also have a network id
< sipa>
256 bit + network class byte
< luke-jr>
sgtm
< BlueMatt>
+ port? I know they dont need them but other things...who knows?
< sipa>
so we can stop using onioncat embedding in ipv6
< BlueMatt>
I mean whats an extra 4 bytes
< jonasschnelli>
Not sure what plans sipa and gmaxwell may have with authentication.. not sure if that is overlapping with addr
< BlueMatt>
err 2 bytes
< sipa>
jonasschnelli: no overlap
< 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
<@wumpus>
BlueMatt: yes, the port should still be there, good point
< luke-jr>
could do a variable length :P
< jonasschnelli>
Yes. I mean what roasbeef just said
< jonasschnelli>
*meant
< sipa>
roasbeef: that seems to defeat the purpose :(
<@wumpus>
roasbeef: should that be gossiped?
< roasbeef>
how so?
< roasbeef>
depends...
< sipa>
that leaks identity
< sdaftuar>
could this overlap with NODE_NETWORK_LIMITED etc to gossip block ranges that nodes might store and serve to the network?
< cfields>
wumpus: any changes to serviceflags logic while you're at it?
<@wumpus>
cfields: no
< luke-jr>
wumpus: please add multi-bit service flags
<@wumpus>
(preferably not)
< luke-jr>
:x
<@wumpus>
I don't want too much scope creep
< cfields>
heh
< sipa>
roasbeef, jonasschnelli: oh!
< sipa>
wait, are you just saying a bit to indicate "this peer supports encryption"?
< sipa>
or rumouring pubkeys?
<@wumpus>
cfields: at least not as in "extend the service flags to arbitrary text" or something like that
<@wumpus>
cfields: if you need some more bits there, sure
< sipa>
(i'm in favor of the first, against the latter)
< jonasschnelli>
sdaftuar: don't we already pass around the service bits? Or can you be more specific about the NODE_NETWORK_LIMITED flag?
< roasbeef>
i was saying rumouring pubkeys
< sipa>
yeah, no
< roasbeef>
how do you stop MiTM otherwise?
< BlueMatt>
roasbeef: nooooo, we dont want to leak identity
<@wumpus>
cfields: the data to be gossiped should be fairly compact, after all
< sipa>
roasbeef: out of band
< jonasschnelli>
roasbeef: manual pairing only for now
<@wumpus>
cfields: but I'm interested in hearing your ideas
< 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
< jonasschnelli>
?
< sipa>
roasbeef: most connections don't need MitM protection, as there is no identity of the peer they're connecting yo
< roasbeef>
true, and the ones that do can use an ssh like auth_keys structure i guess
< 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"
< sipa>
only situations where you're connecting to a friend's peer or a node you run yourself need authentication
<@wumpus>
sdaftuar: seems like something that will get outdated really soon
< 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.
< luke-jr>
sipa: well, keys can ensure the age of your peers, so the ISP can't MITM *everything*
<@wumpus>
sdaftuar: what you'd want to gossip is block storage policy, not range, I think
< luke-jr>
sipa: eg, if you're on an untrusted wifi, it'd be nice to know you have peers you found at home
< jimpo>
Wouldn't Tor v3 address leak identity?
<@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
< roasbeef>
jimpo: no more than tor v2
<@wumpus>
cfields: I really just want to support torv3 and I2P asap :)
< jonasschnelli>
luke-jr: but how could you make sure those peers are trustworthy? They could even sell their auth-key, etc.
< sdaftuar>
wumpus: yes, this is premature but i had imagined that we might store block heights % N or something, and communicate that
< sipa>
jimpo: as much as IP addresses are an identity, yes
< cfields>
wumpus: one potential improvement would be filtering based on specified nets. I don't think we can do that now, can we?
< luke-jr>
jonasschnelli: you can't in any case; it just ensures some wifi access point isn't sybil'ing you
< jonasschnelli>
sdaftuar, wumpus: do we have stats (impossible) how deep pruned peers do prune?
<@wumpus>
cfields: no, I don't think so
< jimpo>
That seems similar to IP + BIP 151 pubkey then?
< cfields>
(obviously we can/do after receipt)
< sipa>
jimpo: the issue is being able to correlate multiple IP addresses belonging to the same node
< 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
<@wumpus>
cfields: clients use some weird heuristic to determine what peers to send AFAIK
< jimpo>
Could BIP 151 blind pubkeys with the hash of the IP/port?
< luke-jr>
sdaftuar: that was my idea with the seed
< jonasschnelli>
jimpo: BIP 151 has no authentication
< sipa>
jimpo: that's one possibility, yes - but even better is a technique that doesn't reveal pubkeys at all
< jonasschnelli>
however, to not distract, the 256+bit addr proposal should be written and discussion should continued on the ML
< sipa>
agree
<@wumpus>
jonasschnelli: yes
< sipa>
but it's something i've wanted to do since 2012 :)
<@wumpus>
jonasschnelli: I was just asking for ideas.
<@wumpus>
any other topics?
< jonasschnelli>
Maybe a quick dive into seeder hardening?
<@wumpus>
#topic Seeder hardening (jonasschnelli)
< jonasschnelli>
It seems like that most active DNS seeds pass around ABC/BCash peers...
< jonasschnelli>
It's a cat and mouse game... but we could tighten the screws
< jonasschnelli>
By checking for a recent block during crawling (expansive) or avoid protocol version >80000
< cfields>
jonasschnelli: didn't they change magic?
< jonasschnelli>
cfields: not sure,... maybe, but then there are still some zombies around.
<@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
<@wumpus>
having to run a bitcoind on seeder nodes sounds like prohibitively expensive
< 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
< jonasschnelli>
wumpus: yeah.. I dislike that as well
< sipa>
my seeder node has a bitcoind... i'm more worried about the bandwidth increase from asking for blocks
< jonasschnelli>
Maybe we should just keep an eye on it and start to form some thoughts
< sipa>
asking for headers may be better
<@wumpus>
sipa: good point.
< sipa>
i don't seem to have many ABC nodes
< jonasschnelli>
Yeah. Bandwith... although you could disconnect after the header+a couple of txns
< sipa>
30 in my top 100k IPs
<@wumpus>
jonasschnelli: but how would you verify, if you don't actually receive the data?
< sipa>
13 in my top 10k
<@wumpus>
jonasschnelli: also it increases load on the nodes you're probing
< sipa>
1 in my top 1000
< jonasschnelli>
Okay. Yes. That is a different image...
< jonasschnelli>
Well,.. then nm..
<@wumpus>
jonasschnelli: the difference is strange
< jonasschnelli>
I need to check my mainnet seed. I played with some options on the testnet seed... there its def. worse
<@wumpus>
jonasschnelli: you should probably check what your configuration differences with sipa are
< jonasschnelli>
Indeed
< jonasschnelli>
or if someone is trying to sybil my crawler. :)
<@wumpus>
hehe, probe through tor :)
< 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
< jonasschnelli>
since then I mostly crawl via tor
<@wumpus>
ohh maybe they're sybilling tor exit nodes then
< jonasschnelli>
however, I double check and report back IF it is an issue
< jonasschnelli>
wumpus: or that, yeah.
<@wumpus>
though I somehow doubt that would take the form of ... more ABC nodes
< cfields>
jonasschnelli: you're filtering out non-segwit?
< 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
< BlueMatt>
my seeder has /always/ asked for one block
< BlueMatt>
(but does not need a full node)
< sipa>
BlueMatt: nice
<@wumpus>
BlueMatt: the only reason it would need a node is to ask for a recent one
< jonasschnelli>
BlueMatt: hopefully your not asking for the genesis. :)
< BlueMatt>
wumpus: I mean its an spv client so it does ask for a recent one
<@wumpus>
but asking after the ABC and gold forks it would be ok I guess
< jonasschnelli>
however,.. I'll investigate. If sipas seeder "is clean", then I guess its handable.
<@wumpus>
it's really strange
< jonasschnelli>
Would removing the database and "give-it-a-fresh-start" may help?
< 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
< aj>
wumpus: so matrix was managing to show me what you were saying, but nothing from anyone else
< cfields>
achow101: the logs were nuked when the build was restarted. got a copy?
< achow101>
No, but the first error was about TransactionSignatureCreator at sign.cpp:48
< achow101>
it couldn't find TransactionSignatureCreator
< achow101>
cfields: well all of the builds are still failing, so you have the logs now
<@wumpus>
aj: lol, weird, maybe becuase I have +o?
< cfields>
ah, there we go
< wumpus>
aj: can I be invisible too now?
< MarcoFalke>
achow101: Fails locally for me as well
< achow101>
oh
< ajtowns[m]>
Wumpus: nope your words still cross the ethereal boundaries
< 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
< wumpus>
ajtowns[m]: darn!
< MarcoFalke>
achow101: Note that you have to rebase
< aj>
wumpus: promag also makes it through, so you're not totally special fwiw
< MarcoFalke>
This is a merge conflict (silent)
< MarcoFalke>
travis always runs against merge(master, pull)
< achow101>
MarcoFalke: I thought I rebased. maybe I didn't rebase far enough
< MarcoFalke>
heh
< MarcoFalke>
git rebase 36fc8052f62b87b11b0366fefee5f38dc886aefd
< cfields>
achow101: wow, that's a lot of inheritance. Try calling the parent instead of great-grandparent?
< achow101>
ok, now I see the problem.
< achow101>
cfields: originall TransactionSignatureCreator was the parent..
< achow101>
*originally
< cfields>
achow101: I haven't really looked, but could you possibly inherit directly from the interface instead?
< achow101>
cfields: the problem is that someone got rid of TransactionSignatureCreator in master and I hadn't rebased to that
< cfields>
ah, ok
< echeveria>
2018-05-31 19:45:07.675057 Potential stale tip detected, will try using extra outbound peer (last tip update: 2128 seconds ago)