--- Log opened Wed Mar 02 00:00:14 2022
00:53 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
04:09 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
04:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
04:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 252 seconds]
04:58 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
06:00 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
06:02 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews
06:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
06:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Remote host closed the connection]
06:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
06:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
07:09 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
07:18 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has quit [Quit: leaving]
07:38 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
07:44 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
07:45 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
07:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
08:12 -!- metallicc [~metallicc@c-73-217-34-231.hsd1.co.comcast.net] has quit [Quit: Leaving]
08:22 -!- glozow [sid453516@user/glozow] has quit [Read error: Connection reset by peer]
08:22 -!- glozow [sid453516@user/glozow] has joined #bitcoin-core-pr-reviews
08:25 -!- schmidty [sid297174@lymington.irccloud.com] has quit [Read error: Connection reset by peer]
08:25 -!- schmidty [sid297174@id-297174.lymington.irccloud.com] has joined #bitcoin-core-pr-reviews
08:32 -!- erik1 [~erik@181-191-0-203.uplinkx.com.br] has joined #bitcoin-core-pr-reviews
08:35 -!- jaonoctus [~jaonoctus@177-55-195-3.static.sumicity.net.br] has joined #bitcoin-core-pr-reviews
08:39 -!- erik1 [~erik@181-191-0-203.uplinkx.com.br] has quit [Quit: WeeChat 3.4]
08:43 -!- Vilela [~Vilela@177.22.160.76] has joined #bitcoin-core-pr-reviews
08:47 -!- jaonoctus [~jaonoctus@177-55-195-3.static.sumicity.net.br] has left #bitcoin-core-pr-reviews []
08:49 -!- jaonoctus [~jaonoctus@177-55-195-3.static.sumicity.net.br] has joined #bitcoin-core-pr-reviews
08:51 -!- jaonoctus [~jaonoctus@177-55-195-3.static.sumicity.net.br] has quit [Client Quit]
08:51 -!- erik-etsuji-kato [~erik@181.191.0.203] has joined #bitcoin-core-pr-reviews
08:52 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews
08:55 -!- Guest58 [~Guest58@pool-74-101-51-187.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
08:56 -!- Guest58 [~Guest58@pool-74-101-51-187.nycmny.fios.verizon.net] has quit [Client Quit]
08:57 -!- sanya [~sanya@178-221-64-249.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
08:59 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:00 < brunoerg> #startmeeting
09:00 < svav> Hi
09:00 < erik-etsuji-kato> hi
09:00 < brunoerg> hi
09:00 < jaonoctus> hi
09:00 < theStack> hi
09:00 < Kaizen_Kintsugi_> hi
09:00 < brunoerg> Hello, everyone! Today we’re looking at #24034 (Delete anchors.dat after trying to connect to that peers)! 
09:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:00 -!- bitcoin_1o1 [~bitcoin_1@187.202.196.86] has joined #bitcoin-core-pr-reviews
09:01 < brunoerg> Anyone here for the first time? :)
09:01 < larryruane> hi
09:01 < effexzi> Hi every1 
09:01 -!- Tobi4000 [~Tobi4000@185.212.107.48] has joined #bitcoin-core-pr-reviews
09:01 < brunoerg> no one?
09:02 < bitcoin_1o1> hi all
09:02 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:02 < brunoerg> did anyone review the PR? 
09:02 < brunoerg> y/n/partial?
09:02 < Kaizen_Kintsugi_> y
09:02 < erik-etsuji-kato> 0.76y
09:02 < jaonoctus> y
09:03 < larryruane> 0.5y
09:03 < glozow> hi
09:03 < bitplebpaul> conceptually Y
09:03 < svav> I read the notes and looked at some of the code
09:03 < theStack> y, concept ack
09:03 < brunoerg> ok, cool :)
09:03 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Client Quit]
09:03 < brunoerg> Before discussing about this PR, let's do a quick review! 
09:04 < brunoerg> What is an eclipse attack? Could someone explain it?
09:04 < svav> In an eclipse attack, a malicious actor isolates a specific user or node within a peer-to-peer (P2P) network. The attacker’s goal is to obscure a user’s view of the P2P network in preparation for more complex attacks or to cause general disruption.
09:04 < bitcoin_1o1> y
09:04 < brunoerg> svav: great
09:04 < Kaizen_Kintsugi_> +1 svav
09:04 < svav> In an eclipse attack, an attacker tries to redirect the target network participant’s inbound and outbound connections from legitimate nodes to the attacker’s nodes. By doing so, the target is sealed off from the actual network.
09:04 < svav> Since the target is disconnected from the blockchain ledger, the isolated node can then be manipulated by the attacker. An eclipse attack can lead to block mining disruptions as well as illegitimate transaction confirmations.
09:05 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:05 -!- Tobi400060 [~Tobi4000@185.212.107.48] has joined #bitcoin-core-pr-reviews
09:05 < bitcoin_1o1> +1 svav
09:05 < larryruane> I've always been a little unclear on the difference between an eclipse attack and a sybil attack .. are these related? 
09:05 < erik-etsuji-kato> + the attacker can see what transactions is been made by this peer, hurting privacy
09:05 < svav> One different is eclipse is one node and sybil is whole network
09:05 -!- Vilela [~Vilela@177.22.160.76] has quit [Quit: Connection closed]
09:06 < svav> *difference*
09:06 < brunoerg> larryruane: great question
09:06 -!- Tobi4000 [~Tobi4000@185.212.107.48] has quit [Ping timeout: 240 seconds]
09:06 -!- santimena [~santimena@45.176.89.48] has joined #bitcoin-core-pr-reviews
09:06 < larryruane> svav: do you mean one node is the victim in the eclipse attack? (or one node is the attacker?)
09:06 < santimena> #startmeeting hi
09:07 < erik-etsuji-kato> An eclipse attack is when most (if not all) of your peers are malicious and they basically prevent you from being well-connected to the network to obtain information about transactions you're interested in. An eclipse attack is particular useful when a payer has sent some bitcoins to you in some transaction, then decides to also doublespend the same bitcoins.
09:07 < bitplebpaul> one node is the victim
09:07 < bitplebpaul> i believe
09:07 < glozow> in my head i consider “sybil attacking” to refer to the technique used, ie making lots of sybils, and “eclipse” as the outcome to the victim of an attack.
09:08 < brunoerg> I think in Sybil the attacker tries to take control of the network by creating multiple peers
09:08 < glozow> but this is my imaginary distinction and not scientific haha
09:08 < ls55> I think eclipse attack implies isolate the victim in a subnet controlled by the attacker. In sybil attack, there isn't his concept.
09:08 < svav> Sybil Attack is a type of attack seen in peer-to-peer networks in which a node in the network operates multiple identities actively at the same time and undermines the authority/power in reputation systems. The main aim of this attack is to gain the majority of influence in the network to carry out illegal(with respect to rules and laws set in the
09:08 < svav> network) actions in the system.
09:08 < svav>  A single entity(a computer) has the capability to create and operate multiple identities(user accounts, IP address based accounts). To outside observers, these multiple fake identities appear to be real unique identities.
09:08 < sipa> I think they are distinct concepts.
09:08 < erik-etsuji-kato> A sybil attack on the other hand is where a malicious actor is trying to spam the network with nodes that they control attempting to subvert the network's reputation system. 
09:08 < erik-etsuji-kato> https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack
09:08 < sipa> The goal of an eclipse attack is making a node isolated (i.e., no honest peers).
09:09 < sipa> The goal of a Sybil attack is exploiting a reputation mechanism where a node e.g. believes most of its peers.
09:09 < svav> So eclipse, one node is surrounded by malicious info, in sybil, one person impersonates lots of nodes
09:09 < ls55> Exact
09:09 < brunoerg> +1 sipa
09:09 < sipa> I think in early Bitcoin history, the two were often conflated.
09:10 < brunoerg> good explanations, any more questions about this?
09:10 < sipa> And the term Sybil attack was used to what should really be called eclipse attacks. Sybil attackd generally don't apply to Bitcoin's P2P network, because we never do something like believing the majority of our peers.
09:10 < sipa> It suffices to have one honest peer.
09:11 < Kaizen_Kintsugi_> So #17428 prevents this by using the anchors.dat file to reconnect to honest peers
09:11 < Kaizen_Kintsugi_> ?
09:11 < larryruane> sipa: +1 yes because of proof-of-work
09:11 < svav> larryruane: I mean one node is the victim in an eclipse attack.
09:11 < Kaizen_Kintsugi_> so when the node restarts it can't be automatically surrounded by the attacker?
09:12 < ls55> `So #17428 prevents this by using the anchors.dat file to reconnect to honest peers` How does the node consider a peer honest ? What are the criteria?
09:12 < Kaizen_Kintsugi_> Most work?
09:12 < bitplebpaul> +1 question of ls55
09:13 < Kaizen_Kintsugi_> or is it the the type of node
09:13 < Kaizen_Kintsugi_> only block relay nodes are saved as anchors?
09:13 < brunoerg> not sure if i agree with "honest"
09:13 < Kaizen_Kintsugi_> yea, "honest" is a vague term, I'm using it to describe a node that is acting in good faith
09:14 < brunoerg> Kaizen_Kintsugi_: yes, only block-relay-only
09:14 < erik-etsuji-kato> I think we take a long-lived and stable connection we had during operation
09:15 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Quit: Connection closed]
09:16 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:16 < brunoerg> we mentioned here "anchors.dat", Kaizen said that `#17428 prevents this by using the anchors.dat file to reconnect to honest peers`, but how it works? what we save into anchors.dat? when?
09:16 < Kaizen_Kintsugi_> Anchors are last known outgoing block-relay-only peers that are tried to re-connect to on startup
09:17 < larryruane> Really basic Q: The earlier PR that added anchors.dat, 17428, could it have included the changes that this PR (24034) is making, but didn't due to just an oversight (or ease of programming)? Or was 17428's behavior intentional, and then only later it was understood that 24034's behavior would be an improvement?
09:17 < svav> This PR helps prevent an eclipse attack because it prevents the possibility of there being an empty anchors.dat file on restart, that a malicious user could use as part of a a restart-based eclipse attack.
09:17 < ls55> anchors.dat is written when the node starts and shuts down
09:18 < Kaizen_Kintsugi_> and anchors seems to be simply last known block replays
09:18 < Kaizen_Kintsugi_> err *relays
09:19 < svav> This PR prevents this - 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.
09:19 < brunoerg> larryruane: I didn't follow the discussions in 17428 but i think 24034's behavior would be an improvement
09:20 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Client Quit]
09:20 < larryruane> "... then force the victim to restart ..." That's something else unclear to me, how can an attacker for the victim to restart?
09:20 < brunoerg> larryduane: DoS? 
09:20 < larryruane> *force
09:20 < brunoerg> sorry, larryruane*
09:20 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:21 -!- yoooooowlknflds [~yoooooowl@136.36.80.83] has joined #bitcoin-core-pr-reviews
09:21 < larryruane> ok but, not that we're aware of a specific way? Just that there *may* be a way (to force a restart)?
09:21 < brunoerg> larryruane: or maybe social engineering?
09:21 < Kaizen_Kintsugi_> what would the DoS be? Spamming the node with bad transactions? Or is there an assumption that their could be something out there?
09:21 < larryruane> oh right, good point brunoerg !
09:22 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Client Quit]
09:22 < Kaizen_Kintsugi_> ah okay okay, I get it know, 
09:22 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:22 < Kaizen_Kintsugi_> attacks can be multi-pronged
09:22 < ls55> if a peer spams bad transactions, it will be blocked automatically.
09:22 < larryruane> or (to further answer my own question) maybe an attacker somehow can cut power to the victim?
09:23 < larryruane> (not any attacker could do that obviously, but maybe one can)
09:23 < svav> Just on my previous comment, which is slightly incorrect - I think currently the weakness is that an attacker could force node to shutdown before it attempts anchors.dat connection, creating blank anchors.dat, which can then be repopulated by attacker before node restarted - I think
09:23 < brunoerg> larryruane: it's a possibility
09:23 < theStack> the DoS doesn't have to be bitcoin-specific, it could target another service running on the same or the OS in general (e.g. ping flood or alike) that causes it to crash or needing to restart
09:23 -!- Guest58 [~Guest58@pool-74-101-51-187.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:23 < erik-etsuji-kato> +ls55: yes, but what if you make it with tons of machines? Verifying transactions ain't cheap
09:23 < larryruane> theStack: +1
09:24 < brunoerg> theStack: +1, excellent
09:24 < Kaizen_Kintsugi_> theStack: thx
09:24 < bitcoin_1o1> theStack: +1
09:24 < Kaizen_Kintsugi_> so this leads in to the next question of the clean and unclean shutdown?
09:24 < Kaizen_Kintsugi_> an attack or interuption would be an unclean shutdown?
09:25 < brunoerg> yes! 
09:25 < erik-etsuji-kato> yes, unclean
09:25 < brunoerg> but before it, we can discuss why anchor.dat is deleted?
09:25 < brunoerg> anchors.dat*
09:25 < larryruane> So to me, even on a very superficial level, we can know that this PR deserves a concept ack because if it's a good idea to persist some data across restarts, then it's good to also do so in the case of a *quick* restart ... is that legitimate reasoning?
09:25 < erik-etsuji-kato> Because if we have an unclean shutdown, we don't reuse anchors?
09:25 < brunoerg> when a node starts, it deletes the anchors.dat file, why?
09:26 < Kaizen_Kintsugi_> my only guess is to make sure that it you are starting from a clean anchors file
09:26 < ls55> erik-etsuji-kato yes, ddos is more difficult to handle, but it is also more expensive for the attacker.
09:26 < Kaizen_Kintsugi_> like if you reinstalled and there was a very old anchors.data with very old data in it
09:27 < ls55> `when a node starts, it deletes the anchors.dat file, why?`To ensure the anchor peers are up to date
09:27 < svav> This PR could do with a detailed explanation of the lifecycle of anchors.dat, i.e. when it is created, read/write and deleted.
09:28 < brunoerg> larryruane: I think so. I discovered this 'issue' after a quick restart, I just noticed in my terminal that it read 2 anchors from anchors.dat and right after it dumped 0 ones
09:28 < brunoerg> ls55: yes, to keep it up to date
09:29 < brunoerg> So, couldn't we only read and write? 
09:29 < Kaizen_Kintsugi_> so node starts, reads anchors, deletes, then dumps anchors
09:29 < Kaizen_Kintsugi_> on shut down
09:29 < ls55> Exact
09:30 < Kaizen_Kintsugi_> brunoerg, no because we want to clear the old anchors
09:30 < Kaizen_Kintsugi_> ?
09:30 < brunoerg> we could clear it by reading and writing... couldn't we?
09:31 -!- Guest58 [~Guest58@pool-74-101-51-187.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
09:31 < brunoerg> we can clear a db or a file without deleting it
09:31 < Kaizen_Kintsugi_> I guess we could, but I think that would open up to more complexity? I can't think of a specific reason? Is there something that reads the creation date of the anchor file?
09:31 < brunoerg> clean*
09:32 < Kaizen_Kintsugi_> is a clean file read as empty?
09:32 < ls55> `So, couldn't we only read and write? `It is simpler to delete the file.
09:32 < Kaizen_Kintsugi_> ls55, that is the logic that I am arriving at.
09:32 < larryruane> ".. clear it by reading and writing .." There is a subtle difference between deleting a file and truncating it to zero-length ... if the user changes permissions on the file, then it gets deleted and re-created, its permissions will revert ... also hard-link behavior is slightly different (not that that matters much)
09:33 < Kaizen_Kintsugi_> oh sweet
09:33 < brunoerg> larryruane: nice! 
09:33 < jaonoctus> larryruane: +1
09:33 < Kaizen_Kintsugi_> I didn't think of file permmissions coming into play
09:33 < bitplebpaul> sorry, when would the permissions be changed? under what conditions
09:33 < bitplebpaul> +1 Kaizen
09:34 < Kaizen_Kintsugi_> I think the logic is being prepared for whatever condition could happen
09:34 < Kaizen_Kintsugi_> we don't know why someone would change permissions of the file, but they can
09:34 < ls55> The file is created by the `bitcoind` process. I think the permissions will be inherited.
09:34 < larryruane> bitplebpaul: if the bitcoind node creates the file with (let's say) mode 0755, and the user changes it to 0777 for some reason, then bitcoind deletes and recreates the file, it goes back to 0755
09:34 < Kaizen_Kintsugi_> so there is an open vunderability that needs to be addressed
09:35 < Kaizen_Kintsugi_> damn I learn so much at these things damn
09:35 < ls55> Why would that be a vulnerability?
09:35 < larryruane> (or the owner or group or ACLs could be manually changed)
09:36 < bitplebpaul> it sounds like resetting to 0755 is avoiding a vulnerability
09:36 < Kaizen_Kintsugi_> yea
09:36 < ls55> This file is made to be ephemeral
09:36 < bitplebpaul> sorry ACLs?
09:36 < Kaizen_Kintsugi_> yea if the person is on a computer that doesn't belong to them and the administrator does something to .dat files
09:36 < larryruane> bitplebpaul: well that's just an example ... presumably if the user (owner of the machine) changes permissions, there's some good reason for that (i guess!)
09:36 < bitplebpaul> access control list**
09:37 < bitplebpaul> got it
09:37 < bitplebpaul> thx
09:38 < brunoerg> Kaizen_Kintsugi_: well, if someone can access my computer, he could replace anchors.dat, not sure if changing the permission would be the biggest problem
09:39 -!- Tobi400060 [~Tobi4000@185.212.107.48] has quit [Quit: Connection closed]
09:39 < larryruane> the return value (indicating success or failure) from `fs::remove()` is ignored, which is ok (we're just making a best-effort), but maybe add a comment to that effect, so readers don't think it was just an oversight? (this is more of a comment i should leave on the PR)
09:40 < Kaizen_Kintsugi_> brunoerg: agreed, under those conditions, thats probably the least of your worries :)
09:41 < brunoerg> cool! can we go to the next question?
09:42 < erik-etsuji-kato> y
09:42 < theStack> larryruane: or as alternative, casting the return value to (void)? though i am not sure if this is in line with our coding guidelines, i didn't see it much
09:42 < larryruane> theStack: +1 that does indicate that you're aware of the return value
09:43 < jaonoctus> brunoerg: y
09:43 < brunoerg> There are two ways to shutdown a node: a “clean” way and “unclean” one. What does that mean?
09:43 < Kaizen_Kintsugi_> clean is uninterupted
09:43 < svav> Clean is an operator requested shutdown where bitcoind can go through all its shutdown processes. Unclean is an inadvertent shutdown.
09:43 < Kaizen_Kintsugi_> unclean is forced
09:44 < theStack> svav: +1
09:44 < Kaizen_Kintsugi_> I like svav's description better
09:44 < Kaizen_Kintsugi_> +1 svav
09:44 < brunoerg> svav: +1 
09:44 < erik-etsuji-kato> svav: +1
09:45 < brunoerg> Now that we have a good definition about "clean" and "unclean" shutdown, we can discuss the next question...
09:45 < ls55> "Clean" mode implies that all data is stored properly (UTXO Set, Blockchain, anchors.dat, etc ...) before shutdown 
09:46 < larryruane> good answers, i think of clean as "flushing in-memory data to disk" (unclean, not)
09:46 < brunoerg> good ones
09:46 < brunoerg> So...
09:46 < brunoerg> On current master, what happens if we shut down (cleanly or uncleanly) before the node has tried to connect to the peers from anchors.dat?
09:46 < svav> An empty anchors.dat is created.
09:47 < brunoerg> svav: in both scenarios? 
09:47 < svav> Not sure
09:47 < larryruane> brunoerg: if the node has had a chance to read `anchors.dat` then that file is deleted
09:47 < ls55> Exact
09:47 < bitcoin_1o1> svav: +1
09:47 < erik-etsuji-kato> If we shutdown cleanly, then anchors.dat is created again
09:48 < erik-etsuji-kato> I guess
09:48 < brunoerg> erik-etsuji-kato: +1 
09:48 < brunoerg> larryruane: yes and it happens in both scenarios
09:50 < bitplebpaul> how long after opening bitcoin core does it take to connect to the peers on anchors.dat
09:50 < bitplebpaul> usually*
09:50 < bitplebpaul> ie what time window are we discussing? 2-10 seconds?
09:51 < larryruane> bitplebpaul: +1 I was wondering this too!
09:51 < bitplebpaul> cool! i was worried o was only being tangentially relevant
09:51 < brunoerg> bitplebpaul: i don't know exactly, but I don't think it takes more than 10 seconds
09:51 < Kaizen_Kintsugi_> I think the old way, there is a window of opportunity to connect to the attackers nodes if that anchors.dat file is empty
09:53 < brunoerg> We can go to the next question that is related to this one
09:53 < Kaizen_Kintsugi_> It seems like nodes just start connecting
09:53 < brunoerg> In this PR, in which scenarios do we delete anchors.dat?
09:53 < erik-etsuji-kato> If we actually tried those peers
09:54 < bitplebpaul> what if we only tried some peers and then force/unclean close?
09:54 < theStack> after we read it, and after we tried all of its peers?
09:54 < ls55> After `m_anchors` is no longer  empty.
09:55 < bitcoin_1o1> +1 theStack
09:56 < erik-etsuji-kato> bitplebpaul: Then it's not deleted
09:56 < theStack> ah no, my first part was wrong; only after we read it and it's empty
09:56 < Kaizen_Kintsugi_> Yea I think it only gets deleted after it's read
09:56 < brunoerg> theStack: +1
09:56 < Kaizen_Kintsugi_> I'm reading around line 1975, cant find a delete
09:56 < svav> So, node starts, anchors.dat exists, it is read, anchors.dat deleted - all ok. But if node starts, anchors.dat exists and populated, it does not get read, then node forced shut down, anchors.dat is recreated at startup as an empty file - vulnerable to start-up eclipse attack .... is this correct???
09:57 < Kaizen_Kintsugi_> start > read > delete > connect
09:58 < brunoerg> No, in this PR we do: start > read > try to connect to all peers from the file > delete
09:58 < brunoerg> So, if we shut down our node before trying to connect to that peers, the file is preserved
09:59 < Kaizen_Kintsugi_> I understand now
09:59 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Quit: Connection closed]
09:59 < larryruane> quick question on testing... there is one small test change, but are you planning to add more tests? Or is it just very difficult to test these changes?
09:59 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:59 < brunoerg> of course, if the file is empty as theStack said, we delete it right after reading the file
10:00 < ls55> How does this PR know the anchor peers are connected ?
10:00 < larryruane> also wondering, is the one small test change just fixing a timing window (does not depend on this PR)?
10:00 < brunoerg> larryruane: Yes and i intend to use the stress test to test it 
10:00 < larryruane> brunoerg: +1 perfect, looking forward to seeing how to do that!
10:00 < theStack> would be interested what happens if the file contains garbage (for example, due to power loss while writing). is it still deleted, as the deserialization leads to an empty vector, or is there some other exception thrown?
10:00 < larryruane> (you mean fuzz?)
10:01 < bitcoin_1o1> brunoerg: what about functional tests?
10:01 < larryruane> theStack: great question
10:01 < brunoerg> larryruane: no, see feature_init.py into functional tests
10:01 < svav> Some diagrams about how anchors.dat currently works and will then work after this PR would have been nice ...
10:02 < svav> or flow charts
10:02 < brunoerg> our time is over :( 
10:02 < larryruane> brunoerg: thanks, this was great!
10:02 < brunoerg> thanks everyone! 
10:03 < theStack> thanks for hosting brunoerg!
10:03 < brunoerg> #endmeeting
10:03 < bitplebpaul> thanks bruno thanks everyone
10:03 < jaonoctus> ty
10:03 < erik-etsuji-kato> thanks brunoerg!
10:03 < Kaizen_Kintsugi_> thanks everyone!
10:03 < ls55> thanks brunoerg
10:03 < Kaizen_Kintsugi_> Learned a lot again
10:03 < Kaizen_Kintsugi_> Brain is swole
10:03 < bitcoin_1o1> thanks brunoerg, and all
10:03 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has quit [Quit: WeeChat 2.8]
10:03 < svav> Thanks brunoerg and all!
10:03 < brunoerg> i learned a lot as well 
10:04 < brunoerg> theStack: empty vector
10:05 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Quit: Connection closed]
10:05 < theStack> brunoerg: true, i just saw that ReadAnchors() simply catches std::exception and then clears the result vector
10:05 < brunoerg> yeah
10:06 < effexzi> Thanks every1 
10:07 < brunoerg> so, about the last question... Avoiding deletion of anchors.dat file before trying to connect to all peers from it is not enough to preserve it in a clean shutdown. Why? How does the PR deal with this?
10:07 < brunoerg> so as not to take too long, I can answer it :) 
10:08 < larryruane> i had a little trouble understanding this question, somehow :)
10:08 < brunoerg> Avoiding deletion of anchors.dat file before trying to connect to all peers from it is not enough to preserve that PEERS in a clean shutdown.
10:09 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:09 < Kaizen_Kintsugi_> hmmm
10:09 < brunoerg> because in a clean shutdown, it calls DumpAnchors(), and it overwrites the file resulting an empty one.
10:11 < Kaizen_Kintsugi_> So there is an opportunity to start > read > clean shut down > dump empty anchors?
10:11 < larryruane> I think for me to even understand the question, I have to understand something even more basic first: 1. we start up, 2. read anchors.dat and try connecting, let's say we're successful, 3. (with this PR) delete the anchors.dat file ... but we still have those anchor peers persisted in our peers.dat file? so we didn't lose them? (sorry this is so basic!)
10:12 < Kaizen_Kintsugi_> and you need the whole cycle? start > read > connect > clean shutdown > write valid anchors
10:12 < Kaizen_Kintsugi_> does DumpAddresses() write the peer.dat?
10:13 < Kaizen_Kintsugi_> (it does)
10:13 < brunoerg> larryruane: we have that peers connected, so, it calls GetCurrentBlockRelayOnlyConns() to dump them into a new anchors.dat
10:13 < Kaizen_Kintsugi_> ahhh so if that gets called before we are connected to anything, that is where we get into trouble
10:14 < brunoerg> start > read > try to connect > delete > shut down > if we have block-relay-only peers connected, it dumps them...
10:14 < Kaizen_Kintsugi_> but if we dont have any block-relay-only peers, we get an empty file?
10:15 < brunoerg> so, start > read > shut down before trying to connect > call GetCurrentBlockRelayOnlyConns() (it will return 0 peers) > create an empty anchors.dat
10:15 < larryruane> brunoerg: ok so, if we start > read > try to connect but while trying we clean-shutdown, then we write an empty anchors.dat?
10:15 < brunoerg> larryruane: yes! 
10:16 < larryruane> so is there further work to do after this PR to fix that? Or should this PR fix that?
10:16 < Kaizen_Kintsugi_> I think there is further work to be done
10:16 < Kaizen_Kintsugi_> We need a check to see if that is zero
10:16 < brunoerg> This PR fixes that by avoiding calling DumpAnchors in a clean shutdown if we didn't try to connect to that peers...
10:16 < larryruane> OH so this PR does address this, got it
10:17 < larryruane> i did see that conditional added, cool
10:17 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:17 < Kaizen_Kintsugi_> oh I see that now
10:17 < brunoerg> i addressed it recently :)
10:17 < Kaizen_Kintsugi_> if (fAddressesInitialized) is the check?
10:18 < larryruane> found it i think here https://github.com/bitcoin/bitcoin/pull/24034/files#diff-00021eed586a482abdb09d6cdada1d90115abe988a91421851960e26658bed02L2716
10:18 < brunoerg> cool
10:19 < Kaizen_Kintsugi_> Thanks for taking the time to help me understand this further
10:20 < brunoerg> you're welcome!
10:24 < larryruane> really tiny point, but pre-this PR there's a `DumpAnchors()` and `ReadAnchors()` ... would it be more consistent to call the new function `DeleteAnchors()` instead of `DeleteAnchorsFile()`? I do think the latter is more descriptive, but did you consider the consistency point too?
10:24 < Kaizen_Kintsugi_> As a noob, I would agree with that, I prefer things to be explicit
10:26 < brunoerg> larryruane: I think you're right
10:26 < brunoerg> will see it soon
10:27 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:29 -!- bitcoin_1o1 [~bitcoin_1@187.202.196.86] has quit [Ping timeout: 240 seconds]
10:29 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:31 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
10:33 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:39 -!- metallicc [~metallicc@c-73-217-34-231.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews
10:45 -!- sanya [~sanya@178-221-64-249.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
10:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Remote host closed the connection]
10:59 -!- santimena [~santimena@45.176.89.48] has quit [Quit: Connection closed]
11:10 -!- yoooooowlknflds [~yoooooowl@136.36.80.83] has quit [Quit: Connection closed]
11:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
11:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 260 seconds]
11:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
11:30 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Remote host closed the connection]
11:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
12:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Remote host closed the connection]
12:12 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
12:30 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 250 seconds]
12:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
12:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 245 seconds]
13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]
13:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
13:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 250 seconds]
13:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
13:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 268 seconds]
14:06 -!- jamesob1 [~jamesob@45.129.56.197] has joined #bitcoin-core-pr-reviews
14:07 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
14:07 -!- jamesob1 is now known as jamesob
14:07 -!- hashfunc133c [~user@2601:5c0:c280:7090:8c1e:afa3:b36b:39be] has joined #bitcoin-core-pr-reviews
14:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
14:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 250 seconds]
14:14 -!- erik-etsuji-kato [~erik@181.191.0.203] has quit [Quit: WeeChat 3.4]
14:28 -!- pink_sarco is now known as shiza
14:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
14:29 -!- shiza is now known as pink_sarco
14:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
14:46 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
14:50 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 245 seconds]
14:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
15:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 268 seconds]
15:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
15:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
15:47 -!- hashfunc133c [~user@2601:5c0:c280:7090:8c1e:afa3:b36b:39be] has quit [Ping timeout: 240 seconds]
16:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
16:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 260 seconds]
16:18 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
16:38 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
16:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
16:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 245 seconds]
17:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
17:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 252 seconds]
17:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
18:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 250 seconds]
18:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
18:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 260 seconds]
19:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
19:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 256 seconds]
19:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
19:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 245 seconds]
20:31 -!- hashfunc107e [~user@2601:5c0:c280:7090:78e9:5f82:1899:8c96] has joined #bitcoin-core-pr-reviews
20:46 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
20:50 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 250 seconds]
21:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
21:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
22:03 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:04 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:10 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
22:14 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds]
22:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
22:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
23:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has joined #bitcoin-core-pr-reviews
23:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:545f:a190:c707:505] has quit [Ping timeout: 240 seconds]
23:52 -!- karliatto [~karliatto@ip-78-45-9-182.net.upcbroadband.cz] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Mar 03 00:00:15 2022