19:01:09 <wumpus> #startmeeting
19:01:09 <lightningbot> Meeting started Thu Jun 20 19:01:09 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:09 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:13 <sipa> hello
19:01:17 <jeremyrubin> hi
19:01:31 <jonasschnelli> hi
19:01:45 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
19:01:53 <achow101> hi
19:01:57 <meshcollider> hi
19:02:20 <wumpus> two topics proposed in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : Bitcoin core PR review club, ASN blob discussion
19:02:44 <kanzure> hi
19:02:46 <wumpus> also maybe we want to discuss the travis issue again
19:04:03 <meshcollider> Also 2FA discussion from fanquake
19:04:08 <moneyball> hi
19:04:09 <wumpus> #topic High priority for review
19:04:51 <wumpus> https://github.com/bitcoin/bitcoin/projects/8   5 blockers, 2 bugfixes and 6(!) things chasing concept ack
19:05:13 <wumpus> anything to add/remove this week ?
19:05:34 <jnewbery> hi
19:07:21 <wumpus> ok, apparently nothing to discuss in regard to that
19:07:50 <wumpus> #topic Bitcoin Core PR review club (jnewbery)
19:08:03 <jnewbery> Thanks wumpus
19:08:07 <wumpus> https://bitcoin-core-review-club.github.io/
19:08:09 <jnewbery> I just wanted to give an update on the Bitcoin Core Review Club (https://bitcoin-core-review-club.github.io/) that we've been doing for the last couple of months.
19:08:18 <jnewbery> We've got a solid group of attendees every week, and some of them are commenting on and reviewing PRs in github, so I think it's been reasonably successful so far.
19:08:39 <jnewbery> If anyone wants to get involved, we have IRC meetings at 17:00 UTC on Wednesdays. Appearances from established contributors are always appreciated.
19:08:45 <jonasschnelli> thanks for doing this jnewbery!
19:09:01 <jnewbery> If you have any friends who are less experienced and want to get into Bitcoin Core development, you should send them along
19:09:15 <wumpus> yes, great!
19:09:31 <jnewbery> I'm away for the next couple of weeks and I'm looking for one or two volunteer hosts, so please message me if you're interested
19:09:38 <meshcollider> Very cool, I would definitely come if it wasn't at 5am haha
19:10:21 <jnewbery> oh, and finally, if you have any suggested PRs for us to cover, please message me also. We're looking for stuff that doesn't require too much esoteric knowledge and is a reasonable size (perhaps ~100 LOC)
19:10:26 <jnewbery> that's all. Thanks!
19:10:36 <BlueMatt> can we do asns? I want to take a nap
19:10:37 <wumpus> thanks jnewbery
19:10:43 <BlueMatt> also, +1 thanks jnewbery
19:10:53 <wumpus> #topic ASN blobs (BlueMatt)
19:11:00 <BlueMatt> well maybe sipa can introduce
19:11:09 <BlueMatt> but the idea is, basically, why are we bucketing by /16s
19:11:25 <BlueMatt> its an easy hack, but there's lots of isps with way more than /16s and lots with way less
19:11:33 <sipa> to give some context
19:11:35 <BlueMatt> our goal, really, is to capture diversity of isps/hosting providers
19:12:09 <BlueMatt> we also have seen several groups of spy nodes/large-connection-farms from several different places, but, all together, they originate from < 10 isps
19:12:15 <BlueMatt> despite being a *ton* of ips
19:12:33 <sipa> we're currently "grouping" certain IP ranges into groups, to make decisions such as whether to make multiple connections to the same range or not, prioritize incoming connections from distinct groups, and control which addrman buckets IPs go into (under the theory that an attacker has a hard time controlling many groups, sybil resistance is improved)
19:12:41 <sipa> right now, those are just /16 groups
19:12:45 <sipa> for most things
19:13:13 <sipa> but /16 is a really naive choice; some ISPs control very large ranges, some very small ones
19:13:54 <sipa> an obvious improvement is to have a map built-in to bitcoin core that tells what the actual independent network ranges are
19:14:33 <wumpus> so the practical problem would be how to include enough of this data to be useful, but without adding too much data to the executable size
19:14:37 <luke-jr> BlueMatt: don't ASNs change?
19:14:41 <sipa> so i've been working on seeing how large such a map for real internet data would be, and it turns out we can pack it in around 1 MB, and still efficiently look things up in it
19:14:49 <BlueMatt> luke-jr: sure, but not a *lot*
19:14:50 <wumpus> yes, they change, it'd be at most an approximation at the time of release
19:14:56 <luke-jr> and even if the same ISP owns a big range, that range may be very diverse?
19:15:09 <wumpus> but that's good enough
19:15:27 <BlueMatt> diverse how? against any practical attacks that grouping helps prevent, not diverse at all (mitms, sybils, etc)
19:15:37 <wumpus> we don't really want to include all the data in our github repo though
19:16:04 <luke-jr> BlueMatt: depends on the attack I guess
19:16:06 <wumpus> so I guess this is some kind of challenge for the deterministic builds
19:16:12 <BlueMatt> well we could incoporate a text file dump of a routing table into the build process
19:16:13 <BlueMatt> thats not too hard
19:16:24 <sipa> so i've used a dump from BGP (which is... a gigabyte or so) to extract a mapping from prefixes to ASNs, and then developed a custom packed format to store just the mapping
19:16:33 <wumpus> yes, but it should be determinstic per version, without including it into the repo itself
19:16:54 <luke-jr> we don't actually need the ASNs though, right? just some logic to decide whether to group by /16, /24, /8, etc
19:17:10 <BlueMatt> indeed, we'd have to agree on a source (we could use my dumps, or get them from one of several others who provide dumps, or get output from anyone's bird router)
19:17:12 <sipa> luke-jr: correct; though consistency matters for things like addrman
19:17:13 <wumpus> that does add some requirements, maybe it's not hard, but it's also not something we've done before
19:17:24 <sipa> as we don't want to change what number each range maps to too frequently
19:17:27 <luke-jr> although maybe some ISPs have multiple subnets
19:17:32 <sipa> and ASN numbers are small
19:17:44 <sipa> (most are below 2^16, all are below 350000 or so)
19:17:50 <wumpus> luke-jr:yes, quite a few ISPs have non-consecutive subnets
19:18:02 <sipa> luke-jr: indeed, and that's actually by design
19:18:08 <sipa> this would give most of AWS one number
19:18:21 <BlueMatt> hmm, is there some attack whereby someone just flips their asn every 6 months per release and gets into several buckets? I mean at most you'd get one per six months
19:18:32 <sipa> yeah, it's not terrible
19:18:37 <sipa> just better to be consistent when possible
19:18:41 <BlueMatt> which i guess is also plenty of time to register a new asn, buy some ips, and sell the old ones
19:19:05 <sipa> so i think a question for here is, what binary size increase is acceptable and/or is it a separate file with the map that can be replaced?
19:19:26 <BlueMatt> separate file seems ideal to me, but that has deployment concerns
19:19:43 <BlueMatt> I dont think we could realistically say "take this file that shipped with bitcoin core and copy it to your datadir on first run"
19:19:46 <sipa> and what kind of auditing is necessary for it... not everyone is able to extract a BGP dump and compare the result (and it wouldn't be consistent across dumps anyway)
19:20:09 <BlueMatt> we could get my dump, and a few other dumps and have a tool to compare them?
19:20:18 <BlueMatt> there's several providers, so it should be doable
19:20:20 <sipa> just a text list of prefix -> ASN mappings is just a few MB
19:20:27 <sipa> when gzipped
19:20:31 <BlueMatt> eg you could get a bunch of dumps from https://rt-bgp.he.net/
19:20:45 <BlueMatt> (including mine, indirectly)
19:21:18 <sipa> so opinions?
19:21:36 <luke-jr> maybe we should only do it for 4 of the 8 peers?
19:21:36 <BlueMatt> well I guess two hard proposals, pick one:
19:21:40 <BlueMatt> a) build it into the binary
19:21:41 <luke-jr> in case ther'es a way to game it
19:21:59 <BlueMatt> b) ship a file and (1) look in datadir, (2) if not there, look in the folder where bitcoind is being run from.
19:22:10 <BlueMatt> b) (3) if not, print warning and fall back to /16s
19:22:15 <achow101> is it possible to do both? i.e. build it in and have a separate file in datador
19:22:22 <sipa> yeah
19:22:26 <jnewbery> I'd say not (a). We don't want to add a MB of data to the repo
19:22:26 <achow101> so datadir file overrides built in
19:22:41 <jnewbery> do we want people to be able to override?
19:22:42 <BlueMatt> right, but its mostly a binary size question
19:22:44 <sipa> jnewbery: but the distribution should still include it
19:22:49 <wumpus> well the build could fetch it somewhere else, it doesn't need to be in the repo
19:22:56 <jb55> why does it have to be in-tree? couldn't it be a dependency?
19:22:58 <jnewbery> yes, i think the distribution should include it
19:22:58 <jb55> yeah
19:22:59 <wumpus> it definitely shouldn't be *
19:23:01 <BlueMatt> jnewbery: doesnt *technically* have to be in the repo
19:23:13 <luke-jr> BlueMatt: data files shouldn't be in bin/
19:23:14 <BlueMatt> it could be in the binary without that, as a separate input to gitian
19:23:43 <BlueMatt> luke-jr: if you're using a distribution, it should install it appropriately, if you're downloading the targz, then it can be wherever
19:24:00 <luke-jr> BlueMatt: datadir is per-user, so can't install there
19:24:44 <BlueMatt> further opinions?
19:25:11 <jnewbery> Do we want people to be able to supply their own. I think no
19:25:21 <BlueMatt> luke-jr: sure, that doesnt mean its not allowed to be there? there's also a copy of the chain there, which is not per-user :p
19:25:21 <sipa> jnewbery: i see no reason not to allow that
19:25:41 <luke-jr> BlueMatt: it means the distro can't install it there
19:25:54 <sipa> we'd have the scripts to build the blob from a list of mappings in contrib/ i guess
19:26:06 <wumpus> could have an argument to point to where it is
19:26:19 <BlueMatt> yes, definitely have to make it possible to generate your own, given the input is otherwise hard to audit
19:26:32 <BlueMatt> luke-jr: yes, hence an option like -look-in-var
19:26:51 <wumpus> datadir would only be the default, like it is for other things too unless overridden
19:27:55 <luke-jr> so force distros to patch it?
19:27:59 <wumpus> but I think we're very much getting into specific implementation details now
19:28:00 <jnewbery> because then bad people might supply a bogus network.dat (or whatever) file and tell people to use it
19:28:28 <wumpus> well that's true for any file, like peers.dat too
19:28:39 <gwillen> I think you could limit the damage a bad network.dat could do by putting sanity checks on it
19:28:40 <wumpus> or like a malicious wallet
19:28:52 <gwillen> e.g. no aggregating the entire internet into a single "ASN", that sort of thing
19:28:53 <sipa> wumpus: are you talking about having it always as a separate file (which may be sourced from several locations), or having it built into the binary (with the option to source it from elsewhere)
19:28:55 <wumpus> if you get people to install bogus files into their datadir it's kind of bad
19:29:24 <BlueMatt> (hopefully, many of these classes of attacks can be further limited by better peer eviction logic, so hopefully thats not *that* easy)
19:29:33 <wumpus> sipa: the latter, I think
19:29:43 <harding> Perhaps it should start as a separate file and then, later, if it's working well it can be considered for direct inclusion in the binary.
19:29:55 <wumpus> sipa: I'm ok with including the data in the distributed binary, I just don't want it in the repository
19:30:00 <sipa> ok fair
19:30:02 <wumpus> harding: good point too
19:30:13 <wumpus> first add support for this
19:30:16 <wumpus> then the rest later
19:31:53 <sipa> yeah
19:33:02 <wumpus> #topic Requiring 2FA for bitcoin orgs on GH (fanquake)
19:33:35 <jonasschnelli> I guess I we should disable sms 2fa recovery...
19:33:49 <luke-jr> eh, maybe for people with push? it doesn't really matter for most of us
19:34:13 <luke-jr> GH doesn't even check 2FA all that often either
19:34:15 <BlueMatt> i mean push is pgp-signed (at least in theory)
19:34:19 <BlueMatt> matters most for acks
19:34:22 <wumpus> jonasschnelli: so is that possible on an organization?
19:34:37 <BlueMatt> but, yea, I think I've not had to re-login to github in...years?
19:34:42 <jonasschnelli> no... I think need to be done on an individual level
19:34:45 <luke-jr> BlueMatt: GitHub being trusted with ACKs is a problem in itself :x
19:34:57 <BlueMatt> indeed
19:36:02 * jeremyrubin acks on the blockchain
19:36:13 <luke-jr> (why nobody sees it)
19:36:59 * BlueMatt -> nap
19:37:00 <wumpus> I don't think there's actually much to discuss here: in any case, if you read this and haven't enabled 2FA please do so if possible
19:37:21 <jonasschnelli> Yes. And disable phone 2fa recovery
19:37:45 <jonasschnelli> (probably use FIDO key and recovery code for backup)
19:38:32 <wumpus> ok, any other topics? I think we're through
19:39:30 <phantomcircuit> jonasschnelli, at an organization level you can only enforce that some form of 2fa is enabled, not which type
19:41:15 <sipa> oh also short reminder we're going to meet with github tomorrow, if there are any things we should bring up, see https://github.com/bitcoin/bitcoin/issues/15847
19:44:08 <wumpus> good to know sipa
19:44:20 <wumpus> thanks everyone
19:44:21 <wumpus> #endmeeting