--- Day changed Wed Feb 26 2020
00:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]     
00:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
03:05 -!- Forest73Gutmann [~Forest73G@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews     
03:10 -!- Forest73Gutmann [~Forest73G@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 260 seconds]     
04:30 -!- Zenton [~user@unaffiliated/vicenteh] has left #bitcoin-core-pr-reviews ["ERC (IRC client for Emacs 26.1)"]     
04:31 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
04:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
04:36 -!- audichya [6753d7c1@103.83.215.193] has joined #bitcoin-core-pr-reviews     
04:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
05:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
05:33 < pinheadmz> huh this is interesting: I pushed to a branch in my own repo, and the bitcoin-core-ci ran tests on it! I thought that was only run when a PR is opened?
05:34 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
05:34 -!- audichya [6753d7c1@103.83.215.193] has quit [Ping timeout: 260 seconds]     
05:38 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
07:02 < jnewbery> pinheadmz: you mean on your own travis account? I think you can change the settings to build whenever you push a branch
07:03 < pinheadmz> jnewbery: https://github.com/pinheadmz/bitcoin/runs/469761833
07:03 < pinheadmz> It's not a PR to bitcoin/bitcoin, just my own branch
07:04 < pinheadmz> hm I guess by cloning bitcoin I also cloned the github "action" - this is new to me
07:08 -!- molly [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
07:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
07:09 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds]     
07:44 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
07:44 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
08:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
08:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
08:46 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]     
08:47 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:01 -!- MasterdonX [~masterdon@165.231.253.164] has quit [Ping timeout: 272 seconds]     
09:01 -!- masterdonx2 [~masterdon@178-175-148-4.static.as43289.net] has joined #bitcoin-core-pr-reviews     
09:28 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews     
09:35 -!- embark [~embark@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:38 -!- lightlike [~lightlike@p200300C7EF0EC300D1F5536EEE70558F.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:39 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection]     
09:47 -!- audichya [6753d7c1@103.83.215.193] has joined #bitcoin-core-pr-reviews     
09:51 < embark> Review Club page for today: https://bitcoincore.reviews/17428.html
09:51 < jnewbery> we'll get started in 10 minutes
09:56 -!- ecurrencyhodler [68afd3af@cpe-104-175-211-175.socal.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:57 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews     
09:58 -!- pbleam [268ebb82@38.142.187.130] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery> #startmeeting
10:00 < amiti> jnewbery you beat me to it!
10:00 < rockzombie2> hi     
10:00 < pinheadmz> hi!     
10:00 < hebasto> hi     
10:00 < amiti> hi everyone! welcome to this weeks PR review club
10:00 < pbleam> hi     
10:00 < nothingmuch> ohai
10:00 < _andrewtoth_> hi     
10:00 < lightlike> hi     
10:00 < nehan_> hi     
10:00 < audichya> hi     
10:00 < ecurrencyhodler> hello
10:00 < jnewbery> hi     
10:01 < amiti> I had a lot of fun digging into this PR & problem space and think we have lots to talk about :)
10:01 < luke-jr> hi     
10:01 < emzy> hi     
10:01 < rockzombie2> I have a question: Can someone give a quick explanation of what an eclipse attack is?
10:01 < embark> hi     
10:01 -!- pglazman [~pglazman@205.209.24.227] has joined #bitcoin-core-pr-reviews     
10:01 < amiti> who got the chance to review this weeks PR?
10:01 < ajonas> hi     
10:01 < amiti> can we do a quick round of y/n?
10:02 < embark> rockzombie2 Did you see the notes for the review? https://bitcoincore.reviews/17428.html attack is described there
10:02 < pinheadmz> y     
10:02 < hebasto> rockzombie2: every node you are connected are evel
10:02 < hebasto> *evil*
10:03 < emzy> n     
10:03 < lightlike> yes     
10:03 < nehan_> y     
10:03 < _andrewtoth_> 0.5y
10:03 < amiti> haha rockzombie2 that was exactly how I was planning to start the conversation =P
10:03 < rockzombie2> Oh my bad. I was looking at the notes linked in the previous PR club meeting
10:03 < rockzombie2> I didn't really get to look at the PR tbh
10:03 < nothingmuch> 0.3y
10:04 < amiti> continuing on the idea of eclipse attacks, can someone describe how an adversary would eclipse a node?
10:04 < luke-jr> I'd like an example that doesn't require MITM, since MITM is unmitigatable..
10:04 < pinheadmz> tldr - fill up their addr list with addrs the attacker owns, then forcing them to restart somehow
10:04 < pinheadmz> the victim will create outbounds to only the attackers nodes
10: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
10:05 < _andrewtoth_> but how do they do the first part - "fill up their addr list with addrs the attacker owns"?
10:05 < rockzombie2> ^     
10:05 < luke-jr> that seems like the real flaw :P
10:06 < pinheadmz> bitcoin nodes send each other addr packets all the time - actually does anyone know if they are allowed ot be unsolicited?
10:06 < nehan_> Ethan explains here eclipse attacks don't require restarts? https://github.com/bitcoin/bitcoin/issues/17326#issuecomment-548410548
10:06 < pinheadmz> or are they only supposed ot be served in rsponse to getaddr or something
10:06 < jnewbery> pinheadmz: yes, I believe they can be unsolicited
10: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
10:07 < amiti> nehan_: great point. since there is peer rotation logic, its possible for adversaries to take over an addrman without the victim restarting
10: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
10:08 < jnewbery> pinheadmz: I believe https://github.com/bitcoin/bitcoin/blob/2bdc476d4d23256d8396bb9051a511f540d87392/src/net_processing.cpp#L3607 is where we'll send unsolicited ADDRs to our peers
10: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?
10:09 < amiti> ok, so if a node is eclipsed, what sort of attacks can an adversary execute on the victim?
10:09 < rockzombie2> they could convince the node to empty their wallet?
10:09 < amiti> can anyone answer rockzombie2's question and explain why eclipse attacks don't require 51% attacks?
10:09 < pinheadmz> ha     
10:10 < ecurrencyhodler> amiti: Serve malicious blocks with double spends in them.
10:10 < pinheadmz> well it still takes a lot of hashpower to find a block
10:10 < embark> rockzombie2 and EA is at the P2P level not at consensus or miner level
10:11 < pinheadmz> but with the rest of the network blocked, the attacker can take as long as they want
10:11 < embark> s/and/an
10:11 < pbleam> won     
10:11 < amiti> embark: what is EA?
10:11 < lightlike> if the eclipsed node is a miner, it won't use their computing power for anything useful.
10:11 < pbleam> won't that look suspicious if the attacker takes especially long to serve a new block?
10: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.
10:11 < embark> amiti: my attempt at being lazy :P Eclipse Attack (EA)
10: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
10: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"
10:12 < ecurrencyhodler> _andrewth_: thanks for the clarification.
10:12 < pinheadmz> but if all your outbound connections are to attackers, this wont help
10:12 < embark> lightlike good point,  an Eclipse Attack'ed peer can eventually be fed low PoW blocks and will accept them as valid
10:12 < embark> too     
10:13 < jnewbery> embark: no. The blocks need to be the right difficulty
10:13 < ecurrencyhodler> pbleam: it depends on how long is a long time. Sometimes it's taken an hour to find a block.
10:13 < nothingmuch> embark: can you clarify eventually? do you mean including difficulty adjustment?
10:13 < lightlike> embark: I just meant less competition for the people actually mining on the main chain
10:13 < embark> jnewbery: I eclipse you for 4 weeks (unlikely to suceed but a possibility) you will start to accept difficulty discounted blocks, no?
10: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/
10:14 < embark> actually I probably need to retract that
10:14 < nothingmuch> embark: no, difficulty adjustment is triggered by block height, not nominal time
10: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
10:14 < embark> yes I retract
10:15 < embark> I was....uhh.. testing people... ha
10:15 < amiti> ok moving on, how does this PR mitigate an eclipse attack?
10:15 < pinheadmz> although hm that wouldnt force a reorg though huh
10:15 < ajonas> I think the LN attack is pretty worrisome
10: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
10:16 < amiti> ajonas: I agree!
10: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
10:16 < rockzombie2> the PR preserves the list of nodes you were connected to before? Making it less likely for an EA
10:16 < embark> jnewbery yes not the most important facet to focus on, I say we continue
10:16 < amiti> yup! it introduces the idea of "anchor" connections
10:17 < amiti> I'm going to jump to question #4 and then loop back to #3
10:17 < amiti> can someone explain what the conditions are for adding anchors ?
10:17 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: Textual IRC Client: www.textualapp.com]     
10:17 < pinheadmz> outbound connections that are block-relay only ?
10:18 < pinheadmz> and also ~fFeeler ... whcih idk what that is
10:18 < pinheadmz> !fFeeler
10:18 < amiti> pinheadmz: yup, we treat the last successful outbound block-relay-only connections as our anchors when we restart
10:19 < ecurrencyhodler> What happens when an attackers node is saved? Doesn't that keep them stuck in that connection?
10:19 < rockzombie2> It doesn't sound like it. If the anchor is the *last* successful outbound block-relay-only connection
10: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
10:20 < ecurrencyhodler> very cool
10:20 < embark> so feeler = assess candidate peer?
10: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
10:20 < pinheadmz> amiti: so those feeler connections arent sustained? jsut a quick test and hangup?
10:20 < ecurrencyhodler> okay thanks
10:21 < amiti> embark, pinheadmz: yes thats my understanding
10:21 < lightlike> mine too: just connect to see if it's there.
10:21 < amiti> ok so can anyone explain why the anchors are blocks-only peers?
10:22 < amiti> and similarly, what would be the issue of using normal (txn + block relay) peers as anchors?
10: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
10: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...
10:23 < nehan_> as long as the number is limited
10:24 < pinheadmz> the blocks-only peers dont relay addr messages?
10: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
10:25 < amiti> can anyone think of why that would not be desirable?
10:25 < _andrewtoth_> it makes topology inference easier
10:25 < ajonas> It helps maintain honest/trustworthy connections
10:25 < pinheadmz> privacy, trace the origin of a TX
10:26 < rockzombie2> It sounds like it could centralize the network towards nodes that have been around longer
10:26 < ajonas> oh NOT
10:26 < amiti> _andrewtoth_: and why is topology inference undesirable?
10:26 < ajonas> the opposite
10:26 < amiti> pinheadmz: exactly
10:26 < embark> generally dynamic systems that don't have noise/randomness can converge to states that are suboptimal
10: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?
10:26 < amiti> ajonas: well, you highlight the dissonant objectives
10:26 < embark> Eg "Noise can speed convergence in Markov chains" http://sipi.usc.edu/~kosko/Physical-Review-Noisy-Markov-Chain-Oct2011.pdf
10:26 < ajonas> that's what I'm here for
10:26 < luke-jr> embark: but in this case, it has a history of working, even if suboptimal
10:27 < luke-jr> and the anchors aren't ALL your peers
10:27 < amiti> so basically, for txn privacy you want the topology to be obscured and the network to be dynamic
10:27 < amiti> but if your connections are frequently changing, its easier to be eclipsed
10:27 < amiti> so this is a fundamental point about the implementation of this PR
10:27 < _andrewtoth_> here's a good summary from hebasto https://github.com/bitcoin/bitcoin/issues/17326#issuecomment-550337452
10:28 < amiti> by using blocks-relay-only connections, you are avoiding the privacy leak of anchoring your transaction-relay connections
10:28 < amiti> but getting the benefits of added protection from being eclipsed
10:28 < ecurrencyhodler> wow     
10:29 < ecurrencyhodler> amiti: makes a lot of sense.
10:29 < embark> e.g. the choice is more about node's txn relay privacy than mitigating an EA?
10:29 < _andrewtoth_> it's about finding a good balance between the two competing objectives I believe
10: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?
10:29 < luke-jr> in  theory, by having both anchor peers and dynamic peers, we get the best of both
10:30 < luke-jr> amiti: that's the problem
10:30 < embark> given EA mitigation, how do we mitigate second order detriments?
10:30 < amiti> luke-jr pointed out this risk in the PR
10:30 < amiti> would you like to explain the concern?
10:30 < jnewbery> pinheadmz: to answer your previous question about blocks-only peers, no we don't relay addrs: https://github.com/bitcoin/bitcoin/blob/2bdc476d4d23256d8396bb9051a511f540d87392/src/net.cpp#L2681
10: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
10:31 < pinheadmz> jnewbery: thanks youre fast! i was trying to find this in #15759
10:31 < luke-jr> chances are you won't reconnect to the malicious peer
10:31 < luke-jr> but if we have an anchor, the peer can keep crashing you indefinitely
10: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.
10:31 < luke-jr> possibly causing you to not continue syncing and retain a stale state, for one example
10:31 < ecurrencyhodler> luke-jr: How can they crash your node?
10:32 < luke-jr> ecurrencyhodler: that would require a different vulnerability too
10:32 < ecurrencyhodler> Ah okay.
10:32 < amiti> so did anyone catch what the proposed fix is?
10:32 < luke-jr> not an uncommon type
10: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
10:32 < ecurrencyhodler> I remember reading about parity nodes crashing because they were served invalid blocks. Is that an example?
10:32 < luke-jr> amiti: last I saw, proposed fix was to drop anchors on crash
10:33 < amiti> yup.
10:33 < luke-jr> ecurrencyhodler: probably
10:33 -!- pbleam [268ebb82@38.142.187.130] has quit [Remote host closed the connection]     
10:33 < _andrewtoth_> that proposed fix is not yet implemented afaict
10:33 < amiti> hebasto: what are your current thoughts about the PR?
10:33 < amiti> _andrewtoth_: correct
10:33 < hebasto> amiti: If your node is remote crashable, you want to fix it pretty quickly anyway...
10:34 -!- pbleam [268ebb82@38.142.187.130] has joined #bitcoin-core-pr-reviews     
10: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.
10:34 < ecurrencyhodler> anchors*.
10:34 < nehan_> which means it becomes susceptible to restart-based eclipse attacks again.
10:35 < amiti> ecurrencyhodler: yes, thats the proposed fix
10:35 < nehan_> at least you required the eclipse attacker to also figure out how to crash the node uncleanly
10:35 < pinheadmz> nehan_: yeah remote execution of `bitcoin-cli stop` would be bad
10:35 < amiti> nehan_: pretty much, but one thing I learned from hebasto's comment here: https://github.com/bitcoin/bitcoin/pull/17428#issuecomment-591449881 is the two types of restart-based eclipse attacks
10:36 -!- ecurrencyhodler [68afd3af@cpe-104-175-211-175.socal.res.rr.com] has quit [Remote host closed the connection]     
10:36 < amiti> so yes, if we wipe anchors on unclean restarts, then we are vulnerable to some of those attacks but protected against others
10:36 < hebasto> yup ^^
10:36 < nehan_> amiti: thanks!
10:37 < nehan_> hebasto: power failures are clean shut downs?
10:37 < hebasto> nehan_: no!
10: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
10:37 -!- ecurrenchodler [68afd3af@cpe-104-175-211-175.socal.res.rr.com] has joined #bitcoin-core-pr-reviews     
10: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.
10:38 < pbleam> power failures are unclean but hopefully not as repeatable as remote shutdowns?
10:38 < nothingmuch> i'm curious what peoples' thoughts on the right balance might be
10:38 < rockzombie2> yeah, why does the current PR implementation work well against power failures?
10:38 < luke-jr> nothingmuch: losing anchors isn't particularly problematic
10:38 < nothingmuch> and how easy it is for evil anchors to game
10:38 < _andrewtoth_> nothingmuch I believe the fix is to not use what was written when restarting uncleanly
10: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.
10: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
10:39 < luke-jr> nehan_: anchors resist the eclipse
10:39 < amiti> curious what other reviewers think about that, as well as hebasto & luke-jr
10: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
10:39 < hebasto> nehan_: current implementation, without a suggested fix, will do
10:39 < lightlike> nehan_: i believe hebasto was suggesting not to implement this feature of wiping during unclean restarts.
10:39 < luke-jr> amiti: being unable to start is a different attack than eclipse
10:39 < nehan_> lightlike: ah ok, thanks
10:40 < nehan_> lightlike: _not_ wiping works well against an EA adversary. yes.
10: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
10: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?
10:41 < luke-jr> amiti: right
10:41 < amiti> ok good point. I should say unable to sync instead of unable to start
10:41 < luke-jr> under certain eclipse attacks
10:41 < emzy> Maybe have a counter. And wipe the anchors after lets say 5 restarts/crashes.
10:42 < hebasto> luke-jr: in the worst case we find out remote crash vulnerability and will fix it, I hope
10:42 < luke-jr> hebasto: sure, we have in the past
10: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
10:42 < luke-jr> emzy: if the EA can kill power, they can do it 5 times
10:42 < amiti> does that make sense?
10:43 < luke-jr> amiti: no
10:43 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection]     
10:43 < luke-jr> EAs are theoretical; node-crashing vulns are common in practice
10:43 < luke-jr> (power-based EAs are theoretical *and* unlikely)
10:43 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews     
10:43 < emzy> luke-jr: but after the 5. time I don't use the anchor anymore. So it limits the attack
10:43 < amiti> ok gotcha
10:44 < nehan_> emzy: no, it enables the restart-based eclipse attack
10:44 < luke-jr> emzy: the power-cycling attack is EA; it BENEFITS from you dropping the anchor
10: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
10:44 < luke-jr> emzy: if they just want to DoS, they will simpoly leave the power off :P
10:44 < amiti> hebasto: what are you thinking for the next steps for this PR?
10:45 < emzy> nehan_: luke-jr: Ok. I understand the problem.
10:45 < amiti> nothingmuch: thats true, there could be more complex anchor logic
10: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
10:45 < nothingmuch> amiti: fwiw not an actual suggestion, just an extreme hypothetical
10:45 < luke-jr> https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
10:46 < hebasto> applying suggested fix will make pr scope significantly smaller, but it seems still useful
10:46 < luke-jr> almost all the "DoS" category are node crashers
10:46 < luke-jr> to get a sense of how common this is
10:46 < amiti> hebasto: I agree.
10:47 < amiti> ok, are people interested in continuing with the questions?
10:47 < amiti> lets take a look at the implementation (question #3)
10: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
10:48 < amiti> in the current implementation, whats the logic for how peers are persisted and removed?
10:50 < jnewbery> they're persisted in the DumpAnchors() function
10:50 < amiti> nothingmuch: you alluded to it before :) whats the method that adds peers to the anchors.dat?
10:51 < nothingmuch> i was rereading to verify my understanding
10:51 < amiti> jnewbery: yup!
10:51 < nothingmuch> but i think DumpAnchors is done after a successful handshake with a blocks only outgoing peer
10:51 < amiti> nothingmuch: yup! thats my understanding too
10:51 < jnewbery> (which is called in the ProcessMessage() function in net_processing
10:51 < nothingmuch> and that in turn saves all of the outgoing blocks only peers based on the current addrman state
10:51 < amiti> for anyone wondering, here's where that happens: https://github.com/bitcoin/bitcoin/pull/17428/files#diff-eff7adeaec73a769788bb78858815c91R2136
10:52 -!- ecurrenchodler [68afd3af@cpe-104-175-211-175.socal.res.rr.com] has quit [Remote host closed the connection]     
10:52  * luke-jr , before running out of time, wonders if anchors should be reduced/skipped entirely if the user has manually configured addnode peers
10:53 < amiti> luke-jr: interesting point, can you explain that further? what are the tradeoffs you see?
10:53 < jnewbery> luke-jr: can you quickly summarise what addnode peers are?
10:53 < luke-jr> addnode peers are typically permanent connections to other known nodes
10:53 < nothingmuch> those count against outbound connection limit, right?
10:53 < luke-jr> seems to be a manual anchor in practice IMO
10:53 < luke-jr> I don't think they do, but I forget
10:54 < nothingmuch> hmm. if they don't what is the downside of having both anchors and manually added connections?
10: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
10:54 < hebasto> luke-jr: will the only -addnode sufficient for not using anchors?
10:54 < luke-jr> hebasto: ?
10:55 < hebasto> maybe require two or more manually added nodes?
10:55 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection]     
10:55 < luke-jr> hebasto: hence "reduce" :P
10:55 < luke-jr> hebasto: ie, if there's 1 addnode, make <defalt>-1 auto anchors
10:55 < luke-jr> s/make/load/
10:55 < amiti> time check: we have 5 more minutes remaining. does anyone have any questions?
10:56 < hebasto> luke-jr: great!
10:56 < pinheadmz> I feel queasy about the anchor peers - im not convinced that an eclipse-attacker couldnt use it against a victim
10: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
10:56 < pinheadmz> but its just a feeling, doesnt feel right
10:56 < nehan_> I'm confused about the conversation her: https://github.com/bitcoin/bitcoin/pull/17428/files#diff-9a82240fe7dfe86564178691cc57f2f1R1824
10:56 < luke-jr> (but maybe it's simpler than I assume)
10:57 < nehan_> *here
10:57 < nehan_> what is that code doing?
10:57 < instagibbs> was there a special reason that anchor connections were blocksonly ones?
10:57 < luke-jr> instagibbs: privacy
10:58 < luke-jr> scroll up
10:58 < instagibbs> there's lots of scroll
10:58 < instagibbs> lol     
10: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?
10:58 < instagibbs> luke-jr, that seems to be a point against "reduce anchors with addnode"
10:58 < pinheadmz> amiti: no just that, taking over the anchors
10:58 < nothingmuch> instagibbs: ~18:22
10:58 < luke-jr> instagibbs: no, you have the downside there with addnode whether or not you have auto-anchors
10:58 < instagibbs> GMT? (doing head math)
10:59 < nothingmuch> instagibbs: yep, heh, i was thinking of doing *:22 just to avoid that confusion
10:59 < amiti> pinheadmz: ah yes, I think thats possible, esp with this first implementation that is intentionally scoped to be minimal
10:59 < nothingmuch> instagibbs: 25 mins ago ;-)
10:59 < instagibbs> luke-jr, I don't understand what you're saying.
11:00 < hebasto> nehan_: that code about connection priority
11: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
11:00 < amiti> ok! looks like thats time!
11:00 < amiti> thank you all for coming and participating
11:00 < pinheadmz> great job amiti
11:00 < amiti> and thank you hebasto for this PR :)
11:00 < jnewbery> great meeting amiti. That was a lot of fun. Thanks!
11:00 < jnewbery> #endmeeting
11:01 < emzy> Thank you amiti and all!
11:01 < lightlike> thanks!
11:01 < _andrewtoth_> thanks all!
11:01 < pbleam> thanks!
11:01 < instagibbs> luke-jr, oh are you saying you've already done the damage(privacy) while also gained the connection robustness?
11:02 < luke-jr> yes     
11:02 < instagibbs> ah, ok
11:02 < nehan_> thanks!
11:02 < instagibbs> hmm, maybe :) I'll think on it
11:02 < luke-jr> anchors don't *require* privacy; it's just something we don't want to lose with them
11:02 < luke-jr> addnode loses privacy, but it also provides what anchors accomplish
11:03 < embark> thanks amiti and all good meeting
11:03 < instagibbs> luke-jr, if you weren't punked into connecting to someone evil manually(manual vs auto I know you discussed that)
11:03 < lightlike> tough PR, lots of decisions to make with pros and cons that seem really hard to weight against each other.
11:03 < instagibbs> good stuff
11:03 < luke-jr> instagibbs: we can't stop users from shooting themsleves in the foot all the time
11:04 < instagibbs> worst-case for now it's 2 additional anchor connections which I don't think in practice will matte
11:04 < instagibbs> obviously more blocks only connections would change this
11:11 < nothingmuch> fwiw it appears addnode is capped at 8 independently of other outbound conns
11:20 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Remote host closed the connection]     
11:29 -!- embark [~embark@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: embark]     
11:31 -!- pbleam [268ebb82@38.142.187.130] has quit [Remote host closed the connection]     
11:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
11:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
11:58 -!- audichya [6753d7c1@103.83.215.193] has quit [Remote host closed the connection]     
12:15 < jnewbery> meeting log is posted: https://bitcoincore.reviews/17428.html
12:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
12:24 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
12:43 -!- pinheadmz [~matthewzi@5.181.234.220] has quit [Quit: pinheadmz]     
12:43 -!- pinheadmz [~matthewzi@5.181.234.220] has joined #bitcoin-core-pr-reviews     
13:00 < luke-jr> jnewbery: do you think #17356 would be a good review candidate here?
14:41 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
14:58 -!- masterdonx2 [~masterdon@178-175-148-4.static.as43289.net] has quit [Read error: Connection reset by peer]     
15:01 -!- MasterdonX [~masterdon@104.244.208.36] has joined #bitcoin-core-pr-reviews     
15:09 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
15:12 -!- slivera [~slivera@217.138.204.90] has joined #bitcoin-core-pr-reviews     
16:05 < jnewbery> luke-jr: definitely. Would you like to host? We have hosts lined up for March 4 and 11, so the next free slot is March 18
16:08 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]     
16:14 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
16:34 < luke-jr> jnewbery: ok
16:36 -!- lightlike [~lightlike@p200300C7EF0EC300D1F5536EEE70558F.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
16:37 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
16:39 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
16:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
17:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
19:37 -!- felixfoertsch [~felixfoer@2001:16b8:502d:3f00:7442:a60a:c0ed:c1c2] has joined #bitcoin-core-pr-reviews     
19:40 -!- felixfoertsch23 [~felixfoer@92.117.56.33] has quit [Ping timeout: 255 seconds]     
19:45 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
19:46 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
19:55 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
19:56 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
20:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
20:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
22:02 -!- harrigan_ [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
22:04 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 255 seconds]     
23:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]