19:00:59 <wumpus> #startmeeting 
19:00:59 <core-meetingbot> Meeting started Thu Jan  7 19:00:59 2021 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:59 <core-meetingbot> Available commands: action commands idea info link nick
19:01:05 <jonasschnelli> hi
19:01:07 <MarcoFalke> hi
19:01:16 <sipa> hi
19:01:27 <hebasto> hi
19:01:37 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
19:01:38 <achow101> hi
19:01:39 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:40 <jonasschnelli> first meeting in 2021 \o
19:01:51 <jb55> hi
19:02:07 <wumpus> i thought it's still december 2020 :)
19:02:21 <MarcoFalke> wumpus: happy new year :)
19:02:27 <jb55> eternal december
19:02:30 <wumpus> no proposed meeting topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:02:32 <sipa> it is March 313th
19:02:39 <nehan> hi! happy new year
19:02:40 <wumpus> MarcoFalke: thank you, same to you!
19:02:45 <Murch> hi
19:03:01 <MarcoFalke> #proposedmeetingtopic 0.21.0 release
19:03:03 <jamesob> hi
19:03:07 <wumpus> any last minute meeting topic suggestions?
19:03:28 <wumpus> #topic High priority for review
19:03:28 <core-meetingbot> topic: High priority for review
19:03:43 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  10 blockers, 1 chasing concept ACK
19:04:13 <luke-jr> hi
19:04:19 <jonatack> hi
19:04:23 <wumpus> anything to add/remove, or almost ready to merge?
19:05:41 <promag> #20017 for concept ack
19:05:44 <gribble> https://github.com/bitcoin/bitcoin/issues/20017 | rpc: Add RPCContext by promag · Pull Request #20017 · bitcoin/bitcoin · GitHub
19:05:51 <fjahr> hi
19:06:31 <wumpus> promag: added
19:06:53 <wumpus> anything else?
19:07:18 <jnewbery> hi
19:07:37 <ajonas> hi
19:08:01 <wumpus> thanks sipa, good to see more review on #19806
19:08:05 <gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
19:08:23 <jamesob> yup, thanks sipa
19:08:43 <jamesob> will look at, at least, the tsan error tonight
19:09:12 <wumpus> #topic 0.21.0 release (MarcoFalke)
19:09:13 <core-meetingbot> topic: 0.21.0 release (MarcoFalke)
19:09:42 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/45
19:10:13 <sipa> so, #20849 and/or #20852, and rc6?
19:10:15 <gribble> https://github.com/bitcoin/bitcoin/issues/20849 | net: disconnect peers by address without using a subnet by vasild · Pull Request #20849 · bitcoin/bitcoin · GitHub
19:10:17 <gribble> https://github.com/bitcoin/bitcoin/issues/20852 | net: allow CSubNet of non-IP networks by vasild · Pull Request #20852 · bitcoin/bitcoin · GitHub
19:10:18 <wumpus> let's at least wait a week or two before tagging final, I'm sure if people start testing issues will come up
19:10:24 <MarcoFalke> sipa: Or none of them
19:10:32 <jnewbery> wumpus: can we move #20557 to high priority bug fixes? PR #16702 broke some aspects of addrman deserialization and it'd be nice to fix them
19:10:34 <gribble> https://github.com/bitcoin/bitcoin/issues/20557 | addrman: Fix new table bucketing during unserialization by jnewbery · Pull Request #20557 · bitcoin/bitcoin · GitHub
19:10:38 <gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub
19:10:45 <wumpus> I'm confused about #20849
19:10:57 <gribble> https://github.com/bitcoin/bitcoin/issues/20849 | net: disconnect peers by address without using a subnet by vasild · Pull Request #20849 · bitcoin/bitcoin · GitHub
19:11:06 <MarcoFalke> wumpus: It is a smaller-impact fix than 20852
19:11:08 <wumpus> (but I posted that on the issue)
19:11:46 <wumpus> MarcoFalke: ok, yes that's true
19:11:51 <sipa> wumpus: 20852 is the more general fix, but perhaps more invasive than what we want for 0.21
19:11:59 <MarcoFalke> There havne't been any blocker issues  reported since rc3
19:12:02 <wumpus> but using a diffrent solution for 0.21 is going to make future backports harder
19:12:08 <MarcoFalke> rc4 and rc5 only contained test and doc fixups, IIRC
19:12:34 <MarcoFalke> so I think we can also tag rc5 as -final
19:12:48 <wumpus> so I'd prefer to just bite the bullet and do #20852 on both master and 0.21  (maybe 0.21.1?)
19:12:50 <gribble> https://github.com/bitcoin/bitcoin/issues/20852 | net: allow CSubNet of non-IP networks by vasild · Pull Request #20852 · bitcoin/bitcoin · GitHub
19:12:51 <sipa> not being able to disconnect misbehaving tor nodes seems like something worth addressing
19:13:07 <wumpus> yes, rc4 and rc5 were doc only
19:13:23 <wumpus> apart from the torv2->torv3 signet seed change
19:15:10 <wumpus> MarcoFalke: ofc, assuming nothing comes up with rc5
19:15:53 <wumpus> so we could make it depend on that, if a rc6 is needed for another reason, include, say, 20852
19:16:52 <wumpus> ok, this starts to be a monologue, any other topics?
19:17:22 <MarcoFalke> sipa: *outbound tor nodes
19:17:43 <MarcoFalke> sipa: Delaying the release will also delay already included bugfixes that exist in previous releases
19:17:50 <MarcoFalke> So I think it is a trade-off
19:18:00 <sipa> ?
19:18:29 <wumpus> I don't think in itself it warrants delaying the release
19:18:54 <sipa> ok
19:21:31 <wumpus> of course we could merge it and do rc6 right now but that'd not be very mindful of people that just started testing rc5, better to stick with a rc per week at most
19:22:42 <MarcoFalke> rc5 pretty much only needs testing on macOS
19:22:56 <MarcoFalke> apart from the signature, nothing changed code-wise
19:23:04 <luke-jr> could always just go 0.21.1 sooner too
19:23:08 <wumpus> if there's no other topics, that's a short first meeting of the year
19:23:17 <wumpus> MarcoFalke: luke-jr: agree
19:23:19 <MarcoFalke> luke-jr: 0.21.0.1 ;)
19:23:24 <jonasschnelli> <MarcoFalke> rc5 pretty much only needs testing on macOS
19:23:26 <jonasschnelli> ^ why?
19:23:35 <MarcoFalke> jonasschnelli: Only documentation fixups were merged
19:23:39 <luke-jr> MarcoFalke: no reason for that mess :P
19:23:49 <MarcoFalke> (compared to rc3)
19:23:53 <jonasschnelli> It was testable on macOS before rc5
19:23:53 <luke-jr> oh, I have a possible topic
19:24:05 <luke-jr> Debian wants to include bitcoin core again
19:24:25 <wumpus> #topic Debian package (luke-jr)
19:24:25 <core-meetingbot> topic: Debian package (luke-jr)
19:24:27 <MarcoFalke> fedora as well
19:24:28 <luke-jr> does anyone want to possibly maintain whatever version they release, for their maintenance period?
19:24:34 <luke-jr> (IIRC 3 years?)
19:25:02 <jonasschnelli> thats about 6 version steps?!...
19:25:07 <luke-jr> they're also using system leveldb, which is another issue to resolve - not sure what they're going to do in that regard
19:25:13 <luke-jr> jonasschnelli: yeah :/
19:25:19 <wumpus> I don't particularly feel like repeating this discussion, we've had it before and I don't think anything changed?
19:25:23 <jonasschnelli> Smells after troubles
19:25:34 <luke-jr> wumpus: just thought I'd mention it in case anyone is interested :p
19:25:49 <wumpus> FWIW, I still think it's a bad idea
19:26:17 <luke-jr> IF they resolve the leveldb side, and if someone is willing to maintain it that long… not sure there's any other objections to have?
19:26:27 <wumpus> but so is auto-updating bitcoin core in general
19:26:32 <luke-jr> hmm
19:26:44 <luke-jr> but we already allow auto-updates via Snap etc
19:27:05 <wumpus> (defiitely between major releases, or when there's a softfork, or policy changes, or...)
19:27:23 <sipa> oh i have a topic: how reasonable is it for us to produce a docker image inside gitian?
19:27:38 <MarcoFalke> It is not auto update, only update on `apt update`, no?
19:27:49 <luke-jr> MarcoFalke: Debian supports auto-upgrade optionally
19:27:58 <sipa> MarcoFalke: i don't think that's a meaningful difference
19:28:13 <sipa> it's not like you're going to review all the things that get changed when updating
19:28:22 <sipa> also, auto-update can be enabled
19:28:23 <luke-jr> If we are auto-updating via official Snaps, I don't think we can make that objection
19:28:31 <wumpus> right, the point is that bitcoin needs *special* review compared to upgrading other software
19:28:37 <MarcoFalke> I do review them (at least of the important packages)
19:29:05 <luke-jr> MarcoFalke: can you confirm the Snap situation?
19:29:21 <MarcoFalke> luke-jr: Yes, there is an auto-update footgun
19:29:26 <MarcoFalke> I think it is optional
19:29:56 <MarcoFalke> Also, there are tracks for previous releaes
19:30:06 <sipa> regardless, i don't think we're ready for 3-year maintenance
19:30:14 <MarcoFalke> So even with auto-update you can say "only auto update on the 0.19 branch"
19:30:16 <jonasschnelli> yes
19:30:42 <MarcoFalke> (no one uses the tracks, though)
19:30:48 <wumpus> I definitely have no interest in maintaining a 3-year old release
19:31:40 <jonasschnelli> plus core is very easy to "install" on most systems thanks to the static binaries
19:31:50 <wumpus> maintaining he releases we do is already overwhelming enough sometimes
19:32:04 <luke-jr> anyway, I guess it's moot unless someone wants to maintain for 3 years..
19:32:04 <MarcoFalke> sipa: Creating a docker image should be trivial. Not sure if it is deterministic, though.
19:32:04 <luke-jr> I've done it before, but having no funding, I'm not too inclinded to repeat it
19:32:29 <jonasschnelli> no fun(ding)
19:32:53 <wumpus> it's definitely a job that would require funding, no one is going to do it for fun :)
19:33:25 <wumpus> if there are really companies that want to run a three-year old stable, make them fund it
19:33:30 <sipa> MarcoFalke: i read that docker images can be identified by their hash, so if creating one is deterministic, that may be something people are interested in having
19:33:39 <sipa> (i've never used docker myself, though)
19:33:48 <wumpus> okok docker
19:33:54 <wumpus> #topic Docker image generation in gitian
19:33:54 <core-meetingbot> topic: Docker image generation in gitian
19:33:57 <MarcoFalke> sipa:  me neither
19:34:14 <achow101> in theory it is deterministic because you can specify parent image hashes
19:34:15 <jonasschnelli> sipa: why inside gitian? What are the benefits?
19:34:20 <achow101> in practice, I've had no such luck
19:34:28 <MarcoFalke> jonasschnelli: For release binaries
19:34:30 <sipa> jonasschnelli: otherwise we're relying on external people to do it?
19:34:47 <MarcoFalke> We could also just include a docker script
19:35:17 <jonasschnelli> Wait? For uploading the gitian built deterministic release binary?
19:35:37 <sipa> jonasschnelli: the idea is that we could publish a docker image hash, together with the release binaries & their hashes
19:35:38 <MarcoFalke> no, in parallel to the snap package, also offer a docker package
19:36:09 <sipa> jonasschnelli: and if that hash if verified through gitian, it means it has the same standard of review and auditability as the rest of the release process
19:36:33 <jonasschnelli> okay.. I see.
19:37:24 <sipa> i'm just mentioning this because i saw https://github.com/bitcoin-core/packaging/issues/55, and it seems doing it inside gitian is an almost trivial change for us, apart from some initial work to set up the scripts
19:37:57 <sipa> jamesob seems to maintain a script for building docker images?
19:38:20 <MarcoFalke> I just feel that we need a docker expert to pull this off. Also, it would be sad if that blocked progress on guix
19:38:38 <luke-jr> hmm, true
19:38:42 <wumpus> so the question then would be: for what platforms?  we can't quite do {docker,tar.gz} for all supported platforms
19:38:54 <sipa> wumpus: good point
19:39:03 <sipa> do people do docker for more than just x86_64 linux?
19:39:20 <luke-jr> can we add a file to the .tar.gz to run it as a docker?
19:39:27 <MarcoFalke> sipa: Also arm
19:39:33 <MarcoFalke> wumpus: Which is why I'd rather publish a docker script
19:39:42 <wumpus> i'd be surprised if it wouldn't be used on arm64
19:39:51 <wumpus> as for the other platforms, probably rarely
19:40:02 <sipa> MarcoFalke: okay, i'm not all that familiar with the different mechanics
19:40:04 <wumpus> MarcoFalke: agree, it's the same binaries anyhow packaged differently
19:40:39 <MarcoFalke> sipa: the docker script builds the docker image, so it is just one step less to do for us
19:40:58 <sipa> and your suggestion would be to have the script inside the release tgz?
19:41:09 <MarcoFalke> jup
19:41:14 <sipa> seems reasonable
19:41:45 <sipa> (plus having some sort of CI to see if the script works?)
19:42:50 <wumpus> yes
19:42:51 <MarcoFalke> hmm, maybe the idea isn't that good because we couldn't reference the gitian built binaries in the script
19:43:24 <luke-jr> why not?
19:43:38 <wumpus> as i see it it'd convert a set of gitian-built binaries to a docker image, deterministically
19:44:04 <MarcoFalke> ok, so the user has to provide the binaries. fair enough
19:44:20 <luke-jr> the binaries are right there with the script, no?
19:44:39 <sipa> if it's deterministic to do so even in a fairly uncontrolled environment, that'd still permit publishing the resulting hashes
19:44:40 <dongcarl> looks back at `guix pack --format=docker`
19:44:48 <sipa> dongcarl: o?
19:44:50 <wumpus> luke-jr: oh... of course
19:45:03 <wumpus> luke-jr: it'd be shipped with the binary tarball, not the source one
19:45:08 <luke-jr> right
19:45:11 <sipa> right
19:45:19 <luke-jr> (well, part of source too I assume)
19:45:39 <wumpus> right it has to come from somewhere
19:46:08 <wumpus> dongcarl: hah!
19:46:33 <dongcarl> still trying to find the goal of this discussion
19:47:09 <sipa> dongcarl: it seems docker is popular (i don't know why, i've never used it), so it'd be great if we have a direct path from our release process to something people can run directly
19:47:32 <wumpus> yes, for example btcpayserver uses docker IIRC?
19:47:42 <dongcarl> sipa: Stupid question: why aren't the release binaries enough for this?
19:48:04 <jonatack> yes iirc dockre is btcpay's recommended installation method
19:48:15 <achow101> dongcarl: people are just using docker images published by other people that contain the release binaries. afaiu, the point is for us to publish those images instead
19:48:18 <sipa> dongcarl: that requires people to build their own image from it, using a script they get from... somewhere?
19:48:36 <sipa> MarcoFalke has a point that just making publishing the script as part of the process may be enough
19:49:00 <wumpus> it would use the same release binaries, just package them
19:49:02 <sipa> i think publishing the image directly would be slightly more convenient (and also allow others to build on top of it, i think?)
19:49:03 <achow101> in the end, it's still our release binaries, but the images themselves may contain other stuff that could be malicious. hence the desire for the developers to create an official one
19:49:46 <MarcoFalke> sipa:  The image can still be published, even if we include only the script in the release
19:49:57 <sipa> MarcoFalke: if it's deterministic, yes
19:50:29 <jonatack> https://docs.btcpayserver.org/Docker/
19:50:46 <sipa> but i somehow expect that if a guix pack --format=docker exists... that'd be pretty likely to be deterministic ;)
19:51:37 <sipa> there isn't so much to discuss here i guess, a lot depends on what work people are willing to put into it
19:51:43 <sipa> but it's good to get an idea about the sentiment
19:51:50 <dongcarl> I think the only risk is Docker's determinism
19:51:55 <dongcarl> The actual Dockerfile will be like... 4 lines?
19:52:21 <MarcoFalke> dongcarl: People will ask for features, so the file surely will grow
19:52:54 <sipa> jamesob's Dockerfile seems quite a bit longer: https://github.com/jamesob/docker-bitcoind/blob/master/Dockerfile
19:52:55 <wumpus> i guess it's bascially glibc and the bitcoind binary?
19:53:14 <wumpus> if we'd link bitcoind statically with musl libc there wouldn't even be dependency on that
19:53:28 <luke-jr> MarcoFalke: what features are even possible?
19:53:35 <MarcoFalke> "I want to supply the cookie file from outside"
19:53:47 <sipa> "I want it to mine signet!"
19:53:58 <luke-jr> that's not runtime?
19:54:26 <MarcoFalke> "I want to run the gui in docker"
19:54:31 <wumpus> a docker image with bitcoind that's, just bitcoind :)
19:54:31 <dongcarl> I'm not entirely sure I see the point in this, let them use the binaries, it's currently clear that the Dockerfiles are not official, and we can't account for all features. Is there a particular event that makes us more worried now?
19:54:50 <sipa> dongcarl: no
19:55:01 <wumpus> MarcoFalke: nah
19:55:04 <MarcoFalke> dongcarl: ppl are asking for it for years
19:55:10 <sipa> i think the dockerfiles being unofficial is suboptimal
19:55:23 <sipa> s/official/not going through the same review process/
19:55:56 <wumpus> there's plenty of ways to run sandboxed GUI (flatpak, snap) there's no point using docker for that, everyone uses docker for server components
19:56:12 <dongcarl> I think we should do what we do for the systemd services
19:56:21 <dongcarl> Make it clear that it's just for reference
19:56:54 <dongcarl> If we do add a Dockerfile I don't want it to bloat over time
19:58:03 <sipa> yes, that's a delicate line... but i think it'd be better if there was an actual dockerfile that was reviewed and known to be kept working
19:59:10 <sipa> enough on this i guess
19:59:27 <wumpus> okay, let's conclude the meeting then, thanks everyone for attending
19:59:31 <wumpus> #endmeeting