--- Day changed Wed Dec 11 2019
00:38 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Read error: Connection reset by peer]     
00:38 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews     
00:52 -!- b10c [~Thunderbi@mue-88-130-54-169.dsl.tropolys.de] has joined #bitcoin-core-pr-reviews     
01:27 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
01:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 260 seconds]     
01:47 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
02:22 -!- davterra [~dulyNoded@104.140.15.11] has quit [Quit: Leaving]     
03:13 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
03:15 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Read error: Connection reset by peer]     
03:17 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]     
03:18 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
03:21 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
03:21 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:33 -!- Jordan72Bogisich [~Jordan72B@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews     
03:38 -!- Jordan72Bogisich [~Jordan72B@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]     
04:51 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]     
05:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
05:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
06:38 -!- davterra [~dulyNoded@104.140.15.11] has joined #bitcoin-core-pr-reviews     
06:45 -!- reallll is now known as belcher     
07:04 < jonatack> For testing today's review club PR 16702, the following real asmap file works:
07:04 < jonatack>  https://github.com/sipa/asmap/demo.map
07: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."
07:07 < jonatack> or you can use the dummy file in the PR:
07:07 < jonatack> bitcoind -asmap=<path-to>/bitcoin/src/test/data/asmap.raw
07:08 < jonatack> and should see: "Opened asmap file (59 bytes) from disk."
07:09 < jonatack> (the real asmap file is 932kb, the dummy asmap is 59 bytes)
07:18 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-slflmynztusvkafs] has quit []     
07:19 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-ylhjxyvdiutgsgnr] has joined #bitcoin-core-pr-reviews     
07:29 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
07:38 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
07:56 -!- davterra [~dulyNoded@104.140.15.11] has quit [Quit: Leaving]     
08:06 -!- davterra [~dulyNoded@104.140.15.11] has joined #bitcoin-core-pr-reviews     
08:31 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]     
08:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
08:47 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
08:50 -!- ethzero [uid396973@gateway/web/irccloud.com/x-yoycuhonebvpajls] has joined #bitcoin-core-pr-reviews     
08:51 -!- lightlike [~lightlike@2001:16b8:5718:f700:6def:1ede:10e3:b37d] has joined #bitcoin-core-pr-reviews     
08:52 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:22 < pinheadmz> jonatack: 404 on sipa/asmap/demo.map
09:23 < belcher> i think scantxoutset may have been broken in bitcoin core 0.19 ? regardless of what parameters i run it with (e.g. "scantxoutset abort", "scantxoutset status") it just returns the help doc, according to the release notes the only change was https://github.com/bitcoin/bitcoin/pull/16285/files but i dont see anything that wouldve broken it
09:23 < belcher> it works fine with 0.18
09:24 < jonatack> pinheadmz: git clone https://github.com/sipa/asmap/ locally and then just point bitcoind -asmap= to the file location
09:24 < belcher> ah... wrong channel sorry (both start with #bitcoin-core-)
09:25 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
09:27 < jonatack> belcher: strange, same for me
09:28 < belcher> im on regtest in case its important
09:28 < jonatack> i tried it on mainnet
09:28 < belcher> ill try on mainnet, lets continue in #bitcoin-core-dev btw
09:29 < jonatack> i remember using it fine on master recently, but RN i'm on the PR 16702 branch doing a review
09:30 < pinheadmz> sipa's build script not working for me :-( stuck on "loading..."
09:30 < pinheadmz> https://gist.github.com/sipa/b90070570597b950f29a6297772a7636
09:30 < pinheadmz> does it take hella long
09:30 < pinheadmz> ?     
09: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)
09:32 < lightlike> pinheadmz: looks like it needs input from stdin, though im not sure how to get that
09:32 < pinheadmz> ha - didnt realize it took an arg
09: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
09: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
09:34 < jonatack> https://github.com/bitcoin/bitcoin/pull/16702#pullrequestreview-280680935
09:34 < jonatack> So for now test it with sipa's demo.map in the sipa/asmap repo. that works.
09:34 < pinheadmz> sure ty
09:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]     
09:43 -!- shesek [~shesek@5.22.135.198] has joined #bitcoin-core-pr-reviews     
09:43 -!- shesek [~shesek@5.22.135.198] has quit [Changing host]     
09:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
09:54 < pinheadmz> interesting that boost takes an unquoted string to name the test cases: BOOST_AUTO_TEST_CASE(caddrinfo_get_new_bucket)
10:00 < jonatack> #startmeeting
10:00 < pinheadmz> hi     
10:00 < jonatack> hi     
10:00 < emilengler> hi     
10:00 < jnewbery> hi     
10:00 < lightlike> hi     
10:00 < gleb> hi!     
10:00 < _andrewtoth_> hi     
10:00 < ajonas> hi     
10:00 < emzy> Hi     
10:01 < ariard> hi     
10:01 < jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club looking at PR 16702.
10: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!
10:01 < jonatack> Please jump in at any point with thoughts and questions. Don't be shy! This discussion is about your thoughts and input.
10:01 < jonatack> This week, we're talking about PR16702 - "Supplying and using asmap to improve IP bucketing in addrman (p2p)" by gleb
10:01 < jonatack> This PR proposes to implement the ideas in issue #16599, "ASN-based bucketing of
10:01 < jonatack> the network nodes" in order to diversify network connections.
10:02 < jonatack> If you didn't have have a chance to read the notes, I encourage you to do so.
10:02 < jonatack> I think they provide a pretty good background summary for this discussion and for reviewing the PR.
10:02 < jonatack> gleb: Would you like to say anything about this PR? Feel free to jump in anytime.
10:02 < jonatack> Did you review the PR? Concept ACK, approach ACK, ACK \<commit\>, or NACK?
10:03 < amiti> hi     
10:03 < gleb> I would say that i'm doing some work on improving *creating asmap* so that it solves the problem better.
10:03 < ethzero> hi     
10:03 < gleb> But it's orthogonal to the pr.
10:03 -!- survey [~survey@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10: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.
10:04 < pinheadmz> gleb: asmap = mapping IP addresses to ASN's?
10: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.
10: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.
10:05 < gleb> pinheadmz: yes.
10:05 < instagibbs> I think the distribution model of the maps is interesting to discuss
10: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.
10:06 < jonatack> gleb: any footguns to know about running your asmap effect analysis script? haven't tried that yet
10: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
10:07 < jonatack> instagibbs: as in, in the binary vs a separate file? your preference?
10:08 < jonatack> gleb: thanks. I ran out of time to try it before this meeting. Will do.
10:08 < jonatack> ethzero: Don't be shy, please jump in with your thoughts.
10: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.
10: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.
10: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.
10: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.
10:10 < gleb> lightlike: yeah, pieter is working on documenting. It's a custom thing "inspired by video codecs" lol.
10:10 < jnewbery> ethzero: I think both of the issues would be solved by adequate logging
10:10 < jonatack> lightlike: I agree. There is a lot more that can be done. This is just initial infra AFAICT.
10:11 < emzy> I think the asmap for ipv will be very stable.
10:11 < emzy> ipv4
10:11 < pinheadmz> oh yeah does it map v4 and v6 separately?
10: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.
10:12 < nehan> hi     
10:12 < gleb> Both v4 and v6 mappings are currently in one resulting file. Asmap creation script takes care of merging them.
10: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"
10:13 < _andrewtoth_> how often would the asmap change?
10: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?
10: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.
10:15 < _andrewtoth_> i more meant that if i generate an asmap today and then again tomorrow would it likely be the same?
10: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?
10:16 < gleb> I feel like I need to summon matt, to be as precise as possible here.
10:16 < emzy> _andrewtoth_: I would think there is maybe 0.01% change.
10:16 < jonatack> pinheadmz: presumably that should be an ongoing dashboard by interested parties like BlueMatt
10: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
10:18 < jkczyz> hi     
10: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
10: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.
10:18 < jonatack> http://www.erisian.com.au/bitcoin-core-dev/log-2019-06-20.html#l-518
10:19 < nehan> i don't know much about the governance of ASNs. How easy is to create one? Do they merge often?
10:19 < emzy> The assignment of networks to AS are very static.
10:19 < survey> AFAIK ASN creation is very easy
10: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.
10:19 < nehan> is it reasonable to worry about an attacker making a lot of ASNs?
10:19 < survey> didnt blue matt really easily make ASN for testing?
10:20 < gleb> nehan: Creating a lot of new ASNs will be detected when we ship a new asmap.
10:20 < pinheadmz> i think BlueMatt does have an ASN - ive seen him demonstrate a BGP hijack live :-)
10:20 < gleb> As long as a user uses the old asmap, they won't be aware of new ASNs, so not affected.
10:20 < nehan> gleb: what is the "auditing" process for a new asmap?
10: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"
10:20 < nehan> who checks it?
10:21 < jonatack> at https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-533545858
10:21 < nehan> (also apologies if this is already covered -- i didn't have enough time to prepare today)
10:21 < gleb> nehan: We have two ways to create it: 1) shipped with Bitcoin core release; 2) User creates independently
10:21 < nehan> gleb: i'm asking a different question
10:21 < survey> jonatack suhas' comment is a good one, can lead to AS grouping value
10:21 < pinheadmz> gleb: is it practical to add ASNs to rpc getpeerinfo ?
10:21 < gleb> In case 1), that will be a number of core devs who care.
10:22 < nehan> who checks the asmap to make sure it's reasonable before it is included in a release?  and what constitutes "reasonable"?
10: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.
10: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.
10: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
10: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
10: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
10:23 < BlueMatt> one obvious filtering is "all of these asns only ever are accessible via one asn, just treat them as one"
10:24 < pinheadmz> has there been any research on how the bitcoin network maps to ASNs? like, are 50% of bitcoind nodes on AWS etc
10:24 < BlueMatt> yes, essentially that
10:24 < BlueMatt> sadly
10:24 < gleb> pinheadmz: Some of it is in the issue related to the pr
10:24 < BlueMatt> digitalocean, aws, google cloud, hertzner, ovh.
10:24 < gleb> 25% of reachable nodes are owned by top-3 asns, including amazon
10:24 < jonatack> BlueMatt: right, look at the paths
10:24 < gleb> 50% are owned by 10 asns I believe.
10: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 ?
10:25 < BlueMatt> pinheadmz: yes.
10: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?
10:26 < gleb> I'm sorry if I missed any questions, this thing is running fast.
10:26 < jonatack> pinheadmz: erebus is available mainly to tier 1 and 2 ASNs: ISPs and nation-states who can control large transit ISPs
10: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.
10: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.
10:28 < survey> regarding pinheadmz's point a big peering change, is it not the case that would cause P2P network bandwidth to change significantly?
10:28 < gleb> I don't think any reason for bandwidth to change at all.
10:29 < BlueMatt> jonatack: outbound connections dont "use" asmap, its mostly an addrman change
10:29 < survey> e.g. block propogation time is significantly affected
10:29 < BlueMatt> and we could (and maybe should) run multiple addrmans, but its not key here.
10:29 < BlueMatt> err, is probably out of scope
10:30 < BlueMatt> survey: maybe, but probably not enough to care. we dont target low latency today, so...
10: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)
10:30 < jonatack> BlueMatt: good point distinguishing outbounds from addrman, ty
10:30 < pinheadmz> ugh, and disk performance (AWS)
10:31 < pinheadmz> lingering Q for gleb: is it practical to add ASNs to rpc getpeerinfo ?
10: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
10:32 < gleb> pinheadmz: Yeah, totally doable.
10:32 < survey> is that fair?
10: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
10:32 < BlueMatt> nor does it change the connectedness (aside from maybe connecting outbound to fewer spy nodes)
10:32 < gleb> And connecting to local peers is not necessarily an optimization too :)
10:33 < gleb> As a network-wide effect. Whatever.
10:33 < BlueMatt> (connecting to local peers is a terrible idea for network health, though miners may apprecaite the improved latency)
10:33 < jonatack> Advice/thoughts on how to test/evaluate PRs like this one?
10:33 < BlueMatt> jonatack: think hard about it :)
10:33 < emzy> have a good mix of nodes connected is the goal.
10:34 < gleb> jonatack: I made some tests, see if I'm missing something there. That's rather an integration thing tho.
10: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
10:35 < survey> >connecting to local peers is a terrible idea for network health      no argument from me there :]
10: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
10: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.
10:36 < BlueMatt> of course, I dont think miniscule block prop latency is a goal of the p2p network.
10:36 < BlueMatt> it should be reasonable, but its never going to be "ideal"
10:37 < gleb> Ideal latency can be achieved with the star topology :)
10:37 < BlueMatt> gleb: well, I mean, no, cause speed-of-light :p
10: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.
10: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.
10:37 < jonatack> gleb: yes, i need to go throught your tests. will do
10:38 < survey> jonatack I thought the summary of ASN was great! very succinct and sufficient.
10:38 < survey> what else should be discussed?
10:39 < nehan> I left my questions in the discussion: https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-564675925
10:39 < jonatack> BlueMatt: any further plans to add connections over tor or increase default conns?
10:39 < jonatack> survey: thanks!
10: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 ...
10:40 < BlueMatt> welcome to p2p networks, best you can do is simulate :P
10:40 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
10:40 < pinheadmz> word.
10: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..
10:40 < jonatack> nehan: nice. Asking good questions seems very valuable to me.
10:40 < BlueMatt> i mean you can go build an as map, get the set of p2p addresses and look at the results :)
10:41 < BlueMatt> gleb: we should probably make sure to include any multiple bucketing changes in the same release
10:41 < BlueMatt> to void changing buckets twice
10:41 < nehan> adding a new file that needs to be maintained is always annoying
10:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
10:42 < jonatack> pinheadmz: i think amiti has been spending time on p2p testing, but yeah, it's not simple
10:42 < gleb> pinheadmz: Not sure what you want, but my script in the issue somewhat simulates all this stuff.
10:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
10:42 < gleb> Like, it operates with real asmap and real list of reachable nodes.
10:42 < jonatack> #action: run and review gleb's script
10:43 < amiti> mmm, yes I've been doing some p2p testing, but not at this level
10:43 < amiti> which is different cause of what pinheadmz is saying
10:43 < pinheadmz> im just curious, the script with real asmap makes sense
10:44 < jonatack> amiti: right, true
10: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.
10: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.
10:45 < survey> gleb yes, I think the point by which we measure these changes is how they preform relative to /16 bucketing
10:45 < jonatack> and ASNs are supposed to be globally unique
10:45 < jonatack> s/minimum of 8/8/
10:46 < gleb> But yeah, from the repo/release maintainers point of view, doing all this asmap stuff is not trivial I guess.
10: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?
10: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
10:47 < gleb> Worst case: they get bucketing, which is as powerful as pre-asmap. This is my intuition.
10:48 < jonatack> one thing i found interesting was ariard extending the thinking to the LN this week
10:48 < jonatack> ariard posted on the lightning-dev mail list about network (eclipse iirc) attacks here:
10:48 < jonatack> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002369.html
10:48 < emzy> nehan: worst case. There is only one AS left. And it is owned by one company.
10:49 < pinheadmz> yeah - this should apply to every p2p right? tor, etc
10:49 < nehan> gleb: how does it fall back to bucketing?
10:50 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving]     
10:50 < gleb> nehan: I feel we are confused with terms there. Bitcoin Core currently has /16 bucketing. I'm suggesting ASN bucketing.
10:50 < gleb> I'm saying in the case you explained, a user will get roughly as much security as /16 bucketing provides.
10: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
10:51 < gleb> No, it does not happen at all. This is just my estimate of the security a user gets.
10: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
10:52 < survey> nehan you're question being: what is the fallback behavior asmap?
10:52 < gleb> https://www.irccloud.com/pastebin/nt4Ydajw/
10:52 < gleb> fuck
10:52 < gleb> If we measure diversity of peers. Currently /16 is doing 6/10, asmap will do 10/10.
10:52 < gleb> In 10 years, both of them might be equally ~4/10 with the same chance.
10: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
10: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
10: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.
10:54 < nehan> gleb: thanks! still trying to understand your PR/design.
10:54 < gleb> thank you, feel free to ask more.
10:54 < jonatack> 5 minutes everyone!
10:55 < gleb> The implementation of asmap integration is actually not that difficult — just require a bit of learning how AddrMan serialization currently works.
10: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?
10:56 < gleb> Matt suggested it when he was contacted by erebus people.
10:57 < gleb> Maybe the idea was around before, but not from me.
10:57 < emzy> I think it is a good idea.
10:57 < jonatack> The stealthy aspect of Erebus is a good motivation.
10: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.
10:59 < jonatack> #action improve the logging of the PR as per suggestions here (and by Ethan Heilman)
10:59 < jonatack> Any last questions?
10:59 < jonatack> Thanks everyone!
10:59 < pinheadmz> good jam everyone! ty
10:59 < jonatack> Thank you gleb and BlueMatt
11:00 < jnewbery> Thanks jonatack. Great notes and great meeting!
11: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?
11:00 < jonatack> #action review the PR
11:00 < jonatack> #endmeeting
11:00 < survey> wondering if any other project could make use of it
11: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.
11:00 < jonatack> gleb: +1
11:00 < survey> +1     
11:01 < jonatack> jnewbery: thanks!
11:01 < emzy> Thank you all!
11:01 < survey> thanks jonatack gleb BlueMatt jnewbery
11:01 < survey> and great questions from everyone
11:02 < _andrewtoth_> thanks all!
11: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.
11:02 < gleb> survey: It's actually pretty generalizable I would say.
11:02 < survey> yeah that's my thinking
11:03 -!- lightlike [~lightlike@2001:16b8:5718:f700:6def:1ede:10e3:b37d] has quit [Quit: Leaving]     
11:08 < gleb> survey: There are not that many systems with these requirements I would say. And most of bLoCkChAiNs don't have trivial protections on the p2p layer, so those would be pretty far from these considerations.
11:32 < jnewbery> Meeting Log posted: https://bitcoincore.reviews/16702.html#meeting-log
11:33 -!- survey [~survey@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: survey]     
11:37 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 276 seconds]     
11:38 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
11:39 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
11:41 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
11:43 -!- diogoser1io [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
11:44 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 246 seconds]     
11:47 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
11:49 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving]     
11:56 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
11:57 -!- diogoser1io [~diogoserg@176.24.23.243] has quit [Ping timeout: 276 seconds]     
12:00 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
12:06 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:19 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 250 seconds]     
12:24 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
12:31 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 246 seconds]     
12:34 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
12:34 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
12:36 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
12:52 -!- diogoser1io [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
12:53 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 265 seconds]     
12:58 -!- diogoser1io [~diogoserg@176.24.23.243] has quit [Ping timeout: 250 seconds]     
12:59 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
13:07 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 268 seconds]     
13:10 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
13:19 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 265 seconds]     
13:26 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews     
13:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 260 seconds]     
13:44 -!- b10c [~Thunderbi@mue-88-130-54-169.dsl.tropolys.de] has quit [Ping timeout: 252 seconds]     
13:52 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
13:52 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
14:09 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
14:15 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Quit: Lost terminal]     
14:50 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection]     
18:44 -!- felixfoertsch23 [~felixfoer@2001:16b8:5019:ab00:21e8:5659:1ddb:63e8] has joined #bitcoin-core-pr-reviews     
18:44 -!- felixfoertsch [~felixfoer@2001:16b8:5046:5200:21e8:5659:1ddb:63e8] has quit [Ping timeout: 245 seconds]     
19:09 -!- felixfoertsch [~felixfoer@92.117.47.103] has joined #bitcoin-core-pr-reviews     
19:10 -!- felixfoertsch23 [~felixfoer@2001:16b8:5019:ab00:21e8:5659:1ddb:63e8] has quit [Ping timeout: 276 seconds]     
19:21 -!- slivera_ [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews     
19:52 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
20:12 -!- davterra [~dulyNoded@104.140.15.11] has quit [Quit: Leaving]     
20:41 -!- davterra [~dulyNoded@104.140.15.11] has joined #bitcoin-core-pr-reviews     
22:18 -!- slivera_ [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Quit: Leaving]     
22:58 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #bitcoin-core-pr-reviews