Supplying and using asmap to improve IP bucketing in addrman (
p2p) Dec 11, 2019
(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.
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
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). Notes
By default, Bitcoin Core 0.19 allows
up to 125
different peers, 10 of which are outbound: 8
full-relay and 2
These outbound connections rely on
bucketing by network groups (/16
logic in contained in
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
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
Attack. The word Erebus is ancient Greek for
“shadow” or “darkness” and underscores the attack’s stealthy nature.
Resources for related network attacks ( Eclipse
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.
asmap is the IP-to-ASN mapping in the form of a .map file named
“ip_asn.map” 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
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.
Gleb Naumenko wrote an asmap
that can be studied or run. Erebus attack
Did you review the PR?
Concept ACK, approach ACK, ACK <commit>, or
Don’t forget to put your PR review on GitHub or ask
What steps did you take to review this PR? Did you try the
custom prints/logging, or modifying the code/tests?
Did you read the Erebus website and paper? Did you study the Eclipse attack
and the BGP hijacking attack?
the Erebus attack: can it be detected; is it scaleable against multiple
the BGP hijacking attack (Apostolaski et al.)
the Eclipse attack (Heilman et al.)
major differences between the three
What are potential countermeasures to defend against the Erebus attack and
their current implementation status?
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?
What do you think about the vectors to circumvent the asmap protection
wiz in this review
and the replies by practicalswift and
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?
Any thoughts on the test coverage? Do you see anything that is not tested or
could also be tested?
1 10:04 <jonatack> For testing today's review club PR 16702, the following real asmap file works:
3 10:06 <jonatack> launch bitcoind with : bitcoind -asmap=<path-to>/asmap/demo.map and the log should output "2019-12-11T15:01:16Z Opened asmap file (932999 bytes) from disk."
4 10:07 <jonatack> or you can use the dummy file in the PR:
5 10:07 <jonatack> bitcoind -asmap=<path-to>/bitcoin/src/test/data/asmap.raw
6 10:08 <jonatack> and should see: "Opened asmap file (59 bytes) from disk."
7 10:09 <jonatack> (the real asmap file is 932kb, the dummy asmap is 59 bytes)
8 12:22 <pinheadmz> jonatack: 404 on sipa/asmap/demo.map
9 12:30 <pinheadmz> sipa's build script not working for me :-( stuck on "loading..."
11 12:30 <pinheadmz> does it take hella long
13 12: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)
14 12:32 <lightlike> pinheadmz: looks like it needs input from stdin, though im not sure how to get that
15 12:32 <pinheadmz> ha - didnt realize it took an arg
16 12:32 <jonatack> So i tested the PR with the asmap files: the dummy one in the PR, and the demo.map one in sipa's asmap repo
17 12: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
19 12:34 <jonatack> So for now test it with sipa's demo.map in the sipa/asmap repo. that works.
20 12:34 <pinheadmz> sure ty
21 12:54 <pinheadmz> interesting that boost takes an unquoted string to name the test cases: BOOST_AUTO_TEST_CASE(caddrinfo_get_new_bucket)
22 13:00 <jonatack> #startmeeting
29 13:00 <_andrewtoth_> hi
33 13:01 <jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club looking at PR 16702.
34 13: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!
35 13:01 <jonatack> Please jump in at any point with thoughts and questions. Don't be shy! This discussion is about your thoughts and input.
36 13:01 <jonatack> This week, we're talking about PR16702 - "Supplying and using asmap to improve IP bucketing in addrman (p2p)" by gleb
37 13:01 <jonatack> This PR proposes to implement the ideas in issue #16599, "ASN-based bucketing of
38 13:01 <jonatack> the network nodes" in order to diversify network connections.
39 13:02 <jonatack> If you didn't have have a chance to read the notes, I encourage you to do so.
40 13:02 <jonatack> I think they provide a pretty good background summary for this discussion and for reviewing the PR.
41 13:02 <jonatack> gleb: Would you like to say anything about this PR? Feel free to jump in anytime.
42 13:02 <jonatack> Did you review the PR? Concept ACK, approach ACK, ACK \<commit\>, or NACK?
44 13:03 <gleb> I would say that i'm doing some work on improving *creating asmap* so that it solves the problem better.
46 13:03 <gleb> But it's orthogonal to the pr.
47 13: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.
48 13:04 <pinheadmz> gleb: asmap = mapping IP addresses to ASN's?
49 13: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.
50 13: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.
51 13:05 <gleb> pinheadmz: yes.
52 13:05 <instagibbs> I think the distribution model of the maps is interesting to discuss
53 13: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.
54 13:06 <jonatack> gleb: any footguns to know about running your asmap effect analysis script? haven't tried that yet
55 13: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
56 13:07 <jonatack> instagibbs: as in, in the binary vs a separate file? your preference?
57 13:08 <jonatack> gleb: thanks. I ran out of time to try it before this meeting. Will do.
58 13:08 <jonatack> ethzero: Don't be shy, please jump in with your thoughts.
59 13: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.
60 13: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.
61 13: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.
62 13: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.
63 13:10 <gleb> lightlike: yeah, pieter is working on documenting. It's a custom thing "inspired by video codecs" lol.
64 13:10 <jnewbery> ethzero: I think both of the issues would be solved by adequate logging
65 13:10 <jonatack> lightlike: I agree. There is a lot more that can be done. This is just initial infra AFAICT.
66 13:11 <emzy> I think the asmap for ipv will be very stable.
68 13:11 <pinheadmz> oh yeah does it map v4 and v6 separately?
69 13: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.
71 13:12 <gleb> Both v4 and v6 mappings are currently in one resulting file. Asmap creation script takes care of merging them.
72 13: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"
73 13:13 <_andrewtoth_> how often would the asmap change?
74 13: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?
75 13: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.
76 13:15 <_andrewtoth_> i more meant that if i generate an asmap today and then again tomorrow would it likely be the same?
77 13: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?
78 13:16 <gleb> I feel like I need to summon matt, to be as precise as possible here.
79 13:16 <emzy> _andrewtoth_: I would think there is maybe 0.01% change.
80 13:16 <jonatack> pinheadmz: presumably that should be an ongoing dashboard by interested parties like BlueMatt
81 13: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
83 13: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
84 13: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.
86 13:19 <nehan> i don't know much about the governance of ASNs. How easy is to create one? Do they merge often?
87 13:19 <emzy> The assignment of networks to AS are very static.
88 13:19 <survey> AFAIK ASN creation is very easy
89 13: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.
90 13:19 <nehan> is it reasonable to worry about an attacker making a lot of ASNs?
91 13:19 <survey> didnt blue matt really easily make ASN for testing?
92 13:20 <gleb> nehan: Creating a lot of new ASNs will be detected when we ship a new asmap.
93 13:20 <pinheadmz> i think BlueMatt does have an ASN - ive seen him demonstrate a BGP hijack live :-)
94 13:20 <gleb> As long as a user uses the old asmap, they won't be aware of new ASNs, so not affected.
95 13:20 <nehan> gleb: what is the "auditing" process for a new asmap?
96 13: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"
97 13:20 <nehan> who checks it?
99 13:21 <nehan> (also apologies if this is already covered -- i didn't have enough time to prepare today)
100 13:21 <gleb> nehan: We have two ways to create it: 1) shipped with Bitcoin core release; 2) User creates independently
101 13:21 <nehan> gleb: i'm asking a different question
102 13:21 <survey> jonatack suhas' comment is a good one, can lead to AS grouping value
103 13:21 <pinheadmz> gleb: is it practical to add ASNs to rpc getpeerinfo ?
104 13:21 <gleb> In case 1), that will be a number of core devs who care.
105 13:22 <nehan> who checks the asmap to make sure it's reasonable before it is included in a release? and what constitutes "reasonable"?
106 13: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.
107 13: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.
108 13: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
109 13: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
110 13: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
111 13:23 <BlueMatt> one obvious filtering is "all of these asns only ever are accessible via one asn, just treat them as one"
112 13:24 <pinheadmz> has there been any research on how the bitcoin network maps to ASNs? like, are 50% of bitcoind nodes on AWS etc
113 13:24 <BlueMatt> yes, essentially that
114 13:24 <BlueMatt> sadly
115 13:24 <gleb> pinheadmz: Some of it is in the issue related to the pr
116 13:24 <BlueMatt> digitalocean, aws, google cloud, hertzner, ovh.
117 13:24 <gleb> 25% of reachable nodes are owned by top-3 asns, including amazon
118 13:24 <jonatack> BlueMatt: right, look at the paths
119 13:24 <gleb> 50% are owned by 10 asns I believe.
120 13: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 ?
121 13:25 <BlueMatt> pinheadmz: yes.
122 13: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?
123 13:26 <gleb> I'm sorry if I missed any questions, this thing is running fast.
124 13:26 <jonatack> pinheadmz: erebus is available mainly to tier 1 and 2 ASNs: ISPs and nation-states who can control large transit ISPs
125 13: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.
126 13: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.
127 13:28 <survey> regarding pinheadmz's point a big peering change, is it not the case that would cause P2P network bandwidth to change significantly?
128 13:28 <gleb> I don't think any reason for bandwidth to change at all.
129 13:29 <BlueMatt> jonatack: outbound connections dont "use" asmap, its mostly an addrman change
130 13:29 <survey> e.g. block propogation time is significantly affected
131 13:29 <BlueMatt> and we could (and maybe should) run multiple addrmans, but its not key here.
132 13:29 <BlueMatt> err, is probably out of scope
133 13:30 <BlueMatt> survey: maybe, but probably not enough to care. we dont target low latency today, so...
134 13: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)
135 13:30 <jonatack> BlueMatt: good point distinguishing outbounds from addrman, ty
136 13:30 <pinheadmz> ugh, and disk performance (AWS)
137 13:31 <pinheadmz> lingering Q for gleb: is it practical to add ASNs to rpc getpeerinfo ?
138 13: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
139 13:32 <gleb> pinheadmz: Yeah, totally doable.
140 13:32 <survey> is that fair?
141 13: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
142 13:32 <BlueMatt> nor does it change the connectedness (aside from maybe connecting outbound to fewer spy nodes)
143 13:32 <gleb> And connecting to local peers is not necessarily an optimization too :)
144 13:33 <gleb> As a network-wide effect. Whatever.
145 13:33 <BlueMatt> (connecting to local peers is a terrible idea for network health, though miners may apprecaite the improved latency)
146 13:33 <jonatack> Advice/thoughts on how to test/evaluate PRs like this one?
147 13:33 <BlueMatt> jonatack: think hard about it :)
148 13:33 <emzy> have a good mix of nodes connected is the goal.
149 13:34 <gleb> jonatack: I made some tests, see if I'm missing something there. That's rather an integration thing tho.
150 13: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
151 13:35 <survey> >connecting to local peers is a terrible idea for network health no argument from me there :]
152 13: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
153 13: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.
154 13:36 <BlueMatt> of course, I dont think miniscule block prop latency is a goal of the p2p network.
155 13:36 <BlueMatt> it should be reasonable, but its never going to be "ideal"
156 13:37 <gleb> Ideal latency can be achieved with the star topology :)
157 13:37 <BlueMatt> gleb: well, I mean, no, cause speed-of-light :p
158 13: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.
159 13: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.
160 13:37 <jonatack> gleb: yes, i need to go throught your tests. will do
161 13:38 <survey> jonatack I thought the summary of ASN was great! very succinct and sufficient.
162 13:38 <survey> what else should be discussed?
164 13:39 <jonatack> BlueMatt: any further plans to add connections over tor or increase default conns?
165 13:39 <jonatack> survey: thanks!
166 13: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 :-) 127.0.0.1 ...
167 13:40 <BlueMatt> welcome to p2p networks, best you can do is simulate :P
168 13:40 <pinheadmz> word.
169 13: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..
170 13:40 <jonatack> nehan: nice. Asking good questions seems very valuable to me.
171 13:40 <BlueMatt> i mean you can go build an as map, get the set of p2p addresses and look at the results :)
172 13:41 <BlueMatt> gleb: we should probably make sure to include any multiple bucketing changes in the same release
173 13:41 <BlueMatt> to void changing buckets twice
174 13:41 <nehan> adding a new file that needs to be maintained is always annoying
175 13:42 <jonatack> pinheadmz: i think amiti has been spending time on p2p testing, but yeah, it's not simple
176 13:42 <gleb> pinheadmz: Not sure what you want, but my script in the issue somewhat simulates all this stuff.
177 13:42 <gleb> Like, it operates with real asmap and real list of reachable nodes.
178 13:42 <jonatack> #action: run and review gleb's script
179 13:43 <amiti> mmm, yes I've been doing some p2p testing, but not at this level
180 13:43 <amiti> which is different cause of what pinheadmz is saying
181 13:43 <pinheadmz> im just curious, the script with real asmap makes sense
182 13:44 <jonatack> amiti: right, true
183 13: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.
184 13: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.
185 13:45 <survey> gleb yes, I think the point by which we measure these changes is how they preform relative to /16 bucketing
186 13:45 <jonatack> and ASNs are supposed to be globally unique
187 13:45 <jonatack> s/minimum of 8/8/
188 13:46 <gleb> But yeah, from the repo/release maintainers point of view, doing all this asmap stuff is not trivial I guess.
189 13: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?
190 13: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
191 13:47 <gleb> Worst case: they get bucketing, which is as powerful as pre-asmap. This is my intuition.
192 13:48 <jonatack> one thing i found interesting was ariard extending the thinking to the LN this week
193 13:48 <jonatack> ariard posted on the lightning-dev mail list about network (eclipse iirc) attacks here:
195 13:48 <emzy> nehan: worst case. There is only one AS left. And it is owned by one company.
196 13:49 <pinheadmz> yeah - this should apply to every p2p right? tor, etc
197 13:49 <nehan> gleb: how does it fall back to bucketing?
198 13:50 <gleb> nehan: I feel we are confused with terms there. Bitcoin Core currently has /16 bucketing. I'm suggesting ASN bucketing.
199 13:50 <gleb> I'm saying in the case you explained, a user will get roughly as much security as /16 bucketing provides.
200 13: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
201 13:51 <gleb> No, it does not happen at all. This is just my estimate of the security a user gets.
202 13: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
203 13:52 <survey> nehan you're question being: what is the fallback behavior asmap?
205 13:52 <gleb> If we measure diversity of peers. Currently /16 is doing 6/10, asmap will do 10/10.
206 13:52 <gleb> In 10 years, both of them might be equally ~4/10 with the same chance.
207 13: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
208 13: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
209 13: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.
210 13:54 <nehan> gleb: thanks! still trying to understand your PR/design.
211 13:54 <gleb> thank you, feel free to ask more.
212 13:54 <jonatack> 5 minutes everyone!
213 13:55 <gleb> The implementation of asmap integration is actually not that difficult — just require a bit of learning how AddrMan serialization currently works.
214 13: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?
215 13:56 <gleb> Matt suggested it when he was contacted by erebus people.
216 13:57 <gleb> Maybe the idea was around before, but not from me.
217 13:57 <emzy> I think it is a good idea.
218 13:57 <jonatack> The stealthy aspect of Erebus is a good motivation.
219 13: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.
220 13:59 <jonatack> #action improve the logging of the PR as per suggestions here (and by Ethan Heilman)
221 13:59 <jonatack> Any last questions?
222 13:59 <jonatack> Thanks everyone!
223 13:59 <pinheadmz> good jam everyone! ty
224 13:59 <jonatack> Thank you gleb and BlueMatt
225 14:00 <jnewbery> Thanks jonatack. Great notes and great meeting!
226 14: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?
227 14:00 <jonatack> #action review the PR
228 14:00 <jonatack> #endmeeting
229 14:00 <survey> wondering if any other project could make use of it
230 14: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.
231 14:00 <jonatack> gleb: +1
233 14:01 <jonatack> jnewbery: thanks!
234 14:01 <emzy> Thank you all!
235 14:01 <survey> thanks jonatack gleb BlueMatt jnewbery
236 14:01 <survey> and great questions from everyone
237 14:02 <_andrewtoth_> thanks all!
238 14: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 0.19.0.1 patch release.
239 14:02 <gleb> survey: It's actually pretty generalizable I would say.
240 14:02 <survey> yeah that's my thinking