12021-07-01T00:21:11 *** belcher_ <belcher_!~belcher@user/belcher> has joined #bitcoin-core-dev
22021-07-01T00:24:18 *** belcher <belcher!~belcher@user/belcher> has quit IRC (Ping timeout: 240 seconds)
32021-07-01T00:25:08 *** roconnor_ <roconnor_!~roconnor@host-45-58-213-173.dyn.295.ca> has joined #bitcoin-core-dev
42021-07-01T00:25:44 *** roconnor <roconnor!~roconnor@host-45-58-197-229.dyn.295.ca> has quit IRC (Ping timeout: 272 seconds)
52021-07-01T00:27:09 *** roconnor_ is now known as roconnor
62021-07-01T00:56:53 *** ratelius <ratelius!ratelius@gateway/vpn/protonvpn/ratelius> has quit IRC (Ping timeout: 250 seconds)
72021-07-01T01:09:41 *** ratelius <ratelius!ratelius@gateway/vpn/protonvpn/ratelius> has joined #bitcoin-core-dev
82021-07-01T01:27:33 *** roconnor <roconnor!~roconnor@host-45-58-213-173.dyn.295.ca> has quit IRC (Ping timeout: 258 seconds)
92021-07-01T01:49:15 *** hex17or <hex17or!~hex17or@gateway/tor-sasl/hex17or> has quit IRC (Ping timeout: 244 seconds)
102021-07-01T01:50:06 *** hex17or <hex17or!~hex17or@gateway/tor-sasl/hex17or> has joined #bitcoin-core-dev
112021-07-01T02:09:33 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
122021-07-01T02:20:38 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
132021-07-01T02:40:25 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Remote host closed the connection)
142021-07-01T02:56:28 *** earnestly <earnestly!~earnest@user/earnestly> has quit IRC (Ping timeout: 272 seconds)
152021-07-01T03:10:55 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
162021-07-01T03:11:36 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 256 seconds)
172021-07-01T03:15:30 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
182021-07-01T03:18:40 *** upekkha is now known as metta
192021-07-01T03:21:09 *** jtrag <jtrag!~jtrag@c-71-207-125-151.hsd1.pa.comcast.net> has quit IRC (Read error: Connection reset by peer)
202021-07-01T03:29:18 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
212021-07-01T03:33:54 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
222021-07-01T03:36:43 *** VzxPLnHqr_ <VzxPLnHqr_!VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr> has joined #bitcoin-core-dev
232021-07-01T03:37:29 *** VzxPLnHqr <VzxPLnHqr!VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr> has quit IRC (Remote host closed the connection)
242021-07-01T03:37:30 *** ironsoba <ironsoba!~z@user/ironsoba> has quit IRC (Ping timeout: 240 seconds)
252021-07-01T04:00:46 *** achow101 <achow101!~achow101@user/achow101> has quit IRC (Quit: Bye)
262021-07-01T04:00:56 *** achow101 <achow101!~achow101@user/achow101> has joined #bitcoin-core-dev
272021-07-01T04:06:23 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
282021-07-01T04:10:42 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
292021-07-01T04:22:09 *** focus <focus!~focus@109-184-162-4.dynamic.mts-nn.ru> has joined #bitcoin-core-dev
302021-07-01T04:38:39 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
312021-07-01T04:42:42 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
322021-07-01T05:13:49 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
332021-07-01T05:18:18 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
342021-07-01T05:33:00 <fanquake> thanks achow101
352021-07-01T05:54:58 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has joined #bitcoin-core-dev
362021-07-01T05:58:24 *** deeepfield <deeepfield!~deepfield@066-190-041-167.res.spectrum.com> has left #bitcoin-core-dev (Leaving)
372021-07-01T06:06:08 <laanwj> why 0.21.1, we should be pretty close to 0.21.2
382021-07-01T06:09:03 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds)
392021-07-01T06:12:39 *** jinkbs89 is now known as jinkbs
402021-07-01T06:16:11 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.236> has joined #bitcoin-core-dev
412021-07-01T06:19:06 <hebasto> pr bot (opening, closing, merging) still keep silence here; whom to ping?
422021-07-01T06:20:05 <_aj_> it was back earlier
432021-07-01T06:20:16 <_aj_> oh, no that was number to url bot
442021-07-01T06:20:44 <_aj_> hebasto: meeting topic it maybe?
452021-07-01T06:29:17 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Ping timeout: 244 seconds)
462021-07-01T06:31:38 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
472021-07-01T06:32:46 *** vasild <vasild!~vd@user/vasild> has quit IRC (Ping timeout: 256 seconds)
482021-07-01T06:38:23 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
492021-07-01T06:39:16 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
502021-07-01T06:42:42 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
512021-07-01T07:03:40 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.236> has quit IRC (Ping timeout: 246 seconds)
522021-07-01T07:11:02 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.188> has joined #bitcoin-core-dev
532021-07-01T07:21:42 *** belcher_ is now known as belcher
542021-07-01T07:24:28 *** goatpig <goatpig!~goat@h-94-254-2-155.A498.priv.bahnhof.se> has quit IRC (Quit: Konversation terminated!)
552021-07-01T07:24:38 <vasild> I am drafting a BIP to resolve the problem with relaying addresses to nodes that just drop them: https://github.com/vasild/bitcoin/wiki/BIP-nounsolicitedaddr, gleb, sdaftuar, amiti
562021-07-01T07:27:30 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
572021-07-01T07:31:09 <vasild> That is related to #17194 and #21528
582021-07-01T07:31:11 <gribble> https://github.com/bitcoin/bitcoin/issues/17194 | p2p: Avoid forwarding ADDR messages to SPV nodes by naumenkogs · Pull Request #17194 · bitcoin/bitcoin · GitHub
592021-07-01T07:31:14 <gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
602021-07-01T07:38:00 *** earnestly <earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
612021-07-01T07:50:20 *** Guest50 <Guest50!~Guest50@120.17.197.217> has joined #bitcoin-core-dev
622021-07-01T07:54:46 *** focus <focus!~focus@109-184-162-4.dynamic.mts-nn.ru> has quit IRC (Ping timeout: 246 seconds)
632021-07-01T07:56:17 *** Guest50 <Guest50!~Guest50@120.17.197.217> has quit IRC (Quit: Client closed)
642021-07-01T08:02:57 *** goatpig <goatpig!~goat@blocksettle-gw.cust.31173.se> has joined #bitcoin-core-dev
652021-07-01T08:39:05 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
662021-07-01T08:42:18 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 240 seconds)
672021-07-01T08:43:06 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
682021-07-01T08:44:27 *** dongcarl[m] <dongcarl[m]!~dongcarlm@2001:470:69fc:105::82> has quit IRC (Quit: node-irc says goodbye)
692021-07-01T08:48:40 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
702021-07-01T08:56:18 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
712021-07-01T08:58:49 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.188> has quit IRC (Ping timeout: 246 seconds)
722021-07-01T09:02:52 *** kexkey_ <kexkey_!~kexkey@198.54.132.118> has joined #bitcoin-core-dev
732021-07-01T09:04:52 *** kexkey <kexkey!~kexkey@198.54.132.118> has quit IRC (Ping timeout: 258 seconds)
742021-07-01T09:23:36 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f03bc00e8dae3d2b501b2e6.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
752021-07-01T10:13:15 *** stevenroose <stevenroose!~steven@2001:19f0:6801:83a:a90a:4c55:7940:b7e2> has quit IRC (Quit: ZNC 1.7.4 - https://znc.in)
762021-07-01T10:13:32 *** stevenroose <stevenroose!~steven@irc.roose.io> has joined #bitcoin-core-dev
772021-07-01T10:14:42 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Quit: Client closed)
782021-07-01T10:14:57 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
792021-07-01T10:23:58 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 256 seconds)
802021-07-01T10:24:22 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
812021-07-01T10:28:00 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Quit: Client closed)
822021-07-01T10:39:52 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
832021-07-01T10:43:54 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 240 seconds)
842021-07-01T10:49:13 <laanwj> hebasto: strange, let's see
852021-07-01T10:51:36 *** smartin <smartin!~Icedove@88.135.18.171> has joined #bitcoin-core-dev
862021-07-01T10:56:25 *** roconnor <roconnor!~roconnor@host-45-78-206-181.dyn.295.ca> has joined #bitcoin-core-dev
872021-07-01T10:57:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
882021-07-01T10:57:33 <bitcoin-git> [bitcoin] fanquake merged pull request #22379: wallet: erase spkmans rather than setting to nullptr (master...fix-spkman-del) https://github.com/bitcoin/bitcoin/pull/22379
892021-07-01T10:57:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
902021-07-01T10:57:40 <laanwj> there it is again
912021-07-01T10:57:56 <hebasto> nice
922021-07-01T10:58:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
932021-07-01T10:58:00 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ef2d400fa42...fa46e489820b
942021-07-01T10:58:00 <bitcoin-git> bitcoin/master b945a31 Andrew Chow: wallet: erase spkmans rather than setting to nullptr
952021-07-01T10:58:00 <bitcoin-git> bitcoin/master fa46e48 fanquake: Merge bitcoin/bitcoin#22379: wallet: erase spkmans rather than setting to ...
962021-07-01T10:58:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
972021-07-01T11:07:02 <laanwj> looks like a bug in the bot: https://github.com/gkrizek/ghi/issues/13 think i'm going to solve it for now by firewalling just github IPs
982021-07-01T11:08:22 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
992021-07-01T11:13:21 *** jinkbs <jinkbs!~jinkbs@240e:3b2:a3f:1820:cd78:5ac8:cdbd:5b0> has quit IRC (Quit: Client closed)
1002021-07-01T11:14:23 *** jinkbs238 <jinkbs238!~jinkbs2@240e:3b2:a3f:1820:cd78:5ac8:cdbd:5b0> has quit IRC (Quit: Client closed)
1012021-07-01T11:17:13 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1022021-07-01T11:19:54 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1032021-07-01T11:19:54 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ef2d400fa42...fa46e489820b
1042021-07-01T11:19:54 <bitcoin-git> bitcoin/master b945a31 Andrew Chow: wallet: erase spkmans rather than setting to nullptr
1052021-07-01T11:19:54 <bitcoin-git> bitcoin/master fa46e48 fanquake: Merge bitcoin/bitcoin#22379: wallet: erase spkmans rather than setting to ...
1062021-07-01T11:19:56 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1072021-07-01T11:20:12 <laanwj> (^^ that was a test, hence the repeated notification)
1082021-07-01T11:23:03 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1092021-07-01T11:23:03 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fa46e489820b...185acdb5e818
1102021-07-01T11:23:03 <bitcoin-git> bitcoin/master 6084d2c S3RK: wallet: do not spam about non-existent spk managers
1112021-07-01T11:23:03 <bitcoin-git> bitcoin/master 185acdb fanquake: Merge bitcoin/bitcoin#22334: wallet: do not spam about non-existent spk ma...
1122021-07-01T11:23:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1132021-07-01T11:26:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1142021-07-01T11:26:33 <bitcoin-git> [bitcoin] fanquake merged pull request #22334: wallet: do not spam about non-existent spk managers (master...stop_non_existing_spkman_spam) https://github.com/bitcoin/bitcoin/pull/22334
1152021-07-01T11:26:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1162021-07-01T11:37:33 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
1172021-07-01T11:48:28 *** jespada <jespada!~jespada@90.254.247.46> has quit IRC (Ping timeout: 272 seconds)
1182021-07-01T11:49:07 *** jespada <jespada!~jespada@90.254.247.46> has joined #bitcoin-core-dev
1192021-07-01T11:55:28 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
1202021-07-01T12:14:40 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has joined #bitcoin-core-dev
1212021-07-01T12:17:54 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1222021-07-01T12:17:54 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/185acdb5e818...2749613020ed
1232021-07-01T12:17:54 <bitcoin-git> bitcoin/master 67669ab Hennadii Stepanov: build: Fix Boost Process compatibility with mingw-w64 compiler
1242021-07-01T12:17:54 <bitcoin-git> bitcoin/master 2749613 fanquake: Merge bitcoin/bitcoin#22348: build: Fix cross build for Windows with Boost...
1252021-07-01T12:17:56 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1262021-07-01T12:18:11 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1272021-07-01T12:18:11 <bitcoin-git> [bitcoin] fanquake merged pull request #22348: build: Fix cross build for Windows with Boost Process (master...210627-boost) https://github.com/bitcoin/bitcoin/pull/22348
1282021-07-01T12:18:12 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1292021-07-01T12:23:30 *** jinkbs <jinkbs!~jinkbs@240e:3b2:a3f:1820:fd1c:d1fa:912a:ce89> has joined #bitcoin-core-dev
1302021-07-01T12:32:24 *** jinkbs <jinkbs!~jinkbs@240e:3b2:a3f:1820:fd1c:d1fa:912a:ce89> has quit IRC (Quit: Client closed)
1312021-07-01T12:35:15 *** neha <neha!~neha@41.213.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
1322021-07-01T12:40:00 *** neha <neha!~neha@41.213.196.104.bc.googleusercontent.com> has quit IRC (Quit: leaving)
1332021-07-01T12:40:18 *** neha <neha!~neha@41.213.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
1342021-07-01T12:46:40 *** neha <neha!~neha@41.213.196.104.bc.googleusercontent.com> has quit IRC (Quit: leaving)
1352021-07-01T12:46:58 *** neha <neha!~neha@41.213.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
1362021-07-01T12:47:40 <fanquake> 3/4 of the way through your Guix build is the wrong time to be trying to remember if you checked out the right branch before startitng
1372021-07-01T13:02:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1382021-07-01T13:02:18 <bitcoin-git> [bitcoin] fanquake opened pull request #22381: guix: Test security-check sanity before performing them (with macOS) (master...20980_macOS_fixups) https://github.com/bitcoin/bitcoin/pull/22381
1392021-07-01T13:02:19 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1402021-07-01T13:03:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1412021-07-01T13:03:37 <bitcoin-git> [bitcoin] fanquake closed pull request #20980: guix: Test security-check sanity before performing them (master...2020-12-guix-mingw-extra-flags) https://github.com/bitcoin/bitcoin/pull/20980
1422021-07-01T13:03:38 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1432021-07-01T13:19:22 *** powerjungle <powerjungle!~powerjung@h081217087223.dyn.cm.kabsi.at> has left #bitcoin-core-dev (see ya around)
1442021-07-01T13:39:25 <laanwj> haha yes
1452021-07-01T13:43:33 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has quit IRC (Ping timeout: 258 seconds)
1462021-07-01T13:46:14 <hebasto> it seems #22381 cannot be fully tested and reviewed before #22365, at least to test the ELF functionality
1472021-07-01T13:46:15 <gribble> https://github.com/bitcoin/bitcoin/issues/22381 | guix: Test security-check sanity before performing them (with macOS) by fanquake · Pull Request #22381 · bitcoin/bitcoin · GitHub
1482021-07-01T13:46:17 <gribble> https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
1492021-07-01T13:47:30 <fanquake> You can always just run the tests manually
1502021-07-01T13:47:41 <hebasto> right
1512021-07-01T13:49:02 <fanquake> The important changes there are for Win and macOS
1522021-07-01T13:49:40 <fanquake> Also, the other changes will mostly be dropped when we move to testing the ELF binaries with LIEF
1532021-07-01T13:50:52 <hebasto> we won't move to LIEF for ELF binaries for 22.0 release, right?
1542021-07-01T13:51:29 <laanwj> i don't think so
1552021-07-01T13:51:40 <fanquake> It's not a requirement, but I could put the changes together tomorrow if you want to see them
1562021-07-01T13:52:01 <fanquake> I wont be around for the meeting, but I assume branch off will discussed, and I think we are in pretty good shape.
1572021-07-01T13:52:04 <laanwj> i'm not sure what would be the advantage of switching that last minute
1582021-07-01T13:52:16 <fanquake> 22365 + 22381 will just about round out the Guix changes. With some docs in #21711.
1592021-07-01T13:52:18 <gribble> https://github.com/bitcoin/bitcoin/issues/21711 | guix: Add full installation and usage documentation by dongcarl · Pull Request #21711 · bitcoin/bitcoin · GitHub
1602021-07-01T13:52:28 <fanquake> I think a Guix only release is the way to go.
1612021-07-01T13:52:44 <laanwj> I think so too
1622021-07-01T13:52:46 <fanquake> There's not much else left in the milestone other than that
1632021-07-01T13:53:17 <laanwj> what about #19438
1642021-07-01T13:53:20 <gribble> https://github.com/bitcoin/bitcoin/issues/19438 | Introduce deploymentstatus by ajtowns · Pull Request #19438 · bitcoin/bitcoin · GitHub
1652021-07-01T13:53:36 <laanwj> in my idea that was holding things up
1662021-07-01T13:54:32 <fanquake> It looks like there could be benefits to getting that in pre branch-off
1672021-07-01T13:55:16 <laanwj> definitely
1682021-07-01T13:58:17 <fanquake> It's not clear to me if #20234 is a requirement, but it has some ACKs, albeit one recent comment re the behaviour change
1692021-07-01T13:58:20 <gribble> https://github.com/bitcoin/bitcoin/issues/20234 | net: dont extra bind for Tor if binds are restricted by vasild · Pull Request #20234 · bitcoin/bitcoin · GitHub
1702021-07-01T14:00:26 <laanwj> i see, if people concept-disagree with it it's better to bump it from the milestone
1712021-07-01T14:00:55 <laanwj> don't think it is critical to make it into 22.0
1722021-07-01T14:02:42 *** roconnor <roconnor!~roconnor@host-45-78-206-181.dyn.295.ca> has quit IRC (Ping timeout: 252 seconds)
1732021-07-01T14:02:50 <fanquake> If anyone thinks anything has been missed they should also make a point to call it out in the meeting
1742021-07-01T14:11:08 <jonatack> a choice should probably made between the I2P options outlined in https://github.com/bitcoin/bitcoin/issues/21389#issuecomment-866925116 (a non-choice would also be a choice, but worth mentioning it)
1752021-07-01T14:14:27 <jonatack> (not to hold up rc1 but before -final)
1762021-07-01T14:15:18 <laanwj> I think I prefer #22112
1772021-07-01T14:15:21 <gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
1782021-07-01T14:16:47 <laanwj> but good point on needing a solution to that
1792021-07-01T14:18:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1802021-07-01T14:18:08 <bitcoin-git> [gui] hebasto opened pull request #377: Translations update (master...210701-tr) https://github.com/bitcoin-core/gui/pull/377
1812021-07-01T14:18:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1822021-07-01T14:18:58 <hebasto> laanwj: ^ I've noted FF is checked in https://github.com/bitcoin/bitcoin/issues/20851 since yesterday
1832021-07-01T14:20:08 <laanwj> hebasto: yes, it doesn't seem any new features have been added to the milestone for some time so I thought it was about time
1842021-07-01T14:23:47 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1852021-07-01T14:23:47 <bitcoin-git> [bitcoin] jlopp opened pull request #22383: prefer to use txindex if available for GetTransaction (master...GetTransactionPerformance) https://github.com/bitcoin/bitcoin/pull/22383
1862021-07-01T14:23:48 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1872021-07-01T14:23:53 <laanwj> bugfixes can still go in, and besides, we're not ready to branch off yet as things are still tagged 22.0 that need to make it in
1882021-07-01T14:28:22 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
1892021-07-01T14:34:13 *** jtrag <jtrag!~jtrag@c-71-207-125-151.hsd1.pa.comcast.net> has joined #bitcoin-core-dev
1902021-07-01T14:37:06 <jonatack> laanwj: yes, vasild and i have been discussing the merits of each offline, 22112 seems best given that SAM 3.2 and up will default ports to 0 and begin portful routing in 3.3 iiuc, but it had some addrman and connection issues to sort out that may have been addressed today. will review again and retest
1912021-07-01T14:37:53 <laanwj> jonatack: thanks, I'll start testing it too
1922021-07-01T14:39:09 <vasild> btw, to be clear - the last commit from 22112 is kind of optional - it is only to convert the addrmans of early users who run un-relased bitcoin core
1932021-07-01T14:40:48 <vasild> as such I think it can/should be reverted eventually at some time in the future, when people have stopped using post-i2p and pre-22112 code
1942021-07-01T14:40:48 <jonatack> the two issues were that (a) I2P addrman entries were removed due to bucket repositioning with the resetting of those entries' ports to 0 (i went from 15 I2P in my addrman to 5) but the new version preserves them and removes the "other" entry instead
1952021-07-01T14:41:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1962021-07-01T14:41:05 <bitcoin-git> [gui] hebasto merged pull request #377: Translations update (master...210701-tr) https://github.com/bitcoin-core/gui/pull/377
1972021-07-01T14:41:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1982021-07-01T14:41:24 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1992021-07-01T14:41:24 <bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2749613020ed...091d35c70e88
2002021-07-01T14:41:24 <bitcoin-git> bitcoin/master c7f74f1 Hennadii Stepanov: Translations update
2012021-07-01T14:41:24 <bitcoin-git> bitcoin/master 091d35c Hennadii Stepanov: Merge bitcoin-core/gui#377: Translations update
2022021-07-01T14:41:26 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2032021-07-01T14:42:09 <jonatack> and (b) we realized that addnode of I2P peers without a port specified would not establish an outbound connection. the latest push intends to fix that as well.
2042021-07-01T14:42:26 <jonatack> so two things to test :)
2052021-07-01T14:58:14 *** goatpig <goatpig!~goat@blocksettle-gw.cust.31173.se> has quit IRC (Quit: Konversation terminated!)
2062021-07-01T15:09:44 <sdaftuar> vasild: thanks for thinking about this addr relay issue. i'm supportive of work towards documenting and coordinating how we want addr relay to work on the network, but i tend to think it's premature to add a new protocol message until we've done a bit more work on how we want addr relay to work for different kinds of network addresses and what kind of propagation model we want to aim for
2072021-07-01T15:11:08 <sdaftuar> with respect to your proposed "no-unsolicited-addrs" message, i think it would likely be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?
2082021-07-01T15:12:25 <sdaftuar> but even now we don't have a good model, or agreed upon set of goals, for how we want addrs to propagate. for instance one question i have is to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all.
2092021-07-01T15:12:48 <sdaftuar> or, what fraction of the network should receive any given announced address, over some time period
2102021-07-01T15:13:07 <vasild> hmm
2112021-07-01T15:13:12 <jonatack> interesting questions
2122021-07-01T15:13:30 <sdaftuar> those kinds of questions make it hard in my mind to ask the network to adopt an addr relay protocol right now. if we're going to ask software to coordinate on this area, we should first have an idea of what we're aiming for
2132021-07-01T15:14:06 <vasild> I agree
2142021-07-01T15:14:55 <vasild> "be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?" -- do you mean unsolicited or regardless?
2152021-07-01T15:15:54 <sdaftuar> could be either; i could imagine that we need to negotiate behavior both around getaddr/getaddr-responses as well as unsolicited relay
2162021-07-01T15:16:03 <jonatack> it does seems that adding networks has introduced changes, effects and interactions that we're probably still mostly on the cusp of
2172021-07-01T15:16:36 <jonatack> and addr relay was already fertile ground for more research
2182021-07-01T15:17:21 <vasild> So would a message like the following deprecate "no-unsolicited-addrs": "I want only ipv6,tor addresses as a response to getaddr and/or unsolicited"...
2192021-07-01T15:18:35 <earnestly> (Can solicitation divulge information in such a way that is useful for attacking anonimity?)
2202021-07-01T15:18:56 <vasild> I don't think the latter supersedes "no-unsolicited-addrs". solicited-or-not is one thing, the type of addresses is another, no?
2212021-07-01T15:19:38 <sdaftuar> vasild: i could imagine that we'd provide some kind of score for how we treat relay of different address types, akin to how we currently have different relay policies for networks we understand and networks we don't
2222021-07-01T15:19:53 <sdaftuar> it's possible it own't evolve that way of course, i just htink we don't know yet
2232021-07-01T15:21:59 *** Guyver2_ <Guyver2_!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
2242021-07-01T15:23:50 <vasild> earnestly: I think, in theory mostly, one can observe that a given ipv4 node relays readily i2p addresses but does not relay tor addresses. So one may be able to deduct that that node has i2p connectivity and not tor connectivity...
2252021-07-01T15:24:18 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Ping timeout: 256 seconds)
2262021-07-01T15:24:19 *** Guyver2_ is now known as Guyver2
2272021-07-01T15:24:25 <vasild> s/does not relay tor addresses/relays tor addresses less readily/
2282021-07-01T15:26:17 <vasild> earnestly: even if I can tell your ipv4 node has i2p connectivity and does not have tor connectivity, what harm could I do?
2292021-07-01T15:26:18 <earnestly> vasild: It only came to mind due to that old paper about vulnerabilities in using tor with that autoban system
2302021-07-01T15:27:08 <vasild> I have not read that one
2312021-07-01T15:27:45 <vasild> it is cheap to generate tor addresses, I guess if one gets banned he can create a new address easily and persist misbehaving
2322021-07-01T15:28:09 <earnestly> vasild: https://arxiv.org/abs/1410.6079 (2015)
2332021-07-01T15:30:25 <vasild> "A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor" :-O
2342021-07-01T15:35:08 <vasild> sdaftuar: "to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all" -- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki contains this sentence: "Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and
2352021-07-01T15:35:14 <vasild> make it more difficult for an observer to tell which networks a node is connected to.", I think that makes sense.
2362021-07-01T15:38:52 <vasild> sdaftuar: "what fraction of the network should receive any given announced address, over some time period" -- some simulations are at https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-865658016, I guess a good starting point for that.
2372021-07-01T15:43:37 <vasild> Do we want as many as possible nodes to receive an announced address as soon as possible? (if we could do that without causing flood/excessive traffic)
2382021-07-01T15:58:59 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f03bc00e8dae3d2b501b2e6.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
2392021-07-01T16:37:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2402021-07-01T16:37:36 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/091d35c70e88...a926d6dfd291
2412021-07-01T16:37:36 <bitcoin-git> bitcoin/master c4ddee6 Antoine Riard: test: Add test for replacement relay fee check
2422021-07-01T16:37:36 <bitcoin-git> bitcoin/master a926d6d MarcoFalke: Merge bitcoin/bitcoin#22310: test: Add functional test for replacement rel...
2432021-07-01T16:37:38 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2442021-07-01T16:37:52 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2452021-07-01T16:37:52 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #22310: test: Add functional test for replacement relay fee check (master...2021-06-add-rbf5-test) https://github.com/bitcoin/bitcoin/pull/22310
2462021-07-01T16:37:53 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2472021-07-01T16:42:36 *** lightlike <lightlike!~lightlike@user/lightlike> has joined #bitcoin-core-dev
2482021-07-01T16:58:56 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 256 seconds)
2492021-07-01T17:03:27 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
2502021-07-01T17:13:28 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has joined #bitcoin-core-dev
2512021-07-01T17:16:35 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2522021-07-01T17:16:35 <bitcoin-git> [bitcoin] MarcoFalke pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/a926d6dfd291...ddc6979b8baa
2532021-07-01T17:16:35 <bitcoin-git> bitcoin/master 36a4ba0 Anthony Towns: versionbits: correct doxygen comments
2542021-07-01T17:16:35 <bitcoin-git> bitcoin/master eccd736 Anthony Towns: versionbits: Use dedicated lock instead of cs_main
2552021-07-01T17:16:35 <bitcoin-git> bitcoin/master 2b0d291 Anthony Towns: [refactor] Add deploymentstatus.h
2562021-07-01T17:16:37 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2572021-07-01T17:16:52 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2582021-07-01T17:16:52 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19438: Introduce deploymentstatus (master...202007-deployment-refactor) https://github.com/bitcoin/bitcoin/pull/19438
2592021-07-01T17:16:53 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2602021-07-01T17:19:37 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
2612021-07-01T17:33:07 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.196> has joined #bitcoin-core-dev
2622021-07-01T18:01:26 <hebasto> meeting?
2632021-07-01T18:01:56 <hebasto> or missed an hour
2642021-07-01T18:02:30 <laanwj> date -u shows there's still an hour to go
2652021-07-01T18:02:40 <sipa> indeed
2662021-07-01T18:02:43 <hebasto> yeap
2672021-07-01T18:09:01 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2682021-07-01T18:09:02 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #22385: refactor: Use DeploymentEnabled to hide VB deployments (master...2107-dep) https://github.com/bitcoin/bitcoin/pull/22385
2692021-07-01T18:09:03 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2702021-07-01T18:39:44 *** kabaum <kabaum!~kabaum@ua-84-216-129-44.bbcust.telenor.se> has quit IRC (Ping timeout: 265 seconds)
2712021-07-01T18:39:54 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 240 seconds)
2722021-07-01T18:40:31 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
2732021-07-01T18:48:41 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
2742021-07-01T18:53:24 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds)
2752021-07-01T19:00:11 <laanwj> #startmeeting
2762021-07-01T19:00:12 <core-meetingbot> Meeting started Thu Jul 1 19:00:11 2021 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
2772021-07-01T19:00:12 <core-meetingbot> Available commands: action commands idea info link nick
2782021-07-01T19:00:35 <hebasto> hi
2792021-07-01T19:00:45 <laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
2802021-07-01T19:00:46 <laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
2812021-07-01T19:00:54 <jarolrod> hi
2822021-07-01T19:01:08 <ajonas> Hi
2832021-07-01T19:01:19 <ariard> hi
2842021-07-01T19:01:20 <meshcollider> Hi
2852021-07-01T19:01:23 <michaelfolkson> hi
2862021-07-01T19:01:23 <jonatack> hi
2872021-07-01T19:01:28 <gleb> hi
2882021-07-01T19:01:29 <luke-jr> #proposedmeetingtopic When it's okay to auto-update across softfork enforcement
2892021-07-01T19:01:35 <neha> hi
2902021-07-01T19:01:47 <lightlike> hi
2912021-07-01T19:01:49 <laanwj> welcome to the weekly meeting; there have been no proposed meeting topics for this week, any last minute ones?
2922021-07-01T19:02:05 <neha> #proposedmeetingtopic Training to rotate release responsibility
2932021-07-01T19:02:26 <luke-jr> laanwj: see ^
2942021-07-01T19:02:40 <luke-jr> err, ^ ^ too ;)
2952021-07-01T19:02:57 <laanwj> yes!
2962021-07-01T19:03:03 <laanwj> #topic 22.0 release
2972021-07-01T19:03:03 <core-meetingbot> topic: 22.0 release
2982021-07-01T19:03:22 <achow101> hi
2992021-07-01T19:03:46 <laanwj> we're getting pretty close to the 22.0 branch-off point, but some PRs are still open https://github.com/bitcoin/bitcoin/milestone/47
3002021-07-01T19:04:41 <laanwj> most have to do with the build system and guix, but there's also #22122 which is P2P related
3012021-07-01T19:04:43 <gribble> https://github.com/bitcoin/bitcoin/issues/22122 | ci: Bump macOS image to big-sur-xcode-12.5 by MarcoFalke · Pull Request #22122 · bitcoin/bitcoin · GitHub
3022021-07-01T19:04:57 <laanwj> wait no not that one #22112
3032021-07-01T19:04:59 <gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
3042021-07-01T19:05:32 <laanwj> i'm thinking of removing #20234 from the milestone because there is some concept discussion/disagreement, it's a bit too late in the cycle for that and it's not critical to have in 22.0
3052021-07-01T19:05:35 <gribble> https://github.com/bitcoin/bitcoin/issues/20234 | net: dont extra bind for Tor if binds are restricted by vasild · Pull Request #20234 · bitcoin/bitcoin · GitHub
3062021-07-01T19:05:42 <achow101> should the guix stuff be kept? they're both still drafts
3072021-07-01T19:05:54 <laanwj> the guix stuff is needed to do a release
3082021-07-01T19:06:02 <laanwj> not sure why they're draft labeled
3092021-07-01T19:06:42 <jonasschnelli> hi
3102021-07-01T19:06:44 <jarolrod> ^ pinging dongcarl
3112021-07-01T19:06:48 <luke-jr> unless we just use gitian again
3122021-07-01T19:06:55 <achow101> #21711 is just docs and some error checking, so I don't think it is necessary
3132021-07-01T19:06:58 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
3142021-07-01T19:06:58 <gribble> https://github.com/bitcoin/bitcoin/issues/21711 | guix: Add full installation and usage documentation by dongcarl · Pull Request #21711 · bitcoin/bitcoin · GitHub
3152021-07-01T19:07:16 <laanwj> docs are very important because a lot of people are going to do guix builds for the first time
3162021-07-01T19:08:02 <hebasto> luke-jr: #22365 and guix, or multiple glibc symbol compatibility fixups and gitian
3172021-07-01T19:08:05 <gribble> https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
3182021-07-01T19:08:10 <laanwj> luke-jr: if there is a problem with the guix build we can always fall back to gitian, but it is unlikely
3192021-07-01T19:09:16 <luke-jr> hebasto: gitian should be fixed even if we use guix
3202021-07-01T19:09:19 <laanwj> it might be possible that bugfixes are still added for the 22.0 milestone but the feature freeze is active now
3212021-07-01T19:09:33 <dongcarl> Hi
3222021-07-01T19:09:54 <dongcarl> Iâm working on the docs right now, updating for Guix 1.3.0
3232021-07-01T19:10:15 <dongcarl> Are we talking about fixing the gitian build for the symbol problem?
3242021-07-01T19:10:20 <laanwj> (and so is the translation string freeze, we've done the last update of the source translations pre-rc a few hours ago)
3252021-07-01T19:10:47 <laanwj> dongcarl: achow101 just noted that your PRs on the 22.0 milestone are labeled as draft, which is somewhat confusing
3262021-07-01T19:11:42 <dongcarl> Yes I intend on adding more commentary to those PRs so thatâs why they are still Draft
3272021-07-01T19:11:56 <dongcarl> Can mark as ready if people want, no strong opinions
3282021-07-01T19:12:11 <laanwj> it's fine imo
3292021-07-01T19:12:36 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 265 seconds)
3302021-07-01T19:13:03 <dongcarl> Happy to answer any more questions :-)
3312021-07-01T19:13:19 <laanwj> #topic
3322021-07-01T19:13:19 <core-meetingbot> topic:
3332021-07-01T19:13:26 <laanwj> #topic When it's okay to auto-update across softfork enforcement (luke-jr)
3342021-07-01T19:13:27 <core-meetingbot> topic: When it's okay to auto-update across softfork enforcement (luke-jr)
3352021-07-01T19:14:10 <luke-jr> We obviously don't have any auto-updates in Core, but some things exist (Snap, PPAs, Gentoo pkg) which do allow for users to auto-upgrade
3362021-07-01T19:14:44 <luke-jr> Softforks should be consensual, but when does it move on to the point where it's just assumed users want it?
3372021-07-01T19:15:26 <luke-jr> any thoughts?
3382021-07-01T19:15:42 <achow101> presumably after lock in?
3392021-07-01T19:15:46 <luke-jr> (my Core PPA is still at 0.21.0 pending some solution)
3402021-07-01T19:15:55 <luke-jr> achow101: but lock-in is just miners, not the community
3412021-07-01T19:16:05 <ariard> well we have buried deployment which are quite making assumptions on users w.r.t to softfork activation
3422021-07-01T19:16:12 <ariard> bip90
3432021-07-01T19:16:14 <luke-jr> do we then assume any opposed users would have forked off at this point?
3442021-07-01T19:16:31 <luke-jr> ariard: but those are already active, which I think is a very clear safe time to do it
3452021-07-01T19:16:49 <sipa> is it possible in snap etc to have a different channel or package name per release?
3462021-07-01T19:16:51 <luke-jr> once activation, IMO it's pretty clearly fine
3472021-07-01T19:17:25 <luke-jr> sipa: not sure about Snaps, but for the PPA, it seems to be possible to prompt the user to explicitly agree
3482021-07-01T19:17:58 <luke-jr> there's some packages that added an EULA for a version bump prompting the user on upgrade, and that seems similar logically
3492021-07-01T19:18:21 <luke-jr> Gentoo packages have USE flags, and can be set to not install until one is set by the user
3502021-07-01T19:18:28 <ariard> luke-jr: i might miss context there, but my reasoning by pointing to buried deployment is when we hardcode activation height we restrain user choice of opposing softforks
3512021-07-01T19:18:32 <luke-jr> (which is what 0.21.1 is doing right now on the Gentoo overlay)
3522021-07-01T19:19:00 <sipa> ariard: we can't wait for buried deployment here
3532021-07-01T19:19:03 <luke-jr> ariard: by the time of activation, users need to either enforce, or reject the chain it activated on; the latter requires code changes regardless
3542021-07-01T19:19:15 <sipa> ariard: we can't wait to release 0.21.1 packages until taproot is active, e.g.
3552021-07-01T19:19:26 <sipa> (+ probably a few years)
3562021-07-01T19:19:54 <luke-jr> yeah, simply not having packages is a problem too because most users *will* want to upgrade
3572021-07-01T19:20:02 <luke-jr> doing so should be easy
3582021-07-01T19:20:08 <sipa> and i don't think opposition is the right criterion here; nothing is being forced
3592021-07-01T19:20:17 <sipa> the question is about unaware upgrading
3602021-07-01T19:20:32 <ariard> luke-jr: gotcha it's regard with increasing the number of users with softfork enforcement logic at time of taproot activation?
3612021-07-01T19:20:37 <sipa> if people were aware of a softfork they'd active oppose, they'd stop using the snap/ppa/whatever
3622021-07-01T19:21:05 <sipa> ariard: no, it's just that people shouldn't be opted into enforcing softfork rules without being aware of it
3632021-07-01T19:21:06 <luke-jr> ariard: softforks without user enforcement are effectively failed softforks
3642021-07-01T19:22:15 <sipa> ariard: the concern is simply that whomever has the PPA/snap/... admin powers could push new consensus rule enforcement onto the network, without the node operators being aware
3652021-07-01T19:22:29 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
3662021-07-01T19:22:37 <sipa> this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
3672021-07-01T19:22:57 <sipa> but this is obviously bypassed by using distro-packaged versions that do automatically update
3682021-07-01T19:23:09 <luke-jr> obviously not-pushing a good change doesn't stop someone from pushing a bad one, but there's an ethical and liability side as well
3692021-07-01T19:23:12 <ariard> sipa: okay so it's about making showy the upgrade of PPA/snap/... etc in case of node operators disapprove the new consensus rules and want to switch vendors ?
3702021-07-01T19:23:25 <sipa> ariard: i don't know what the solution is
3712021-07-01T19:23:28 <luke-jr> ariard: the node owner should be the one to make the decision
3722021-07-01T19:23:41 <ariard> luke-jr: fully agree on this!
3732021-07-01T19:24:01 <ariard> but a lot of folks might just fetch package without reading release notes
3742021-07-01T19:24:13 <sipa> that's inevitable
3752021-07-01T19:24:29 <ariard> i think so too
3762021-07-01T19:24:36 <luke-jr> ariard: bitcoincore.org's blog post has the title specific to Taproot too for example
3772021-07-01T19:24:59 <laanwj> yes the thing with linux distributions is that the user will get the update together with tons of other package updates, they might not even notice it
3782021-07-01T19:25:14 <luke-jr> I *can* make the PPA and Gentoo stuff force user consent explicitly; the question is when it's okay to omit that ;)
3792021-07-01T19:25:27 <luke-jr> (MarcoFalke would have to comment on his snap stuff)
3802021-07-01T19:25:43 <laanwj> being at the least able to show release notes would be nice, freebsd has this for significant changes, but dunno about linux distros, never saw it in debian afaik
3812021-07-01T19:26:55 <ariard> luke-jr: imho, i would say it's more a PPA/gentoo/snap admin policy there, hard to all agree on this?
3822021-07-01T19:27:06 <harding> debian has an opt-in setting for major release note stuff.
3832021-07-01T19:27:29 <laanwj> (and for people doing background automatic updates that wouldn't work anyway)
3842021-07-01T19:27:32 <laanwj> harding: oh good to know
3852021-07-01T19:28:05 <sipa> in a way this is a strange discussion, because i think we're effectively worrying about a rogue distribution maintainer
3862021-07-01T19:28:17 <harding> For people with background updates, debian will main those notices to you, but only if you're like the 0.01% of people who still setup a MTA.
3872021-07-01T19:28:19 <sipa> but if that's the case, they would obviously patch out whatever warning exists
3882021-07-01T19:28:24 <harding> s/main/mail/
3892021-07-01T19:28:59 <luke-jr> sipa: not necessarily rogue
3902021-07-01T19:29:09 <sipa> and taking this to its logical conclusion, i think it's just that centrally-controlled package repositories are a risk... which isn't surprising
3912021-07-01T19:29:18 <luke-jr> sipa: this is a real-world issue for me right now, I need to bump the Core PPA at some point before November
3922021-07-01T19:29:41 <laanwj> right, it's for good reason we resisted bitcoin being part of package repositories for a long time
3932021-07-01T19:30:03 <laanwj> it's extremly unsuited to automatic updates
3942021-07-01T19:30:19 <sipa> luke-jr: right, i agree this should happen for information purposes, but the real reason why you'd want to show that warning is so that users know "be aware, the package maintainer is including a consensus change in this release, which you're automatically getting - if you don't want that, move away"
3952021-07-01T19:30:32 <sipa> luke-jr: and clearly, we're of the opinion that this consensus change is going to happen
3962021-07-01T19:30:52 <sipa> so what is the warning protecting against? if this information was intentionally false, you'd also remove the warning...
3972021-07-01T19:31:11 <luke-jr> because even honest package maintainers shouldn't make the call for users ;)
3982021-07-01T19:31:28 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Remote host closed the connection)
3992021-07-01T19:32:10 <ariard> sipa: well you might be a really rogue distribution maintainer and luring the user that softfork A' shipped in the package is software A that user heard activated in the public space...
4002021-07-01T19:32:16 <sipa> i'm not sure. by installing through a package manager, users have delegated most of their power in having control over what they run already, regardless of consensus changes even
4012021-07-01T19:32:24 <sipa> that's a concern on itself
4022021-07-01T19:32:28 <ariard> s/software/softfork/g
4032021-07-01T19:32:30 <sipa> but i don't know what to do about it
4042021-07-01T19:33:12 <ariard> empower and educate users to have more of them building from the sources
4052021-07-01T19:33:23 <sipa> yeah
4062021-07-01T19:33:25 <sipa> also, good luck
4072021-07-01T19:33:28 <earnestly> (Casestudy: debian would miscompile mpv against ffmpeg, mpv added warnings to avoid bug reports, debian patched the warning out rendering mpv's attempts ineffectual.)
4082021-07-01T19:33:31 <laanwj> manually downloading binaries is fine too
4092021-07-01T19:33:33 <jonatack> or download the binaries
4102021-07-01T19:33:44 <harding> Some packages in debian come shipped in a not-completely-functional state; you have to flip some flag in /etc/defaults/package-name. You can have Bitcoin Core 0.21.1+ require you put "taproot = yes" in that file before it'll run.
4112021-07-01T19:34:14 <laanwj> just not anything that auto updates, it's also arisk if you're actually using bitcoind for anything; e.g. some software might not work with the new release yet, though that's mostly for major releases that deprecate or change RPC functionality
4122021-07-01T19:34:24 <earnestly> You really have to leave these decisions to downstream
4132021-07-01T19:34:25 <harding> (The debconf configuration wizard can prompt you to do that.)
4142021-07-01T19:34:34 <earnestly> (I.e. not worry)
4152021-07-01T19:34:38 <luke-jr> harding: but then we're patching the code
4162021-07-01T19:34:43 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
4172021-07-01T19:35:01 <luke-jr> maybe we should add a softforks=<list> upstream for future stuff like that
4182021-07-01T19:35:29 <luke-jr> earnestly: there is no downstream
4192021-07-01T19:35:30 <earnestly> That would be the best option, probably
4202021-07-01T19:35:43 <earnestly> downstream here is defined as package maintainers
4212021-07-01T19:36:03 <harding> luke-jr: eh, I guess. Maybe then you could rename /usr/bin/bitcoind to /usr/bin/bitcoind-taproot and then use the symlink alternatives mechanism to manage /usr/bin/bitcoind. That way users have to opt in to the "bitcoind-taproot" alternative.
4222021-07-01T19:36:07 <luke-jr> earnestly: ie, me
4232021-07-01T19:36:10 <sipa> and just have it not run if the flag isn't present? you'll risk maintainers patching it out, because it's too much of an annoyance to users
4242021-07-01T19:36:29 <luke-jr> harding: won't it auto-switch?
4252021-07-01T19:36:31 <sipa> and i think this also isn't the core of the issue
4262021-07-01T19:36:32 <earnestly> luke-jr: That there is an overlap between upstream and downstream doesn't change the distinction
4272021-07-01T19:36:40 <laanwj> yes , getting the update but ending up with a non-working binary that's pretty awful for users
4282021-07-01T19:36:51 <earnestly> What you do for the distribution is related to upstream but not identical
4292021-07-01T19:36:57 <luke-jr> sipa: right; we can't stop people from patchign things out, but this provides a good solution otherwise
4302021-07-01T19:37:04 <sipa> i'm not sure
4312021-07-01T19:37:09 <harding> luke-jr: I'm pretty sure you can control auto-switching via the package install scripts, but my Debian packaging knowledge is like 15 years out of date.
4322021-07-01T19:37:11 <luke-jr> laanwj: GUI can prompt too?
4332021-07-01T19:37:23 <luke-jr> harding: even when the prior value is being removed? :p
4342021-07-01T19:38:01 <earnestly> sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
4352021-07-01T19:38:03 <harding> luke-jr: yeah, the different symlinks have priorities and you can set like -1 or something for never-auto-select.
4362021-07-01T19:39:18 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds)
4372021-07-01T19:39:26 <harding> luke-jr: also you could make the default /usr/bin/bitcoind a shell script that prompts you to opt-in to taproot.
4382021-07-01T19:39:46 <harding> (Or whatever thing you as maintainer thinks needs opting in.)
4392021-07-01T19:39:52 <luke-jr> anyway, there are multiple solutions; my question was mainly when we no longer should take extra steps like these
4402021-07-01T19:40:23 <laanwj> harding: for user-facing tools that's fine, but that would go wrong if it's started from an (init) script
4412021-07-01T19:40:34 <laanwj> you can usually assume bitcoind is used as part of some stack
4422021-07-01T19:40:50 <harding> IMO, three months after we've honestly done our best to announce the change is enough time for people who want to know to learn about it.
4432021-07-01T19:41:06 <sipa> i think the message really isn't so much "warning, this has taproot, do you like that?", but it is "warning: the package maintainer you trust has power to make your system update to new consensus rules, you should be aware of that risk, and evaluate whether that's an acceptable way to use bitcoin"
4442021-07-01T19:41:09 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
4452021-07-01T19:41:29 <earnestly> They can just remove that, there's no point playing this game
4462021-07-01T19:41:35 <sipa> it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
4472021-07-01T19:41:45 <sipa> but that's just the normal release notes/process
4482021-07-01T19:42:07 <harding> laanwj: I think it would only go bad in the sense of the software not starting, and as long as it prints an informative error to the log, that's not too bad? If you're in a configuration where you're making major-version upgrades in an automated fashion, you have to be prepared for breakage no matter what (IMO).
4492021-07-01T19:42:25 <earnestly> (I do like luke-jr's idea of having a softfork= option though, future?)
4502021-07-01T19:43:10 <ariard> harding: if by "announce the change" you mean publicity around softfork locks in, 3 months sounds reasonable to me
4512021-07-01T19:43:17 <luke-jr> the solutions I have right now just don't perform the update until the user explicitly agrees
4522021-07-01T19:43:41 <laanwj> harding: this is not a major version update (0.21.0 to 0.21.1) ... but i agree all of this is manouvring around auto-updates just being a bad idea for bitcoin in the first place, and people who use it through a package manager sign up for that
4532021-07-01T19:43:50 <harding> ariard: I was thinking 3 months from the BitcoinCore.org release announcement.
4542021-07-01T19:44:58 <luke-jr> but people might never see that :/
4552021-07-01T19:45:13 <laanwj> we might want ot leave some time for the last topic
4562021-07-01T19:45:42 <harding> luke-jr: yeah, it's not a perfect world, and I don't think we can fix that and still allow people to use the PPA.
4572021-07-01T19:46:18 <luke-jr> maybe I'll just leave the extra step installing in place until November
4582021-07-01T19:47:47 <luke-jr> laanwj: I think the topic is done
4592021-07-01T19:48:09 <laanwj> #topic Training to rotate release responsibility (neha)
4602021-07-01T19:48:10 <core-meetingbot> topic: Training to rotate release responsibility (neha)
4612021-07-01T19:48:49 <neha> it would be good to train others to do releases. what do people think about laanwj mentoring people and eventually getting on a rotating schedule?
4622021-07-01T19:49:30 <michaelfolkson> What are the responsibilities? Are there any that we wouldn't want to rotate?
4632021-07-01T19:49:39 <laanwj> i think the best idea would be to have doc/release-process.md up to date so everything is in there, i've added some things already
4642021-07-01T19:49:45 <neha> it could initially circulate among maintainers, for example. though it's not necessary to figure out a long-term plan right now. one short-term idea is for someone else to do the next minor release under laanwj's supervision
4652021-07-01T19:49:55 <laanwj> but of course the best way to find out is to have someone else go through it
4662021-07-01T19:49:56 <luke-jr> neha: it's not too hard tbh
4672021-07-01T19:50:01 <luke-jr> we have good docs
4682021-07-01T19:50:10 <neha> fanquake has already volunteered, i believe
4692021-07-01T19:50:18 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 252 seconds)
4702021-07-01T19:50:35 <laanwj> yes, unfortunately he's couldn't be at this meeting
4712021-07-01T19:50:38 <amiti> I think it's a great idea!
4722021-07-01T19:51:01 <michaelfolkson> Any downsides? Presumably it would only rotate around maintainers?
4732021-07-01T19:51:12 <achow101> wouldn't this require giving more people write access and upload access to bitcoincore.org?
4742021-07-01T19:51:36 <jonatack> ^ i would have thought that was a maintainer role (more or less by definition)
4752021-07-01T19:51:38 <laanwj> probably makes sense to do it for a minor release first, 22.0 is going to be different in some ways so it will take some extra attention (also updating the release process where needed)
4762021-07-01T19:52:08 <sipa> laanwj: agree, but also feel free to ask if you see places where help is useful
4772021-07-01T19:52:12 <luke-jr> there's going to be one more 0.20.x before 22.0, right?
4782021-07-01T19:52:21 <achow101> we could trial with 0.20.2
4792021-07-01T19:52:23 <laanwj> achow101: sure, or they could do everything except the upload
4802021-07-01T19:52:52 <ariard> maybe we could have more distribution mirrors instead of one big official one like bitcoincore.org
4812021-07-01T19:53:02 <luke-jr> michaelfolkson: NACK treating maintainers special
4822021-07-01T19:53:04 <laanwj> there was another idea for the longer run to have bitcoincore.org build the binaries itself (it's deterministic after all)
4832021-07-01T19:53:42 <luke-jr> laanwj: not sure we gain anything from that?
4842021-07-01T19:53:44 <laanwj> then the maintainer would only have to do a tag, and trigger it, i guess
4852021-07-01T19:53:51 <laanwj> luke-jr: no one needs to upload binaries
4862021-07-01T19:53:52 <sipa> laanwj: that's cool, but it's also a really infrequent thing; making sure that keeps working may be more work than doing it manually...
4872021-07-01T19:54:02 <harding> The deterministic build idea is already how we handle the website content basically, so it's not too strange.
4882021-07-01T19:54:09 <achow101> laanwj: still have upload sha256sums
4892021-07-01T19:54:13 <laanwj> seems beter than giving multiple people write aceess to the /bin
4902021-07-01T19:54:18 <achow101> *signed sha256sums
4912021-07-01T19:54:27 <laanwj> achow101: depends on how we're going to do the signing
4922021-07-01T19:54:32 <luke-jr> laanwj: just check that uploads have N signers
4932021-07-01T19:54:46 <luke-jr> we would want that even if it built itself
4942021-07-01T19:54:55 <laanwj> achow101: but yeah, having that happen on the website is a bad idea :)
4952021-07-01T19:55:11 <harding> If N people sign the torrent hash, then the website could download that directly.
4962021-07-01T19:55:12 <neha> to separate the next minor release question from a longer-term strategy: it sounds like there is no immediate objection to fanquake doing the next minor release? when is 0.20.2?
4972021-07-01T19:55:24 <laanwj> in any case the uploading is the least interesting part
4982021-07-01T19:55:50 <laanwj> the rest of the release process is where more work is
4992021-07-01T19:55:54 <laanwj> neha: sgtm
5002021-07-01T19:55:57 <luke-jr> neha: it won't make sense to do it once we get to November
5012021-07-01T19:56:03 <luke-jr> since it doesn't have Taproot
5022021-07-01T19:56:14 <achow101> 0.20.2 is ready to go except for release notes
5032021-07-01T19:56:26 <luke-jr> and rc cycle
5042021-07-01T19:56:34 <laanwj> yes
5052021-07-01T19:56:36 <sdaftuar> practical thing that people will have to figure out is what key they are checking a signature from when they download the binary/sha256sums. would that be fanquake's in this scenario?
5062021-07-01T19:57:04 <luke-jr> sdaftuar: we really should be moving to a setup where many of us sign those
5072021-07-01T19:57:06 <michaelfolkson> It appears to work well for c-lightning but smaller project, smaller number of contributors and seems to rotate around the three major contributors mostly.
5082021-07-01T19:57:09 <achow101> luke-jr: we already have 0.20.2rc2 since early june
5092021-07-01T19:57:10 <sdaftuar> luke-jr: sure, but i assume we're not there yet?
5102021-07-01T19:57:11 <neha> sdaftuar: i think part of the goal is to achieve fault tolerance, so ideally yes
5112021-07-01T19:57:15 <jonatack> looking at https://github.com/bitcoin/bitcoin/commits/master/doc/release-process.md to see who has been interested in the process, there are a few non-maintainers who have been interested, as well as the maintainers, generally
5122021-07-01T19:57:17 <luke-jr> achow101: has anyone tested it?
5132021-07-01T19:57:22 <laanwj> sdaftuar: it should be multi-signed i think
5142021-07-01T19:57:25 <luke-jr> sdaftuar: it's just a matter of doing it
5152021-07-01T19:57:38 <laanwj> sdaftuar: i think that's dongcarl's thing too, the same sha256sum is signed by every builder
5162021-07-01T19:57:47 <laanwj> so the signatures can be concatenated
5172021-07-01T19:57:52 <luke-jr> someone just has to copy/paste others' signatures into the file
5182021-07-01T19:57:53 <achow101> luke-jr: probably not, but I expect that's normal for minor releases for old versions
5192021-07-01T19:58:11 <sdaftuar> laanwj: ah ok. just want to make sure we think to do whatever communication to the community is required for the change
5202021-07-01T19:58:29 <sipa> i think there is a conflation here
5212021-07-01T19:58:32 <luke-jr> so long as laanwj's signature is included, I expect it will be smooth
5222021-07-01T19:58:49 <laanwj> well i can do the signing and upload for 0.20.2 no problem
5232021-07-01T19:58:52 <sipa> guix attestations only prove that a particular source code corresponds to a certain binary
5242021-07-01T19:59:12 <sipa> an auto-building site doesn't need that if it does a guix build itself
5252021-07-01T19:59:18 <sipa> the question is what it should be building
5262021-07-01T19:59:34 <laanwj> sipa: the idea is that people who download the binary have something to verify
5272021-07-01T19:59:41 <neha> a longer term question (which doesn't need to be answered right now) is how we might get to a placed where the community could tolerate it if laanwj's sig wasn't there for whatever reason
5282021-07-01T19:59:54 <laanwj> sipa: currently the sha256sums.asc is signed with my GPG key, someone else cannot do that
5292021-07-01T20:00:15 <laanwj> so the idea is what to do instead for future releases
5302021-07-01T20:00:22 <sipa> oh ok, we're not talking about using guix attestations to instruct the site what to publish?
5312021-07-01T20:00:29 <sipa> just something similar
5322021-07-01T20:01:15 <harding> We've had to update the expiration on laanwj's key before, which created some confusion but not much. On Bitcoin.org years ago, we saw that 99% of people who downloaded binaries didn't download the SHASUMs file, so most people aren't verifying in any case.
5332021-07-01T20:01:34 <luke-jr> :|
5342021-07-01T20:01:54 <luke-jr> harding: or perhaps verifying via gitian.sigs as ideal, but.. unlikely
5352021-07-01T20:01:56 <ariard> harding: yes though maybe we can hope that the 1% doing it will serve as canary to alert the others ?
5362021-07-01T20:01:56 <sdaftuar> harding: i think it would be terrible though if the few people who do verify, stop doing it because one time they tried and it didn't seem to work so they threw their hands up
5372021-07-01T20:02:04 <laanwj> but yes it's kind of a hassle that so many instructions have my gpg key hardcoded now for validation
5382021-07-01T20:02:09 <harding> I think on BitcoinCore.org, we could just provide copies of laanwj's signed shasums next to some other signed shasums file for a few releases, and then transition away from laanwj's to the alternative.
5392021-07-01T20:02:13 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
5402021-07-01T20:02:30 <laanwj> (well it's a separate distribution signing key, not my main gpg key, but still i don't feel comfortable giving it to others)
5412021-07-01T20:02:40 <luke-jr> harding: the combined file would still verify with laanwj's key
5422021-07-01T20:02:40 <sipa> of course
5432021-07-01T20:02:42 <harding> The BitcoinCore.org download page has shasum verification instructinos on it, so we could mention any alternative.
5442021-07-01T20:03:00 <laanwj> harding: makes sense to me
5452021-07-01T20:03:40 <harding> If there's a clear plan for the alternative, someone please ping me and I'll open a PR for the website making the changes.
5462021-07-01T20:04:06 <laanwj> harding: thanks!
5472021-07-01T20:04:10 <luke-jr> fwiw I wrote this a while back https://medium.com/@lukedashjr/how-to-securely-install-bitcoin-9bfeca7d3b2a?readmore=1
5482021-07-01T20:04:22 <luke-jr> but it's designed around gitian sigs, so will need a revision for guoix
5492021-07-01T20:04:23 <luke-jr> guix*
5502021-07-01T20:04:40 <achow101> I think a better test run would be 0.21.2 since we haven't started on that
5512021-07-01T20:04:40 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
5522021-07-01T20:04:52 * dongcarl is here if anyone has questions
5532021-07-01T20:05:05 <luke-jr> achow101: yeah, but no point training users on a gitian-specific verification if we move to guix
5542021-07-01T20:05:20 <laanwj> i think it's time to end the meeting, we can continue this topic some other time if needed
5552021-07-01T20:05:44 <laanwj> #endmeeting
5562021-07-01T20:05:44 <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
5572021-07-01T20:05:44 <core-meetingbot> Meeting ended Thu Jul 1 20:05:44 2021 UTC.
5582021-07-01T20:05:44 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-07-01-19.00.moin.txt
5592021-07-01T20:07:44 <michaelfolkson> Having multiple bitcoincore.org equivalents and rotation of release signers sounds good (decentralization, reduce single points of failure) but could certainly introduce confusion for users
5602021-07-01T20:07:57 *** lukedashjr <lukedashjr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
5612021-07-01T20:08:10 <gleb> While people are still here I wanted to mention that #21515 is ready for review again, although it makes sense to review #21859 first if you feel like it.
5622021-07-01T20:08:12 <gribble> https://github.com/bitcoin/bitcoin/issues/21515 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #21515 · bitcoin/bitcoin · GitHub
5632021-07-01T20:08:14 <gribble> https://github.com/bitcoin/bitcoin/issues/21859 | Add minisketch subtree and integrate in build/test by sipa · Pull Request #21859 · bitcoin/bitcoin · GitHub
5642021-07-01T20:08:27 <jonatack> thinking out loud, of the non-maintainers, personally i could see achow101 who has been very involved in everything to do with signing and gitian sigs. good additional criteria might be number of years active in general and in contributing gitian signatures.
5652021-07-01T20:08:46 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Ping timeout: 256 seconds)
5662021-07-01T20:09:46 <jonatack> quite happy to see laanwj continue as well.
5672021-07-01T20:10:12 <michaelfolkson> jonatack: Right. Rotating it to anyone who puts their hand up doesn't sound like a great idea
5682021-07-01T20:11:02 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Ping timeout: 256 seconds)
5692021-07-01T20:11:11 *** lukedashjr is now known as luke-jr
5702021-07-01T20:11:18 <michaelfolkson> Someone like achow101 obviously would be zero problem
5712021-07-01T20:11:20 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 272 seconds)
5722021-07-01T20:11:43 <ariard> yeah let's take time to do this, especially if you put more responsiblity on users to browse through multiple vending websites
5732021-07-01T20:12:53 <laanwj> multiple vending websites?
5742021-07-01T20:13:38 <jonatack> gleb indeed, looking forward to diving into erlay soon after 22.0 is ready
5752021-07-01T20:13:50 <achow101> I'd be willing to do releases
5762021-07-01T20:16:20 <laanwj> achow101: great!
5772021-07-01T20:17:25 <ariard> laanwj: mirros? ultimately with bitcoincore.org you might have domain name/ip law issues :/
5782021-07-01T20:18:02 <laanwj> ariard: i don't think that's part of the plan right now, there's bitcoincore.org and the torrent
5792021-07-01T20:18:43 <lightlike> gleb: cool, I'll try to review soon! I read that you incorporated some changes (e.g. static q), is the BIP linked in the OP still in sync with the current code?
5802021-07-01T20:18:51 <jonatack> musing, fanquake and achow101 are at the top of https://github.com/bitcoin-core/gitian.sigs/graphs/contributors by a fair measure, makes sense
5812021-07-01T20:19:54 <laanwj> i mean, sure, you could have mirrors, but that makes it much harder for users to know what to trust, what if one gets compromised, in any case that can be considered independently, it's orthogonal to rotating who does the release
5822021-07-01T20:25:55 <laanwj> jonatack: that's cool
5832021-07-01T20:28:27 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
5842021-07-01T20:28:59 <ariard> quick update on coredev making progress, we had a call with veterans yesterday :)
5852021-07-01T20:35:43 <laanwj> ariard: thanks!
5862021-07-01T20:37:41 <jonatack> laanwj: yes and as PoW it's not gameable, can't go faster than the releases :D
5872021-07-01T20:38:41 <jonatack> ariard: it was great seeing everyone, some for the first time. i was quite distracted and don't remember who is now supposed to do what, so will look out for your recap
5882021-07-01T20:46:38 *** GIANTWORLDKEEPER <GIANTWORLDKEEPER!~pjetcetal@128-71-13-182.broadband.corbina.ru> has quit IRC (Quit: EXIT)
5892021-07-01T21:12:18 *** smartin <smartin!~Icedove@88.135.18.171> has quit IRC (Ping timeout: 240 seconds)
5902021-07-01T21:28:53 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has quit IRC (Remote host closed the connection)
5912021-07-01T21:39:30 *** AaronvanW <AaronvanW!~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53> has joined #bitcoin-core-dev
5922021-07-01T21:47:04 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.196> has quit IRC (Ping timeout: 246 seconds)
5932021-07-01T22:03:31 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
5942021-07-01T22:23:31 <gleb> lightlike: BIP is low-key in sync. The new changes technically don't violate the old BIP, but it might have some little references to meaningless (now) stuff
5952021-07-01T22:24:31 <gleb> I will soon create some FAQ on protocol design choices and deviations from the original proposal.
5962021-07-01T22:34:16 *** jeremyru_ <jeremyru_!~jeremyrub@024-176-247-182.res.spectrum.com> has joined #bitcoin-core-dev
5972021-07-01T22:43:28 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 256 seconds)
5982021-07-01T23:10:39 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
5992021-07-01T23:33:42 *** earnestly <earnestly!~earnest@user/earnestly> has quit IRC (Ping timeout: 268 seconds)
6002021-07-01T23:47:13 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev