Supplying and using asmap to improve IP bucketing in addrman (p2p)

Host: jonatack  -  PR author: naumenkogs




  • An autonomous system (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators (typically ISPs or large companies) on behalf of a single administrative entity or domain that presents a common, clearly defined routing policy to the internet.

  • An autonomous system number (ASN) is a globally unique identifier allocated to each AS for use in BGP routing. The ASN uniquely identifies each network on the Internet.

  • Border Gateway Protocol (BGP) addresses the routing of packets among different autonomous systems to connect them. BGP uses ASNs to uniquely identify each AS.

  • BGP hijacking (sometimes referred to as “prefix hijacking”, “route hijacking” or “IP hijacking”) is the illegitimate takeover of groups of IP addresses by the act of corrupting Internet routing tables maintained using the Border Gateway Protocol (BGP).


  • By default, Bitcoin Core 0.19 allows up to 125 connections to different peers, 10 of which are outbound: 8 full-relay and 2 block-relay only.

  • These outbound connections rely on bucketing by network groups (/16 prefix) for network diversification. This logic in contained in src/addrman.h and src/addrman.cpp.

  • Due to the non-uniformity of IP distribution among ASNs, bucketing 8 outbound connections by /16 prefix network groups may result in connecting to 8 peers from just 2 large ASNs.

  • The idea is that allowing nodes to connect to each globally unique ASN only once should increase the security of the Bitcoin network by diversifying connections. With this PR, instead of connecting to possibly as few as 2 ASNs, nodes would connect to 8 different ASNs.

  • Diversifying network connections is motivated by the Erebus Attack. The word Erebus is ancient Greek for “shadow” or “darkness” and underscores the attack’s stealthy nature. Resources for related network attacks (Eclipse attack, BGP hijacking) are included below.

  • Instead of relying on the /16 IP prefix to diversify the connections every node creates, this PR proposes to rely instead on IP-to-ASN mapping, if the mapping is provided.

  • The asmap is the IP-to-ASN mapping in the form of a .map file named “” by default. It would be created by every user independently based on a router dump or provided along with the Bitcoin release. This PR currently generates an asmap under 2MB in size with this Python script by Pieter Wuille.

  • Users would be able to toggle asmap use by passing the -asmap= argument when launching bitcoind or by setting it in the bitcoin.conf configuration file.

  • PR author Gleb Naumenko wrote an asmap effect analysis script that can be studied or run.

Erebus attack

Eclipse attack

BGP hijacking


  1. Did you review the PR? Concept ACK, approach ACK, ACK <commit>, or NACK?  Don’t forget to put your PR review on GitHub or ask questions.

  2. What steps did you take to review this PR? Did you try the asmap effect analysis script, custom prints/logging, or modifying the code/tests?

  3. Did you read the Erebus website and paper? Did you study the Eclipse attack and the BGP hijacking attack?

  4. Briefly describe:
    • the Erebus attack: can it be detected; is it scaleable against multiple Bitcoin nodes?
    • the BGP hijacking attack (Apostolaski et al.)
    • the Eclipse attack (Heilman et al.)
    • major differences between the three
  5. What are potential countermeasures to defend against the Erebus attack and their current implementation status?

  6. This PR claims to increase Bitcoin’s network security by using ASN information for addrman bucketing and for diversifying peer connections. Do you agree? Do you see any tradeoffs?

  7. What do you think about the vectors to circumvent the asmap protection mentioned by wiz in this review comment and the replies by practicalswift and TheBlueMatt?

  8. What do you think of the implementation? How should the .map file be distributed – in the binary or outside it? Should the data be hosted in the Bitcoin Core repository?

  9. Any thoughts on the test coverage? Do you see anything that is not tested or could also be tested?

Meeting Log

  110:04 <jonatack> For testing today's review club PR 16702, the following real asmap file works:
  210:04 <jonatack>
  310:06 <jonatack> launch bitcoind with : bitcoind -asmap=<path-to>/asmap/ and the log should output "2019-12-11T15:01:16Z Opened asmap file (932999 bytes) from disk."
  410:07 <jonatack> or you can use the dummy file in the PR:
  510:07 <jonatack> bitcoind -asmap=<path-to>/bitcoin/src/test/data/asmap.raw
  610:08 <jonatack> and should see: "Opened asmap file (59 bytes) from disk."
  710:09 <jonatack> (the real asmap file is 932kb, the dummy asmap is 59 bytes)
  812:22 <pinheadmz> jonatack: 404 on sipa/asmap/
  912:30 <pinheadmz> sipa's build script not working for me :-( stuck on "loading..."
 1012:30 <pinheadmz>
 1112:30 <pinheadmz> does it take hella long
 1212:30 <pinheadmz> ?
 1312:32 <jonatack> i didn't get sipa's script to work. how are you calling it and with what data file? (see my convo on bitcoin-core-dev 3 hours ago)
 1412:32 <lightlike> pinheadmz: looks like it needs input from stdin, though im not sure how to get that
 1512:32 <pinheadmz> ha - didnt realize it took an arg
 1612:32 <jonatack> So i tested the PR with the asmap files: the dummy one in the PR, and the one in sipa's asmap repo
 1712:33 <jonatack> yeah, need to feed it data. it's not well-documented. see provoostenator's review comment on needing a data source in the PR
 1812:34 <jonatack>
 1912:34 <jonatack> So for now test it with sipa's in the sipa/asmap repo. that works.
 2012:34 <pinheadmz> sure ty
 2112:54 <pinheadmz> interesting that boost takes an unquoted string to name the test cases: BOOST_AUTO_TEST_CASE(caddrinfo_get_new_bucket)
 2213:00 <jonatack> #startmeeting
 2313:00 <pinheadmz> hi
 2413:00 <jonatack> hi
 2513:00 <emilengler> hi
 2613:00 <jnewbery> hi
 2713:00 <lightlike> hi
 2813:00 <gleb> hi!
 2913:00 <_andrewtoth_> hi
 3013:00 <ajonas> hi
 3113:00 <emzy> Hi
 3213:01 <ariard> hi
 3313:01 <jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club looking at PR 16702.
 3413:01 <jonatack> We usually start Bitcoin Core IRC meetings with a 'hi' so it's clear who's at keyboard. Feel free to say hi, even if you arrive in the middle of the meeting!
 3513:01 <jonatack> Please jump in at any point with thoughts and questions. Don't be shy! This discussion is about your thoughts and input.
 3613:01 <jonatack> This week, we're talking about PR16702 - "Supplying and using asmap to improve IP bucketing in addrman (p2p)" by gleb
 3713:01 <jonatack> This PR proposes to implement the ideas in issue #16599, "ASN-based bucketing of
 3813:01 <jonatack> the network nodes" in order to diversify network connections.
 3913:02 <jonatack> If you didn't have have a chance to read the notes, I encourage you to do so.
 4013:02 <jonatack> I think they provide a pretty good background summary for this discussion and for reviewing the PR.
 4113:02 <jonatack> gleb: Would you like to say anything about this PR? Feel free to jump in anytime.
 4213:02 <jonatack> Did you review the PR? Concept ACK, approach ACK, ACK \<commit\>, or NACK?
 4313:03 <amiti> hi
 4413:03 <gleb> I would say that i'm doing some work on improving *creating asmap* so that it solves the problem better.
 4513:03 <ethzero> hi
 4613:03 <gleb> But it's orthogonal to the pr.
 4713:04 <gleb> Pieter also promised to document asmap creation, which would make it more accessible, because right now it's a little bit of a black box, unless you spend a lot of time digging into it.
 4813:04 <pinheadmz> gleb: asmap = mapping IP addresses to ASN's?
 4913:04 <gleb> So I'd try to not spend much time discussing sipa/asmap, but rather the high-level approach of the solution, and integration aspects I propose.
 5013:05 <jonatack> gleb: Ty for being with us. One thought: It might be helpful to add some "how to review this PR" to the description.
 5113:05 <gleb> pinheadmz: yes.
 5213:05 <instagibbs> I think the distribution model of the maps is interesting to discuss
 5313:05 <ethzero> There is a lot to be said in support of this solution but I'm going to take a moment to focus on the negative aspects.
 5413:06 <jonatack> gleb: any footguns to know about running your asmap effect analysis script? haven't tried that yet
 5513:07 <gleb> jonatack: No, I think it's pretty short and everything should be understandable. Maybe not very optimized, so it might take some time given 60,000 nodes parameters and 100 experiments
 5613:07 <jonatack> instagibbs: as in, in the binary vs a separate file? your preference?
 5713:08 <jonatack> gleb: thanks. I ran out of time to try it before this meeting. Will do.
 5813:08 <jonatack> ethzero: Don't be shy, please jump in with your thoughts.
 5913:08 <ethzero> It makes reasoning about addrmans behavior dependent on the data of asmap. For example lets say a person wants to know why their node is only making 6 outgoing connections. In the current world they could just reason about this from the IP addresses they are connected to. Now they have to read the asmap file and understand how the rules are followed.
 6013:09 <gleb> Analysis script is explained in the issue related to the pr. Basically I wanted to show that we're not making a network graph less "random". This might be important for several reasons.
 6113:09 <ethzero> Additionally since this file will be updated, now debugging issues requires know which version they had and if they used a custom asmap file.
 6213:09 <lightlike> I didn't really understand the internal binary asmap representation. aside from documenting the creation script (which afaik won't make it into the bitcoin repo) some documentation in asmap.h/cpp could be helpful.
 6313:10 <gleb> lightlike: yeah, pieter is working on documenting. It's a custom thing "inspired by video codecs" lol.
 6413:10 <jnewbery> ethzero: I think both of the issues would be solved by adequate logging
 6513:10 <jonatack> lightlike: I agree. There is a lot more that can be done. This is just initial infra AFAICT.
 6613:11 <emzy> I think the asmap for ipv will be very stable.
 6713:11 <emzy> ipv4
 6813:11 <pinheadmz> oh yeah does it map v4 and v6 separately?
 6913:12 <ethzero> @jnewberyI think logging would definitely help. One could imagine a bug in this system that requires reading the asmap to understand the behavior is not correct. Right now I could look at addrman log file and identify an issue without any additional context.
 7013:12 <nehan> hi
 7113:12 <gleb> Both v4 and v6 mappings are currently in one resulting file. Asmap creation script takes care of merging them.
 7213:13 <gleb> ethzero: I see your point. It would be awesome if you provide a bit more extensive feedback in the PR body about that. Like, what kind of logs you would want to see? Something like "Okay, we have 1,000 addrs in database, but managed to connect to only 6 due to this and that"
 7313:13 <_andrewtoth_> how often would the asmap change?
 7413:14 <gleb> _andrewtoth_: as a node operator, you can provide a new one anytime. We probably will ship an upgraded version with every major release?
 7513:15 <jonatack> _andrewtoth_: I think minimum once per release depending on how the it is distributed, but users should be able to generate their own asmap and use it.
 7613:15 <_andrewtoth_> i more meant that if i generate an asmap today and then again tomorrow would it likely be the same?
 7713:15 <pinheadmz> how easy is it for the actual internet mapping to change? i.e. can amazon just change everything right after a bitcoin core release?
 7813:16 <gleb> I feel like I need to summon matt, to be as precise as possible here.
 7913:16 <emzy> _andrewtoth_: I would think there is maybe 0.01% change.
 8013:16 <jonatack> pinheadmz: presumably that should be an ongoing dashboard by interested parties like BlueMatt
 8113:18 <jonatack> there was some discussion on this last June in the IRC meeting gleb linked to in the issue and it's at the top of this meeting's notes
 8213:18 <jkczyz> hi
 8313:18 <_andrewtoth_> and going further, could the asmap that shipped with bitcoin (if that happens) become out of date enough that an attacker could abuse knowledge of what most bitcoin nodes use
 8413:18 <gleb> Talked to matt a bit. I think the understanding is that asmap will be pretty stable, with exceptions minor enough so we won't be exposed to any big threats.
 8513:18 <jonatack>
 8613:19 <nehan> i don't know much about the governance of ASNs. How easy is to create one? Do they merge often?
 8713:19 <emzy> The assignment of networks to AS are very static.
 8813:19 <survey> AFAIK ASN creation is very easy
 8913:19 <gleb> _andrewtoth_: Yeah, so it's an open question, but our current intuition is *no*. Worst case, we get bad actors a little bit more connectivity than average.
 9013:19 <nehan> is it reasonable to worry about an attacker making a lot of ASNs?
 9113:19 <survey> didnt blue matt really easily make ASN for testing?
 9213:20 <gleb> nehan: Creating a lot of new ASNs will be detected when we ship a new asmap.
 9313:20 <pinheadmz> i think BlueMatt does have an ASN - ive seen him demonstrate a BGP hijack live :-)
 9413:20 <gleb> As long as a user uses the old asmap, they won't be aware of new ASNs, so not affected.
 9513:20 <nehan> gleb: what is the "auditing" process for a new asmap?
 9613:20 <jonatack> i found suhas' comment on that interesting: "dishonest peers can gain a connectivity advantage by locating themselves in small AS groups, that seems potentially problematic"
 9713:20 <nehan> who checks it?
 9813:21 <jonatack> at
 9913:21 <nehan> (also apologies if this is already covered -- i didn't have enough time to prepare today)
10013:21 <gleb> nehan: We have two ways to create it: 1) shipped with Bitcoin core release; 2) User creates independently
10113:21 <nehan> gleb: i'm asking a different question
10213:21 <survey> jonatack suhas' comment is a good one, can lead to AS grouping value
10313:21 <pinheadmz> gleb: is it practical to add ASNs to rpc getpeerinfo ?
10413:21 <gleb> In case 1), that will be a number of core devs who care.
10513:22 <nehan> who checks the asmap to make sure it's reasonable before it is included in a release? and what constitutes "reasonable"?
10613:22 <ethzero> Getting an ASN requires filling out a request form. If you just spam them it will not get approved. I have no done it myself but my impression is that it would be cheaper for an attacker to just rent IPv4s in a bunch of different ASes.
10713:23 <gleb> nehan: It's probably a good idea to have a script of comparing 2 asmaps (or dumps used to create them) and detect things like this. Like, if there is 10% growth in ASNs over 6 months, it's probably suspicious.
10813:23 <BlueMatt> its not perfect, but its better than today - /X is a completely bogus metric, asns are better. asns are sybilable (you really just need to create a corporate entity to get one), but we can also filter a bit more
10913:23 <lightlike> if the bitcoin devs would create one with each release, the creation script would probably have to become more sophisticated to detect tampering like artificial creation of many new ASNs
11013:23 <jonatack> practicalswift also proposed applying a whitelisting approach: allow only AS number ranges that have been been allocated to the five Regional Internet Registries (AFRINIC, APNIC, ARIN, LACNIC and RIPE) by IANA
11113:23 <BlueMatt> one obvious filtering is "all of these asns only ever are accessible via one asn, just treat them as one"
11213:24 <pinheadmz> has there been any research on how the bitcoin network maps to ASNs? like, are 50% of bitcoind nodes on AWS etc
11313:24 <BlueMatt> yes, essentially that
11413:24 <BlueMatt> sadly
11513:24 <gleb> pinheadmz: Some of it is in the issue related to the pr
11613:24 <BlueMatt> digitalocean, aws, google cloud, hertzner, ovh.
11713:24 <gleb> 25% of reachable nodes are owned by top-3 asns, including amazon
11813:24 <jonatack> BlueMatt: right, look at the paths
11913:24 <gleb> 50% are owned by 10 asns I believe.
12013:25 <pinheadmz> this would also apply to ISPs? like, everyone in California uses comcast - even their full nodes at home would be under one ASN ?
12113:25 <BlueMatt> pinheadmz: yes.
12213:26 <pinheadmz> so it seems like this PR could have a big negative effect as well? Like, we need better actual network diversity for it to work?
12313:26 <gleb> I'm sorry if I missed any questions, this thing is running fast.
12413:26 <jonatack> pinheadmz: erebus is available mainly to tier 1 and 2 ASNs: ISPs and nation-states who can control large transit ISPs
12513:26 <BlueMatt> pinheadmz: nah, I think thats good - connecting only to comcast is bad even if the nodes are controlled by a diverse set of people.
12613:28 <jonatack> Question: It's opt'in for now, but should all 8 outbound connections use the asmap? lukejr suggested using it for only 4 of the 8, for instance.
12713:28 <survey> regarding pinheadmz's point a big peering change, is it not the case that would cause P2P network bandwidth to change significantly?
12813:28 <gleb> I don't think any reason for bandwidth to change at all.
12913:29 <BlueMatt> jonatack: outbound connections dont "use" asmap, its mostly an addrman change
13013:29 <survey> e.g. block propogation time is significantly affected
13113:29 <BlueMatt> and we could (and maybe should) run multiple addrmans, but its not key here.
13213:29 <BlueMatt> err, is probably out of scope
13313:30 <BlueMatt> survey: maybe, but probably not enough to care. we dont target low latency today, so...
13413:30 <BlueMatt> and its not like aws is famous for good latency performance (in fact, usually the opposite, as hosting companies go, aws is one of the worst for latency)
13513:30 <jonatack> BlueMatt: good point distinguishing outbounds from addrman, ty
13613:30 <pinheadmz> ugh, and disk performance (AWS)
13713:31 <pinheadmz> lingering Q for gleb: is it practical to add ASNs to rpc getpeerinfo ?
13813:31 <survey> BlueMatt said another way: it's not believed that latency will materially affect block relay by more than current targets .5%? .005*10*60 = 3 seconds
13913:32 <gleb> pinheadmz: Yeah, totally doable.
14013:32 <survey> is that fair?
14113:32 <BlueMatt> survey: I mean I havent done any kind of formal analysis, but this doesnt change the fact that we dont do any kind of optimizing to connect to nearby/local peers
14213:32 <BlueMatt> nor does it change the connectedness (aside from maybe connecting outbound to fewer spy nodes)
14313:32 <gleb> And connecting to local peers is not necessarily an optimization too :)
14413:33 <gleb> As a network-wide effect. Whatever.
14513:33 <BlueMatt> (connecting to local peers is a terrible idea for network health, though miners may apprecaite the improved latency)
14613:33 <jonatack> Advice/thoughts on how to test/evaluate PRs like this one?
14713:33 <BlueMatt> jonatack: think hard about it :)
14813:33 <emzy> have a good mix of nodes connected is the goal.
14913:34 <gleb> jonatack: I made some tests, see if I'm missing something there. That's rather an integration thing tho.
15013:34 <survey> BlueMatt true there isn't code to promot local peering but is it not the case that due to previous prefix filtering network topology could produce topology that achieve network performance based on local peers and now due to ASN filtering nodes need to connect to peers in which higher latency will occur? or is your point that you think the marginal change is negligibile? I see the change having sticky dynamics
15113:35 <survey> >connecting to local peers is a terrible idea for network health no argument from me there :]
15213:36 <survey> my point being: making ASN filtering must be factored into peering for P2P robustness but, let's consider how it'll affect network topology and mitigate as much as possible
15313:36 <BlueMatt> survey: right, if I had to bet, Id think this biasing against the mega-providers means network-wide you *will* see higher latency, but in fact this is the same effect we're targeting (so we cant avoid it). we want more diverse peers, which means we want more latency for mega-provider nodes.
15413:36 <BlueMatt> of course, I dont think miniscule block prop latency is a goal of the p2p network.
15513:36 <BlueMatt> it should be reasonable, but its never going to be "ideal"
15613:37 <gleb> Ideal latency can be achieved with the star topology :)
15713:37 <BlueMatt> gleb: well, I mean, no, cause speed-of-light :p
15813:37 <BlueMatt> well-laid-out networks re *always* going to win, by a lot, and the p2p network shouldnt be trying to compete, it should be trying to be robust.
15913:37 <jonatack> What I found interesting in prepping to review this PR is the amount of domain learning to do. I tried to convey some of that in the prep notes for this session.
16013:37 <jonatack> gleb: yes, i need to go throught your tests. will do
16113:38 <survey> jonatack I thought the summary of ASN was great! very succinct and sufficient.
16213:38 <survey> what else should be discussed?
16313:39 <nehan> I left my questions in the discussion:
16413:39 <jonatack> BlueMatt: any further plans to add connections over tor or increase default conns?
16513:39 <jonatack> survey: thanks!
16613:40 <pinheadmz> re: testing - is there really any way to test "big picture" of the PR locally? I see the unit tests in C, but I guess we couldn't really add pyhton e2e tests since all peers would have the same IP :-) ...
16713:40 <BlueMatt> welcome to p2p networks, best you can do is simulate :P
16813:40 <pinheadmz> word.
16913:40 <gleb> Addrman handling Tor is not very healthy right now — Tor takes 16 buckets, meaning that there is a chance connecting only to Tor. That's pretty bad, because Tor is very sybillable. I hope to get to that somewhere later in Winter..
17013:40 <jonatack> nehan: nice. Asking good questions seems very valuable to me.
17113:40 <BlueMatt> i mean you can go build an as map, get the set of p2p addresses and look at the results :)
17213:41 <BlueMatt> gleb: we should probably make sure to include any multiple bucketing changes in the same release
17313:41 <BlueMatt> to void changing buckets twice
17413:41 <nehan> adding a new file that needs to be maintained is always annoying
17513:42 <jonatack> pinheadmz: i think amiti has been spending time on p2p testing, but yeah, it's not simple
17613:42 <gleb> pinheadmz: Not sure what you want, but my script in the issue somewhat simulates all this stuff.
17713:42 <gleb> Like, it operates with real asmap and real list of reachable nodes.
17813:42 <jonatack> #action: run and review gleb's script
17913:43 <amiti> mmm, yes I've been doing some p2p testing, but not at this level
18013:43 <amiti> which is different cause of what pinheadmz is saying
18113:43 <pinheadmz> im just curious, the script with real asmap makes sense
18213:44 <jonatack> amiti: right, true
18313:44 <gleb> nehan: Even if you stick to an outdated file, you're still in a better position than we do today with /16 netgroup bucketing.
18413:45 <jonatack> nehan: IIUC, with this PR, instead of connecting to possibly as few as 2 ASNs, nodes would connect to a minimum of 8.
18513:45 <survey> gleb yes, I think the point by which we measure these changes is how they preform relative to /16 bucketing
18613:45 <jonatack> and ASNs are supposed to be globally unique
18713:45 <jonatack> s/minimum of 8/8/
18813:46 <gleb> But yeah, from the repo/release maintainers point of view, doing all this asmap stuff is not trivial I guess.
18913:46 <nehan> thought experiment: let's say someone turned on their bitcoin node in 10 years and used today's ASN map. What's the worst that could happen?
19013:47 <survey> has anyone done any research on ASN deduping? e.g. single entities having several ASN registered to them (bit beyond my knowledge) E.g. before a merger two telecomms used two ASNs but now they merged and though they have seemingly distinct ASNs they're beholden to a single corporate entity
19113:47 <gleb> Worst case: they get bucketing, which is as powerful as pre-asmap. This is my intuition.
19213:48 <jonatack> one thing i found interesting was ariard extending the thinking to the LN this week
19313:48 <jonatack> ariard posted on the lightning-dev mail list about network (eclipse iirc) attacks here:
19413:48 <jonatack>
19513:48 <emzy> nehan: worst case. There is only one AS left. And it is owned by one company.
19613:49 <pinheadmz> yeah - this should apply to every p2p right? tor, etc
19713:49 <nehan> gleb: how does it fall back to bucketing?
19813:50 <gleb> nehan: I feel we are confused with terms there. Bitcoin Core currently has /16 bucketing. I'm suggesting ASN bucketing.
19913:50 <gleb> I'm saying in the case you explained, a user will get roughly as much security as /16 bucketing provides.
20013:51 <nehan> gleb: that was my understanding of what you said as well. i just wasn't clear on if that happens automatically, and if so, how
20113:51 <gleb> No, it does not happen at all. This is just my estimate of the security a user gets.
20213:52 <jonatack> pinheadmz: not sure what you mean, but tor is a bit of a special case iiuc, because it is far easire to sybil attack than ipv4/6
20313:52 <survey> nehan you're question being: what is the fallback behavior asmap?
20413:52 <gleb>
20513:52 <gleb> If we measure diversity of peers. Currently /16 is doing 6/10, asmap will do 10/10.
20613:52 <gleb> In 10 years, both of them might be equally ~4/10 with the same chance.
20713:53 <pinheadmz> jonatack: I meant the tor relay nodes whose IPs are known in order to route messages - if I create a circuit I want to ensure that all 3 hops are different ASNs
20813:54 <jonatack> nehan: your question probably excludes it, but in this PR, IP-to-ASN bucketing is off by default unless the user specifies it and provides a valid map file
20913:54 <gleb> They also might do 0/10 in 10 years both, if everything is *completely* useless w.r.t diversity. But it seems unlikely to me that asmap can be worse than /16.
21013:54 <nehan> gleb: thanks! still trying to understand your PR/design.
21113:54 <gleb> thank you, feel free to ask more.
21213:54 <jonatack> 5 minutes everyone!
21313:55 <gleb> The implementation of asmap integration is actually not that difficult — just require a bit of learning how AddrMan serialization currently works.
21413:56 <jonatack> gleb: i find this to be a really interesting PR. were you considering it before the EREBUS paper was published, or was that paper the impetus to do it?
21513:56 <gleb> Matt suggested it when he was contacted by erebus people.
21613:57 <gleb> Maybe the idea was around before, but not from me.
21713:57 <emzy> I think it is a good idea.
21813:57 <jonatack> The stealthy aspect of Erebus is a good motivation.
21913:58 <gleb> I mean, it is useful much beyond Erebus. In general sybil attacks are easier to be deployed from a single provider and clouds.
22013:59 <jonatack> #action improve the logging of the PR as per suggestions here (and by Ethan Heilman)
22113:59 <jonatack> Any last questions?
22213:59 <jonatack> Thanks everyone!
22313:59 <pinheadmz> good jam everyone! ty
22413:59 <jonatack> Thank you gleb and BlueMatt
22514:00 <jnewbery> Thanks jonatack. Great notes and great meeting!
22614:00 <survey> are there any design decisions that'll be made that are specific to bitcoind that wouldn't be applicable to other projects trying to use this effort?
22714:00 <jonatack> #action review the PR
22814:00 <jonatack> #endmeeting
22914:00 <survey> wondering if any other project could make use of it
23014:00 <gleb> Thank you, it's been a bit like a sprint. Hope there was something useful. More people knowing these things can already contribute to p2p improvements we're trying to push forward.
23114:00 <jonatack> gleb: +1
23214:00 <survey> +1
23314:01 <jonatack> jnewbery: thanks!
23414:01 <emzy> Thank you all!
23514:01 <survey> thanks jonatack gleb BlueMatt jnewbery
23614:01 <survey> and great questions from everyone
23714:02 <_andrewtoth_> thanks all!
23814:02 <jonatack> everyone: next week we will tentatively be looking at a PR to improve valgrind integration into Bitcoin Core, to help detect issues like the one that recently caused the patch release.
23914:02 <gleb> survey: It's actually pretty generalizable I would say.
24014:02 <survey> yeah that's my thinking