19:00:11 <laanwj> #startmeeting 
19: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.
19:00:12 <core-meetingbot> Available commands: action commands idea info link nick
19:00:35 <hebasto> hi
19: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
19:00:46 <laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:54 <jarolrod> hi
19:01:08 <ajonas> Hi
19:01:19 <ariard> hi
19:01:20 <meshcollider> Hi
19:01:23 <michaelfolkson> hi
19:01:23 <jonatack> hi
19:01:28 <gleb> hi
19:01:29 <luke-jr> #proposedmeetingtopic When it's okay to auto-update across softfork enforcement
19:01:35 <neha> hi
19:01:47 <lightlike> hi
19:01:49 <laanwj> welcome to the weekly meeting; there have been no proposed meeting topics for this week, any last minute ones?
19:02:05 <neha> #proposedmeetingtopic Training to rotate release responsibility
19:02:26 <luke-jr> laanwj: see ^
19:02:40 <luke-jr> err, ^ ^ too ;)
19:02:57 <laanwj> yes!
19:03:03 <laanwj> #topic 22.0 release
19:03:03 <core-meetingbot> topic: 22.0 release
19:03:22 <achow101> hi
19: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
19:04:41 <laanwj> most have to do with the build system and guix, but there's also #22122 which is P2P related
19: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
19:04:57 <laanwj> wait no not that one #22112
19:04:59 <gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
19: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
19: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
19:05:42 <achow101> should the guix stuff be kept? they're both still drafts
19:05:54 <laanwj> the guix stuff is needed to do a release
19:06:02 <laanwj> not sure why they're draft labeled
19:06:42 <jonasschnelli> hi
19:06:44 <jarolrod> ^ pinging dongcarl
19:06:48 <luke-jr> unless we just use gitian again
19:06:55 <achow101> #21711 is just docs and some error checking, so I don't think it is necessary
19: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
19:07:16 <laanwj> docs are very important because a lot of people are going to do guix builds for the first time
19:08:02 <hebasto> luke-jr: #22365 and guix, or multiple glibc symbol compatibility fixups and gitian
19: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
19: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
19:09:16 <luke-jr> hebasto: gitian should be fixed even if we use guix
19:09:19 <laanwj> it might be possible that bugfixes are still added for the 22.0 milestone but the feature freeze is active now
19:09:33 <dongcarl> Hi
19:09:54 <dongcarl> I’m working on the docs right now, updating for Guix 1.3.0
19:10:15 <dongcarl> Are we talking about fixing the gitian build for the symbol problem?
19: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)
19:10:47 <laanwj> dongcarl: achow101  just noted that your PRs on the 22.0 milestone are labeled as draft, which is somewhat confusing
19:11:42 <dongcarl> Yes I intend on adding more commentary to those PRs so that’s why they are still Draft
19:11:56 <dongcarl> Can mark as ready if people want, no strong opinions
19:12:11 <laanwj> it's fine imo
19:13:03 <dongcarl> Happy to answer any more questions :-)
19:13:19 <laanwj> #topic 
19:13:19 <core-meetingbot> topic:
19:13:26 <laanwj> #topic When it's okay to auto-update across softfork enforcement (luke-jr)
19:13:27 <core-meetingbot> topic: When it's okay to auto-update across softfork enforcement (luke-jr)
19: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
19: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?
19:15:26 <luke-jr> any thoughts?
19:15:42 <achow101> presumably after lock in?
19:15:46 <luke-jr> (my Core PPA is still at 0.21.0 pending some solution)
19:15:55 <luke-jr> achow101: but lock-in is just miners, not the community
19:16:05 <ariard> well we have buried deployment which are quite making assumptions on users w.r.t to softfork activation
19:16:12 <ariard> bip90
19:16:14 <luke-jr> do we then assume any opposed users would have forked off at this point?
19:16:31 <luke-jr> ariard: but those are already active, which I think is a very clear safe time to do it
19:16:49 <sipa> is it possible in snap etc to have a different channel or package name per release?
19:16:51 <luke-jr> once activation, IMO it's pretty clearly fine
19: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
19: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
19:18:21 <luke-jr> Gentoo packages have USE flags, and can be set to not install  until one is set by the user
19: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
19:18:32 <luke-jr> (which is what 0.21.1 is doing right now on the Gentoo overlay)
19:19:00 <sipa> ariard: we can't wait for buried deployment here
19: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
19:19:15 <sipa> ariard: we can't wait to release 0.21.1 packages until taproot is active, e.g.
19:19:26 <sipa> (+ probably a few years)
19:19:54 <luke-jr> yeah, simply not having packages is a problem too because most users *will* want to upgrade
19:20:02 <luke-jr> doing so should be easy
19:20:08 <sipa> and i don't think opposition is the right criterion here; nothing is being forced
19:20:17 <sipa> the question is about unaware upgrading
19:20:32 <ariard> luke-jr: gotcha it's regard with increasing the number of users with softfork enforcement logic at time of taproot activation?
19:20:37 <sipa> if people were aware of a softfork they'd active oppose, they'd stop using the snap/ppa/whatever
19:21:05 <sipa> ariard: no, it's just that people shouldn't be opted into enforcing softfork rules without being aware of it
19:21:06 <luke-jr> ariard: softforks without user enforcement are effectively failed softforks
19: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
19:22:37 <sipa> this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
19:22:57 <sipa> but this is obviously bypassed by using distro-packaged versions that do automatically update
19: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
19: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 ?
19:23:25 <sipa> ariard: i don't know what the solution is
19:23:28 <luke-jr> ariard: the node owner should be the one to make the decision
19:23:41 <ariard> luke-jr: fully agree on this!
19:24:01 <ariard> but a lot of folks might just fetch package without reading release notes
19:24:13 <sipa> that's inevitable
19:24:29 <ariard> i think so too
19:24:36 <luke-jr> ariard: bitcoincore.org's blog post has the title specific to Taproot too for example
19: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
19: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 ;)
19:25:27 <luke-jr> (MarcoFalke would have to comment on his snap stuff)
19: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
19: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?
19:27:06 <harding> debian has an opt-in setting for major release note stuff.
19:27:29 <laanwj> (and for people doing background automatic updates that wouldn't work anyway)
19:27:32 <laanwj> harding: oh good to know
19:28:05 <sipa> in a way this is a strange discussion, because i think we're effectively worrying about a rogue distribution maintainer
19: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.
19:28:19 <sipa> but if that's the case, they would obviously patch out whatever warning exists
19:28:24 <harding> s/main/mail/
19:28:59 <luke-jr> sipa: not necessarily rogue
19: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
19: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
19:29:41 <laanwj> right, it's for good reason we resisted bitcoin being part of package repositories for a long time
19:30:03 <laanwj> it's extremly unsuited to automatic updates
19: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"
19:30:32 <sipa> luke-jr: and clearly, we're of the opinion that this consensus change is going to happen
19:30:52 <sipa> so what is the warning protecting against? if this information was intentionally false, you'd also remove the warning...
19:31:11 <luke-jr> because even honest package maintainers shouldn't make the call for users ;)
19: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...
19: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
19:32:24 <sipa> that's a concern on itself
19:32:28 <ariard> s/software/softfork/g
19:32:30 <sipa> but i don't know what to do about it
19:33:12 <ariard> empower and educate users to have more of them building from the sources
19:33:23 <sipa> yeah
19:33:25 <sipa> also, good luck
19: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.)
19:33:31 <laanwj> manually downloading binaries is fine too
19:33:33 <jonatack> or download the binaries
19: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.
19: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
19:34:24 <earnestly> You really have to leave these decisions to downstream
19:34:25 <harding> (The debconf configuration wizard can prompt you to do that.)
19:34:34 <earnestly> (I.e. not worry)
19:34:38 <luke-jr> harding: but then we're patching the code
19:35:01 <luke-jr> maybe we should add a softforks=<list> upstream for future stuff like that
19:35:29 <luke-jr> earnestly: there is no downstream
19:35:30 <earnestly> That would be the best option, probably
19:35:43 <earnestly> downstream here is defined as package maintainers
19: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.
19:36:07 <luke-jr> earnestly: ie, me
19: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
19:36:29 <luke-jr> harding: won't it auto-switch?
19:36:31 <sipa> and i think this also isn't the core of the issue
19:36:32 <earnestly> luke-jr: That there is an overlap between upstream and downstream doesn't change the distinction
19:36:40 <laanwj> yes , getting the update but ending up with a non-working binary that's pretty awful for users
19:36:51 <earnestly> What you do for the distribution is related to upstream but not identical
19:36:57 <luke-jr> sipa: right; we can't stop people from patchign things out, but this provides a good solution otherwise
19:37:04 <sipa> i'm not sure
19: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.
19:37:11 <luke-jr> laanwj: GUI can prompt too?
19:37:23 <luke-jr> harding: even when the prior value is being removed? :p
19:38:01 <earnestly> sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
19:38:03 <harding> luke-jr: yeah, the different symlinks have priorities and you can set like -1 or something for never-auto-select.
19: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.
19:39:46 <harding> (Or whatever thing you as maintainer thinks needs opting in.)
19:39:52 <luke-jr> anyway, there are multiple solutions; my question was mainly when we no longer should take extra steps like these
19:40:23 <laanwj> harding: for user-facing tools that's fine, but that would go wrong if it's started from an (init) script
19:40:34 <laanwj> you can usually assume bitcoind is used as part of some stack
19: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.
19: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"
19:41:29 <earnestly> They can just remove that, there's no point playing this game
19:41:35 <sipa> it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
19:41:45 <sipa> but that's just the normal release notes/process
19: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).
19:42:25 <earnestly> (I do like luke-jr's idea of having a softfork= option though, future?)
19:43:10 <ariard> harding: if by "announce the change" you mean publicity around softfork locks in, 3 months sounds reasonable to me
19:43:17 <luke-jr> the solutions I have right now just don't perform the update until the user explicitly agrees
19: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
19:43:50 <harding> ariard: I was thinking 3 months from the BitcoinCore.org release announcement.
19:44:58 <luke-jr> but people might never see that :/
19:45:13 <laanwj> we might want ot leave some time for the last topic
19: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.
19:46:18 <luke-jr> maybe I'll just leave the extra step installing in place until November
19:47:47 <luke-jr> laanwj: I think the topic is done
19:48:09 <laanwj> #topic Training to rotate release responsibility (neha)
19:48:10 <core-meetingbot> topic: Training to rotate release responsibility (neha)
19: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?
19:49:30 <michaelfolkson> What are the responsibilities? Are there any that we wouldn't want to rotate?
19: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
19: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
19:49:55 <laanwj> but of course the best way to find out is to have someone else go through it
19:49:56 <luke-jr> neha: it's not too hard tbh
19:50:01 <luke-jr> we have good docs
19:50:10 <neha> fanquake has already volunteered, i believe
19:50:35 <laanwj> yes, unfortunately he's couldn't be at this meeting
19:50:38 <amiti> I think it's a great idea!
19:51:01 <michaelfolkson> Any downsides? Presumably it would only rotate around maintainers?
19:51:12 <achow101> wouldn't this require giving more people write access and upload access to bitcoincore.org?
19:51:36 <jonatack> ^ i would have thought that was a maintainer role (more or less by definition)
19: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)
19:52:08 <sipa> laanwj: agree, but also feel free to ask if you see places where help is useful
19:52:12 <luke-jr> there's going to be one more 0.20.x before 22.0, right?
19:52:21 <achow101> we could trial with 0.20.2
19:52:23 <laanwj> achow101: sure, or they could do everything except the upload
19:52:52 <ariard> maybe we could have more distribution mirrors instead of one big official one like bitcoincore.org
19:53:02 <luke-jr> michaelfolkson: NACK treating maintainers special
19:53:04 <laanwj> there was another idea for the longer run to have bitcoincore.org build the binaries itself (it's deterministic after all)
19:53:42 <luke-jr> laanwj: not sure we gain anything from that?
19:53:44 <laanwj> then the maintainer would only have to do a tag, and trigger it, i guess
19:53:51 <laanwj> luke-jr: no one needs to upload binaries
19: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...
19:54:02 <harding> The deterministic build idea is already how we handle the website content basically, so it's not too strange.
19:54:09 <achow101> laanwj: still have upload sha256sums
19:54:13 <laanwj> seems beter than giving multiple people write aceess to the /bin
19:54:18 <achow101> *signed sha256sums
19:54:27 <laanwj> achow101: depends on how we're going to do the signing
19:54:32 <luke-jr> laanwj: just check that uploads have N signers
19:54:46 <luke-jr> we would want that even if it built itself
19:54:55 <laanwj> achow101: but yeah, having that happen on the website is a bad idea :)
19:55:11 <harding> If N people sign the torrent hash, then the website could download that directly.
19: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?
19:55:24 <laanwj> in any case the uploading is the least interesting part
19:55:50 <laanwj> the rest of the release process is where more work is
19:55:54 <laanwj> neha: sgtm
19:55:57 <luke-jr> neha: it won't make sense to do it once we get to November
19:56:03 <luke-jr> since it doesn't have Taproot
19:56:14 <achow101> 0.20.2 is ready to go except for release notes
19:56:26 <luke-jr> and rc cycle
19:56:34 <laanwj> yes
19: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?
19:57:04 <luke-jr> sdaftuar: we really should be moving to a setup where many of us sign those
19: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.
19:57:09 <achow101> luke-jr: we already have 0.20.2rc2 since early june
19:57:10 <sdaftuar> luke-jr: sure, but i assume we're not there yet?
19:57:11 <neha> sdaftuar: i think part of the goal is to achieve fault tolerance, so ideally yes
19: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
19:57:17 <luke-jr> achow101: has anyone tested it?
19:57:22 <laanwj> sdaftuar: it should be multi-signed i think
19:57:25 <luke-jr> sdaftuar: it's just a matter of doing it
19:57:38 <laanwj> sdaftuar: i think that's dongcarl's thing too, the same sha256sum is signed by every builder
19:57:47 <laanwj> so the signatures can be concatenated
19:57:52 <luke-jr> someone just has to copy/paste others' signatures into the file
19:57:53 <achow101> luke-jr: probably not, but I expect that's normal for minor releases for old versions
19: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
19:58:29 <sipa> i think there is a conflation here
19:58:32 <luke-jr> so long as laanwj's signature is included, I expect it will be smooth
19:58:49 <laanwj> well i can do the signing and upload for 0.20.2 no problem
19:58:52 <sipa> guix attestations only prove that a particular source code corresponds to a certain binary
19:59:12 <sipa> an auto-building site doesn't need that if it does a guix build itself
19:59:18 <sipa> the question is what it should be building
19:59:34 <laanwj> sipa: the idea is that people who download the binary have something to verify
19: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
19:59:54 <laanwj> sipa: currently the sha256sums.asc is signed with my GPG key, someone else cannot do that
20:00:15 <laanwj> so the idea is what to do instead for future releases
20:00:22 <sipa> oh ok, we're not talking about using guix attestations to instruct the site what to publish?
20:00:29 <sipa> just something similar
20: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.
20:01:34 <luke-jr> :|
20:01:54 <luke-jr> harding: or perhaps verifying via gitian.sigs as ideal, but.. unlikely
20:01:56 <ariard> harding: yes though maybe we can hope that the 1% doing it will serve as canary to alert the others ?
20: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
20:02:04 <laanwj> but yes it's kind of a hassle that so many instructions have my gpg key hardcoded now for validation
20: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.
20: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)
20:02:40 <luke-jr> harding: the combined file would still verify with laanwj's key
20:02:40 <sipa> of course
20:02:42 <harding> The BitcoinCore.org download page has shasum verification instructinos on it, so we could mention any alternative.
20:03:00 <laanwj> harding: makes sense to me
20: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.
20:04:06 <laanwj> harding: thanks!
20:04:10 <luke-jr> fwiw I wrote this a while back https://medium.com/@lukedashjr/how-to-securely-install-bitcoin-9bfeca7d3b2a?readmore=1
20:04:22 <luke-jr> but it's designed around gitian sigs, so will need a revision for guoix
20:04:23 <luke-jr> guix*
20:04:40 <achow101> I think a better test run would be 0.21.2 since we haven't started on that
20:04:52 <dongcarl> is here if anyone has questions
20:05:05 <luke-jr> achow101: yeah, but no point training users on a gitian-specific verification if we move to guix
20:05:20 <laanwj> i think it's time to end the meeting, we can continue this topic some other time if needed
20:05:44 <laanwj> #endmeeting