--- Log opened Tue Jan 12 00:00:13 2021
00:00 -!- Anne_ [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Remote host closed the connection]
00:04 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in]
00:05 < aj> fanquake: err, how does changing the ldadd order in #19937 possibly fix things?? what is going on??
00:05 < gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
00:06 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
00:06 < aj> oh libs have to be in order in general apparently? geez. TIL apparently?
00:10 < sipa> aj: yes, dependency order, unless they"re grouped, in which case the linker loops
00:14 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in]
00:14 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
00:45 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in]
00:45 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
00:49 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
00:50 -!- asdlkfjwerpoicvx [~flack@p200300d46f24de00e403ea479718bc87.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:52 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.8.2 - https://znc.in]
00:55 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
01:00 -!- astrolince [astrolince@gateway/shell/matrix.org/x-epshixvunsdsuvjp] has quit [Quit: Idle for 30+ days]
01:12 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
01:14 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
01:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:23 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
01:23 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds]
01:23 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds]
01:23 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
01:23 -!- ogo [~ogo@gateway/tor-sasl/ogo] has quit [Ping timeout: 240 seconds]
01:24 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
01:25 -!- norisg_ [~norisgOG@89.45.6.103] has joined #bitcoin-core-dev
01:25 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-dev
01:26 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
01:26 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
01:30 -!- ogo [~ogo@gateway/tor-sasl/ogo] has quit [Remote host closed the connection]
01:48 -!- norisg_ [~norisgOG@89.45.6.103] has quit [Remote host closed the connection]
01:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
01:53 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-173.cust.tzulo.com] has quit [Ping timeout: 256 seconds]
02:05 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
02:05 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
02:07 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
02:10 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
02:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
02:29 < vasild> jnewbery: aj: I guess the benefit of having a separate classes for peer manager "implementation" and "interface" is not clear from 20811 alone.
02:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:37 < bitcoin-git> [bitcoin] romanz closed pull request #20702: rpc: Add getblocklocations call (master...locations) https://github.com/bitcoin/bitcoin/pull/20702
02:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:42 < jnewbery> vasild: did you see https://github.com/bitcoin/bitcoin/pull/20758? Some of the benefits are listed there
02:42 < vasild> yes, this is why I say "from 20811 alone" :)
02:42 < jnewbery> ah ok
02:43 < vasild> I went looking for "why do that?" answers in the other PR :)
02:43 < jnewbery> It also helps with https://github.com/bitcoin/bitcoin/issues/19398, which is gradually moving data into the Peer struct. Having that only declared internally in net_processing.cpp reduces header churn
02:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:54 < bitcoin-git> [bitcoin] fanquake pushed 14 commits to master: https://github.com/bitcoin/bitcoin/compare/7838db141b76...18017152c2a5
02:54 < bitcoin-git> bitcoin/master 444fcfc Carl Dong: guix: Make guix honor MAX_JOBS setting
02:54 < bitcoin-git> bitcoin/master 0f31e24 Carl Dong: guix: Add SUBSTITUTE_URLS option
02:54 < bitcoin-git> bitcoin/master 93b6a85 Carl Dong: guix: Add ADDITIONAL_GUIX_{COMMON,TIMEMACHINE}_FLAGS options
02:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:54 < bitcoin-git> [bitcoin] fanquake merged pull request #20619: guix: Quality of life improvements (master...2020-12-guix-fixups) https://github.com/bitcoin/bitcoin/pull/20619
02:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:06 -!- arik__ [sid402902@gateway/web/irccloud.com/x-jfkmjvnsnrtdogdp] has quit [Read error: Connection reset by peer]
03:06 -!- arik__ [sid402902@gateway/web/irccloud.com/x-kdxbclwzdajdnfea] has joined #bitcoin-core-dev
03:07 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
03:19 -!- sipa_ [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
03:19 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
03:20 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
03:20 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
03:20 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
03:20 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
03:21 -!- openoms [~quassel@91.132.136.76] has quit [Quit: No Ping reply in 180 seconds.]
03:22 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
03:22 -!- openoms [~quassel@91.132.136.76] has joined #bitcoin-core-dev
03:23 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
03:25 < wumpus> aj: linker order is important with static libraries; dynamic libraries contain the list of NEEDED libraries they depend on in turn so there it doesn't matter
03:30 < wumpus> would be nice to get some more review on #18710, it's fairly straightforward but as it affects the thread pool used for script verification, which is consensus code, it needs some more eyes on it
03:30 < gribble> https://github.com/bitcoin/bitcoin/issues/18710 | Add local thread pool to CCheckQueue by hebasto · Pull Request #18710 · bitcoin/bitcoin · GitHub
03:30 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com]
03:31 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
03:33 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Client Quit]
03:34 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
03:36 < MarcoFalke> Is there a way to disable all discussions on loose commits?
03:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:54 < bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/18017152c2a5...7b975639ef93
03:54 < bitcoin-git> bitcoin/master 81c54de Anthony Towns: rpc: update getblocktemplate with signet rule, include signet_challenge
03:54 < bitcoin-git> bitcoin/master 95d5d5e Anthony Towns: rpc: allow getblocktemplate for test chains when unconnected or in IBD
03:54 < bitcoin-git> bitcoin/master 13762bc Anthony Towns: Add bitcoin-util command line utility
03:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:55 < bitcoin-git> [bitcoin] laanwj merged pull request #19937: signet mining utility (master...202009-signet-generate) https://github.com/bitcoin/bitcoin/pull/19937
03:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:57 < aj> wumpus: yay! / oh no! now i need another PR for the typo things i forgot from there
03:58 < wumpus> MarcoFalke: not that i know of, unfortunately
03:58 < aj> "move away from github" is the answer for everything involving loose commits, isn't it?
03:59 < wumpus> aj: the help/manpage still needs to be done anyway
03:59 < aj> wumpus: oh bitcoin-util needs a zillion things, i just meant some of the signet readme bits
04:00 < wumpus> aj: right
04:00 < MarcoFalke> wumpus: Any thoughts on radicle? Havne't tried it, but it makes issues harder to report for one-offs, right?
04:00 < fanquake> wumpus can you block bitmastercoin shortly
04:01 < MarcoFalke> Also, radicle will probably break email notifications (one of the few nice things that GitHub offers)
04:01 < wumpus> MarcoFalke: i like the direction of that project, and i think the design is pretty elegant; it still needs a lot of functionality to be able to replace our use of github, though
04:02 < fanquake> They are spamming my personal repos as well: https://github.com/fanquake/autotools/commit/02e7a4c3a93f2052ee0a5188488f48fd97237425. Quite annoying.
04:02 < wumpus> fanquake: ok
04:03 < wumpus> huh i only see a *list* of blocked users and can unblock people but not block them
04:03 < aj> MarcoFalke: sounds like it only does code, not discussion? (bug reports, patches, discussion are on the "roadmap"?)
04:04 < wumpus> aj: right-the 'social coding' features are going to be based on git notes, but are still in development
04:04 < MarcoFalke> TIL git help notes
04:04 < wumpus> something like email notifications and such will need an external bot i guess
04:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:04 < bitcoin-git> [bitcoin] bitmastercoin opened pull request #20911: Create act.conf (master...patch-2) https://github.com/bitcoin/bitcoin/pull/20911
04:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:05 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #20911: Create act.conf (master...patch-2) https://github.com/bitcoin/bitcoin/pull/20911
04:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:05 < MarcoFalke> I checked in december and 60% of all pull requests and issues opened were spam
04:05 < MarcoFalke> This is not sustainable
04:05 < wumpus> but this is very strange, why can't i block anyone
04:06 < wumpus> i'm still repository owner so it's not a privilege thing
04:06 < fanquake> very strange
04:09 < wumpus> fanquake:  it looks like this now: https://0bin.net/paste/VyDIFRGJ#DnMd5HHPGpTJXHaWKvNs+dg-jvD3LBhIlhwILA7o6PX    ... there should be a input widget as in https://docs.github.com/assets/images/help/organizations/org-block-username-field.png
04:10 -!- sipa_ [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
04:12 < fanquake> wumpus: ok. If you can’t find any explanation tonight, I’ll follow up with GH
04:12 -!- moti [3c7471e7@softbank060116113231.bbtec.net] has joined #bitcoin-core-dev
04:12 < wumpus> it is the same for other organizations
04:12 -!- moti [3c7471e7@softbank060116113231.bbtec.net] has quit [Client Quit]
04:13 -!- moti [3c7471e7@softbank060116113231.bbtec.net] has joined #bitcoin-core-dev
04:13 -!- moti [3c7471e7@softbank060116113231.bbtec.net] has quit [Client Quit]
04:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
04:15 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com]
04:16 < wumpus> checked on another computer, same... can oneone who is owner of a gh organization please check https://github.com/organizations/<org>/settings/user_blocks ?
04:16 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
04:18 < aj> wumpus: i see the same on https://github.com/settings/blocked_users (ie, where i should be able to block people for my personal account, i guess?)
04:20 < wumpus> could try it through the API https://docs.github.com/en/free-pro-team@latest/rest/reference/users#block-a-user
04:20 < wumpus> aj: thanks for checking
04:21 < aj> https://docs.github.com/en/free-pro-team@latest/rest/reference/orgs#block-a-user-from-an-organization ym?
04:22 < wumpus> aj: better
04:27 < aj> wumpus: it appears i can successfully block you from my homepage by api
04:28 < aj> curl -u$USER:$TOKEN  -H "Accept: application/vnd.github.v3+json" -XPUT https://api.github.com/org/$ORG/blocks/$WHO
04:29 < wumpus> aj: that worked, thanks
04:31 < aj> wumpus: sweet
04:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:38 -!- udecker [~udecker@173.243.88.22] has joined #bitcoin-core-dev
04:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
04:56 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
05:01 -!- MasterdonX [~masterdon@45.9.249.244] has quit [Ping timeout: 256 seconds]
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:06 < bitcoin-git> [bitcoin] laanwj opened pull request #20913: doc: Add manual page generation for bitcoin-util (master...2021_01_bitcoin_util_manpage) https://github.com/bitcoin/bitcoin/pull/20913
05:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:28 -!- belcher_ is now known as belcher
05:30 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
05:31 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
05:35 < jonatack> MarcoFalke: thanks! TIL about git help notes too, interesting
05:40 < jonatack> results of a fediverse poll by cdecker on switching from GH to a a git-based system https://bitcoinhackers.org/@cdecker/105537311249244507
05:42 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.28-247.dynamic.3bb.co.th] has joined #bitcoin-core-dev
05:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
05:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:55 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:02 -!- Cyberfox [~cyberfox@185.26.198.59] has joined #bitcoin-core-dev
06:14 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
06:15 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
06:15 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
06:16 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
06:16 -!- belcher_ is now known as belcher
06:18 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
06:19 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds]
06:21 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-dev
06:24 -!- sdaftuar_ is now known as sdaftuar
06:25 -!- ogo [~ogo@gateway/tor-sasl/ogo] has joined #bitcoin-core-dev
06:26 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
06:26 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
06:26 -!- jonatack [~jon@134.19.179.235] has joined #bitcoin-core-dev
06:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
06:29 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:43 -!- lontivero [~lontivero@186.183.48.51] has joined #bitcoin-core-dev
06:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
06:50 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
06:50 -!- pbase [~pbase@171.61.16.193] has joined #bitcoin-core-dev
06:50 -!- pbase [~pbase@171.61.16.193] has quit [Changing host]
06:50 -!- pbase [~pbase@unaffiliated/pbase] has joined #bitcoin-core-dev
06:51 -!- glozow [uid453516@gateway/web/irccloud.com/x-fxumjocdhrcrnkpo] has joined #bitcoin-core-dev
06:52 < jnewbery> Hi folks. Reminder that we have our first p2p meeting in just under 10 minutes. We have three suggested topics so far: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#12-jan-2021
06:52 < gribble> https://github.com/bitcoin/bitcoin/issues/12 | Monitor transactions and/or blocks · Issue #12 · bitcoin/bitcoin · GitHub
06:53 -!- lontivero_ [~lontivero@186.183.48.215] has joined #bitcoin-core-dev
06:56 -!- lontivero [~lontivero@186.183.48.51] has quit [Ping timeout: 264 seconds]
07:00 < jnewbery> #startmeeting
07:00 < core-meetingbot> Meeting started Tue Jan 12 15:00:17 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
07:00 < core-meetingbot> Available commands: action commands idea info link nick
07:00 < jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb 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 petertodd  
07:00 < jnewbery> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
07:00 < glozow> hai
07:00 < jamesob> hi
07:00 < ariard> yo
07:00 < jonatack> hola
07:00 < vasild> hi
07:01 < ajonas> hi
07:01 < amiti> hi
07:01 < jnewbery> hi folks. Welcome to the first p2p meeting of 2021!
07:01 < jnewbery> We have three proposed meeting topics: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#12-jan-2021
07:01 < sdaftuar> hi
07:01 < gribble> https://github.com/bitcoin/bitcoin/issues/12 | Monitor transactions and/or blocks · Issue #12 · bitcoin/bitcoin · GitHub
07:02 < jnewbery> Before we get on to those, I suggest we start with our regular topic of priorities. What are people working on/hoping to make progress on over the next weeks/months?
07:02 < jnewbery> don't be shy!
07:02 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:03 < vasild> On my end #20788
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/20788 | net: add RAII socket and use it instead of bare SOCKET by vasild · Pull Request #20788 · bitcoin/bitcoin · GitHub
07:03 < vasild> it would help #19203 and #20685 to move forward
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/19203 | net: Add regression fuzz harness for CVE-2017-18350. Add FuzzedSocket. Add thin SOCKET wrapper. by practicalswift · Pull Request #19203 · bitcoin/bitcoin · GitHub
07:03 < gribble> https://github.com/bitcoin/bitcoin/issues/20685 | Add I2P support using I2P SAM by vasild · Pull Request #20685 · bitcoin/bitcoin · GitHub
07:03 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has joined #bitcoin-core-dev
07:04 < jonatack> On my end https://github.com/bitcoin/bitcoin/pull/20197
07:04 < jonatack> #20197 and adding more unit test coverage to the eviction logic
07:04 < jnewbery> My main priority for the start of this year is to make progress on the net/net_processing split (#19398). I'm currently waiting for #20811 because I think my remaining changes are less disruptive after that.
07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: improve onion detection in AttemptToEvictConnection() by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/19398 | Move remaining application layer data to net processing · Issue #19398 · bitcoin/bitcoin · GitHub
07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20811 | refactor: move net_processing implementation details out of header by ajtowns · Pull Request #20811 · bitcoin/bitcoin · GitHub
07:04 < ariard> reviewing erlay/package testmempoolaccept and updating #20277 with last sdaftuar feedback
07:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20277 | p2p: Stop processing unrequested transactions during IBD and extend p2p_ibd_txrelay.py coverage by ariard · Pull Request #20277 · bitcoin/bitcoin · GitHub
07:06 < jnewbery> Reminder that aj maintains a board of p2p PRs here: https://github.com/users/ajtowns/projects/1
07:07 < jnewbery> ok, if no-one has anything else, let's move onto the first topic
07:07 < jnewbery> #topic disabletx P2P message (sdaftuar)
07:07 < core-meetingbot> topic: disabletx P2P message (sdaftuar)
07:07 < sdaftuar> ooh i'm up
07:07 < sdaftuar> ok so the context here is #20726
07:07 < gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
07:08 < sdaftuar> it's gotten a decent bit of feedback so far, so not sure if it's helpful for me to go through all the context again?
07:08 < sdaftuar> but i can for anyone who hasn't looked at it
07:09 < sdaftuar> the main goal here is to be able to increase the number of inbound connection slots on the network, in order to feel good about increasing hte number of block-relay-only connections we make
07:09 < sdaftuar> which in turn is in order to add security to the network by increasing its partition resistance, at relatively low cost (block-relay-only connections are low-resource)
07:10 < sdaftuar> but to do all that, we need to give nodes a way to know that an inbound peer is a block-relay-only peer. currently block-relay-only peers use the fRelay flag from BIP37 to instruct their peer they don't want transactions
07:10 < sdaftuar> but BIP37 allows for transaction relay to resume with a FILTERCLEAR message
07:10 < jnewbery> sdaftuar: when you say low-resource, are you mostly talking about memory, bandwidth of something else?
07:10 < jnewbery> *or something else
07:10 < sdaftuar> memory and bandwidth
07:10 < sdaftuar> and cpu, i guess
07:11 < sdaftuar> so my proposal is to add a new p2p message ("disabletx") which means that a connection will never relay transactions, for its lifetime
07:11 < amiti> sdaftuar: do I understand correctly the current proposal is a `disabletx` messages that explicitly disables transactions & implicitly disables addresses? And the thinking is that in the future we could have a message that explicitly enables addresses ? I followed your reasoning for opt out vs opt in (why would we ever opt out of blocks?), but what do you think about implementing block-relay conns with two 
07:11 < amiti> messages, `disabletx` and `disableaddr` or something?  
07:11 < vasild> if the node is up to date, then block-relay conveys just a few MB of data per 10 minutes, right? But if the node is not up to date...
07:11 < sdaftuar> this in turn will allow us to write code to increase the number of connections lots by reserving additional slots for disabletx-peers
07:12 < sdaftuar> amiti: right, so block-relay-only connections currently have no way to communicate that they also don't want addr messages
07:13 < sdaftuar> and my proposal for now is to just have the BIP "RECOMMEND" that we not send addrs to peers sending disabletx
07:13 < sdaftuar> with the idea being that in the future, we should adopt some kind of addr relay negotiation protocol, which would then take precedence
07:13 < sdaftuar> however i think designing an addr relay protocol will take some work, and i'm not ready to propose one now
07:14 < sdaftuar> i think there are a bunch of questions around what the goals of addr relay should be, and how best we might achieve them
07:14 < sdaftuar> and so i don't think it makes sense to propose something that we'd likely just want to change soon after
07:14 < amiti> ah I see, you think the long term design should be more than a toggle (like with txs)?
07:15 < sdaftuar> yeah, at the least i suspect we want to communicate information about particular networks (as described in BIP 155)
07:15 < amiti> yeah, that makes sense. 
07:16 < sdaftuar> and it's not clear to me yet what our different handling should be for different networks (ie addresses we understand versus ones we don't)
07:16 < vasild> tx relay is unrelated to addr relay, linking both together under "disabletx" would be confusing?
07:16 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Ping timeout: 256 seconds]
07:17 -!- pbase [~pbase@unaffiliated/pbase] has quit [Quit: Leaving]
07:17 < sdaftuar> vasild: both are related to block-relay-only peer logic, which is the only thing that will be using this at the start... i don't see why it's a problem to have a recommendation for this?
07:17 < sdaftuar> software that ignores the addr-relay suggestion will not be in violation of the design
07:18 < sdaftuar> but it accommodates our desired behavior today
07:18 -!- lontivero_ [~lontivero@186.183.48.215] has quit [Ping timeout: 260 seconds]
07:19 < sdaftuar> if there were some other software that was going to be using this which wanted different functionality, then i might agree
07:19 < jnewbery> I agree that it seems strange to link the two things (tx relay and addr relay) in the BIP
07:19 < vasild> then isn't s/disabletx/relayblocksonly/ more clear (relay only blocks and nothing else - no tx, no addr)?
07:20 < ariard> but the alternative to introduce a `disabeladdr` will be superceded when we have a better addr relay protocol?
07:20 < sdaftuar> vasild: that was my first approach, but many people seemed to feel that having a BIP that governed too much behavior was also confusing or bad protocol design, for future compatibility
07:20 < vasild> :)
07:20 < sdaftuar> vasild: so this approach is narrow -- just specifies required behavior for tx-relay -- but the motivation gives us an implication for other behavior as well
07:21 < sdaftuar> in the absence of protocol support
07:21 < jonatack> sdaftuar: fwiw i like the original "blockrelay"
07:22 < jnewbery> (the original discussion of blockrelay -> disabletx is here: https://github.com/bitcoin/bitcoin/pull/20726#discussion_r548352366)
07:22 < sdaftuar> (trying to figure out how to do an ascii shrug)
07:22 < jonatack> sometimes in those discussions the squeaky wheel gets the grease, so mentioning it as a fwiw here
07:22 < sdaftuar> i mean i could go either way. i think there's benefit to understanding the network from communicating more exactly what these connections do, and establishing first-class support in the protocol
07:23 < sdaftuar> which was more inline with my initial proposal / description
07:23 < sdaftuar> but i can see the argument that it imposes design burden on future protocol implementers to figure out how new features should interact with this
07:24 < sdaftuar> so making this more narrowly tailored shifts the burden back on just software implementing this feature
07:24 < jonatack> jnewbery: i thought it was here: https://github.com/bitcoin/bitcoin/pull/20726#discussion_r548352366
07:24 < jonatack> jnewbery: nvm, GitHub doesn't work for me correctly, your link sent me to a different one
07:24 < sdaftuar> i think i can implement what i would like to implement with either approach, so i'm hoping that we can just pick a path and move forward.
07:25 < sdaftuar> i don't think my current proposal inhibits any future protocol extensions at all
07:25 < jnewbery> I don't see much difference between the original proposal and the disabletx proposal. They both interact with addr relay in a potentially unexpected way.
07:26 < sdaftuar> jnewbery: but it's just a recommendation.  what drawback is there to having it in there?
07:26 < sdaftuar> obviously it could be removed; it just seems to me that it makes things strictly worse.
07:27 < jonatack> sdaftuar: hm, the latest push of 20726 seems smaller and inbound-block-relay was dropped?
07:27 < ariard> sdaftuar: implementation-wise, how do we tread `disabletx` peers keep sending us addrs? we disconnect or ignore msgs ?
07:27 < sdaftuar> jonatack: yes, i switched to using just a bool to track whether the peer is a disabletx bool, rather than upgrading connection type.
07:27 < jnewbery> If there is some new addr relay negotiation method introduced in future you have to specify how that interacts with the disabletx BIP
07:28 < sdaftuar> jnewbery: obviously it takes precedence, as the disabletx BIP only has a recommendation, and not MUST semantics, and it even calls out this possibility
07:28 < sipa> good morning
07:29 < jonatack> sdaftuar: ok. we already have a de facto inbound block relay type IIUC and it would be nice to formalize it, if so, but I understand that it may not be central to your proposal 
07:29 < sdaftuar> jonatack: there was feedback that the connection type change was not the right fit for this. i don't feel strongly, but in changing the thinking from explicitly communicating BLOCKRELAY to a peer, to sending a DISABLETX, it felt more in line with just another setting on a peer's preferred transaction relay
07:29 < jnewbery> I think it's probably more useful to discuss the protocol proposal at this stage than implementation details
07:30 < sdaftuar> here's my question for people who are concerned abotu the addr relay interaction:
07:30 -!- lontivero_ [~lontivero@186.183.49.186] has joined #bitcoin-core-dev
07:30 < sdaftuar> let's say we deployed disabletx. shoudl bitcoin core relay addrs to software sending these messages?
07:30 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has joined #bitcoin-core-dev
07:31 < vasild> yes
07:31 < amiti> I would prefer if there was a way to be explicit about what we are relaying (tx / block / addr). both the original & current proposal are suggesting one message to communicate two pieces of information. I see the challenges of designing for a future where we want more advanced addr relay, but I'm still wondering how we could do both. 
07:31 < sdaftuar> vasild: the fact that we relay addrs to inbound-block-relay-only peers is a problem, no?
07:32 < amiti> hm, if bitcoin core relayed addrs to software that sends disabletx, we aren't able to take advantage of the savings that is the goal, right? 
07:32 < sdaftuar> isn't that behavior strictly worse than not relaying addrs?
07:32 < sdaftuar> amiti: that's a minor goal. addr relay is not nearly as big a deal as tx-relay
07:32 < sdaftuar> the data structure is much smaller, i believe
07:32 < amiti> ok
07:32 < sdaftuar> but yes, a bit annoying
07:33 < ariard> it can be cleanup when an addr relay negotiation protocol is introduced
07:33 < sdaftuar> one of the drawbacks to increasing the number of inbound-block-relay-only peers is that we create a bunch of addr-relay blakc holes
07:33 < sdaftuar> i don't see why we can't make progress on this while deferring design of an actual addr relay protocol ot the future?
07:33 < jnewbery> amiti: the receiving node could just drop all addr/getaddr messages. There wouldn't be any memory cost and minimal bandwidth cost
07:33 < vasild> I mean "yes", because they did not send "disableaddr" (which does not exist) -- i.e. don't link addr and tx relay in one option
07:35 < amiti> jnewbery: ah. right.  
07:35 < jonatack> sdaftuar: ack
07:36 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Ping timeout: 264 seconds]
07:37 < jnewbery> sdaftuar: do you have any further thoughts about what a future addr relay negotiation method would look like? I know you were pushing for something similar with BIP155
07:38 < sdaftuar> i have a guess, but i think we need to get everyone on the same page about the goals of addr relay are, and come up with some relay policies that we think would achieve that goal, and then make sure our design supports those relay policies
07:38 < sdaftuar> there's currently no writeup anywhere on how addr relay should work, to my knowledge
07:39 < sdaftuar> but my naive guess is that adding some kind of feature negotiation where we signal support (not sure 0/1 or if more precision is necessary) for different networks (as defined in bip 155) is probably what we will eventually want
07:39 < sdaftuar> i just can't defend that right now 
07:40 < jnewbery> what's the downside of removing the addr relay RECOMMEND point and punting on how to do addr relay negotiation?
07:40 < sdaftuar> jnewbery: first you answer my question from above please!
07:40 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has joined #bitcoin-core-dev
07:40 < ariard> even assuming you have one goal, and nodes operators might wish different relay strategies in function of their privacy needs
07:40 < sdaftuar> let's say we deployed disabletx. shoudl bitcoin core relay addrs to software sending these messages?
07:40 < sdaftuar> i think the answer to that is of course not
07:41 < jnewbery> it depends what the spec says, of course
07:41 < sdaftuar> well then that creates the black-hole problem, which will prevent us from wanting to add more blokc-relay connections
07:41 < sdaftuar> i mean we can certainly gate all these improvements on addr relay improvements. i just think that will set us back a long time
07:42 < ariard> sdaftuar: to be clear you're envisioning 1) adding more block-relay connection and then 2) addr relay improvements?
07:42 < sdaftuar> ariard: yes i think we know how to do 1), while 2) requires research
07:43 < jnewbery> You don't want a disableaddr message because it won't be useful after the new addr relay negotiation method?
07:43 < sdaftuar> i've started doing some research on 2), but it might be a year or more before i feel good about proposing anything, i don't know
07:43 -!- jespada [~jespada@90.254.245.49] has quit [Ping timeout: 264 seconds]
07:43 < sipa> sdaftuar: i hadn't considered the fact that adding more block-only connections (a goal of disabletx), actually worsens the addr black hole problem
07:43 < jonatack> sdaftuar: i agree that incremental and possibly iterative is the pragmatic way forward here
07:44 < sdaftuar> sipa: this came up in #15759 when first proposed, and was one of the reasons we kept it at 2 connections
07:44 < gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
07:44 < sdaftuar> based on looking at my own nodes at the time, i didn't feel it was a material worsening of the sitaution, given the other software on the network
07:45 -!- Anne [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Ping timeout: 264 seconds]
07:45 < sdaftuar> but i would feel uncomfortable advocating going up to 8 peers without really looking at it a lot more carefully
07:45 < sdaftuar> in the absence of us changing our default behavior for disabletx peers
07:45 -!- jespada [~jespada@90.254.245.49] has joined #bitcoin-core-dev
07:45 < sdaftuar> jnewbery: yes i think a disableaddr message would be short-lived
07:46 < sipa> right
07:46 < ariard> to be back on the question "should bitcoin core relay addrs to software sending these messages?" _currently_ we don't accept addr msgs from outbound-block-relay peers so why it's worsening the black-hole problem?
07:46 < sdaftuar> ariard: the outbound peer will choose us for addr relay (sometimes)
07:47 < sdaftuar> and we will drop it and not relay further
07:47 < sdaftuar> so increasing the number of connections that drop addr messages could inhibit addr relay
07:47 < sdaftuar> this gets to what i was saying before though, i don't think anyone has studied addr relay. this is an open area of research that is (to my knowledge) very undeveloped
07:47 < ariard> yeah because you have less peers doing useful addr relay, but I think we should defer this discussion when we introduce more block-relay connectiions
07:48 < sdaftuar> so i'm just trying to not make things worse
07:48 < ariard> I agree things aren't worse post-#20726
07:48 < gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
07:48 < sdaftuar> ariard: well i'd like to establish that people are comfortable with not relaying addrs to disabletx peers
07:49 < sdaftuar> because if not, then i don't to advocate for this
07:49 < ariard> sdaftuar: and my feeling is some folks would prefer introduce a `disableaddr` to have a clean protocol signaling
07:49 < sdaftuar> (not relaying addrs to disabletx peers until such time that we deploy addr-relay negotiation, to be clear)
07:49 < ariard> I'm ~0 on this
07:49 < sipa> i don't think it's unreasonable to recommend not relaying addresses to disabletx peers; so far addr relay is completely local policy anyway with no BIPs discussing it at all afaik
07:50 < sdaftuar> sipa: my understanding as well that there are no BIPs on it
07:50 < sipa> it's what we'd do anyway, unless the BIP explicitly says the opposite
07:53 < jnewbery> any additional points, or should we move on?
07:53 < jonatack> subject to review, concept ack on the BIP draft and 20726
07:54 -!- Anne [uid482204@gateway/web/irccloud.com/x-zjdveqnxaamxneop] has joined #bitcoin-core-dev
07:54 < jnewbery> jonatack: we only have 5 minutes left, so I propose we punt your topics to the next meeting
07:54 < sdaftuar> thanks. i'm planning to mark 20726 ready for review once a bip number is assigned, fyi
07:55 < jnewbery> One quick topic before we end. How do people feel about a different time for this meeting? It would have been nice to have aj here, but it's 1am for him, so it's not the most sociable time.
07:55 < jonatack> jnewbery: that's fine. for now i'd only like to mention that connection type implementations are open for the CLI and GUI (and partially merged in the GUI), in case people didn't see them
07:55 -!- Anne_ [~igloo@65-122-123-66.dia.static.qwest.net] has joined #bitcoin-core-dev
07:55 < jonatack> and they have had to go beyond the literal connection types to cover the actual cases
07:56 < jnewbery> 2100 UTC is 07:00 in Brisbane, 16:00 in New York and 13:00 in California
07:56 < sipa> jnewbery: earlier will be hard for me
07:56 < vasild> 21:00 UTC is 22:00 central europe, I will not be able to attend
07:57 < sipa> timezones suck :(
07:57 < vasild> (I rarely attend the other two meetings because they are too late too)
07:57 < jonatack> agreed
07:57 < jonatack> (they suck and the meetings are late :)
07:58 < jnewbery> ok, let's keep it at the current time for now.
07:58 < jnewbery> time's up
07:58 < jnewbery> #endmeeting
07:58 < 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
07:58 < core-meetingbot> Meeting ended Tue Jan 12 15:58:58 2021 UTC.  
07:58 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-12-15.00.moin.txt
07:59 < jonatack> let's meet at bitcoin beach for the p2p meetings
07:59 < jonatack> (el zonte, el salvador)
07:59 < vasild> 1am - moved 6 hours earlier should be 19:00 aj's time and 11:00 central europe - I would be fine with that
08:00 < jonatack> that's in the middle of the night in the US though
08:00 < vasild> I wonder why all meetings are in evening time for europe? I can also do meetings at 9:00 am :)
08:01 < vasild> hmm, timezones suck
08:02 -!- lontivero_ [~lontivero@186.183.49.186] has quit [Ping timeout: 264 seconds]
08:04 < vasild> jnewbery: something like this may help to see where is most overlap: https://www.timeanddate.com/worldclock/meetingtime.html?day=29&month=1&year=2021&p1=195&p2=136&p3=179&iv=0
08:08 < MarcoFalke> If sipa moves to the east coast, all our problems are solved, no?
08:10 < sipa> nobody else on the west coast?
08:12 < sipa> if so, there is a 9 hour timezone gap between US east coast and eastern australia
08:14 -!- Anne_ [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Ping timeout: 265 seconds]
08:14 -!- lontivero_ [~lontivero@186.183.3.108] has joined #bitcoin-core-dev
08:15 < MarcoFalke> 19:00 au, 11:00 europe, 7:00 east coast?
08:15 -!- Bitcoinr [~Bitcoinr@202.185.196.193] has joined #bitcoin-core-dev
08:18 -!- Anne_ [~igloo@65-122-123-66.dia.static.qwest.net] has joined #bitcoin-core-dev
08:20 < jonatack> 1100 CET is 0600 EST
08:21 < jonatack> er, 0500 EST
08:21 < jonatack> 6 hours
08:27 -!- Anne_ [~igloo@65-122-123-66.dia.static.qwest.net] has quit [Ping timeout: 240 seconds]
08:35 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection]
08:37 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev
08:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:40 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20915: fuzz: Fail if message type is not fuzzed (master...2101-fuzzFailMsgType) https://github.com/bitcoin/bitcoin/pull/20915
08:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:42 < MarcoFalke> There is also +-2 hours due to DST :(
08:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:52 < bitcoin-git> [bitcoin] laanwj pushed 4 commits to 0.20: https://github.com/bitcoin/bitcoin/compare/a4bc4c1f79d7...f1c3c53e5f94
08:52 < bitcoin-git> bitcoin/0.20 bcb655d Ben Carman: rpc: Add missing description of vout in getrawtransaction help text
08:52 < bitcoin-git> bitcoin/0.20 d0c75ab MarcoFalke: doc: Extract net permissions doc
08:52 < bitcoin-git> bitcoin/0.20 19bcf17 Amiti Uttarwar: [doc] Add permissions to the getpeerinfo help.
08:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:52 < bitcoin-git> [bitcoin] laanwj merged pull request #20738: [0.20] final rc2 backports (0.20...2012-20rc2) https://github.com/bitcoin/bitcoin/pull/20738
08:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:53 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.28-247.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
08:54 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-dev
08:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
08:59 < MarcoFalke> \o/
08:59 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Ping timeout: 246 seconds]
09:10 -!- Bitcoinr [~Bitcoinr@202.185.196.193] has quit [Quit: Exit game!]
09:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
09:12 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-dev
09:28 < jeremyrubin> achow101: is there a reason why utxoupdatepsbt does not fill in the witnessScript field?
09:28 < achow101> jeremyrubin: it only has access to the utxo set, so witnessScripts are not known
09:29 < jeremyrubin> achow101: but it does conceivably have access to *our* utxos, for which it does know witness scripts?
09:29 < achow101> jeremyrubin: it's not a wallet rpc
09:29 < achow101> it's a node rpc
09:30 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
09:31 < sipa> you can run utxoupdatepsbt + walletprocesspsbt, and you'll have both
09:31 < jeremyrubin> ah i see
09:31 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:34 < jeremyrubin> so from what I can tell, it does not add the witness script
09:34 < achow101> walletprocesspsbt will add whatever the wallet knows
09:35 < jeremyrubin> or wait let me look more closely at what happened here..
09:37 < jeremyrubin> somehow I ended up with a corrupt psbt
09:37 < jeremyrubin> let me figure out exactly what happened
09:37 -!- udecker [~udecker@173.243.88.22] has quit [Quit: udecker]
09:39 -!- Cyberfox [~cyberfox@185.26.198.59] has quit [Remote host closed the connection]
09:48 -!- udecker [~udecker@173.243.88.22] has joined #bitcoin-core-dev
09:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:52 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #20916: rpc: Return wtxid from testmempoolaccept (master...2101-wtxidTestmempool) https://github.com/bitcoin/bitcoin/pull/20916
09:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:06 < jeremyrubin> I think I may be missing something, but in TransactionError DescriptorScriptPubKeyMan::FillPSBT
10:06 < jeremyrubin> What line is the sigdata actually used?
10:09 < jeremyrubin> Maybe I need to rebase some changes...
10:09 < jeremyrubin> https://github.com/bitcoin/bitcoin/blob/afdfd3c8c1ce96adae11809e3989de381137fee9/src/wallet/scriptpubkeyman.cpp#L625
10:14 -!- lontivero_ [~lontivero@186.183.3.108] has quit [Ping timeout: 260 seconds]
10:15 < jeremyrubin> it looks to me that if the legacy provider is used then the data just gets dropped instead of written into the psbt
10:17 < sipa> jeremyrubin: that does look weird... but it's the same in DescriptorScriptPubKeyMan::FillPSBT and in LegacyScriptPubKeyMan::FillPSBT
10:17 < sipa> SignatureData object is created, FillSignatureData is called on it, and then never used
10:18 < jeremyrubin> I'm *pretty sure* it is a bug
10:19 < jeremyrubin> It doesn't come up because I think if we're able to sign the input we erase the data and finalize it anyways
10:19 < jeremyrubin> but it would be an issue in certain e.g. multisig cases I think
10:20 < jeremyrubin> (finalize it, it = that input)
10:25 < jeremyrubin> Well maybe it's not a bug; it just has no effect. But I think in theory we should be filling this information in from a different source and writing it back to the PSBT.
10:25 < jeremyrubin> AFAICT there is no path for getting the witness_script (n.b. not scriptWitness) field filled in
10:25 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
10:26 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #bitcoin-core-dev
10:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:30 < bitcoin-git> [bitcoin] theStack opened pull request #20917: doc, rpc: add missing signet mentions in network name lists (master...2021-add_missing_signet_network_name) https://github.com/bitcoin/bitcoin/pull/20917
10:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:31 < jeremyrubin> looks like passing sigdata to SignPSBTInput would be one step
10:32 < jeremyrubin> ah it seems like that path does happen (sorry for the thinking out loud here)
10:32 -!- asdlkfjwerpoicvx [~flack@p200300d46f24de00e403ea479718bc87.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
10:33 < jeremyrubin> There's another call which covers it
10:33 < jeremyrubin> so we can probably just delete those temporaries? I'm just curious why they are there at all
10:35 -!- owowo [~ovovo@31.7.59.226] has joined #bitcoin-core-dev
10:35 -!- owowo [~ovovo@31.7.59.226] has quit [Changing host]
10:35 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:36 -!- ovovo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds]
10:36 -!- lontivero_ [~lontivero@186.141.229.18] has joined #bitcoin-core-dev
10:40 < jeremyrubin> I'm still unable to get it to fill out the witness_script fwiw 
10:40 < jeremyrubin> e.g., `bitcoin-cli walletprocesspsbt $(cat PSBT) true | jq  '.psbt' | xargs printf > PSBT2` succeeds
10:41 < jeremyrubin> it produces a signature successfully 
10:41 < jeremyrubin> but
10:41 < jeremyrubin> `bitcoin-cli walletprocesspsbt $(cat PSBT) false | jq  '.psbt' | xargs printf > PSBT2` does not fill in the witness_script
10:47 < jeremyrubin> even a fresh call to walletcreatefundedpsbt seems not to fill out this field. Maybe I'm missing something? But I thought this field is required to derive the scriptcode
10:50 < sipa> what exactly is your wallet like?
10:51 < sipa> it does look like a bug; i can't imagine that a wallet is able to sign, but if asked not to, doesn't fill in the witness_script
10:51 < sipa> but it would be useful to be able to exactly reproduce the problem
10:54 -!- jayg [~jayg@178.162.212.214] has quit [Remote host closed the connection]
10:54 < jeremyrubin> yeah let me give you an exact repro script...
10:56 < jeremyrubin> ./bitcoin-cli walletcreatefundedpsbt '[]' '[{"bcrt1qkgjcurnce02xu5kgyd3l3zamv548vaydv0w2ju": 1.999}]' | jq '.psbt'  | xargs printf > PSBT
10:56 < jeremyrubin> or even better
10:58 < jeremyrubin> `./bitcoin-cli walletcreatefundedpsbt '[]' "[{\"$(./bitcoin-cli getnewaddress)\": 1.999}]" | jq '.psbt'  | xargs printf > PSBT`
10:58 < jeremyrubin> (you can skip the jq stuff if you want, just so you don't need to manual copy out the field)
10:58 < sipa> and what is the wallet? legacy/descriptor? what keys/scripts/descriptors in it?
10:59 < jeremyrubin> output of ./bitcoin-cli getaddressinfo $(./bitcoin-cli getnewaddress):
11:00 < jeremyrubin> (apologies multiline paste)
11:00 < jeremyrubin> {
11:00 < jeremyrubin>   "address": "bcrt1qdczyxwznstvd9vpp58qya4c8vv2d30vxtfs63x",
11:00 < jeremyrubin>   "scriptPubKey": "00146e0443385382d8d2b021a1c04ed7076314d8bd86",
11:00 < jeremyrubin>   "ismine": true,
11:00 < jeremyrubin>   "solvable": true,
11:00 < jeremyrubin>   "desc": "wpkh([9efb471d/0'/0'/10']035bb97d5589f1a6dc4bf0b9ff0e8a2618cf0fb8217bde55c3137258463e33be2a)#fpe79sll",
11:00 < jeremyrubin>   "iswatchonly": false,
11:00 < jeremyrubin>   "isscript": false,
11:00 < jeremyrubin>   "iswitness": true,
11:00 < jeremyrubin>   "witness_version": 0,
11:00 < jeremyrubin>   "witness_program": "6e0443385382d8d2b021a1c04ed7076314d8bd86",
11:00 < jeremyrubin>   "pubkey": "035bb97d5589f1a6dc4bf0b9ff0e8a2618cf0fb8217bde55c3137258463e33be2a",
11:00 < jeremyrubin>   "ischange": false,
11:00 < jeremyrubin>   "timestamp": 1608084501,
11:00 < jeremyrubin>   "hdkeypath": "m/0'/0'/10'",
11:00 < sipa> that's P2WPKH; that doesn't have any witness_script
11:00 < jeremyrubin>   "hdseedid": "61316b9e5b4eed5608d1492c26b449f2a307c4e3",
11:00 < jeremyrubin>   "hdmasterfingerprint": "9efb471d",
11:00 < jeremyrubin>   "labels": [
11:00 < jeremyrubin>     ""
11:00 < jeremyrubin>   ]
11:01 < jeremyrubin> }
11:01 < sipa> please don't paste more than 3 lines
11:02 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]
11:02 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
11:03 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-dev
11:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
11:06 < jeremyrubin> Ah I see -- the documentation is sort of confusing for that, but that makes sense
11:07 -!- rex4539_ [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
11:08 < jeremyrubin> thank you for helping me work through that -- I'll try to construct a non P2WPKH case to see if it handles properly
11:08 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Quit: No Ping reply in 180 seconds.]
11:09 < jeremyrubin> I think where I got confused is (non-core, going to move convo to appropriate channel) https://docs.rs/bitcoin/0.25.2/bitcoin/util/bip143/struct.SigHashCache.html#method.signature_hash requires a scriptcode field
11:11 -!- FrontSevens [~FrontSeve@185.204.1.185] has joined #bitcoin-core-dev
11:11 < sipa> BIP141 defines witness script
11:17 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Ping timeout: 240 seconds]
11:26 -!- udecker [~udecker@173.243.88.22] has quit [Quit: udecker]
11:37 -!- udecker [~udecker@173.243.88.22] has joined #bitcoin-core-dev
11:58 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
11:59 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
12:03 -!- proofofkeags [~proofofke@174-29-3-187.hlrn.qwest.net] has quit [Remote host closed the connection]
12:09 -!- lontivero_ [~lontivero@186.141.229.18] has quit [Ping timeout: 240 seconds]
12:29 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:57 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
12:59 < hebasto> wumpus: https://github.com/bitcoin/bitcoin/commit/98c9d79d2bebbb52777696d9d4273015d1d92e66#commitcomment-45898153
13:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
13:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:07 < bitcoin-git> [bitcoin] sinetek opened pull request #20920: add include for std::bind. (master...FUNCTIONAL) https://github.com/bitcoin/bitcoin/pull/20920
13:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
13:10 < wumpus> hebasto: yes that translation looks pointless, just a repeat of English source messages
13:10 < wumpus> i've added the list of pulls and list of authors to the draft 0.21 release notes
13:11 < wumpus> unless anything comes up, i plan on merging the wiki back into the branch then tagging 0.21.0 final tomorrow
13:23 -!- MickSaunders [~michael@193.105.188.215] has quit []
13:43 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:50 < darosior> wumpus: if i have a small addition to the release notes, can i just modify https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.21.0-Release-Notes-Draft in place?
13:50 < darosior> Modif being mentioning that -blocksonly will now completely deactivate fee estimation
13:51 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Quit: The Lounge - https://thelounge.chat]
13:53 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]
14:00 < jonatack> darosior: yes (and before the wiki is merged back into the branch tomorrow)
14:06 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
14:10 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-dev
14:35 -!- DarkHunter [BerTTon@89.35.250.199] has joined #bitcoin-core-dev
14:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
14:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
15:00 < achow101> is #19935 rtm? has 3 acks
15:01 < gribble> https://github.com/bitcoin/bitcoin/issues/19935 | Move SaltedHashers to separate file and add some new ones by achow101 · Pull Request #19935 · bitcoin/bitcoin · GitHub
15:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:15 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
15:28 -!- DarkHunter [BerTTon@89.35.250.199] has quit [Remote host closed the connection]
15:34 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
16:13 < amiti> #20811 might also be rfm / has 3 acks 
16:13 < gribble> https://github.com/bitcoin/bitcoin/issues/20811 | refactor: move net_processing implementation details out of header by ajtowns · Pull Request #20811 · bitcoin/bitcoin · GitHub
16:22 -!- elrifleman [63172455@99-23-36-85.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-core-dev
16:23 -!- elrifleman [63172455@99-23-36-85.lightspeed.hstntx.sbcglobal.net] has quit [Client Quit]
16:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:26 < bitcoin-git> [bitcoin] theStack opened pull request #20921: validation: don't try to invalidate genesis block in CChainState::InvalidateBlock (master...2021-rpc-forbid_invalidateblock_on_genesisblock) https://github.com/bitcoin/bitcoin/pull/20921
16:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:29 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
16:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:39 < bitcoin-git> [bitcoin] sinetek closed pull request #20920: add include for std::bind. (master...FUNCTIONAL) https://github.com/bitcoin/bitcoin/pull/20920
16:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:06 < bitcoin-git> [gui] sinetek opened pull request #183: Add include for std::bind. (master...functional) https://github.com/bitcoin-core/gui/pull/183
17:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:15 -!- MasterdonX [~masterdon@45.9.249.244] has joined #bitcoin-core-dev
17:16 -!- rex4539_ [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
17:21 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-dev
17:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:45 -!- DevnySee [0ec9f4e1@14-201-244-225.tpgi.com.au] has joined #bitcoin-core-dev
17:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:45 < bitcoin-git> [bitcoin] sinetek opened pull request #20922: switch over to std::shared_mutex. (master...stdsm) https://github.com/bitcoin/bitcoin/pull/20922
17:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:48 -!- ReleaseGreed24 [44eb20fe@static-68-235-32-254.cust.tzulo.com] has joined #bitcoin-core-dev
17:49 -!- DevnySee [0ec9f4e1@14-201-244-225.tpgi.com.au] has quit [Ping timeout: 248 seconds]
17:52 -!- ReleaseGreed24 [44eb20fe@static-68-235-32-254.cust.tzulo.com] has quit [Client Quit]
18:06 -!- FrontSevens [~FrontSeve@185.204.1.185] has quit [Remote host closed the connection]
18:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:15 < bitcoin-git> [bitcoin] sinetek closed pull request #20922: switch over to std::shared_mutex. (master...stdsm) https://github.com/bitcoin/bitcoin/pull/20922
18:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
18:23 -!- MartinAS1 [~MartinAS@185.163.110.125] has joined #bitcoin-core-dev
18:40 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
18:45 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Ping timeout: 240 seconds]
18:54 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
18:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:57 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
18:59 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
19:17 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye]
19:18 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
19:18 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
19:20 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Client Quit]
19:21 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
19:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
19:44 -!- jespada [~jespada@90.254.245.49] has quit [Ping timeout: 240 seconds]
19:47 -!- jespada [~jespada@90.254.245.49] has joined #bitcoin-core-dev
19:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
19:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
20:01 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
20:04 -!- MartinAS1 [~MartinAS@185.163.110.125] has quit [Remote host closed the connection]
20:04 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
20:06 -!- tomCook [b2a5825e@178.165.130.94.wireless.dyn.drei.com] has joined #bitcoin-core-dev
20:07 -!- tomCook [b2a5825e@178.165.130.94.wireless.dyn.drei.com] has quit [Client Quit]
20:16 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
20:17 -!- MasterdonX [~masterdon@45.9.249.244] has quit [Ping timeout: 246 seconds]
20:21 -!- tadeo [~tadeo@185.103.96.147] has joined #bitcoin-core-dev
20:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:29 < bitcoin-git> [bitcoin] ajtowns opened pull request #20923: signet miner followups (master...202101-signet-tweak) https://github.com/bitcoin/bitcoin/pull/20923
20:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
20:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
20:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
20:56 -!- vasild_ is now known as vasild
21:04 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
21:24 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]
21:25 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
21:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:05 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
22:14 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 260 seconds]
22:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
22:44 -!- thomaseizinger [thomaseizi@gateway/shell/matrix.org/x-kjdwehkpxcuxnxpm] has joined #bitcoin-core-dev
22:54 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
23:18 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
23:31 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
23:43 < wumpus> jonatack: using @ in your ACK messages is messing with the github-merge script :)
23:44 < wumpus> (it has a detection for those to avoid @... mentions that would cause spam with github's email notification so it makes it warn about @'s in the merge message)
23:46 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-dev
23:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:50 < bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7b975639ef93...8ffaf5c2f5aa
23:50 < bitcoin-git> bitcoin/master 95e61c1 Andrew Chow: Move Hashers to util/hasher.{cpp/h}
23:50 < bitcoin-git> bitcoin/master 210b693 Andrew Chow: Add generic SaltedSipHasher
23:50 < bitcoin-git> bitcoin/master 281fd1a Andrew Chow: Replace KeyIDHasher with SaltedSipHasher
23:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:51 < bitcoin-git> [bitcoin] laanwj merged pull request #19935: Move SaltedHashers to separate file and add some new ones (master...mv-saltedhash) https://github.com/bitcoin/bitcoin/pull/19935
23:51 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:52 -!- BGL [~twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
23:54 < wumpus> darosior: yes, the release notes are in the wiki during the release candidate phase for easy editing
23:57 < wumpus> darosior: invited you to the "frequent contributors" group for bitcoin and bitcoin-core orgs (this is not currently a requirement for editing the wiki but will likely become so)
--- Log closed Wed Jan 13 00:00:14 2021