Try to preserve outbound block-relay-only connections during restart (
p2p) Feb 26, 2020
The PR branch HEAD was 78b2f9503 at the time of this review club meeting.
eclipse attack is when an attacker is able to isolate a node from all honest
This PR seeks to mitigate a specific type of eclipse attack by introducing
anchor connections, which are peers that a node tries to reconnect to on
PR 15759 changed the
peer-to-peer behavior to add two blocks-only connections. We discussed
this change in a previous Review Club
meeting. I recommend you read
the notes, questions and meeting log from that meeting if you’re not
already familiar with those changes.
Eclipse attacks occur
when an adversary is able to isolate a victim’s node from the rest of the
network. We discussed eclipse attacks in previous Review Club meetings,
including the discussion on PR
16702. If you’re unfamiliar with the
concept of eclipse attacks, the Optech topics page and the notes from that
meeting contain links to many resources on the subject.
restart-based eclipse attack occurs when the adversary is able to add its
own addresses to the victim’s address manager and then force the victim to
restart. If the attack succeeds, the victim will make all of its connections
to the adversary’s addresses when it restarts.
Issue 17326 proposed
persisting the node’s outbound connection list to disk, and on restart
reconnecting to the same peers. It’s worth reading the full discussion in
that issue, since there are a lot of subtle points around which peers
should be persisted.
PR 17428 adds
functionality to preserve outbound block-relay-only connections during
restart. Issue 17326
The most likely way for an eclipse attack to occur is by forcing a victim
to restart and then making it connect only to malicious peers.
In the 2015 implementation of Bitcoin Core, an attacker could carry out a
“connection starvation attack”. In this attack, the adversary fills up
all of the available inbound connections on the network and then forces
the victim to reboot. When the victim restarts, he’s unable to connect to
any honest peers on the network since their inbound connections slots are
all filled up. Since anchor connections only help identify honest peers, not
connect to them, they are not an effective mitigation strategy against such an
Since then, Bitcoin Core has implemented logic to sometimes rotate through
incoming connections when the max number is hit. This means the victim has a
way to successfully evict an attacker’s connections to honest peers and
reconnect to those honest peers. While this means that it’s possible for an
attacker to eclipse a node without it rebooting, it also makes carrying out the
eclipse attack more complex.
Reconnecting to the same outgoing connections on restart makes the network graph more static. While
this helps maintain longstanding honest connections and prevent an eclipse
attack, this can have a negative effect on privacy since the network topology
is easier to map.
There are some other reasons that we might not want to anchor all connections:
A victim of an eclipse attack has no way of escaping if all of his connections
are anchored to the adversary.
Strong persistence can contribute to the network self-partitioning. For
example, if the longer distance connections are less reliable, nodes are
incentivized to connect locally and this could lead to subgraphs per continent.
An attacker could eclipse nodes with a small number of nodes but 100% uptime
and a large capacity for inbound connections. Every time a node adds a
connection to a new peer, if that peer is an adversary then it would be “locked in”
forever with anchoring logic.
The suggestion of using blocks-relay-only peers mitigates the concerns around
reduced outbound peer rotation negatively impacting transaction privacy,
while maintaing the benefit of mitigating from an eclipse attack.
The 2 outbound block-relay-only connections are written to the
file. When a node restarts, it first tries establishing connections with the
anchors before attempting to connect to other peers.
Previously, a node that would quickly reattempt the same outgoing connections
was detected as a spy or mass connector. The new behavior in this PR means that honest
nodes will attempt the same outgoing connections more than once, which was
The current state of this implementation introduces a new risk – if one of the
anchor peers is malicious and is able to exploit a remote crash vulnerability, they
can repeatedly crash the victim’s node. Every time the victim node restarts,
it would connect to the same malicious anchor peer, which could force another
The proposed fix is to forget the anchor peers on an unclean exit.
In reaction to these findings, the PR was
The PR has subsequently been reopened since there are still advantages to
preserving connections when restarting a node. The implementation of the
proposed fix is yet to come. Questions
Did you review the PRs?
Concept ACK, approach ACK, tested ACK, or
(Don’t forget to put your PR review on GitHub.) What is an eclipse attack?
How does an adversary eclipse a node?
What attacks can an adversary execute on the victim?
How does this PR mitigate the attack? What are some limitations of the proposed fix?
How does the anchors.dat file work?
When are peers persisted and removed?
When does the node ignore the contents of anchors.dat?
What are some implications of the timing of adding peers?
What are the conditions for adding an anchor?
Why do we only consider adding blocks-only peers as anchor peers?
What would be the issue of using normal (transaction & block relay) peers
What are limitations of how this implementation chooses anchors?
Why limit to only 2 anchors?
With the current implementation of this PR, how could an adversary carry out
an attack? How is this different from what an attacker would have to do
What is the new risk that this implementation currently introduces? What are
the tradeoffs of the proposed fix (yet to be implemented)? Do you think the
changeset would still be worthwhile? Why?
1 13:00 <jnewbery> #startmeeting
2 13:00 <amiti> jnewbery you beat me to it!
6 13:00 <amiti> hi everyone! welcome to this weeks PR review club
8 13:00 <nothingmuch> ohai
13 13:00 <ecurrencyhodler> hello
15 13:01 <amiti> I had a lot of fun digging into this PR & problem space and think we have lots to talk about :)
18 13:01 <rockzombie2> I have a question: Can someone give a quick explanation of what an eclipse attack is?
20 13:01 <amiti> who got the chance to review this weeks PR?
22 13:01 <amiti> can we do a quick round of y/n?
25 13:02 <hebasto> rockzombie2: every node you are connected are evel
30 13:03 <_andrewtoth_> 0.5y
31 13:03 <amiti> haha rockzombie2 that was exactly how I was planning to start the conversation =P
32 13:03 <rockzombie2> Oh my bad. I was looking at the notes linked in the previous PR club meeting
33 13:03 <rockzombie2> I didn't really get to look at the PR tbh
34 13:03 <nothingmuch> 0.3y
35 13:04 <amiti> continuing on the idea of eclipse attacks, can someone describe how an adversary would eclipse a node?
36 13:04 <luke-jr> I'd like an example that doesn't require MITM, since MITM is unmitigatable..
37 13:04 <pinheadmz> tldr - fill up their addr list with addrs the attacker owns, then forcing them to restart somehow
38 13:04 <pinheadmz> the victim will create outbounds to only the attackers nodes
39 13:05 <amiti> pinheadmz: yup! although one nuance is you don't need to force them to restart, alternatively you could wait for them to restart
40 13:05 <_andrewtoth_> but how do they do the first part - "fill up their addr list with addrs the attacker owns"?
42 13:05 <luke-jr> that seems like the real flaw :P
43 13:06 <pinheadmz> bitcoin nodes send each other addr packets all the time - actually does anyone know if they are allowed ot be unsolicited?
45 13:06 <pinheadmz> or are they only supposed ot be served in rsponse to getaddr or something
46 13:06 <jnewbery> pinheadmz: yes, I believe they can be unsolicited
47 13:06 <amiti> _andrewtoth_: I'm curious to learn more about this too. the addrman is populated based on addr messages received, but I'm unfamiliar with the exact logic of how
48 13:07 <amiti> nehan_: great point. since there is peer rotation logic, its possible for adversaries to take over an addrman without the victim restarting
49 13:08 <amiti> pinheadmz: but there's also the case where a victim has one malicious connection, and then receives solicited addr messages and then over time the adversary poisons the addrman and takes over all the connections
51 13:08 <rockzombie2> How successful would an eclipse attack be? because ultimately, wouldn't the attacker need to do a 51% attack on the whole network before the "eclipsed" node realizes they are not on the main chain?
52 13:09 <amiti> ok, so if a node is eclipsed, what sort of attacks can an adversary execute on the victim?
53 13:09 <rockzombie2> they could convince the node to empty their wallet?
54 13:09 <amiti> can anyone answer rockzombie2's question and explain why eclipse attacks don't require 51% attacks?
56 13:10 <ecurrencyhodler> amiti: Serve malicious blocks with double spends in them.
57 13:10 <pinheadmz> well it still takes a lot of hashpower to find a block
58 13:10 <embark> rockzombie2 and EA is at the P2P level not at consensus or miner level
59 13:11 <pinheadmz> but with the rest of the network blocked, the attacker can take as long as they want
60 13:11 <embark> s/and/an
62 13:11 <amiti> embark: what is EA?
63 13:11 <lightlike> if the eclipsed node is a miner, it won't use their computing power for anything useful.
64 13:11 <pbleam> won't that look suspicious if the attacker takes especially long to serve a new block?
65 13:11 <ecurrencyhodler> rockzomebie2: You only need enough hashpower to find a block to serve a malicious one. If your node is eclipsed, then they can take their sweet time generating the block.
66 13:11 <embark> amiti: my attempt at being lazy :P Eclipse Attack (EA)
67 13:11 <_andrewtoth_> the blocks wouldn't really be malicious with double spends, they would still have to be valid blocks, but they would be on a lower proof of work chain
68 13:11 <pinheadmz> pbleam: actually yes and there is already mitigations like "if i havent seen a block in a while, make an additional outbound connection"
69 13:12 <ecurrencyhodler> _andrewth_: thanks for the clarification.
70 13:12 <pinheadmz> but if all your outbound connections are to attackers, this wont help
71 13:12 <embark> lightlike good point, an Eclipse Attack'ed peer can eventually be fed low PoW blocks and will accept them as valid
73 13:13 <jnewbery> embark: no. The blocks need to be the right difficulty
74 13:13 <nothingmuch> embark: can you clarify eventually? do you mean including difficulty adjustment?
75 13:13 <ecurrencyhodler> pbleam: it depends on how long is a long time. Sometimes it's taken an hour to find a block.
76 13:13 <lightlike> embark: I just meant less competition for the people actually mining on the main chain
77 13:13 <embark> jnewbery: I eclipse you for 4 weeks (unlikely to suceed but a possibility) you will start to accept difficulty discounted blocks, no?
78 13:14 <amiti> there's a lot of different attacks possible on an eclipsed node... I found the notes on the optech topics page interesting for highlighting some at the txn level that I hadn't thought about: https://bitcoinops.org/en/topics/eclipse-attacks/
79 13:14 <embark> actually I probably need to retract that
80 13:14 <nothingmuch> embark: no, difficulty adjustment is triggered by block height, not nominal time
81 13:14 <pinheadmz> embark: no yore right i think, there is the chain-width attack. starting from an old block, the attacker creates a dsihonest chain with fake timestamps that force the difficulty down
82 13:14 <embark> yes I retract
83 13:15 <embark> I was....uhh.. testing people... ha
84 13:15 <amiti> ok moving on, how does this PR mitigate an eclipse attack?
85 13:15 <pinheadmz> although hm that wouldnt force a reorg though huh
86 13:15 <ajonas> I think the LN attack is pretty worrisome
87 13:16 <jnewbery> embark: yes, theoretically if you can eclipse a node over a difficulty retarget, you could decrease the difficulty for their retarget, but you'd still need to do a lot of work to get to that difficulty retarget height. I feel like we're getting a little in the weeds of an unlikely and very expensive attack though
88 13:16 <amiti> ajonas: I agree!
89 13:16 <pinheadmz> amiti: by saving the addr of two peers to disk, then on restart, reconnecting to them instead of picking addrs from the list that might belong to an attacker
90 13:16 <rockzombie2> the PR preserves the list of nodes you were connected to before? Making it less likely for an EA
91 13:16 <embark> jnewbery yes not the most important facet to focus on, I say we continue
92 13:16 <amiti> yup! it introduces the idea of "anchor" connections
93 13:17 <amiti> I'm going to jump to question #4 and then loop back to #3
94 13:17 <amiti> can someone explain what the conditions are for adding anchors ?
95 13:17 <pinheadmz> outbound connections that are block-relay only ?
96 13:18 <pinheadmz> and also ~fFeeler ... whcih idk what that is
97 13:18 <pinheadmz> !fFeeler
98 13:18 <amiti> pinheadmz: yup, we treat the last successful outbound block-relay-only connections as our anchors when we restart
99 13:19 <ecurrencyhodler> What happens when an attackers node is saved? Doesn't that keep them stuck in that connection?
100 13:19 <rockzombie2> It doesn't sound like it. If the anchor is the *last* successful outbound block-relay-only connection
101 13:19 <amiti> when we get a message about new addresses, feelers are a way of testing out those connections and then moving them to a "tried" table if they were successful. this prevents us from filling up our address tables with bogus info
102 13:20 <ecurrencyhodler> very cool
103 13:20 <embark> so feeler = assess candidate peer?
104 13:20 <amiti> ecurrencyhodler: great question! this is a point that has been discussed in the PR conversation. lets defer for a few minutes and come back to it
105 13:20 <pinheadmz> amiti: so those feeler connections arent sustained? jsut a quick test and hangup?
106 13:20 <ecurrencyhodler> okay thanks
107 13:21 <amiti> embark, pinheadmz: yes thats my understanding
108 13:21 <lightlike> mine too: just connect to see if it's there.
109 13:21 <amiti> ok so can anyone explain why the anchors are blocks-only peers?
110 13:22 <amiti> and similarly, what would be the issue of using normal (txn + block relay) peers as anchors?
111 13:23 <embark> Maybe: If a node only uses outbound connections it increasing the costs an eclipse attacker would need to marshal to shunt the node to their nodes
112 13:23 <nehan_> anchors are a bit dangerous if you get stuck with evil anchors. and the real issue with being eclipsed is not seeing new blocks, transactions are less concerning. but i don't see why it couldn't be txn+block connections as well...
113 13:23 <nehan_> as long as the number is limited
114 13:24 <pinheadmz> the blocks-only peers dont relay addr messages?
115 13:24 <amiti> ok, so if we step back and look at the network graph as a whole, adding anchor connections makes the network graph more static
116 13:25 <amiti> can anyone think of why that would not be desirable?
117 13:25 <_andrewtoth_> it makes topology inference easier
118 13:25 <ajonas> It helps maintain honest/trustworthy connections
119 13:25 <pinheadmz> privacy, trace the origin of a TX
120 13:26 <rockzombie2> It sounds like it could centralize the network towards nodes that have been around longer
122 13:26 <amiti> _andrewtoth_: and why is topology inference undesirable?
123 13:26 <ajonas> the opposite
124 13:26 <amiti> pinheadmz: exactly
125 13:26 <embark> generally dynamic systems that don't have noise/randomness can converge to states that are suboptimal
126 13:26 <nehan_> oh is it an attempt to reduce the privacy implications? blocks-only connections leak less information, so it's ok to keep them around longer?
127 13:26 <amiti> ajonas: well, you highlight the dissonant objectives
129 13:26 <ajonas> that's what I'm here for
130 13:26 <luke-jr> embark: but in this case, it has a history of working, even if suboptimal
131 13:27 <luke-jr> and the anchors aren't ALL your peers
132 13:27 <amiti> so basically, for txn privacy you want the topology to be obscured and the network to be dynamic
133 13:27 <amiti> but if your connections are frequently changing, its easier to be eclipsed
134 13:27 <amiti> so this is a fundamental point about the implementation of this PR
136 13:28 <amiti> by using blocks-relay-only connections, you are avoiding the privacy leak of anchoring your transaction-relay connections
137 13:28 <amiti> but getting the benefits of added protection from being eclipsed
138 13:28 <ecurrencyhodler> wow
139 13:29 <ecurrencyhodler> amiti: makes a lot of sense.
140 13:29 <embark> e.g. the choice is more about node's txn relay privacy than mitigating an EA?
141 13:29 <_andrewtoth_> it's about finding a good balance between the two competing objectives I believe
142 13:29 <amiti> ok, lets jump back to the topic that ecurrencyhodler brought up earlier. what happens if you chose a malicious node as an anchor?
143 13:29 <luke-jr> in theory, by having both anchor peers and dynamic peers, we get the best of both
144 13:30 <luke-jr> amiti: that's the problem
145 13:30 <embark> given EA mitigation, how do we mitigate second order detriments?
146 13:30 <amiti> luke-jr pointed out this risk in the PR
147 13:30 <amiti> would you like to explain the concern?
149 13:31 <luke-jr> if a peer has a way to crash your node, right now, you can have a script that just restarts it automatically
150 13:31 <pinheadmz> jnewbery: thanks youre fast! i was trying to find this in #15759
151 13:31 <luke-jr> chances are you won't reconnect to the malicious peer
152 13:31 <luke-jr> but if we have an anchor, the peer can keep crashing you indefinitely
153 13:31 <lightlike> you will stay connected to evil anchors forever (unless they disconnect), and they know it because all blocks-only connections will be anchors.
154 13:31 <luke-jr> possibly causing you to not continue syncing and retain a stale state, for one example
155 13:31 <ecurrencyhodler> luke-jr: How can they crash your node?
156 13:32 <luke-jr> ecurrencyhodler: that would require a different vulnerability too
157 13:32 <ecurrencyhodler> Ah okay.
158 13:32 <amiti> so did anyone catch what the proposed fix is?
159 13:32 <luke-jr> not an uncommon type
160 13:32 <pinheadmz> I thought part of this PR was to record a "dirty" shutdown so if a node crashed it would NOT use the same anchors
161 13:32 <ecurrencyhodler> I remember reading about parity nodes crashing because they were served invalid blocks. Is that an example?
162 13:32 <luke-jr> amiti: last I saw, proposed fix was to drop anchors on crash
164 13:33 <luke-jr> ecurrencyhodler: probably
165 13:33 <_andrewtoth_> that proposed fix is not yet implemented afaict
166 13:33 <amiti> hebasto: what are your current thoughts about the PR?
167 13:33 <amiti> _andrewtoth_: correct
168 13:33 <hebasto> amiti: If your node is remote crashable, you want to fix it pretty quickly anyway...
169 13:34 <ecurrencyhodler> So the assumption is that if your node crashes, one reason is because it was crashed remotely on purpose. So now your node will look for new anchor outputs.
170 13:34 <ecurrencyhodler> anchors*.
171 13:34 <nehan_> which means it becomes susceptible to restart-based eclipse attacks again.
172 13:35 <amiti> ecurrencyhodler: yes, thats the proposed fix
173 13:35 <nehan_> at least you required the eclipse attacker to also figure out how to crash the node uncleanly
174 13:35 <pinheadmz> nehan_: yeah remote execution of `bitcoin-cli stop` would be bad
176 13:36 <amiti> so yes, if we wipe anchors on unclean restarts, then we are vulnerable to some of those attacks but protected against others
177 13:36 <hebasto> yup ^^
178 13:36 <nehan_> amiti: thanks!
179 13:37 <nehan_> hebasto: power failures are clean shut downs?
180 13:37 <hebasto> nehan_: no!
181 13:37 <amiti> but in the existing implementation (use anchors for unclean restarts as well), we would not be able to start our node in the worst case scenario
182 13:38 <nothingmuch> currently it seems that DumpAnchors is called eagerly. an alternative would be to only save on clean shutdown, but that is problematic if the user never restarts.
183 13:38 <pbleam> power failures are unclean but hopefully not as repeatable as remote shutdowns?
184 13:38 <nothingmuch> i'm curious what peoples' thoughts on the right balance might be
185 13:38 <rockzombie2> yeah, why does the current PR implementation work well against power failures?
186 13:38 <luke-jr> nothingmuch: losing anchors isn't particularly problematic
187 13:38 <nothingmuch> and how easy it is for evil anchors to game
188 13:38 <_andrewtoth_> nothingmuch I believe the fix is to not use what was written when restarting uncleanly
189 13:38 <nehan_> hebasto: then I think your comment is incorrect... it looks (to me) like it claims it helps with an eclipse attacker who can cause a power shutdown to do a restart. it does not, because that is an unclean restart, so the anchors would be wiped.
190 13:38 <amiti> I've been thinking about this.. and I wonder if its desirable to be able to start your node if you're the victim of an eclipse attack? I think I'd rather not be able to start up because that would force me to figure out what's wrong
191 13:39 <luke-jr> nehan_: anchors resist the eclipse
192 13:39 <amiti> curious what other reviewers think about that, as well as hebasto & luke-jr
193 13:39 <nehan_> luke-jr: yes. and with a power shutdown, the anchor file would be wiped, so it would not help resist an eclipse attack
194 13:39 <hebasto> nehan_: current implementation, without a suggested fix, will do
195 13:39 <lightlike> nehan_: i believe hebasto was suggesting not to implement this feature of wiping during unclean restarts.
196 13:39 <luke-jr> amiti: being unable to start is a different attack than eclipse
197 13:39 <nehan_> lightlike: ah ok, thanks
198 13:40 <nehan_> lightlike: _not_ wiping works well against an EA adversary. yes.
199 13:40 <luke-jr> also, the worst-case scenario isn't inability to restart: it's being prevented from syncing because your node is killed too quickly, but not until RPC calls are made
200 13:41 <amiti> luke-jr: right. the two options of implementation are 1. use anchors on every restart & 2. use anchors only on clean restarts. #1 has the issue you pointed out where the node is unable to function. #2 has less protection under an eclipse attack. right?
201 13:41 <luke-jr> amiti: right
202 13:41 <amiti> ok good point. I should say unable to sync instead of unable to start
203 13:41 <luke-jr> under certain eclipse attacks
204 13:41 <emzy> Maybe have a counter. And wipe the anchors after lets say 5 restarts/crashes.
205 13:42 <hebasto> luke-jr: in the worst case we find out remote crash vulnerability and will fix it, I hope
206 13:42 <luke-jr> hebasto: sure, we have in the past
207 13:42 <amiti> so, the question I'm floating is ... which is more desirable? to me, #1 seems to make more sense because I wouldn't want to be able to operate if I'm eclipsed anyways
208 13:42 <luke-jr> emzy: if the EA can kill power, they can do it 5 times
209 13:42 <amiti> does that make sense?
210 13:43 <luke-jr> amiti: no
211 13:43 <luke-jr> EAs are theoretical; node-crashing vulns are common in practice
212 13:43 <luke-jr> (power-based EAs are theoretical *and* unlikely)
213 13:43 <emzy> luke-jr: but after the 5. time I don't use the anchor anymore. So it limits the attack
214 13:43 <amiti> ok gotcha
215 13:44 <nehan_> emzy: no, it enables the restart-based eclipse attack
216 13:44 <luke-jr> emzy: the power-cycling attack is EA; it BENEFITS from you dropping the anchor
217 13:44 <nothingmuch> amiti: i think there are more options (what i meant to imply by my question). for example the anchor file could be a write ahead log with commitments on successful restarts so that it's not all or nothing
218 13:44 <luke-jr> emzy: if they just want to DoS, they will simpoly leave the power off :P
219 13:44 <amiti> hebasto: what are you thinking for the next steps for this PR?
220 13:45 <emzy> nehan_: luke-jr: Ok. I understand the problem.
221 13:45 <amiti> nothingmuch: thats true, there could be more complex anchor logic
222 13:45 <nothingmuch> hence my question above - i'm not sure sensible lead time from an outbound block only seeming non malicious, but my intuition is that it should not depend on the user's restart habits
223 13:45 <nothingmuch> amiti: fwiw not an actual suggestion, just an extreme hypothetical
225 13:46 <hebasto> applying suggested fix will make pr scope significantly smaller, but it seems still useful
226 13:46 <luke-jr> almost all the "DoS" category are node crashers
227 13:46 <luke-jr> to get a sense of how common this is
228 13:46 <amiti> hebasto: I agree.
229 13:47 <amiti> ok, are people interested in continuing with the questions?
230 13:47 <amiti> lets take a look at the implementation (question #3)
231 13:47 <embark> even if the attack isn't common or known, we know it's possibly so we don't want to enable an attack vector with design choices that deny its possibility
232 13:48 <amiti> in the current implementation, whats the logic for how peers are persisted and removed?
233 13:50 <jnewbery> they're persisted in the DumpAnchors() function
234 13:50 <amiti> nothingmuch: you alluded to it before :) whats the method that adds peers to the anchors.dat?
235 13:51 <nothingmuch> i was rereading to verify my understanding
236 13:51 <amiti> jnewbery: yup!
237 13:51 <nothingmuch> but i think DumpAnchors is done after a successful handshake with a blocks only outgoing peer
238 13:51 <amiti> nothingmuch: yup! thats my understanding too
239 13:51 <jnewbery> (which is called in the ProcessMessage() function in net_processing
240 13:51 <nothingmuch> and that in turn saves all of the outgoing blocks only peers based on the current addrman state
242 13:52 * luke-jr , before running out of time, wonders if anchors should be reduced/skipped entirely if the user has manually configured addnode peers
243 13:53 <amiti> luke-jr: interesting point, can you explain that further? what are the tradeoffs you see?
244 13:53 <jnewbery> luke-jr: can you quickly summarise what addnode peers are?
245 13:53 <luke-jr> addnode peers are typically permanent connections to other known nodes
246 13:53 <nothingmuch> those count against outbound connection limit, right?
247 13:53 <luke-jr> seems to be a manual anchor in practice IMO
248 13:53 <luke-jr> I don't think they do, but I forget
249 13:54 <nothingmuch> hmm. if they don't what is the downside of having both anchors and manually added connections?
250 13:54 <luke-jr> I'm not sure if there is a downside, just thinking it might make sense to disable automatic anchors if we have user-provided anchors
251 13:54 <hebasto> luke-jr: will the only -addnode sufficient for not using anchors?
252 13:54 <luke-jr> hebasto: ?
253 13:55 <hebasto> maybe require two or more manually added nodes?
254 13:55 <luke-jr> hebasto: hence "reduce" :P
255 13:55 <luke-jr> hebasto: ie, if there's 1 addnode, make <defalt>-1 auto anchors
256 13:55 <luke-jr> s/make/load/
257 13:55 <amiti> time check: we have 5 more minutes remaining. does anyone have any questions?
258 13:56 <hebasto> luke-jr: great!
259 13:56 <pinheadmz> I feel queasy about the anchor peers - im not convinced that an eclipse-attacker couldnt use it against a victim
260 13:56 <luke-jr> it might or might not be worth the extra logic to do this - perhaps better to save for another PR unless someone thinks of a reason it's critical
261 13:56 <pinheadmz> but its just a feeling, doesnt feel right
263 13:56 <luke-jr> (but maybe it's simpler than I assume)
265 13:57 <nehan_> what is that code doing?
266 13:57 <instagibbs> was there a special reason that anchor connections were blocksonly ones?
267 13:57 <luke-jr> instagibbs: privacy
268 13:58 <luke-jr> scroll up
269 13:58 <instagibbs> there's lots of scroll
270 13:58 <instagibbs> lol
271 13:58 <amiti> pinheadmz: "use it against"? I think theres ways an eclipse attacker can take over the anchors, but it requires more work. do you think there's further exploits they could do with the anchors?
272 13:58 <instagibbs> luke-jr, that seems to be a point against "reduce anchors with addnode"
273 13:58 <pinheadmz> amiti: no just that, taking over the anchors
274 13:58 <nothingmuch> instagibbs: ~18:22
275 13:58 <luke-jr> instagibbs: no, you have the downside there with addnode whether or not you have auto-anchors
276 13:58 <instagibbs> GMT? (doing head math)
277 13:59 <nothingmuch> instagibbs: yep, heh, i was thinking of doing *:22 just to avoid that confusion
278 13:59 <amiti> pinheadmz: ah yes, I think thats possible, esp with this first implementation that is intentionally scoped to be minimal
279 13:59 <nothingmuch> instagibbs: 25 mins ago ;-)
280 13:59 <instagibbs> luke-jr, I don't understand what you're saying.
281 14:00 <hebasto> nehan_: that code about connection priority
282 14:00 <amiti> nehan_: that code is checking if there are valid anchors and if so trying to connect to them before continuing with the other connection logic
283 14:00 <amiti> ok! looks like thats time!
284 14:00 <amiti> thank you all for coming and participating
285 14:00 <pinheadmz> great job amiti
286 14:00 <amiti> and thank you hebasto for this PR :)
287 14:00 <jnewbery> great meeting amiti. That was a lot of fun. Thanks!
288 14:00 <jnewbery> #endmeeting
289 14:01 <emzy> Thank you amiti and all!
290 14:01 <lightlike> thanks!
291 14:01 <_andrewtoth_> thanks all!
292 14:01 <pbleam> thanks!
293 14:01 <instagibbs> luke-jr, oh are you saying you've already done the damage(privacy) while also gained the connection robustness?
295 14:02 <instagibbs> ah, ok
296 14:02 <nehan_> thanks!
297 14:02 <instagibbs> hmm, maybe :) I'll think on it
298 14:02 <luke-jr> anchors don't *require* privacy; it's just something we don't want to lose with them
299 14:02 <luke-jr> addnode loses privacy, but it also provides what anchors accomplish
300 14:03 <embark> thanks amiti and all good meeting
301 14:03 <instagibbs> luke-jr, if you weren't punked into connecting to someone evil manually(manual vs auto I know you discussed that)
302 14:03 <lightlike> tough PR, lots of decisions to make with pros and cons that seem really hard to weight against each other.
303 14:03 <instagibbs> good stuff
304 14:03 <luke-jr> instagibbs: we can't stop users from shooting themsleves in the foot all the time
305 14:04 <instagibbs> worst-case for now it's 2 additional anchor connections which I don't think in practice will matte
306 14:04 <instagibbs> obviously more blocks only connections would change this
307 14:11 <nothingmuch> fwiw it appears addnode is capped at 8 independently of other outbound conns