Try to preserve outbound block-relay-only connections during restart (p2p)

Host: amitiuttarwar  -  PR author: hebasto

The PR branch HEAD was 78b2f9503 at the time of this review club meeting.


An eclipse attack is when an attacker is able to isolate a node from all honest peers.

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 startup.


  • 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.

  • A 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.

  • This PR, 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 attack.

  • 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:

    1. A victim of an eclipse attack has no way of escaping if all of his connections are anchored to the adversary.
    2. 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.
    3. 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.

PR 17428

  • The 2 outbound block-relay-only connections are written to the anchors.dat 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 unlikely before.

  • 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 remote crash.

    The proposed fix is to forget the anchor peers on an unclean exit.

    In reaction to these findings, the PR was closed. 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.


  1. Did you review the PRs? Concept ACK, approach ACK, tested ACK, or NACK? (Don’t forget to put your PR review on GitHub.)

  2. 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?
  3. 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?
  4. 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 as anchors?
    • What are limitations of how this implementation chooses anchors?
    • Why limit to only 2 anchors?
  5. 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 currently?

  6. 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?

Meeting Log

  113:00 <jnewbery> #startmeeting
  213:00 <amiti> jnewbery you beat me to it!
  313:00 <rockzombie2> hi
  413:00 <pinheadmz> hi!
  513:00 <hebasto> hi
  613:00 <amiti> hi everyone! welcome to this weeks PR review club
  713:00 <pbleam> hi
  813:00 <nothingmuch> ohai
  913:00 <_andrewtoth_> hi
 1013:00 <lightlike> hi
 1113:00 <nehan_> hi
 1213:00 <audichya> hi
 1313:00 <ecurrencyhodler> hello
 1413:00 <jnewbery> hi
 1513:01 <amiti> I had a lot of fun digging into this PR & problem space and think we have lots to talk about :)
 1613:01 <luke-jr> hi
 1713:01 <emzy> hi
 1813:01 <rockzombie2> I have a question: Can someone give a quick explanation of what an eclipse attack is?
 1913:01 <embark> hi
 2013:01 <amiti> who got the chance to review this weeks PR?
 2113:01 <ajonas> hi
 2213:01 <amiti> can we do a quick round of y/n?
 2313:02 <embark> rockzombie2 Did you see the notes for the review? attack is described there
 2413:02 <pinheadmz> y
 2513:02 <hebasto> rockzombie2: every node you are connected are evel
 2613:02 <hebasto> *evil*
 2713:03 <emzy> n
 2813:03 <lightlike> yes
 2913:03 <nehan_> y
 3013:03 <_andrewtoth_> 0.5y
 3113:03 <amiti> haha rockzombie2 that was exactly how I was planning to start the conversation =P
 3213:03 <rockzombie2> Oh my bad. I was looking at the notes linked in the previous PR club meeting
 3313:03 <rockzombie2> I didn't really get to look at the PR tbh
 3413:03 <nothingmuch> 0.3y
 3513:04 <amiti> continuing on the idea of eclipse attacks, can someone describe how an adversary would eclipse a node?
 3613:04 <luke-jr> I'd like an example that doesn't require MITM, since MITM is unmitigatable..
 3713:04 <pinheadmz> tldr - fill up their addr list with addrs the attacker owns, then forcing them to restart somehow
 3813:04 <pinheadmz> the victim will create outbounds to only the attackers nodes
 3913: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
 4013:05 <_andrewtoth_> but how do they do the first part - "fill up their addr list with addrs the attacker owns"?
 4113:05 <rockzombie2> ^
 4213:05 <luke-jr> that seems like the real flaw :P
 4313:06 <pinheadmz> bitcoin nodes send each other addr packets all the time - actually does anyone know if they are allowed ot be unsolicited?
 4413:06 <nehan_> Ethan explains here eclipse attacks don't require restarts?
 4513:06 <pinheadmz> or are they only supposed ot be served in rsponse to getaddr or something
 4613:06 <jnewbery> pinheadmz: yes, I believe they can be unsolicited
 4713: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
 4813:07 <amiti> nehan_: great point. since there is peer rotation logic, its possible for adversaries to take over an addrman without the victim restarting
 4913: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
 5013:08 <jnewbery> pinheadmz: I believe is where we'll send unsolicited ADDRs to our peers
 5113: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?
 5213:09 <amiti> ok, so if a node is eclipsed, what sort of attacks can an adversary execute on the victim?
 5313:09 <rockzombie2> they could convince the node to empty their wallet?
 5413:09 <amiti> can anyone answer rockzombie2's question and explain why eclipse attacks don't require 51% attacks?
 5513:09 <pinheadmz> ha
 5613:10 <ecurrencyhodler> amiti: Serve malicious blocks with double spends in them.
 5713:10 <pinheadmz> well it still takes a lot of hashpower to find a block
 5813:10 <embark> rockzombie2 and EA is at the P2P level not at consensus or miner level
 5913:11 <pinheadmz> but with the rest of the network blocked, the attacker can take as long as they want
 6013:11 <embark> s/and/an
 6113:11 <pbleam> won
 6213:11 <amiti> embark: what is EA?
 6313:11 <lightlike> if the eclipsed node is a miner, it won't use their computing power for anything useful.
 6413:11 <pbleam> won't that look suspicious if the attacker takes especially long to serve a new block?
 6513: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.
 6613:11 <embark> amiti: my attempt at being lazy :P Eclipse Attack (EA)
 6713: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
 6813: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"
 6913:12 <ecurrencyhodler> _andrewth_: thanks for the clarification.
 7013:12 <pinheadmz> but if all your outbound connections are to attackers, this wont help
 7113:12 <embark> lightlike good point, an Eclipse Attack'ed peer can eventually be fed low PoW blocks and will accept them as valid
 7213:12 <embark> too
 7313:13 <jnewbery> embark: no. The blocks need to be the right difficulty
 7413:13 <nothingmuch> embark: can you clarify eventually? do you mean including difficulty adjustment?
 7513:13 <ecurrencyhodler> pbleam: it depends on how long is a long time. Sometimes it's taken an hour to find a block.
 7613:13 <lightlike> embark: I just meant less competition for the people actually mining on the main chain
 7713:13 <embark> jnewbery: I eclipse you for 4 weeks (unlikely to suceed but a possibility) you will start to accept difficulty discounted blocks, no?
 7813: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:
 7913:14 <embark> actually I probably need to retract that
 8013:14 <nothingmuch> embark: no, difficulty adjustment is triggered by block height, not nominal time
 8113: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
 8213:14 <embark> yes I retract
 8313:15 <embark> I was....uhh.. testing people... ha
 8413:15 <amiti> ok moving on, how does this PR mitigate an eclipse attack?
 8513:15 <pinheadmz> although hm that wouldnt force a reorg though huh
 8613:15 <ajonas> I think the LN attack is pretty worrisome
 8713: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
 8813:16 <amiti> ajonas: I agree!
 8913: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
 9013:16 <rockzombie2> the PR preserves the list of nodes you were connected to before? Making it less likely for an EA
 9113:16 <embark> jnewbery yes not the most important facet to focus on, I say we continue
 9213:16 <amiti> yup! it introduces the idea of "anchor" connections
 9313:17 <amiti> I'm going to jump to question #4 and then loop back to #3
 9413:17 <amiti> can someone explain what the conditions are for adding anchors ?
 9513:17 <pinheadmz> outbound connections that are block-relay only ?
 9613:18 <pinheadmz> and also ~fFeeler ... whcih idk what that is
 9713:18 <pinheadmz> !fFeeler
 9813:18 <amiti> pinheadmz: yup, we treat the last successful outbound block-relay-only connections as our anchors when we restart
 9913:19 <ecurrencyhodler> What happens when an attackers node is saved? Doesn't that keep them stuck in that connection?
10013:19 <rockzombie2> It doesn't sound like it. If the anchor is the *last* successful outbound block-relay-only connection
10113: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
10213:20 <ecurrencyhodler> very cool
10313:20 <embark> so feeler = assess candidate peer?
10413: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
10513:20 <pinheadmz> amiti: so those feeler connections arent sustained? jsut a quick test and hangup?
10613:20 <ecurrencyhodler> okay thanks
10713:21 <amiti> embark, pinheadmz: yes thats my understanding
10813:21 <lightlike> mine too: just connect to see if it's there.
10913:21 <amiti> ok so can anyone explain why the anchors are blocks-only peers?
11013:22 <amiti> and similarly, what would be the issue of using normal (txn + block relay) peers as anchors?
11113: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
11213: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...
11313:23 <nehan_> as long as the number is limited
11413:24 <pinheadmz> the blocks-only peers dont relay addr messages?
11513: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
11613:25 <amiti> can anyone think of why that would not be desirable?
11713:25 <_andrewtoth_> it makes topology inference easier
11813:25 <ajonas> It helps maintain honest/trustworthy connections
11913:25 <pinheadmz> privacy, trace the origin of a TX
12013:26 <rockzombie2> It sounds like it could centralize the network towards nodes that have been around longer
12113:26 <ajonas> oh NOT
12213:26 <amiti> _andrewtoth_: and why is topology inference undesirable?
12313:26 <ajonas> the opposite
12413:26 <amiti> pinheadmz: exactly
12513:26 <embark> generally dynamic systems that don't have noise/randomness can converge to states that are suboptimal
12613: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?
12713:26 <amiti> ajonas: well, you highlight the dissonant objectives
12813:26 <embark> Eg "Noise can speed convergence in Markov chains"
12913:26 <ajonas> that's what I'm here for
13013:26 <luke-jr> embark: but in this case, it has a history of working, even if suboptimal
13113:27 <luke-jr> and the anchors aren't ALL your peers
13213:27 <amiti> so basically, for txn privacy you want the topology to be obscured and the network to be dynamic
13313:27 <amiti> but if your connections are frequently changing, its easier to be eclipsed
13413:27 <amiti> so this is a fundamental point about the implementation of this PR
13513:27 <_andrewtoth_> here's a good summary from hebasto
13613:28 <amiti> by using blocks-relay-only connections, you are avoiding the privacy leak of anchoring your transaction-relay connections
13713:28 <amiti> but getting the benefits of added protection from being eclipsed
13813:28 <ecurrencyhodler> wow
13913:29 <ecurrencyhodler> amiti: makes a lot of sense.
14013:29 <embark> e.g. the choice is more about node's txn relay privacy than mitigating an EA?
14113:29 <_andrewtoth_> it's about finding a good balance between the two competing objectives I believe
14213: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?
14313:29 <luke-jr> in theory, by having both anchor peers and dynamic peers, we get the best of both
14413:30 <luke-jr> amiti: that's the problem
14513:30 <embark> given EA mitigation, how do we mitigate second order detriments?
14613:30 <amiti> luke-jr pointed out this risk in the PR
14713:30 <amiti> would you like to explain the concern?
14813:30 <jnewbery> pinheadmz: to answer your previous question about blocks-only peers, no we don't relay addrs:
14913: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
15013:31 <pinheadmz> jnewbery: thanks youre fast! i was trying to find this in #15759
15113:31 <luke-jr> chances are you won't reconnect to the malicious peer
15213:31 <luke-jr> but if we have an anchor, the peer can keep crashing you indefinitely
15313: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.
15413:31 <luke-jr> possibly causing you to not continue syncing and retain a stale state, for one example
15513:31 <ecurrencyhodler> luke-jr: How can they crash your node?
15613:32 <luke-jr> ecurrencyhodler: that would require a different vulnerability too
15713:32 <ecurrencyhodler> Ah okay.
15813:32 <amiti> so did anyone catch what the proposed fix is?
15913:32 <luke-jr> not an uncommon type
16013: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
16113:32 <ecurrencyhodler> I remember reading about parity nodes crashing because they were served invalid blocks. Is that an example?
16213:32 <luke-jr> amiti: last I saw, proposed fix was to drop anchors on crash
16313:33 <amiti> yup.
16413:33 <luke-jr> ecurrencyhodler: probably
16513:33 <_andrewtoth_> that proposed fix is not yet implemented afaict
16613:33 <amiti> hebasto: what are your current thoughts about the PR?
16713:33 <amiti> _andrewtoth_: correct
16813:33 <hebasto> amiti: If your node is remote crashable, you want to fix it pretty quickly anyway...
16913: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.
17013:34 <ecurrencyhodler> anchors*.
17113:34 <nehan_> which means it becomes susceptible to restart-based eclipse attacks again.
17213:35 <amiti> ecurrencyhodler: yes, thats the proposed fix
17313:35 <nehan_> at least you required the eclipse attacker to also figure out how to crash the node uncleanly
17413:35 <pinheadmz> nehan_: yeah remote execution of `bitcoin-cli stop` would be bad
17513:35 <amiti> nehan_: pretty much, but one thing I learned from hebasto's comment here: is the two types of restart-based eclipse attacks
17613:36 <amiti> so yes, if we wipe anchors on unclean restarts, then we are vulnerable to some of those attacks but protected against others
17713:36 <hebasto> yup ^^
17813:36 <nehan_> amiti: thanks!
17913:37 <nehan_> hebasto: power failures are clean shut downs?
18013:37 <hebasto> nehan_: no!
18113: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
18213: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.
18313:38 <pbleam> power failures are unclean but hopefully not as repeatable as remote shutdowns?
18413:38 <nothingmuch> i'm curious what peoples' thoughts on the right balance might be
18513:38 <rockzombie2> yeah, why does the current PR implementation work well against power failures?
18613:38 <luke-jr> nothingmuch: losing anchors isn't particularly problematic
18713:38 <nothingmuch> and how easy it is for evil anchors to game
18813:38 <_andrewtoth_> nothingmuch I believe the fix is to not use what was written when restarting uncleanly
18913: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.
19013: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
19113:39 <luke-jr> nehan_: anchors resist the eclipse
19213:39 <amiti> curious what other reviewers think about that, as well as hebasto & luke-jr
19313: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
19413:39 <hebasto> nehan_: current implementation, without a suggested fix, will do
19513:39 <lightlike> nehan_: i believe hebasto was suggesting not to implement this feature of wiping during unclean restarts.
19613:39 <luke-jr> amiti: being unable to start is a different attack than eclipse
19713:39 <nehan_> lightlike: ah ok, thanks
19813:40 <nehan_> lightlike: _not_ wiping works well against an EA adversary. yes.
19913: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
20013: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?
20113:41 <luke-jr> amiti: right
20213:41 <amiti> ok good point. I should say unable to sync instead of unable to start
20313:41 <luke-jr> under certain eclipse attacks
20413:41 <emzy> Maybe have a counter. And wipe the anchors after lets say 5 restarts/crashes.
20513:42 <hebasto> luke-jr: in the worst case we find out remote crash vulnerability and will fix it, I hope
20613:42 <luke-jr> hebasto: sure, we have in the past
20713: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
20813:42 <luke-jr> emzy: if the EA can kill power, they can do it 5 times
20913:42 <amiti> does that make sense?
21013:43 <luke-jr> amiti: no
21113:43 <luke-jr> EAs are theoretical; node-crashing vulns are common in practice
21213:43 <luke-jr> (power-based EAs are theoretical *and* unlikely)
21313:43 <emzy> luke-jr: but after the 5. time I don't use the anchor anymore. So it limits the attack
21413:43 <amiti> ok gotcha
21513:44 <nehan_> emzy: no, it enables the restart-based eclipse attack
21613:44 <luke-jr> emzy: the power-cycling attack is EA; it BENEFITS from you dropping the anchor
21713: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
21813:44 <luke-jr> emzy: if they just want to DoS, they will simpoly leave the power off :P
21913:44 <amiti> hebasto: what are you thinking for the next steps for this PR?
22013:45 <emzy> nehan_: luke-jr: Ok. I understand the problem.
22113:45 <amiti> nothingmuch: thats true, there could be more complex anchor logic
22213: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
22313:45 <nothingmuch> amiti: fwiw not an actual suggestion, just an extreme hypothetical
22413:45 <luke-jr>
22513:46 <hebasto> applying suggested fix will make pr scope significantly smaller, but it seems still useful
22613:46 <luke-jr> almost all the "DoS" category are node crashers
22713:46 <luke-jr> to get a sense of how common this is
22813:46 <amiti> hebasto: I agree.
22913:47 <amiti> ok, are people interested in continuing with the questions?
23013:47 <amiti> lets take a look at the implementation (question #3)
23113: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
23213:48 <amiti> in the current implementation, whats the logic for how peers are persisted and removed?
23313:50 <jnewbery> they're persisted in the DumpAnchors() function
23413:50 <amiti> nothingmuch: you alluded to it before :) whats the method that adds peers to the anchors.dat?
23513:51 <nothingmuch> i was rereading to verify my understanding
23613:51 <amiti> jnewbery: yup!
23713:51 <nothingmuch> but i think DumpAnchors is done after a successful handshake with a blocks only outgoing peer
23813:51 <amiti> nothingmuch: yup! thats my understanding too
23913:51 <jnewbery> (which is called in the ProcessMessage() function in net_processing
24013:51 <nothingmuch> and that in turn saves all of the outgoing blocks only peers based on the current addrman state
24113:51 <amiti> for anyone wondering, here's where that happens:
24213:52 * luke-jr , before running out of time, wonders if anchors should be reduced/skipped entirely if the user has manually configured addnode peers
24313:53 <amiti> luke-jr: interesting point, can you explain that further? what are the tradeoffs you see?
24413:53 <jnewbery> luke-jr: can you quickly summarise what addnode peers are?
24513:53 <luke-jr> addnode peers are typically permanent connections to other known nodes
24613:53 <nothingmuch> those count against outbound connection limit, right?
24713:53 <luke-jr> seems to be a manual anchor in practice IMO
24813:53 <luke-jr> I don't think they do, but I forget
24913:54 <nothingmuch> hmm. if they don't what is the downside of having both anchors and manually added connections?
25013: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
25113:54 <hebasto> luke-jr: will the only -addnode sufficient for not using anchors?
25213:54 <luke-jr> hebasto: ?
25313:55 <hebasto> maybe require two or more manually added nodes?
25413:55 <luke-jr> hebasto: hence "reduce" :P
25513:55 <luke-jr> hebasto: ie, if there's 1 addnode, make <defalt>-1 auto anchors
25613:55 <luke-jr> s/make/load/
25713:55 <amiti> time check: we have 5 more minutes remaining. does anyone have any questions?
25813:56 <hebasto> luke-jr: great!
25913:56 <pinheadmz> I feel queasy about the anchor peers - im not convinced that an eclipse-attacker couldnt use it against a victim
26013: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
26113:56 <pinheadmz> but its just a feeling, doesnt feel right
26213:56 <nehan_> I'm confused about the conversation her:
26313:56 <luke-jr> (but maybe it's simpler than I assume)
26413:57 <nehan_> *here
26513:57 <nehan_> what is that code doing?
26613:57 <instagibbs> was there a special reason that anchor connections were blocksonly ones?
26713:57 <luke-jr> instagibbs: privacy
26813:58 <luke-jr> scroll up
26913:58 <instagibbs> there's lots of scroll
27013:58 <instagibbs> lol
27113: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?
27213:58 <instagibbs> luke-jr, that seems to be a point against "reduce anchors with addnode"
27313:58 <pinheadmz> amiti: no just that, taking over the anchors
27413:58 <nothingmuch> instagibbs: ~18:22
27513:58 <luke-jr> instagibbs: no, you have the downside there with addnode whether or not you have auto-anchors
27613:58 <instagibbs> GMT? (doing head math)
27713:59 <nothingmuch> instagibbs: yep, heh, i was thinking of doing *:22 just to avoid that confusion
27813:59 <amiti> pinheadmz: ah yes, I think thats possible, esp with this first implementation that is intentionally scoped to be minimal
27913:59 <nothingmuch> instagibbs: 25 mins ago ;-)
28013:59 <instagibbs> luke-jr, I don't understand what you're saying.
28114:00 <hebasto> nehan_: that code about connection priority
28214: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
28314:00 <amiti> ok! looks like thats time!
28414:00 <amiti> thank you all for coming and participating
28514:00 <pinheadmz> great job amiti
28614:00 <amiti> and thank you hebasto for this PR :)
28714:00 <jnewbery> great meeting amiti. That was a lot of fun. Thanks!
28814:00 <jnewbery> #endmeeting
28914:01 <emzy> Thank you amiti and all!
29014:01 <lightlike> thanks!
29114:01 <_andrewtoth_> thanks all!
29214:01 <pbleam> thanks!
29314:01 <instagibbs> luke-jr, oh are you saying you've already done the damage(privacy) while also gained the connection robustness?
29414:02 <luke-jr> yes
29514:02 <instagibbs> ah, ok
29614:02 <nehan_> thanks!
29714:02 <instagibbs> hmm, maybe :) I'll think on it
29814:02 <luke-jr> anchors don't *require* privacy; it's just something we don't want to lose with them
29914:02 <luke-jr> addnode loses privacy, but it also provides what anchors accomplish
30014:03 <embark> thanks amiti and all good meeting
30114:03 <instagibbs> luke-jr, if you weren't punked into connecting to someone evil manually(manual vs auto I know you discussed that)
30214:03 <lightlike> tough PR, lots of decisions to make with pros and cons that seem really hard to weight against each other.
30314:03 <instagibbs> good stuff
30414:03 <luke-jr> instagibbs: we can't stop users from shooting themsleves in the foot all the time
30514:04 <instagibbs> worst-case for now it's 2 additional anchor connections which I don't think in practice will matte
30614:04 <instagibbs> obviously more blocks only connections would change this
30714:11 <nothingmuch> fwiw it appears addnode is capped at 8 independently of other outbound conns