--- Log opened Thu Jul 01 00:00:53 2021 00:03 -!- Kiminuo [~Kiminuo@141.98.103.236] has quit [Ping timeout: 246 seconds] 00:11 -!- Kiminuo [~Kiminuo@141.98.103.188] has joined #bitcoin-core-dev 00:21 -!- belcher_ is now known as belcher 00:24 -!- goatpig [~goat@h-94-254-2-155.A498.priv.bahnhof.se] has quit [Quit: Konversation terminated!] 00:24 < 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 00:27 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 00:31 < vasild> That is related to #17194 and #21528 00:31 <@gribble> https://github.com/bitcoin/bitcoin/issues/17194 | p2p: Avoid forwarding ADDR messages to SPV nodes by naumenkogs · Pull Request #17194 · bitcoin/bitcoin · GitHub 00:31 <@gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [p2p] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub 00:37 -!- earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev 00:50 -!- Guest50 [~Guest50@120.17.197.217] has joined #bitcoin-core-dev 00:54 -!- focus [~focus@109-184-162-4.dynamic.mts-nn.ru] has quit [Ping timeout: 246 seconds] 00:56 -!- Guest50 [~Guest50@120.17.197.217] has quit [Quit: Client closed] 01:02 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has joined #bitcoin-core-dev 01:39 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 01:42 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 240 seconds] 01:43 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 240 seconds] 01:44 -!- dongcarl[m] [~dongcarlm@2001:470:69fc:105::82] has quit [Quit: node-irc says goodbye] 01:48 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:56 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 01:58 -!- Kiminuo [~Kiminuo@141.98.103.188] has quit [Ping timeout: 246 seconds] 02:02 -!- kexkey_ [~kexkey@198.54.132.118] has joined #bitcoin-core-dev 02:04 -!- kexkey [~kexkey@198.54.132.118] has quit [Ping timeout: 258 seconds] 02:23 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f03bc00e8dae3d2b501b2e6.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 03:13 -!- stevenroose [~steven@2001:19f0:6801:83a:a90a:4c55:7940:b7e2] has quit [Quit: ZNC 1.7.4 - https://znc.in] 03:13 -!- stevenroose [~steven@irc.roose.io] has joined #bitcoin-core-dev 03:14 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed] 03:14 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev 03:23 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 256 seconds] 03:24 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 03:28 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed] 03:39 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 03:43 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 240 seconds] 03:49 < laanwj> hebasto: strange, let's see 03:51 -!- smartin [~Icedove@88.135.18.171] has joined #bitcoin-core-dev 03:56 -!- roconnor [~roconnor@host-45-78-206-181.dyn.295.ca] has joined #bitcoin-core-dev 03:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 03:57 < 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 03:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 03:57 < laanwj> there it is again 03:57 < hebasto> nice 03:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 03:58 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ef2d400fa42...fa46e489820b 03:58 < bitcoin-git> bitcoin/master b945a31 Andrew Chow: wallet: erase spkmans rather than setting to nullptr 03:58 < bitcoin-git> bitcoin/master fa46e48 fanquake: Merge bitcoin/bitcoin#22379: wallet: erase spkmans rather than setting to ... 03:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:07 < 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 04:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 04:13 -!- jinkbs [~jinkbs@240e:3b2:a3f:1820:cd78:5ac8:cdbd:5b0] has quit [Quit: Client closed] 04:14 -!- jinkbs238 [~jinkbs2@240e:3b2:a3f:1820:cd78:5ac8:cdbd:5b0] has quit [Quit: Client closed] 04:17 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev 04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:19 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ef2d400fa42...fa46e489820b 04:19 < bitcoin-git> bitcoin/master b945a31 Andrew Chow: wallet: erase spkmans rather than setting to nullptr 04:19 < bitcoin-git> bitcoin/master fa46e48 fanquake: Merge bitcoin/bitcoin#22379: wallet: erase spkmans rather than setting to ... 04:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:20 < laanwj> (^^ that was a test, hence the repeated notification) 04:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:23 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fa46e489820b...185acdb5e818 04:23 < bitcoin-git> bitcoin/master 6084d2c S3RK: wallet: do not spam about non-existent spk managers 04:23 < bitcoin-git> bitcoin/master 185acdb fanquake: Merge bitcoin/bitcoin#22334: wallet: do not spam about non-existent spk ma... 04:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:26 < 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 04:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:37 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 04:48 -!- jespada [~jespada@90.254.247.46] has quit [Ping timeout: 272 seconds] 04:49 -!- jespada [~jespada@90.254.247.46] has joined #bitcoin-core-dev 04:55 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 05:14 -!- kabaum [~kabaum@ua-84-216-129-44.bbcust.telenor.se] has joined #bitcoin-core-dev 05:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 05:17 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/185acdb5e818...2749613020ed 05:17 < bitcoin-git> bitcoin/master 67669ab Hennadii Stepanov: build: Fix Boost Process compatibility with mingw-w64 compiler 05:17 < bitcoin-git> bitcoin/master 2749613 fanquake: Merge bitcoin/bitcoin#22348: build: Fix cross build for Windows with Boost... 05:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 05:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 05:18 < 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 05:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 05:23 -!- jinkbs [~jinkbs@240e:3b2:a3f:1820:fd1c:d1fa:912a:ce89] has joined #bitcoin-core-dev 05:32 -!- jinkbs [~jinkbs@240e:3b2:a3f:1820:fd1c:d1fa:912a:ce89] has quit [Quit: Client closed] 05:35 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-dev 05:40 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has quit [Quit: leaving] 05:40 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-dev 05:46 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has quit [Quit: leaving] 05:46 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-dev 05:47 < 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 06:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:02 < 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 06:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:03 < 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 06:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:19 -!- powerjungle [~powerjung@h081217087223.dyn.cm.kabsi.at] has left #bitcoin-core-dev [see ya around] 06:39 < laanwj> haha yes 06:43 -!- kabaum [~kabaum@ua-84-216-129-44.bbcust.telenor.se] has quit [Ping timeout: 258 seconds] 06:46 < hebasto> it seems #22381 cannot be fully tested and reviewed before #22365, at least to test the ELF functionality 06:46 <@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 06:46 <@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 06:47 < fanquake> You can always just run the tests manually 06:47 < hebasto> right 06:49 < fanquake> The important changes there are for Win and macOS 06:49 < fanquake> Also, the other changes will mostly be dropped when we move to testing the ELF binaries with LIEF 06:50 < hebasto> we won't move to LIEF for ELF binaries for 22.0 release, right? 06:51 < laanwj> i don't think so 06:51 < fanquake> It's not a requirement, but I could put the changes together tomorrow if you want to see them 06:52 < fanquake> I wont be around for the meeting, but I assume branch off will discussed, and I think we are in pretty good shape. 06:52 < laanwj> i'm not sure what would be the advantage of switching that last minute 06:52 < fanquake> 22365 + 22381 will just about round out the Guix changes. With some docs in #21711. 06:52 <@gribble> https://github.com/bitcoin/bitcoin/issues/21711 | guix: Add full installation and usage documentation by dongcarl · Pull Request #21711 · bitcoin/bitcoin · GitHub 06:52 < fanquake> I think a Guix only release is the way to go. 06:52 < laanwj> I think so too 06:52 < fanquake> There's not much else left in the milestone other than that 06:53 < laanwj> what about #19438 06:53 <@gribble> https://github.com/bitcoin/bitcoin/issues/19438 | Introduce deploymentstatus by ajtowns · Pull Request #19438 · bitcoin/bitcoin · GitHub 06:53 < laanwj> in my idea that was holding things up 06:54 < fanquake> It looks like there could be benefits to getting that in pre branch-off 06:55 < laanwj> definitely 06:58 < 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 06:58 <@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 07:00 < laanwj> i see, if people concept-disagree with it it's better to bump it from the milestone 07:00 < laanwj> don't think it is critical to make it into 22.0 07:02 -!- roconnor [~roconnor@host-45-78-206-181.dyn.295.ca] has quit [Ping timeout: 252 seconds] 07:02 < fanquake> If anyone thinks anything has been missed they should also make a point to call it out in the meeting 07:11 < 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) 07:14 < jonatack> (not to hold up rc1 but before -final) 07:15 < laanwj> I think I prefer #22112 07:15 <@gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub 07:16 < laanwj> but good point on needing a solution to that 07:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:18 < bitcoin-git> [gui] hebasto opened pull request #377: Translations update (master...210701-tr) https://github.com/bitcoin-core/gui/pull/377 07:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:18 < hebasto> laanwj: ^ I've noted FF is checked in https://github.com/bitcoin/bitcoin/issues/20851 since yesterday 07:20 < 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 07:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:23 < 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 07:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:23 < 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 07:28 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 07:34 -!- jtrag [~jtrag@c-71-207-125-151.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 07:37 < 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 07:37 < laanwj> jonatack: thanks, I'll start testing it too 07:39 < 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 07:40 < 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 07:40 < 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 07:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:41 < bitcoin-git> [gui] hebasto merged pull request #377: Translations update (master...210701-tr) https://github.com/bitcoin-core/gui/pull/377 07:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:41 < bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2749613020ed...091d35c70e88 07:41 < bitcoin-git> bitcoin/master c7f74f1 Hennadii Stepanov: Translations update 07:41 < bitcoin-git> bitcoin/master 091d35c Hennadii Stepanov: Merge bitcoin-core/gui#377: Translations update 07:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:42 < 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. 07:42 < jonatack> so two things to test :) 07:58 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has quit [Quit: Konversation terminated!] 08:09 < 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 08:11 < 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? 08:12 < 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. 08:12 < sdaftuar> or, what fraction of the network should receive any given announced address, over some time period 08:13 < vasild> hmm 08:13 < jonatack> interesting questions 08:13 < 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 08:14 < vasild> I agree 08:14 < 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? 08:15 < sdaftuar> could be either; i could imagine that we need to negotiate behavior both around getaddr/getaddr-responses as well as unsolicited relay 08:16 < jonatack> it does seems that adding networks has introduced changes, effects and interactions that we're probably still mostly on the cusp of 08:16 < jonatack> and addr relay was already fertile ground for more research 08:17 < 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"... 08:18 < earnestly> (Can solicitation divulge information in such a way that is useful for attacking anonimity?) 08:18 < vasild> I don't think the latter supersedes "no-unsolicited-addrs". solicited-or-not is one thing, the type of addresses is another, no? 08:19 < 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 08:19 < sdaftuar> it's possible it own't evolve that way of course, i just htink we don't know yet 08:21 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:23 < 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... 08:24 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 256 seconds] 08:24 -!- Guyver2_ is now known as Guyver2 08:24 < vasild> s/does not relay tor addresses/relays tor addresses less readily/ 08:26 < vasild> earnestly: even if I can tell your ipv4 node has i2p connectivity and does not have tor connectivity, what harm could I do? 08:26 < earnestly> vasild: It only came to mind due to that old paper about vulnerabilities in using tor with that autoban system 08:27 < vasild> I have not read that one 08:27 < vasild> it is cheap to generate tor addresses, I guess if one gets banned he can create a new address easily and persist misbehaving 08:28 < earnestly> vasild: https://arxiv.org/abs/1410.6079 (2015) 08:30 < vasild> "A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor" :-O 08:35 < 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 08:35 < vasild> make it more difficult for an observer to tell which networks a node is connected to.", I think that makes sense. 08:38 < 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. 08:43 < 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) 08:58 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f03bc00e8dae3d2b501b2e6.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 09:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:37 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/091d35c70e88...a926d6dfd291 09:37 < bitcoin-git> bitcoin/master c4ddee6 Antoine Riard: test: Add test for replacement relay fee check 09:37 < bitcoin-git> bitcoin/master a926d6d MarcoFalke: Merge bitcoin/bitcoin#22310: test: Add functional test for replacement rel... 09:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:37 < 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 09:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:42 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-dev 09:58 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 256 seconds] 10:03 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev 10:13 -!- kabaum [~kabaum@ua-84-216-129-44.bbcust.telenor.se] has joined #bitcoin-core-dev 10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:16 < bitcoin-git> [bitcoin] MarcoFalke pushed 13 commits to master: https://github.com/bitcoin/bitcoin/compare/a926d6dfd291...ddc6979b8baa 10:16 < bitcoin-git> bitcoin/master 36a4ba0 Anthony Towns: versionbits: correct doxygen comments 10:16 < bitcoin-git> bitcoin/master eccd736 Anthony Towns: versionbits: Use dedicated lock instead of cs_main 10:16 < bitcoin-git> bitcoin/master 2b0d291 Anthony Towns: [refactor] Add deploymentstatus.h 10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:16 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #19438: Introduce deploymentstatus (master...202007-deployment-refactor) https://github.com/bitcoin/bitcoin/pull/19438 10:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:19 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 10:33 -!- Kiminuo [~Kiminuo@141.98.103.196] has joined #bitcoin-core-dev 11:01 < hebasto> meeting? 11:01 < hebasto> or missed an hour 11:02 < laanwj> date -u shows there's still an hour to go 11:02 < sipa> indeed 11:02 < hebasto> yeap 11:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:09 < 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 11:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:39 -!- kabaum [~kabaum@ua-84-216-129-44.bbcust.telenor.se] has quit [Ping timeout: 265 seconds] 11:39 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 240 seconds] 11:40 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 11:48 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 11:53 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds] 12:00 < laanwj> #startmeeting 12:00 < 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. 12:00 < core-meetingbot> Available commands: action commands idea info link nick 12:00 < hebasto> hi 12:00 < 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 12:00 < laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 12:00 < jarolrod> hi 12:01 < ajonas> Hi 12:01 < ariard> hi 12:01 < meshcollider> Hi 12:01 < michaelfolkson> hi 12:01 < jonatack> hi 12:01 < gleb> hi 12:01 < luke-jr> #proposedmeetingtopic When it's okay to auto-update across softfork enforcement 12:01 < neha> hi 12:01 < lightlike> hi 12:01 < laanwj> welcome to the weekly meeting; there have been no proposed meeting topics for this week, any last minute ones? 12:02 < neha> #proposedmeetingtopic Training to rotate release responsibility 12:02 < luke-jr> laanwj: see ^ 12:02 < luke-jr> err, ^ ^ too ;) 12:02 < laanwj> yes! 12:03 < laanwj> #topic 22.0 release 12:03 < core-meetingbot> topic: 22.0 release 12:03 < achow101> hi 12:03 < 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 12:04 < laanwj> most have to do with the build system and guix, but there's also #22122 which is P2P related 12:04 <@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 12:04 < laanwj> wait no not that one #22112 12:04 <@gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub 12:05 < 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 12:05 <@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 12:05 < achow101> should the guix stuff be kept? they're both still drafts 12:05 < laanwj> the guix stuff is needed to do a release 12:06 < laanwj> not sure why they're draft labeled 12:06 < jonasschnelli> hi 12:06 < jarolrod> ^ pinging dongcarl 12:06 < luke-jr> unless we just use gitian again 12:06 < achow101> #21711 is just docs and some error checking, so I don't think it is necessary 12:06 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 12:06 <@gribble> https://github.com/bitcoin/bitcoin/issues/21711 | guix: Add full installation and usage documentation by dongcarl · Pull Request #21711 · bitcoin/bitcoin · GitHub 12:07 < laanwj> docs are very important because a lot of people are going to do guix builds for the first time 12:08 < hebasto> luke-jr: #22365 and guix, or multiple glibc symbol compatibility fixups and gitian 12:08 <@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 12:08 < laanwj> luke-jr: if there is a problem with the guix build we can always fall back to gitian, but it is unlikely 12:09 < luke-jr> hebasto: gitian should be fixed even if we use guix 12:09 < laanwj> it might be possible that bugfixes are still added for the 22.0 milestone but the feature freeze is active now 12:09 < dongcarl> Hi 12:09 < dongcarl> I’m working on the docs right now, updating for Guix 1.3.0 12:10 < dongcarl> Are we talking about fixing the gitian build for the symbol problem? 12:10 < laanwj> (and so is the translation string freeze, we've done the last update of the source translations pre-rc a few hours ago) 12:10 < laanwj> dongcarl: achow101 just noted that your PRs on the 22.0 milestone are labeled as draft, which is somewhat confusing 12:11 < dongcarl> Yes I intend on adding more commentary to those PRs so that’s why they are still Draft 12:11 < dongcarl> Can mark as ready if people want, no strong opinions 12:12 < laanwj> it's fine imo 12:12 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds] 12:13 < dongcarl> Happy to answer any more questions :-) 12:13 < laanwj> #topic 12:13 < core-meetingbot> topic: 12:13 < laanwj> #topic When it's okay to auto-update across softfork enforcement (luke-jr) 12:13 < core-meetingbot> topic: When it's okay to auto-update across softfork enforcement (luke-jr) 12:14 < 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 12:14 < luke-jr> Softforks should be consensual, but when does it move on to the point where it's just assumed users want it? 12:15 < luke-jr> any thoughts? 12:15 < achow101> presumably after lock in? 12:15 < luke-jr> (my Core PPA is still at 0.21.0 pending some solution) 12:15 < luke-jr> achow101: but lock-in is just miners, not the community 12:16 < ariard> well we have buried deployment which are quite making assumptions on users w.r.t to softfork activation 12:16 < ariard> bip90 12:16 < luke-jr> do we then assume any opposed users would have forked off at this point? 12:16 < luke-jr> ariard: but those are already active, which I think is a very clear safe time to do it 12:16 < sipa> is it possible in snap etc to have a different channel or package name per release? 12:16 < luke-jr> once activation, IMO it's pretty clearly fine 12:17 < luke-jr> sipa: not sure about Snaps, but for the PPA, it seems to be possible to prompt the user to explicitly agree 12:17 < luke-jr> there's some packages that added an EULA for a version bump prompting the user on upgrade, and that seems similar logically 12:18 < luke-jr> Gentoo packages have USE flags, and can be set to not install until one is set by the user 12:18 < 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 12:18 < luke-jr> (which is what 0.21.1 is doing right now on the Gentoo overlay) 12:19 < sipa> ariard: we can't wait for buried deployment here 12:19 < 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 12:19 < sipa> ariard: we can't wait to release 0.21.1 packages until taproot is active, e.g. 12:19 < sipa> (+ probably a few years) 12:19 < luke-jr> yeah, simply not having packages is a problem too because most users *will* want to upgrade 12:20 < luke-jr> doing so should be easy 12:20 < sipa> and i don't think opposition is the right criterion here; nothing is being forced 12:20 < sipa> the question is about unaware upgrading 12:20 < ariard> luke-jr: gotcha it's regard with increasing the number of users with softfork enforcement logic at time of taproot activation? 12:20 < sipa> if people were aware of a softfork they'd active oppose, they'd stop using the snap/ppa/whatever 12:21 < sipa> ariard: no, it's just that people shouldn't be opted into enforcing softfork rules without being aware of it 12:21 < luke-jr> ariard: softforks without user enforcement are effectively failed softforks 12:22 < 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 12:22 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:22 < sipa> this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism 12:22 < sipa> but this is obviously bypassed by using distro-packaged versions that do automatically update 12:23 < 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 12:23 < 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 ? 12:23 < sipa> ariard: i don't know what the solution is 12:23 < luke-jr> ariard: the node owner should be the one to make the decision 12:23 < ariard> luke-jr: fully agree on this! 12:24 < ariard> but a lot of folks might just fetch package without reading release notes 12:24 < sipa> that's inevitable 12:24 < ariard> i think so too 12:24 < luke-jr> ariard: bitcoincore.org's blog post has the title specific to Taproot too for example 12:24 < 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 12:25 < luke-jr> I *can* make the PPA and Gentoo stuff force user consent explicitly; the question is when it's okay to omit that ;) 12:25 < luke-jr> (MarcoFalke would have to comment on his snap stuff) 12:25 < 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 12:26 < ariard> luke-jr: imho, i would say it's more a PPA/gentoo/snap admin policy there, hard to all agree on this? 12:27 < harding> debian has an opt-in setting for major release note stuff. 12:27 < laanwj> (and for people doing background automatic updates that wouldn't work anyway) 12:27 < laanwj> harding: oh good to know 12:28 < sipa> in a way this is a strange discussion, because i think we're effectively worrying about a rogue distribution maintainer 12:28 < 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. 12:28 < sipa> but if that's the case, they would obviously patch out whatever warning exists 12:28 < harding> s/main/mail/ 12:28 < luke-jr> sipa: not necessarily rogue 12:29 < 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 12:29 < 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 12:29 < laanwj> right, it's for good reason we resisted bitcoin being part of package repositories for a long time 12:30 < laanwj> it's extremly unsuited to automatic updates 12:30 < 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" 12:30 < sipa> luke-jr: and clearly, we're of the opinion that this consensus change is going to happen 12:30 < sipa> so what is the warning protecting against? if this information was intentionally false, you'd also remove the warning... 12:31 < luke-jr> because even honest package maintainers shouldn't make the call for users ;) 12:31 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Remote host closed the connection] 12:32 < 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... 12:32 < 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 12:32 < sipa> that's a concern on itself 12:32 < ariard> s/software/softfork/g 12:32 < sipa> but i don't know what to do about it 12:33 < ariard> empower and educate users to have more of them building from the sources 12:33 < sipa> yeah 12:33 < sipa> also, good luck 12:33 < 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.) 12:33 < laanwj> manually downloading binaries is fine too 12:33 < jonatack> or download the binaries 12:33 < 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. 12:34 < 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 12:34 < earnestly> You really have to leave these decisions to downstream 12:34 < harding> (The debconf configuration wizard can prompt you to do that.) 12:34 < earnestly> (I.e. not worry) 12:34 < luke-jr> harding: but then we're patching the code 12:34 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 12:35 < luke-jr> maybe we should add a softforks= upstream for future stuff like that 12:35 < luke-jr> earnestly: there is no downstream 12:35 < earnestly> That would be the best option, probably 12:35 < earnestly> downstream here is defined as package maintainers 12:36 < 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. 12:36 < luke-jr> earnestly: ie, me 12:36 < 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 12:36 < luke-jr> harding: won't it auto-switch? 12:36 < sipa> and i think this also isn't the core of the issue 12:36 < earnestly> luke-jr: That there is an overlap between upstream and downstream doesn't change the distinction 12:36 < laanwj> yes , getting the update but ending up with a non-working binary that's pretty awful for users 12:36 < earnestly> What you do for the distribution is related to upstream but not identical 12:36 < luke-jr> sipa: right; we can't stop people from patchign things out, but this provides a good solution otherwise 12:37 < sipa> i'm not sure 12:37 < 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. 12:37 < luke-jr> laanwj: GUI can prompt too? 12:37 < luke-jr> harding: even when the prior value is being removed? :p 12:38 < earnestly> sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them? 12:38 < harding> luke-jr: yeah, the different symlinks have priorities and you can set like -1 or something for never-auto-select. 12:39 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds] 12:39 < harding> luke-jr: also you could make the default /usr/bin/bitcoind a shell script that prompts you to opt-in to taproot. 12:39 < harding> (Or whatever thing you as maintainer thinks needs opting in.) 12:39 < luke-jr> anyway, there are multiple solutions; my question was mainly when we no longer should take extra steps like these 12:40 < laanwj> harding: for user-facing tools that's fine, but that would go wrong if it's started from an (init) script 12:40 < laanwj> you can usually assume bitcoind is used as part of some stack 12:40 < 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. 12:41 < 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" 12:41 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 12:41 < earnestly> They can just remove that, there's no point playing this game 12:41 < sipa> it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included" 12:41 < sipa> but that's just the normal release notes/process 12:42 < 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). 12:42 < earnestly> (I do like luke-jr's idea of having a softfork= option though, future?) 12:43 < ariard> harding: if by "announce the change" you mean publicity around softfork locks in, 3 months sounds reasonable to me 12:43 < luke-jr> the solutions I have right now just don't perform the update until the user explicitly agrees 12:43 < 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 12:43 < harding> ariard: I was thinking 3 months from the BitcoinCore.org release announcement. 12:44 < luke-jr> but people might never see that :/ 12:45 < laanwj> we might want ot leave some time for the last topic 12:45 < 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. 12:46 < luke-jr> maybe I'll just leave the extra step installing in place until November 12:47 < luke-jr> laanwj: I think the topic is done 12:48 < laanwj> #topic Training to rotate release responsibility (neha) 12:48 < core-meetingbot> topic: Training to rotate release responsibility (neha) 12:48 < 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? 12:49 < michaelfolkson> What are the responsibilities? Are there any that we wouldn't want to rotate? 12:49 < 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 12:49 < 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 12:49 < laanwj> but of course the best way to find out is to have someone else go through it 12:49 < luke-jr> neha: it's not too hard tbh 12:50 < luke-jr> we have good docs 12:50 < neha> fanquake has already volunteered, i believe 12:50 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds] 12:50 < laanwj> yes, unfortunately he's couldn't be at this meeting 12:50 < amiti> I think it's a great idea! 12:51 < michaelfolkson> Any downsides? Presumably it would only rotate around maintainers? 12:51 < achow101> wouldn't this require giving more people write access and upload access to bitcoincore.org? 12:51 < jonatack> ^ i would have thought that was a maintainer role (more or less by definition) 12:51 < 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) 12:52 < sipa> laanwj: agree, but also feel free to ask if you see places where help is useful 12:52 < luke-jr> there's going to be one more 0.20.x before 22.0, right? 12:52 < achow101> we could trial with 0.20.2 12:52 < laanwj> achow101: sure, or they could do everything except the upload 12:52 < ariard> maybe we could have more distribution mirrors instead of one big official one like bitcoincore.org 12:53 < luke-jr> michaelfolkson: NACK treating maintainers special 12:53 < laanwj> there was another idea for the longer run to have bitcoincore.org build the binaries itself (it's deterministic after all) 12:53 < luke-jr> laanwj: not sure we gain anything from that? 12:53 < laanwj> then the maintainer would only have to do a tag, and trigger it, i guess 12:53 < laanwj> luke-jr: no one needs to upload binaries 12:53 < 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... 12:54 < harding> The deterministic build idea is already how we handle the website content basically, so it's not too strange. 12:54 < achow101> laanwj: still have upload sha256sums 12:54 < laanwj> seems beter than giving multiple people write aceess to the /bin 12:54 < achow101> *signed sha256sums 12:54 < laanwj> achow101: depends on how we're going to do the signing 12:54 < luke-jr> laanwj: just check that uploads have N signers 12:54 < luke-jr> we would want that even if it built itself 12:54 < laanwj> achow101: but yeah, having that happen on the website is a bad idea :) 12:55 < harding> If N people sign the torrent hash, then the website could download that directly. 12:55 < 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? 12:55 < laanwj> in any case the uploading is the least interesting part 12:55 < laanwj> the rest of the release process is where more work is 12:55 < laanwj> neha: sgtm 12:55 < luke-jr> neha: it won't make sense to do it once we get to November 12:56 < luke-jr> since it doesn't have Taproot 12:56 < achow101> 0.20.2 is ready to go except for release notes 12:56 < luke-jr> and rc cycle 12:56 < laanwj> yes 12:56 < 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? 12:57 < luke-jr> sdaftuar: we really should be moving to a setup where many of us sign those 12:57 < 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. 12:57 < achow101> luke-jr: we already have 0.20.2rc2 since early june 12:57 < sdaftuar> luke-jr: sure, but i assume we're not there yet? 12:57 < neha> sdaftuar: i think part of the goal is to achieve fault tolerance, so ideally yes 12:57 < 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 12:57 < luke-jr> achow101: has anyone tested it? 12:57 < laanwj> sdaftuar: it should be multi-signed i think 12:57 < luke-jr> sdaftuar: it's just a matter of doing it 12:57 < laanwj> sdaftuar: i think that's dongcarl's thing too, the same sha256sum is signed by every builder 12:57 < laanwj> so the signatures can be concatenated 12:57 < luke-jr> someone just has to copy/paste others' signatures into the file 12:57 < achow101> luke-jr: probably not, but I expect that's normal for minor releases for old versions 12:58 < sdaftuar> laanwj: ah ok. just want to make sure we think to do whatever communication to the community is required for the change 12:58 < sipa> i think there is a conflation here 12:58 < luke-jr> so long as laanwj's signature is included, I expect it will be smooth 12:58 < laanwj> well i can do the signing and upload for 0.20.2 no problem 12:58 < sipa> guix attestations only prove that a particular source code corresponds to a certain binary 12:59 < sipa> an auto-building site doesn't need that if it does a guix build itself 12:59 < sipa> the question is what it should be building 12:59 < laanwj> sipa: the idea is that people who download the binary have something to verify 12:59 < 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 12:59 < laanwj> sipa: currently the sha256sums.asc is signed with my GPG key, someone else cannot do that 13:00 < laanwj> so the idea is what to do instead for future releases 13:00 < sipa> oh ok, we're not talking about using guix attestations to instruct the site what to publish? 13:00 < sipa> just something similar 13:01 < 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. 13:01 < luke-jr> :| 13:01 < luke-jr> harding: or perhaps verifying via gitian.sigs as ideal, but.. unlikely 13:01 < ariard> harding: yes though maybe we can hope that the 1% doing it will serve as canary to alert the others ? 13:01 < 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 13:02 < laanwj> but yes it's kind of a hassle that so many instructions have my gpg key hardcoded now for validation 13:02 < 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. 13:02 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 13:02 < 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) 13:02 < luke-jr> harding: the combined file would still verify with laanwj's key 13:02 < sipa> of course 13:02 < harding> The BitcoinCore.org download page has shasum verification instructinos on it, so we could mention any alternative. 13:03 < laanwj> harding: makes sense to me 13:03 < 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. 13:04 < laanwj> harding: thanks! 13:04 < luke-jr> fwiw I wrote this a while back https://medium.com/@lukedashjr/how-to-securely-install-bitcoin-9bfeca7d3b2a?readmore=1 13:04 < luke-jr> but it's designed around gitian sigs, so will need a revision for guoix 13:04 < luke-jr> guix* 13:04 < achow101> I think a better test run would be 0.21.2 since we haven't started on that 13:04 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 13:04 * dongcarl is here if anyone has questions 13:05 < luke-jr> achow101: yeah, but no point training users on a gitian-specific verification if we move to guix 13:05 < laanwj> i think it's time to end the meeting, we can continue this topic some other time if needed 13:05 < laanwj> #endmeeting 13:05 < 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 13:05 < core-meetingbot> Meeting ended Thu Jul 1 20:05:44 2021 UTC. 13:05 < core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-07-01-19.00.moin.txt 13:07 < 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 13:07 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev 13:08 < 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. 13:08 <@gribble> https://github.com/bitcoin/bitcoin/issues/21515 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #21515 · bitcoin/bitcoin · GitHub 13:08 <@gribble> https://github.com/bitcoin/bitcoin/issues/21859 | Add minisketch subtree and integrate in build/test by sipa · Pull Request #21859 · bitcoin/bitcoin · GitHub 13:08 < 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. 13:08 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 256 seconds] 13:09 < jonatack> quite happy to see laanwj continue as well. 13:10 < michaelfolkson> jonatack: Right. Rotating it to anyone who puts their hand up doesn't sound like a great idea 13:11 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds] 13:11 -!- lukedashjr is now known as luke-jr 13:11 < michaelfolkson> Someone like achow101 obviously would be zero problem 13:11 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 272 seconds] 13:11 < ariard> yeah let's take time to do this, especially if you put more responsiblity on users to browse through multiple vending websites 13:12 < laanwj> multiple vending websites? 13:13 < jonatack> gleb indeed, looking forward to diving into erlay soon after 22.0 is ready 13:13 < achow101> I'd be willing to do releases 13:16 < laanwj> achow101: great! 13:17 < ariard> laanwj: mirros? ultimately with bitcoincore.org you might have domain name/ip law issues :/ 13:18 < laanwj> ariard: i don't think that's part of the plan right now, there's bitcoincore.org and the torrent 13:18 < 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? 13:18 < 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 13:19 < 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 13:25 < laanwj> jonatack: that's cool 13:28 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 13:28 < ariard> quick update on coredev making progress, we had a call with veterans yesterday :) 13:35 < laanwj> ariard: thanks! 13:37 < jonatack> laanwj: yes and as PoW it's not gameable, can't go faster than the releases :D 13:38 < 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 13:46 -!- GIANTWORLDKEEPER [~pjetcetal@128-71-13-182.broadband.corbina.ru] has quit [Quit: EXIT] 14:12 -!- smartin [~Icedove@88.135.18.171] has quit [Ping timeout: 240 seconds] 14:28 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Remote host closed the connection] 14:39 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 14:47 -!- Kiminuo [~Kiminuo@141.98.103.196] has quit [Ping timeout: 246 seconds] 15:03 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 15:23 < 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 15:24 < gleb> I will soon create some FAQ on protocol design choices and deviations from the original proposal. 15:34 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 15:43 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 256 seconds] 16:10 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 16:33 -!- earnestly [~earnest@user/earnestly] has quit [Ping timeout: 268 seconds] 16:47 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 17:07 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving] 17:21 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-dev 17:25 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 272 seconds] 17:26 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 256 seconds] 17:43 -!- earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev 17:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 17:53 < bitcoin-git> [bitcoin] sipa opened pull request #22387: Rate limit the processing of rumoured addresses (master...202106_rate_limit_addr) https://github.com/bitcoin/bitcoin/pull/22387 17:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 17:55 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 18:01 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 18:04 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 18:06 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 18:29 -!- davterra [~davterra@178.128.106.205] has quit [Quit: Leaving] 18:30 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 18:31 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 18:33 -!- instagibbs_ [~instagibb@119247204116.ctinets.com] has quit [Ping timeout: 268 seconds] 18:46 -!- earnestly [~earnest@user/earnestly] has quit [Ping timeout: 252 seconds] 18:46 -!- instagibbs_ [~instagibb@119247204116.ctinets.com] has joined #bitcoin-core-dev 18:57 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Remote host closed the connection] 19:03 -!- instagibbs_ [~instagibb@119247204116.ctinets.com] has quit [Read error: Connection timed out] 19:04 -!- instagibbs_ [~instagibb@119247204116.ctinets.com] has joined #bitcoin-core-dev 19:19 -!- instagibbs_ [~instagibb@119247204116.ctinets.com] has quit [Read error: Connection timed out] 19:28 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 19:33 < fanquake> Looks like the Android CI is failing because it's failing to download some java packages 19:34 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 256 seconds] 19:36 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 19:36 < fanquake> Have restarted, hopefully just intermittent 19:37 < fanquake> relevant log here: https://gist.github.com/fanquake/b3527bc3bab5aa2e9922c7f31e00c589 19:44 -!- emcy [~emcy@user/emcy] has quit [Ping timeout: 256 seconds] 19:46 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 19:49 -!- emcy [~emcy@user/emcy] has joined #bitcoin-core-dev 19:51 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 240 seconds] 19:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 19:58 < bitcoin-git> [bitcoin] fanquake opened pull request #22388: ci: use Ubuntu 20.04 as the default Docker container (master...ci_ubuntu_20_04) https://github.com/bitcoin/bitcoin/pull/22388 19:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 20:10 -!- RCasatta[m] [~rcasattam@2001:470:69fc:105::c85] has quit [Remote host closed the connection] 20:10 -!- kvaciral[m] [~kvaciralx@2001:470:69fc:105::17b] has quit [Remote host closed the connection] 20:10 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Remote host closed the connection] 20:10 -!- orionwl[m] [~orionwlx0@2001:470:69fc:105::80] has quit [Read error: Connection reset by peer] 20:10 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Read error: Connection reset by peer] 20:10 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Remote host closed the connection] 20:10 -!- poucatreta[m] [~poucatret@2001:470:69fc:105::20ae] has quit [Remote host closed the connection] 20:10 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has quit [Read error: Connection reset by peer] 20:10 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Remote host closed the connection] 20:11 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has quit [Remote host closed the connection] 20:11 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has quit [Remote host closed the connection] 20:11 -!- vasanth2[m] [~vasanth2m@2001:470:69fc:105::3548] has quit [Read error: Connection reset by peer] 20:11 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Write error: Connection reset by peer] 20:11 -!- orionwl[m] [~orionwlx0@2001:470:69fc:105::80] has joined #bitcoin-core-dev 20:12 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-dev 20:12 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #bitcoin-core-dev 20:12 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-dev 20:12 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #bitcoin-core-dev 20:13 -!- vasanth2[m] [~vasanth2m@2001:470:69fc:105::3548] has joined #bitcoin-core-dev 20:13 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has joined #bitcoin-core-dev 20:13 -!- kvaciral[m] [~kvaciralx@2001:470:69fc:105::17b] has joined #bitcoin-core-dev 20:13 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has joined #bitcoin-core-dev 20:13 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has joined #bitcoin-core-dev 20:13 -!- poucatreta[m] [~poucatret@2001:470:69fc:105::20ae] has joined #bitcoin-core-dev 20:13 -!- RCasatta[m] [~rcasattam@2001:470:69fc:105::c85] has joined #bitcoin-core-dev 20:13 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has joined #bitcoin-core-dev 20:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 20:14 < bitcoin-git> [bitcoin] fanquake opened pull request #22390: system: skip trying to set the locale on NetBSD (master...netbsd_dont_set_locale) https://github.com/bitcoin/bitcoin/pull/22390 20:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 20:32 -!- orionwl[m] [~orionwlx0@2001:470:69fc:105::80] has quit [Quit: node-irc says goodbye] 20:34 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Quit: node-irc says goodbye] 20:34 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Quit: node-irc says goodbye] 20:34 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: node-irc says goodbye] 20:35 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Quit: node-irc says goodbye] 20:36 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Quit: node-irc says goodbye] 20:36 -!- kvaciral[m] [~kvaciralx@2001:470:69fc:105::17b] has quit [Quit: node-irc says goodbye] 20:36 -!- vasanth2[m] [~vasanth2m@2001:470:69fc:105::3548] has quit [Quit: node-irc says goodbye] 20:36 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has quit [Quit: node-irc says goodbye] 20:36 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has quit [Quit: node-irc says goodbye] 20:36 -!- poucatreta[m] [~poucatret@2001:470:69fc:105::20ae] has quit [Quit: node-irc says goodbye] 20:36 -!- RCasatta[m] [~rcasattam@2001:470:69fc:105::c85] has quit [Quit: node-irc says goodbye] 20:36 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has quit [Quit: node-irc says goodbye] 20:37 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 252 seconds] 20:40 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-dev 20:47 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 252 seconds] 20:51 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-dev 21:05 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 21:07 -!- GIANTWORLDKEEPER [~pjetcetal@128-71-13-182.broadband.corbina.ru] has joined #bitcoin-core-dev 21:11 -!- arowser [~quassel@103.82.227.50] has quit [Quit: No Ping reply in 180 seconds.] 21:13 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 21:25 -!- instagibbs [~instagibb@119247204116.ctinets.com] has joined #bitcoin-core-dev 21:31 -!- arowser [~quassel@103.82.227.50] has quit [Quit: No Ping reply in 180 seconds.] 21:33 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 21:40 -!- arowser [~quassel@103.82.227.50] has quit [Read error: Connection reset by peer] 21:41 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 21:47 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 21:52 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 256 seconds] 21:56 -!- arowser [~quassel@103.82.227.50] has quit [Quit: No Ping reply in 180 seconds.] 21:58 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 22:06 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:31 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ddc6979b8baa...7a49fdc58115 22:31 < bitcoin-git> bitcoin/master 7fc1e14 fanquake: ci: use Ubuntu 20.04 as the default Docker container 22:31 < bitcoin-git> bitcoin/master 7a49fdc MarcoFalke: Merge bitcoin/bitcoin#22388: ci: use Ubuntu 20.04 as the default Docker co... 22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 22:31 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #22388: ci: use Ubuntu 20.04 as the default Docker container (master...ci_ubuntu_20_04) https://github.com/bitcoin/bitcoin/pull/22388 22:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 22:33 -!- arowser [~quassel@103.82.227.50] has quit [Ping timeout: 268 seconds] 22:34 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 22:45 -!- vnogueira [~vnogueira@user/vnogueira] has quit [Ping timeout: 244 seconds] 22:53 -!- arowser [~quassel@103.82.227.50] has quit [Quit: No Ping reply in 180 seconds.] 22:55 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 23:10 -!- vnogueira [~vnogueira@user/vnogueira] has joined #bitcoin-core-dev 23:14 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 23:14 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 23:15 -!- vnogueira [~vnogueira@user/vnogueira] has quit [Ping timeout: 244 seconds] 23:17 -!- arowser [~quassel@103.82.227.50] has quit [Ping timeout: 265 seconds] 23:17 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 23:28 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 23:29 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 23:35 -!- arowser [~quassel@103.82.227.50] has quit [Ping timeout: 265 seconds] 23:37 -!- arowser [~quassel@103.82.227.50] has joined #bitcoin-core-dev 23:46 -!- vnogueira [~vnogueira@user/vnogueira] has joined #bitcoin-core-dev 23:48 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has joined #bitcoin-core-dev 23:49 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 23:51 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 23:52 -!- AaronvanW [~AaronvanW@2806:2f0:90a1:5d4d:5c29:724b:fcd1:6a53] has quit [Ping timeout: 240 seconds] 23:52 -!- jeremyru_ [~jeremyrub@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev 23:53 -!- arowser_ [~quassel@103.82.227.50] has joined #bitcoin-core-dev 23:54 -!- arowser [~quassel@103.82.227.50] has quit [Ping timeout: 272 seconds] 23:55 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer] 23:55 -!- emcy_ [~emcy@user/emcy] has joined #bitcoin-core-dev --- Log closed Fri Jul 02 00:00:54 2021