12020-12-03T00:00:08 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Quit: Leaving)
22020-12-03T00:00:55 *** TheRec_ <TheRec_!~toto@drupal.org/user/146860/view> has joined #bitcoin-core-dev
32020-12-03T00:01:22 *** TheRec <TheRec!~toto@drupal.org/user/146860/view> has quit IRC (Ping timeout: 246 seconds)
42020-12-03T00:03:05 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
52020-12-03T00:17:45 *** davterra <davterra!~davterra@68.235.43.158> has quit IRC (Ping timeout: 240 seconds)
62020-12-03T00:31:09 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
72020-12-03T00:31:23 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@171.5.161.165> has joined #bitcoin-core-dev
82020-12-03T00:33:37 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@171.5.161.165> has quit IRC (Client Quit)
92020-12-03T00:39:05 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th> has joined #bitcoin-core-dev
102020-12-03T00:41:16 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
112020-12-03T01:11:26 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
122020-12-03T01:23:56 *** davterra <davterra!~davterra@static-198-54-131-92.cust.tzulo.com> has joined #bitcoin-core-dev
132020-12-03T01:27:04 *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
142020-12-03T01:30:49 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 264 seconds)
152020-12-03T01:35:29 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
162020-12-03T01:35:29 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Disconnected by services)
172020-12-03T01:37:12 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC (Ping timeout: 272 seconds)
182020-12-03T01:42:45 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Remote host closed the connection)
192020-12-03T01:44:05 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
202020-12-03T01:46:12 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:359b:3052:cb08:82ec> has quit IRC (Ping timeout: 260 seconds)
212020-12-03T01:48:43 *** Asbestos_Vapor <Asbestos_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has joined #bitcoin-core-dev
222020-12-03T01:49:31 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
232020-12-03T01:52:25 *** Mercury_Vapor <Mercury_Vapor!~Mercury_V@174-082-166-092.res.spectrum.com> has quit IRC (Ping timeout: 240 seconds)
242020-12-03T01:53:56 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 240 seconds)
252020-12-03T01:57:22 *** tylerlevine6 <tylerlevine6!~hardforkt@li120-195.members.linode.com> has joined #bitcoin-core-dev
262020-12-03T01:59:25 *** tylerlevine6 <tylerlevine6!~hardforkt@li120-195.members.linode.com> has quit IRC (Client Quit)
272020-12-03T01:59:40 *** tylerlevine <tylerlevine!~hardforkt@li120-195.members.linode.com> has joined #bitcoin-core-dev
282020-12-03T02:04:50 *** tylerlevine <tylerlevine!~hardforkt@li120-195.members.linode.com> has quit IRC (Quit: The Lounge - https://thelounge.chat)
292020-12-03T02:10:46 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
302020-12-03T02:12:05 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 240 seconds)
312020-12-03T02:15:13 *** tlev7 <tlev7!~tlev@li120-195.members.linode.com> has joined #bitcoin-core-dev
322020-12-03T02:15:14 *** tlev7 <tlev7!~tlev@li120-195.members.linode.com> has quit IRC (Client Quit)
332020-12-03T02:15:15 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
342020-12-03T02:15:16 *** TheRec_ <TheRec_!~toto@drupal.org/user/146860/view> has quit IRC (Ping timeout: 240 seconds)
352020-12-03T02:15:30 *** tlev <tlev!~tlev@li120-195.members.linode.com> has joined #bitcoin-core-dev
362020-12-03T02:19:30 *** molz_ <molz_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 256 seconds)
372020-12-03T02:30:55 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
382020-12-03T02:36:24 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
392020-12-03T02:48:13 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
402020-12-03T02:52:44 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 260 seconds)
412020-12-03T03:09:55 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
422020-12-03T03:12:50 *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
432020-12-03T03:13:17 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
442020-12-03T03:15:36 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
452020-12-03T03:17:15 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
462020-12-03T03:20:44 *** molz_ <molz_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
472020-12-03T03:24:49 *** RusAlex <RusAlex!~Chel@unaffiliated/rusalex> has quit IRC (Ping timeout: 260 seconds)
482020-12-03T03:26:02 *** RusAlex <RusAlex!~Chel@unaffiliated/rusalex> has joined #bitcoin-core-dev
492020-12-03T03:27:18 *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
502020-12-03T03:28:58 *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 256 seconds)
512020-12-03T03:30:16 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
522020-12-03T03:31:20 *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
532020-12-03T03:34:07 *** dermoth_ <dermoth_!~dermoth@unaffiliated/dermoth> has joined #bitcoin-core-dev
542020-12-03T03:34:27 *** dermoth <dermoth!~dermoth@unaffiliated/dermoth> has quit IRC (Disconnected by services)
552020-12-03T03:34:29 *** dermoth_ is now known as dermoth
562020-12-03T03:37:17 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has quit IRC (Quit: pinheadmz)
572020-12-03T03:44:39 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
582020-12-03T03:44:45 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
592020-12-03T03:44:54 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has joined #bitcoin-core-dev
602020-12-03T03:49:02 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
612020-12-03T03:50:50 <aj> #proposedmeetingtopic bitcoin-util cli utility for 19937 (see also 14671 and 18573)
622020-12-03T03:52:57 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
632020-12-03T04:41:02 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
642020-12-03T04:45:42 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
652020-12-03T04:54:18 *** Katlyn27Runolfsd <Katlyn27Runolfsd!~Katlyn27R@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
662020-12-03T04:57:28 *** Bullit <Bullit!~Bullit01@163.158.236.42> has quit IRC (Quit: Defeated by Superior)
672020-12-03T05:00:03 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
682020-12-03T05:01:11 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has quit IRC (Remote host closed the connection)
692020-12-03T05:03:04 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has quit IRC (Quit: pinheadmz)
702020-12-03T05:07:01 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has joined #bitcoin-core-dev
712020-12-03T05:12:30 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
722020-12-03T05:18:12 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Remote host closed the connection)
732020-12-03T05:28:26 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has quit IRC (Quit: pinheadmz)
742020-12-03T05:50:33 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
752020-12-03T05:58:58 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has quit IRC (Quit: leaving)
762020-12-03T06:00:07 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-mblandatniuyyvuo> has joined #bitcoin-core-dev
772020-12-03T06:01:18 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
782020-12-03T06:01:43 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
792020-12-03T06:01:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
802020-12-03T06:01:59 <bitcoin-git> [gui] Bosch-0 opened pull request #143: Add icon policy documentation (master...icon_policy) https://github.com/bitcoin-core/gui/pull/143
812020-12-03T06:02:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
822020-12-03T06:03:29 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
832020-12-03T06:03:29 <bitcoin-git> [gui] Bosch-0 opened pull request #144: Merge pull request #1 from bitcoin-core/master (master...master) https://github.com/bitcoin-core/gui/pull/144
842020-12-03T06:03:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
852020-12-03T06:03:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
862020-12-03T06:03:50 <bitcoin-git> [gui] Bosch-0 closed pull request #144: Merge pull request #1 from bitcoin-core/master (master...master) https://github.com/bitcoin-core/gui/pull/144
872020-12-03T06:04:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
882020-12-03T06:10:51 *** tralfaz <tralfaz!~davterra@static-198-54-131-92.cust.tzulo.com> has joined #bitcoin-core-dev
892020-12-03T06:11:19 *** kexkey <kexkey!~kexkey@static-198-54-132-169.cust.tzulo.com> has quit IRC (Ping timeout: 246 seconds)
902020-12-03T06:12:19 *** davterra <davterra!~davterra@static-198-54-131-92.cust.tzulo.com> has quit IRC (Read error: Connection reset by peer)
912020-12-03T06:15:13 *** Guest19 <Guest19!~textual@78-0-24-193.adsl.net.t-com.hr> has joined #bitcoin-core-dev
922020-12-03T06:29:08 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 244 seconds)
932020-12-03T06:33:31 *** Kiminuo <Kiminuo!~mix@194.213.208.81> has joined #bitcoin-core-dev
942020-12-03T06:36:13 *** guest534543 <guest534543!~mix@141.98.103.196> has joined #bitcoin-core-dev
952020-12-03T06:37:41 *** guest534543 <guest534543!~mix@141.98.103.196> has quit IRC (Client Quit)
962020-12-03T06:38:03 *** guest534543 <guest534543!~mix@141.98.103.196> has joined #bitcoin-core-dev
972020-12-03T06:40:14 *** Kiminuo <Kiminuo!~mix@194.213.208.81> has quit IRC (Ping timeout: 260 seconds)
982020-12-03T06:50:12 *** Katlyn27Runolfsd <Katlyn27Runolfsd!~Katlyn27R@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 256 seconds)
992020-12-03T06:52:52 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
1002020-12-03T07:31:33 *** chrisch1974 <chrisch1974!~chrisch19@139.28.218.148> has quit IRC (Remote host closed the connection)
1012020-12-03T07:32:40 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Remote host closed the connection)
1022020-12-03T07:37:49 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1032020-12-03T07:38:00 *** virtu <virtu!~virtu@gateway/tor-sasl/virtu> has quit IRC (Remote host closed the connection)
1042020-12-03T07:38:15 *** virtu <virtu!~virtu@gateway/tor-sasl/virtu> has joined #bitcoin-core-dev
1052020-12-03T07:38:57 *** ctrlbreak_MAD <ctrlbreak_MAD!~ctrlbreak@159.2.182.106> has joined #bitcoin-core-dev
1062020-12-03T07:42:30 *** ctrlbreak <ctrlbreak!~ctrlbreak@159.2.182.106> has quit IRC (Ping timeout: 256 seconds)
1072020-12-03T07:45:56 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has quit IRC (Read error: Connection reset by peer)
1082020-12-03T07:47:01 *** CubicEarth <CubicEarth!~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net> has joined #bitcoin-core-dev
1092020-12-03T07:52:04 *** feb <feb!~feb@178.162.212.214> has joined #bitcoin-core-dev
1102020-12-03T07:57:29 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1112020-12-03T08:05:39 *** benthecarman <benthecarman!~ben@108-95-148-10.lightspeed.austtx.sbcglobal.net> has joined #bitcoin-core-dev
1122020-12-03T08:09:39 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@ppp-223-24-170-139.revip6.asianet.co.th> has joined #bitcoin-core-dev
1132020-12-03T08:09:55 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-mblandatniuyyvuo> has quit IRC (Quit: Connection closed for inactivity)
1142020-12-03T08:20:13 *** twistedline <twistedline!~twisted@unaffiliated/twistedline> has quit IRC (Read error: Connection reset by peer)
1152020-12-03T08:21:19 *** twistedline <twistedline!~twisted@unaffiliated/twistedline> has joined #bitcoin-core-dev
1162020-12-03T08:35:07 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-hjzqeykpbkgroeyg> has joined #bitcoin-core-dev
1172020-12-03T08:38:39 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1182020-12-03T08:42:27 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@ppp-223-24-170-139.revip6.asianet.co.th> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
1192020-12-03T08:51:49 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1202020-12-03T08:56:30 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has quit IRC (Ping timeout: 256 seconds)
1212020-12-03T08:58:24 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1> has joined #bitcoin-core-dev
1222020-12-03T09:08:07 *** TheRec <TheRec!~toto@84-75-225-47.dclient.hispeed.ch> has joined #bitcoin-core-dev
1232020-12-03T09:11:55 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1242020-12-03T09:11:55 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a35b948836db...681ce59d0eac
1252020-12-03T09:11:56 <bitcoin-git> bitcoin/master fad7be5 MarcoFalke: test: Fix intermittent p2p_finerprint issue
1262020-12-03T09:11:56 <bitcoin-git> bitcoin/master 681ce59 MarcoFalke: Merge #20466: test: Fix intermittent p2p_fingerprint issue
1272020-12-03T09:11:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1282020-12-03T09:12:10 *** benthecarman <benthecarman!~ben@108-95-148-10.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 260 seconds)
1292020-12-03T09:12:15 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1302020-12-03T09:12:15 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #20466: test: Fix intermittent p2p_fingerprint issue (master...2011-testIntFixp2p) https://github.com/bitcoin/bitcoin/pull/20466
1312020-12-03T09:12:16 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1322020-12-03T09:19:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1332020-12-03T09:19:43 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20556: rpc: Properly document return values (submitblock, gettxout, getblocktemplate, scantxoutset) (master...2012-rpcDoc) https://github.com/bitcoin/bitcoin/pull/20556
1342020-12-03T09:19:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1352020-12-03T09:35:51 *** Guest19 <Guest19!~textual@78-0-24-193.adsl.net.t-com.hr> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
1362020-12-03T09:37:17 <promag> MarcoFalke: is #20017 something to push forward? what is the best time work on it?
1372020-12-03T09:37:20 <gribble> https://github.com/bitcoin/bitcoin/issues/20017 | rpc: Add RPCContext by promag · Pull Request #20017 · bitcoin/bitcoin · GitHub
1382020-12-03T09:43:27 <MarcoFalke> promag: Heh, depends on other reviewers
1392020-12-03T09:48:30 <promag> I don't mean to merge. with branch 21 "done" maybe its something to work on early on 22
1402020-12-03T09:54:19 *** Guest19 <Guest19!~textual@95.168.100.138> has joined #bitcoin-core-dev
1412020-12-03T09:56:48 *** jonatack <jonatack!~jon@88.124.242.136> has quit IRC (Ping timeout: 256 seconds)
1422020-12-03T09:57:15 *** jonatack <jonatack!~jon@134.19.179.187> has joined #bitcoin-core-dev
1432020-12-03T10:21:25 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
1442020-12-03T10:40:49 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1452020-12-03T10:40:49 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #20548: RPC: Tolerate unknown parameters, but with clear warning/errors (master...soften_rpcauth) https://github.com/bitcoin/bitcoin/pull/20548
1462020-12-03T10:40:50 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1472020-12-03T11:00:39 *** Guest19 <Guest19!~textual@95.168.100.138> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
1482020-12-03T11:02:28 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Remote host closed the connection)
1492020-12-03T11:03:19 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
1502020-12-03T11:03:42 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 260 seconds)
1512020-12-03T11:18:22 *** Madaline26Gibson <Madaline26Gibson!~Madaline2@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
1522020-12-03T11:25:31 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
1532020-12-03T11:39:14 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1542020-12-03T11:39:14 <bitcoin-git> [bitcoin] jnewbery opened pull request #20557: addrman: Fix new table bucketing during unserialization (master...2020-12-fix-addrman-bucketing) https://github.com/bitcoin/bitcoin/pull/20557
1552020-12-03T11:39:15 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1562020-12-03T11:43:03 *** roconnor <roconnor!~roconnor@host-45-58-200-239.dyn.295.ca> has quit IRC (Remote host closed the connection)
1572020-12-03T11:51:13 *** molz_ <molz_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 264 seconds)
1582020-12-03T11:55:36 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1592020-12-03T11:56:14 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
1602020-12-03T11:56:46 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1612020-12-03T11:58:09 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
1622020-12-03T12:23:46 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1632020-12-03T12:23:46 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/681ce59d0eac...a3186b6da60e
1642020-12-03T12:23:47 <bitcoin-git> bitcoin/master c82d15b Hennadii Stepanov: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux
1652020-12-03T12:23:48 <bitcoin-git> bitcoin/master a3186b6 Wladimir J. van der Laan: Merge #20520: depends: Do not force Precompiled Headers (PCH) for building...
1662020-12-03T12:23:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1672020-12-03T12:24:16 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1682020-12-03T12:24:16 <bitcoin-git> [bitcoin] laanwj merged pull request #20520: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux (master...201127-pch) https://github.com/bitcoin/bitcoin/pull/20520
1692020-12-03T12:24:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1702020-12-03T12:24:54 *** bosch-0 <bosch-0!uid472282@gateway/web/irccloud.com/x-hjzqeykpbkgroeyg> has quit IRC (Quit: Connection closed for inactivity)
1712020-12-03T12:37:36 *** Madaline26Gibson <Madaline26Gibson!~Madaline2@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 240 seconds)
1722020-12-03T12:40:14 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 264 seconds)
1732020-12-03T12:40:32 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1742020-12-03T12:43:50 *** pinheadmz <pinheadmz!~pinheadmz@71.190.30.138> has joined #bitcoin-core-dev
1752020-12-03T12:47:08 *** dviola <dviola!~diego@unaffiliated/dviola> has joined #bitcoin-core-dev
1762020-12-03T12:48:50 *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
1772020-12-03T12:50:38 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1782020-12-03T13:03:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1792020-12-03T13:03:00 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20558: test: Add MaybeCompactWalletDB tsan suppression (take 2) (master...2012-testSanTsan) https://github.com/bitcoin/bitcoin/pull/20558
1802020-12-03T13:03:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1812020-12-03T13:04:40 *** reallll is now known as belcher
1822020-12-03T13:04:58 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
1832020-12-03T13:05:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1842020-12-03T13:05:45 <bitcoin-git> [bitcoin] naumenkogs closed pull request #20539: Avoid rebucketing on restart when it's not necessary (master...2020-12-01-rebucket-asmap-fix) https://github.com/bitcoin/bitcoin/pull/20539
1852020-12-03T13:05:46 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1862020-12-03T13:08:56 *** rhiaro <rhiaro!~opendatas@178.62.242.100> has quit IRC (Quit: No Ping reply in 180 seconds.)
1872020-12-03T13:10:01 *** rhiaro <rhiaro!~opendatas@178.62.242.100> has joined #bitcoin-core-dev
1882020-12-03T13:16:58 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
1892020-12-03T13:21:22 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 256 seconds)
1902020-12-03T13:28:26 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1912020-12-03T13:35:13 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1> has joined #bitcoin-core-dev
1922020-12-03T13:35:24 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
1932020-12-03T13:35:25 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Disconnected by services)
1942020-12-03T13:36:05 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
1952020-12-03T13:42:24 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1962020-12-03T13:42:25 <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a3186b6da60e...3fa6a9fc8c90
1972020-12-03T13:42:25 <bitcoin-git> bitcoin/master 8b99e60 Aaron Clauson: Adjusted msvc compiler and linker settings to remove optimisations that ar...
1982020-12-03T13:42:26 <bitcoin-git> bitcoin/master 2c69381 Aaron Clauson: Removed redundant git pull from appveyor config.
1992020-12-03T13:42:26 <bitcoin-git> bitcoin/master 3fa6a9f Wladimir J. van der Laan: Merge #20506: ci: AppVeyor fixes for Visual Studio 2019 16.8.1 image
2002020-12-03T13:42:28 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2012020-12-03T13:42:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2022020-12-03T13:42:44 <bitcoin-git> [bitcoin] laanwj merged pull request #20506: ci: AppVeyor fixes for Visual Studio 2019 16.8.1 image (master...msvc-no-optimise) https://github.com/bitcoin/bitcoin/pull/20506
2032020-12-03T13:42:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2042020-12-03T13:42:58 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
2052020-12-03T13:48:38 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:9156:658b:3008:cf:28b1> has quit IRC (Ping timeout: 264 seconds)
2062020-12-03T13:53:28 *** feb <feb!~feb@178.162.212.214> has quit IRC (Remote host closed the connection)
2072020-12-03T13:54:48 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2082020-12-03T13:54:49 <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/3fa6a9fc8c90...a0489f3472f3
2092020-12-03T13:54:49 <bitcoin-git> bitcoin/master 467c346 Hennadii Stepanov: net: Drop unneeded Windows headers in compat.h
2102020-12-03T13:54:50 <bitcoin-git> bitcoin/master f796f00 Hennadii Stepanov: net: Drop unneeded headers when compat.h included
2112020-12-03T13:54:51 <bitcoin-git> bitcoin/master cadb77a Hennadii Stepanov: net: Add compat.h header for htonl function
2122020-12-03T13:54:52 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2132020-12-03T13:55:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2142020-12-03T13:55:08 <bitcoin-git> [bitcoin] laanwj merged pull request #20221: net: compat.h related cleanup (master...201022-compat) https://github.com/bitcoin/bitcoin/pull/20221
2152020-12-03T13:55:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2162020-12-03T13:55:19 *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
2172020-12-03T13:55:47 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 265 seconds)
2182020-12-03T14:02:36 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
2192020-12-03T14:04:57 *** vasild_ is now known as vasild
2202020-12-03T14:07:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2212020-12-03T14:07:17 <bitcoin-git> [bitcoin] testingaccount234234 opened pull request #20559: Update README.md (master...fix-readme-term-change) https://github.com/bitcoin/bitcoin/pull/20559
2222020-12-03T14:07:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2232020-12-03T14:09:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2242020-12-03T14:09:02 <bitcoin-git> [bitcoin] laanwj closed pull request #20559: Update README.md (master...fix-readme-term-change) https://github.com/bitcoin/bitcoin/pull/20559
2252020-12-03T14:09:03 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2262020-12-03T14:10:14 *** reallll <reallll!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 272 seconds)
2272020-12-03T14:11:03 *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
2282020-12-03T14:23:25 *** sunweaver1 <sunweaver1!~sunweaver@185.163.110.125> has joined #bitcoin-core-dev
2292020-12-03T14:24:34 <vasild> hebasto: I guess s/a0489f3/0e2d9ef/ in your comment https://github.com/bitcoin/bitcoin/pull/20182#issuecomment-738023008
2302020-12-03T14:25:57 <hebasto> vasild: thanks! fixed
2312020-12-03T14:28:03 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
2322020-12-03T14:28:44 <vasild> yw :)
2332020-12-03T14:30:42 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
2342020-12-03T14:37:18 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
2352020-12-03T14:37:48 *** shesek <shesek!~shesek@unaffiliated/shesek> has joined #bitcoin-core-dev
2362020-12-03T14:40:42 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
2372020-12-03T14:43:16 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
2382020-12-03T14:48:15 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Quit: leaving)
2392020-12-03T14:59:58 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has quit IRC (Ping timeout: 256 seconds)
2402020-12-03T15:05:01 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
2412020-12-03T15:07:44 *** guest534543 <guest534543!~mix@141.98.103.196> has quit IRC (Ping timeout: 260 seconds)
2422020-12-03T15:09:49 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
2432020-12-03T15:33:40 *** reallll is now known as belcher
2442020-12-03T15:35:56 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
2452020-12-03T15:36:20 *** Kiminuo <Kiminuo!~mix@141.98.103.196> has joined #bitcoin-core-dev
2462020-12-03T15:37:27 *** miketwenty1 <miketwenty1!~miketwent@ec2-18-211-157-212.compute-1.amazonaws.com> has joined #bitcoin-core-dev
2472020-12-03T15:41:26 <miketwenty1> Question about bitcoin builds and gitian builds, when you build from source you can put in build options/flags to exclude/include certain things like whether or not the wallet, UPnP, zmq.. are these build options baked into gitian builds to enable everything? If I for example wanted to do a gitian build and not build someone or include something do I have this flexibility?
2482020-12-03T15:42:16 <miketwenty1> not build something* like exclude wallet
2492020-12-03T15:42:44 <fanquake> yes
2502020-12-03T15:42:55 <fanquake> just adjust the CONFIGFLAGS in the gitian descriptor
2512020-12-03T15:42:56 <fanquake> https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L42
2522020-12-03T15:43:52 <miketwenty1> ok.. but this would now result in different binaries if you start messing with the descriptor files right?
2532020-12-03T15:44:28 <fanquake> yes
2542020-12-03T15:51:37 <miketwenty1> in the future / even with guix .. would you imagine gitian sigs for multiple common options for each minor/major release of bitcoin? like one with everything enabled.. another build is just the node.. another build with zmq and maybe a few other things .. etc..
2552020-12-03T15:54:02 <fanquake> Yes that's possible, and probably quite likely. I'd imagine there are many people running bitcoin nodes, that have no interest in it supporting UPNP, ZMQ, or even having the wallet compiled into it.
2562020-12-03T15:55:11 *** budo <budo!4f45b238@79-69-178-56.dynamic.dsl.as9105.com> has joined #bitcoin-core-dev
2572020-12-03T15:57:22 *** budo <budo!4f45b238@79-69-178-56.dynamic.dsl.as9105.com> has quit IRC (Remote host closed the connection)
2582020-12-03T16:03:57 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
2592020-12-03T16:06:06 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 260 seconds)
2602020-12-03T16:06:51 <luke-jr> jnewbery: are you trolling? "to make life easier for maintainers of downstream projects."
2612020-12-03T16:07:18 *** belcher <belcher!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
2622020-12-03T16:10:55 <luke-jr> I mean, not only is the premise false, but you're saying you want to reject my PRs simply to go out of the way to discriminate against and make things harder for me personally?
2632020-12-03T16:22:06 <harding> luke-jr: what are you responding to?
2642020-12-03T16:23:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2652020-12-03T16:23:34 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #20560: fuzz: Link all targets once (master...2012-fuzzLinkOnce) https://github.com/bitcoin/bitcoin/pull/20560
2662020-12-03T16:23:35 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2672020-12-03T16:25:14 <harding> Ah, that was a comment from https://github.com/bitcoin/bitcoin/pull/20548
2682020-12-03T16:27:35 *** kexkey <kexkey!~kexkey@static-198-54-132-121.cust.tzulo.com> has joined #bitcoin-core-dev
2692020-12-03T16:27:39 *** jeremyrubin <jeremyrubin!~jr@c-73-15-215-148.hsd1.ca.comcast.net> has joined #bitcoin-core-dev
2702020-12-03T16:30:44 *** jarolrod <jarolrod!uid475272@gateway/web/irccloud.com/x-rlfzxaphdcoussrw> has joined #bitcoin-core-dev
2712020-12-03T16:51:15 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
2722020-12-03T16:51:43 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
2732020-12-03T16:52:44 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 256 seconds)
2742020-12-03T17:11:51 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2752020-12-03T17:11:51 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #20550: RPC: Tolerate invalid rpcauth options (master...soften_rpcauth2) https://github.com/bitcoin/bitcoin/pull/20550
2762020-12-03T17:11:52 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2772020-12-03T17:12:14 *** Kiminuo <Kiminuo!~mix@141.98.103.196> has quit IRC (Read error: Connection reset by peer)
2782020-12-03T17:13:07 <luke-jr> MarcoFalke: please stop abusing github access
2792020-12-03T17:13:51 <MarcoFalke> the pull has three NACKs, I am personally fine with it, but I don't see how it could be merged
2802020-12-03T17:14:17 <luke-jr> there isn't a single NACK
2812020-12-03T17:16:20 <luke-jr> and all three negative-sounding comments, are based on false assumptions
2822020-12-03T17:16:48 <luke-jr> (contrast to the change this is fixing, where I had in fact posted a reasoned NACK on true premises)
2832020-12-03T17:17:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2842020-12-03T17:17:30 <bitcoin-git> [bitcoin] MarcoFalke reopened pull request #20550: RPC: Tolerate invalid rpcauth options (master...soften_rpcauth2) https://github.com/bitcoin/bitcoin/pull/20550
2852020-12-03T17:17:31 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2862020-12-03T17:18:25 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 246 seconds)
2872020-12-03T17:22:06 <promag> > On the command line only, not in config files
2882020-12-03T17:22:20 <promag> why?
2892020-12-03T17:23:16 <promag> what's the reason for this behavior? I wasn't aware of it
2902020-12-03T17:23:38 <promag> and are you saying that -rpcauth=foo on the cmdline should fail?
2912020-12-03T17:23:51 <luke-jr> promag: config files are expected to possibly have unknown options
2922020-12-03T17:24:18 <luke-jr> -rpcauth=foo on the cmdline failing sounds okay - I can't think of a use case for tolerating that
2932020-12-03T17:24:32 <promag> this is a known option though
2942020-12-03T17:24:35 <luke-jr> and it would match the existing behaviour
2952020-12-03T17:24:54 <promag> it's a known option with an invalid value
2962020-12-03T17:24:57 <luke-jr> promag: >3 fields is unknown
2972020-12-03T17:26:19 <promag> no, it's invalid
2982020-12-03T17:26:40 <luke-jr> â¦
2992020-12-03T17:27:32 <promag> for instance, -zmqpubrawtx=foo is invalid, not unknown
3002020-12-03T17:28:49 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
3012020-12-03T17:29:06 <luke-jr> except rpcauth isn't zmqpubrawtx
3022020-12-03T17:29:30 <luke-jr> it's a group
3032020-12-03T17:30:18 <luke-jr> it also has no effect on startup/running
3042020-12-03T17:32:00 <promag> iirc invalid zmqpubrawtx fails init
3052020-12-03T17:33:57 <promag> hmm checking
3062020-12-03T17:34:07 <luke-jr> as it needs to
3072020-12-03T17:34:14 <luke-jr> ZMQ is something that needs to be understood at startup..
3082020-12-03T17:34:27 <luke-jr> it actually affects what startup does
3092020-12-03T17:36:12 *** proofofkeags <proofofkeags!~proofofke@c-73-34-43-4.hsd1.co.comcast.net> has joined #bitcoin-core-dev
3102020-12-03T17:37:01 <sipa> why would rpcauth be any different?
3112020-12-03T17:37:30 <sipa> if software doesn't know what an option means, it should fail
3122020-12-03T17:37:42 <luke-jr> it can fail at runtime, for that one user
3132020-12-03T17:37:43 <sipa> this seems especially true for something as security-sensitive as rpcauth
3142020-12-03T17:38:28 <luke-jr> it can be reasonably assumed that >3 fields would be used for more details in the future
3152020-12-03T17:39:20 <sipa> what if the option means "only allowed to run certain RPCs"?
3162020-12-03T17:39:30 <luke-jr> that's why it fails at runtime ;)
3172020-12-03T17:39:40 <sipa> that seems incredibly annoying
3182020-12-03T17:39:44 <luke-jr> how?
3192020-12-03T17:39:58 <sipa> "wth is this not working"
3202020-12-03T17:40:01 <luke-jr> we don't throw errors if the config file has GUI options, in non-GUI builds..
3212020-12-03T17:40:13 <luke-jr> sipa: well, that's why my first PR had an explanatory error..
3222020-12-03T17:40:18 <sipa> because they have a known meaning
3232020-12-03T17:40:50 <harding> But if the future config says that user foo can only run RPC bar and you use that config with an old node, now user foo can run dumpwallet. That doesn't sound sane.
3242020-12-03T17:41:09 <luke-jr> harding: that's not correct; it will refuse to let user foo do anything
3252020-12-03T17:41:21 <sipa> harding: luke-jr's point is that this should be detected, and then refuse *any* RPCs from that user
3262020-12-03T17:41:37 <luke-jr> sipa: that's how it always worked, yes
3272020-12-03T17:41:41 <sipa> which is not crazy, but still far more annoying than just failing
3282020-12-03T17:42:09 <luke-jr> sipa: #20548 would give the user "Invalid rpcauth configuration line" as an error
3292020-12-03T17:42:10 <harding> Ok. Agree that's not insane.
3302020-12-03T17:42:12 <gribble> https://github.com/bitcoin/bitcoin/issues/20548 | RPC: Tolerate unknown parameters, but with clear warning/errors by luke-jr · Pull Request #20548 · bitcoin/bitcoin · GitHub
3312020-12-03T17:42:28 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3322020-12-03T17:46:16 <luke-jr> sipa: annoying in theory for some corner case that probably has never occurred, perhaps; but the new behaviour is annoying in practice for real users..
3332020-12-03T17:47:22 <luke-jr> (or if you want to pretend Knots doesn't exist, it's a lot more realistic a hypothesis to talk about users of a future Core version making use of the 4th+ field)
3342020-12-03T17:47:52 <sipa> luke-jr: i don't think the existence of Knots is relevant in this discussion
3352020-12-03T17:48:41 <luke-jr> my point is it's a lot more realistic an annoyance to error at startup, than to error at runtime might be in some weird case
3362020-12-03T17:48:56 <sipa> i'm not confinced about that
3372020-12-03T17:48:58 <luke-jr> k
3382020-12-03T17:49:07 <promag> tbh I prefer startup errors
3392020-12-03T17:49:15 <luke-jr> err, how not? (sorry, misread "convinced" as "confused")
3402020-12-03T17:49:33 <luke-jr> promag: even when it isn't actually an error?
3412020-12-03T17:50:15 <luke-jr> users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
3422020-12-03T17:50:31 <sipa> i can see the argument in favor of instituting a policy that future rpcauth flags are reserved for future restrictions of the permission, and thus that it is safe to treat unknown ones as "act as if the auth line didn't exist"
3432020-12-03T17:50:58 <sipa> but that's orthogonal to the question if we should in general aim to reject unknown options
3442020-12-03T17:51:17 <luke-jr> and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
3452020-12-03T17:51:35 <luke-jr> (error at startup vs runtime means the latter needs to fix the problem either way)
3462020-12-03T17:51:53 <sipa> yes, but at startup you immediately know the problem is there and fix it
3472020-12-03T17:52:14 <sipa> if it happens at runtime it may result in wondering why CoinFancyPoolMixer stopped working
3482020-12-03T17:52:15 <luke-jr> but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
3492020-12-03T17:52:25 <luke-jr> all to workaround an erroneous error message..
3502020-12-03T17:52:57 <sipa> but it's not an erroneous message; if the node can't do what you're asking it to do in the configuration, something is wrong and you need to fix it
3512020-12-03T17:53:04 <sipa> as it's won't do what you ask it to do
3522020-12-03T17:53:10 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
3532020-12-03T17:58:39 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
3542020-12-03T18:00:25 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 246 seconds)
3552020-12-03T18:03:24 <luke-jr> [17:49:33] <luke-jr> promag: even when it isn't actually an error?
3562020-12-03T18:03:26 <luke-jr> [17:50:15] <luke-jr> users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
3572020-12-03T18:03:28 <luke-jr> [17:51:17] <luke-jr> and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
3582020-12-03T18:03:29 <luke-jr> [17:51:34] <luke-jr> (error at startup vs runtime means the latter needs to fix the problem either way)
3592020-12-03T18:03:31 <luke-jr> [17:52:15] <luke-jr> but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
3602020-12-03T18:04:15 <sipa> if you're going to frequently switch between different versions, it seems entirely reasonable to have 2 config files and use -conf
3612020-12-03T18:04:36 * luke-jr peers at freenode
3622020-12-03T18:05:04 <sipa> or, more likely, not rely on any features that are only present in one version
3632020-12-03T18:08:36 <luke-jr> all the avoid one node restart of some hypothetical guy with a truly erroneous rpcauth line that is unlikely to ever exist�
3642020-12-03T18:09:29 <sipa> no
3652020-12-03T18:09:57 <sipa> to make sure that someone who is relying on a future command line option doesn't need to break his head over why it isn't working
3662020-12-03T18:10:23 <sipa> i'm talking generically, not specifically about rpcauth
3672020-12-03T18:11:27 <promag> I'd bet lots of startups were lost to bad -rpcauth :)
3682020-12-03T18:12:10 <luke-jr> I'm starting to like promag's -strict idea
3692020-12-03T18:12:35 <sipa> i think that will fail to have the same effect; people just won't turn it on
3702020-12-03T18:12:42 <luke-jr> sipa: it could possibly be on by default
3712020-12-03T18:12:49 <sipa> that's fair
3722020-12-03T18:12:53 <luke-jr> then people who want to switch between versions regularly can just put strict=0 in bitcoin.conf
3732020-12-03T18:13:06 <promag> yeah, on by default
3742020-12-03T18:17:16 <promag> like gcc -Werror
3752020-12-03T18:17:27 <luke-jr> well, -Werror is not on by default :P
3762020-12-03T18:20:59 *** zndtoshi <zndtoshi!~zndtoshi@79.112.20.148> has joined #bitcoin-core-dev
3772020-12-03T18:21:10 <promag> right, bad example because it is an error in the first place x)
3782020-12-03T18:22:23 <luke-jr> promag: so do you want to do the PR, or should I? :p
3792020-12-03T18:22:31 *** owowo <owowo!~ovovo@unaffiliated/ovovo> has joined #bitcoin-core-dev
3802020-12-03T18:23:01 <promag> you mean -strict ?
3812020-12-03T18:23:04 <luke-jr> yes
3822020-12-03T18:24:17 <promag> hmmm
3832020-12-03T18:26:02 <promag> :) I mean, if it gets concept ack why not, it could be discussed in the meeting
3842020-12-03T18:26:25 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
3852020-12-03T18:27:40 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
3862020-12-03T18:39:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3872020-12-03T18:39:43 <bitcoin-git> [bitcoin] sdaftuar opened pull request #20561: p2p: periodically clear m_addr_known, and choose new peers to receive relayed addresses (master...2020-12-moar-addrz) https://github.com/bitcoin/bitcoin/pull/20561
3882020-12-03T18:39:44 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3892020-12-03T18:45:19 *** adiabat <adiabat!~adiabat@63.209.32.102> has quit IRC (Ping timeout: 260 seconds)
3902020-12-03T18:50:41 <jnewbery> luke-jr: not trolling. If a PR is opened where the goal is primarily to make things easier for downstream projects, then (1) that should be explicitly declared in the PR description (2) it should be judged for inclusion in Bitcoin Core solely on whether it's a benefit to the users of this project.
3912020-12-03T18:52:35 <wumpus> agreed...
3922020-12-03T18:58:55 <luke-jr> jnewbery: that wasn't even the case here
3932020-12-03T18:59:19 <wumpus> what is this altnerative syntax that you introduced in a downstream project anyway?
3942020-12-03T19:00:12 <jonatack> meeting?
3952020-12-03T19:00:16 <achow101> meeting?
3962020-12-03T19:00:24 <sipa> meeting?
3972020-12-03T19:00:28 <wumpus> we could, I guess, ignore alternative syntax that we know about and don't support, though it's a bit strange
3982020-12-03T19:00:35 <wumpus> but it's better than ignoring all errors
3992020-12-03T19:00:38 <wumpus> #startmeeting
4002020-12-03T19:00:38 <core-meetingbot> Meeting started Thu Dec 3 19:00:38 2020 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
4012020-12-03T19:00:38 <core-meetingbot> Available commands: action commands idea info link nick
4022020-12-03T19:00:40 <jonasschnelli> hi
4032020-12-03T19:00:45 <jonatack> hi
4042020-12-03T19:00:46 <promag> howdy
4052020-12-03T19:00:51 <hebasto> hi
4062020-12-03T19:00:57 <jnewbery> hi
4072020-12-03T19:00:58 <wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
4082020-12-03T19:01:00 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
4092020-12-03T19:01:01 <luke-jr> wumpus: #10615 has supported a 4th field with a wallet name
4102020-12-03T19:01:04 <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
4112020-12-03T19:01:23 <achow101> hi
4122020-12-03T19:01:30 <wumpus> luke-jr: oh okay, so separate access control per wallet
4132020-12-03T19:01:32 <amiti> hi
4142020-12-03T19:01:42 <fjahr> hi
4152020-12-03T19:01:46 <sipa> hi
4162020-12-03T19:02:22 <luke-jr> wumpus: yes; not sure what else it could be used for, but the behaviour of rejecting the line (at runtime) should be generally safe
4172020-12-03T19:02:23 <aj> hi
4182020-12-03T19:02:24 <luke-jr> hi
4192020-12-03T19:02:27 <wumpus> two proposed topics for today: rc3, 0.19 release, 0.20 release (marcofalke), bitcoin-util cli utility for 19937 (aj)
4202020-12-03T19:03:00 <MarcoFalke> hi
4212020-12-03T19:03:05 <luke-jr> wumpus: maybe should add -strict if we have time
4222020-12-03T19:03:07 <jonasschnelli> #19937
4232020-12-03T19:03:09 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
4242020-12-03T19:03:27 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:21a3:28f3:d78:7f10> has joined #bitcoin-core-dev
4252020-12-03T19:03:44 <wumpus> any last minute topics anyone wants to discuss?
4262020-12-03T19:04:10 *** Chris_Stewart_5 <Chris_Stewart_5!~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383> has quit IRC (Read error: Connection reset by peer)
4272020-12-03T19:04:25 <wumpus> #topic High priority for review
4282020-12-03T19:04:25 <core-meetingbot> topic: High priority for review
4292020-12-03T19:04:46 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 11 blockers, 2 chasing concept ACK
4302020-12-03T19:05:27 <jonatack> can rm #20483
4312020-12-03T19:05:30 <gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
4322020-12-03T19:06:06 <wumpus> jonatack: done
4332020-12-03T19:06:09 <MarcoFalke> I'd like to switch mine out for #20362
4342020-12-03T19:06:12 <gribble> https://github.com/bitcoin/bitcoin/issues/20362 | test: Implicitly sync after generate* to preempt races and intermittent test failures by MarcoFalke · Pull Request #20362 · bitcoin/bitcoin · GitHub
4352020-12-03T19:06:13 <jonatack> (it can't go in until we have estimatefeerate / setfeerate)
4362020-12-03T19:06:23 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
4372020-12-03T19:06:37 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has quit IRC (Quit: Leaving)
4382020-12-03T19:07:10 <wumpus> MarcoFalke: done
4392020-12-03T19:07:14 <wumpus> jonatack: yes, makes sense
4402020-12-03T19:07:14 <MarcoFalke> thx
4412020-12-03T19:07:24 <jonatack> (e.g. sat/vB versions of settxfee and estimatesmartfee)
4422020-12-03T19:08:17 <wumpus> anything else to add/remove? or that's ready to merge?
4432020-12-03T19:08:40 <wumpus> #19937 is already a topic in itself
4442020-12-03T19:08:43 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
4452020-12-03T19:09:04 <hebasto> jnewbery: kindly reminder to rebase #19910
4462020-12-03T19:09:06 <gribble> https://github.com/bitcoin/bitcoin/issues/19910 | net processing: Move peer_map to PeerManager by jnewbery · Pull Request #19910 · bitcoin/bitcoin · GitHub
4472020-12-03T19:09:18 *** Emcy <Emcy!~Emcy@unaffiliated/emcy> has joined #bitcoin-core-dev
4482020-12-03T19:09:31 <jnewbery> hebasto: thanks. Will do!
4492020-12-03T19:10:35 <wumpus> #topic rc3, 0.19 release, 0.20 release (marcofalke)
4502020-12-03T19:10:36 <core-meetingbot> topic: rc3, 0.19 release, 0.20 release (marcofalke)
4512020-12-03T19:10:58 <MarcoFalke> ok, 0.19 first. Are we going to tag a release?
4522020-12-03T19:11:02 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/46 is empty
4532020-12-03T19:11:16 <wumpus> sounds fine to me
4542020-12-03T19:11:18 <MarcoFalke> if yes, are we going to gitian build?
4552020-12-03T19:11:23 <luke-jr> might as well do a rc1 at least
4562020-12-03T19:11:33 <wumpus> I think that's what he means, tag rc1
4572020-12-03T19:11:36 <luke-jr> whether there will be enough people who test it to warrant a final, dunno
4582020-12-03T19:12:24 <wumpus> well we can tag it we'll see if people care about building it
4592020-12-03T19:12:24 <luke-jr> looks like 0.19 is still pretty common use
4602020-12-03T19:12:35 <MarcoFalke> Ok, so it seems 0.19.2rc1 soon
4612020-12-03T19:12:37 <luke-jr> ~12% of the network
4622020-12-03T19:12:40 <MarcoFalke> Then 0.20
4632020-12-03T19:12:46 <wumpus> not really something I care about but tagging isn't much work
4642020-12-03T19:12:57 <wumpus> 0.20 on the other hand
4652020-12-03T19:13:02 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/49
4662020-12-03T19:13:26 <MarcoFalke> There is one issue, hasen't gotten more review
4672020-12-03T19:13:31 <MarcoFalke> What to do about that?
4682020-12-03T19:13:42 <MarcoFalke> outstanding thing is #19740
4692020-12-03T19:13:45 <gribble> https://github.com/bitcoin/bitcoin/issues/19740 | [0.20] wallet: Simplify and fix CWallet::SignTransaction by achow101 · Pull Request #19740 · bitcoin/bitcoin · GitHub
4702020-12-03T19:13:58 <luke-jr> most 0.19 nodes are 0.19.0.1 still
4712020-12-03T19:14:00 <hebasto> if 0.21 is around the coner is 0.19.2 really needed?
4722020-12-03T19:14:24 <MarcoFalke> hebasto: At least the tag, so that people building from source can use it
4732020-12-03T19:14:25 <luke-jr> hebasto: doesn't hurt
4742020-12-03T19:14:33 <hebasto> ok
4752020-12-03T19:14:50 <MarcoFalke> the branch will be deleted eventually, so a tag also helps to archive the latest branch
4762020-12-03T19:15:08 <wumpus> looks like 19740 has some difficulty getting review, please focus on that, 0.20 is much more relevant
4772020-12-03T19:15:10 <hebasto> MarcoFalke: I see
4782020-12-03T19:15:31 <MarcoFalke> does 19740 warrant holding back 0.20.2?
4792020-12-03T19:15:46 <wumpus> maybe we should add it to high prio
4802020-12-03T19:15:50 <luke-jr> probably not
4812020-12-03T19:15:56 <wumpus> achow101: here?
4822020-12-03T19:16:05 <MarcoFalke> I think we should ping reviewers directly
4832020-12-03T19:16:09 <luke-jr> IIRC I hit the bug only by some corner case
4842020-12-03T19:16:12 <achow101> MarcoFalke: IMO yes. it's a pretty significant bug
4852020-12-03T19:16:33 <MarcoFalke> achow101: Any suggestions who could review it?
4862020-12-03T19:17:01 <achow101> meshcollider and ryanofsky at least
4872020-12-03T19:17:02 *** adiabat <adiabat!~adiabat@63.209.32.102> has joined #bitcoin-core-dev
4882020-12-03T19:17:04 <wumpus> it's ony a change in one function, a very important one though
4892020-12-03T19:17:33 <MarcoFalke> I checked that the function content is copied from master, that is easy to check
4902020-12-03T19:17:39 <achow101> and anyone who reviewed the changes leading up to descriptor wallets
4912020-12-03T19:18:30 <MarcoFalke> what is the worst thing that could happen? I guess a tx could come back unsigned?
4922020-12-03T19:18:52 <achow101> yes
4932020-12-03T19:20:05 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
4942020-12-03T19:20:11 <wumpus> the functional tests should catch that though
4952020-12-03T19:20:47 <MarcoFalke> SignTransaction is marked const, so it shouldn't modify the spkm either
4962020-12-03T19:21:08 <achow101> the bug was that a fully signed tx would come back as supposedly not complete, although nothing would change in that tx
4972020-12-03T19:21:13 <MarcoFalke> Seems almost safe to merge as-is (famous last words?)
4982020-12-03T19:21:43 <jonatack> nice simplification, surprising that no tests need to be updated if something was broken
4992020-12-03T19:21:49 <achow101> given that 0.20 only has the LegacySPKM implemented, I think this could be trivially correct?
5002020-12-03T19:22:23 <wumpus> jonatack: right seems there's no test for the fixed behavior
5012020-12-03T19:22:52 <wumpus> in any case if it's 'trivially correct' I'd like to see some ACKs soon :)
5022020-12-03T19:22:54 <jonatack> a description of what was broken/fixed in the PR or commit would be nice
5032020-12-03T19:23:11 <achow101> #17204 apparently tests this kind of accidentally
5042020-12-03T19:23:13 <gribble> https://github.com/bitcoin/bitcoin/issues/17204 | wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code (sipa) by meshcollider · Pull Request #17204 · bitcoin/bitcoin · GitHub
5052020-12-03T19:24:17 <wumpus> would be worth a try then maybe
5062020-12-03T19:24:46 <MarcoFalke> #action tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
5072020-12-03T19:24:46 <core-meetingbot> ACTION: tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
5082020-12-03T19:25:09 <MarcoFalke> ok, finally rc3
5092020-12-03T19:25:15 <MarcoFalke> Anything missing for rc3?
5102020-12-03T19:25:25 <jnewbery> is there definitely going to be an rc3?
5112020-12-03T19:25:35 <sipa> short topic: can people read over https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.21.0-Release-Notes-Draft? i think a few things are missing
5122020-12-03T19:25:36 <wumpus> do we have any serious issues reported for rc2 yet?
5132020-12-03T19:25:58 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/45
5142020-12-03T19:26:09 <MarcoFalke> jnewbery: Yes, stuff has been merged, so there must be one
5152020-12-03T19:26:23 <wumpus> did we merge stuff? oh
5162020-12-03T19:26:26 <jonatack> achow101: you mean the test I added in 17204? That PR was a bit of a head-scratcher tbh
5172020-12-03T19:26:48 <sipa> #20511: i think we should drop it for 0.21
5182020-12-03T19:26:49 <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
5192020-12-03T19:27:03 <MarcoFalke> merged stuff: https://github.com/bitcoin/bitcoin/commits/0.21
5202020-12-03T19:27:09 <sipa> it's harder to fix than i initially imagined, and anchors.dat didn't exist at all so it's a new feature anyway
5212020-12-03T19:27:10 <wumpus> did we have any regressions then?
5222020-12-03T19:27:36 <sdaftuar> what's the status of sendaddrv2/bip155, there was a report that it caused other peers to disconnect us i think?
5232020-12-03T19:27:44 <luke-jr> couldn't anchors.dat store all V2 then?
5242020-12-03T19:27:48 <jnewbery> sipa: I removed #20511 from the milestone
5252020-12-03T19:27:49 <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
5262020-12-03T19:28:52 <MarcoFalke> sdaftuar: Yes, the protocol version wasn't bumped, and some peers use the protocol version to determine which message types are "expected"
5272020-12-03T19:28:55 <sipa> sdaftuar: you mean gating it based on protocol version?
5282020-12-03T19:29:01 <sdaftuar> yes, that
5292020-12-03T19:29:09 <jnewbery> If we're doing an rc3, then I think we should merge a change to only send sendaddrv2 to peers on v70016+
5302020-12-03T19:29:16 <wumpus> my initial proposal was to increase the protocol version but this was almost universally hated
5312020-12-03T19:29:16 <sipa> we did bump the version number anyway, right?
5322020-12-03T19:29:31 <MarcoFalke> is 70016 the version of wtxidrelay?
5332020-12-03T19:29:45 <jnewbery> and if we're doing that (which means changing the code and spec), then we should also move it to be done between version and verack like wtxidrelay
5342020-12-03T19:29:47 <wumpus> everyone wanted some other mechanism
5352020-12-03T19:29:49 <sipa> wumpus: this isn't about protocol version vs sendaddrv2; it's about using protocol version to know whether "sendaddrv2" is a legal message
5362020-12-03T19:29:52 <wumpus> so where is it given problems?
5372020-12-03T19:30:03 <sdaftuar> i think the feedback from maintainers of other software was a preference to bump the version numbers when we roll out new messages like this, since that is easy, i think we should
5382020-12-03T19:30:09 <wumpus> we don't have *any* mechanism like that
5392020-12-03T19:30:10 <jnewbery> wumpus: btcd drops the connection if it receives a sendaddrv2
5402020-12-03T19:30:18 <wumpus> that's their problem
5412020-12-03T19:30:20 <MarcoFalke> libbitcoin might, too
5422020-12-03T19:30:27 <sipa> wumpus: i agree it's silly
5432020-12-03T19:30:39 <wumpus> we've always ignored unknown messages
5442020-12-03T19:30:51 <wumpus> and that's how it should be
5452020-12-03T19:31:15 <wumpus> it was always the idea that new messages could be used as an extension mechanism
5462020-12-03T19:31:21 <hebasto> ^^^ isn't this rule a part of ptotocol?
5472020-12-03T19:31:27 <sipa> apparently historically new messages have always been accompagnied with a protocol bump; i'm kind of surprised by this, as it forces serialized coordination for adding new messages
5482020-12-03T19:31:45 <wumpus> sipa: exactly
5492020-12-03T19:31:50 <sipa> hebasto: "the protocol" will differ depending on who you ask
5502020-12-03T19:31:54 <wumpus> it shouldn't be like that in a decentralized protocol
5512020-12-03T19:32:06 <luke-jr> NACK bullying other implementations on the p2p protocol
5522020-12-03T19:32:14 <wumpus> I'm pretty sure we've added messages before without increasing the version
5532020-12-03T19:32:17 <luke-jr> though I agree it's a dumb idea to force protocol version increments like this
5542020-12-03T19:32:26 <wumpus> "bullying" wtf
5552020-12-03T19:32:29 <wumpus> come on
5562020-12-03T19:32:44 <MarcoFalke> incrementing the protocol version number doesn't mean p2p dev is centralized
5572020-12-03T19:32:45 <luke-jr> wumpus: causing them to disconnect when we could easily remain compatible?
5582020-12-03T19:32:46 <sipa> i don't think this is bullying; it's a disagreement about what the protocol entails
5592020-12-03T19:33:01 <wumpus> luke-jr: it was their choice to disconnect on a silly reason like that
5602020-12-03T19:33:08 <sdaftuar> whatever we decide to do, i think the updated bip that describes what we do should be reposted to the mailing list
5612020-12-03T19:33:09 <aj> btcd would stay connected to 0.20 and earlier nodes so won't drop off from the network entirely, no? is this that big a problem?
5622020-12-03T19:33:13 <luke-jr> wumpus: this isn't their change
5632020-12-03T19:33:23 <wumpus> in any case my first proposal for the BIP was to do it with a version bump
5642020-12-03T19:33:34 <wumpus> but no one wanted it and now suddenly ...
5652020-12-03T19:33:43 <jonasschnelli> Was/is there a reason to _not_ bump the protocol version for addr2?
5662020-12-03T19:33:49 <wumpus> just because some other imnplementation does something weird
5672020-12-03T19:33:54 <jonasschnelli> like it was done for sendheaders BIP 130
5682020-12-03T19:33:55 <MarcoFalke> wumpus: Yes, I think it wasn't clear that btcd and libbitcoin did that
5692020-12-03T19:33:58 <wumpus> I honestly don't know
5702020-12-03T19:34:04 <sipa> wumpus: oh, another minor point is that the bip and the implementation currently mismatch
5712020-12-03T19:34:05 <MarcoFalke> wumpus: I just learned about that last week
5722020-12-03T19:34:12 <wumpus> I'm not going to reconsider based on that anyway
5732020-12-03T19:34:13 <sipa> wumpus: about a related thing
5742020-12-03T19:34:47 <sipa> the bip says send sendaddrv2 after receiving verack, but the implementation sends it after sending verack
5752020-12-03T19:34:59 <luke-jr> right now, the network is all talking fine; Core intentionally deploying a change that breaks it seems wrong
5762020-12-03T19:35:01 <Victorsueca> ´causing them to disconnect when we could easily remain compatible?´ < The reverse could also be said, causing us to implement things in a specific way when they could easily ignore the messages?
5772020-12-03T19:35:26 <wumpus> so they don't plan on implementing addrv2 at all?
5782020-12-03T19:35:31 <wumpus> let's just drop it
5792020-12-03T19:35:39 <sipa> wumpus: what?
5802020-12-03T19:35:54 <sipa> they're just concerned because their _old_ versions can't talk to new core anymore
5812020-12-03T19:36:05 <wumpus> sipa: Im ean if no one else wants to move forward on that
5822020-12-03T19:36:23 <jonasschnelli> why not just bump the protocol version?
5832020-12-03T19:36:26 <wumpus> or maybe don't send addrv2 to ipv4 and ipv6 nodes at all
5842020-12-03T19:36:54 <wumpus> they don't care about the other networks
5852020-12-03T19:37:06 <sdaftuar> i'm a bit confused. the only question is whether to send the "sendaddrv2" message on startup?
5862020-12-03T19:37:09 <luke-jr> they might
5872020-12-03T19:37:26 <MarcoFalke> I think for rc3 we should aim for a minimal fix (or no fix at all)
5882020-12-03T19:37:31 <MarcoFalke> I liked jnewbery's suggestion
5892020-12-03T19:37:45 <MarcoFalke> I suspect that can be implemented with a one-line patch
5902020-12-03T19:37:46 <jnewbery> It's really just a very small fix, moving a few lines of code
5912020-12-03T19:37:59 <jnewbery> and updating the BIP to match
5922020-12-03T19:38:01 <wumpus> but addrv2 isn't bound to any protocol version
5932020-12-03T19:38:03 <hebasto> but we bumper protocol version due to new wtxidrelay message
5942020-12-03T19:38:06 <wumpus> it shouldn't be
5952020-12-03T19:38:27 <hebasto> #18044
5962020-12-03T19:38:29 <sipa> that part doesn't even need a bip change; we can just as courtesy decide to not send sendaddrv2 below a certain protocol version, because we know locally that things with lower protocol version don't support it anyway
5972020-12-03T19:38:31 <wumpus> it's silly to do this now in a last minute rc chang
5982020-12-03T19:38:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
5992020-12-03T19:38:41 <sipa> wumpus: yeah...
6002020-12-03T19:38:52 <jnewbery> wumpus: i'm confused. You said earlier you wanted it to be done with a version bump
6012020-12-03T19:38:59 <wumpus> jnewbery: at the time, yes
6022020-12-03T19:39:00 <luke-jr> anyone want to throw together a BIP saying the same protocol version bump also implies unknown messages are ignored? ;)
6032020-12-03T19:39:05 <MarcoFalke> and the workaround can be removed later on
6042020-12-03T19:39:13 <wumpus> then we spent months discussing it and no one else wanted it
6052020-12-03T19:39:19 <sipa> luke-jr: good luck opening that can of worms again
6062020-12-03T19:39:22 <luke-jr> though I suspect libbitcoin will disagree with that BIP
6072020-12-03T19:39:25 <wumpus> because it was so much easier to do it without a version bump
6082020-12-03T19:39:35 <jnewbery> wumpus: why is it easier?
6092020-12-03T19:39:43 <sdaftuar> luke-jr: i proposed something similar recently, and then withdrew it after opposition on the mailing list
6102020-12-03T19:39:49 <wumpus> because agreeing on a version bump is hard ESPECIALLY BETWEEN IMPLEMENTATIONS
6112020-12-03T19:39:54 <luke-jr> sigh
6122020-12-03T19:40:14 <wumpus> just adding an identification message allowed for a mechanism to extend the protocol without a central point of agreement !
6132020-12-03T19:40:42 <wumpus> this doensn't bind it together with other protocol changes
6142020-12-03T19:40:57 <sipa> wumpus: well, i fully agree
6152020-12-03T19:41:02 <wumpus> so implemetnations can implement and relay v2 without implementing other protocol changes
6162020-12-03T19:41:07 <wumpus> so many people told this to me
6172020-12-03T19:41:14 <sipa> but isn't it reasonable to try to not break things on the existing network, regardless of who is at fault for it?
6182020-12-03T19:41:40 <jonasschnelli> I agree. IMO it should be handled on the side of btcd/libbitcoin. Dropping on unknown messages makes backward compatibility just insanely hard.
6192020-12-03T19:41:51 <wumpus> yes
6202020-12-03T19:41:57 <luke-jr> jonasschnelli: can't change deployed nodes
6212020-12-03T19:42:04 <jonasschnelli> Sure you can
6222020-12-03T19:42:06 <luke-jr> â¦
6232020-12-03T19:42:10 <jonasschnelli> by upgrading
6242020-12-03T19:42:10 <sipa> jonasschnelli: ?
6252020-12-03T19:42:27 <jonasschnelli> I guess a fix send a wrong signal
6262020-12-03T19:42:29 <aj> or by adding a compatability node in between
6272020-12-03T19:42:30 <MarcoFalke> Maybe we shouldn't modify the bip, but add a temporary patch to be able to speak to non-upgraded nodes
6282020-12-03T19:42:38 <sipa> i'm happy to reach out to btcd and tell them this is silly, and we don't think it makes sense to continue this... but in order not to break their existing nodes, we'll not send sendaddrv2 to older versions this one time
6292020-12-03T19:42:53 <sipa> MarcoFalke: that's my suggestion
6302020-12-03T19:43:24 <luke-jr> what about libbitcoin which fundamentally disagrees with us?
6312020-12-03T19:43:36 <jonasschnelli> Probably an adequate trade-off. There is just the risk our codebase will have many workaround in the future to protect falling alternative implementations
6322020-12-03T19:43:37 <sipa> i can't comprehend their stance
6332020-12-03T19:43:44 <wumpus> as ssaid we don't need this for ipv4/ipv6 nodes
6342020-12-03T19:43:46 <luke-jr> sipa: I suspect it's just disagreement for the sake of disagreement :/
6352020-12-03T19:43:51 <MarcoFalke> luke-jr: I think that can be hashed out on the mailing list
6362020-12-03T19:44:02 <wumpus> maybe I made a mistake to try this at all
6372020-12-03T19:44:02 <MarcoFalke> no need to block rc3 on resolving that discussion
6382020-12-03T19:44:04 <sipa> wumpus: we do want torv3 addresses to relay across ipv4/ipv6 nodes
6392020-12-03T19:44:12 <jonasschnelli> wumpus: no you didn't
6402020-12-03T19:44:33 <luke-jr> MarcoFalke: true
6412020-12-03T19:44:33 <jonasschnelli> It's clearly a missimplementation
6422020-12-03T19:44:43 <sipa> wumpus: indeed you don't- i think there are just misunderstandings about what the protocol entails
6432020-12-03T19:44:53 <sipa> and it's unfortunate that this comes out now
6442020-12-03T19:45:02 <wumpus> mostly sorry for vasild who did all the actual implementation work
6452020-12-03T19:45:08 <luke-jr> jonasschnelli: it's intentional, so not mis-
6462020-12-03T19:45:11 <jonatack> is there a post on the btcd/libbitcoin position and plans? seems quite late
6472020-12-03T19:45:16 <jonasschnelli> are they (btcd) dropping on any unknown message?
6482020-12-03T19:45:46 <jonasschnelli> or to they just pin valid message to protocol versions?
6492020-12-03T19:45:47 <wumpus> jonatack: yes, why does this come up last minute? between rcs?
6502020-12-03T19:45:49 <MarcoFalke> wumpus: I think it was the right choice, and everyone agreed with you. the mismatch on the live network was just not anticipated back then.
6512020-12-03T19:46:03 <sipa> wumpus: well that's when people test
6522020-12-03T19:46:15 <sdaftuar> i am not sure an updated version of bip155 was ever sent to the mailing list describing that the version bump was being dropped. so it's hard to blame them, imo, other than for a long-running misunderstanding of how we think unknown messaegs should be treated
6532020-12-03T19:46:41 <luke-jr> sdaftuar: we also have no authority to impose BIP155 on them anyway
6542020-12-03T19:46:49 <sdaftuar> luke-jr: agreed
6552020-12-03T19:46:50 <sipa> sdaftuar: i think the initial discussion was about version bump vs sendaddrv2 as the negotiation mechanism itself
6562020-12-03T19:46:51 <MarcoFalke> (we still have one more topic, so we should slowly wrap up)
6572020-12-03T19:46:58 <wumpus> they're free to not implement it, but disconnecting just doens't make sese
6582020-12-03T19:47:13 <wumpus> there's no question of "authority" here
6592020-12-03T19:47:19 <wumpus> they're preventing us from implementing new messages
6602020-12-03T19:47:38 <wumpus> sipa: yes
6612020-12-03T19:47:42 <luke-jr> well, preventing it from being implemented nicely anyway
6622020-12-03T19:48:04 <sipa> wumpus: yes, agree, i believe that going forward using new messages is absolutely the right way, not tied to protocol version
6632020-12-03T19:48:18 <wumpus> it's enforcing authority by denying the upgrade method of introducing new messages
6642020-12-03T19:48:22 <sdaftuar> sipa: was that discussion on hte mailing list?
6652020-12-03T19:48:39 <wumpus> because everyone needs to agree on new version numbers then
6662020-12-03T19:48:51 <wumpus> and what messages come with them
6672020-12-03T19:48:51 <sipa> wumpus: but it's kind of similar to "don't break userspace" in linux's philosophy... somehow someone ended up relying on something that wasn't guaranteed; we can be courteous and make sure it doesn't cause problems
6682020-12-03T19:49:02 <wumpus> this is not accetpable for a protocol that is not centrally coordinated
6692020-12-03T19:49:43 <sipa> https://github.com/btcsuite/btcd/issues/1661
6702020-12-03T19:49:45 <jonasschnelli> same with the service bits (a bit more flexible)
6712020-12-03T19:49:48 <wumpus> if there was some organization like IANA it'd be different
6722020-12-03T19:50:01 <MarcoFalke> there is still the "central" BIP repo
6732020-12-03T19:50:10 <sipa> looks like they were just completely unaware that ignoring unknown messages was the right thing to do, but are ok with ignoring unknown messages otherwise
6742020-12-03T19:50:10 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6752020-12-03T19:50:10 <bitcoin-git> [bitcoin] achow101 opened pull request #20562: tests: Test that a fully signed tx given to signrawtx is unchanged (master...test-signraw-fullysigned) https://github.com/bitcoin/bitcoin/pull/20562
6762020-12-03T19:50:11 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6772020-12-03T19:50:13 <luke-jr> IANA and BIPs aren't that different
6782020-12-03T19:50:43 <luke-jr> sipa: that's just btcd though; IIRC, libbitcoin disagrees explicitly
6792020-12-03T19:50:43 <wumpus> MarcoFalke: well, yes, but a lot of things get accepted as BIP, not only if they're really implemented
6802020-12-03T19:51:01 <jonasschnelli> indeed.
6812020-12-03T19:51:02 <MarcoFalke> as long as the bip process doesn't allow duplicate assignments, it shouldn't lead to issues
6822020-12-03T19:51:09 <wumpus> I mean 'accepted as BIP' as in merged to the repository
6832020-12-03T19:51:10 <jonasschnelli> Overlap of version numbers might happen quicky
6842020-12-03T19:51:14 <wumpus> it only has to ofllow basic protocol for that
6852020-12-03T19:51:14 <luke-jr> MarcoFalke: well, it does even then
6862020-12-03T19:51:26 <MarcoFalke> (not advocating for it, just saying it is possible)
6872020-12-03T19:51:30 <wumpus> it's not a real selection process
6882020-12-03T19:51:35 <luke-jr> if ver 100 defines X, and ver 101 defines Y, now everyone who wants Y needs X
6892020-12-03T19:51:36 <wumpus> nor a central coordination
6902020-12-03T19:51:58 <aj> luke-jr: needs X or needs to successfully ignore X
6912020-12-03T19:52:00 <MarcoFalke> luke-jr: it would be on top of the negotiation message type
6922020-12-03T19:52:08 <luke-jr> aj: good point
6932020-12-03T19:52:23 <jonasschnelli> define a protocol version where tolerating unknown message is a must?
6942020-12-03T19:52:33 <sipa> jonasschnelli: that's what sdaftuar tried
6952020-12-03T19:52:39 <wumpus> jonasschnelli: heh, use the reasoning against themselves
6962020-12-03T19:52:40 <jonasschnelli> I see
6972020-12-03T19:53:07 <luke-jr> jonasschnelli: but they will reject the BIP defining it
6982020-12-03T19:53:24 <wumpus> I'm pretty tired of this
6992020-12-03T19:53:30 <jonasschnelli> well,.. then it should be their mess to clean up?
7002020-12-03T19:53:30 <sipa> we don't need their consent to implement anything
7012020-12-03T19:53:39 <sipa> but we can take discussion points into accoutn
7022020-12-03T19:53:41 <sdaftuar> jonasschnelli: see thread starting here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018084.html
7032020-12-03T19:54:02 <wumpus> could freeze the current P2P network and define a new one :)
7042020-12-03T19:54:08 <sdaftuar> i think we should just decide what we want to do and let everyone know what that is
7052020-12-03T19:54:12 <luke-jr> jonasschnelli: that implies we have authority to impose this on them?
7062020-12-03T19:54:14 * sipa points at BIP324
7072020-12-03T19:54:23 <wumpus> with jonasschnelli 's encryption and stuff
7082020-12-03T19:54:33 <luke-jr> oooh good idea
7092020-12-03T19:54:34 <jonasschnelli> yes. That will be a nightmare
7102020-12-03T19:54:38 <aj> luke-jr: can't impose anything on them, they can keep disconnecting if they think that's desirable
7112020-12-03T19:54:39 <luke-jr> ?
7122020-12-03T19:54:47 <luke-jr> jonasschnelli: make the ignoring unknown msgs part of it
7132020-12-03T19:54:56 <wumpus> the old one will still work and it's entirely voluntary to implement it *shrug*
7142020-12-03T19:55:01 <jonasschnelli> Its not even messages in BIP324,.. its the handshake that is headerless
7152020-12-03T19:55:16 <aj> wumpus: bender meme, we'll make our own p2p with encryption and blow?
7162020-12-03T19:55:20 <jonasschnelli> agree with sdaftuar
7172020-12-03T19:55:39 <wumpus> I really don't want these kind of questions about authority, no one needs authority to do anything, that's not the point
7182020-12-03T19:55:41 <wumpus> aj: yess
7192020-12-03T19:55:57 <jonasschnelli> aj: heh. Yes.
7202020-12-03T19:55:59 <aj> blackjack and encryption apparently
7212020-12-03T19:56:08 <wumpus> and permissionlessness
7222020-12-03T19:56:33 <luke-jr> wumpus: when existing nodes on the network stop working because of a change we make, it takes authority to say that the blame is on someone else..
7232020-12-03T19:56:36 <aj> 4min left if we want to quickly discuss bitcoin-util
7242020-12-03T19:56:50 <wumpus> #topic bitcoin-util (aj)
7252020-12-03T19:56:51 <core-meetingbot> topic: bitcoin-util (aj)
7262020-12-03T19:56:52 <MarcoFalke> #action bender meme, we'll make our own p2p with encryption and blow?
7272020-12-03T19:56:52 <core-meetingbot> ACTION: bender meme, we'll make our own p2p with encryption and blow?
7282020-12-03T19:56:52 <wumpus> aj: sorry
7292020-12-03T19:56:57 <aj> #19937
7302020-12-03T19:57:00 <jonasschnelli> BIP324 is probably different since we want to get disconnected when the handshake is not supported
7312020-12-03T19:57:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
7322020-12-03T19:57:16 <MarcoFalke> aj: I still don't get why it needs a new way of parsing args
7332020-12-03T19:57:40 <aj> signet mining has high enough difficulty that grinding in python doesn't work. but gridning needs libconsensus code so can't be stuck in bitcoin-cli without bloating it
7342020-12-03T19:57:53 <MarcoFalke> this is just asking for an unmaintaible mess if new features are added
7352020-12-03T19:58:13 <aj> bitcoin-util as a generic thing has been proposed in #14671 iirc for doing things like psbt without needing a running node
7362020-12-03T19:58:15 <gribble> https://github.com/bitcoin/bitcoin/issues/14671 | Utility to replace RPC calls that dont need wallet or chain context · Issue #14671 · bitcoin/bitcoin · GitHub
7372020-12-03T19:58:15 <MarcoFalke> ACK on adding the utility in general
7382020-12-03T19:58:20 <wumpus> python bindings for libconsensus
7392020-12-03T19:58:26 <sipa> aj: any reason why it can't be an RPC?
7402020-12-03T19:58:35 <MarcoFalke> sipa: I asked that too
7412020-12-03T19:58:45 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 240 seconds)
7422020-12-03T19:58:45 <sipa> (i know it doesn't *need* to be an RPC, but in this specific case, is there a reason why that'd be problematic)
7432020-12-03T19:59:04 <aj> sipa: 14671 talks about not adding RPCs for utility functions in general, and having a separate command for that
7442020-12-03T19:59:23 <sipa> ok
7452020-12-03T19:59:27 <sipa> That's fair
7462020-12-03T19:59:44 <wumpus> I guess the drawback is adding yet another executable, which links in a lot of stuff, but if we have other plans for bitcoin-util apart from just the signet grinding it may be worth it
7472020-12-03T19:59:54 <aj> sipa: could be, but would be a bit weird. no specific problem i thnk. making "generate" just work is a pain since signet signing needs a wallet
7482020-12-03T20:00:01 <MarcoFalke> aj: If someone already has the server running, it might be faster to call the rpc instead of figuring out how to run the util
7492020-12-03T20:00:19 <aj> wumpus suggested adding it to bitcoin-tx which works fine (it already links libconsensus), but is klunky
7502020-12-03T20:00:34 <wumpus> it's too bad we already have bitcoin-tx with the same (in)dependency idea
7512020-12-03T20:00:37 <wumpus> yes
7522020-12-03T20:00:38 <andytoshi> in elements we had this issue with our signed blocks, we had to back out some of the separation between wallet and node
7532020-12-03T20:00:44 <andytoshi> which i was not happy about
7542020-12-03T20:00:49 <aj> might make sense to do it in bitcoin-tx now, and have a new PR later that adds bitcoin-util with multiple functionality bits (and better arg handling like MarcoFalke suggests)
7552020-12-03T20:00:58 <andytoshi> and i wish we didn't have that RPC. fwiw.
7562020-12-03T20:01:10 <sipa> andytoshi: that's useful information
7572020-12-03T20:01:30 <wumpus> aj: I don't particularly need to have that intermediate state FWIW
7582020-12-03T20:01:37 <wumpus> aj: if there are plans for bitcoin-util it's okay with me
7592020-12-03T20:01:47 <andytoshi> esp as, in practice, the requirements for a blocksigner are different from the requirements for a generic wallet, so probably signers would want their own sepaarte software anyway. the RPC is mostly just good for testing
7602020-12-03T20:01:48 <MarcoFalke> the private keys could be passed in to the grind command. *hides
7612020-12-03T20:01:58 <wumpus> aj: and yes, it needs to use the same argument handling as our other binaries
7622020-12-03T20:02:04 <sipa> aj: btw, why is the difficulty too high for python? you control the difficulty yourself, no?
7632020-12-03T20:02:07 <luke-jr> separate repo that runs a temporary bitcoind, runs a RPC, and exits? :P
7642020-12-03T20:02:15 <sipa> also have you tried pypy?
7652020-12-03T20:02:25 <sipa> it tends to be several times faster for things like this
7662020-12-03T20:02:39 <wumpus> we definitely don't want to use differnt argument handling between binaries
7672020-12-03T20:02:44 <aj> sipa: min difficulty for signet is higher than original because the retarget calculations don't work right for particularly high targets
7682020-12-03T20:02:52 <sipa> ha
7692020-12-03T20:03:10 <aj> sipa: pypy is faster, but not crazy faster and it makes it more complicated to run
7702020-12-03T20:04:01 <sipa> aj: what is the effective min difficulty?
7712020-12-03T20:04:08 <wumpus> you can load libconsensus using ctypes
7722020-12-03T20:04:12 <wumpus> *ducks*
7732020-12-03T20:04:45 <luke-jr> if libconsensus works, the util should be a separate repo ;)
7742020-12-03T20:05:20 <sipa> libconsensus doesn't do mining; you'd still be calling python->c++ for every individual hash attempt
7752020-12-03T20:05:21 <wumpus> (ctypes works very well I've used it in the past for python bindings)
7762020-12-03T20:05:33 <sipa> pretty sure that's going to be slower than the actual time spent hashing
7772020-12-03T20:05:38 <wumpus> huh yes
7782020-12-03T20:05:45 <MarcoFalke> *libbitcoinkernel
7792020-12-03T20:05:48 <luke-jr> doesn't Python have its own hashing stuff?
7802020-12-03T20:05:57 <aj> doesn't have double sha256
7812020-12-03T20:06:01 <wumpus> yes, python has its own hashing stuff, but appearntly it's too slow
7822020-12-03T20:06:17 <luke-jr> maybe just do it in C then?
7832020-12-03T20:06:25 <luke-jr> libblkmaker has a straightforward example.c
7842020-12-03T20:06:29 <luke-jr> that could be extended
7852020-12-03T20:06:40 <wumpus> yes, loading shared libraries from python is straightforward
7862020-12-03T20:07:32 <wumpus> ok, time to end the meeting I think
7872020-12-03T20:07:40 <wumpus> #endmeeting
7882020-12-03T20:07:40 <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
7892020-12-03T20:07:40 <core-meetingbot> Meeting ended Thu Dec 3 20:07:40 2020 UTC.
7902020-12-03T20:07:40 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-12-03-19.00.moin.txt
7912020-12-03T20:07:57 <jonatack> bitcoin-util SGTM
7922020-12-03T20:08:11 <achow101> re #19740, i've updated the description and added a specific test case
7932020-12-03T20:08:12 <gribble> https://github.com/bitcoin/bitcoin/issues/19740 | [0.20] wallet: Simplify and fix CWallet::SignTransaction by achow101 · Pull Request #19740 · bitcoin/bitcoin · GitHub
7942020-12-03T20:08:14 <aj> so conclusion is stick with -util and fix up marcofalke's arg handling objections?
7952020-12-03T20:08:15 <jonatack> sipa: thanks for the link to the btcd issue
7962020-12-03T20:08:21 <luke-jr> example.c is 135 lines and mines a block from a GBT template
7972020-12-03T20:08:21 <wumpus> even better, shared libraries have less call overhead than a separate process
7982020-12-03T20:08:41 <sipa> aj: seems reasonable to me
7992020-12-03T20:08:51 <aj> luke-jr: there's also the nbits to target and comparison against target stuff that arith_uint256 currently handles
8002020-12-03T20:09:45 <luke-jr> aj: true
8012020-12-03T20:09:53 <aj> wumpus: shared libraries seem like it'd be a super pita to make work for people running mac and windows?
8022020-12-03T20:10:02 <wumpus> aj: why?
8032020-12-03T20:10:11 <wumpus> aj: windows has dlls and mac simply has so's
8042020-12-03T20:10:17 <aj> wumpus: everything seems like a pain for mac and windows? i don't know :)
8052020-12-03T20:10:22 <luke-jr> dunno about mac, but it's even easier on Windows
8062020-12-03T20:10:34 <luke-jr> Windows will prefer a DLL in your working directory ;)
8072020-12-03T20:10:40 <wumpus> windows has a better shared library implementatin than POSIX imo *ducks*
8082020-12-03T20:10:58 <MarcoFalke> #20483 is also tagged for 0.21.0
8092020-12-03T20:11:00 <gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
8102020-12-03T20:11:01 <luke-jr> wumpus: well, Windows has no way out of DLL hell system-wide
8112020-12-03T20:11:11 <MarcoFalke> is 20483 needed?
8122020-12-03T20:12:23 <jonatack> MarcoFalke: for 0.21 I agree with your review, it seems too late as the current plan is to not merge it until estimatefeerate/setfeerate in sat/vB
8132020-12-03T20:12:49 <luke-jr> yeah, too late for 0.21 IMO
8142020-12-03T20:12:57 <jonatack> based on the discussion in luke-jr's estimatesmartfee PR
8152020-12-03T20:13:05 <jonatack> yeah
8162020-12-03T20:13:13 <wumpus> luke-jr: I'm very much exagaratting, what I like about windows is their separation between link libraries (.lib) and the dlls themselves, the versioning stuff is much worse on windows
8172020-12-03T20:14:25 <wumpus> jonatack: ok let's remove it then
8182020-12-03T20:14:33 <MarcoFalke> ok, removed milestone on #20483
8192020-12-03T20:14:35 <gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
8202020-12-03T20:15:30 <wumpus> I think we should only tag regression fixes for 0.21 for now
8212020-12-03T20:16:17 <MarcoFalke> So I guess #19362 will go away too?
8222020-12-03T20:16:19 <gribble> https://github.com/bitcoin/bitcoin/issues/19362 | rpc/blockchain: Reset scantxoutset progress before inferring descriptors by prusnak · Pull Request #19362 · bitcoin/bitcoin · GitHub
8232020-12-03T20:17:48 <wumpus> I guess so, especially as there is still discussion in the PR what way to go
8242020-12-03T20:18:20 <wumpus> it's fine for backport -- for 0.21.1
8252020-12-03T20:19:56 <wumpus> I mean, not everything that could be backported to 0.21 needs to go in between rcs
8262020-12-03T20:21:57 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
8272020-12-03T20:23:42 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
8282020-12-03T20:33:42 *** sunweaver1 <sunweaver1!~sunweaver@185.163.110.125> has quit IRC (Remote host closed the connection)
8292020-12-03T20:35:55 *** davterra <davterra!~davterra@static-198-54-131-92.cust.tzulo.com> has joined #bitcoin-core-dev
8302020-12-03T20:38:36 *** tralfaz <tralfaz!~davterra@static-198-54-131-92.cust.tzulo.com> has quit IRC (Ping timeout: 256 seconds)
8312020-12-03T21:04:50 *** murch <murch!murch@2a01:4f8:141:1272::2> has quit IRC (Read error: Connection reset by peer)
8322020-12-03T21:24:49 *** mdrjr1 <mdrjr1!~mdrjr@178.239.168.171> has joined #bitcoin-core-dev
8332020-12-03T21:33:10 *** Pavlenex <Pavlenex!~Thunderbi@178.220.68.122> has joined #bitcoin-core-dev
8342020-12-03T21:34:11 <vasild> Is there any email post, chat message or anything from btcd or libbitcoin on sendaddrv2? I think is it ok to proceeed with 0.21 as it is now in current master because as mentioned above agreeing on a protocol version is indeed too centralized. What if there are 7 implementations and they never agree?
8352020-12-03T21:34:55 <luke-jr> vasild: uh, as things are now, we have *disagreement*
8362020-12-03T21:35:03 <vasild> The first response by somebody to https://github.com/btcsuite/btcd/issues/1661 is 19 days (!?) after the bug was opened
8372020-12-03T21:35:43 <luke-jr> breaking the network and blaming others is even more centralised
8382020-12-03T21:35:48 <luke-jr> vasild: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018088.html
8392020-12-03T21:36:23 <vasild> luke-jr: thanks, I will read and followup tomorrow
8402020-12-03T21:37:19 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
8412020-12-03T21:41:27 <wumpus> yes, breaking the network would be a bad thing
8422020-12-03T21:43:11 <wumpus> i don't think torv3 support is more important than breaking the network, if push comes to shove they win
8432020-12-03T21:46:31 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
8442020-12-03T21:46:31 <bitcoin-git> [bitcoin] hebasto opened pull request #20563: build: Check that Homebrew's berkeley-db4 package is actually installed (master...201203-bdb) https://github.com/bitcoin/bitcoin/pull/20563
8452020-12-03T21:46:32 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
8462020-12-03T21:47:02 <wumpus> do they have a proposal to support torv3? or is that just not important
8472020-12-03T21:47:13 <luke-jr> wumpus: I think they just want the protocol number bumped
8482020-12-03T21:47:45 <wumpus> I could see how it would be beneficial to some parties to break tor hidden service support
8492020-12-03T21:48:10 <sipa> wumpus: the discussion there isn't about addrv2 at all, but in general (and started by the wtxid discussion)
8502020-12-03T21:48:13 <wumpus> it wouldn't be so much of a hurry if v2 support wasn't deprecated
8512020-12-03T21:49:36 <sipa> and in any case it's a minor thing - it's not like the entire network is suddenly going to run 0.21
8522020-12-03T21:49:40 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has quit IRC (Remote host closed the connection)
8532020-12-03T21:49:53 <wumpus> sipa: so essentailly this means that clients before that version (and implement *all* its features) could never support torv3 relaying
8542020-12-03T21:50:01 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
8552020-12-03T21:50:42 <sipa> wumpus: well the last few years at least all new features have used a combination of protocol version bump that triggers a "sendFEATURE" message
8562020-12-03T21:50:44 <wumpus> which means they can't support tor hidden services at all anymore in short time
8572020-12-03T21:50:46 <wumpus> period
8582020-12-03T21:50:47 <luke-jr> wumpus: from my understanding, libbitcoin's vision is that every new feature bumps the version number *and* negotiates availability
8592020-12-03T21:51:07 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
8602020-12-03T21:51:17 <sipa> wumpus: so really all that a version bump does is "sendaddrv2 and addrv2 now exist" - if they're not negotiated they'll still not be used
8612020-12-03T21:51:24 <wumpus> it was already short while and I'm very disappointed people try to sabotage this
8622020-12-03T21:51:29 <luke-jr> so you could support the latest version number by simply ignoring the negotiation of everything
8632020-12-03T21:51:39 <sipa> wumpus: there are two separate discussions here
8642020-12-03T21:51:45 <wumpus> just send version number 9999999
8652020-12-03T21:51:48 <sipa> wumpus: the libbitcoin one, which was related to wtxid relay
8662020-12-03T21:51:49 <luke-jr> XD
8672020-12-03T21:52:01 <wumpus> deprecate protocol version numbers
8682020-12-03T21:52:07 <sipa> and now the btcd disconnecting when sendaddrv2 is sent
8692020-12-03T21:52:09 <sipa> wumpus: yes, agree
8702020-12-03T21:52:11 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
8712020-12-03T21:52:35 <sipa> i don't think it's constructive to call this sabotage
8722020-12-03T21:52:56 <wumpus> well no one else came up with a solution to this even with so little time left
8732020-12-03T21:53:19 <sipa> what do you mean? there is a solution, it works, it's tested, and it'll be in the next release
8742020-12-03T21:53:26 <luke-jr> ?
8752020-12-03T21:53:49 <wumpus> sipa: if it's up to me, yes
8762020-12-03T21:54:07 <sipa> oh i assumed "solution to this" was about addrv2 itself; not about protocol negotiation
8772020-12-03T21:55:29 <sipa> my suggestion is to just only send sendaddrv2 to clients with protocol version>=70016, as i believe that'll just work with no practical downsides
8782020-12-03T21:55:58 <sipa> and tell btcd people that it's in their own interest to not keep expecting such bumps going forward, as a single version number for negotiation things just doesn't work
8792020-12-03T21:55:58 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 246 seconds)
8802020-12-03T21:56:16 <sipa> i don't know what to do about libbitcoin - it seems we just fundamentally disagree about what the protocol is there
8812020-12-03T21:57:17 <luke-jr> as long as we ensure they can't continue their silliness into BIP324, at least it has an end date?
8822020-12-03T21:58:20 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has quit IRC (Remote host closed the connection)
8832020-12-03T21:58:39 <luke-jr> (we can just add new features only within the context of BIP324)
8842020-12-03T21:59:40 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has joined #bitcoin-core-dev
8852020-12-03T22:01:10 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
8862020-12-03T22:01:13 *** rc_423 <rc_423!~r_423@cpe-75-185-100-189.cinci.res.rr.com> has quit IRC (Read error: Connection reset by peer)
8872020-12-03T22:02:16 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev
8882020-12-03T22:20:40 *** Murch <Murch!murch@2a01:4f8:141:1272::2> has joined #bitcoin-core-dev
8892020-12-03T22:26:12 <wumpus> luke-jr: I just had the idea we could recycle the alert message, it allows arbirary content, right, and as long as the signature doesn't check out old clients won't interpret it as an actual alert
8902020-12-03T22:27:58 <sipa> haha
8912020-12-03T22:39:07 *** Pavlenex <Pavlenex!~Thunderbi@178.220.68.122> has quit IRC (Quit: Pavlenex)
8922020-12-03T22:52:43 *** zndtoshi <zndtoshi!~zndtoshi@79.112.20.148> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
8932020-12-03T22:56:52 <luke-jr> wumpus: O.o
8942020-12-03T22:57:03 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
8952020-12-03T22:57:07 <luke-jr> eh, IMO not worth it
8962020-12-03T22:57:23 <luke-jr> easier to just gratuitously bump the protocol version number for everything
8972020-12-03T22:57:30 <luke-jr> until we switch to BIP324
8982020-12-03T22:59:31 <wumpus> I'm not seriously considering it, but if people want silly I can do silly very well :)
8992020-12-03T23:00:57 <luke-jr> :p
9002020-12-03T23:00:59 <wumpus> it's always possible to find a away to shuttle data over some protocol
9012020-12-03T23:01:13 <wumpus> and impossible to block all such vectors
9022020-12-03T23:03:05 <wumpus> one thing I had never imagined was having to do this for the bitcoin P2P protocol, I mean usually it's about trying to smuggle bitcoin P2P data like blocks and transactions over some other layer
9032020-12-03T23:04:05 <wumpus> but in any case, no, they can't block permissionless extensibility
9042020-12-03T23:04:23 <wumpus> there are sneaky ways to negotiate :p
9052020-12-03T23:06:05 <wumpus> maybe one day we have the entire protocol running over the alert message
9062020-12-03T23:06:13 <sipa> https://github.com/bitcoin/bitcoin/pull/20564
9072020-12-03T23:06:35 <jonatack> curious, the PR didn't appear here
9082020-12-03T23:06:50 <wumpus> weird is the bot broken
9092020-12-03T23:06:51 <sipa> indeed
9102020-12-03T23:10:02 <wumpus> Connecting to chat.freenode.net:6697 with nick bitcoin-git and channels: #bitcoin-commits,#bitcoin-core-dev: There was a problem sending messages to IRC: timed out
9112020-12-03T23:10:56 <wumpus> eh hopefully it's a temporary problem
9122020-12-03T23:12:41 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
9132020-12-03T23:12:41 <bitcoin-git> [bitcoin] laanwj closed pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
9142020-12-03T23:12:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
9152020-12-03T23:13:01 <wumpus> seems so
9162020-12-03T23:13:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
9172020-12-03T23:13:06 <bitcoin-git> [bitcoin] laanwj reopened pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
9182020-12-03T23:13:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
9192020-12-03T23:18:23 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
9202020-12-03T23:22:05 *** yoyo-slays <yoyo-slays!615fc728@097-095-199-040.res.spectrum.com> has joined #bitcoin-core-dev
9212020-12-03T23:22:56 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 256 seconds)
9222020-12-03T23:23:05 *** yoyo-slays <yoyo-slays!615fc728@097-095-199-040.res.spectrum.com> has quit IRC (Remote host closed the connection)
9232020-12-03T23:23:22 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has quit IRC (Ping timeout: 260 seconds)
9242020-12-03T23:25:22 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Read error: Connection reset by peer)
9252020-12-03T23:50:27 *** Victorsueca <Victorsueca!~Victorsue@unaffiliated/victorsueca> has joined #bitcoin-core-dev