--- Log opened Thu Mar 04 00:00:46 2021
00:10 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
00:27 -!- landakram [~mark@2601:643:8002:3f20:9eb6:d0ff:fef0:5981] has quit [Ping timeout: 240 seconds]
00:28 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has joined #bitcoin-core-dev
00:29 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-nimakvacfthwvsmg] has joined #bitcoin-core-dev
00:29 -!- jarolrod_ [sid475272@gateway/web/irccloud.com/x-xgqmsomclcrfgckc] has joined #bitcoin-core-dev
00:29 -!- michaelfolkson2 [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined #bitcoin-core-dev
00:29 -!- eragmus_ [sid136308@gateway/web/irccloud.com/x-uddttftymtbhneef] has joined #bitcoin-core-dev
00:29 -!- glozow_ [sid453516@gateway/web/irccloud.com/x-halahfbtacapjfun] has joined #bitcoin-core-dev
00:29 -!- amiti_ [sid373138@gateway/web/irccloud.com/x-fwysclwpgofmexkv] has joined #bitcoin-core-dev
00:29 -!- jessepos_ [~jp@2601:645:200:162f:3167:e7cf:cd0a:198e] has joined #bitcoin-core-dev
00:29 -!- nejon_ [sid38993@gateway/web/irccloud.com/x-yasjxziehzsimuyv] has joined #bitcoin-core-dev
00:30 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
00:30 -!- Abelian_ [sid2662@gateway/web/irccloud.com/x-aohpwcgvzdqxkchw] has joined #bitcoin-core-dev
00:30 -!- infernixx [nix@unaffiliated/infernix] has joined #bitcoin-core-dev
00:31 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
00:32 -!- helo_ [~helo@2604:a880:800:10::15:2001] has joined #bitcoin-core-dev
00:35 -!- _flow__ [~none@salem.informatik.uni-erlangen.de] has joined #bitcoin-core-dev
00:43 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca00fdd1784d01507960.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:43 -!- Netsplit *.net <-> *.split quits: eragmus, Norrin, infernix, glozow, amiti, jarolrod, michaelfolkson, Abelian, brg444, helo,  (+6 more, use /NETSPLIT to show all of them)
00:43 -!- Lightsword_ is now known as Lightsword
00:43 -!- brg444_ is now known as brg444
00:43 -!- eragmus_ is now known as eragmus
00:43 -!- infernixx is now known as infernix
00:43 -!- Abelian_ is now known as Abelian
00:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:43 -!- glozow_ is now known as glozow
00:43 -!- nejon_ is now known as nejon
00:43 -!- amiti_ is now known as amiti
00:47 -!- Norrin [~Joe@2605:2700:0:5::4713:9659] has joined #bitcoin-core-dev
01:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
01:15 < vasild> wumpus: wrt torv2 - if torv2 addresses are non-operational on the tor network, then I think we want to stop trying to connect to such ones and maybe even purge them from addrman.
01:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
01:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:17 < bitcoin-git> [bitcoin] laanwj pushed 15 commits to master: https://github.com/bitcoin/bitcoin/compare/d099894ec124...92b7efcf54d3
01:17 < bitcoin-git> bitcoin/master 9d5313d Anthony Towns: move-only: Add txorphanage module
01:17 < bitcoin-git> bitcoin/master 81dd57e Anthony Towns: txorphanage: Pass uint256 by reference instead of value
01:17 < bitcoin-git> bitcoin/master 38a11c3 Anthony Towns: txorphanage: Add lock annotations
01:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:17 < vasild> jnewbery: ack, 21:00 UTC is usually too late for me, but maybe I will visit the party once in a while :)
01:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:17 < bitcoin-git> [bitcoin] laanwj merged pull request #21148: Split orphan handling from net_processing into txorphanage (master...202102-txorphanage) https://github.com/bitcoin/bitcoin/pull/21148
01:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:27 -!- dviola [~diego@187.39.20.240] has left #bitcoin-core-dev []
01:28 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
01:30 < wumpus> vasild: I'd agree--though the current situation seems more subtle: they still work on the tor network, but future Tor releases will no longer support them, I think with old tor versions they will still work for a while
01:31 < vasild> hmm, right
01:31 < wumpus> vasild: so we might want to make it an option first ! no strong preference though
01:31 < vasild> nothing can prevent old tor nodes from exchaning torv2 between themselves
01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:31 < wumpus> if there is wider agreement to nuke v2 support completely for 0.22 that's ok with me
01:32 < vasild> I am not sure either, when is 22.0 freeze?
01:33 < vasild> "when is the 22.0 freeze"
01:33 < fanquake> #20851
01:33 < wumpus> currently planned for 2021-06-15
01:33 < gribble> https://github.com/bitcoin/bitcoin/issues/20851 | Release schedule for 22.0 · Issue #20851 · bitcoin/bitcoin · GitHub
01:33 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca00fdd1784d01507960.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
01:34 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca004363a2e8cd9c70d9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:35 < vasild> lets see how connecting to torv2 nodes works in e.g. beginning of June and decide then what to do: 1. do nothing, 2. introduce an option --ignore-torv2 with default of false, 3. --ignore-torv2 with default of true, 4. unconditionally ignore torv2 without any new options
01:36 < wumpus> right, good summary of the options
01:38 < vasild> a test may be something like: run (old) tor node that supports torv2, pick e.g. 100 torv2 addresses from addrman and try to connect each one of them
01:56 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:56 < aj> wumpus: i have a draft branch that moves g_cs_orphans into TxOrphanage, it's mentioned in one of the comments
01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:01 < wumpus> aj: thanks, good to know (i tried to read the comments but there's so many of them + github likes to play hide and seek with them)
02:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:05 < bitcoin-git> [bitcoin] t-bast opened pull request #21359: rpc: include_unsafe option for fundrawtransaction (master...fund-raw-transaction-allow-unsafe) https://github.com/bitcoin/bitcoin/pull/21359
02:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:07 < aj> wumpus: yep. https://github.com/bitcoin/bitcoin/pull/21148#discussion_r585725021 fwiw
02:08 < aj> wumpus: anyway, will open a pr for it sometime soonish (expect the net/chrono and addr-to-net-processing PRs will end up having to come first due to touching related code though)
02:14 -!- tredaelli [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:14 -!- tredaelli is now known as timothy
02:19 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
02:26 < aj> jnewbery: i think aim for merging chrono before addr, yeah?
02:37 < jnewbery> vasild: sorry :( There's no time slot that's nice for everyone and 21:00 UTC seems to minimimze ∑(inconvenience)
02:41 < jnewbery> aj: I don't mind rebasing addr if chrono gets in first, and chrono seems to have a few more engaged reviewers at this point, so yeah lets get that in.
02:44 < vasild> jnewbery: right, can't make it convenient for everybody without a time machine :)
02:45 < fanquake> after a while you get very good at speed reading irc logs
02:57 -!- belcher_ is now known as belcher
03:09 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
03:17 -!- michaelfolkson2 is now known as michaelfolkson
03:18 -!- Jordy86Stiedeman [~Jordy86St@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:44 < aj> MarcoFalke: how frequently does drahtbot update it's conflicts comments?
03:52 -!- gimps [~gimps@139.28.218.148] has quit [Remote host closed the connection]
04:14 -!- Jordy86Stiedeman [~Jordy86St@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:14 < bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/92b7efcf54d3...33921379b6bb
04:14 < bitcoin-git> bitcoin/master 4d98b40 Pieter Wuille: Change all ping times to std::chrono types
04:14 < bitcoin-git> bitcoin/master c733ac4 Pieter Wuille: Convert block/header sync timeouts to std::chrono types
04:14 < bitcoin-git> bitcoin/master 55e8288 Pieter Wuille: Make all Poisson delays use std::chrono types
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:14 < bitcoin-git> [bitcoin] fanquake merged pull request #21015: Make all of net_processing (and some of net) use std::chrono types (master...pr-20044) https://github.com/bitcoin/bitcoin/pull/21015
04:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:15 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
04:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
04:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:21 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33921379b6bb...7450a01691e8
04:21 < bitcoin-git> bitcoin/master fa59ad5 MarcoFalke: fuzz: Add missing include (test/util/setup_common.h)
04:21 < bitcoin-git> bitcoin/master 7450a01 fanquake: Merge #21358: fuzz: Add missing include (test/util/setup_common.h)
04:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:21 < bitcoin-git> [bitcoin] fanquake merged pull request #21358: fuzz: Add missing include (test/util/setup_common.h) (master...2103-fuzzInc) https://github.com/bitcoin/bitcoin/pull/21358
04:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:29 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7450a01691e8...83bdbbd300bb
04:29 < bitcoin-git> bitcoin/master fa576b4 MarcoFalke: Move MakeNoLogFileContext to common libtest_util, and use it in bench
04:29 < bitcoin-git> bitcoin/master 83bdbbd fanquake: Merge #21003: test: Move MakeNoLogFileContext to libtest_util, and use it ...
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:29 < bitcoin-git> [bitcoin] fanquake merged pull request #21003: test: Move MakeNoLogFileContext to libtest_util, and use it in bench (master...2101-benchNoLog) https://github.com/bitcoin/bitcoin/pull/21003
04:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:35 -!- skinkie1 [~skinkie@178.239.168.171] has joined #bitcoin-core-dev
04:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:36 < bitcoin-git> [bitcoin] fanquake closed pull request #21341: build: removing xcrun from darwin build (master...removing_xcrum) https://github.com/bitcoin/bitcoin/pull/21341
04:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
05:07 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Read error: Connection reset by peer]
05:25 -!- tlev [~tlev@li120-195.members.linode.com] has quit [Quit: Ping timeout (120 seconds)]
05:45 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
05:47 -!- tlev [~tlev@li120-195.members.linode.com] has joined #bitcoin-core-dev
05:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:56 < bitcoin-git> [bitcoin] laanwj pushed 17 commits to master: https://github.com/bitcoin/bitcoin/compare/83bdbbd300bb...702cfc8c531d
05:56 < bitcoin-git> bitcoin/master 9da106b Carl Dong: validation: Check chain tip is non-null in CheckFinalTx
05:56 < bitcoin-git> bitcoin/master 4927c9e Carl Dong: validation: Remove global ::LoadGenesisBlock
05:56 < bitcoin-git> bitcoin/master a3ba08b Carl Dong: validation: Remove global ::{{Precious,Invalidate}Block,ResetBlockFailureF...
05:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:56 < bitcoin-git> [bitcoin] laanwj merged pull request #21055: [Bundle 3/n] Prune remaining g_chainman usage in validation functions (master...2020-09-reduce-validation-ccsactiveglobal-usage) https://github.com/bitcoin/bitcoin/pull/21055
05:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
05:57 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
05:58 -!- jespada [~jespada@90.254.243.187] has quit [Ping timeout: 265 seconds]
05:59 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
06:03 -!- jonatack_ [~jon@37.173.203.38] has joined #bitcoin-core-dev
06:03 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 256 seconds]
06:09 -!- jonatack_ [~jon@37.173.203.38] has quit [Quit: jonatack_]
06:21 -!- egp__ [~egp_@2.95.74.168] has quit [Quit: EXIT]
06:22 -!- egp_ [~egp_@2.95.74.168] has joined #bitcoin-core-dev
06:25 -!- egp_ [~egp_@2.95.74.168] has quit [Client Quit]
06:25 -!- JokerAscensionEx [~egp_@2.95.74.168] has joined #bitcoin-core-dev
06:26 -!- JokerAscensionEx [~egp_@2.95.74.168] has quit [Remote host closed the connection]
06:26 -!- JokerAscensionEx [~egp_@2.95.74.168] has joined #bitcoin-core-dev
06:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #bitcoin-core-dev
06:40 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
06:47 -!- Kiminuo [~Kiminuo@141.98.103.76] has joined #bitcoin-core-dev
06:52 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 256 seconds]
06:55 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-core-dev
07:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:02 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/702cfc8c531d...b4d22654fe9e
07:02 < bitcoin-git> bitcoin/master 7bbb409 Hennadii Stepanov: guix: Update darwin native packages dependencies
07:02 < bitcoin-git> bitcoin/master c967fb7 Hennadii Stepanov: guix: Remove libcap from manifest
07:02 < bitcoin-git> bitcoin/master b4d2265 Wladimir J. van der Laan: Merge #21337: guix: Update darwin native packages dependencies
07:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:02 < bitcoin-git> [bitcoin] laanwj merged pull request #21337: guix: Update darwin native packages dependencies (master...210302-cdrkit) https://github.com/bitcoin/bitcoin/pull/21337
07:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:04 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
07:10 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 272 seconds]
07:28 -!- Kiminuo [~Kiminuo@141.98.103.76] has quit [Remote host closed the connection]
07:28 -!- Kiminuo [~Kiminuo@141.98.103.76] has joined #bitcoin-core-dev
07:30 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
07:35 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 245 seconds]
07:38 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
07:46 < MarcoFalke> aj: About once/twice a day, I think
07:53 -!- emzy [~quassel@2a01:4f8:192:628a::83] has quit [Changing host]
07:53 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
07:54 -!- realname192 [~real@37.162.4.110] has joined #bitcoin-core-dev
07:55 -!- mrostecki [mrostecki@nat/suse/x-psigibnclcfhfbgx] has joined #bitcoin-core-dev
07:57 -!- Deinogalerix21 [~Deinogale@165.231.33.140] has joined #bitcoin-core-dev
07:59 -!- Deinogalerix21 [~Deinogale@165.231.33.140] has quit [Client Quit]
08:00 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 260 seconds]
08:02 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
08:02 -!- realname192 [~real@37.162.4.110] has quit [Quit: Leaving]
08:03 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
08:03 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #bitcoin-core-dev
08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #bitcoin-core-dev
08:10 -!- Mercury_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Quit: Leaving]
08:16 -!- Mercury_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
08:27 -!- p0x [~pox@gateway/tor-sasl/pox] has left #bitcoin-core-dev []
08:35 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
08:56 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds]
09:07 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
09:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
09:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
09:27 -!- asdlkfjwerpoicvx [~flack@p200300d46f1aca004363a2e8cd9c70d9.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:30 -!- jessepos_ [~jp@2601:645:200:162f:3167:e7cf:cd0a:198e] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:30 -!- jesseposner [~jp@2601:645:200:162f:3167:e7cf:cd0a:198e] has joined #bitcoin-core-dev
09:30 < jnewbery> MarcoFalke: wen button to bribe drahtbot with lightning to update its comment on my PR?
09:31 < MarcoFalke> pls pr number, jnewbery
09:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:33 < bitcoin-git> [bitcoin] ivanacostarubio opened pull request #21362: qa: testing for the year 2038 problem (master...y2038_tests) https://github.com/bitcoin/bitcoin/pull/21362
09:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:38 < MarcoFalke> Looks like this one was updated an hour ago: https://github.com/bitcoin/bitcoin/pull/21236#issuecomment-782102826
09:51 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has joined #bitcoin-core-dev
09:51 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
09:58 -!- eoin [402b84c0@64.43.132.192] has joined #bitcoin-core-dev
09:59 -!- stortz [b1982408@177.152.36.8] has joined #bitcoin-core-dev
10:01 -!- Kimi [~Kiminuo@141.98.103.76] has joined #bitcoin-core-dev
10:02 -!- lightlike [~lightlike@p200300c7ef1c4d0035e5f1bdebb24717.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:03 -!- Kiminuo [~Kiminuo@141.98.103.76] has quit [Ping timeout: 256 seconds]
10:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
10:12 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 260 seconds]
10:14 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
10:15 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
10:20 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has quit []
10:21 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vbqmiwqebvrkdcvc] has joined #bitcoin-core-dev
10:36 -!- achow101_ is now known as achow101
10:39 -!- jungly [~jungly@host-212-171-255-115.pool212171.interbusiness.it] has quit [Ping timeout: 246 seconds]
10:44 < achow101> anyone else getting a bunch of compiler warnings for FuzzedSock?
10:44 < sipa> yes
10:46 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 264 seconds]
10:47 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
10:48 < MarcoFalke> #21355 
10:48 < gribble> https://github.com/bitcoin/bitcoin/issues/21355 | windows: new -Wreturn-type warnings after #19203 · Issue #21355 · bitcoin/bitcoin · GitHub
10:50 < hebasto> MarcoFalke: #20586 ?
10:50 < gribble> https://github.com/bitcoin/bitcoin/issues/20586 | Fix Windows build with --enable-werror by hebasto · Pull Request #20586 · bitcoin/bitcoin · GitHub
10:52 < MarcoFalke> hebasto: I'd presume that sipa and achow101 use gcc, not mingw
10:52 < hebasto> aah, sorry
10:53 < MarcoFalke> I switched to clang long ago. gcc doesn't seem even remotely stable anymore
10:53 < sipa> how so?
10:54 < MarcoFalke> all the bugs we run into?
10:54 < sipa> the memcmp thing?
10:54 < jonatack> master is clean with clang 9 for me
10:55 < MarcoFalke> Also, the warnings. I think the txmempool std::optional warning is still there, now the return-type warning, ...
10:55 < jonatack> sipa: there were a few false warnings ?
10:55 < jonatack> s/?/^/ what MarcoFalke wrote
10:55 < achow101> This warning is -Woverloaded-virtual
10:56 < achow101> "./util/sock.h:61:19: warning: ‘virtual Sock& Sock::operator=(Sock&&)’ was hidden [-Woverloaded-virtual]"
10:56 < achow101> the txmempool warning is also still there
10:57 < sipa> it can be silenced by replacing with return nullopt;... but that's clearly a bogus warning
10:57 < jonatack> MarcoFalke: which clang are you using nowadays?
10:59 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has quit [Remote host closed the connection]
11:00 -!- rex4539 [~rex4539@gateway/tor-sasl/rex4539] has joined #bitcoin-core-dev
11:00 < wumpus> #startmeeting
11:01 < jonasschnelli_> (again)
11:01 -!- jonasschnelli_ is now known as jonasschnelli
11:01 < jonasschnelli> hi
11:01 < kanzure> hi
11:01 < ajonas> hi
11:01 < hebasto> hi
11:01 < achow101> hi
11:01 < amiti> hi
11:01 < jnewbery> hi
11:01 < wumpus> one proposed meeting topic: blocksonly mode and transaction relay (jnewbery)
11:01 < fjahr> hi
11:01 < wumpus> #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
11:01 < wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
11:01 < sipa> hi
11:02 -!- core-meetingbot` [~meetingbo@static.239.36.216.95.clients.your-server.de] has quit [Quit: 2019.02.23]
11:02 -!- core-meetingbot [~meetingbo@2a01:4f9:2a:2510::2] has joined #bitcoin-core-dev
11:02 < promag> o/
11:02 < wumpus> any last-minute topics?
11:02 < jonatack> hi
11:02 < ajonas> wumpus: I just have a brief mention of the developer survey
11:03 < wumpus> ajonas: great!
11:03 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
11:03 < wumpus> #topic High priority for review
11:03 < jonasschnelli> I added #20664 to the hiprio list
11:04 < wumpus> https://github.com/bitcoin/bitcoin/projects/8   9 blockers, 2 chasing concept ACK
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20664 | Add scanblocks RPC call by jonasschnelli · Pull Request #20664 · bitcoin/bitcoin · GitHub
11:04 < wumpus> does anyone else want to add or remove anything ?
11:04 < jonatack> maybe add #20197 please, if the list isn't too long
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: protect onions in AttemptToEvictConnection(), add eviction protection test coverage by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
11:05 < wumpus> jonatack: added!
11:05 < jonatack> wumpus: ty!
11:06 < wumpus> is there anything (almost) ready for merge?
11:07 < ariard> hi
11:07 < achow101> #20536 has 3 acks
11:07 < gribble> https://github.com/bitcoin/bitcoin/issues/20536 | wallet: Error with "Transaction too large" if the funded tx will end up being too large after signing by achow101 · Pull Request #20536 · bitcoin/bitcoin · GitHub
11:07 < elichai2> hi
11:07 < MarcoFalke> hi
11:07 < ajonas> There are a few old tests that have got some new review... nothing major though
11:08 < wumpus> achow101: good to know
11:08 < ajonas> #18795, #19393, #14604
11:08 < wumpus> i guess that's all for this topic, let's go to next one then
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/18795 | Test: wallet issue with orphaned rewards by domob1812 · Pull Request #18795 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/19393 | test: Add more tests for orphan tx handling by hebasto · Pull Request #19393 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/14604 | tests: Add test and refactor feature_block.py by sanket1729 · Pull Request #14604 · bitcoin/bitcoin · GitHub
11:09 < wumpus> ajonas: thank you
11:09 < wumpus> #topic Blocksonly mode and transaction relay (jnewbery)
11:09 < jnewbery> hello!
11:10 < jnewbery> There is a `-blocksonly` option in Bitcoin Core, which disables transaction relay for a node.
11:10 < jnewbery> It does this by setting fRelay=false on the version message on all of its connections.
11:10 < jnewbery> This was added in PR #6993 and was made a public documented option #15990 (https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md#4-turn-off-transaction-relay--blocksonly)
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/6993 | Add -blocksonly option by pstratem · Pull Request #6993 · bitcoin/bitcoin · GitHub
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/15990 | Add tests and documentation for blocksonly by MarcoFalke · Pull Request #15990 · bitcoin/bitcoin · GitHub
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
11:10 < jnewbery> One strange (and potentially footgun-ish aspect) of -blocksonly is that if a transaction is submitted to the node over RPC, or sent by a whitelisted peer, then the node will relay that transaction to all its peers.
11:10 < jnewbery> This makes it very obvious that the node is the origin of the transaction, since it doesn't relay any other transaction!
11:11 < jnewbery> Are there legitimate use cases for this behaviour?
11:11 < ariard> I would say emergency broadcast, you don't care about the privacy
11:11 < sipa> fRelay=false is also set in other cases, right?
11:11 < sipa> for blocks relay connections, even if you're not in blocksonly mode?
11:11 < ariard> like when your main node is upgrading/power outage/...
11:12 < jnewbery> by Bitcoin Core? We set fRelay=false for -blocksonly mode, or for the block-relay-only connections, even if you're not in -blocksonly mode
11:12 < sipa> oh, nvm, i was confusing things; this isn't relevant
11:12 < jnewbery> bloom filter clients also set fRelay=false when connecting to supress tx relay until they've loaded the filter
11:13 < sipa> i'm not sure what the right behavior is
11:13 < sipa> it's clearly a privacy leak, but i think it would also be incorrect to just not relay
11:13 < wumpus> maybe reject it by default but add a 'force' flag to override, i dunno
11:13 < sipa> there is an expectation that a transaction is relayed if you call sendrawtransaction
11:14 < fjahr> I was just going to suggest a force flag too
11:14 < wumpus> yea failing silently would be the worst of both worlds
11:14 < ariard> yeah force flag sounds good
11:14 < jonasschnelli> +1 for the force flag
11:14 < jnewbery> always fail sendrawtransaction if -blocksonly is set?
11:14 < jonasschnelli> jnewbery: seems a bit to hand-holdish
11:14 < MarcoFalke> Seems a bit too hand-holdish to add a force flag for this
11:15 < MarcoFalke> The privacy leak is well documented in the option help
11:15 < jnewbery> a force flag seems the worst of all worlds
11:15 < sdaftuar> can't someone use bitcoin-qt in blocksonly mode? i'm not understanding hte force flag in that scenario
11:15 < sdaftuar> some warnign popup i guess?
11:15 < jonasschnelli> The GUI could have a warning, yes.
11:15 < jnewbery> oh, one thing I should add: -blocksonly will soft-set -walletbroadcast to false
11:15 < jonasschnelli> Which is more or less the UX adaption of a "force" CLI flag
11:15 < luke-jr> MarcoFalke: it fits well with your force-past-policy PR
11:15 < wumpus> it doesn't imply walletbroadca.. right
11:16 < wumpus> so we did think of that
11:16 < jonatack> sendrawtransaction help states the issue clearly
11:16 < jonasschnelli> sendrawtransaction respectes walletbroadcast?
11:16 < MarcoFalke> as jnewbery points out the wallet should disable the broadcast with blocksonly
11:16 < jnewbery> I don't expect users to understand the privacy implications of this. Putting an option in the GUI seems overly complex
11:16 < wumpus> i also remember this came up before
11:16 < MarcoFalke> but the rpc is separate
11:16 < sdaftuar> so are we only talking about changing behavior in the case that -blocksonly=true and -walletbroadcast=true?
11:16 < jnewbery> sendrawtransaction is not a wallet rpc, so should have no interaction with walletrebroadcast
11:17 < sdaftuar> if the user has set that, it seems clear waht the intent is
11:17 < luke-jr> sdaftuar: the intent of sendrawtransaction is also clear and contradicts it
11:17 < wumpus> sdaftuar: +1
11:17 < MarcoFalke> luke-jr: It doesn't contradict. It overwrites for a specific tx
11:18 < jonasschnelli> if you don't have transaction relay, doesn't the wallet always need manual fee settings (problematic either)?
11:18 < MarcoFalke> jonasschnelli: This is also documented
11:18 < jnewbery> jonasschnelli: indeed
11:18 < MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md#4-turn-off-transaction-relay--blocksonly
11:18 < gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
11:18 < MarcoFalke> If we assume that no one reads the docs, what is the point of adding it in the first place.
11:19 < jonasschnelli> yes. that is a valid point.
11:19 < jonasschnelli> Maybe we should expect people read the docs
11:19 < jnewbery> My baseline assumption is that users don't read docs
11:19 < amiti> MarcoFalke: I think its not boolean? I'd expect some users to read docs, but not all
11:19 < sipa> i'm a bit confused about the context... this is only about the sendrawtransaction RPC, not about wallet sending?
11:19 < jnewbery> and I don't think documenting bad behaviour is better than removing bad behaviour
11:19 < jonasschnelli> jnewbery: if so, how do they even find out about the blocksonly mode? :-)
11:20 < luke-jr> jonasschnelli: reading *some* docs but not others! XD
11:20 < MarcoFalke> sipa: I think this is a general discussion about the version message fRelay field
11:20 < jnewbery> jonasschnelli: because someone suggests that they enable it on a twitter thread to save themselves some bandwidth?
11:20 < jonasschnelli> yes... that
11:20 < sipa> what specifically are we discussing changing?
11:20 < sdaftuar> the followup question to this, i believe, is whether it's reasonable for our software to ignore transactions from a peer that has set fRelay=false -- do i have that right jnewbery?
11:21 < jnewbery> sdaftuar: that's the wider context, yes
11:21 < sdaftuar> so this question is to establish whether our current relay behavior is sort of reasonable at all
11:21 < jonasschnelli> Aren't there any valid use-cases that use blocksonly & wallet broadcast (like a private network, designated connection)?
11:21 < MarcoFalke> jnewbery: There is the use case where the node(s) with blocksonly only connect to trusted nodes. It seems too broad to call the feature bad
11:22 < jonasschnelli> Agree with MarcoFalke
11:22 < sipa> MarcoFalke: i'd expect people to set whitelisting in that case, though (or they'll experience more broken behavior)
11:22 < sipa> like rebroadcasting won't work
11:22 < jnewbery> I don't understand this use case
11:23 < sdaftuar> sipa: i think rebroadcasting would work fine? it'll relay to your node in the same circumstances that your node would succeed in relaying it to their peers, no?
11:23 < luke-jr> jnewbery: maybe the user just doesn't care about privacy?
11:23 < jnewbery> luke-jr: that's fair, but is that a use case we want to support?
11:23 < luke-jr> …
11:24 < MarcoFalke> sipa: sendrawtrasnaction is designed to do a rebroadcast every time you call it
11:24 < sipa> MarcoFalke: right, but wallet rebroadcasting won't work, because alreadyhave logic will think the (only) peer already has it
11:24 < MarcoFalke> permission flags can't override the inv-getdata filter either, IIRC
11:24 < sipa> not alreadyhave; inventoryknown
11:25 < MarcoFalke> your inventoryknown is the other peer's alreadyhave ;)
11:25 < sipa> hmm, fair; even if you announce again, the peer won't fetch it again
11:25 < sipa> i'm confused now
11:25 < jnewbery> transaction relay is a public network function, and it should be designed in such a way that is optimal for users connecting to public networks
11:25 < sipa> i thought that was the reason we introduced whitelisting in the first place
11:25 < luke-jr> jnewbery: I never liked the idea of telling users what they can and can't do. And if Core is going to do that, at least the protocol needs to be neutral.
11:26 < sdaftuar> oh! we never clear filterInventoryKnown? that seems potentially problematic
11:26 < amiti> I find it unexpected that the default behavior of -blocksonly mode is to disable wallet broadcast, but if you submit via sendrawtransaction RPC the node will still relay your transaction 
11:26 < sipa> doesn't look like it
11:26 < sipa> amiti: that's inconsistent for sure
11:26 < sipa> but i don't really know what to do about it
11:27 < jnewbery> I'm still curious about the supposed use cases. jonasschnelli and MarcoFalke thing there are use cases, but I don't understand them
11:27 < ariard> actually you can be willingly to not participate in tx-relay to mask your connection graph
11:27 < ariard> and only broardcat when you really need it
11:27 < amiti> sipa: what's the issue with just giving the user an error message if  they attempt sendrawtransaction?
11:28 < amiti> maybe not desirable, but one way to make it consistent
11:28 < jonasschnelli> jnewbery: Assume someone runs a blockonly node at home (bandwith) but connects it to a trusted peer over wireguard
11:28 < MarcoFalke> sendrawtransaction is explicitly called. Wallet broadcast is implicit, so I think the current behavior makes sense
11:28 < MarcoFalke> (It is possible to enable wallet broadcast explicitly as well)
11:29 < amiti> MarcoFalke: fair
11:29 < jnewbery> jonasschnelli: that'd associate all of your transactions to your node
11:29 < luke-jr> bandwidth vs privacy is a tradeoff. Users may prefer bandwidth.
11:29 < sdaftuar> jnewbery: does that matter to tor users?
11:29 < MarcoFalke> jnewbery: Which is no problem because you control the other node
11:29 < lightlike> Am I right to assume that this issue with sendrawtransaction doesn't apply to regular blocks-only connections in normal mode - only in full blocksonly mode?
11:29 < ariard> but even if you don't control the other node, you prefer the transaction propagating over the privacy gain
11:29 < jnewbery> MarcoFalke. Presumably the home node is relaying the transaction on to the network?
11:29  * luke-jr wonders if Tor nodes can/should make a dedicated connection just for broadcast
11:29 < amiti> lightlike: yes
11:29 < ariard> you *might* prefer (e.g time-sensitive txn)
11:30 < MarcoFalke> sdaftuar: If you don't control the tor node, I'd say yes. (The other peer will learn your whole wallet contents over time)
11:30 < sipa> so sendrawtransaction does not relay over fRelay=false connections in general, only in -blocksonly mode?
11:30 < jnewbery> sipa: I belive that is correct
11:30 < sipa> curious
11:30 < MarcoFalke> sendrawtransaction will send it out to all peers that have send you a fRelay=true
11:30 < sdaftuar> fRelay=false isn't a "category" of connection, really
11:30 < luke-jr> jnewbery: in that scenario, the home node talks exclusively to your dedicated server somewhere over VPN
11:31 < MarcoFalke> sendrawtransaction doesn't take into account what fRelay you sent to the peer
11:31 < sdaftuar> we have full-relay-outbound connections, which might actually be fRelay=false if we're in -blocksonly mode
11:31 < jnewbery> luke-jr: I don't think that's what jonasschnelli was describing
11:31 < sipa> ah, i see
11:31 < sdaftuar> but we treat them as our tx relay peers anyway (which is correct, in the sense that fRelay=false only instructs our peer to not relay to us, not the other way around)
11:31 < sipa> jnewbery: that's how i interpret jonasschnelli's scenario as well
11:31 < jonasschnelli> yes. m2
11:32 < sipa> (only one connection, blocksonly to a trusted peer; you don't care about privacy w.r.t. that peer)
11:33 < sipa> i think in general "i don't care about privacy w.r.t. this peer" is something to be captured by whitelisting
11:33 < sipa> but of course... who knows what people read
11:33 < luke-jr> hmm
11:33 < MarcoFalke> Another use case might be to create a larger gap from your hot wallet to the live p2p network (multiprocess isn't a thing yet)
11:33 < ariard> sipa: whitelisting is static, you might willingly to bypass "i don't care about privacy w.r.t this peer" for a one-shot broadcast
11:33 < MarcoFalke> sipa: It is called permission flags now ;)
11:33 < sipa> MarcoFalke: right, thanks
11:34 < jnewbery> ah, thank you. I was misunderstanding. I think if you control both ends of the connection, then it'd make more sense for the home node to set feefilter=max to the trusted peer
11:34 < sipa> ariard: that seems more like something you'd want for tor connections (and as a specific way of broadcasting transactions)
11:35 < MarcoFalke> And permission flags don't work for outbound connections (yet)
11:35 < luke-jr> MarcoFalke: have a PR for that for a year+ now :P
11:35 < wumpus> what is holding it up?
11:36 < luke-jr> lack of review last I checked
11:36 < MarcoFalke> either that or "Needs rebase"
11:36 < sipa> pr number?
11:36 < sipa> (mentioning it here may help :p)
11:36 < wumpus> yes
11:36 < luke-jr> #17167
11:36 < gribble> https://github.com/bitcoin/bitcoin/issues/17167 | Allow whitelisting outgoing connections by luke-jr · Pull Request #17167 · bitcoin/bitcoin · GitHub
11:36 < luke-jr> looks like it needs rebase at the moment
11:36 < MarcoFalke> jnewbery: Sending feefilter=max to the trusted peer could work
11:37 < wumpus> i have always liked the idea of being able to whitelist ^D^D permission outgoing connections
11:37 < jnewbery> 17167 has needed rebase since December
11:37 < MarcoFalke> jnewbery: Can we replace fRelay with feefilter=max?
11:37 -!- adria22 [b2ede236@178.237.226.54] has joined #bitcoin-core-dev
11:37 < jonasschnelli> The current wallet broadcast in normal operations isn't privacy preserving either (AFAIK without dandelion or similar)?
11:37 < jonatack> FWIW regarding fRelay, I mentally rename it to m_wants_tx_relay
11:37 < luke-jr> if there's renewed interest I can go ahead and rebase it
11:38 < MarcoFalke> jonasschnelli: I think the wallet broadcast has been reworked to be less agressive
11:38 < sdaftuar> MarcoFalke: would we then require that the peer support feefilter to stay connected?
11:38 -!- adria22 [b2ede236@178.237.226.54] has quit [Client Quit]
11:38 < jonasschnelli> sure. AFAIK chainanalysis companies are still able to capture it
11:39 < amiti> jonasschnelli: no its not, but I'm working on it :) #21061
11:39 < gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
11:39 -!- adria22 [b2ede236@178.237.226.54] has joined #bitcoin-core-dev
11:39 < jonasschnelli> amiti: nice
11:39 -!- adria22 [b2ede236@178.237.226.54] has quit [Client Quit]
11:39 < jonasschnelli> Just saying because if we flag blockonly privacy leaking we imply normal operation isn't
11:39 < MarcoFalke> sdaftuar: We also assume the node to support BIP 60 for blocksonly, so it is not a large change?
11:40 -!- adria22 [b2ede236@178.237.226.54] has joined #bitcoin-core-dev
11:40 < sipa> if we believe that wallet privacy is a lost cause, there is no reason to improve it; but i don't think it is, and with improvements in the pipeline i don't think suboptimal privacy right now is a reason not to think about other issues
11:40 < MarcoFalke> (nodes will be disconnected if they don't support BIP 60, no?)
11:40 < sdaftuar> MarcoFalke: well my guess is that bip37/bip60 is more widely supported on the network. feefilter has always been optional
11:40 < jnewbery> MarcoFalke: BIP60 is version 70002. feefilter is version 70013.
11:40 < amiti> sipa: strong +1
11:40 < jonasschnelli> yes. thats a good point sipa
11:41 -!- adria22 [b2ede236@178.237.226.54] has quit [Client Quit]
11:41 < jnewbery> but I think being able to send feefilter before verack would be nice
11:41 -!- adria22 [b2ede236@178.237.226.54] has joined #bitcoin-core-dev
11:41 < sipa> still, i'm not sure exactly what we're talking about? blocksonly + sendrawtransaction? or also blocksonly + walletbroadcast + wallet send? something else?
11:41 -!- adria22 [b2ede236@178.237.226.54] has quit [Client Quit]
11:41 < sdaftuar> but wait feefilter doesn't help right jnewbery?
11:42 < jnewbery> feefilter doesn't help here, no
11:42 < jnewbery> we'd still need BIP 338
11:42 < wumpus> both security and privacy are always about making attacks marginally more difficult/expensive, not absolutes, would not call it a lost cause
11:42 < jnewbery> some way to signal tx relay
11:43 < sipa> wumpus: right, my point was that sometimes an argument of "you're trying to improve X, but X is always going to be bad because of Y, and we can't fix Y" is a valid argument not to work on something... but i don't think that's the case here
11:44 < jnewbery> sipa: the specific reason I'm asking is that other than these edge cases, fRelay=false means "I don't want txs on this connection and I'll never send txs on this connection". That's a nice property
11:44 < sipa> what happens right now if someone runs bitcoin-qt in -blocksonly mode and creates a transaction?
11:44 < sdaftuar> that's only true in a world where NODE_BLOOM isn't supported
11:44 < jnewbery> I was trying to understand if those edge cases are actually important, or whether they're just things that people are speculating about
11:44 < jonatack> jnewbery: only the first of the two?
11:44 < jnewbery> *only true for nodes that don't support serving bloom filters, yes
11:45 < luke-jr> jnewbery: didn't sdaftuar just add a new flag for that?
11:45 < sipa> while still supporting fRelay
11:45 < wumpus> sipa: sure, agree
11:45 < sdaftuar> luke-jr: not merged yet
11:45 < jnewbery> sipa: it wouldn't be broadcast because walletbroadcast is set to false. I don't know what the GUI shows
11:46 < sipa> that seems bad
11:46 < luke-jr> sdaftuar: right, but it would make fRelay having this property redundant..?
11:46  * sipa conjectures that barely anyone uses -blocksonly on nodes they actually use as wallets
11:46 < jnewbery> this was also my conjecture
11:46 < sdaftuar> luke-jr: i think jnewbery's proposal is to scrap the BIP
11:46 < luke-jr> ah
11:47 < wumpus> i don't think blocksonly was ever officially supported for the GUI, it works, sure
11:47 < MarcoFalke> so replace BIP338 with a breaking p2p change and blocksonly meaning "feefilter=max"?
11:47 < jnewbery> my original proposal was to script fRelay, but it seems that people rely on it to mean 'blocks only'
11:47 < wumpus> but it was originally intended to be some kind of internal, rarely used thing
11:47 < wumpus> not something GUI end users would face
11:47 < jnewbery> *scrap fRelay
11:48 < ariard> fwiw, core doesn't even commit to bip60 as a supported bip
11:48 < MarcoFalke> ariard: It only does when -blocksonly
11:48 < darosior> Fwiw i believe the GUI would show a fee estimation error in this case if no fallbackfee is set
11:48 < wumpus> e.g. there is no configuration dialog option to enable it
11:48 < sipa> darosior: fair point
11:49 < ariard> MarcoFalke: i mean here https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md, for a dev writing another bitcoin client and trying to understand core behavior
11:49 < wumpus> darosior: i think so too
11:49 < sipa> we don't support bip60 and never have
11:49 -!- jungly [~jungly@host-212-171-255-115.pool212171.interbusiness.it] has joined #bitcoin-core-dev
11:49 < jonasschnelli> darosior: Yes. It will. But users with just set a manual fee
11:49 < sipa> or at least, we don't assume our peers do
11:49 < luke-jr> sipa: we send it
11:49 < luke-jr> iirc
11:49 < jnewbery> we always send fRelay, but don't expect our peers to
11:50 < sipa> luke-jr: BIP60 is about predictably-sized version messages, not just the fRelay flag
11:50 < jnewbery> we also don't require that our peers send starting height, subversion, etc
11:50 < luke-jr> sipa: but on the sender side
11:51 < sdaftuar> sipa: but we're compatible with bip60 peers, and i think we now expect our peers to always read our fRelay flag if its' set to false, right? 
11:51 < ariard> even the original bip37 is really unclear if fRelay semantic is to disable tx-relay or just tx-announcement
11:51 < luke-jr> it doesn't require breakign non-BIP60 peers
11:51 < sipa> sdaftuar: hmm, true
11:51 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
11:52 < jnewbery> sdaftuar: you mean we expect them to read fRelay because we'll disconnect them if they send us a tx?
11:52 < sdaftuar> right, if we set fRelay=false i think we now disconnect if they ignore it
11:52 < ariard> unless you signal NODE_BLOOM
11:53 < MarcoFalke> Bitcoin Core implements BIP60, but doesn't require peers to implement it. (Like any other optional BIP)
11:53 < jnewbery> I'm not sure we do disconnect peers for that
11:53 < amiti> orly? I thought we disconnected for that too
11:54 < sdaftuar> jnewbery: it is possible i'm misremembering , i know i thought this at some point in the past and was wrong
11:54 < sipa> so i guess we could list BIP60 as implemented, actually
11:54 < MarcoFalke> jnewbery: I am pretty sure there is a "tx sent in violation of protocol" log
11:54 < ariard> iirc #15759 introduce the change of disconnecting block-relay-only peers sending us a transaction
11:54 < gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
11:55 < jnewbery> but not if we send fRelay=false because we're in -blocksonly
11:55 < wumpus> 5 minutes to go for the meeting, ajonas still had an announcement wrt the developer survey
11:55 < MarcoFalke> jnewbery: Oh, I didn't know
11:55 < jnewbery> I may be wrong. I searched for fRelayTxes in net_processing
11:55 < sdaftuar> looks likew e disconnect in that case to me? can look later jnewbery
11:55 < amiti> https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L3001
11:56 < MarcoFalke> (Side note: we  also don't disconnect on feefilter=max violations)
11:56 < ariard> jnewbery: correct this was a pre-15759 behavior
11:56 < jnewbery> sdaftuar: ah, you're right. Thanks!
11:56 < jnewbery> ok, shall we let jonas have his three minutes? :)
11:56 < phantomcircuit> sipa, would the headers sync thing be appropriate in this meeting?
11:56 < wumpus> #topic Developer survey (ajonas)
11:56 < MarcoFalke> m_ignore_incoming_txs means "blocksonly"
11:56 < ajonas> Hi. A summary of the latest dev survey is at https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-retro/. Thank you to everyone who participated.
11:57 < MarcoFalke> ajonas: Thanks for summing those up!
11:57 < jnewbery> MarcoFalke: yup. You're right
11:57 < wumpus> ajonas: thanks for doing this
11:57 < ajonas> Happy to!
11:57 < jnewbery> thank you ajonas!
11:57 < MarcoFalke> One major theme is "It is unclear which status a pr is in". I was thinking how to improve that, but couldn't find a solution
11:58 < ajonas> I think a labeling system might be worth trialing
11:58 < MarcoFalke> Obviously it can't be an objective metric (that a computer could measure), because then it would be gameable
11:58 < amiti> imo, communicating PR status should be the responsibility of the pr author instead of maintainers 
11:58 < ajonas> But we could also add some meta data in the first comment that can be updated over time
11:58 < wumpus> what are the PR statuses in the first place?
11:59 < MarcoFalke> I think the best metric is a heuristic "A pr is closer to merge the more ACKs it has relative to its potential risk"
11:59 < wumpus> i mean we have a few like 'waiting for author' 'needs rebase' but not sure what you mean here
11:59 < ajonas> I think concept / approach ack vs deep code review
11:59 < wumpus> MarcoFalke: yes, definitely
11:59 < MarcoFalke> wumpus: I'd say when there is no "needs rebase" label, the status is implicitly "needs review"
12:00 < wumpus> ok so like 'needs concept ACK'
12:00 < wumpus> we could add that, but yes, like amiti  says, authors have to request this
12:00 < ariard> draft status doesn't mean "needs concept ACK"?
12:00 < MarcoFalke> I am not sure if that makes sense. How would you know when to remove the "needs concept ACK" label?
12:00 < wumpus> ariard: maybe
12:01 < ajonas> I think the use of draft is inconsistent
12:01 < wumpus> ariard: we could use it for that
12:01 < wumpus> MarcoFalke: good point
12:01 < ariard> good thing with draft you can do it just a pr author, doesn't special repo permisions iirc
12:01 < wumpus> yes that is good
12:02 < wumpus> self-organizaing is good, anything that gives the maintainers more on their plate is probably not going to fly
12:02 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
12:03 < amiti> something I'm trying on #21061 is adding an explicit "status" section at the top of OP. not super relevant yet because the PR hasn't gotten much attention, but was hoping to make this easier for reviewers as the comments accumulate
12:03 < wumpus> that concludes the meeting for today
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
12:03 < wumpus> #endmeeting
12:03 < sdaftuar> phantomcircuit: did you see my comments on your PR? curious if you think my description matches what you saw
12:04 < sdaftuar> regarding the headers sync issue
12:04 < wumpus> amiti: right, something like that makes sense, for larger PRs definitely, and if it's in the OP then the author can simply edit it
12:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:04 < bitcoin-git> [bitcoin] hebasto opened pull request #21363: build, qt: Improve Qt static plugins/libs check code (master...210304-qt) https://github.com/bitcoin/bitcoin/pull/21363
12:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:05 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
12:06 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #bitcoin-core-dev
12:06 < amiti> wumpus: yeah, its a bit weird because at the end I'd have to remove status when I thought its RFM? or potentially have the status included in the merge commit? 
12:06 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:07 < sdaftuar> amiti: maybe try to make it the second post instead?  a bit annoying but would solve that issue, too late now though i guess!
12:07 < MarcoFalke> sdaftuar: I think the point is that a miner can't mine a block during IBD? getblocktemplate will fail
12:07 < sdaftuar> MarcoFalke: -maxtipage exists for that exact reason
12:07 < MarcoFalke> ah
12:08 < amiti> sdaftuar: haha, not too late.. I also have description in second post (additional info I thought useful for review, but unnecessary for merge commit) so I could edit, but I think its more useful if its very apparent when someone comes to the page 
12:08 < jonatack> Out of curiosity, has a weekly or fortnightly random review distribution bingo ever been tried? e.g. people sign up to receive a randomly chosen PR to review. It might get people looking at new code or reviewing new people.
12:08 < sipa> jonatack: heh
12:08 < sdaftuar> amiti: ah, nice! btw i did appreciate the extensive background in that PR, will be helpful when i get to it, thanks for doing that!
12:08 < sipa> jonatack: i might sign up
12:09 < amiti> sdaftuar: :) 
12:09 < jonatack> sipa: same
12:10 < jonatack> ajonas: wdyt
12:10 < aj> wow, that was a lot of frelay discussion
12:10 < sipa> morning, aj
12:11 < phantomcircuit> sdaftuar, no i dont think that's right, we don't even inv if we support compact blocks do we?
12:13 < aj> ajonas: your word cloud is almost subliminal messages: "core people think feel time" (we're high?) "code review progress consensus just maybe" (so positive) "PRs work, yes? help contributors process taproot wallet" (bribery?)
12:14 < sipa> needs haiku
12:16 < luke-jr> wut
12:16 < aj> phantomcircuit: isn't that only for the couple of peers we select/who select us for fast compact block relay?
12:17 < sdaftuar> phantomcircuit: i believe that as long as we're out of IBD, we'll always announce a new block via inv, header, or cmpctblock
12:17 < sdaftuar> a header or compactblock will only be sent if we think it will connect to the peer's headers chain, based on prior headers sent or received
12:17 < sdaftuar> (along with other requirements)
12:17 < sdaftuar> so the point is, if a block is found, it should get announced
12:18 < sdaftuar> and if the header doesn't connect, or if we get an inv, i believe we always send a getheaders to the peer that gave us the block
12:19 < sdaftuar> once we have the header chain, we can sometimes direct fetch the blocks (when the header is received), and sometimes we rely on the parallel download logic. i think the latter is the issue, as we don't call it on inbound peers while in IBD, if we have outbound peers
12:20 < sdaftuar> and if we're in IBD the direct fetch is disabled
12:21 < aj> jnewbery: fwiw, i had the idea at one point that -blocksonly could relay dandelion++ stems (of txs that don't depend on in-mempool parents) and get some privacy that way, obv pretty long-term though
12:26 -!- eoin [402b84c0@64.43.132.192] has quit [Quit: Connection closed]
12:27 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
12:30 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
12:34 -!- eoin [402b84c0@64.43.132.192] has joined #bitcoin-core-dev
12:35 < ajonas> aj: you caught me. foiled again!
12:35 -!- promag [~promag@188.250.84.129] has quit [Ping timeout: 264 seconds]
12:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:36 < bitcoin-git> [bitcoin] practicalswift opened pull request #21364: fuzz: Avoid -Wreturn-type warnings (master...–Wreturn-type) https://github.com/bitcoin/bitcoin/pull/21364
12:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:37 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
12:39 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:39 < phantomcircuit> sdaftuar, on receipt of a compact block we only do getheaders if we're not in IBD
12:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
12:41 -!- lukedashjr is now known as luke-jr
12:42 -!- eoin [402b84c0@64.43.132.192] has quit [Quit: Connection closed]
12:42 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
12:42 < sdaftuar> don't we send a getheaders if it doesnt' connect to our tip?
12:44 < sdaftuar> also - we wouldn't get a compact block if we're in IBD because we wouldnt' have told anyone to send us unrequested compact blocks
12:44 < sdaftuar> oh- i see what you're saying, we seem to ignore compact blocks that don't connect if we're in IBD. that is indeed odd.
12:45 < sdaftuar> however i don't think that can be implicated here, as it should never occur
12:46 < sdaftuar> (i also think we should fix that so we treat it the same as an unconnecting header, always)
12:48 < phantomcircuit> sdaftuar, only if we're not in ibd
12:51 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
12:52 < andytoshi> achow101: in BIP174, the test vector "PSBT with unknown types in the inputs" describes an input which has keytype 0x0f and key 0102030405060708. this is a valid PSBT
12:52 < andytoshi> but in PSBT2 it's invalid because keytype 0x0f is now the sequence number
12:52 < andytoshi> is it worth updating the text of PSBT0 for this
12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in]
12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-core-dev
13:03 < achow101> andytoshi: probably. I think I updated it in the implementation pr but not the bip pr
13:03 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 264 seconds]
13:04 < andytoshi> oh ok i'll see if i can find that .. you're saying there's a replacement test vector in the implementation?
13:04 < achow101> yes
13:04 < andytoshi> ah yep https://github.com/bitcoin/bitcoin/pull/21283/commits/73b569c26dc13f6727dd45f1469752890845fa78
13:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
13:06 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
13:08 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
13:09 -!- belcher_ is now known as belcher
13:15 < achow101> andytoshi: I've pushed the updated tests to my bips pr too
13:18 < andytoshi> oh thanks!
13:19 < phantomcircuit> sdaftuar, why would that never occur?
13:24 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
13:27 -!- Kimi [~Kiminuo@141.98.103.76] has quit [Ping timeout: 245 seconds]
13:32 -!- mekster [~mekster@139.180.192.79] has joined #bitcoin-core-dev
13:35 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
13:37 -!- zivl [~zivl@unaffiliated/zivl] has quit [Client Quit]
13:45 < sipa> achow101: do we ever set the requested hashtype flag in PSBTs we create?
13:45 < sipa> (in bitcoin core)
13:48 < achow101> sipa: no
13:49 < achow101> err, I don't think so
13:50 < sipa> to deal with taproot's SIGHASH_DEFAULT (0), i'm thinking of just making SIGHASH_DEFAULT the default everywhere, but in the non-taproot signing function treat SIGHASH_DEFAULT as SIGHASH_ALL
13:51 -!- Guest13_ [~textual@64-18-155-61.starry-inc.net] has joined #bitcoin-core-dev
13:51 < sipa> but if we ever leak a hashtype via PSBT that might result in emitting a 0 there, which other signers would consider nonsensical
13:51 < achow101> seems reasonable
13:52 < sipa> also i think in some places we treat sighash=0 as "unspecified"
13:52 < achow101> yes
13:52 < achow101> I think we would only output a sighash type in a psbt if it was specified in a psbt
13:52 < achow101> and iirc none of the rpcs take a sighash type
13:55 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:58 < sipa> achow101: any reason why this wouldn't work? you create two descriptor wallets, one with keys disabled, and the other doesn't, you import an xpub descriptor in one, and xprv in the other (one for internal and one for real)... you run walletcreatefundedpsbt on one, walletprocesspsbt on the other
13:58 < sipa> i try this, and it correctly signs the first transactions, but not any subsequent ones
13:59 < achow101> change?
13:59 < achow101> it should work, and I think there's tests for it
14:00 < sipa> neither transaction has change inputs, but i do have an internal descriptor imported in both
14:00 < sipa> ok
14:00 < sipa> then it's likely a problem in my changes
14:00 -!- justan0theruser is now known as justanotheruser
14:03 -!- very_sne_ [~very_snea@45.67.96.42] has joined #bitcoin-core-dev
14:05 -!- very_sneaky [~very_snea@45.67.96.18] has quit [Ping timeout: 265 seconds]
14:07 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 260 seconds]
14:11 < luke-jr> #17167 rebase done
14:11 < gribble> https://github.com/bitcoin/bitcoin/issues/17167 | Allow whitelisting outgoing connections by luke-jr · Pull Request #17167 · bitcoin/bitcoin · GitHub
14:11 -!- Guest13_ [~textual@64-18-155-61.starry-inc.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:17 -!- jespada [~jespada@90.254.243.187] has quit [Ping timeout: 240 seconds]
14:20 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
14:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:49 < bitcoin-git> [bitcoin] sipa opened pull request #21365: Basic Taproot signing support for descriptor wallets (master...202102_taproot_sign) https://github.com/bitcoin/bitcoin/pull/21365
14:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:58 -!- parazyd [~parazyd@devuan/developer/parazyd] has joined #bitcoin-core-dev
15:03 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 256 seconds]
15:06 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 276 seconds]
15:08 -!- Guest13 [~textual@64-18-155-61.starry-inc.net] has joined #bitcoin-core-dev
15:12 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:13 -!- victorSN5 [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev
15:15 < achow101> ooh taproot
15:15 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-core-dev
15:15 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Read error: Connection reset by peer]
15:15 -!- victorSN5 is now known as victorSN
15:21 -!- Guest13 [~textual@64-18-155-61.starry-inc.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:22 -!- Guest13 [~textual@64-18-155-61.starry-inc.net] has joined #bitcoin-core-dev
15:27 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 272 seconds]
15:27 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
15:38 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
15:43 < real_or_random> TIL when you click on the file name at the top of the "code comment box" in a review on github, you get the exact commit range the reviewer was looking at when writing the comment
15:50 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 272 seconds]
15:51 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
15:56 -!- jungly [~jungly@host-212-171-255-115.pool212171.interbusiness.it] has quit [Ping timeout: 246 seconds]
15:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 260 seconds]
15:56 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Remote host closed the connection]
15:57 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
15:59 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-core-dev
16:02 < sipa> if i run most wallet functional tests with --valgrind, i get a "Conditional jump or move depends on uninitialised value(s)" on line https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1822
16:03 < sipa> do other people get this too?
16:03 < sipa> current master
16:03 < sipa> if i try to print the values involved it goes away...
16:04 < sipa> "test/functional/wallet_hd.py --valgrind" e.g.
16:10 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
16:11 < jonatack> sipa: the tests run cleanly for me with --valgrind
16:11 < jonatack> (clang 9 debian)
16:12 < sipa> i have it both on ubuntu 21.04 and 20.10
16:12 < sipa> gcc 10.2.0-13ubuntu1 and gcc 10.2.1-20ubuntu1
16:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:13 < jonatack> tried with wallet_basic, wallet_hd, and wallet_multiwallet, using the --valgrind test runner option and also `valgrind test/functional/wallet_...`
16:13 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Ping timeout: 245 seconds]
16:14 < jonatack> i'll try with gcc 10.2.1
16:15 -!- Nebraskka [~Nebraskka@51.83.249.56] has quit [Ping timeout: 245 seconds]
16:15 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Ping timeout: 245 seconds]
16:15 -!- Nebraskka [~Nebraskka@51.83.249.56] has joined #bitcoin-core-dev
16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
16:15 -!- comboy [~quassel@tesuji.pl] has quit [Ping timeout: 245 seconds]
16:15 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-dtwtatudsbdmxdhk] has quit [Ping timeout: 246 seconds]
16:16 -!- victorSN [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev
16:16 -!- rockhouse1 [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev
16:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:16 < bitcoin-git> [bitcoin] theStack opened pull request #21366: refactor: replace util::Ref with std::any (C++17) (master...202012-replace-util_ref-by-std_any) https://github.com/bitcoin/bitcoin/pull/21366
16:16 < sipa> trying to see if i find something with ubsan
16:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:17 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Ping timeout: 245 seconds]
16:17 -!- rockhouse1 is now known as rockhouse
16:17 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined #bitcoin-core-dev
16:17 -!- comboy [~quassel@tesuji.pl] has joined #bitcoin-core-dev
16:20 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-fdehsptnoijbiozc] has joined #bitcoin-core-dev
16:20  * jonatack sees the good ol' txmempool.cpp:897 bogus warning scroll by...
16:23 < sipa> nothing with ubsan
16:37 -!- Aaronvan_ is now known as AaronvanW
16:37 -!- stortz [b1982408@177.152.36.8] has joined #bitcoin-core-dev
16:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
16:47 < jonatack> sipa: ok, saw a bunch of FuzzedSock warnings as achow101 had mentioned, and then test/functional/wallet_hd.py --valgrind reproduces your issue
16:47 < jonatack> gcc (Debian 10.2.1-6)
16:48 < jonatack> Conditional jump or move depends on uninitialised value(s), CWallet::ScanForWalletTransactions(uint256 const&, int, std::optional<int>, WalletRescanReserver const&, bool) (wallet.cpp:1822)
16:48 < sipa> yea
16:48 < sipa> and it disappears whatever i do trying to investigate it
16:49 < jonatack> (heading to sleep now)
16:50 < sipa> jonatack.sleep(28800);
16:51 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
16:53 -!- jonatack_ [~jon@37.171.225.50] has joined #bitcoin-core-dev
16:53 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-dev
16:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 264 seconds]
16:58 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
17:01 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
17:04 -!- jonatack_ [~jon@37.171.225.50] has quit [Ping timeout: 246 seconds]
17:05 -!- jonatack_ [~jon@37.172.247.108] has joined #bitcoin-core-dev
17:08 -!- jonatack_ [~jon@37.172.247.108] has quit [Read error: Connection reset by peer]
17:10 -!- lightlike [~lightlike@p200300c7ef1c4d0035e5f1bdebb24717.dip0.t-ipconnect.de] has quit [Quit: Leaving]
17:11 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
17:11 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving]
17:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
17:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
17:29 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
17:33 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
17:41 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
17:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:42 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/b4d22654fe9e...2620ac4ec308
17:42 < bitcoin-git> bitcoin/master d823936 Hennadii Stepanov: build, doc: Drop libcap-dev from macOS cross-compiling dependencies
17:42 < bitcoin-git> bitcoin/master f7f3829 Hennadii Stepanov: build, doc: Drop libbz2-dev from macOS cross-compiling dependencies
17:42 < bitcoin-git> bitcoin/master 2620ac4 fanquake: Merge #21354: build, doc: Drop no longer required packages from macOS cros...
17:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:42 < bitcoin-git> [bitcoin] fanquake merged pull request #21354: build, doc: Drop no longer required packages from macOS cross-compiling dependencies (master...210303-macos) https://github.com/bitcoin/bitcoin/pull/21354
17:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:45 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-fdehsptnoijbiozc] has quit [Ping timeout: 240 seconds]
17:46 -!- zeropoint[m] [zeropointi@gateway/shell/matrix.org/x-fvjbddazkpfeytnz] has quit [Ping timeout: 265 seconds]
17:46 -!- vdero133[m] [vdero133ma@gateway/shell/matrix.org/x-aocifqbibvwysmuu] has quit [Ping timeout: 240 seconds]
17:50 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 268 seconds]
17:53 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
17:55 -!- IGHOR [~quassel@176.121.4.135] has quit [Ping timeout: 245 seconds]
17:56 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
17:59 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-xhaxtioxrayuwngt] has joined #bitcoin-core-dev
17:59 -!- jespada [~jespada@90.254.243.187] has quit [Ping timeout: 245 seconds]
18:01 -!- jespada [~jespada@90.254.243.187] has joined #bitcoin-core-dev
18:05 -!- zeropoint[m] [zeropointi@gateway/shell/matrix.org/x-hsjzqeovzsxwoctk] has joined #bitcoin-core-dev
18:11 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-xhaxtioxrayuwngt] has quit [Ping timeout: 240 seconds]
18:15 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has quit [Read error: Connection reset by peer]
18:15 -!- rc_423 [~r_423@cpe-75-185-100-189.cinci.res.rr.com] has joined #bitcoin-core-dev
18:15 -!- vdero133[m] [vdero133ma@gateway/shell/matrix.org/x-hpbiyhjfkpokbvgf] has joined #bitcoin-core-dev
18:18 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has quit [Ping timeout: 258 seconds]
18:21 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has joined #bitcoin-core-dev
18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:31 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2620ac4ec308...fbf5d16238d6
18:31 < bitcoin-git> bitcoin/master 6a0a6e7 Russell O'Connor: Correction for VerifyTaprootCommitment comments
18:31 < bitcoin-git> bitcoin/master fbf5d16 fanquake: Merge #21246: doc: Correction for VerifyTaprootCommitment comments
18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:31 < bitcoin-git> [bitcoin] fanquake merged pull request #21246: doc: Correction for VerifyTaprootCommitment comments (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21246
18:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:43 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fbf5d16238d6...da8c7edffe0c
18:43 < bitcoin-git> bitcoin/master 3f36468 practicalswift: fuzz: Avoid -Wreturn-type warnings
18:43 < bitcoin-git> bitcoin/master da8c7ed fanquake: Merge #21364: fuzz: Avoid -Wreturn-type warnings
18:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:43 < bitcoin-git> [bitcoin] fanquake merged pull request #21364: fuzz: Avoid -Wreturn-type warnings (master...–Wreturn-type) https://github.com/bitcoin/bitcoin/pull/21364
18:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:43 -!- Guest13 [~textual@64-18-155-61.starry-inc.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:46 -!- chrisguidaOld[m] [chrisguida@gateway/shell/matrix.org/x-uziypwmaednbgohz] has joined #bitcoin-core-dev
18:57 < fanquake> sipa: I see it. Opened #21367
18:57 < gribble> https://github.com/bitcoin/bitcoin/issues/21367 | ScanForWalletTransactions: jump or move depends on uninitialised value · Issue #21367 · bitcoin/bitcoin · GitHub
19:06 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Ping timeout: 268 seconds]
19:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
19:25 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
19:33 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has quit [Ping timeout: 258 seconds]
19:33 -!- Norrin [~Joe@2605:2700:0:5::4713:9659] has quit [Excess Flood]
19:38 -!- Norrin [~Joe@2605:2700:0:5::4713:9659] has joined #bitcoin-core-dev
19:44 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
20:25 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has joined #bitcoin-core-dev
20:25 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
20:26 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Max SendQ exceeded]
20:26 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
20:27 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Max SendQ exceeded]
20:28 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
20:29 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Max SendQ exceeded]
20:29 -!- Mercury_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has quit [Ping timeout: 260 seconds]
20:29 -!- Asbestos_Vapor [~Mercury_V@174-082-158-108.res.spectrum.com] has joined #bitcoin-core-dev
20:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
20:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:46 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-dev
20:46 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
20:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
20:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
21:00 -!- aferreira44 [~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a] has quit [Quit: WeeChat 2.8]
21:01 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
21:02 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
23:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:20 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/da8c7edffe0c...f7653eb5ae6e
23:20 < bitcoin-git> bitcoin/master a061a29 Martin Zumsande: test: bring p2p_leak.py up to date.
23:20 < bitcoin-git> bitcoin/master f7653eb MarcoFalke: Merge #21345: test: bring p2p_leak.py up to date
23:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:20 -!- mariorz [sid490@gateway/web/irccloud.com/x-nmciwajewsvvqoif] has quit [Ping timeout: 258 seconds]
23:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:21 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21345: test: bring p2p_leak.py up to date (master...202103_p2p_leak) https://github.com/bitcoin/bitcoin/pull/21345
23:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:21 -!- mariorz [sid490@gateway/web/irccloud.com/x-hgzzdllglznrqrsn] has joined #bitcoin-core-dev
23:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:22 < bitcoin-git> [gui] MarcoFalke merged pull request #217: qt: Make warning label look clickable (master...warning-look-like-button) https://github.com/bitcoin-core/gui/pull/217
23:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:22 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:22 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f7653eb5ae6e...ed25cb58f605
23:22 < bitcoin-git> bitcoin/master 67c59ae Jarol Rodriguez: qt: Make warning label look clickable
23:22 < bitcoin-git> bitcoin/master ed25cb5 MarcoFalke: Merge bitcoin-core/gui#217: qt: Make warning label look clickable
23:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:32 -!- Kiminuo [~Kiminuo@141.98.103.76] has joined #bitcoin-core-dev
23:33 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:48 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
23:54 -!- Kimi [~Kiminuo@141.98.103.196] has joined #bitcoin-core-dev
23:58 -!- Kiminuo [~Kiminuo@141.98.103.76] has quit [Ping timeout: 260 seconds]
--- Log closed Fri Mar 05 00:00:47 2021