12021-03-04T00:00:47  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Read error: Connection reset by peer)
  22021-03-04T00:01:38  *** larryruane_ <larryruane_!uid473749@gateway/web/irccloud.com/x-lmsrftnnjdmdxmiz> has quit IRC (Quit: Connection closed for inactivity)
  32021-03-04T00:04:06  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
  42021-03-04T00:06:57  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
  52021-03-04T00:34:24  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
  62021-03-04T00:41:33  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
  72021-03-04T00:41:35  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
  82021-03-04T00:41:44  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
  92021-03-04T00:48:27  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
 102021-03-04T00:54:06  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
 112021-03-04T00:54:47  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
 122021-03-04T00:55:33  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
 132021-03-04T00:58:51  *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 246 seconds)
 142021-03-04T00:59:19  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 276 seconds)
 152021-03-04T01:01:12  *** d <d!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
 162021-03-04T01:01:35  *** d is now known as Guest84735
 172021-03-04T01:02:03  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC (Remote host closed the connection)
 182021-03-04T01:04:43  *** jungly_ <jungly_!~jungly@host-212-171-255-115.retail.telecomitalia.it> has joined #bitcoin-core-dev
 192021-03-04T01:05:54  *** GankMove <GankMove!~GankMove@unaffiliated/gankmove> has quit IRC (Ping timeout: 245 seconds)
 202021-03-04T01:08:33  *** p0x <p0x!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
 212021-03-04T01:09:04  *** jungly <jungly!~jungly@host-95-235-238-177.retail.telecomitalia.it> has quit IRC (Ping timeout: 276 seconds)
 222021-03-04T01:10:23  *** pox <pox!~pox@gateway/tor-sasl/pox> has quit IRC (Ping timeout: 268 seconds)
 232021-03-04T01:14:55  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 276 seconds)
 242021-03-04T01:15:21  *** Guest84735 is now known as davterra
 252021-03-04T01:21:58  <aj> why does drahtbot not list #21015 and and #21236 to conflict with each other?
 262021-03-04T01:22:01  <gribble> https://github.com/bitcoin/bitcoin/issues/21015 | Make all of net_processing (and some of net) use std::chrono types by dhruv · Pull Request #21015 · bitcoin/bitcoin · GitHub
 272021-03-04T01:22:03  <gribble> https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
 282021-03-04T01:49:44  *** lightlike <lightlike!~lightlike@p200300c7ef119f002c09a758dd7fa4c8.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
 292021-03-04T02:02:48  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
 302021-03-04T02:04:02  *** elector <elector!~elector@gateway/tor-sasl/elector> has quit IRC (Ping timeout: 268 seconds)
 312021-03-04T02:04:41  *** elector <elector!~elector@gateway/tor-sasl/elector> has joined #bitcoin-core-dev
 322021-03-04T02:24:12  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 332021-03-04T02:25:03  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 245 seconds)
 342021-03-04T02:29:21  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
 352021-03-04T02:30:23  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
 362021-03-04T02:31:27  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Remote host closed the connection)
 372021-03-04T02:32:54  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 260 seconds)
 382021-03-04T02:39:45  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has quit IRC (Quit: Leaving)
 392021-03-04T02:57:49  *** justan0theruser <justan0theruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 402021-03-04T02:59:15  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 240 seconds)
 412021-03-04T03:03:51  *** virtu <virtu!~virtu@gateway/tor-sasl/virtu> has quit IRC (Ping timeout: 268 seconds)
 422021-03-04T03:05:26  *** virtu <virtu!~virtu@gateway/tor-sasl/virtu> has joined #bitcoin-core-dev
 432021-03-04T03:06:30  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 442021-03-04T03:08:09  *** rex4539 <rex4539!~rex4539@gateway/tor-sasl/rex4539> has quit IRC (Ping timeout: 268 seconds)
 452021-03-04T03:12:21  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 265 seconds)
 462021-03-04T03:18:07  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Read error: Connection reset by peer)
 472021-03-04T03:18:41  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
 482021-03-04T03:34:43  *** emzy <emzy!~quassel@unaffiliated/emzy> has quit IRC (Ping timeout: 272 seconds)
 492021-03-04T03:43:15  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 502021-03-04T03:43:39  *** emzy <emzy!~quassel@2a01:4f8:192:628a::83> has joined #bitcoin-core-dev
 512021-03-04T03:55:35  *** Gunni1 <Gunni1!~Gunni@139.28.218.148> has quit IRC (Remote host closed the connection)
 522021-03-04T04:16:33  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
 532021-03-04T04:46:01  *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
 542021-03-04T04:46:24  *** shesek <shesek!~shesek@164.90.217.137> has joined #bitcoin-core-dev
 552021-03-04T04:53:21  *** shaunsun__ <shaunsun__!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 264 seconds)
 562021-03-04T04:54:30  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
 572021-03-04T05:23:54  *** gimps <gimps!~gimps@139.28.218.148> has joined #bitcoin-core-dev
 582021-03-04T05:24:59  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 260 seconds)
 592021-03-04T05:53:43  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 602021-03-04T05:55:19  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 260 seconds)
 612021-03-04T05:55:37  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
 622021-03-04T05:58:09  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 264 seconds)
 632021-03-04T06:13:52  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
 642021-03-04T06:28:21  *** mrostecki <mrostecki!mrostecki@nat/suse/x-sdnnjckashdcacrc> has quit IRC (Quit: WeeChat 1.8)
 652021-03-04T06:41:13  *** jungly_ <jungly_!~jungly@host-212-171-255-115.retail.telecomitalia.it> has quit IRC (Ping timeout: 276 seconds)
 662021-03-04T06:47:04  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 276 seconds)
 672021-03-04T06:49:42  *** rex4539 <rex4539!~rex4539@gateway/tor-sasl/rex4539> has joined #bitcoin-core-dev
 682021-03-04T06:52:49  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 692021-03-04T06:52:49  <bitcoin-git> [bitcoin] jarolrod opened pull request #21357: test: Unconditionally check for fRelay field in test framework (master...test-framework-ver-msg-fix) https://github.com/bitcoin/bitcoin/pull/21357
 702021-03-04T06:52:50  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 712021-03-04T07:10:56  *** dermoth_ <dermoth_!~dermoth@unaffiliated/dermoth> has quit IRC (Ping timeout: 240 seconds)
 722021-03-04T07:15:42  *** landakram <landakram!~mark@2601:643:8002:3f20:9eb6:d0ff:fef0:5981> has joined #bitcoin-core-dev
 732021-03-04T07:18:20  *** dermoth_ <dermoth_!~dermoth@unaffiliated/dermoth> has joined #bitcoin-core-dev
 742021-03-04T07:37:45  *** dviola <dviola!~diego@unaffiliated/dviola> has quit IRC (Ping timeout: 264 seconds)
 752021-03-04T07:39:00  *** dviola <dviola!~diego@187.39.20.240> has joined #bitcoin-core-dev
 762021-03-04T07:39:36  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 772021-03-04T07:39:37  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/47b99ab1a9e9...d099894ec124
 782021-03-04T07:39:37  <bitcoin-git> bitcoin/master 233a886 Sebastian Falbesoner: test: check that getblockfilter RPC fails without block filter index
 792021-03-04T07:39:39  <bitcoin-git> bitcoin/master d099894 MarcoFalke: Merge #20969: test: check that getblockfilter RPC fails without block filt...
 802021-03-04T07:39:39  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 812021-03-04T07:39:52  *** jungly <jungly!~jungly@host-212-171-255-115.pool212171.interbusiness.it> has joined #bitcoin-core-dev
 822021-03-04T07:39:56  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 832021-03-04T07:39:56  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20969: test: check that getblockfilter RPC fails without block filter index (master...2021-test_getblockfilter_with_disabled_blockfilters) https://github.com/bitcoin/bitcoin/pull/20969
 842021-03-04T07:39:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 852021-03-04T07:40:12  *** dermoth_ is now known as dermoth
 862021-03-04T07:40:54  *** jonatack_ <jonatack_!~jon@37.170.222.46> has quit IRC (Ping timeout: 260 seconds)
 872021-03-04T07:42:37  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
 882021-03-04T07:42:37  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #21358: fuzz: Add missing include (test/util/setup_common.h) (master...2103-fuzzInc) https://github.com/bitcoin/bitcoin/pull/21358
 892021-03-04T07:42:38  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
 902021-03-04T07:46:49  <wumpus> amiti: will take a look
 912021-03-04T07:56:26  *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
 922021-03-04T07:57:59  *** rc_423_ <rc_423_!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has quit IRC (Ping timeout: 245 seconds)
 932021-03-04T08:10:39  *** jespada <jespada!~jespada@90.254.243.187> has joined #bitcoin-core-dev
 942021-03-04T08:27:35  *** landakram <landakram!~mark@2601:643:8002:3f20:9eb6:d0ff:fef0:5981> has quit IRC (Ping timeout: 240 seconds)
 952021-03-04T08:28:59  *** ajonas_ <ajonas_!sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio> has joined #bitcoin-core-dev
 962021-03-04T08:29:00  *** brg444_ <brg444_!uid207215@gateway/web/irccloud.com/x-nimakvacfthwvsmg> has joined #bitcoin-core-dev
 972021-03-04T08:29:03  *** jarolrod_ <jarolrod_!sid475272@gateway/web/irccloud.com/x-xgqmsomclcrfgckc> has joined #bitcoin-core-dev
 982021-03-04T08:29:16  *** michaelfolkson2 <michaelfolkson2!~michaelfo@2a03:b0c0:1:e0::23d:d001> has joined #bitcoin-core-dev
 992021-03-04T08:29:17  *** eragmus_ <eragmus_!sid136308@gateway/web/irccloud.com/x-uddttftymtbhneef> has joined #bitcoin-core-dev
1002021-03-04T08:29:18  *** glozow_ <glozow_!sid453516@gateway/web/irccloud.com/x-halahfbtacapjfun> has joined #bitcoin-core-dev
1012021-03-04T08:29:23  *** amiti_ <amiti_!sid373138@gateway/web/irccloud.com/x-fwysclwpgofmexkv> has joined #bitcoin-core-dev
1022021-03-04T08:29:26  *** jessepos_ <jessepos_!~jp@2601:645:200:162f:3167:e7cf:cd0a:198e> has joined #bitcoin-core-dev
1032021-03-04T08:29:55  *** nejon_ <nejon_!sid38993@gateway/web/irccloud.com/x-yasjxziehzsimuyv> has joined #bitcoin-core-dev
1042021-03-04T08:30:01  *** Lightsword_ <Lightsword_!~Lightswor@2604:a880:1:20::1d3:9001> has joined #bitcoin-core-dev
1052021-03-04T08:30:02  *** Abelian_ <Abelian_!sid2662@gateway/web/irccloud.com/x-aohpwcgvzdqxkchw> has joined #bitcoin-core-dev
1062021-03-04T08:30:17  *** infernixx <infernixx!nix@unaffiliated/infernix> has joined #bitcoin-core-dev
1072021-03-04T08:31:22  *** achow101_ <achow101_!~achow101@unaffiliated/achow101> has joined #bitcoin-core-dev
1082021-03-04T08:32:06  *** helo_ <helo_!~helo@2604:a880:800:10::15:2001> has joined #bitcoin-core-dev
1092021-03-04T08:35:48  *** _flow__ <_flow__!~none@salem.informatik.uni-erlangen.de> has joined #bitcoin-core-dev
1102021-03-04T08:43:01  *** asdlkfjwerpoicvx <asdlkfjwerpoicvx!~flack@p200300d46f1aca00fdd1784d01507960.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
1112021-03-04T08:43:31  *** brg444 <brg444!uid207215@gateway/web/irccloud.com/x-grayfyxgnmhtyjsj> has quit IRC (*.net *.split)
1122021-03-04T08:43:31  *** jesseposner <jesseposner!~jp@2601:645:200:162f:ed47:4e32:2608:2782> has quit IRC (*.net *.split)
1132021-03-04T08:43:31  *** Lightsword <Lightsword!~Lightswor@2604:a880:1:20::1d3:9001> has quit IRC (*.net *.split)
1142021-03-04T08:43:31  *** Norrin <Norrin!~Joe@2605:2700:0:5::4713:9659> has quit IRC (*.net *.split)
1152021-03-04T08:43:31  *** Abelian <Abelian!sid2662@gateway/web/irccloud.com/x-wufnsbynefogrljl> has quit IRC (*.net *.split)
1162021-03-04T08:43:32  *** michaelfolkson <michaelfolkson!~michaelfo@2a03:b0c0:1:e0::23d:d001> has quit IRC (*.net *.split)
1172021-03-04T08:43:32  *** infernix <infernix!~nix@unaffiliated/infernix> has quit IRC (*.net *.split)
1182021-03-04T08:43:32  *** achow101 <achow101!~achow101@unaffiliated/achow101> has quit IRC (*.net *.split)
1192021-03-04T08:43:33  *** eragmus <eragmus!sid136308@gateway/web/irccloud.com/x-gubloxbjkswaqomm> has quit IRC (*.net *.split)
1202021-03-04T08:43:33  *** jarolrod <jarolrod!sid475272@gateway/web/irccloud.com/x-dqenokmijdcsqzvr> has quit IRC (*.net *.split)
1212021-03-04T08:43:34  *** nejon <nejon!sid38993@gateway/web/irccloud.com/x-tnxlrxtehnwryzda> has quit IRC (*.net *.split)
1222021-03-04T08:43:34  *** ajonas <ajonas!sid385278@gateway/web/irccloud.com/x-wkvzzewmevfwhusu> has quit IRC (*.net *.split)
1232021-03-04T08:43:37  *** _flow_ <_flow_!~none@salem.informatik.uni-erlangen.de> has quit IRC (*.net *.split)
1242021-03-04T08:43:37  *** amiti <amiti!sid373138@gateway/web/irccloud.com/x-xxmrneenrqgbcodn> has quit IRC (*.net *.split)
1252021-03-04T08:43:37  *** glozow <glozow!sid453516@gateway/web/irccloud.com/x-eecqfvkinqkxwjyj> has quit IRC (*.net *.split)
1262021-03-04T08:43:37  *** helo <helo!~helo@unaffiliated/helo> has quit IRC (*.net *.split)
1272021-03-04T08:43:37  *** Lightsword_ is now known as Lightsword
1282021-03-04T08:43:37  *** brg444_ is now known as brg444
1292021-03-04T08:43:38  *** eragmus_ is now known as eragmus
1302021-03-04T08:43:38  *** infernixx is now known as infernix
1312021-03-04T08:43:38  *** Abelian_ is now known as Abelian
1322021-03-04T08:43:38  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1332021-03-04T08:43:38  *** glozow_ is now known as glozow
1342021-03-04T08:43:43  *** nejon_ is now known as nejon
1352021-03-04T08:43:45  *** amiti_ is now known as amiti
1362021-03-04T08:47:24  *** Norrin <Norrin!~Joe@2605:2700:0:5::4713:9659> has joined #bitcoin-core-dev
1372021-03-04T09:13:48  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1382021-03-04T09:15:54  <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.
1392021-03-04T09:17:09  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
1402021-03-04T09:17:24  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1412021-03-04T09:17:25  <bitcoin-git> [bitcoin] laanwj pushed 15 commits to master: https://github.com/bitcoin/bitcoin/compare/d099894ec124...92b7efcf54d3
1422021-03-04T09:17:26  <bitcoin-git> bitcoin/master 9d5313d Anthony Towns: move-only: Add txorphanage module
1432021-03-04T09:17:27  <bitcoin-git> bitcoin/master 81dd57e Anthony Towns: txorphanage: Pass uint256 by reference instead of value
1442021-03-04T09:17:27  <bitcoin-git> bitcoin/master 38a11c3 Anthony Towns: txorphanage: Add lock annotations
1452021-03-04T09:17:32  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1462021-03-04T09:17:34  <vasild> jnewbery: ack, 21:00 UTC is usually too late for me, but maybe I will visit the party once in a while :)
1472021-03-04T09:17:50  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1482021-03-04T09:17:50  <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
1492021-03-04T09:17:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1502021-03-04T09:27:54  *** dviola <dviola!~diego@187.39.20.240> has left #bitcoin-core-dev
1512021-03-04T09:28:16  *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
1522021-03-04T09:30:07  <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
1532021-03-04T09:31:11  <vasild> hmm, right
1542021-03-04T09:31:30  <wumpus> vasild: so we might want to make it an option first ! no strong preference though
1552021-03-04T09:31:34  <vasild> nothing can prevent old tor nodes from exchaning torv2 between themselves
1562021-03-04T09:31:43  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1572021-03-04T09:31:43  <wumpus> if there is wider agreement to nuke v2 support completely for 0.22 that's ok with me
1582021-03-04T09:32:33  <vasild> I am not sure either, when is 22.0 freeze?
1592021-03-04T09:33:01  <vasild> "when is the 22.0 freeze"
1602021-03-04T09:33:06  <fanquake> #20851
1612021-03-04T09:33:07  <wumpus> currently planned for 2021-06-15
1622021-03-04T09:33:07  <gribble> https://github.com/bitcoin/bitcoin/issues/20851 | Release schedule for 22.0 · Issue #20851 · bitcoin/bitcoin · GitHub
1632021-03-04T09:33:18  *** asdlkfjwerpoicvx <asdlkfjwerpoicvx!~flack@p200300d46f1aca00fdd1784d01507960.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
1642021-03-04T09:34:42  *** asdlkfjwerpoicvx <asdlkfjwerpoicvx!~flack@p200300d46f1aca004363a2e8cd9c70d9.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
1652021-03-04T09:35:50  <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
1662021-03-04T09:36:55  <wumpus> right, good summary of the options
1672021-03-04T09:38:25  <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
1682021-03-04T09:56:00  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1692021-03-04T09:56:21  <aj> wumpus: i have a draft branch that moves g_cs_orphans into TxOrphanage, it's mentioned in one of the comments
1702021-03-04T09:57:14  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
1712021-03-04T09:57:30  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1722021-03-04T10:01:06  <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)
1732021-03-04T10:05:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1742021-03-04T10:05:59  <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
1752021-03-04T10:06:07  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1762021-03-04T10:07:00  <aj> wumpus: yep. https://github.com/bitcoin/bitcoin/pull/21148#discussion_r585725021 fwiw
1772021-03-04T10:08:30  <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)
1782021-03-04T10:13:56  *** tredaelli <tredaelli!~tredaelli@redhat/timothy> has joined #bitcoin-core-dev
1792021-03-04T10:14:44  *** tredaelli is now known as timothy
1802021-03-04T10:19:48  *** timothy <timothy!~tredaelli@redhat/timothy> has quit IRC (Quit: Konversation terminated!)
1812021-03-04T10:26:34  <aj> jnewbery: i think aim for merging chrono before addr, yeah?
1822021-03-04T10:37:30  <jnewbery> vasild: sorry :( There's no time slot that's nice for everyone and 21:00 UTC seems to minimimze ∑(inconvenience)
1832021-03-04T10:41:09  <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.
1842021-03-04T10:44:53  <vasild> jnewbery: right, can't make it convenient for everybody without a time machine :)
1852021-03-04T10:45:40  <fanquake> after a while you get very good at speed reading irc logs
1862021-03-04T10:57:23  *** belcher_ is now known as belcher
1872021-03-04T11:09:47  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
1882021-03-04T11:10:44  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1892021-03-04T11:17:27  *** michaelfolkson2 is now known as michaelfolkson
1902021-03-04T11:18:30  *** Jordy86Stiedeman <Jordy86Stiedeman!~Jordy86St@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1912021-03-04T11:44:14  <aj> MarcoFalke: how frequently does drahtbot update it's conflicts comments?
1922021-03-04T11:52:32  *** gimps <gimps!~gimps@139.28.218.148> has quit IRC (Remote host closed the connection)
1932021-03-04T12:14:10  *** Jordy86Stiedeman <Jordy86Stiedeman!~Jordy86St@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 265 seconds)
1942021-03-04T12:14:13  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1952021-03-04T12:14:14  <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/92b7efcf54d3...33921379b6bb
1962021-03-04T12:14:14  <bitcoin-git> bitcoin/master 4d98b40 Pieter Wuille: Change all ping times to std::chrono types
1972021-03-04T12:14:15  <bitcoin-git> bitcoin/master c733ac4 Pieter Wuille: Convert block/header sync timeouts to std::chrono types
1982021-03-04T12:14:15  <bitcoin-git> bitcoin/master 55e8288 Pieter Wuille: Make all Poisson delays use std::chrono types
1992021-03-04T12:14:16  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2002021-03-04T12:14:32  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
2012021-03-04T12:14:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2022021-03-04T12:14:34  <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
2032021-03-04T12:14:35  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2042021-03-04T12:15:55  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2052021-03-04T12:20:41  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
2062021-03-04T12:21:17  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2072021-03-04T12:21:17  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33921379b6bb...7450a01691e8
2082021-03-04T12:21:18  <bitcoin-git> bitcoin/master fa59ad5 MarcoFalke: fuzz: Add missing include (test/util/setup_common.h)
2092021-03-04T12:21:18  <bitcoin-git> bitcoin/master 7450a01 fanquake: Merge #21358: fuzz: Add missing include (test/util/setup_common.h)
2102021-03-04T12:21:31  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2112021-03-04T12:21:47  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2122021-03-04T12:21:47  <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
2132021-03-04T12:22:01  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2142021-03-04T12:29:39  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2152021-03-04T12:29:39  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7450a01691e8...83bdbbd300bb
2162021-03-04T12:29:40  <bitcoin-git> bitcoin/master fa576b4 MarcoFalke: Move MakeNoLogFileContext to common libtest_util, and use it in bench
2172021-03-04T12:29:41  <bitcoin-git> bitcoin/master 83bdbbd fanquake: Merge #21003: test: Move MakeNoLogFileContext to libtest_util, and use it ...
2182021-03-04T12:29:42  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2192021-03-04T12:29:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2202021-03-04T12:29:59  <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
2212021-03-04T12:30:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2222021-03-04T12:35:18  *** skinkie1 <skinkie1!~skinkie@178.239.168.171> has joined #bitcoin-core-dev
2232021-03-04T12:36:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2242021-03-04T12:36:59  <bitcoin-git> [bitcoin] fanquake closed pull request #21341: build: removing xcrun from darwin build (master...removing_xcrum) https://github.com/bitcoin/bitcoin/pull/21341
2252021-03-04T12:37:00  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2262021-03-04T12:58:55  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2272021-03-04T13:07:25  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Read error: Connection reset by peer)
2282021-03-04T13:25:30  *** tlev <tlev!~tlev@li120-195.members.linode.com> has quit IRC (Quit: Ping timeout (120 seconds))
2292021-03-04T13:45:33  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
2302021-03-04T13:47:31  *** tlev <tlev!~tlev@li120-195.members.linode.com> has joined #bitcoin-core-dev
2312021-03-04T13:56:19  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2322021-03-04T13:56:20  <bitcoin-git> [bitcoin] laanwj pushed 17 commits to master: https://github.com/bitcoin/bitcoin/compare/83bdbbd300bb...702cfc8c531d
2332021-03-04T13:56:20  <bitcoin-git> bitcoin/master 9da106b Carl Dong: validation: Check chain tip is non-null in CheckFinalTx
2342021-03-04T13:56:21  <bitcoin-git> bitcoin/master 4927c9e Carl Dong: validation: Remove global ::LoadGenesisBlock
2352021-03-04T13:56:22  <bitcoin-git> bitcoin/master a3ba08b Carl Dong: validation: Remove global ::{{Precious,Invalidate}Block,ResetBlockFailureF...
2362021-03-04T13:56:23  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2372021-03-04T13:56:39  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2382021-03-04T13:56:39  <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
2392021-03-04T13:56:40  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2402021-03-04T13:56:54  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
2412021-03-04T13:57:10  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2422021-03-04T13:58:34  *** jespada <jespada!~jespada@90.254.243.187> has quit IRC (Ping timeout: 265 seconds)
2432021-03-04T13:59:47  *** jespada <jespada!~jespada@90.254.243.187> has joined #bitcoin-core-dev
2442021-03-04T14:03:08  *** jonatack_ <jonatack_!~jon@37.173.203.38> has joined #bitcoin-core-dev
2452021-03-04T14:03:37  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 256 seconds)
2462021-03-04T14:09:49  *** jonatack_ <jonatack_!~jon@37.173.203.38> has quit IRC (Quit: jonatack_)
2472021-03-04T14:21:45  *** egp__ <egp__!~egp_@2.95.74.168> has quit IRC (Quit: EXIT)
2482021-03-04T14:22:09  *** egp_ <egp_!~egp_@2.95.74.168> has joined #bitcoin-core-dev
2492021-03-04T14:25:06  *** egp_ <egp_!~egp_@2.95.74.168> has quit IRC (Client Quit)
2502021-03-04T14:25:28  *** JokerAscensionEx <JokerAscensionEx!~egp_@2.95.74.168> has joined #bitcoin-core-dev
2512021-03-04T14:26:19  *** JokerAscensionEx <JokerAscensionEx!~egp_@2.95.74.168> has quit IRC (Remote host closed the connection)
2522021-03-04T14:26:37  *** JokerAscensionEx <JokerAscensionEx!~egp_@2.95.74.168> has joined #bitcoin-core-dev
2532021-03-04T14:38:56  *** jonatack <jonatack!jon@gateway/vpn/airvpn/jonatack> has joined #bitcoin-core-dev
2542021-03-04T14:40:53  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
2552021-03-04T14:47:39  *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.76> has joined #bitcoin-core-dev
2562021-03-04T14:52:21  *** jonatack <jonatack!jon@gateway/vpn/airvpn/jonatack> has quit IRC (Ping timeout: 256 seconds)
2572021-03-04T14:55:53  *** jonatack <jonatack!~jon@37.173.203.38> has joined #bitcoin-core-dev
2582021-03-04T15:02:10  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2592021-03-04T15:02:11  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/702cfc8c531d...b4d22654fe9e
2602021-03-04T15:02:11  <bitcoin-git> bitcoin/master 7bbb409 Hennadii Stepanov: guix: Update darwin native packages dependencies
2612021-03-04T15:02:12  <bitcoin-git> bitcoin/master c967fb7 Hennadii Stepanov: guix: Remove libcap from manifest
2622021-03-04T15:02:12  <bitcoin-git> bitcoin/master b4d2265 Wladimir J. van der Laan: Merge #21337: guix: Update darwin native packages dependencies
2632021-03-04T15:02:18  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2642021-03-04T15:02:34  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2652021-03-04T15:02:34  <bitcoin-git> [bitcoin] laanwj merged pull request #21337: guix: Update darwin native packages dependencies (master...210302-cdrkit) https://github.com/bitcoin/bitcoin/pull/21337
2662021-03-04T15:02:35  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2672021-03-04T15:04:51  *** davterra <davterra!~davterra@gateway/tor-sasl/tralfaz> has joined #bitcoin-core-dev
2682021-03-04T15:10:52  *** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC (Ping timeout: 272 seconds)
2692021-03-04T15:28:09  *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.76> has quit IRC (Remote host closed the connection)
2702021-03-04T15:28:19  *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.76> has joined #bitcoin-core-dev
2712021-03-04T15:30:38  *** dqx <dqx!~dqx@unaffiliated/dqx> has joined #bitcoin-core-dev
2722021-03-04T15:35:29  *** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC (Ping timeout: 245 seconds)
2732021-03-04T15:38:19  *** dqx <dqx!~dqx@unaffiliated/dqx> has joined #bitcoin-core-dev
2742021-03-04T15:46:53  <MarcoFalke> aj: About once/twice a day, I think
2752021-03-04T15:54:44  *** realname192 <realname192!~real@37.162.4.110> has joined #bitcoin-core-dev
2762021-03-04T15:55:59  *** mrostecki <mrostecki!mrostecki@nat/suse/x-psigibnclcfhfbgx> has joined #bitcoin-core-dev
2772021-03-04T15:57:08  *** Deinogalerix21 <Deinogalerix21!~Deinogale@165.231.33.140> has joined #bitcoin-core-dev
2782021-03-04T15:59:37  *** Deinogalerix21 <Deinogalerix21!~Deinogale@165.231.33.140> has quit IRC (Client Quit)
2792021-03-04T16:00:13  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 260 seconds)
2802021-03-04T16:02:44  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
2812021-03-04T16:03:00  *** realname192 <realname192!~real@37.162.4.110> has quit IRC (Quit: Leaving)
2822021-03-04T16:03:05  *** uasf <uasf!~uasf@2604:a880:2:d0::1bda:1001> has quit IRC (Remote host closed the connection)
2832021-03-04T16:03:37  *** uasf <uasf!~uasf@2604:a880:2:d0::1bda:1001> has joined #bitcoin-core-dev
2842021-03-04T16:08:36  *** uasf <uasf!~uasf@2604:a880:2:d0::1bda:1001> has quit IRC (Remote host closed the connection)
2852021-03-04T16:08:44  *** uasf <uasf!~uasf@2604:a880:2:d0::1bda:1001> has joined #bitcoin-core-dev
2862021-03-04T16:10:11  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-158-108.res.spectrum.com> has quit IRC (Quit: Leaving)
2872021-03-04T16:16:19  *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-158-108.res.spectrum.com> has joined #bitcoin-core-dev
2882021-03-04T16:27:30  *** p0x <p0x!~pox@gateway/tor-sasl/pox> has left #bitcoin-core-dev
2892021-03-04T16:35:45  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
2902021-03-04T16:56:46  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Ping timeout: 276 seconds)
2912021-03-04T17:07:43  *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
2922021-03-04T17:16:05  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
2932021-03-04T17:16:52  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2942021-03-04T17:27:16  *** asdlkfjwerpoicvx <asdlkfjwerpoicvx!~flack@p200300d46f1aca004363a2e8cd9c70d9.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
2952021-03-04T17:30:23  *** jessepos_ <jessepos_!~jp@2601:645:200:162f:3167:e7cf:cd0a:198e> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
2962021-03-04T17:30:48  *** jesseposner <jesseposner!~jp@2601:645:200:162f:3167:e7cf:cd0a:198e> has joined #bitcoin-core-dev
2972021-03-04T17:30:51  <jnewbery> MarcoFalke: wen button to bribe drahtbot with lightning to update its comment on my PR?
2982021-03-04T17:31:33  <MarcoFalke> pls pr number, jnewbery
2992021-03-04T17:33:47  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3002021-03-04T17:33:47  <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
3012021-03-04T17:33:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3022021-03-04T17:38:17  <MarcoFalke> Looks like this one was updated an hour ago: https://github.com/bitcoin/bitcoin/pull/21236#issuecomment-782102826
3032021-03-04T17:51:14  *** aferreira44 <aferreira44!~andre@2001:1284:f013:36cc:2192:8325:a3f2:f67a> has joined #bitcoin-core-dev
3042021-03-04T17:51:41  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3052021-03-04T17:54:33  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 260 seconds)
3062021-03-04T17:58:59  *** eoin <eoin!402b84c0@64.43.132.192> has joined #bitcoin-core-dev
3072021-03-04T17:59:02  *** stortz <stortz!b1982408@177.152.36.8> has joined #bitcoin-core-dev
3082021-03-04T18:01:01  *** Kimi <Kimi!~Kiminuo@141.98.103.76> has joined #bitcoin-core-dev
3092021-03-04T18:02:53  *** lightlike <lightlike!~lightlike@p200300c7ef1c4d0035e5f1bdebb24717.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
3102021-03-04T18:03:23  *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.76> has quit IRC (Ping timeout: 256 seconds)
3112021-03-04T18:11:35  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 268 seconds)
3122021-03-04T18:12:39  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 260 seconds)
3132021-03-04T18:14:13  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
3142021-03-04T18:15:26  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
3152021-03-04T18:20:56  *** ajonas_ <ajonas_!sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio> has quit IRC ()
3162021-03-04T18:21:18  *** ajonas <ajonas!sid385278@gateway/web/irccloud.com/x-vbqmiwqebvrkdcvc> has joined #bitcoin-core-dev
3172021-03-04T18:36:43  *** achow101_ is now known as achow101
3182021-03-04T18:39:00  *** jungly <jungly!~jungly@host-212-171-255-115.pool212171.interbusiness.it> has quit IRC (Ping timeout: 246 seconds)
3192021-03-04T18:44:49  <achow101> anyone else getting a bunch of compiler warnings for FuzzedSock?
3202021-03-04T18:44:56  <sipa> yes
3212021-03-04T18:46:45  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 264 seconds)
3222021-03-04T18:47:28  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
3232021-03-04T18:48:20  <MarcoFalke> #21355
3242021-03-04T18:48:21  <gribble> https://github.com/bitcoin/bitcoin/issues/21355 | windows: new -Wreturn-type warnings after #19203 · Issue #21355 · bitcoin/bitcoin · GitHub
3252021-03-04T18:50:43  <hebasto> MarcoFalke: #20586 ?
3262021-03-04T18:50:45  <gribble> https://github.com/bitcoin/bitcoin/issues/20586 | Fix Windows build with --enable-werror by hebasto · Pull Request #20586 · bitcoin/bitcoin · GitHub
3272021-03-04T18:52:02  <MarcoFalke> hebasto: I'd presume that sipa and achow101 use gcc, not mingw
3282021-03-04T18:52:22  <hebasto> aah, sorry
3292021-03-04T18:53:17  <MarcoFalke> I switched to clang long ago. gcc doesn't seem even remotely stable anymore
3302021-03-04T18:53:48  <sipa> how so?
3312021-03-04T18:54:13  <MarcoFalke> all the bugs we run into?
3322021-03-04T18:54:28  <sipa> the memcmp thing?
3332021-03-04T18:54:32  <jonatack> master is clean with clang 9 for me
3342021-03-04T18:55:18  <MarcoFalke> Also, the warnings. I think the txmempool std::optional warning is still there, now the return-type warning, ...
3352021-03-04T18:55:33  <jonatack> sipa: there were a few false warnings ?
3362021-03-04T18:55:49  <jonatack> s/?/^/ what MarcoFalke wrote
3372021-03-04T18:55:57  <achow101> This warning is -Woverloaded-virtual
3382021-03-04T18:56:01  <achow101> "./util/sock.h:61:19: warning: ‘virtual Sock& Sock::operator=(Sock&&)’ was hidden [-Woverloaded-virtual]"
3392021-03-04T18:56:44  <achow101> the txmempool warning is also still there
3402021-03-04T18:57:24  <sipa> it can be silenced by replacing with return nullopt;... but that's clearly a bogus warning
3412021-03-04T18:57:42  <jonatack> MarcoFalke: which clang are you using nowadays?
3422021-03-04T18:59:46  *** rex4539 <rex4539!~rex4539@gateway/tor-sasl/rex4539> has quit IRC (Remote host closed the connection)
3432021-03-04T19:00:53  *** rex4539 <rex4539!~rex4539@gateway/tor-sasl/rex4539> has joined #bitcoin-core-dev
3442021-03-04T19:00:55  <wumpus> #startmeeting
3452021-03-04T19:01:01  <jonasschnelli_> (again)
3462021-03-04T19:01:06  *** jonasschnelli_ is now known as jonasschnelli
3472021-03-04T19:01:10  <jonasschnelli> hi
3482021-03-04T19:01:11  <kanzure> hi
3492021-03-04T19:01:13  <ajonas> hi
3502021-03-04T19:01:17  <hebasto> hi
3512021-03-04T19:01:17  <achow101> hi
3522021-03-04T19:01:18  <amiti> hi
3532021-03-04T19:01:20  <jnewbery> hi
3542021-03-04T19:01:44  <wumpus> one proposed meeting topic: blocksonly mode and transaction relay (jnewbery)
3552021-03-04T19:01:52  <fjahr> hi
3562021-03-04T19:01:55  <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
3572021-03-04T19:01:58  <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
3582021-03-04T19:01:58  <sipa> hi
3592021-03-04T19:02:01  *** core-meetingbot` <core-meetingbot`!~meetingbo@static.239.36.216.95.clients.your-server.de> has quit IRC (Quit: 2019.02.23)
3602021-03-04T19:02:13  *** core-meetingbot <core-meetingbot!~meetingbo@2a01:4f9:2a:2510::2> has joined #bitcoin-core-dev
3612021-03-04T19:02:35  <promag> o/
3622021-03-04T19:02:39  <wumpus> any last-minute topics?
3632021-03-04T19:02:45  <jonatack> hi
3642021-03-04T19:02:49  <ajonas> wumpus: I just have a brief mention of the developer survey
3652021-03-04T19:03:04  <wumpus> ajonas: great!
3662021-03-04T19:03:39  *** pox <pox!~pox@gateway/tor-sasl/pox> has joined #bitcoin-core-dev
3672021-03-04T19:03:43  <wumpus> #topic High priority for review
3682021-03-04T19:03:57  <jonasschnelli> I added #20664 to the hiprio list
3692021-03-04T19:04:00  <wumpus> https://github.com/bitcoin/bitcoin/projects/8   9 blockers, 2 chasing concept ACK
3702021-03-04T19:04:00  <gribble> https://github.com/bitcoin/bitcoin/issues/20664 | Add scanblocks RPC call by jonasschnelli · Pull Request #20664 · bitcoin/bitcoin · GitHub
3712021-03-04T19:04:40  <wumpus> does anyone else want to add or remove anything ?
3722021-03-04T19:04:47  <jonatack> maybe add #20197 please, if the list isn't too long
3732021-03-04T19:04:50  <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
3742021-03-04T19:05:24  <wumpus> jonatack: added!
3752021-03-04T19:05:33  <jonatack> wumpus: ty!
3762021-03-04T19:06:46  <wumpus> is there anything (almost) ready for merge?
3772021-03-04T19:07:45  <ariard> hi
3782021-03-04T19:07:52  <achow101> #20536 has 3 acks
3792021-03-04T19:07:53  <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
3802021-03-04T19:07:55  <elichai2> hi
3812021-03-04T19:07:58  <MarcoFalke> hi
3822021-03-04T19:07:59  <ajonas> There are a few old tests that have got some new review... nothing major though
3832021-03-04T19:08:04  <wumpus> achow101: good to know
3842021-03-04T19:08:53  <wumpus> i guess that's all for this topic, let's go to next one then
3852021-03-04T19:08:53  <ajonas> #18795, #19393, #14604
3862021-03-04T19:08:55  <gribble> https://github.com/bitcoin/bitcoin/issues/18795 | Test: wallet issue with orphaned rewards by domob1812 · Pull Request #18795 · bitcoin/bitcoin · GitHub
3872021-03-04T19:08:57  <gribble> https://github.com/bitcoin/bitcoin/issues/19393 | test: Add more tests for orphan tx handling by hebasto · Pull Request #19393 · bitcoin/bitcoin · GitHub
3882021-03-04T19:08:59  <gribble> https://github.com/bitcoin/bitcoin/issues/14604 | tests: Add test and refactor feature_block.py by sanket1729 · Pull Request #14604 · bitcoin/bitcoin · GitHub
3892021-03-04T19:09:13  <wumpus> ajonas: thank you
3902021-03-04T19:09:39  <wumpus> #topic Blocksonly mode and transaction relay (jnewbery)
3912021-03-04T19:09:59  <jnewbery> hello!
3922021-03-04T19:10:03  <jnewbery> There is a `-blocksonly` option in Bitcoin Core, which disables transaction relay for a node.
3932021-03-04T19:10:14  <jnewbery> It does this by setting fRelay=false on the version message on all of its connections.
3942021-03-04T19:10:24  <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)
3952021-03-04T19:10:26  <gribble> https://github.com/bitcoin/bitcoin/issues/6993 | Add -blocksonly option by pstratem · Pull Request #6993 · bitcoin/bitcoin · GitHub
3962021-03-04T19:10:29  <gribble> https://github.com/bitcoin/bitcoin/issues/15990 | Add tests and documentation for blocksonly by MarcoFalke · Pull Request #15990 · bitcoin/bitcoin · GitHub
3972021-03-04T19:10:31  <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
3982021-03-04T19:10:40  <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.
3992021-03-04T19:10:52  <jnewbery> This makes it very obvious that the node is the origin of the transaction, since it doesn't relay any other transaction!
4002021-03-04T19:11:02  <jnewbery> Are there legitimate use cases for this behaviour?
4012021-03-04T19:11:22  <ariard> I would say emergency broadcast, you don't care about the privacy
4022021-03-04T19:11:29  <sipa> fRelay=false is also set in other cases, right?
4032021-03-04T19:11:46  <sipa> for blocks relay connections, even if you're not in blocksonly mode?
4042021-03-04T19:11:50  <ariard> like when your main node is upgrading/power outage/...
4052021-03-04T19:12:01  <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
4062021-03-04T19:12:33  <sipa> oh, nvm, i was confusing things; this isn't relevant
4072021-03-04T19:12:49  <jnewbery> bloom filter clients also set fRelay=false when connecting to supress tx relay until they've loaded the filter
4082021-03-04T19:13:21  <sipa> i'm not sure what the right behavior is
4092021-03-04T19:13:35  <sipa> it's clearly a privacy leak, but i think it would also be incorrect to just not relay
4102021-03-04T19:13:41  <wumpus> maybe reject it by default but add a 'force' flag to override, i dunno
4112021-03-04T19:13:50  <sipa> there is an expectation that a transaction is relayed if you call sendrawtransaction
4122021-03-04T19:14:00  <fjahr> I was just going to suggest a force flag too
4132021-03-04T19:14:03  <wumpus> yea failing silently would be the worst of both worlds
4142021-03-04T19:14:05  <ariard> yeah force flag sounds good
4152021-03-04T19:14:08  <jonasschnelli> +1 for the force flag
4162021-03-04T19:14:12  <jnewbery> always fail sendrawtransaction if -blocksonly is set?
4172021-03-04T19:14:28  <jonasschnelli> jnewbery: seems a bit to hand-holdish
4182021-03-04T19:14:50  <MarcoFalke> Seems a bit too hand-holdish to add a force flag for this
4192021-03-04T19:15:04  <MarcoFalke> The privacy leak is well documented in the option help
4202021-03-04T19:15:13  <jnewbery> a force flag seems the worst of all worlds
4212021-03-04T19:15:15  <sdaftuar> can't someone use bitcoin-qt in blocksonly mode? i'm not understanding hte force flag in that scenario
4222021-03-04T19:15:24  <sdaftuar> some warnign popup i guess?
4232021-03-04T19:15:34  <jonasschnelli> The GUI could have a warning, yes.
4242021-03-04T19:15:42  <jnewbery> oh, one thing I should add: -blocksonly will soft-set -walletbroadcast to false
4252021-03-04T19:15:51  <jonasschnelli> Which is more or less the UX adaption of a "force" CLI flag
4262021-03-04T19:15:52  <luke-jr> MarcoFalke: it fits well with your force-past-policy PR
4272021-03-04T19:15:54  <wumpus> it doesn't imply walletbroadca.. right
4282021-03-04T19:16:17  <wumpus> so we did think of that
4292021-03-04T19:16:21  <jonatack> sendrawtransaction help states the issue clearly
4302021-03-04T19:16:22  <jonasschnelli> sendrawtransaction respectes walletbroadcast?
4312021-03-04T19:16:23  <MarcoFalke> as jnewbery points out the wallet should disable the broadcast with blocksonly
4322021-03-04T19:16:29  <jnewbery> I don't expect users to understand the privacy implications of this. Putting an option in the GUI seems overly complex
4332021-03-04T19:16:37  <wumpus> i also remember this came up before
4342021-03-04T19:16:38  <MarcoFalke> but the rpc is separate
4352021-03-04T19:16:47  <sdaftuar> so are we only talking about changing behavior in the case that -blocksonly=true and -walletbroadcast=true?
4362021-03-04T19:16:59  <jnewbery> sendrawtransaction is not a wallet rpc, so should have no interaction with walletrebroadcast
4372021-03-04T19:17:07  <sdaftuar> if the user has set that, it seems clear waht the intent is
4382021-03-04T19:17:28  <luke-jr> sdaftuar: the intent of sendrawtransaction is also clear and contradicts it
4392021-03-04T19:17:28  <wumpus> sdaftuar: +1
4402021-03-04T19:17:55  <MarcoFalke> luke-jr: It doesn't contradict. It overwrites for a specific tx
4412021-03-04T19:18:04  <jonasschnelli> if you don't have transaction relay, doesn't the wallet always need manual fee settings (problematic either)?
4422021-03-04T19:18:18  <MarcoFalke> jonasschnelli: This is also documented
4432021-03-04T19:18:21  <jnewbery> jonasschnelli: indeed
4442021-03-04T19:18:25  <MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md#4-turn-off-transaction-relay--blocksonly
4452021-03-04T19:18:27  <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
4462021-03-04T19:18:48  <MarcoFalke> If we assume that no one reads the docs, what is the point of adding it in the first place.
4472021-03-04T19:19:02  <jonasschnelli> yes. that is a valid point.
4482021-03-04T19:19:11  <jonasschnelli> Maybe we should expect people read the docs
4492021-03-04T19:19:12  <jnewbery> My baseline assumption is that users don't read docs
4502021-03-04T19:19:25  <amiti> MarcoFalke: I think its not boolean? I'd expect some users to read docs, but not all
4512021-03-04T19:19:35  <sipa> i'm a bit confused about the context... this is only about the sendrawtransaction RPC, not about wallet sending?
4522021-03-04T19:19:43  <jnewbery> and I don't think documenting bad behaviour is better than removing bad behaviour
4532021-03-04T19:19:45  <jonasschnelli> jnewbery: if so, how do they even find out about the blocksonly mode? :-)
4542021-03-04T19:20:00  <luke-jr> jonasschnelli: reading *some* docs but not others! XD
4552021-03-04T19:20:04  <MarcoFalke> sipa: I think this is a general discussion about the version message fRelay field
4562021-03-04T19:20:25  <jnewbery> jonasschnelli: because someone suggests that they enable it on a twitter thread to save themselves some bandwidth?
4572021-03-04T19:20:42  <jonasschnelli> yes... that
4582021-03-04T19:20:55  <sipa> what specifically are we discussing changing?
4592021-03-04T19:20:57  <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?
4602021-03-04T19:21:19  <jnewbery> sdaftuar: that's the wider context, yes
4612021-03-04T19:21:33  <sdaftuar> so this question is to establish whether our current relay behavior is sort of reasonable at all
4622021-03-04T19:21:39  <jonasschnelli> Aren't there any valid use-cases that use blocksonly & wallet broadcast (like a private network, designated connection)?
4632021-03-04T19:21:40  <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
4642021-03-04T19:22:02  <jonasschnelli> Agree with MarcoFalke
4652021-03-04T19:22:17  <sipa> MarcoFalke: i'd expect people to set whitelisting in that case, though (or they'll experience more broken behavior)
4662021-03-04T19:22:18  <sipa> like rebroadcasting won't work
4672021-03-04T19:22:22  <jnewbery> I don't understand this use case
4682021-03-04T19:23:13  <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?
4692021-03-04T19:23:14  <luke-jr> jnewbery: maybe the user just doesn't care about privacy?
4702021-03-04T19:23:49  <jnewbery> luke-jr: that's fair, but is that a use case we want to support?
4712021-03-04T19:23:55  <luke-jr> …
4722021-03-04T19:24:05  <MarcoFalke> sipa: sendrawtrasnaction is designed to do a rebroadcast every time you call it
4732021-03-04T19:24:36  <sipa> MarcoFalke: right, but wallet rebroadcasting won't work, because alreadyhave logic will think the (only) peer already has it
4742021-03-04T19:24:51  <sipa> not alreadyhave; inventoryknown
4752021-03-04T19:24:51  <MarcoFalke> permission flags can't override the inv-getdata filter either, IIRC
4762021-03-04T19:25:25  <sipa> hmm, fair; even if you announce again, the peer won't fetch it again
4772021-03-04T19:25:26  <MarcoFalke> your inventoryknown is the other peer's alreadyhave ;)
4782021-03-04T19:25:29  <sipa> i'm confused now
4792021-03-04T19:25:40  <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
4802021-03-04T19:25:46  <sipa> i thought that was the reason we introduced whitelisting in the first place
4812021-03-04T19:25:49  <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.
4822021-03-04T19:26:10  <sdaftuar> oh! we never clear filterInventoryKnown? that seems potentially problematic
4832021-03-04T19:26:35  <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
4842021-03-04T19:26:36  <sipa> doesn't look like it
4852021-03-04T19:26:47  <sipa> amiti: that's inconsistent for sure
4862021-03-04T19:26:56  <sipa> but i don't really know what to do about it
4872021-03-04T19:27:33  <jnewbery> I'm still curious about the supposed use cases. jonasschnelli and MarcoFalke thing there are use cases, but I don't understand them
4882021-03-04T19:27:33  <ariard> actually you can be willingly to not participate in tx-relay to mask your connection graph
4892021-03-04T19:27:41  <ariard> and only broardcat when you really need it
4902021-03-04T19:27:44  <amiti> sipa: what's the issue with just giving the user an error message if  they attempt sendrawtransaction?
4912021-03-04T19:28:04  <amiti> maybe not desirable, but one way to make it consistent
4922021-03-04T19:28:23  <jonasschnelli> jnewbery: Assume someone runs a blockonly node at home (bandwith) but connects it to a trusted peer over wireguard
4932021-03-04T19:28:38  <MarcoFalke> sendrawtransaction is explicitly called. Wallet broadcast is implicit, so I think the current behavior makes sense
4942021-03-04T19:28:53  <MarcoFalke> (It is possible to enable wallet broadcast explicitly as well)
4952021-03-04T19:29:00  <amiti> MarcoFalke: fair
4962021-03-04T19:29:01  <jnewbery> jonasschnelli: that'd associate all of your transactions to your node
4972021-03-04T19:29:07  <luke-jr> bandwidth vs privacy is a tradeoff. Users may prefer bandwidth.
4982021-03-04T19:29:13  <sdaftuar> jnewbery: does that matter to tor users?
4992021-03-04T19:29:16  <MarcoFalke> jnewbery: Which is no problem because you control the other node
5002021-03-04T19:29:28  <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?
5012021-03-04T19:29:39  <ariard> but even if you don't control the other node, you prefer the transaction propagating over the privacy gain
5022021-03-04T19:29:41  <jnewbery> MarcoFalke. Presumably the home node is relaying the transaction on to the network?
5032021-03-04T19:29:42  * luke-jr wonders if Tor nodes can/should make a dedicated connection just for broadcast
5042021-03-04T19:29:49  <amiti> lightlike: yes
5052021-03-04T19:29:55  <ariard> you *might* prefer (e.g time-sensitive txn)
5062021-03-04T19:30:11  <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)
5072021-03-04T19:30:17  <sipa> so sendrawtransaction does not relay over fRelay=false connections in general, only in -blocksonly mode?
5082021-03-04T19:30:37  <jnewbery> sipa: I belive that is correct
5092021-03-04T19:30:45  <sipa> curious
5102021-03-04T19:30:54  <MarcoFalke> sendrawtransaction will send it out to all peers that have send you a fRelay=true
5112021-03-04T19:30:56  <sdaftuar> fRelay=false isn't a "category" of connection, really
5122021-03-04T19:30:56  <luke-jr> jnewbery: in that scenario, the home node talks exclusively to your dedicated server somewhere over VPN
5132021-03-04T19:31:22  <MarcoFalke> sendrawtransaction doesn't take into account what fRelay you sent to the peer
5142021-03-04T19:31:23  <sdaftuar> we have full-relay-outbound connections, which might actually be fRelay=false if we're in -blocksonly mode
5152021-03-04T19:31:29  <jnewbery> luke-jr: I don't think that's what jonasschnelli was describing
5162021-03-04T19:31:31  <sipa> ah, i see
5172021-03-04T19:31:42  <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)
5182021-03-04T19:31:47  <sipa> jnewbery: that's how i interpret jonasschnelli's scenario as well
5192021-03-04T19:31:53  <jonasschnelli> yes. m2
5202021-03-04T19:32:08  <sipa> (only one connection, blocksonly to a trusted peer; you don't care about privacy w.r.t. that peer)
5212021-03-04T19:33:00  <sipa> i think in general "i don't care about privacy w.r.t. this peer" is something to be captured by whitelisting
5222021-03-04T19:33:08  <sipa> but of course... who knows what people read
5232021-03-04T19:33:14  <luke-jr> hmm
5242021-03-04T19:33:28  <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)
5252021-03-04T19:33:43  <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
5262021-03-04T19:33:53  <MarcoFalke> sipa: It is called permission flags now ;)
5272021-03-04T19:33:59  <sipa> MarcoFalke: right, thanks
5282021-03-04T19:34:43  <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
5292021-03-04T19:34:46  <sipa> ariard: that seems more like something you'd want for tor connections (and as a specific way of broadcasting transactions)
5302021-03-04T19:35:02  <MarcoFalke> And permission flags don't work for outbound connections (yet)
5312021-03-04T19:35:39  <luke-jr> MarcoFalke: have a PR for that for a year+ now :P
5322021-03-04T19:35:56  <wumpus> what is holding it up?
5332021-03-04T19:36:02  <luke-jr> lack of review last I checked
5342021-03-04T19:36:09  <MarcoFalke> either that or "Needs rebase"
5352021-03-04T19:36:22  <sipa> pr number?
5362021-03-04T19:36:29  <sipa> (mentioning it here may help :p)
5372021-03-04T19:36:35  <wumpus> yes
5382021-03-04T19:36:36  <luke-jr> #17167
5392021-03-04T19:36:38  <gribble> https://github.com/bitcoin/bitcoin/issues/17167 | Allow whitelisting outgoing connections by luke-jr · Pull Request #17167 · bitcoin/bitcoin · GitHub
5402021-03-04T19:36:46  <luke-jr> looks like it needs rebase at the moment
5412021-03-04T19:36:56  <MarcoFalke> jnewbery: Sending feefilter=max to the trusted peer could work
5422021-03-04T19:37:04  <wumpus> i have always liked the idea of being able to whitelist ^D^D permission outgoing connections
5432021-03-04T19:37:26  <jnewbery> 17167 has needed rebase since December
5442021-03-04T19:37:27  <MarcoFalke> jnewbery: Can we replace fRelay with feefilter=max?
5452021-03-04T19:37:29  *** adria22 <adria22!b2ede236@178.237.226.54> has joined #bitcoin-core-dev
5462021-03-04T19:37:33  <jonasschnelli> The current wallet broadcast in normal operations isn't privacy preserving either (AFAIK without dandelion or similar)?
5472021-03-04T19:37:36  <jonatack> FWIW regarding fRelay, I mentally rename it to m_wants_tx_relay
5482021-03-04T19:37:40  <luke-jr> if there's renewed interest I can go ahead and rebase it
5492021-03-04T19:38:13  <MarcoFalke> jonasschnelli: I think the wallet broadcast has been reworked to be less agressive
5502021-03-04T19:38:28  <sdaftuar> MarcoFalke: would we then require that the peer support feefilter to stay connected?
5512021-03-04T19:38:42  *** adria22 <adria22!b2ede236@178.237.226.54> has quit IRC (Client Quit)
5522021-03-04T19:38:53  <jonasschnelli> sure. AFAIK chainanalysis companies are still able to capture it
5532021-03-04T19:39:06  <amiti> jonasschnelli: no its not, but I'm working on it :) #21061
5542021-03-04T19:39:08  <gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
5552021-03-04T19:39:09  *** adria22 <adria22!b2ede236@178.237.226.54> has joined #bitcoin-core-dev
5562021-03-04T19:39:17  <jonasschnelli> amiti: nice
5572021-03-04T19:39:31  *** adria22 <adria22!b2ede236@178.237.226.54> has quit IRC (Client Quit)
5582021-03-04T19:39:42  <jonasschnelli> Just saying because if we flag blockonly privacy leaking we imply normal operation isn't
5592021-03-04T19:39:54  <MarcoFalke> sdaftuar: We also assume the node to support BIP 60 for blocksonly, so it is not a large change?
5602021-03-04T19:40:00  *** adria22 <adria22!b2ede236@178.237.226.54> has joined #bitcoin-core-dev
5612021-03-04T19:40:11  <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
5622021-03-04T19:40:12  <MarcoFalke> (nodes will be disconnected if they don't support BIP 60, no?)
5632021-03-04T19:40:18  <sdaftuar> MarcoFalke: well my guess is that bip37/bip60 is more widely supported on the network. feefilter has always been optional
5642021-03-04T19:40:20  <jnewbery> MarcoFalke: BIP60 is version 70002. feefilter is version 70013.
5652021-03-04T19:40:28  <amiti> sipa: strong +1
5662021-03-04T19:40:43  <jonasschnelli> yes. thats a good point sipa
5672021-03-04T19:41:00  *** adria22 <adria22!b2ede236@178.237.226.54> has quit IRC (Client Quit)
5682021-03-04T19:41:00  <jnewbery> but I think being able to send feefilter before verack would be nice
5692021-03-04T19:41:23  *** adria22 <adria22!b2ede236@178.237.226.54> has joined #bitcoin-core-dev
5702021-03-04T19:41:39  <sipa> still, i'm not sure exactly what we're talking about? blocksonly + sendrawtransaction? or also blocksonly + walletbroadcast + wallet send? something else?
5712021-03-04T19:41:45  *** adria22 <adria22!b2ede236@178.237.226.54> has quit IRC (Client Quit)
5722021-03-04T19:41:46  <sdaftuar> but wait feefilter doesn't help right jnewbery?
5732021-03-04T19:42:02  <jnewbery> feefilter doesn't help here, no
5742021-03-04T19:42:06  <jnewbery> we'd still need BIP 338
5752021-03-04T19:42:15  <wumpus> both security and privacy are always about making attacks marginally more difficult/expensive, not absolutes, would not call it a lost cause
5762021-03-04T19:42:31  <jnewbery> some way to signal tx relay
5772021-03-04T19:43:18  <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
5782021-03-04T19:44:07  <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
5792021-03-04T19:44:23  <sipa> what happens right now if someone runs bitcoin-qt in -blocksonly mode and creates a transaction?
5802021-03-04T19:44:25  <sdaftuar> that's only true in a world where NODE_BLOOM isn't supported
5812021-03-04T19:44:37  <jnewbery> I was trying to understand if those edge cases are actually important, or whether they're just things that people are speculating about
5822021-03-04T19:44:39  <jonatack> jnewbery: only the first of the two?
5832021-03-04T19:44:59  <jnewbery> *only true for nodes that don't support serving bloom filters, yes
5842021-03-04T19:45:08  <luke-jr> jnewbery: didn't sdaftuar just add a new flag for that?
5852021-03-04T19:45:17  <sipa> while still supporting fRelay
5862021-03-04T19:45:18  <wumpus> sipa: sure, agree
5872021-03-04T19:45:50  <sdaftuar> luke-jr: not merged yet
5882021-03-04T19:45:52  <jnewbery> sipa: it wouldn't be broadcast because walletbroadcast is set to false. I don't know what the GUI shows
5892021-03-04T19:46:14  <sipa> that seems bad
5902021-03-04T19:46:24  <luke-jr> sdaftuar: right, but it would make fRelay having this property redundant..?
5912021-03-04T19:46:33  * sipa conjectures that barely anyone uses -blocksonly on nodes they actually use as wallets
5922021-03-04T19:46:44  <jnewbery> this was also my conjecture
5932021-03-04T19:46:47  <sdaftuar> luke-jr: i think jnewbery's proposal is to scrap the BIP
5942021-03-04T19:46:51  <luke-jr> ah
5952021-03-04T19:47:28  <wumpus> i don't think blocksonly was ever officially supported for the GUI, it works, sure
5962021-03-04T19:47:30  <MarcoFalke> so replace BIP338 with a breaking p2p change and blocksonly meaning "feefilter=max"?
5972021-03-04T19:47:42  <jnewbery> my original proposal was to script fRelay, but it seems that people rely on it to mean 'blocks only'
5982021-03-04T19:47:42  <wumpus> but it was originally intended to be some kind of internal, rarely used thing
5992021-03-04T19:47:52  <wumpus> not something GUI end users would face
6002021-03-04T19:47:55  <jnewbery> *scrap fRelay
6012021-03-04T19:48:09  <ariard> fwiw, core doesn't even commit to bip60 as a supported bip
6022021-03-04T19:48:41  <MarcoFalke> ariard: It only does when -blocksonly
6032021-03-04T19:48:41  <darosior> Fwiw i believe the GUI would show a fee estimation error in this case if no fallbackfee is set
6042021-03-04T19:48:43  <wumpus> e.g. there is no configuration dialog option to enable it
6052021-03-04T19:48:54  <sipa> darosior: fair point
6062021-03-04T19:49:14  <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
6072021-03-04T19:49:22  <wumpus> darosior: i think so too
6082021-03-04T19:49:27  <sipa> we don't support bip60 and never have
6092021-03-04T19:49:29  *** jungly <jungly!~jungly@host-212-171-255-115.pool212171.interbusiness.it> has joined #bitcoin-core-dev
6102021-03-04T19:49:34  <jonasschnelli> darosior: Yes. It will. But users with just set a manual fee
6112021-03-04T19:49:38  <sipa> or at least, we don't assume our peers do
6122021-03-04T19:49:44  <luke-jr> sipa: we send it
6132021-03-04T19:49:55  <luke-jr> iirc
6142021-03-04T19:49:56  <jnewbery> we always send fRelay, but don't expect our peers to
6152021-03-04T19:50:15  <sipa> luke-jr: BIP60 is about predictably-sized version messages, not just the fRelay flag
6162021-03-04T19:50:57  <jnewbery> we also don't require that our peers send starting height, subversion, etc
6172021-03-04T19:50:58  <luke-jr> sipa: but on the sender side
6182021-03-04T19:51:00  <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?
6192021-03-04T19:51:02  <ariard> even the original bip37 is really unclear if fRelay semantic is to disable tx-relay or just tx-announcement
6202021-03-04T19:51:05  <luke-jr> it doesn't require breakign non-BIP60 peers
6212021-03-04T19:51:10  <sipa> sdaftuar: hmm, true
6222021-03-04T19:51:40  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
6232021-03-04T19:52:20  <jnewbery> sdaftuar: you mean we expect them to read fRelay because we'll disconnect them if they send us a tx?
6242021-03-04T19:52:34  <sdaftuar> right, if we set fRelay=false i think we now disconnect if they ignore it
6252021-03-04T19:52:42  <ariard> unless you signal NODE_BLOOM
6262021-03-04T19:53:16  <MarcoFalke> Bitcoin Core implements BIP60, but doesn't require peers to implement it. (Like any other optional BIP)
6272021-03-04T19:53:38  <jnewbery> I'm not sure we do disconnect peers for that
6282021-03-04T19:53:58  <amiti> orly? I thought we disconnected for that too
6292021-03-04T19:54:02  <sdaftuar> jnewbery: it is possible i'm misremembering , i know i thought this at some point in the past and was wrong
6302021-03-04T19:54:09  <sipa> so i guess we could list BIP60 as implemented, actually
6312021-03-04T19:54:21  <MarcoFalke> jnewbery: I am pretty sure there is a "tx sent in violation of protocol" log
6322021-03-04T19:54:26  <ariard> iirc #15759 introduce the change of disconnecting block-relay-only peers sending us a transaction
6332021-03-04T19:54:30  <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
6342021-03-04T19:55:08  <jnewbery> but not if we send fRelay=false because we're in -blocksonly
6352021-03-04T19:55:24  <wumpus> 5 minutes to go for the meeting, ajonas still had an announcement wrt the developer survey
6362021-03-04T19:55:28  <MarcoFalke> jnewbery: Oh, I didn't know
6372021-03-04T19:55:47  <jnewbery> I may be wrong. I searched for fRelayTxes in net_processing
6382021-03-04T19:55:50  <sdaftuar> looks likew e disconnect in that case to me? can look later jnewbery
6392021-03-04T19:55:50  <amiti> https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L3001
6402021-03-04T19:56:07  <MarcoFalke> (Side note: we  also don't disconnect on feefilter=max violations)
6412021-03-04T19:56:13  <ariard> jnewbery: correct this was a pre-15759 behavior
6422021-03-04T19:56:26  <jnewbery> sdaftuar: ah, you're right. Thanks!
6432021-03-04T19:56:39  <jnewbery> ok, shall we let jonas have his three minutes? :)
6442021-03-04T19:56:41  <phantomcircuit> sipa, would the headers sync thing be appropriate in this meeting?
6452021-03-04T19:56:42  <wumpus> #topic Developer survey (ajonas)
6462021-03-04T19:56:54  <MarcoFalke> m_ignore_incoming_txs means "blocksonly"
6472021-03-04T19:56:55  <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.
6482021-03-04T19:57:06  <MarcoFalke> ajonas: Thanks for summing those up!
6492021-03-04T19:57:07  <jnewbery> MarcoFalke: yup. You're right
6502021-03-04T19:57:13  <wumpus> ajonas: thanks for doing this
6512021-03-04T19:57:27  <ajonas> Happy to!
6522021-03-04T19:57:42  <jnewbery> thank you ajonas!
6532021-03-04T19:57:52  <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
6542021-03-04T19:58:15  <ajonas> I think a labeling system might be worth trialing
6552021-03-04T19:58:24  <MarcoFalke> Obviously it can't be an objective metric (that a computer could measure), because then it would be gameable
6562021-03-04T19:58:32  <amiti> imo, communicating PR status should be the responsibility of the pr author instead of maintainers
6572021-03-04T19:58:52  <ajonas> But we could also add some meta data in the first comment that can be updated over time
6582021-03-04T19:58:59  <wumpus> what are the PR statuses in the first place?
6592021-03-04T19:59:08  <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"
6602021-03-04T19:59:22  <wumpus> i mean we have a few like 'waiting for author' 'needs rebase' but not sure what you mean here
6612021-03-04T19:59:43  <wumpus> MarcoFalke: yes, definitely
6622021-03-04T19:59:43  <ajonas> I think concept / approach ack vs deep code review
6632021-03-04T19:59:53  <MarcoFalke> wumpus: I'd say when there is no "needs rebase" label, the status is implicitly "needs review"
6642021-03-04T20:00:04  <wumpus> ok so like 'needs concept ACK'
6652021-03-04T20:00:21  <wumpus> we could add that, but yes, like amiti  says, authors have to request this
6662021-03-04T20:00:46  <ariard> draft status doesn't mean "needs concept ACK"?
6672021-03-04T20:00:55  <MarcoFalke> I am not sure if that makes sense. How would you know when to remove the "needs concept ACK" label?
6682021-03-04T20:00:59  <wumpus> ariard: maybe
6692021-03-04T20:01:05  <ajonas> I think the use of draft is inconsistent
6702021-03-04T20:01:08  <wumpus> ariard: we could use it for that
6712021-03-04T20:01:21  <wumpus> MarcoFalke: good point
6722021-03-04T20:01:28  <ariard> good thing with draft you can do it just a pr author, doesn't special repo permisions iirc
6732021-03-04T20:01:42  <wumpus> yes that is good
6742021-03-04T20:02:17  <wumpus> self-organizaing is good, anything that gives the maintainers more on their plate is probably not going to fly
6752021-03-04T20:02:36  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
6762021-03-04T20:03:15  <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
6772021-03-04T20:03:15  <wumpus> that concludes the meeting for today
6782021-03-04T20:03:17  <gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
6792021-03-04T20:03:27  <wumpus> #endmeeting
6802021-03-04T20:03:57  <sdaftuar> phantomcircuit: did you see my comments on your PR? curious if you think my description matches what you saw
6812021-03-04T20:04:21  <sdaftuar> regarding the headers sync issue
6822021-03-04T20:04:33  <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
6832021-03-04T20:04:46  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6842021-03-04T20:04:47  <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
6852021-03-04T20:04:47  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6862021-03-04T20:05:52  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Remote host closed the connection)
6872021-03-04T20:06:16  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
6882021-03-04T20:06:22  <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?
6892021-03-04T20:06:32  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
6902021-03-04T20:07:03  <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!
6912021-03-04T20:07:28  <MarcoFalke> sdaftuar: I think the point is that a miner can't mine a block during IBD? getblocktemplate will fail
6922021-03-04T20:07:48  <sdaftuar> MarcoFalke: -maxtipage exists for that exact reason
6932021-03-04T20:07:54  <MarcoFalke> ah
6942021-03-04T20:08:13  <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
6952021-03-04T20:08:26  <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.
6962021-03-04T20:08:43  <sipa> jonatack: heh
6972021-03-04T20:08:45  <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!
6982021-03-04T20:08:51  <sipa> jonatack: i might sign up
6992021-03-04T20:09:01  <amiti> sdaftuar: :)
7002021-03-04T20:09:13  <jonatack> sipa: same
7012021-03-04T20:10:08  <jonatack> ajonas: wdyt
7022021-03-04T20:10:36  <aj> wow, that was a lot of frelay discussion
7032021-03-04T20:10:53  <sipa> morning, aj
7042021-03-04T20:11:55  <phantomcircuit> sdaftuar, no i dont think that's right, we don't even inv if we support compact blocks do we?
7052021-03-04T20:13:46  <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?)
7062021-03-04T20:14:28  <sipa> needs haiku
7072021-03-04T20:16:11  <luke-jr> wut
7082021-03-04T20:16:30  <aj> phantomcircuit: isn't that only for the couple of peers we select/who select us for fast compact block relay?
7092021-03-04T20:17: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
7102021-03-04T20:17:39  <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
7112021-03-04T20:17:44  <sdaftuar> (along with other requirements)
7122021-03-04T20:17:54  <sdaftuar> so the point is, if a block is found, it should get announced
7132021-03-04T20:18:22  <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
7142021-03-04T20:19:41  <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
7152021-03-04T20:20:10  <sdaftuar> and if we're in IBD the direct fetch is disabled
7162021-03-04T20:21:50  <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
7172021-03-04T20:26:41  *** eoin <eoin!402b84c0@64.43.132.192> has quit IRC (Quit: Connection closed)
7182021-03-04T20:27:50  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
7192021-03-04T20:30:25  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
7202021-03-04T20:34:31  *** eoin <eoin!402b84c0@64.43.132.192> has joined #bitcoin-core-dev
7212021-03-04T20:35:04  <ajonas> aj: you caught me. foiled again!
7222021-03-04T20:35:57  *** promag <promag!~promag@188.250.84.129> has quit IRC (Ping timeout: 264 seconds)
7232021-03-04T20:36:22  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
7242021-03-04T20:36:22  <bitcoin-git> [bitcoin] practicalswift opened pull request #21364: fuzz: Avoid -Wreturn-type warnings (master...–Wreturn-type) https://github.com/bitcoin/bitcoin/pull/21364
7252021-03-04T20:36:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
7262021-03-04T20:37:00  *** lukedashjr <lukedashjr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
7272021-03-04T20:39:39  *** stortz <stortz!b1982408@177.152.36.8> has quit IRC (Quit: Connection closed)
7282021-03-04T20:39:49  <phantomcircuit> sdaftuar, on receipt of a compact block we only do getheaders if we're not in IBD
7292021-03-04T20:40:45  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Ping timeout: 264 seconds)
7302021-03-04T20:41:25  *** lukedashjr is now known as luke-jr
7312021-03-04T20:42:04  *** eoin <eoin!402b84c0@64.43.132.192> has quit IRC (Quit: Connection closed)
7322021-03-04T20:42:25  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
7332021-03-04T20:42:26  <sdaftuar> don't we send a getheaders if it doesnt' connect to our tip?
7342021-03-04T20:44:01  <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
7352021-03-04T20:45:00  <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.
7362021-03-04T20:45:26  <sdaftuar> however i don't think that can be implicated here, as it should never occur
7372021-03-04T20:46:47  <sdaftuar> (i also think we should fix that so we treat it the same as an unconnecting header, always)
7382021-03-04T20:48:41  <phantomcircuit> sdaftuar, only if we're not in ibd
7392021-03-04T20:51:59  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
7402021-03-04T20:52:23  <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
7412021-03-04T20:52:45  <andytoshi> but in PSBT2 it's invalid because keytype 0x0f is now the sequence number
7422021-03-04T20:52:56  <andytoshi> is it worth updating the text of PSBT0 for this
7432021-03-04T20:55:19  *** dr-orlovsky <dr-orlovsky!~dr-orlovs@31.14.40.19> has quit IRC (Quit: ZNC 1.8.0 - https://znc.in)
7442021-03-04T20:55:33  *** dr-orlovsky <dr-orlovsky!~dr-orlovs@31.14.40.19> has joined #bitcoin-core-dev
7452021-03-04T21:03:14  <achow101> andytoshi: probably. I think I updated it in the implementation pr but not the bip pr
7462021-03-04T21:03:33  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 264 seconds)
7472021-03-04T21:04:07  <andytoshi> oh ok i'll see if i can find that .. you're saying there's a replacement test vector in the implementation?
7482021-03-04T21:04:41  <achow101> yes
7492021-03-04T21:04:49  <andytoshi> ah yep https://github.com/bitcoin/bitcoin/pull/21283/commits/73b569c26dc13f6727dd45f1469752890845fa78
7502021-03-04T21:06:08  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
7512021-03-04T21:06:27  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
7522021-03-04T21:08:49  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 260 seconds)
7532021-03-04T21:09:05  *** belcher_ is now known as belcher
7542021-03-04T21:15:41  <achow101> andytoshi: I've pushed the updated tests to my bips pr too
7552021-03-04T21:18:37  <andytoshi> oh thanks!
7562021-03-04T21:19:53  <phantomcircuit> sdaftuar, why would that never occur?
7572021-03-04T21:24:11  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has joined #bitcoin-core-dev
7582021-03-04T21:27:08  *** Kimi <Kimi!~Kiminuo@141.98.103.76> has quit IRC (Ping timeout: 245 seconds)
7592021-03-04T21:32:22  *** mekster <mekster!~mekster@139.180.192.79> has joined #bitcoin-core-dev
7602021-03-04T21:35:20  *** zivl <zivl!~zivl@unaffiliated/zivl> has joined #bitcoin-core-dev
7612021-03-04T21:37:17  *** zivl <zivl!~zivl@unaffiliated/zivl> has quit IRC (Client Quit)
7622021-03-04T21:45:23  <sipa> achow101: do we ever set the requested hashtype flag in PSBTs we create?
7632021-03-04T21:45:29  <sipa> (in bitcoin core)
7642021-03-04T21:48:47  <achow101> sipa: no
7652021-03-04T21:49:00  <achow101> err, I don't think so
7662021-03-04T21:50:38  <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
7672021-03-04T21:51:52  *** Guest13_ <Guest13_!~textual@64-18-155-61.starry-inc.net> has joined #bitcoin-core-dev
7682021-03-04T21:51:55  <sipa> but if we ever leak a hashtype via PSBT that might result in emitting a 0 there, which other signers would consider nonsensical
7692021-03-04T21:51:55  <achow101> seems reasonable
7702021-03-04T21:52:08  <sipa> also i think in some places we treat sighash=0 as "unspecified"
7712021-03-04T21:52:15  <achow101> yes
7722021-03-04T21:52:47  <achow101> I think we would only output a sighash type in a psbt if it was specified in a psbt
7732021-03-04T21:52:57  <achow101> and iirc none of the rpcs take a sighash type
7742021-03-04T21:55:49  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
7752021-03-04T21:58:41  <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
7762021-03-04T21:58:58  <sipa> i try this, and it correctly signs the first transactions, but not any subsequent ones
7772021-03-04T21:59:22  <achow101> change?
7782021-03-04T21:59:30  <achow101> it should work, and I think there's tests for it
7792021-03-04T22:00:16  <sipa> neither transaction has change inputs, but i do have an internal descriptor imported in both
7802021-03-04T22:00:19  <sipa> ok
7812021-03-04T22:00:25  <sipa> then it's likely a problem in my changes
7822021-03-04T22:00:40  *** justan0theruser is now known as justanotheruser
7832021-03-04T22:03:52  *** very_sne_ <very_sne_!~very_snea@45.67.96.42> has joined #bitcoin-core-dev
7842021-03-04T22:05:46  *** very_sneaky <very_sneaky!~very_snea@45.67.96.18> has quit IRC (Ping timeout: 265 seconds)
7852021-03-04T22:07:44  *** shaunsun <shaunsun!shaunsun@gateway/vpn/privateinternetaccess/shaunsun> has quit IRC (Ping timeout: 260 seconds)
7862021-03-04T22:11:25  <luke-jr> #17167 rebase done
7872021-03-04T22:11:26  <gribble> https://github.com/bitcoin/bitcoin/issues/17167 | Allow whitelisting outgoing connections by luke-jr · Pull Request #17167 · bitcoin/bitcoin · GitHub
7882021-03-04T22:11:45  *** Guest13_ <Guest13_!~textual@64-18-155-61.starry-inc.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
7892021-03-04T22:17:55  *** jespada <jespada!~jespada@90.254.243.187> has quit IRC (Ping timeout: 240 seconds)
7902021-03-04T22:20:27  *** jespada <jespada!~jespada@90.254.243.187> has joined #bitcoin-core-dev
7912021-03-04T22:49:52  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
7922021-03-04T22:49:52  <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
7932021-03-04T22:49:53  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
7942021-03-04T22:58:00  *** parazyd <parazyd!~parazyd@devuan/developer/parazyd> has joined #bitcoin-core-dev
7952021-03-04T23:03:43  *** jonatack <jonatack!~jon@37.173.203.38> has quit IRC (Ping timeout: 256 seconds)
7962021-03-04T23:06:37  *** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC (Ping timeout: 276 seconds)
7972021-03-04T23:08:33  *** Guest13 <Guest13!~textual@64-18-155-61.starry-inc.net> has joined #bitcoin-core-dev
7982021-03-04T23:12:56  *** dqx <dqx!~dqx@unaffiliated/dqx> has joined #bitcoin-core-dev
7992021-03-04T23:13:49  *** victorSN5 <victorSN5!~victorSN@unaffiliated/victorsn> has joined #bitcoin-core-dev
8002021-03-04T23:15:09  <achow101> ooh taproot
8012021-03-04T23:15:14  *** jonatack <jonatack!~jon@37.173.203.38> has joined #bitcoin-core-dev
8022021-03-04T23:15:29  *** victorSN <victorSN!~victorSN@unaffiliated/victorsn> has quit IRC (Read error: Connection reset by peer)
8032021-03-04T23:15:30  *** victorSN5 is now known as victorSN
8042021-03-04T23:21:46  *** Guest13 <Guest13!~textual@64-18-155-61.starry-inc.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
8052021-03-04T23:22:50  *** Guest13 <Guest13!~textual@64-18-155-61.starry-inc.net> has joined #bitcoin-core-dev
8062021-03-04T23:27:17  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 272 seconds)
8072021-03-04T23:27:41  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
8082021-03-04T23:38:40  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
8092021-03-04T23:43:42  <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
8102021-03-04T23:50:43  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 272 seconds)
8112021-03-04T23:51:11  *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
8122021-03-04T23:56:06  *** jungly <jungly!~jungly@host-212-171-255-115.pool212171.interbusiness.it> has quit IRC (Ping timeout: 246 seconds)
8132021-03-04T23:56:13  *** jonatack <jonatack!~jon@37.173.203.38> has quit IRC (Ping timeout: 260 seconds)
8142021-03-04T23:56:57  *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has quit IRC (Remote host closed the connection)
8152021-03-04T23:57:38  *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
8162021-03-04T23:59:49  *** jonatack <jonatack!~jon@37.173.203.38> has joined #bitcoin-core-dev