--- Log opened Tue Mar 09 00:00:51 2021
00:05 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has joined #bitcoin-core-dev
00:32 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
00:42 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 276 seconds]
00:42 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #bitcoin-core-dev
00:48 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca00c143e0318365b648.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:12 < vasild> fanquake: "your browser did something unexpected" wtf!?
01:14 < vasild> btw I was just logged out of my github account and had to enter user/pass again. This has not happened for months, if not years. May be related.
01:21 -!- Randolf [~randolf@184.70.10.188] has joined #bitcoin-core-dev
01:32 < fanquake> I was also logged out earlier today
01:36 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-fxgnvsfciueukqqj] has quit [Ping timeout: 260 seconds]
01:38 -!- jonatack_ [~jon@37.167.192.44] has joined #bitcoin-core-dev
01:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:42 < bitcoin-git> [bitcoin] jnewbery opened pull request #21395: Net processing: Remove redundant CNode.address member (master...2021-03-remove-address) https://github.com/bitcoin/bitcoin/pull/21395
01:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:42 -!- jonatack [~jon@37.166.110.136] has quit [Ping timeout: 260 seconds]
01:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:43 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/461f0c781e5a...e175ca9c6563
01:43 < bitcoin-git> bitcoin/master fa476f1 MarcoFalke: Use C++11 member initializer in CNodeState
01:43 < bitcoin-git> bitcoin/master e175ca9 fanquake: Merge #21370: Use C++11 member initializer in CNodeState
01:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:43 < bitcoin-git> [bitcoin] fanquake merged pull request #21370: Use C++11 member initializer in CNodeState (master...2103-netCNodeStateRefactor) https://github.com/bitcoin/bitcoin/pull/21370
01:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:49 -!- FrontSevens [~FrontSeve@217.146.82.202] has quit [Remote host closed the connection]
02:06 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-qjonxuxpnxmzzqjx] has joined #bitcoin-core-dev
02:09 < kallewoof> vasild: fanquake: there was some abundance-of-caution event that triggered a mass-expiry of all sessions: https://twitter.com/github/status/1369129888662306819?s=20
02:11 -!- hydenpype [7a1a1385@p1174134-ipoe.ipoe.ocn.ne.jp] has joined #bitcoin-core-dev
02:13 -!- hydenpype [7a1a1385@p1174134-ipoe.ipoe.ocn.ne.jp] has quit [Client Quit]
02:29 -!- JLP1 [~JLP@217.146.82.202] has joined #bitcoin-core-dev
02:33 < vasild> kallewoof: thanks for the link, "extremely rare security issue affecting a very small number of users" :-D
03:11 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-qjonxuxpnxmzzqjx] has quit [Remote host closed the connection]
03:13 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:14 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
03:16 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has quit [Ping timeout: 264 seconds]
03:18 -!- Gerson58Tremblay [~Gerson58T@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:46 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
03:47 -!- pinheadmz [~pinheadmz@hns-contributor.dev] has joined #bitcoin-core-dev
03:50 -!- pinheadmz [~pinheadmz@hns-contributor.dev] has quit [Client Quit]
04:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:00 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21397: fuzz: Bump FuzzedDataProvider.h (master...2103-fuzzInclude) https://github.com/bitcoin/bitcoin/pull/21397
04:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:05 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vbhvluwoeowgddsh] has joined #bitcoin-core-dev
04:31 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
04:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds]
04:48 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
04:51 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]
04:54 -!- belcher_ is now known as belcher
04:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:54 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e175ca9c6563...ee0dc02c6f93
04:54 < bitcoin-git> bitcoin/master fa7dc7a MarcoFalke: fuzz: Bump FuzzedDataProvider.h
04:54 < bitcoin-git> bitcoin/master ee0dc02 MarcoFalke: Merge #21397: fuzz: Bump FuzzedDataProvider.h
04:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:55 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21397: fuzz: Bump FuzzedDataProvider.h (master...2103-fuzzInclude) https://github.com/bitcoin/bitcoin/pull/21397
04:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:02 -!- theprofessor0x [~Mohamed@bb121-6-182-56.singnet.com.sg] has joined #bitcoin-core-dev
05:08 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has joined #bitcoin-core-dev
05:10 -!- owowo [~ovovo@91.193.4.10] has joined #bitcoin-core-dev
05:10 -!- owowo [~ovovo@91.193.4.10] has quit [Changing host]
05:10 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
05:14 -!- jnewbery_ is now known as jnewbery
05:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
05:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
05:16 -!- RandolfR [~randolf@184.70.10.188] has joined #bitcoin-core-dev
05:17 -!- Randolf [~randolf@184.70.10.188] has quit [Ping timeout: 245 seconds]
05:20 -!- jonatack_ [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
05:20 -!- Gerson58Tremblay [~Gerson58T@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]
05:30 -!- JLP1 [~JLP@217.146.82.202] has quit [Remote host closed the connection]
05:30 -!- jonatack [~jon@37.167.192.44] has joined #bitcoin-core-dev
05:37 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
05:38 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has quit [Client Quit]
05:42 -!- kvaciral [~kvaciral@212.8.251.11] has quit [Quit: Lost terminal]
05:46 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vbhvluwoeowgddsh] has quit [Ping timeout: 260 seconds]
05:48 -!- kvaciral [~kvaciral@212.8.251.11] has joined #bitcoin-core-dev
05:55 < sdaftuar> jeremyrubin | Do we nuke all the validation caches after a soft fork activates? <------- the scriptcache includes a hash of the consensus flags that a transaction's scripts were validated with, so that when a softfork activates we just end up with cache misses, and not consensus failure
05:56 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-irngybgfmgpzypua] has joined #bitcoin-core-dev
06:02 -!- maop [~maop@37.120.211.188] has joined #bitcoin-core-dev
06:10 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
06:10 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
06:11 -!- pinheadmz [~pinheadmz@hns-contributor.dev] has joined #bitcoin-core-dev
06:22 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
06:24 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
06:26 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has quit [Client Quit]
06:27 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
06:29 < jnewbery> jeremyrubin: and for reference https://github.com/bitcoin/bitcoin/blob/ee0dc02c6f93de2a366bbff490eb4d37bca6a24f/src/validation.cpp#L982-L987
06:37 -!- jasonzhouu [~jasonzhou@112.10.159.239] has joined #bitcoin-core-dev
06:38 -!- smctwo_ [~smctwo@94.204.225.231] has joined #bitcoin-core-dev
06:40 -!- smctwo_ [~smctwo@94.204.225.231] has quit [Read error: Connection reset by peer]
06:40 -!- smctwo [~smctwo@94.204.225.231] has joined #bitcoin-core-dev
06:43 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
06:44 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Client Quit]
06:45 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
06:52 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has quit [Ping timeout: 245 seconds]
06:57 -!- jtimon [~quassel@90.166.158.146.dynamic.jazztel.es] has joined #bitcoin-core-dev
07:00 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Quit: The Lounge - https://thelounge.chat]
07:01 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
07:04 -!- sanketh [sid461832@gateway/web/irccloud.com/x-qyuwndufvvdayrxr] has left #bitcoin-core-dev []
07:07 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
07:11 -!- awesome_doge [~Thunderbi@1-164-239-176.dynamic-ip.hinet.net] has quit [Ping timeout: 265 seconds]
07:35 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has quit [Quit: scedastik]
07:38 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
07:39 -!- jespada [~jespada@90.254.243.187] has quit [Ping timeout: 276 seconds]
07:41 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
07:42 < wumpus2> re: the "extreme rare github security issue" you might want to check https://github.com/settings/security-log that nothing weird has been done with your account, it doesn't show all events (like pushes) unfortunately
07:47 < jonatack> good idea. "Logged in - Unknown location"... goooood
07:52 -!- wumpus2 is now known as wumpus
07:54 -!- JucaChavesFlamen [8717734b@135-23-115-75.cpe.pppoe.ca] has joined #bitcoin-core-dev
07:56 -!- andytosh1 is now known as andytoshi
07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
07:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
08:01 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
08:04 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-dev
08:11 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
08:24 < ariard> #19160 is pretty mature but still needs more reviewers :)
08:24 < gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
08:27 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
08:28 < jonatack> ariard: indeed. it's on my list (sorry for the delay)
08:28 -!- shefsam [6c5e4ec5@108-94-78-197.lightspeed.miamfl.sbcglobal.net] has joined #bitcoin-core-dev
08:31 < shefsam> Where can I discuss a hacked Bitcoin Core Wallet? I recently opened my wallet after months if not years to find the last transaction - not mine and sweeping the entirety of my balance to an outside address I do not know.
08:37 < wumpus> i also intend to look at the multiprocess stuff but haven't got around to it yet
08:38 -!- JucaChavesFlamen [8717734b@135-23-115-75.cpe.pppoe.ca] has quit [Quit: Connection closed]
08:54 -!- belcher_ is now known as belcher
08:58 -!- crazypython38 [627aa476@98.122.164.118] has joined #bitcoin-core-dev
09:08 -!- crazypython38 [627aa476@98.122.164.118] has quit [Quit: Connection closed]
09:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
09:18 -!- Artea_ [~Lufia@artea.com.pt] has left #bitcoin-core-dev []
09:18 -!- Artea [~Lufia@artea.com.pt] has joined #bitcoin-core-dev
09:18 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
09:20 -!- smctwo [~smctwo@94.204.225.231] has quit [Remote host closed the connection]
09:20 -!- smctwo [~smctwo@94.204.225.231] has joined #bitcoin-core-dev
09:21 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
09:21 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Quit: The Lounge - https://thelounge.chat]
09:23 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca00c143e0318365b648.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:25 -!- smctwo [~smctwo@94.204.225.231] has quit [Ping timeout: 276 seconds]
09:31 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
09:34 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Client Quit]
09:34 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
09:35 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 276 seconds]
09:36 -!- sr_gi1 [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Client Quit]
09:36 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
09:41 -!- jonatack [~jon@37.167.192.44] has joined #bitcoin-core-dev
09:50 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: setpill]
09:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:56 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #21398: doc: Update fuzzing docs for afl-clang-lto (master...2103-docFuzzAflPlusPlus) https://github.com/bitcoin/bitcoin/pull/21398
09:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:56 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
09:59 -!- lightlike [~lightlike@p200300c7ef188100a44b6800926d040e.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:23 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
10:24 < jonatack> vasild: good find! https://github.com/bitcoin/bitcoin/issues/11537
10:36 -!- shefsam [6c5e4ec5@108-94-78-197.lightspeed.miamfl.sbcglobal.net] has quit [Quit: Connection closed]
10:37 -!- jonatack_ [~jon@37.167.192.44] has joined #bitcoin-core-dev
10:37 -!- jonatack [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:40 -!- jonatack_ [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:41 -!- jonatack_ [~jon@37.167.192.44] has joined #bitcoin-core-dev
10:41 -!- jonatack_ [~jon@37.167.192.44] has quit [Client Quit]
10:42 -!- jonatack [~jon@37.167.192.44] has joined #bitcoin-core-dev
10:51 -!- justin [~justin@2605:a601:a0ca:2e00:4d1a:a05a:6265:94e8] has joined #bitcoin-core-dev
10:52 -!- justin is now known as Guest77068
10:57 -!- jungly [~jungly@host-79-19-187-19.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds]
11:00 -!- proofofkeags [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
11:13 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 246 seconds]
11:16 -!- RandolfR [~randolf@184.70.10.188] has quit [Quit: Leaving]
11:19 -!- jonatack [~jon@37.167.192.44] has joined #bitcoin-core-dev
11:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
11:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
11:52 -!- ovovo [~ovovo@179.43.152.50] has joined #bitcoin-core-dev
11:52 -!- ovovo [~ovovo@179.43.152.50] has quit [Changing host]
11:52 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
11:54 -!- stortz [c8b9cbcf@200.185.203.207] has joined #bitcoin-core-dev
11:54 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds]
12:20 -!- stortz [c8b9cbcf@200.185.203.207] has quit [Quit: Connection closed]
12:27 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:42 -!- smctwo [~smctwo@86.98.5.100] has quit [Remote host closed the connection]
12:43 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
12:44 -!- smctwo [~smctwo@86.98.5.100] has quit [Remote host closed the connection]
12:45 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
12:46 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
12:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:47 < bitcoin-git> [bitcoin] luke-jr opened pull request #21399: Genericide BIP9 in variable/type names and comments (master...vbits_rename) https://github.com/bitcoin/bitcoin/pull/21399
12:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:52 < jnewbery> Hi folks. We'll start the p2p meeting in 10 minutes.
12:57 < jnewbery> Feel free to update your priorities in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
12:57 -!- JokerAscensionEx [~egp_@2.95.74.168] has quit [Read error: Connection reset by peer]
13:00 < jnewbery> #startmeeting
13:00 < core-meetingbot> Meeting started Tue Mar  9 21:00:11 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
13:00 < core-meetingbot> Available commands: action commands idea info link nick
13:00 < jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik 
13:00 < jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
13:00 -!- realname192 [~real@37.162.43.185] has joined #bitcoin-core-dev
13:00 < amiti> hi
13:00 < hebasto> hi
13:00 < gleb> hi
13:00 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
13:00 < ariard> hi
13:00 < emzy> hi
13:00 < aj> hi
13:00 < ajonas> hello
13:01 < jnewbery> topics are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings
13:01 < jnewbery> contributors' current priorities are here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
13:01 -!- JokerAscensionEx [~egp_@2.95.74.168] has joined #bitcoin-core-dev
13:01 < jnewbery> There's one proposed topic this week: Erlay (gleb). Before we do that, does anyone have any other proposed topics or short updates?
13:01 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
13:02 < aj> would be interested in an update on disabletx and the thread on -dev about it
13:02 < ajonas> I have a something i put together addrman and eclipse attacks (not quite a full topic)
13:02 < fjahr> hi
13:02 < ajonas> it should only take a couple of minutes
13:02 < jnewbery> aj: yep, we can do that
13:03 < jnewbery> ajonas: ok, if it's quick let's do that first
13:03 < jnewbery> #topic addrman and eclipse attacks (ajonas)
13:03 < core-meetingbot> topic: addrman and eclipse attacks (ajonas)
13:03 < ajonas> This is a doc I put on the wiki: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Addrman-and-eclipse-attacks
13:03 < ajonas> feedback would be appreciated
13:03 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
13:04 < ajonas> Thank you to those that helped track down the details and reviewed
13:04 < ajonas> fin
13:04 < jnewbery> thanks ajonas!
13:04 < jnewbery> any questions or should we move on to the next topic?
13:04 < ariard> ajonas: consider those papers https://www.comp.nus.edu.sg/~kangms/papers/erebus-attack.pdf and https://btc-hijack.ethz.ch/files/btc_hijack.pdf on infrastructure-level eclipse attacks against bitcoin nodes
13:05 < gleb> pretty sure the former one is included
13:05 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
13:06 < ariard> right it mentipns asmap which is only one of the mitigation proposed in erebeus paper iirc
13:06 < ariard> (but better to do feedback after meeting, let's mov on)
13:07 < jnewbery> next topic?
13:07 < jnewbery> #topic erlay (gleb)
13:07 < core-meetingbot> topic: erlay (gleb)
13:07 < gleb> Hi! Just a little update here. I was working on Erlay refactor in a separate branch, currently addressing great comments from jnewbery and ariard. Gonna finish that in a day or two.
13:08 < gleb> jnewbery: perhaps we'll invite everyone to full review again, after you give a quick skim of the high-level encapsulation approach etc in couple days?
13:08 < gleb> or i should just do it once im done, if you think it's good enough?
13:09 < gleb> just trying to make review more focused and optimize efforts
13:09 < phantomcircuit> HELLO
13:09 < jnewbery> gleb: I've left my comments. I don't think you need to wait for another round from me before opening a PR for the new branch.
13:10 < phantomcircuit> jnewbery, i'd like to talk about #21106 today as well
13:10 < gribble> https://github.com/bitcoin/bitcoin/issues/21106 | persist IBD latch across restarts by pstratem · Pull Request #21106 · bitcoin/bitcoin · GitHub
13:10 < gleb> jnewbery: alright, thank you. that's the plan then
13:10 < gleb> im done :)
13:11 < jnewbery> phantomcircuit: sounds good. Thanks
13:11 < jnewbery> any questions about erlay before the next topic?
13:11 < sipa_> hi
13:11 -!- sipa_ is now known as sipa
13:12 < jnewbery> #topic update on disabletx (aj)
13:12 < core-meetingbot> topic: update on disabletx (aj)
13:13 < aj> jnewbery's post makes sense to me -- that we can use frelay and avoid needing disabletx; but i don't understand ariard's response; and see suhas has updated the pr some more
13:14 < amiti> +1
13:15 < jnewbery> aj: did you read the log from the general bitcoin core irc meeting last week? There was quite a lot of discussion about using a -blocksonly node and occasionally sending txs from it
13:16 < aj> jnewbery: i did, but as i understand it we can cope with that via fRelay fine
13:17 < jnewbery> I hadn't thought about it any more since then, but I wasn't sure if we could cope with that via fRelay
13:18 < ariard> aj: my point was bip37 original scope was unclear if it concerns only inv(tx) or any tx-related message, bip338 has the merit to clarify
13:18 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Ping timeout: 268 seconds]
13:18 < jnewbery> the scenario is that you have a border node, and then a core node that only connects to that border node, and is -blocksonly. You want to be able to send txs from the core node to the border node. If we disallowed tx relay based on fRelay=false, then that wouldn't work(?)
13:18 < aj> jnewbery: hmm, i think what i specced out in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018526.html is self-consistent and works with -blocksonly sensibly, can't guarantee it's properly backwards compatible (didn't look hard enough)
13:19 < aj> jnewbery: it differentiates tx's based on direction -- ie if i say fRelay=false, you won't send txs to me, but i might send the to you
13:20 < jnewbery> txRelay isn't required for receiving txs?
13:20 < jnewbery> if that's the case, then I think I agree with you, but need to think about it some more
13:20 < aj> txrelay isn't required for receiving i think, just trequest.cpp
13:20 < aj> trequest.cpp
13:20 < aj> gah
13:20 < aj> txrequest.cpp
13:21 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
13:21 < jnewbery> aj: yes, I think you're right
13:21 < amiti> some small changes are needed to support, but yeah, we don't need the whole txrelay struct to receive  
13:22 -!- smctwo [~smctwo@86.98.5.100] has quit [Remote host closed the connection]
13:22 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
13:23 < aj> ariard: i think bip 37 without bip 111 (the service bit) is pretty dead? bip 60 seems to match what i described above
13:24 < jnewbery> aj: I agree
13:24 < aj> ariard: if you advertise the bloom service bit, then i think you just treat that as no possibility of being lightweight, and everything works fine; and obv if you don't advertise the service bit, you already kill the connection if they try doing bloom stuff to you
13:25 < jnewbery> (I've pinged sdaftuar, since he's probably interested in this)
13:25 < sdaftuar> hi, sorry i'm late to the discussion. i don't understand why we'd go to these contortions to avoid a new p2p message, but if someone is interested in implementing this a different way, please feel free
13:26 < aj> sdaftuar: i think it should not end up that twisted fwiw
13:26 < ariard> aj: bip 60 "Whether the remote peer should announce relayed transactions or not" is a bip-60 compliant client allows to send TX messages after receiving `fRelay=false`
13:26 < aj> ariard: i don't follow what you said?
13:27 < jeremyrubin> sdaftuar: don't we only have 8e28 possible p2p messages?
13:28 < sipa> i think fewer p2p messages with meanings that differ slightly across versions is slightly worse than separate ones with clear well defined meaning :)
13:28 < aj> ariard: I run a -blocksonly node. You run a bip60 compliant node. I tell you fRelay=false. You don't send me any txes. You told me fRelay=true. Therefore I can send you a tx, without violating bip60.
13:30 < ariard> aj: that's my point the "You don't send me any txes" isn't clearly documented in the bip, a naive implementation of bip 60 could try to send raw, unannounced TX messages
13:31 < ariard> and don't understand why the connection is severed
13:32 < sipa> if you're going by reading the spec by the letter... what does bip60"s fRelay flag even mean for a client that chooses not.to implement bip37?
13:32 -!- stortz [c8b9cbcf@200.185.203.207] has joined #bitcoin-core-dev
13:32 < amiti> I'd like explicit p2p messages with clear meanings, but what I don't like about the current disabletx proposal is the implicit disabling of addrs. I understand the hesitation to want to have a better understanding of addr relay before implementing a new protocol message, but I think that having disabletx implicitly disable addrs would make it harder for us to have clear, explicit messages about relay in the 
13:32 < amiti> long-term. so that makes me more inclined to use what we have, since it suffices
13:32 < aj> ariard: it's always the sender's choice to not send a tx?
13:33 < ariard> aj: right but imo current bip60 semantic isn't clear with what the sender is allowed to do
13:34 < sipa> aj: i think ariard is trying to point out that bip37/bip60 only talk about *announcing* transactions, not sending (possibly unannounced) transactions
13:34 -!- realname192 [~real@37.162.43.185] has quit [Remote host closed the connection]
13:35 < sipa> amiti: i think that's fair... i also don't really know what the issue would be with a sendaddrtypes message with a bitvector of bip155 network types for example (apart from not wanting to deal with that too right now)
13:35 < aj> sipa: ie, if I say fRelay=false, ariard shouldn't send me INVs but perhaps should reply to a GETDATA with a TX?
13:36 < ariard> yes that's it, and sending unannounced transactions is tolerated behavior for now
13:36 < sipa> aj: maybe, or maybe he could still send you an unannounced transaction
13:37 < aj> ariard: hmm. i wouldnt tolerate a TX message from you if i'd connected to you as a block-relay-only peer
13:39 < jnewbery> ok, next topic?
13:39 < aj> anyway, should we let phantomcircuit have the floor?
13:39 < jnewbery> thanks aj
13:40 < jnewbery> #topic IBD latch across restarts (phantomcircuit)
13:40 < core-meetingbot> topic: IBD latch across restarts (phantomcircuit)
13:40 < ariard> aj: how I know I'm a block-relay-only peer ? e.g what the exact scope of "block-relay-only"?
13:40 < ariard> but yeah let's move on
13:40 < phantomcircuit> eh hem
13:41 < phantomcircuit> after discussing this with a number of people sipa and sdaftuar especially i think the better approach to a network event that latches all of the listening peers into ibd is simply to make the headers sync peer selection algorithm looser at intervals since we made progress on getting out of ibd
13:41 < phantomcircuit> that more directly addresses the issue
13:42 < sipa> phantomcircuit: did you see sdaftuar last's response where he suspects the issue is block fetching, not header syncinf?
13:42 < phantomcircuit> (can also serve headers when we're past the chains minimum work regardless of ibd)
13:43 < phantomcircuit> sipa, yes, we discussed it here, he missed that compact blocks received will not trigger a getheaders when we're in ibd
13:43 < sipa> ah
13:44 < sipa> so what precisely do you propose to address this?
13:45 < phantomcircuit> if we haven't made progress on headers sync in at least INTERVAL time simply request headers from all peers
13:45 < phantomcircuit> im sure there's more nuisanced solutions that could be employed but that's the most direct to prevent the issue
13:46 < gleb> is there a summary of the issue and this discussion anywhere? I find it difficult to follow without prior context
13:46 < sipa> #21106
13:46 < gribble> https://github.com/bitcoin/bitcoin/issues/21106 | persist IBD latch across restarts by pstratem · Pull Request #21106 · bitcoin/bitcoin · GitHub
13:46 < gleb> thanks
13:47 < jnewbery> phantomcircuit: The scenario that you're trying to address (all or most of the listening nodes are restarted) seems like it'd always need some kind of manual intervention.
13:47 < aj> this was the recent dogecoin network failure more or less?
13:47 < emzy> I think so.
13:48 < phantomcircuit> jnewbery, sure, lets say there's a crash bug, which has existed in the past
13:48 -!- jtimon [~quassel@90.166.158.146.dynamic.jazztel.es] has quit [Remote host closed the connection]
13:49 < sipa> aj: yes
13:49 < phantomcircuit> i'll note that what i describe in the pr has happened on an altcoin derived from the bitcoin codebase and is relatively recently backported so it's not ancient nonsense
13:49 -!- smctwo [~smctwo@86.98.5.100] has quit [Remote host closed the connection]
13:50 < sipa> 0.14 iirc
13:50 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
13:50 < aj> phantomcircuit: (nuanced, not nuisanced :)
13:50 < aj> header polling sure sounds better than perma-latching !IBD to me?
13:51 < sipa> phantomcircuit: given that the dont-ask-headers-from-everyone is purely a bandwidth-preservation heuristic, i think it makes perfect sense to disable/weaken it in cases where we're worrying about being unable to sync
13:52 < jnewbery> it's really difficult to follow the PR to be honest. I
13:52 < jnewbery> I'm not surprised that people are confused
13:52 < sipa> ignore the code in the PR, it's just the discussion there that matters
13:52 < jnewbery> there seem to have been several different approaches, and then comments left and later deleted
13:52 < sipa> the code will be very different once it's hammered out
13:53 < sipa> phantomcircuit, sdaftuar: would it be possible to just post a summary/update of your understanding of what should be addressed?
13:54 < jnewbery> that seems like a sensible next step
13:55 < sipa> because it seems there has been some progress on IRC that's not mentioned there
13:55 -!- smctwo [~smctwo@86.98.5.100] has quit [Ping timeout: 264 seconds]
13:55 < phantomcircuit> aj, English is hard
13:56 < aj> phantomcircuit: nuance is often a nuisance, to be fair
13:56 < sipa> but in any case, if there's reasonable evidence that all we need to do is making headers syncing less restrictive, i think weakening just that in case we haven't found new headers in a while seems like a reasonable approach
13:56 < phantomcircuit> sipa, it's a little confusing, since there's a bunch of things that are potentially separately contributing to the issue
13:56 < sipa> aj: that's a pretty unnuanced statement
13:57 < jnewbery> ok, anyone have any final updates before we close the meeting?
13:57 < phantomcircuit> sipa, i think relaxing the headers sync peer selection combined with serving headers if we're past minwork would get us a long way, but we ban peers for sending headers which are below out minwork and the minwork goes up overtime, so old peers that are restarted could get banned
13:59 < sipa> phantomcircuit: but the banning is only for headers pre-last-checkpoint, which is ancient
13:59 < sipa> and if clients are introduce a new checkpoint that'd need huge scrutiny anyway
14:00 < sipa> so maybe that's not crazy to assume that any minpeerwork is going to be past any-reasonable-client's checkpoints
14:00 < jnewbery> #endmeeting
14:00 < core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
14:00 < core-meetingbot> Meeting ended Tue Mar  9 22:00:43 2021 UTC.  
14:00 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-03-09-21.00.moin.txt
14:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:02 < bitcoin-git> [bitcoin] hebasto opened pull request #21400: build, qt: Fix regression introduced in #21363 (master...210309-regression) https://github.com/bitcoin/bitcoin/pull/21400
14:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:05 < aj> ariard: you have no way of knowing you're a block-relay-only peer, apart from me setting fRelay=false
14:07 < aj> ariard: (which could also mean i'm running with -blocksonly=true and, if you sent NODE_BLOOM, that i want to do bloom stuf later)
14:08 < phantomcircuit> sipa, right so that's less dangerous
14:11 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:15 -!- stortz [c8b9cbcf@200.185.203.207] has quit [Quit: Connection closed]
14:19 < sdaftuar> sorry i missed most of the meeting, had to step away
14:19 < sdaftuar> phantomcircuit: headers sync is insufficient to solve the problem
14:20 < sdaftuar> the biggest issue is that we don't call FindNextBlocksToDownload on inbound peers if we have outbound peers and we're in IBD
14:21 < sdaftuar> if we relaxed that, i believe it would completely solve the problem. the issue you spotted with compact blocks shoulnd't be relevant, because we don't send a peer a block announcement via compact block unless they ask for it
14:21 < sdaftuar> and we don't turn on compact block announcements on any of our peers until we're out of IBD
14:22 < sdaftuar> that said, we could also loosen up headers sync with inbound peers anyway (in my model of how we get out of a situation like this, you have to wait for a block to be found; by syncing with inbound peers more aggressively than we do now you could shorten that window)
14:22 < sdaftuar> but it's not enough to just treat this as a headers sync issue -- we have to fix the block fetching
14:22 -!- ogo [~ogo@gateway/tor-sasl/ogo] has quit [Ping timeout: 268 seconds]
14:37 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
14:51 < lightlike> aj: "you have no way of knowing you're a block-relay-only peer (...)" - wouldn't we still send FEEFILTER while running -blocksonly=true, but never on a block-relay-only connection (because m_tx_relay==null)?
15:04 < phantomcircuit> sdaftuar, that's probably *also* something that's wrong, but what i see is that you can't get the headers first anyways
15:05 -!- scedastik [~scedastik@c-68-58-168-96.hsd1.mi.comcast.net] has quit [Quit: scedastik]
15:16 < sdaftuar> phantomcircuit: do you have a mechanism for how a compact block could be delivered when headers haven't yet synced?
15:16 < sdaftuar> (and while the node is in ibd)
15:16 < phantomcircuit> sdaftuar, i meant the headers sync is broken in the other way
15:17 < phantomcircuit> this is why it's so confusing, there's a bunch of different things which when in ibd might be the issue, but the only one i could observe is that no peer i could connect to and asked would give me headers
15:19 < sdaftuar> my understanding is that at some point after an inbound peer connects to you (while you're in ibd), it should announce a new block
15:19 < sdaftuar> at that point, that announcement will have to be via INV, and it will trigger headers sync
15:20 < sdaftuar> however, due to the block fetching being broken as i described before, you'll be in the stuck state you observed
15:20 < sdaftuar> i can't see a way for compact block relay to even start until you leave IBD so i think that's a completely separate issue
15:21 < sdaftuar> of course if no blocks are found after that peer connects, then indeed you would never even get the chain they have
15:22 < sdaftuar> but i don't think that's the root issue here?  you're concerned with inbound peers being your only bridge to the honest network, and making sure you eventually sync, i think
15:33 < phantomcircuit> sdaftuar, right the gets to the other issue that i forgot about, we don't announce our address while in ibd, so starting a new listening peer you won't get inbound connections anyways
15:33 < phantomcircuit> i forgot about that one
15:34 < sdaftuar> don't we immediately push our address to our outbound peers when we initiate a connection, right at the end of ver/verack?
15:35 < sdaftuar> oh, that is gated on IBD, i see
15:36 < sdaftuar> still i don't think that's really a relevant concern here. we're just trying to make block sync work from an inbound peer i think?
15:38 < sdaftuar> we could probably get rid of the addr relay gating stuff. i think the motivation is that we don't want peers to connect to us if we can't help them sync blocks, but given that good addr propagation takes much longer than block sync should, we should probably just announce our address always i think
15:38 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 268 seconds]
15:39 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
15:39 < sdaftuar> i think a long time ago a peer that never responded to headers and never provided blocks could dos a bitcoin core node, but now that we time out an outbound peer that doesn't sync headers with us when we're looking for headers, this shouldn't be a big concern
15:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:44 < bitcoin-git> [bitcoin] achow101 opened pull request #21401: Refactor versionbits deployments to avoid potential uninitialized variables (master...encap-vbits-params) https://github.com/bitcoin/bitcoin/pull/21401
15:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:44 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
15:45 < phantomcircuit> sdaftuar, possibly? im not sure if that was eclipse related maybe sipa knows
15:46 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 246 seconds]
15:48 < phantomcircuit> sdaftuar, for sure you won't get any inbound until you have finished ibd though
15:50 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
15:50 -!- smctwo [~smctwo@86.98.5.100] has quit [Remote host closed the connection]
15:50 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
15:51 < sdaftuar> phantomcircuit: have i managed to convince you that block fetching is all that we need to fix?  if you have some scenario in mind where that would be insufficient, i'd like to try to understand what that is
15:55 -!- smctwo [~smctwo@86.98.5.100] has quit [Ping timeout: 245 seconds]
15:55 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
16:02 < phantomcircuit> sdaftuar, sort of, if you have inbound connections from a peer that is itself in sync and announcing blocks then you will get headers, but won't call FindNextBlocksToDownload and thus won't get blocks
16:02 < phantomcircuit> but if you're a listening node in ibd then you don't announce your address so you won't get inbound connections at all
16:03 < phantomcircuit> seems like there's a number of things that should be changed but im unsure of why they're all restricted in the first place
16:03 < phantomcircuit> well the bad headers one i am, but the no address relay im not
16:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:04 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ee0dc02c6f93...bca5ee6f38f0
16:04 < bitcoin-git> bitcoin/master ffdd7de Hennadii Stepanov: build, qt: Fix regression introduced in #21363
16:04 < bitcoin-git> bitcoin/master bca5ee6 fanquake: Merge #21400: build: Fix regression introduced in #21363
16:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:05 < bitcoin-git> [bitcoin] fanquake merged pull request #21400: build: Fix regression introduced in #21363 (master...210309-regression) https://github.com/bitcoin/bitcoin/pull/21400
16:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:21 < sdaftuar> if you're a listening node in ibd, getting incoming connections doesn't really help you much? really what you want is to find a node that has the honest chain. since the way you bootstrap yourself is by relaying your address to outbound peers and hoping that other people get it, you're implicitly assuming the network graph is already connected
16:21 < sdaftuar> so i think it's sufficient for our purposes to just fix relay at the local level, and we can extrapolate out that the network will avoid getting stuck as a result
16:24 < phantomcircuit> sdaftuar, if you're a listening node in ibd and you get an inbound connection and that inbound connection broadcasts a block then you will send the getheaders to that peer which will trigger the full headers sync logic from that peer
16:24 < sdaftuar> right, agreed
16:24 < phantomcircuit> but then you won't request blocks from them and you'll still be screwed, but marginally less screwed
16:24 < sdaftuar> also agreed
16:24 < sdaftuar> so we should fix that
16:25 < phantomcircuit> yes, we should *also* fix that
16:25 < phantomcircuit> but we need to broadcast our address to outbound peers in the first place to get any inbound
16:25 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
16:25 < sdaftuar> while i don't think that harms anything, for the reasons i gave above, i think that is a minor consideration
16:26 < sdaftuar> look at it this way - the miner who produced that block presumably made outbound connections to the network
16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:26 < phantomcircuit> thinking about it that might have been why i was able to just rig IBD=false and have my node sync, i instantly got hundreds of inbound connections
16:26 < aj> can you make it so that you start broadcasting your address once you're tip is >= all your outbound peers' tips?
16:26 < sdaftuar> as long as that miner's blocks propagate one hop, we should be able to reason that the blocks will propagate to the rest of the network
16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:26 < sdaftuar> or else nothing we do will work, if the network is partitioned
16:28 < sdaftuar> aj: using the block count they give us in their version message?
16:29 < sdaftuar> aj: i think that's more complicated than it needs to be.  it should be okay by now to just always advertise ourselves, i think
16:29 < sdaftuar> because peers have logic to disconnect nodes that aren't keeping up 
16:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:31 < sdaftuar> phantomcircuit: i would hesitate to try to learn too many lessons about addr relay in Bitcoin based on observations on altcoins
16:31 < sdaftuar> my perspective for now at least is that the heuristics we use mostly seem to work, but whether they work on vastly different looking network graphs is totally unclear
16:32 < sdaftuar> (mostly an aside, i think the gating of addr relay on IBD is not too significant either way)
16:33 < aj> sdaftuar: yeah, i guess block count would be fine as a heuristic. probably right that advertising all the time is fine though
16:34 < phantomcircuit> sdaftuar, well for sure if we don't advertise our address we're unlikely to get inbound connections
16:36 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
16:38 < sdaftuar> phantomcircuit: of course. i think that is solving a distinctly different problem than block sync not working, and its worth noting that fixing block sync causes nodes to leave IBD, which mitigates these other IBD-related issues
16:38 < sdaftuar> that said i'm all in favor of pulling out the IBD gating wherever we don't need it
16:42 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 245 seconds]
16:50 -!- LRSN [d41dd2e6@212.29.210.230] has joined #bitcoin-core-dev
16:54 < phantomcircuit> sdaftuar, actually it looks like we might? call FindNextBlocksToDownload
16:54 < phantomcircuit> (fFetch && !pto->m_limited_node) || !::ChainstateActive().IsInitialBlockDownload()
16:55 < phantomcircuit> fFetch is the 'nice' node logic
16:57 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
16:58 -!- zivl [~zivl@unaffiliated/zivl] has quit [Client Quit]
17:01 < sdaftuar> fFetch will be false for inbound peers, if you have any outbound peers
17:05 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 276 seconds]
17:06 < sipa> indeed
17:06 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-dev
17:08 -!- lightlike [~lightlike@p200300c7ef188100a44b6800926d040e.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
17:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:15 < bitcoin-git> [gui] jarolrod opened pull request #243: qt: fix issue when disabling the auto-enabled blank wallet checkbox (master...create-wallet) https://github.com/bitcoin-core/gui/pull/243
17:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:15 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
17:18 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
17:19 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 264 seconds]
17:21 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-dev
17:23 -!- Artea [~Lufia@artea.com.pt] has quit [Ping timeout: 260 seconds]
17:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:24 < bitcoin-git> [bitcoin] sdaftuar closed pull request #20726: p2p: Add DISABLETX message for negotiating block-relay-only connections (master...2020-12-negotiate-block-relay) https://github.com/bitcoin/bitcoin/pull/20726
17:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:30 < sipa> sdaftuar: :(
17:34 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 264 seconds]
17:34 < phantomcircuit> sdaftuar, indeed
17:39 -!- Netsplit *.net <-> *.split quits: robert_spigler
17:39 -!- maop [~maop@37.120.211.188] has quit [Remote host closed the connection]
17:40 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
17:40 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
17:40 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
17:45 -!- Guest77068 [~justin@2605:a601:a0ca:2e00:4d1a:a05a:6265:94e8] has quit [Quit: Leaving]
17:46 -!- justin [~justin@2605:a601:a0ca:2e00:4d1a:a05a:6265:94e8] has joined #bitcoin-core-dev
17:46 -!- justin is now known as Guest43272
17:51 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
17:56 -!- smctwo [~smctwo@86.98.5.100] has quit [Ping timeout: 276 seconds]
17:58 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:02 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-fqzdcayiqboawwcs] has joined #bitcoin-core-dev
18:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
18:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
18:23 -!- awesome_doge [~Thunderbi@2001-b011-4010-3ce4-30e6-360b-d3b0-71b5.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev
18:23 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
18:24 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
18:24 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:26 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 245 seconds]
18:30 -!- awesome_doge [~Thunderbi@2001-b011-4010-3ce4-30e6-360b-d3b0-71b5.dynamic-ip6.hinet.net] has quit [Ping timeout: 260 seconds]
18:33 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
18:34 -!- dermoth [~dermoth@unaffiliated/dermoth] has quit [Ping timeout: 265 seconds]
18:35 -!- dermoth [~dermoth@unaffiliated/dermoth] has joined #bitcoin-core-dev
18:41 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
18:51 -!- tvn [~tvn@37.120.211.188] has joined #bitcoin-core-dev
18:52 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 268 seconds]
18:58 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-dev
18:58 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
18:58 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
19:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
19:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:42 -!- jespada [~jespada@90.254.243.187] has quit [Ping timeout: 265 seconds]
19:44 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
19:52 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
19:57 -!- smctwo [~smctwo@86.98.5.100] has quit [Ping timeout: 264 seconds]
20:00 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
20:02 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 260 seconds]
20:03 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
20:05 -!- awesome_doge [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-dev
20:07 -!- jesseposner [~jp@2601:645:200:162f:d38:a5c2:980:75b0] has quit [Remote host closed the connection]
20:08 -!- jesseposner [~jp@2601:645:200:162f:d38:a5c2:980:75b0] has joined #bitcoin-core-dev
20:09 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
20:10 -!- LRSN [d41dd2e6@212.29.210.230] has quit [Quit: Connection closed]
20:25 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
20:25 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
20:26 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
20:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:47 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:57 -!- jasonzhouu [~jasonzhou@112.10.159.239] has left #bitcoin-core-dev []
20:57 -!- jasonzhouu [~jasonzhou@112.10.159.239] has joined #bitcoin-core-dev
21:12 -!- smctwo [~smctwo@86.98.5.100] has joined #bitcoin-core-dev
21:17 -!- smctwo [~smctwo@86.98.5.100] has quit [Ping timeout: 265 seconds]
21:29 < shesek> do you think that regularly polling `getblockchaininfo` (say, every 5 seconds) to track syncing progress could have a noticeable effect on syncing times? it appears that it needs to lock cs_main
21:34 < sipa> it does, but i don't think it will affect sync progress
21:35 < sipa> it'll just block while it can't grab the lock, but that won't interfere with actual syncing
21:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
21:40 -!- roconnor [~roconnor@host-45-58-192-182.dyn.295.ca] has quit [Remote host closed the connection]
21:41 -!- roconnor [~roconnor@host-45-58-192-182.dyn.295.ca] has joined #bitcoin-core-dev
21:43 < shesek> sipa, thanks for clarifying
21:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
21:50 < phantomcircuit> shesek, getbestblockhash is a better target to see if you need to call getblockchaininfo
21:52 < shesek> phantomcircuit, this is to display progress to the user, I'm polling getblockchaininfo until headers==blocks && !ibd
21:56 < phantomcircuit> shesek, ah ok
22:01 < shesek> has a pruneuntil=<height/time> config option been discussed before?
22:01 < shesek> one currently has to start syncing, wait until the chain is indexed sufficiently, then issue `pruneblockchain`. it would be nice if this could be configured from the get-go without ongoing interaction, and also if it could prune before the height is reached to keep the peak disk usage down
22:02 < luke-jr> shesek: you could accomplish that with prune locks
22:03 < luke-jr> #19463
22:03 < gribble> https://github.com/bitcoin/bitcoin/issues/19463 | Prune locks by luke-jr · Pull Request #19463 · bitcoin/bitcoin · GitHub
22:03 < luke-jr> also related #20827
22:03 < gribble> https://github.com/bitcoin/bitcoin/issues/20827 | During IBD, prune as much as possible until we get close to where we will eventually keep blocks by luke-jr · Pull Request #20827 · bitcoin/bitcoin · GitHub
22:06 -!- smctwo [~smctwo@94.204.225.231] has joined #bitcoin-core-dev
22:06 < shesek> nice, they both seem pretty useful
22:06 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
22:07 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #bitcoin-core-dev
22:10 < shesek> I think that users would typically want to specify a timestamp though, while prune locks works in terms of block heights
22:10 < sipa> i don't understand why you'd want a timestamp?
22:10 < shesek> it is possible to somehow ask bitcoind for the height around some timestamp?
22:10 -!- smctwo [~smctwo@94.204.225.231] has quit [Ping timeout: 246 seconds]
22:12 < shesek> sipa, I want to let users choose how much unpruned data they want to save to enable wallet rescans, they'll typically be thinking about this in terms of a date rather than height
22:13 < sipa> ah, ok
22:14 < shesek> I made bitcoin wallet tracker support both, users can either `--prune-until 2021-03-10` or `--prune-until 673960` (this is with trying `pruneblockchain` repeatedly until it doesn't fail)
22:15 < shesek> could this have a negative effect on syncing times, btw? `pruneblockchain` also has to scan headers to translate the timestamp into an height
22:17 < luke-jr> shesek: well, the idea is that when you make a new backup, you'd update the prune lock for that wallet's backup
22:17 < luke-jr> shesek: so it won't prune until all your wallets have a backup recent enough
22:17 < luke-jr> and if a reorg occurs, it will shift backward prune lock start heights
22:17 < luke-jr> so in theory, this should avoid pruning ever pruning too much
22:19 < shesek> this is also about enabling the future possibility of doing wallet rescans, say a user could choose to keep around everything since '18, when they first joined bitcoin, so it'll cover all their wallets for sure
22:23 < shesek> basically just trying to offer some middleground between not being able to rescan at all and keeping everything
22:27 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
22:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:33 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bca5ee6f38f0...ceb6df391f28
22:33 < bitcoin-git> bitcoin/master fad0ae6 MarcoFalke: doc: Rename fuzz seed_dir to corpus_dir
22:33 < bitcoin-git> bitcoin/master ceb6df3 MarcoFalke: Merge #21388: doc: Rename fuzz seed_dir to corpus_dir
22:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:33 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21388:  doc: Rename fuzz seed_dir to corpus_dir  (master...2103-docInputDir) https://github.com/bitcoin/bitcoin/pull/21388
22:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:46 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit []
22:47 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
22:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:57 < bitcoin-git> [bitcoin] fanquake opened pull request #21403: build: set --build when configuring packages in depends (master...explicitly_set_depends_build) https://github.com/bitcoin/bitcoin/pull/21403
22:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:01 -!- talbtcha [58e26d9d@88.226.109.157] has joined #bitcoin-core-dev
23:07 -!- T73 [6d4000ac@bzq-109-64-0-172.red.bezeqint.net] has joined #bitcoin-core-dev
23:08 -!- T73 [6d4000ac@bzq-109-64-0-172.red.bezeqint.net] has quit [Client Quit]
23:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:26 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/ceb6df391f28...eea6196c3d80
23:26 < bitcoin-git> bitcoin/master 4866934 fanquake: rpc: remove calls to CWallet.get()
23:26 < bitcoin-git> bitcoin/master 7c90c67 fanquake: rpc: refactor rpc wallet functions to take references instead of pointers
23:26 < bitcoin-git> bitcoin/master eea6196 MarcoFalke: Merge #21331: rpc: replace wallet raw pointers with references (#18592 reb...
23:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:26 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21331: rpc: replace wallet raw pointers with references (#18592 rebased) (master...18592_rebased) https://github.com/bitcoin/bitcoin/pull/21331
23:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:37 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:42 -!- jungly [~jungly@host-79-55-185-171.retail.telecomitalia.it] has joined #bitcoin-core-dev
23:53 -!- rex4539_ [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
23:56 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Ping timeout: 268 seconds]
23:57 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
23:58 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
--- Log closed Wed Mar 10 00:00:53 2021