19:00:48 #startmeeting 19:00:48 Meeting started Thu Mar 19 19:00:48 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:50 hi 19:00:51 hi 19:00:52 hi 19:00:55 hi 19:00:56 hi 19:01:01 hi 19:01:02 hi 19:01:03 hi 19:01:09 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr 19:01:11 jeremyrubin lightlike emilengler jonatack hebasto jb55 19:01:23 hi 19:01:24 hi 19:02:01 one proposed topic by MarcoFalke (PGP is dead) 19:02:11 hi 19:02:35 any last minute topics for today? 19:02:40 hi 19:02:45 hi 19:02:51 hi 19:03:25 #topic High priority for review 19:03:49 I'd like to add #18247 :pray: 19:03:51 https://github.com/bitcoin/bitcoin/issues/18247 | test: Wait for both veracks in add_p2p_connection by MarcoFalke · Pull Request #18247 · bitcoin/bitcoin · GitHub 19:03:54 6 blockers, 1` bugfix, 6 chasing concept ACK 19:04:39 #16528 for hi prio 19:04:42 https://github.com/bitcoin/bitcoin/issues/16528 | Native Descriptor Wallets using DescriptorScriptPubKeyMan by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub 19:04:57 MarcoFalke: added 19:05:11 thx 19:05:31 both #17737/#17954 are pretty mature, just need few more reviews 19:05:39 https://github.com/bitcoin/bitcoin/issues/17737 | Add ChainstateManager, remove BlockManager global by jamesob · Pull Request #17737 · bitcoin/bitcoin · GitHub 19:05:48 https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub 19:06:11 Pretty much only bugfixes for 0.20 should be high prio right now (until end of month). Also refactors that are not risky can go in. Other than that, features have to wait 19:06:20 hi 19:06:42 Features can be in high prio, but they can't be merged right now 19:06:53 Okay so maybe only #17954, that's a non-risky refacto? 19:06:54 MarcoFalke: yes good point I guess, though on the other hand if people want to review features now that's ok, they just can't be merged until the split-off 19:06:56 https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub 19:07:02 right 19:07:21 wait,17954 is already on there? 19:07:36 It used to be on there 19:07:45 yes, it's already on high-prio, just raising awareness for reviewers 19:07:47 yeah, both the ones ariard mentioned are on there? 19:08:16 okay 19:09:31 #topic PGP is dead (MarcoFalke) 19:10:06 So the pgp keyservers that syncronize against each other had a ton of publicly known DOS vectors 19:10:27 Last year they got attacked and to the best of my knowledge they are all disfunctional righ tnow 19:10:45 (Bitcoin Core uses pgp to sign commits and releases) 19:10:51 so we should start hosting our own public keys? 19:11:05 That sounds like a lot of pain 19:11:10 MarcoFalke: Why 19:11:15 Only updating might be hard 19:11:25 just hosting a static keyring is pretty easy? 19:11:31 at least one was up a month ago.. 19:11:32 The public keys are in constant flux (expiry bump, new sigs, ...) 19:11:40 aj: Doesn't work with expiry 19:11:45 anecodatal data: I fetched achow101's keys yesterday with no trouble. 19:11:57 Can you fetch mine? 19:12:12 With the latest expiry dates? 19:12:24 In the docs keyserver.ubuntu.com is provided as the only keyserver that is used AFAIK 19:12:32 Therefore keys should be at least up to date on that keyserver 19:12:41 I could fetch your new expiration date key a while ago, yes 19:12:57 gpg: key BD02942421F4889F: public key "Luke Dashjr " imported 19:13:17 gpg: key 3648A882F4316B9B: public key "Marco Falke " imported 19:13:33 I haven't had any issues pushing to or fetching from keyservers in the past few months 19:13:36 looks expired, but that just means ou need to update it 19:13:52 had to push recently to update my key expriation, and fetch recently for new gitian builder keys 19:13:58 also travis constantly fetches the keys IIRC and that works fine for checking merge commits 19:14:19 wumpus: It doesn't . The check fails 19:14:26 oh, okay 19:14:45 MarcoFalke: ok, fair point, seems to not be working today. 19:14:52 did you push your key to the ubuntu server after changing the expiration date? 19:15:07 can someone send me the log i missed? 19:15:17 I can't push it anymore 19:15:20 sipa: see topic? 19:15:25 Has anyone seen this: https://keys.openpgp.org/about/news#2019-06-12-launch 19:15:27 https://github.com/bitcoin/bitcoin/issues/2019 | update bitcoinstrings.cpp and bitcoin_en.ts by Diapolo · Pull Request #2019 · bitcoin/bitcoin · GitHub 19:15:31 It seems a response to the DOS attacks 19:15:51 MarcoFalke: that's about openpgp's keyserver, not ubuntu's 19:15:55 sipa: sure min 19:15:58 Their idea is that you need to click a link in your email if you want to add a pgp user-id 19:16:10 So I think they solved the DOS issue 19:16:24 And the backend is written in rust, called hagrid 19:16:51 I could upload my key to them, so I'd suggest to use them as backup server 19:17:47 fyi https://gitlab.com/hagrid-keyserver/hagrid 19:18:57 [13bitcoin] 15MarcoFalke opened pull request #18385: contrib: Add keys.openpgp.org as backup server (06master...062003-contribPGPBackupServer) 02https://github.com/bitcoin/bitcoin/pull/18385 19:19:23 sipa: https://0bin.net/paste/13Am+SmhBjfvE4Sc#Dv2VoZfkzSFyIrzjX2flur+BJ31gPWQ9HjHPRlA688i 19:19:28 thanks 19:19:44 An alternative solution is keybase, but they require an account 19:19:46 MarcoFalke: adding a backup server SGTM 19:20:03 MarcoFalke: i'd be very sad if we need to rely on a shitcoin-promoting system like that... 19:20:07 MarcoFalke: do they sync with the other keyservers? or does everyone need to upload their keys again 19:20:12 sipa: Me too 19:20:25 where's the altcoin promotion? :x 19:20:28 achow101: They don't sync, which is the only downside 19:20:35 Ideally c-i's would run their own keyservers as caches, similar to debian/ubuntu packages. 19:20:39 achow101: Because of the verify step by email 19:20:57 MarcoFalke: sounds like a pretty big downside :x 19:21:37 ah, it's some handwavy email identity-based-encryption thingy? 19:21:54 luke-jr: At least they are not DOSable 19:22:26 everything is DOSable 19:22:39 apparently the old gpg server code that was used was written in OCaml, with nobody knowing how it worked... 19:22:44 in the same sense that the historic infrastructure was DOSable 19:23:32 sipa: the annoying bits are the GDPR stuff 19:23:43 The new one seems at least maintained 19:23:44 which I doubt is actually compliant 19:24:00 why can't we host/mirror the keys at bitcoincore.org 19:24:13 emilengler:too much work to maintain it 19:24:24 emilengler: They need to be updated all the time 19:25:06 emilengler: what's the gain? 19:25:11 (at least for all the gitian keys; just a keyring with the maintainer keys wouldn't be too bad) 19:25:25 non-sync bitcoincore.org key hosting isn't much better than non-sync keys.openpgp.org ? 19:25:40 luke-jr: We could directly manage it if it gets down or something 19:25:58 then just point a DNS record at random third-party servers for now? 19:26:09 keys.bitcoincore.org CNAME ubuntu domain 19:26:20 and if that's down for a long while, we can point it elsewhere 19:26:44 that's a cool idea 19:27:37 it could be changed faster than the keyserver in the repository at least (esp all the branches) 19:27:49 That shifts control from submitting a pull request to pinging somebody personally... 19:28:41 Though I guess a cname could also always be changed with a pull request. 19:29:01 Ideally we wouldn't have to change anything 19:30:04 is there any keyserver software that can just sync/cache a whitelist of keys? 19:30:06 ideally yes, maybe it's a temporary problem and we can get the ubuntu keyserver to accept pushes again somehow 19:31:00 I understand if they want to protect against DoS but it can't be intentional to not allow updates at all anymore 19:32:50 https://keyserver.ubuntu.com/ also has a form to submit keys through the web interface FWIW 19:33:06 and does that interface work? 19:33:08 That failed for me 19:33:12 Would people (or maybe maintainers) object if I upload the keys to keys.openpgp.org as a backup and then request a confirmation email on their behalf? 19:33:16 oh, you trid that too? 19:34:05 no, of course not, though it's annoying that we have to keep changing keyservers, I don't think we've been using the ubuntu one for that long 19:34:05 jup 19:34:52 fine with me 19:34:59 Several folks offered to help out by "running a Hagrid server instance". We very much appreciate the offer, but we will probably never have an "open" federation model like SKS, where everyone can run an instance and become part of a "pool" 19:35:08 I don't understand what this is attempting to accomplish. 19:35:10 Yes, I changed to the ubuntu one last March, because the previous was down 19:35:59 cfields: There a no pools anymore, it is just one point/website for the keystorage 19:36:11 if the ubuntu keyserver isn't fixed, we're all going to have this problem when we need to update our key expiration 19:37:07 What's the number for the ubuntu keyserver costumer support? 19:37:47 their statistics still show updated keys https://keyserver.ubuntu.com/pks/lookup?op=stats 19:38:21 oh wait there's a gap from 2020-01-06 to... today 19:40:32 any other topics? 19:41:03 short question: are we in feature freeze now? 19:41:13 Yea 19:41:20 yes 19:41:39 ok! 19:42:22 this is also marked in #17432 FWIW 19:42:23 https://github.com/bitcoin/bitcoin/issues/17432 | Release schedule for 0.20.0 · Issue #17432 · bitcoin/bitcoin · GitHub 19:42:52 Guess we should move the release notes to the wiki soon as well 19:43:26 good idea! 19:43:57 #endmeeting