Periodically make block-relay connections and sync headers (
p2p) Nov 25, 2020
The PR branch HEAD was 93a0ec1a at the time of this review club meeting.
eclipse attack is
when an adversary is able to isolate a victim from the Bitcoin network by
taking over all of its connections. We covered eclipse attacks in the review
club meetings for PR 16702
and PR 17428.
Block-relay-only connections are a type of connection where nodes do not
participate in transaction or address relay and only relay blocks. An
effective way for a spy node to infer the network topology is to observe the
timing and details of transaction and address relay, so these block-relay-only
connections obfuscate network topology, helping to mitigate eclipse attacks.
Block-relay-only connections were introduced in
#15759. After these changes,
nodes by default open two outbound block-relay-only connections on startup.
We discussed this PR in a previous review
club. Refer to the notes and log from
that meeting if you’re interested in learning more.
This week’s PR,
proposes a more advanced use of block-relay-only connections to further
mitigate eclipse attacks. After this PR, the node will periodically initiate
an additional block-relay-only connection, and then sync headers to try to
learn about new blocks.
After the node opens an additional block-relay-only connection to a peer, it
begins to sync headers. If this reveals new blocks, the eviction logic will
rotate out an existing block-relay-only connection. If no new blocks are
discovered, the connection is closed. It’s important for this eviction logic to
be carefully reviewed.
Did you review the PRs?
Concept ACK, approach ACK, ACK, or
Describe a scenario in which periodic block-relay-only connections could
help prevent an attack?
What are potential downsides to the concept? Are there any ways it could
reduce security guarantees?
What happens if we learn about new blocks when opening one of these new
How does the existing stale tip detection work? What are the differences
compared to this mechanism?
How do we maintain the count for block-relay-only connections? What changes
in this PR?
At a high level, how does outbound eviction work? What changes in this PR?
1 17:01 <jnewbery> #startmeeting
3 17:01 <felixweis> hi all!
14 17:01 <michaelfolkson> hi
16 17:01 <jnewbery> welcome all!
18 17:01 <jnewbery> great turnout today. Must be a popular PR!
20 17:02 <jnewbery> anyone here for the first time?
22 17:02 <glozow> it's because jnewbery is a popular person
23 17:02 <jnewbery> Hi joelklabo. Thanks for joining us!
24 17:03 <jnewbery> Normal reminders: feel free to ask any questions at any time. We're all here to learn and all are welcome
25 17:03 <jnewbery> don't ask to ask, just ask
27 17:03 <blanching> welcome joelklabo
28 17:03 <jnewbery> amiti prepared some notes and questions for this meeting, which we'll use to guide the conversation, but feel free to jump in at any time
29 17:03 <jnewbery> who had a chance to review the PR (y/n)?
32 17:04 <pinheadmz> y just on github
33 17:04 <willcl_ark> a brief skim over the top...
39 17:04 <michaelfolkson> y
42 17:05 <jnewbery> ok, any first thoughts about the PR? concept ACK/NACK? What's it trying to achieve?
43 17:05 <pinheadmz> more eclipse attack mitigation, more condfidence that the node is on the mnost work chain by explosring the p2p netowrk
44 17:06 <jonatack> y. i've been collecting data from a node running the branch with custom logging. need to analyze it further, but connectivity does seem improved.
45 17:06 <dappdever> Are block-relay-only connections less observable than address and transaction relays?
46 17:06 <jnewbery> pinheadmz: exactly right!
47 17:06 <pinheadmz> seems like overkill to me but i dunno if its a nack
48 17:06 <joelklabo> periodically checking for new block-relay-only peers to make sure your not only connected to dishonest peers
49 17:06 <blanching> pinheadmz: what's "explosring"?
50 17:06 <emzy> concept ACK. Sounds good to me.
52 17:07 <pinheadmz> blanching connecting to more nodes and checking for more-work blocks
53 17:07 <michaelfolkson> Overkill as in we don't need to worry about eclipse attacks pinheadmz?
54 17:07 <jnewbery> *exploring
55 17:07 <dhruvm> (1) Mitigation against eclipse attacks by periodically creating new relay-only connections to look for higher PoW elsewhere and (2) Honest peers helping bridge other trapped honest nodes.
56 17:07 <pinheadmz> michaelfolkson overkill in that we already have block-only connections and 8 peers
57 17:07 <glozow> it could be better for eclipse attacks, provided you have a healthy/diverse addrman
58 17:07 <michaelfolkson> It is incremental, sure. But incremental better than nothing
59 17:07 <jnewbery> dappdever: yes, relaying transactions and addrs reveals information about the network topology, which could be used by a spy to map your connections
61 17:08 <michaelfolkson> Can we just double check I have terminology right? Stale tip is when your tip has a new block on top of the previous tip right?
62 17:08 <michaelfolkson> *I
63 17:09 <michaelfolkson> Nothing to do with orphan blocks or anything like that
64 17:09 <pinheadmz> stale tip means no new blocks in a while
65 17:09 <pinheadmz> orphan blocks like the name suggests menas a block with no parent
66 17:09 <elle> even if an attacker can map your connections, how can they actually perform the eclipse attack? how can the attacker get you to disconnect you other peers and connect to them instead?
67 17:09 <michaelfolkson> Just missing the latest block?
68 17:09 <pinheadmz> doesnt happen anymore since headers first
69 17:09 <lightlike> I'm still a a bit sceptical: if your addrman has been corrupted, the additional periodic block-only connections don't seem to help much (because you likely won't connect to a good peer). But if your addrman is healthy, how did you get eclipsed in the first place?
70 17:09 <joelklabo> I was curious why block-only peers reveal less about network topology but I'll check if that was covered in the previous reviews
71 17:09 <jnewbery> michaelfolkson: that's a really great question. Terminology is important here, and people often get it wrong or get confused
72 17:09 <glozow> lightlike: that's my bit of skepticism as well
74 17:10 <michaelfolkson> Great, thanks
75 17:10 <pinheadmz> elle i think a real eclipse involves filling up a peers addrman with "poinson" entries and just waiting and waiting for those to get rotated in, or possibly joinging with a DoS attack to force the node to restart ?
76 17:10 <pinheadmz> *poison
77 17:11 <jnewbery> I'd say that 'stale' doesn't mean the block is old. It means that we know about a competing chain with more work
78 17:11 <elle> oh! ok cool. thanks pinheadmz :)
79 17:11 <michaelfolkson> lightlike, glozow: I think you are thinking in boolean rather than on a continuum. Your addrman isn't either perfectly pure or perfectly poisoined. It could be partially poisoned or under attack
80 17:12 <michaelfolkson> Any bolstered defence is better than nothing
81 17:12 <dhruvm> Since certain nodes are probably larger targets for eclipse attacks, small incremental benefits for them should have significant network benefits?
82 17:13 <jnewbery> Right, defense in depth. But I think a good question is whether the potential improved protection is worth the additional complexity
84 17:14 <jnewbery> We've already started touching on the next question: Describe a scenario in which periodic block-relay-only connections could help prevent an attack?
85 17:14 <joelklabo> thanks amiti, I'll check that out
86 17:14 <sipa> one argument may be the symmetry: we create extra normal connections that may get promoted to normal ones... it feels natural to do the same with blockonly connections
87 17:15 <jnewbery> Thanks amiti! That was a great talk.
89 17:15 <ajonas> Would a case be when the node has been eclipsed but their addrman still has honest addresses in it?
90 17:16 <dappdever> A node could receive block-relay-only blocks that reveal the legit chain that was attempting to be obfuscated by an attacker
91 17:16 <amiti> building on the conversation so far- I guess if an adversary has been trying to poison your addrman, has taken over some of it eg. 60%. you could happen to have all your outbound connections to them, but then rotating through some of the others connects you to the honest network?
92 17:16 <jnewbery> ajonas: yes, I think that's the scenario where this would help.
93 17:16 <joelklabo> addrman, that's address manager I'm guessing?
95 17:17 <dhruvm> amiti: is the opposite true as well? if you are eclipsed, this makes it more likely that an honest node reaches out?
96 17:17 <jnewbery> joelklabo: right. It's where we store addresses of potential peers.
97 17:17 <willcl_ark> If we are worried about having a poisoned addrman, and then with a feeler we detect that we're on a stale tip, would we not want to promote that new ("honest") peer to a NODE_NETWORK peer, rather than blocksonly?
98 17:17 <sipa> ip addresses, to be clear; not bitcoin addresses
99 17:17 <pinheadmz> so this PR introduces kind of a slow churn through the addrman
100 17:17 <jnewbery> sipa: thanks for the clarification!
101 17:17 <willcl_ark> unless blocksonly also relays addrs?
102 17:18 <amiti> dhruvm: ah fair, but I think it would be harder to be eclipsed if you're also enabling inbounds? although maybe not that much harder if you were just spinning up 🤔
103 17:18 <pinheadmz> if theres at least one honest peer in there well eventually connect to it and learn the truth about reality
104 17:18 <jnewbery> willcl_ark: no. Just blocks. We want block-relay-only peers to be as undetectable as possible, so they don't take part in address relay
105 17:18 <jnewbery> (I assume you mean block-relay-only peers, not -blocksonly?)
106 17:18 <dappdever> Where do the block-relay-only inbound connections come from? How do they discover your address initially?
107 17:19 <willcl_ark> jnewbery: hmmm. So we would be OK with a "bad" Addrman as long as we keep receiving good blocks?
108 17:19 <willcl_ark> (and yes that's what I mean!0
109 17:19 <pinheadmz> dappdever all inbound connections just come from your public IP being gossiped by peers.
110 17:19 <sipa> dappdever: they're just normal nodes, and their IP address gets rumoured
111 17:19 <pinheadmz> from your nodes perspective, the block only peers that matter are always outbound conenctions
112 17:19 <dhruvm> amiti: That means this PR helps even when your adddrman is 100% poisoned?
113 17:19 <dappdever> got it, thanks
114 17:20 <sipa> dappdever: it's not that these are secret nodes; just rhe existance of the connection that is less observable
115 17:20 <joelklabo> sipa, what does rumoured mean?
116 17:20 <jnewbery> Just so everyone is clear, -blocksonly mode and block-relay-only peers are two different concepts. Again, I think it's important to be precise with terminology because they mean different things and it's easy to get confused between them otherwise.
118 17:20 <sipa> joelklabo: nodes sharing data with each other... "hey i know a cool IP address of a bitcoin node"
119 17:20 <sipa> joelklabo: address relay
120 17:21 <joelklabo> I see, thanks
121 17:21 <michaelfolkson> How long does it take for a newly mined block to propagate across the network? You would want your block-relay connection to have the chance to give you the latest block rather than being cut off instantly?
122 17:21 <sipa> jnewbery: ah yes, thanks - i may be getting the name wrong sometimes
123 17:21 <jnewbery> rumour/gossip/relay are mostly interchangeable
124 17:22 <jnewbery> propogation/dissemination/promulgation. What a rich language we have.
125 17:22 <dappdever> are the rumours just a different message type? Or does it happen on a different protocol?
126 17:22 <dappdever> or different socket?
127 17:22 <sipa> dappdever: all the same P2P protocol, same connections, same sockets
128 17:23 <jnewbery> dappdever: addresses are 'rumoured' or 'gossipped' or 'relayed' using the `addr` message in the P2P protocol
130 17:23 <joelklabo> so the nodes you are connecting to are all the same you just ask those two for block only
132 17:23 <jonatack> dappdever: you might find helpful the enum class ConnectionType documentation in src/net.h
133 17:23 <jnewbery> joelklabo: yes. In fact, you're connecting to them and saying "no transactions please". They may still gossip addresses to you but you'd ignore them
134 17:24 <willcl_ark> so what are the assumptions here: we are currently eclipsed, but we have _some_ honest addresses in our addrman. This PR will eventually rotate through enough block-relay-only peers that we will discover a more-work chain, then replace one of our current block-relay-only peers with the new peer?
135 17:24 <michaelfolkson> And all connections are taken from the addrman right? If your addrman is 100 percent poisoned and all connections are controlled by adversary you're done unless you restart
136 17:24 <jnewbery> willcl_ark: exactly right
137 17:24 <jnewbery> michaelfolkson: you're done even if you restart
138 17:24 <willcl_ark> jnewbery: ok thanks
139 17:25 <jnewbery> because when you restart you'll connect to peers from your addrman
140 17:25 <michaelfolkson> jnewbery: Restart with DNS seeds
141 17:25 <sipa> willcl_ark: another way to put it is that with more connections, even just occasionally, the threshold of how much of addrman needs to be under attacker control increases
142 17:25 <jonatack> michaelfolkson: or addnode an honest peer
143 17:25 <joelklabo> is the reason we ask for blocks only to save bandwidth?
144 17:25 <jnewbery> I'd need to look at it again, but I don't think we use DNS seeds if our addrman is already full
145 17:25 <sipa> joelklabo: less bandwidth, and less leaking of network topology
146 17:26 <sipa> joelklabo: from such a block-relay connection, the peer has a harder time inferring who you're connected to
147 17:26 <dhruvm> michaelfolkson: If you are 100% poisoned, does this PR increase the chance that an honest peer reaches out if you have inbounds enabled?
148 17:26 <jnewbery> joelklabo: I'd say mostly less leaking of network topology. The fact that they use less bandwidth/memory/CPU is a nice property that means we can potentially have more of them
149 17:26 <pinheadmz> jnewbery actually that makes me think - what if this PR actually queried the DNS seeds? they are centralized endpoints but are trusted
150 17:27 <sipa> pinheadmz: dns seeds are a last resort effort to find peers
151 17:27 <pinheadmz> like, use a completely different protocol besides bitcoin p2p to get new peers
152 17:27 <willcl_ark> sipa: thats an interesting way to look at it. To be honest, I am kind of suprised nodes don't handshake and request tip hash (or a getheaders) from more nodes before this PR
153 17:27 <pinheadmz> sipa yes but they exist outside the p2p network and cant be eclipesed
154 17:27 <pinheadmz> unless your DNS resolver is also under attack
155 17:27 <joelklabo> harder to infer network topology because just less traffic between the nodes? Sorry if I'm repeating questions
156 17:27 <pinheadmz> or a seed maintainer is under attack
157 17:27 <michaelfolkson> dhruvm: This PR has no effect on that. But yeah an inbound request could save you generally (I think...)
158 17:27 <jesseposner> There are many flavors of eclipse attacks, and I believe that the block-relay-only connections are trying to mitigate against attacks that target the connected peers directly. It doesn't protect against a 100% poisoned addrman state. It simply makes it more difficult to discover all the connected peers.
159 17:27 <jnewbery> pinheadmz: all of this stuff is easy if you just trust a centralized authority!
160 17:28 <jnewbery> you could just get your blocks directly from sipa
162 17:29 <ajonas> joelklabo - transactions can be fingerprinted to see who is connected to who. It's easier to infer topology through tx relay.
163 17:29 <jnewbery> sorry, that was a bit flippant. But using DNS seeds does have a downside. One is that you're potentially telling people that you're running a bitcoin node that you wouldn't otherwise be doing
164 17:29 <emzy> I only trust blocks I mined myself ;)
166 17:29 <lightlike> I'd hope that it would be much easier to corrupt the DNS nodes (that are on central places with actual, known operators) than our addrman.
167 17:29 <pinheadmz> jnewbery point taken! see Vitaliks recent post about "weak subjectivity" i.e. check a block exploerer now and then 😬
168 17:30 <jnewbery> emzy: that's an impressive level of self-sovereignty
169 17:30 <jnewbery> ok, next question: What are potential downsides to the concept? Are there any ways it could reduce security guarantees?
170 17:30 <sipa> after altcoins, egocoins; everyone has their own
172 17:31 <joelklabo> ajonas, thanks
173 17:31 <michaelfolkson> dhruvm: "the behavior introduced here is beneficial to not just the node doing it, but to the whole network, as a node already connected to the honest network that is periodically connecting to new peers to sync tips with others is helping bridge the entire network"
174 17:31 <michaelfolkson> dhruvm: I think what Suhas means there is that the fewer nodes that are owned/eclipsed the better for the network
175 17:32 <sipa> joelklabo: tx relay and addr relay are relatively easy to use for identifying nodes and connectioms; there are various known techniques, and it's not so surprising... just construct a random tx or addr message, send it somewhere, and see where it appears
176 17:32 <sipa> joelklabo: this is not true for blocks, as they're very infrequent by design, and very expensive to construct
177 17:32 <sipa> joelklabo: look up txprobe
178 17:32 <joelklabo> I see, thanks sipa
179 17:33 <ajonas> michaelfolkson dhruvm - well there is also a subtle upgrade to find new block-only peers that are "useful" as in they deliver blocks that our current peers aren't delivering
180 17:33 <sipa> jnewbery: reducing open listening sockets on the network seems the most obvious downside
181 17:33 <jnewbery> We do make use of techniques to try to mask tx origination (e.g. randomized timer, batching invs), but I think those are really adding statistical noise. With a large enough sample set, I think it would still be possible to map the network
182 17:34 <sipa> jnewbery: exactly
183 17:34 <jonatack> joelklabo: if you run a node, you can observe the network interactions using -netinfo to help get an intuition for these things
184 17:34 <jonatack> watch ./src/bitcoin-cli -netinfo 4
185 17:34 <joelklabo> thanks, I'll check that out
186 17:34 <pinheadmz> jnewbery i dont see how this could affect security but yeah perhaps privacy
187 17:35 <lightlike> one downside would be that an attacker that we connect to and that can send us a new block would replace a potentially honest blocks-only connection - although this would be really costly for the attacker, because they would basically need to be a miner withholding a new block from the network just to eclipse us further.
188 17:35 <jnewbery> sipa: yes, that does seem to be the main downside. Also the cost/complexity/maintenance that's associated with any change
189 17:35 <michaelfolkson> ajonas dhruvm: So the more an individual node can find useful peers the easier it makes it for everybody else?
190 17:35 <pinheadmz> and honestly, if bandwidth were free computaitonally and financially - wouldnt there be a benefit to connecting to all 9,000 nodes?
191 17:35 <michaelfolkson> Not for privacy pinheadmz
192 17:35 <dhruvm> michaelfolkson: ajonas: How is a node already connected to an honest network, helping bridge the entire network by making new "feeler" block-relay-only connections?
193 17:35 <jnewbery> Next question. What happens if we learn about new blocks when opening one of these new block-relay-only connections?
194 17:36 <ajonas> If we learn a new block, we rotate out an existing next-youngest block-relay peer in favor of the new peer.
195 17:36 <blanching> batching invs only hides data flows / timing analysis which in some domains can obfuscate some topology but weakly, probabilistically (high resolution: eve knows x was sent before y and can conclude A)
196 17:36 <amiti> dhruvm, michaelfolkson: block-relay-only connections also help with grander partition attacks than just eclipse attacks (eg. a malicious party trying to create a network split). which is more a network level concern (and everybody loses if that happens)
197 17:36 <blanching> not sufficient to obfuscate topology well
198 17:37 <jnewbery> blanching: indeed. It can make mapping the topology more costly/difficult but can't prevent it entirely
199 17:37 <michaelfolkson> Good point amiti
201 17:37 <dhruvm> michaelfolkson: ajonas: amiti: So that comment is more about block propogation times rather than the honesty of the peer?
202 17:38 <ajonas> dhruvm: that would make sense to me
203 17:38 <jesseposner> ajonas: +1
204 17:38 <michaelfolkson> How long does it take for a newly mined block to propagate across the network? You would want your block-relay connection to have the chance to give you the latest block rather than being cut off instantly?
205 17:38 <murch> jnewbery: but without auth, how would you know they're from sipa?
206 17:39 <blanching> michaelfolkson IIRC something like 6-18 seconds is considered healthy propagation time
207 17:39 <jonatack> murch: i know when i get a block from sipa
208 17:39 <sipa> for non-miners the propagation time really doesn't matter
209 17:39 <michaelfolkson> So should you wait 18 seconds before kicking out a block-relay-only connection blanching?
210 17:39 <sipa> as long as it's not close to interblock time, of course, as you want to see confirmations
211 17:39 <blanching> 6-18 seconds. e.g. 1-3% of the average block creation window
212 17:40 <jnewbery> ajonas: if we receive a block from the additional block-relay-only peer while we're connected, will we _always_ disconnect the second youngest?
213 17:40 <sipa> these improvememts are primarily about making sure you get blocks at all
214 17:40 <sipa> not necessarily fast
215 17:40 <blanching> michaelfolkson I'd defer to someone else to answer that
216 17:40 <willcl_ark> jnewbery: there is a comparison to see who gave us a block most recently too
217 17:41 <blanching> sipa: agreed. it's about preventing peer ossification which would decrease attack costs
218 17:41 <michaelfolkson> You don't want to kick out your block-relay-only connection for no reason
219 17:41 <glozow> could someone elaborate on open listening sockets? how limited is the resource and what's the cost of taking up more?
220 17:41 <pinheadmz> glozow there is a maxInbound setting, right?
221 17:41 <blanching> for clarity: peer ossifying = decreases attack costs
222 17:42 <sipa> glozow: it hasn't been a problem for years, but early in bitcoin's history there was a time when inbound sockets were hard to find
223 17:42 <jnewbery> willcl_ark: right, we see which of our two youngest block-relay-only peers (which will be one of the existing block-relay-only peers and the 'additional' block-relay-only peer) gave us the block least recently and consider it for disconnection
224 17:42 <ajonas> jnewbery: I guess not if we're under the respective conn limits?
225 17:42 <sipa> this was when light clients with permanent p2p connections were far more popular than today
227 17:43 <sipa> glozow: our prioritization logic for incoming connections makes it also harder to attack, unlesd you have lots of source IP networks
228 17:43 <glozow> oh, you mean like, there are fewer total available inbounds in the network? so it'd be harder for a new node to get a good set of outbound connections?
229 17:43 <sipa> glozow: yes
230 17:43 <willcl_ark> ajonas: I think only if we currently have a feeler active
231 17:43 <emzy> But we will free a conection if we find a better block-relay-only peer. So nothing changes.
232 17:44 <dhruvm> blanching: are anchors evidence that some ossification is useful?
233 17:44 <jnewbery> This function EvictExtraOutboundPeers() is called on a timer every 45 seconds
234 17:44 <lightlike> jonatack: In your test on mainnet, how often per hour would you actually succesfully connect to a new outbound peer and compare headers? In a short run on testnet yesterday with a fresh node (no peers.dat), that was rather rare, most of the time I'd get no response and the 5min poisson timer would start again.
235 17:44 <willcl_ark> as GetExtraBlockRelayCount will return > 0
236 17:44 <sipa> glozow: 128 incoming slots per publicly reachable peer, by default... it's a finite resource that can be used up
237 17:45 <sipa> years ago we'd just stop accepting incoming connections when the limit was reached... which made it kind of trivial to attack
238 17:45 <jnewbery> willcl_ark: feelers aren't relevant here. GetExtraBlockRelayCount() doesn't count feelers.
239 17:45 <emzy> btw. all my nodes have more then 128 connections incoming.
240 17:45 <amiti> for the questions around how long it takes blocks to propagate, this is a cool resource:
243 17:46 <willcl_ark> jnewbery: damn my terminology! I meant an extra block-relay-only peer over the limit (of two?)
244 17:46 <pinheadmz> emzy would you be willing to share how you host those/ what the cost is?
245 17:46 <glozow> sipa: ah okay i see, are inbounds less scarce now? does anyone ever have a problem getting 10 outbounds?
246 17:46 <blanching> amiti
247 17:46 <jonatack> lightlike: i've been busy with things for the 0.21 release and meaning to get back to the data, but IIRC, using this PR i did see greater peer diversity (e.g. higher peer id numbers) than usual. don't depend on that info though; i need to refresh and look at the data
248 17:46 <blanching> amiti i didnt realize they were still updating that thanks
249 17:46 <jnewbery> willcl_ark: ah! Terminology is important!!!
250 17:46 <sipa> that's no longer the case, but still... if there are more than 128*public_nodes/10 nodes making connections, not everyone would get them
251 17:46 <jnewbery> otherwise we're talking about different things and we don't realise it :)
252 17:46 <sipa> glozow: yeah, i'm talkimg about 2012 or so
253 17:47 <michaelfolkson> Thanks amiti
254 17:47 <jonatack> lightlike: i don't remember more but will contact you, if you don't mind, when i look at it
255 17:47 <sipa> glozow: i haven't seen evidence of scarcity since
256 17:47 <emzy> pinheadmz: all only HDD. Costs are about $10 to $50.
257 17:47 <sipa> jnewbery: misunderstandings are the basis of the best inventions
258 17:47 <jnewbery> ok, so if we call EvictExtraOutboundPeers(), and we currently have an additional block-relay-only peer (i.e. 3 in total), and the youngest gave us a block more recently than the second youngest, what do we do?
259 17:47 <amiti> sipa: 128 incoming? I thought 125 total - 8 (outbound) - 2 (block-relay-only)
260 17:47 <pinheadmz> emzy ahhhh HDD, must be slow to sync - but these are VPS? like amazon, digital ocean, etc?
261 17:48 <amiti> (searching code now)
262 17:48 <sipa> amiti: you're right, i was simplifying
263 17:48 <sipa> and/or misremembering
264 17:48 <emzy> pinheadmz: some are VPN others are dedicated servers. IBD is like one day.
265 17:48 <glozow> sipa: makes sense. i always thought the inbound : outbound ratio seemed really high, and people explained because not everyone enables inbounds, so the people who do have to make up for it.
266 17:48 <jesseposner> jnewbery: disconnect the second youngest
267 17:48 <lightlike> jonatack: if you had net logging enabled, you could also grep for the new log entries (e.g. "keeping block-relay-only peer=X chosen for eviction")
268 17:48 <michaelfolkson> sipa glozow: Something to monitor if Neutrino becomes widely used
269 17:48 <jnewbery> sipa: apparently so. The half-dose/full-dose oxford vaccine regime is more effective than the full-dose/full-dose regime and they only found out because they'd accidentally given the half dose to a bunch of people
270 17:49 <jesseposner> jnewbery: unless the youngest hasn't given us a block, in which case disconnect the youngest
271 17:49 <sipa> jnewbery: erlay was invented by gleb who misunderstood gmaxwell's idea
272 17:50 <jonatack> lightlike: yes, i did have it enabled and was grepping for "enabling\|block-relay-only" and -i "enabling\|block-relay-only\|extra"
273 17:50 <jonatack> lightlike: (based also on my added logging)
274 17:50 <jnewbery> jesseposner: are there any conditions where we wouldn't disconnect either?
275 17:50 <lightlike> jonatack: cool, I'd be interested in the statistics once you find the time for that!
276 17:51 <jonatack> lightlike: happy to, i'm sure you'll have good ideas for interpreting it
277 17:52 <willcl_ark> looks like we disconnect youngest_peer.first as default
278 17:52 <willcl_ark> ah, if we are getting a block right now then we might not disconnect either
279 17:53 <jnewbery> willcl_ark: youngest_peer.first refers to the peer id. (youngest_peer is a std::pair of peer id and the time of the latest block from that peer)
280 17:54 <jnewbery> willcl_ark: yes, exactly. If we're currently downloading a block from that peer, then we won't disconnect it
281 17:54 <michaelfolkson> sipa jnewbery: Misunderstandings are great for inventing things. Not so great for analyzing a robustness of a system and avoiding bugs ;)
282 17:54 <jnewbery> which makes sense. We shouldn't disconnect a peer if it looks like it's about to give us a block
283 17:54 <ajonas> Am I reading this right that we need to have been connected to those peers for more than 30 seconds?
284 17:55 <willcl_ark> ajonas: looks like that to me: more than 30 seconds connection time and not currently receiveing a block
285 17:55 <jnewbery> ajonas: exactly right. If the timer for EvictExtraOutboundPeers() pops a few seconds after connecting to the additional block-relay-only peer, then we haven't given it enough time to send us a block, so we don't disconnect
286 17:56 <jnewbery> Ok, time for one last question. How do we maintain the count for block-relay-only connections? What changes in this PR?
287 17:57 <jonatack> lightlike: looking at it right now, a few (~4 to 10) times an hour
288 17:57 <jnewbery> hint: we're looking in ThreadOpenConnections()
291 17:59 <jnewbery> That function is really long and really confusing, but it's essential to understanding how we manage our outbound connections, so definitly worth digging into if this stuff interests you
292 18:00 <michaelfolkson> Cool
293 18:00 <jnewbery> That's time everyone. Thanks for coming and chatting about p2p! And thanks again to amiti for preparing the notes and questions.
294 18:00 <lightlike> jonatack: thanks, that sounds quite good to me, considering that at a 100% success rate we'd have 12 hits per hour on average.
295 18:00 <blanching> thanks amiti jnewbery
296 18:00 <lightlike> thanks!
297 18:00 <jesseposner> Thanks!
298 18:00 <ajonas> thanks jnewbery and amiti for notes
299 18:00 <jnewbery> next week, glozow is hosting. Don't miss it!
300 18:00 <jnewbery> #endmeeting
301 18:01 <glozow> thanks jnewbery!!!
302 18:01 <willcl_ark> thanks jnewbery!
303 18:01 <jonatack> thanks amiti and john!
304 18:01 <elle> thanks everyone!
305 18:01 <dhruvm> Thank you, jnewbery, amiti and suhas!
306 18:01 <jnewbery> thank you glozow!!!!!
307 18:01 <amiti> thanks jnewbery, thanks all :)
308 18:01 <emzy> tnx amiti and jnewbery
309 18:01 <glozow> and thank you amiti!!!!!!!!!!!!
310 18:01 <jnewbery> ok time out
311 18:01 <jnewbery> enough !s
312 18:01 <michaelfolkson> Cut the conversation log