--- 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 -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]