14:00:07 <achow101> #startmeeting 14:00:09 <sdaftuar> hi 14:00:09 <glozow> hi 14:00:12 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi theStack TheCharlatan vasild 14:00:13 <josie> hi 14:00:14 <furszy> hi 14:00:15 <darosior> Hi 14:00:15 <instagibbs> hi 14:00:16 <TheCharlatan> hi 14:00:18 <hebasto> hi 14:00:21 <maxedw> hi 14:00:22 <laanwj> hii 14:00:23 <brunoerg> hi 14:00:26 <cfields> hi 14:00:27 <_aj_> hi 14:00:33 <achow101> There is one preproposed meeting topic this week. Any last minute ones to add? 14:01:03 <achow101> #topic package relay updates (glozow) 14:01:05 <dergoegge> hi 14:01:15 <pinheadmz> hi 14:01:18 <glozow> Nothing new this week - #28984 is still the priority. My main focus this week will be reviewing that. I think we are aiming for #29496 and #28984 for 28.0. 14:01:18 <glozow> On the p2p side, I just rebased #30111 which is the main PR to review. 14:01:20 <gribble> https://github.com/bitcoin/bitcoin/issues/28984 | Cluster size 2 package rbf by instagibbs ÷ Pull Request #28984 ÷ bitcoin/bitcoin ÷ GitHub 14:01:22 <gribble> https://github.com/bitcoin/bitcoin/issues/29496 | policy: bump TX_MAX_STANDARD_VERSION to 3 by glozow ÷ Pull Request #29496 ÷ bitcoin/bitcoin ÷ GitHub 14:01:22 <gribble> https://github.com/bitcoin/bitcoin/issues/28984 | Cluster size 2 package rbf by instagibbs ÷ Pull Request #28984 ÷ bitcoin/bitcoin ÷ GitHub 14:01:24 <gribble> https://github.com/bitcoin/bitcoin/issues/30111 | locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip by glozow ÷ Pull Request #30111 ÷ bitcoin/bitcoin ÷ GitHub 14:01:59 <glozow> That's all from me 14:02:11 <willcl-ark> hi 14:02:35 <achow101> #topic cluster mempool updates (sdaftuar) 14:03:06 <sipa> Unsure if Suhas is around. 14:03:11 <sdaftuar> not too much from me this week either. i've rebased #28676 (on master) to try to get that code current again, and i'm planning to further get branches of that code built on sipa's cluster linearization branch (#30126) and the cluster size 2 package rbf PR 14:03:14 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar ÷ Pull Request #28676 ÷ bitcoin/bitcoin ÷ GitHub 14:03:16 <sdaftuar> just to verify that everything works 14:03:16 <gribble> https://github.com/bitcoin/bitcoin/issues/30126 | Low-level cluster linearization code by sipa ÷ Pull Request #30126 ÷ bitcoin/bitcoin ÷ GitHub 14:03:27 <instagibbs> ð thanks 14:03:45 <sdaftuar> sipa -- anything to add on your PR? (that's the one to review right now) 14:04:21 <sipa> Not really, I've updated my low-level linearization code PR to include post-linearization and merging, which is all that I intend to implement at that "layer". 14:04:33 <sipa> Based on review, it may mean splitting some parts off. 14:04:49 <glozow> iiuc we're currently reviewing #30160 and #30161 to get those bits out of the way? 14:04:51 <gribble> https://github.com/bitcoin/bitcoin/issues/30160 | util: add BitSet by sipa ÷ Pull Request #30160 ÷ bitcoin/bitcoin ÷ GitHub 14:04:53 <gribble> https://github.com/bitcoin/bitcoin/issues/30161 | util: add VecDeque by sipa ÷ Pull Request #30161 ÷ bitcoin/bitcoin ÷ GitHub 14:05:31 <instagibbs> I think splitting will be necessary but haven't spent enough time on it to know how, focusing on those 2 prs first 14:05:37 <jon_atack> hi 14:05:41 <sipa> Indeed, those are direct dependencies, though I think it's reasonable to look at the algorithmic parts of #30126 already if you don't care that much about the data structures involved. 14:05:42 <gribble> https://github.com/bitcoin/bitcoin/issues/30126 | Low-level cluster linearization code by sipa ÷ Pull Request #30126 ÷ bitcoin/bitcoin ÷ GitHub 14:05:44 <tdb3_> hi 14:06:09 <glozow> makes sense 14:06:32 <Murch[m]> hi 14:07:09 <sipa> My next plan is to start helping with integration into sdaftuar's PR so we can get the TxGraph abstraction to get an implementation using these algorithms 14:07:18 <sipa> But that won't change what's next for review. 14:07:32 <sipa> That's it from me, I think. 14:08:16 <achow101> #topic legacy wallet removal updates (achow101) 14:08:19 <abubakarsadiq> hi 14:08:45 <achow101> #26596 has been getting some review. It's still the priority pr. 14:08:48 <gribble> https://github.com/bitcoin/bitcoin/issues/26596 | wallet: Migrate legacy wallets to descriptor wallets without requiring BDB by achow101 ÷ Pull Request #26596 ÷ bitcoin/bitcoin ÷ GitHub 14:09:23 <achow101> There's also one more item in the roadmap for 28.0 that isn't started yet: GUI: Migrate wallets that are not loaded 14:09:39 <achow101> will be looking at doing that soon, unless someone else wants to do it 14:10:20 <achow101> #topic Ad-hoc high priority for review 14:10:24 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:13:00 <achow101> #topic vulnerability disclosure policy (darosior) 14:13:15 <darosior> Alright, so as you know we discussed better tracking and disclosing security bugs at the last two coredevs. About three months ago i also updated people during this meeting on Niklas and i writing about historical reports which were never disclosed. After the last coredev a few of us (dergoegge, sipa, _aj_, fanquake, achow101 and i) had a couple 14:13:15 <darosior> calls to discuss what could be a good disclosure policy for the project. We came up with a plan and a disclosure policy we are content starting with. To avoid a large wall of text here i've made it into a gist: https://gist.github.com/darosior/eb71638f20968f0dc896c4261a127be6. 14:13:47 <darosior> We'd like to seek feedback from everyone here. Keep in mind this is not set in stone, the policy may be improved or updated in the future. This is just a reasonable starting point which improves over the current situation. I can also give a TL;DR here to kick off discussions. 14:15:03 <sipa> i think a tl;dr is useful 14:16:11 <achow101> I guess more specific feedback can be also be left on the gist outside of the meeting? 14:16:17 <darosior> TL;DR: 14:16:18 <darosior> - disclose low severity bugs when a fix is released, after a pre-announcement period of 2 weeks. 14:16:18 <darosior> - disclose higher severity bugs once all affected versions are EOL, after a pre-announcement period of 2 weeks. 14:16:18 <darosior> - the plan is to gradually phase-in this policy by first disclosing all the historical reports (up to version 0.21.x). Then we do one version per month. In July all which was fixed in 22.x. In August, 23.x. Etc.. 14:16:33 <darosior> Up until we run out of EOL releases to disclose security bugs for 14:17:04 <sdaftuar> Seems resonable to me on first glance -- thanks for working on this 14:17:16 <glozow> +1 thanks for working on this 14:17:21 <achow101> also the critical bugs that affect the entire network (e.g. inflation bug) will be handled on an ad-hoc basis 14:17:42 <instagibbs> +1 14:17:57 <darosior> achow101: yes if people need more time to think about it feel free to comment on the gist. Since we've got no other topics i'm also fine waiting a couple minutes here for people to read through it. 14:18:46 <sipa> And just to highlight what the goal is here: we'd like to improve the public's perception about some of the work that is not always very visible, and the fact that there definitely are reasons to upgrade (even to backport releases) 14:18:56 <darosior> The next step would be to put up a blog post at bitcoincore.org with the historical bugs, and publish that on the ML at the same time as a request for feedback on our policy. 14:20:04 <darosior> Yes, and having a proper policy in place could also potentially incentivize security researchers to look at our stuff 14:20:13 <sipa> right 14:20:29 <josie> overall, looks great and glad to see this moving forward. regarding high severity disclosures, do we currently send announcements for releases reaching EOL? if we will be disclosing bugs 2 weeks after EOL, maybe we also make general announcements to remind people which releases will be EOL by the next release? 14:20:36 <josie> (maybe we already do this?) 14:20:39 <darosior> Also it's just useful to us as a group to learn from what past bugs were vulnerabilities, and how to try and prevent them moving forward 14:20:58 <achow101> josie: we don't currently. the plan would mean that we will 14:21:24 <pinheadmz> darosior great writeup, good plan and +1 on blog posts, looking forward to reading those myself! 14:21:35 <josie> cool, i think thats important, otherwise the 2 weeks after EOL seems a bit aggressive 14:21:41 <sipa> there is also a possibility of pre-announcements like openssl does (on day X we will be disclousing a bug affecting versions Y, of severity Z) 14:21:42 <darosior> pinheadmz: some are quite nice :) 14:22:04 <achow101> josie: essentially we will announce eol, and pre-announce that things will be disclosed in 2 weeks 14:22:17 <instagibbs> don't be afraid to extract maximum publicity for the series of posts/releases 14:22:22 <TheCharlatan> is there a reason for doing one version per month in this "catch-up" period? 14:22:32 <darosior> instagibbs: yeah i pinged the optech guys ð 14:22:47 <darosior> TheCharlatan: lots of 22.0 still running 14:22:56 <darosior> Give a chance to people to upgrade 14:23:07 <achow101> TheCharlatan: we don't want to dump everything on everyone at once since a lot of people are still running eol software. phasing in gives people time to upgrade 14:23:21 <sipa> or more meta, give people some time to adapt their update processes in function of our process 14:24:06 <josie> achow101: maybe we are saying the same thing, but what im suggesting is "release X is out, also as a reminder Y and Z will be EOL in the next release (~ 6 months)" and then in 6 months "hey remember those EOL releases? we will disclose bugs in 2 weeks" 14:24:24 <achow101> josie: yeah, basically 14:24:43 <darosior> josie: yes 14:25:38 <jon_atack> lgtm. and good point josie. looking forward to reading these. 14:25:38 <darosior> Cool, thanks for the feedback. I guess that's it then. 14:26:11 <josie> big thanks to everyone who worked on this! 14:26:15 <achow101> Any other topics to discuss? 14:28:07 <achow101> #endmeeting