19:00:08 <wumpus> #startmeeting 19:00:21 <provoostenator> hi 19:00:26 <hebasto> hi 19:00:30 <achow101> hi 19:00:35 <meshcollider> hi 19:00:37 <ariard> hi 19:00:43 <wumpus> hi 19:00:45 <michaelfolkson> hi 19:00:46 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow 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:00:48 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus 19:00:50 <amiti> hi 19:00:57 <lightlike> hi 19:00:58 <jeremyrubin> hallo 19:01:00 <glozow> hi 19:01:10 <jnewbery> hi 19:01:11 <gleb> hi 19:01:22 <jonatack> hi 19:01:24 <wumpus> two porosed meeting topics (http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt) : short info/update on the "Bitcoin Core Code Signing Association" status. (jonasschnelli) 0.21 backports and 0.21.1rc1 (achow101) 19:01:48 <wumpus> any last minute topic suggestions? 19:02:30 <wumpus> #topic High priority for review 19:02:43 <jonasschnelli> hi 19:02:44 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 10 blockers, 2 chasing concept ACK right now 19:03:34 <wumpus> anyone have suggestions of something to add/remove or that is ready for merge? 19:03:50 <gleb> I was thinking whether to put #21515 in high-prio at this point. The code is pretty much ready from my side (although ariard promised to contribute fuzzing), but at the same time we probably need to merge minisketch first separately 19:03:53 <gribble> https://github.com/bitcoin/bitcoin/issues/21515 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs ÷ Pull Request #21515 ÷ bitcoin/bitcoin ÷ GitHub 19:04:03 <gleb> For which I expected sipa would be here and say a word :) 19:04:12 <sipa> a word 19:04:15 <gleb> haha 19:04:34 <sipa> i can PR minisketch as a subtree if that's what people want 19:04:47 <wumpus> if it is blocked by something else i'm not sure it makes sense to add to blockers 19:05:20 <jonatack> #19521 seems ready 19:05:24 <gribble> https://github.com/bitcoin/bitcoin/issues/19521 | Coinstats Index by fjahr ÷ Pull Request #19521 ÷ bitcoin/bitcoin ÷ GitHub 19:05:36 <sipa> i believe we're also going to do a review club on the c++ minisketch code; perhaps we want that first 19:05:44 <wumpus> jonatack: thanks, good to know 19:05:46 <gleb> sipa: is that scheduled? 19:05:48 <ariard> yeah let's PR minisketch first, will make erlay review easier 19:06:10 <glozow> +1 19:06:32 <wumpus> okay let's do that first then 19:06:34 <gleb> alright, then the plan is review club -> minisketch pr/review -> erlay pr review. 19:06:44 <wumpus> sgtm 19:06:50 <gleb> In the meanwhile people are welcome to start reviewing erlay 21515 :) 19:07:07 <ariard> erlay pr review can advance a bit, we should figure out testing on a signet :) 19:07:08 <sipa> gleb: jnewbery just ask me to do one on the 21st 19:07:17 <sipa> why signet? 19:07:19 <gleb> that's soon, great. 19:07:58 <provoostenator> Signet has a 1 byte mempool... 19:08:11 <provoostenator> Mainnet seems more interesting for erlay 19:08:17 <provoostenator> (for reckless devs) 19:08:25 <sipa> indeed 19:08:36 <ariard> oh can't generate a bigger mempool on the default signet 19:08:48 <lightlike> doesn't help much though if you are the only one running it on mainnet :-) 19:08:52 <provoostenator> Well signet is centralized so it could be made bigger 19:08:53 <gleb> I was running couple of my erlay nodes at mainnet a while ago, would do again. 19:08:59 <ariard> yeah but testing on mainnet you may not find other erlay peers? 19:09:15 <sipa> ariard: -connect is your friend :) 19:09:29 <gleb> sounds like something i should coordinate. 19:09:36 <ariard> sipa: ahah -connect is my friend but still need to find erlay friends 19:10:04 <ariard> something we can coordinate out of meeting for sure 19:10:14 <gleb> Perhaps by the next week meeting i can have a solid testing plan like that. 19:10:20 <jonatack> ariard: guess how we tested tor v3 and i2p ;) 19:10:27 <wumpus> i'm happy to help testing it fwiw 19:10:44 <gleb> alright, seems like we have an idea of how to proceed. 19:11:10 <wumpus> #topic Short info/update on the "Bitcoin Core Code Signing Association" status (jonasschnelli) 19:11:57 <sipa> paging jonasschnelli 19:12:04 <jonasschnelli> (have some lags) 19:12:28 <jonasschnelli> In order to obtain new certificates for code signing, we need to register the Bitcoin Core Code Signing Association in switzerland 19:12:44 <jonasschnelli> which requires some paperwork and yearly chores 19:12:55 <jonasschnelli> (like tax declaration, financial statements, etc.) 19:13:04 <achow101> For context, the CA/B forum changed the requirements for organization validation for code signing certificates. So we need to register the association with government authority in order to get a certificate issued. 19:13:11 <jonasschnelli> The Bitcoin Association Switzerland is now helping me to set this up... 19:13:16 <sipa> What is CA/B ? 19:13:27 <achow101> Certificate Authority / Browser forum 19:13:29 <jonasschnelli> but since gov is necesarry for that part,..it might take awhile 19:13:44 <achow101> that's the group that sets the rules for CAs and other related things 19:13:44 <sipa> jonasschnelli: it's swiss government, aren't they super fast :) 19:13:54 <jonasschnelli> no in everything. :) 19:13:58 <jonasschnelli> *not 19:14:08 <sipa> ok, what's a realistic timeline? 19:14:16 <jonasschnelli> I don't have an estimate... and without the proper registration, we won't get new window certificates 19:14:21 <jonasschnelli> (unsure about mac) 19:14:36 <jonasschnelli> As soon as the lawyer take on the job, I think i can get an est. 19:14:39 <achow101> I expect Apple will now have similar requirements as they must adhere to the same rules to remain a CA 19:14:40 <jonasschnelli> probably 2-3 month, 19:14:54 <jonasschnelli> achow101: very likely 19:15:15 <sipa> could we try to do this in another jurisdiction? 19:15:21 <sipa> where it's faster 19:15:35 <achow101> An alternative I am beginning to explore now is to setup a LLC in the US, But I am not sure if that will be any faster 19:15:48 <jonasschnelli> maybe it is also 3-4 weeks... as said. Just a wild guess right now 19:16:06 <BlueMatt> achow101: you should be able to get an LLC in most states in a few days, max 19:16:19 <BlueMatt> I know new york is like well under a week, maybe 1 biz day 19:16:24 <jonasschnelli> a US LLC would be an option. 19:16:25 <achow101> There are additional requirements for newly created organizations too... 19:16:54 <roconnor> how about buying a shelf company. :D 19:16:57 <jonasschnelli> If we want, we could do both (as sort of a redundancy) 19:17:06 <sipa> a shelf company or a shell company? 19:17:27 <provoostenator> A SPAC? 19:17:29 <sipa> i like switzerland as a jurisdiction though, for things like this 19:17:35 <jonasschnelli> me 2 19:17:41 <provoostenator> We could raise billions for the certificate in the current market climate :-) 19:17:50 <jonasschnelli> I can probably give an update on the est in a few days 19:18:09 <sipa> this is currently a problem for signing new windows binaries, right? 19:18:14 <achow101> yes 19:18:20 <sipa> and we expect it will be a problem for apple binaries too in the near future? 19:18:21 <jonasschnelli> Things that hit the company registry, often take a few weeks (AFAIK). Because ,... hm... its a gov database. :) 19:18:22 <roconnor> https://en.wikipedia.org/wiki/Shelf_corporation 19:18:31 <achow101> sipa: yes 19:18:32 <roconnor> but I probably shouldn't be commenting since i have no idea what I'm talking about. 19:18:42 <provoostenator> But yeah, all things equal - other than some delay - I'd rather see this thing in Switserland than in the US. 19:18:50 <jonasschnelli> I could try to extend the apple certificate and see what happens... 19:19:24 <wumpus> hopefully it doesn't get retroactively revoked too 19:19:43 <jonasschnelli> That would really surprise me. 19:20:02 <jonasschnelli> I think apple isn't that restrictive (as long as it is not malware) 19:20:22 <wumpus> okay, great 19:20:30 <jonasschnelli> conclusion: we are on it. No clear esta. I'll keep you updated. 19:20:56 <wumpus> thank you! 19:20:57 <sipa> okay 19:21:01 <sipa> sounds good 19:21:33 <wumpus> #topic 0.21 backports and 0.21.1rc1 (achow101) 19:22:28 <achow101> to meet the timeline discussed previously for taproot activation, we need to have 0.21.1rc1 in the next few days 19:22:44 <jeremyrubin> \o/ 19:22:54 <achow101> the parameters have been merged into master, so all that's left is to do the backport 19:23:02 <achow101> and close out any remaining 0.21.1 backports 19:23:17 <jeremyrubin> achow101: also it's worth pointing out that backports are only required insofar as people want to signal via a backport client 19:24:04 <jeremyrubin> backports aren't blocking IMO for signaling, e.g. some miners use a recent core to gate old core patched mining nodes 19:24:07 <wumpus> isn't the backport the most important thing? at least the 0.21.x one 19:24:16 <achow101> considering that 22.0 probably won't land until after the timeout time, we need to have the backport 19:24:25 <wumpus> besides that softforks are never introduced in major versions 19:24:43 <provoostenator> n00b question, but signalling has to be done manually by miners anyway right? Or does getblocktemplate do that automagically? 19:24:44 <jeremyrubin> true, I just mean that the backports (given the minactivetime) can happen anytime before that height quite safely 19:25:03 <jeremyrubin> unless we think that miners will do signaling via backported clients 19:25:18 <jeremyrubin> But I agree we should get them out promptly, just that I don't perceive it as blocking 19:25:27 <jeremyrubin> but others can disagree with that assessment 19:25:31 <achow101> there are currently 5 things tagged for backport (or as backport) to 0.21. 19:25:47 <achow101> 3 are as backport, 2 are for backport 19:25:50 <harding> provoostenator: GBT does it automatically; I tested that was working as part of my review of 21377 (on regtest with vbparams). 19:26:14 <harding> provoostenator: but minres will probably do it manually anyway. 19:26:14 <provoostenator> Ah you're right, I do remember regtest signalling, just nevered inspected how that works. 19:26:17 <hebasto> wumpus: is it assumed to update translations for 0.21.1? 19:26:55 <jonatack> note bene, i'd suggest adding #21644 for backport, it fixes a bug in v0.21 19:26:57 <gribble> https://github.com/bitcoin/bitcoin/issues/21644 | p2p, bugfix: use NetPermissions::HasFlag() in CConnman::Bind() by jonatack ÷ Pull Request #21644 ÷ bitcoin/bitcoin ÷ GitHub 19:27:25 <wumpus> hebasto: yes, unless there is a reason for skipping that? 19:27:42 <provoostenator> Anyway I would much miners to use the 0.21.1 release as soon as it comes out rather than "oh yeah, I'll remember to upgrade later". 19:27:54 <provoostenator> So not blocking, but we should not wait too long either. 19:28:29 <hebasto> wumpus: no reasons for skipping at all :) just want to restore wiped out Ukrainian translation 19:28:37 <jeremyrubin> provoostenator: +1 -- just note that the "later" is by minactivationheight 19:29:00 <wumpus> hebasto: makes sense! 19:29:17 <achow101> I think it would be reasonable to merge the current backports and leave the rest tagged for 0.21.1 for 0.21.2? 19:29:38 <wumpus> achow101: would agree, unless they are critical bugs of course 19:29:56 <wumpus> but we can definitely leave 'would be nice' stuff for 0.21.2 19:30:07 <sipa> makes sense 19:30:10 <provoostenator> There's a Boost dependency URL change PR, which should probably go in too 19:30:25 <provoostenator> #21662 19:30:27 <gribble> https://github.com/bitcoin/bitcoin/issues/21662 | build: update Boost download URL by fdoving ÷ Pull Request #21662 ÷ bitcoin/bitcoin ÷ GitHub 19:30:34 <hebasto> ^ agree 19:31:59 <wumpus> any other topics? 19:32:45 <wumpus> #endmeeting