19:02:19 <wumpus> #startmeeting
19: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.
19:02:19 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:28 <jonasschnelli> hi
19:02:36 <promag> hi
19:02:40 <cfields> hi
19: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
19:02:51 <wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:03:35 <wumpus> proposed topics?
19:04:45 <sipa> c++14
19:04:56 <kanzure> hi.
19:05:00 <sipa> high-priority prs
19:05:02 <MarcoFalke> Is the rc1 out with an email?
19:05:11 <cfields> MarcoFalke: yes
19:05:14 <wumpus> I have one of my own: new "addr" P2P message to support 256-bit addresses, for TorV3 and I2P
19:05:41 <wumpus> yes, rc1 is out with email to bitcoin-core-dev mailing list
19:06:05 <wumpus> #topic High priority for review
19:06:29 <sipa> i'd like #13026 on the list
19: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
19:06:32 <sipa> eh
19:06:36 <sipa> #13062
19: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
19:06:40 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:07:08 <wumpus> sipa: added
19:07:12 <sipa> dank
19:07:24 <jonasschnelli> +e
19:07:38 <wumpus> anything/anyone else?
19:07:53 <promag> #13111
19:07:55 <gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
19:07:56 <promag> please
19:08:12 <wumpus> ok
19:08:18 <promag> 1 per developer right?
19:08:18 <luke-jr> I'm trying to rebase rwconf today
19:08:22 <wumpus> promag: yes
19:08:30 <luke-jr> that seems like it's desirable, so we can get the GUI pruning in
19:08:44 <jonasschnelli> Thanks luke-jr
19:08:51 <wumpus> luke-jr: nice
19:09:11 <luke-jr> #11082 IIRC
19: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
19:09:37 <jonasschnelli> #13058 is a quick review (in high prio), has already two tested ACKs. Plz anyone.
19: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
19:09:54 <jonasschnelli> This opens the door for a lot of things
19:11:25 <wumpus> luke-jr: yes, that one needs rebase
19:12:06 <wumpus> but added, also jnewbery's 13058
19:12:17 <wumpus> I think that's enough for this week :)
19:12:37 <wumpus> #topic C++14 (sipa)
19:12:40 <jonasschnelli> 13058 is already there.. just wanted to make people aware that its a easy review
19: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
19:13:45 <sipa> gcc 5 and clang 3.4 fully implement it
19:14:06 <sipa> debian stable and ubuntu 16.04+ have gcc 5 - though as luke-jr points out, RHEL does not yet
19:14:14 <wumpus> ref: #13356, as well as earlier discussion on IRC today
19:14:16 <gribble> https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub
19:14:19 <gmaxwell> Any idea when RHEL will?
19:14:27 <sipa> RHEL 8 will ship with GCC 7
19:14:35 <sipa> but when...?
19:14:39 <gmaxwell> I mean we basically have a half year lag on major versions...
19:14:56 <wumpus> yes so this would be 0.18 at soonest
19:15:07 <MarcoFalke> Agree with wumpus
19:15:09 <sipa> yeah, true - which would be released... march 2019?
19:15:57 <wumpus> sipa: yes. that's the 0.17 planned release date + 6 months
19:16:13 <sipa> by that time probably most distro limitation concerns will have disappeared
19:16:14 <gmaxwell> also, whats in RHEL7 ? does it support enough of C++14 to cover the features we want?
19:16:34 <sipa> gmaxwell: RHEL7 has gcc 4.9... which barely supports c++11
19:17:13 <cfields> looks like 4.9 doesn't have relaxed constexpr, which is one of the big features
19: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.
19:17:39 <wumpus> yep
19:18:17 <ajtowns[m]> Ugh, did lightningbot die on me?
19:18:30 <wumpus> ajtowns[m]: don't die on us during the meeting!
19:19:11 <luke-jr> wumpus: (re rwconf, I'll ping you after I rebase it for the flag)
19:19:30 <wumpus> ok, so I think everyone agrees C++14 is a good thing for 0.18 (given RHEL at the time)?
19: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.
19:20:42 <luke-jr> gmaxwell: well, that was after waiting for C++11 to be reasonably available ofc
19:20:44 <ajtowns[m]> No seems like matrix is just not seeing everything so flowing the meeting on my phone will be hopeless :(
19:20:49 <wumpus> yes, I was especially worried about debian stable, but apparently that's no problem this time
19:21:04 <luke-jr> btw, should we concern with CentOS or other RHEL respins?
19:21:16 <luke-jr> if RHEL 8 is just barely out, they might lag..
19:21:25 <gmaxwell> luke-jr: yes but even where it wasn't most people just solved it with binaries built on another system.
19:21:32 <cfields> gmaxwell: the second group also included many who refused to _run_ a c++11 binary, despite -static-libstdc++ negating abi issues.
19:21:47 <wumpus> debian stable has gcc *6* which is very good
19:22:02 <luke-jr> gmaxwell: I'm not sure that's viable for GUI
19:22:16 <BlueMatt> wait, when does previous rhel stop getting support?
19:22:18 <wumpus> 08:49 < sipa> https://packages.debian.org/stretch/gcc-6
19:22:26 <luke-jr> BlueMatt: a long long time AFAIK
19:22:30 <BlueMatt> I dont think we can force people to upgrade, though I also doubt we have almost any rhel users
19:22:51 <luke-jr> BlueMatt: even RHEL 5 from 2007 still has support
19:23:01 <BlueMatt> how long is opensuse supported?
19:23:02 <wumpus> luke-jr: -static-libstdc++ works fine if you link qt statically as well.
19:23:06 <BlueMatt> we may actually have opensuse users
19:23:11 <wumpus> luke-jr: (which is the default for depends builds)
19:23:16 <luke-jr> wumpus: but that breaks platform plugins?
19:23:21 <wumpus> luke-jr: who cares
19:23:45 <wumpus> luke-jr: we already ignore this, with building gitian qt executables statically against qt
19:24:04 <luke-jr> but people shouldn't be using those ideally
19:24:23 <luke-jr> BlueMatt: RHEL 5 support ends in 2020
19:24:31 <gmaxwell> when we made the c++11 upgrade anyone I encountered using old RHEL just used binaries built elsewhere.
19:24:33 <wumpus> luke-jr: and anyhow the only major user of that was ubuntu unity, which supported qt4 well only...
19:24:49 <sipa> RHEL 7 support is until 2024
19: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.
19:25:00 <luke-jr> I don't think it's realistic to wait on "oldest supported RHEL"
19:25:06 <BlueMatt> gmaxwell: lol sounds like debian users
19:25:12 <wumpus> gmaxwell: I doubt c++14 will be more of a problem to them than c++11
19:25:19 <BlueMatt> luke-jr: no, I dont think it is either, was just asking
19:25:23 <wumpus> anyhow this is almost a year away
19:25:49 <sipa> there are rumors about RHEL 8 beta this month
19:25:50 <BlueMatt> is supported-ubuntu or supported-debian still not gonna support c++14 for 0.18?
19: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.
19:25:55 <BlueMatt> it does seem a bit premature imho
19:26:12 <wumpus> clang4 is the most common on BSDs, and it supports C++14 already  now
19:26:40 <BlueMatt> do we mostly just want it for shared mutex?
19:26:54 <BlueMatt> seems like we can do a mutex-wrapped shared_mutex pretty easily?
19: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
19:26:59 <wumpus> I was really surprised about that and that caused me to drop all my reservations about it
19:27:04 * cfields wants generic lambdas and relaxed constexpr
19:28:21 <cfields> iirc there are also several handy container cleanups. Like try_emplace().
19: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
19: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
19: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
19:29:21 <luke-jr> it's not a big deal if people can't update right away..
19:29:34 <wumpus> so we can just move this to 0.19
19:29:37 <morcos> another 10 months seems long enough to me...  we can't always be all things to all people
19:29:39 <wumpus> if 0.18 is controversial.
19:29:47 <sipa> how about we see after 0.17 branches off
19:29:52 <wumpus> yes
19:29:57 <sipa> or even later in the 0.18 cycle
19:30:05 <wumpus> that was my proposal too, let's make it depend on RHEL
19:30:05 <BlueMatt> yea
19:30:06 <BlueMatt> agreed
19:30:08 <luke-jr> I expect it won't be controversial
19:30:16 <sipa> there's nothing we can decide here right now - just bringing up potential issues is good in advance
19:30:20 <luke-jr> we're almost there already
19: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
19:30:38 <wumpus> in any case I tried building with -std=c++14 on various platforms today, works without any compile issues.
19:30:44 <BlueMatt> its also a question of people running like one-version-back distro X
19:30:46 <wumpus> so there's really nothing to be done there
19:30:50 <BlueMatt> and if that breaks that'd be bad
19:30:54 <BlueMatt> cause shitloads of people do that
19:31:14 <luke-jr> BlueMatt: trusty isn't just one version back, is it?
19:31:29 <wumpus> with that reasoning, we shouldn't even require c++11 yet
19:31:29 <sipa> last *two* ubuntu LTSs are fine
19:31:46 <BlueMatt> I dont really care about tursty anymore, it was released in fucking 2014
19:31:47 <wumpus> there's no end to that - why not rewrite bitcoin core in C89 while you're at it :)
19:31:51 <BlueMatt> it would be nice to support xenial
19:31:58 <wumpus> it supports xenial
19:32:08 <BlueMatt> I mean I was mostly worried about debian anyway
19:32:08 <wumpus> xenial is gcc 5.4.0
19:32:09 <BlueMatt> but, yea
19:32:21 <sipa> debian oldstable is 4.8
19:32:30 <BlueMatt> when does debian oldstable stop?
19:32:34 <BlueMatt> like 1.5 years or something?
19:32:41 <sipa> when there is a new stable
19:32:44 <luke-jr> BlueMatt: Debian has an oldoldstable now :P
19:32:47 <wumpus> I even *tried* building c++14 bitcoin core on xenial today, it worked
19:32:58 <wumpus> let alone in march 2019...
19:33:00 <BlueMatt> luke-jr: yea, ok, fuck oldoldstable
19:33:06 <luke-jr> :D
19:33:08 <BlueMatt> sipa: yea, that was my question
19:33:17 <sipa> anyway, next topic?
19:33:30 <BlueMatt> mid-2019
19:33:35 <BlueMatt> which would imply like 0.19
19:33:37 <BlueMatt> depending on timeline
19:34:05 <sipa> i'm fine with not being able to *build* on debian oldstable
19:34:12 <wumpus> yes...
19: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
19: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.
19:34:51 <sipa> cfields: they're fixed
19:35:02 <cfields> woohoo!
19:35:09 <wumpus> github unicorns seem to be fixed
19:35:16 <wumpus> haven't encountered any this week, I think
19: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
19:35:29 <jonasschnelli> Yes. They wrote back that they have deployed a fix
19:35:37 <sipa> ah, it was mr schnelli
19:35:46 <wumpus> cool.
19:36:19 <cfields> jonasschnelli: thanks for nagging :)
19:36:22 <sipa> wumpus: you had a topic?
19:36:24 <wumpus> #topic new "addr" P2P message to support 256-bit addresses (wumpus)
19:36:29 <wumpus> so I'd like to work on this
19:36:31 <sipa> concept ack
19:36:53 <BlueMatt> for new-style tor services, I presume?
19:36:54 <luke-jr> is 256- bit enough?
19:36:57 <BlueMatt> sounds like a good idea to me
19:37:02 <roasbeef> wumpus: +1
19: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.
19:37:10 <wumpus> this is to support I2P
19:37:16 <wumpus> and the new TorV3 hidden services
19:37:16 <luke-jr> 256+8 seems better for future-proofing (8 bits to select a network schema)
19:37:20 <wumpus> yes, both use 256 bit
19:37:25 <wumpus> luke-jr: yes
19:37:32 <wumpus> that's my idea, also have a network id
19:37:34 <sipa> 256 bit + network class byte
19:37:39 <luke-jr> sgtm
19:37:44 <BlueMatt> + port? I know they dont need them but other things...who knows?
19:37:47 <sipa> so we can stop using onioncat embedding in ipv6
19:37:51 <BlueMatt> I mean whats an extra 4 bytes
19:37:53 <jonasschnelli> Not sure what plans sipa and gmaxwell may have with authentication.. not sure if that is overlapping with addr
19:37:56 <BlueMatt> err 2 bytes
19:37:58 <sipa> jonasschnelli: no overlap
19: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
19:38:01 <wumpus> BlueMatt: yes, the port should still be there, good point
19:38:05 <luke-jr> could do a variable length :P
19:38:15 <jonasschnelli> Yes. I mean what roasbeef just said
19:38:18 <jonasschnelli> *meant
19:38:19 <sipa> roasbeef: that seems to defeat the purpose :(
19:38:27 <wumpus> roasbeef: should that be gossiped?
19:38:28 <roasbeef> how so?
19:38:34 <roasbeef> depends...
19:38:36 <sipa> that leaks identity
19:38:38 <sdaftuar> could this overlap with NODE_NETWORK_LIMITED etc to gossip block ranges that nodes might store and serve to the network?
19:38:40 <cfields> wumpus: any changes to serviceflags logic while you're at it?
19:38:45 <wumpus> cfields: no
19:38:47 <luke-jr> wumpus: please add multi-bit service flags
19:38:48 <wumpus> (preferably not)
19:38:52 <luke-jr> :x
19:38:56 <wumpus> I don't want too much scope creep
19:38:56 <cfields> heh
19:39:06 <sipa> roasbeef, jonasschnelli: oh!
19:39:19 <sipa> wait, are you just saying a bit to indicate "this peer supports encryption"?
19:39:23 <sipa> or rumouring pubkeys?
19:39:24 <wumpus> cfields: at least not as in "extend the service flags to arbitrary text" or something like that
19:39:31 <wumpus> cfields: if you need some more bits there, sure
19:39:32 <sipa> (i'm in favor of the first, against the latter)
19: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?
19:39:43 <roasbeef> i was saying rumouring pubkeys
19:39:47 <sipa> yeah, no
19:39:51 <roasbeef> how do you stop MiTM otherwise?
19:39:55 <BlueMatt> roasbeef: nooooo, we dont want to leak identity
19:40:01 <wumpus> cfields: the data to be gossiped should be fairly compact, after all
19:40:04 <sipa> roasbeef: out of band
19:40:07 <jonasschnelli> roasbeef: manual pairing only for now
19:40:07 <wumpus> cfields: but I'm interested in hearing your ideas
19: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
19:40:55 <jonasschnelli> ?
19:40:56 <sipa> roasbeef: most connections don't need MitM protection, as there is no identity of the peer they're connecting yo
19:41:14 <roasbeef> true, and the ones that do can use an ssh like auth_keys structure i guess
19: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"
19:41:19 <sipa> only situations where you're connecting to a friend's peer or a node you run yourself need authentication
19:41:21 <wumpus> sdaftuar: seems like something that will get outdated really soon
19: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.
19:41:35 <luke-jr> sipa: well, keys can ensure the age of your peers, so the ISP can't MITM *everything*
19:41:38 <wumpus> sdaftuar: what you'd want to gossip is block storage policy, not range, I think
19: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
19:42:29 <jimpo> Wouldn't Tor v3 address leak identity?
19: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
19:42:40 <roasbeef> jimpo: no more than tor v2
19:42:41 <wumpus> cfields: I really just want to support torv3 and I2P asap :)
19:42:42 <jonasschnelli> luke-jr: but how could you make sure those peers are trustworthy? They could even sell their auth-key, etc.
19:42:47 <sdaftuar> wumpus: yes, this is premature but i had imagined that we might store block heights % N or something, and communicate that
19:42:50 <sipa> jimpo: as much as IP addresses are an identity, yes
19: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?
19:43:21 <luke-jr> jonasschnelli: you can't in any case; it just ensures some wifi access point isn't sybil'ing you
19:43:21 <jonasschnelli> sdaftuar, wumpus: do we have stats (impossible) how deep pruned peers do prune?
19:43:26 <wumpus> cfields: no, I don't think so
19:43:26 <jimpo> That seems similar to IP + BIP 151 pubkey then?
19:43:29 <cfields> (obviously we can/do after receipt)
19:43:30 <sipa> jimpo: the issue is being able to correlate multiple IP addresses belonging to the same node
19: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
19:43:53 <wumpus> cfields: clients use some weird heuristic to determine what peers to send AFAIK
19:43:57 <jimpo> Could BIP 151 blind pubkeys with the hash of the IP/port?
19:44:07 <luke-jr> sdaftuar: that was my idea with the seed
19:44:30 <jonasschnelli> jimpo: BIP 151 has no authentication
19:44:35 <sipa> jimpo: that's one possibility, yes - but even better is a technique that doesn't reveal pubkeys at all
19:44:57 <wumpus> issue for this is #2091
19:44:59 <gribble> https://github.com/bitcoin/bitcoin/issues/2091 | Binding to multiple anonymous networks (esp. I2P) · Issue #2091 · bitcoin/bitcoin · GitHub
19:45:05 <cfields> sipa: speaking of which, any updates on the scheme you're scheming?
19:45:21 <sipa> cfields: no, sorry
19:45:27 <cfields> np
19:45:40 <sipa> jimpo: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b has some arguments in favor
19:46:16 <jonasschnelli> however, to not distract, the 256+bit addr proposal should be written and discussion should continued on the ML
19:46:23 <sipa> agree
19:46:33 <wumpus> jonasschnelli: yes
19:46:36 <sipa> but it's something i've wanted to do since 2012 :)
19:46:41 <wumpus> jonasschnelli: I was just asking for ideas.
19:47:06 <wumpus> any other topics?
19:47:54 <jonasschnelli> Maybe a quick dive into seeder hardening?
19:48:12 <wumpus> #topic Seeder hardening (jonasschnelli)
19:48:20 <jonasschnelli> It seems like that most active DNS seeds pass around ABC/BCash peers...
19:48:33 <jonasschnelli> It's a cat and mouse game... but we could tighten the screws
19:48:52 <jonasschnelli> By checking for a recent block during crawling (expansive) or avoid protocol version >80000
19:49:06 <cfields> jonasschnelli: didn't they change magic?
19:49:24 <jonasschnelli> cfields: not sure,... maybe, but then there are still some zombies around.
19: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
19:49:53 <wumpus> having to run a bitcoind on seeder nodes sounds like prohibitively expensive
19: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
19:50:04 <jonasschnelli> wumpus: yeah.. I dislike that as well
19:50:13 <sipa> my seeder node has a bitcoind... i'm more worried about the bandwidth increase from asking for blocks
19:50:20 <jonasschnelli> Maybe we should just keep an eye on it and start to form some thoughts
19:50:22 <sipa> asking for headers may be better
19:50:31 <wumpus> sipa: good point.
19:50:49 <sipa> i don't seem to have many ABC nodes
19:50:54 <jonasschnelli> Yeah. Bandwith... although you could disconnect after the header+a couple of txns
19:51:02 <sipa> 30 in my top 100k IPs
19:51:11 <wumpus> jonasschnelli: but how would you verify, if you don't actually receive the data?
19:51:12 <sipa> 13 in my top 10k
19:51:22 <wumpus> jonasschnelli: also it increases load on the nodes you're probing
19:51:23 <sipa> 1 in my top 1000
19:52:00 <jonasschnelli> Okay. Yes. That is a different image...
19:52:30 <jonasschnelli> Well,.. then nm..
19:52:46 <wumpus> jonasschnelli: the difference is strange
19:53:11 <jonasschnelli> I need to check my mainnet seed. I played with some options on the testnet seed... there its def. worse
19:53:17 <wumpus> jonasschnelli: you should probably check what your configuration differences with sipa are
19:53:25 <jonasschnelli> Indeed
19:53:44 <jonasschnelli> or if someone is trying to sybil my crawler. :)
19:54:07 <wumpus> hehe, probe through tor :)
19: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
19:54:45 <jonasschnelli> since then I mostly crawl via tor
19:54:56 <wumpus> ohh maybe they're sybilling tor exit nodes then
19:55:04 <jonasschnelli> however, I double check and report back IF it is an issue
19:55:18 <jonasschnelli> wumpus: or that, yeah.
19:55:25 <wumpus> though I somehow doubt that would take the form of ... more ABC nodes
19:55:43 <cfields> jonasschnelli: you're filtering out non-segwit?
19:56:37 <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
19:56:49 <BlueMatt> my seeder has /always/ asked for one block
19:57:03 <BlueMatt> (but does not need a full node)
19:57:09 <sipa> BlueMatt: nice
19:57:24 <wumpus> BlueMatt: the only reason it would need a node is to ask for a recent one
19:57:28 <jonasschnelli> BlueMatt: hopefully your not asking for the genesis. :)
19:57:37 <BlueMatt> wumpus: I mean its an spv client so it does ask for a recent one
19:57:44 <wumpus> but asking after the ABC and gold forks it would be ok I guess
19:58:02 <jonasschnelli> BlueMatt: nice.
19:58:43 <wumpus> yes
19:59:06 <jonasschnelli> cat dnsseed.dump | grep "Bitcoin ABC" | grep "  1   " | wc -l
19:59:10 <jonasschnelli> 207 ips
19:59:24 <sipa> and: cat dnsseed.dump | head -n 1000 | grep ABC | wc ?
19:59:44 <jonasschnelli> 58     762    9526
19:59:53 <sipa> significantly more than for me
20:00:01 <sipa> (i have 1 with that command line)
20:00:10 <jonasschnelli> Strange... just checked... I don't crawl anymore via tor
20:00:17 <sipa> well, time's up
20:00:20 <wumpus> #endmeeting