14:00:37 <achow101> #startmeeting 14:00:41 <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 theStack TheCharlatan vasild 14:00:42 <abubakarsadiq> hi 14:00:44 <josie> hi 14:00:44 <kanzure> hi 14:00:46 <kevkevin_> hi 14:00:46 <hebasto> hi 14:00:47 <brunoerg> hi 14:00:49 <emzy> hi 14:00:49 <TheCharlatan> hi 14:00:53 <cfields> hi 14:00:59 <vasild> hi 14:01:00 <achow101> There is one preproposed meeting topic this week. Any last minute ones to add? 14:01:02 <lightlike> hi 14:01:05 <kanzure> #proposedmeetingtopic mailing list archive progress 14:01:08 <LarryRuane> Hi 14:01:18 <sdaftuar> hi 14:01:26 <dergoegge> hi 14:02:04 <achow101> #topic package relay updates (glozow) 14:02:04 <furszy> hi 14:02:11 <instagibbs> Hi, glozow is afk for now, so I'll be giving the update today 14:02:38 <instagibbs> #28948 is still the thing to review, we're gunning for merge pre-feature freeze, with 14:02:38 <instagibbs> it nonstandard in mainnet prior to release to allow for a bit of bikeshedding over the magic number 14:02:41 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow ÷ Pull Request #28948 ÷ bitcoin/bitcoin ÷ GitHub 14:02:52 <instagibbs> Next release focus on 1p1c relay, V3 sibling eviction, 2-cluster package rbf, LN imbue(if any), cluster mempool(!ambitious!) 14:02:53 <instagibbs> that's all 14:02:54 <fjahr> hi 14:02:59 <maxedw> hi 14:03:20 <achow101> #topic silent payments updates (josie) 14:03:25 <instagibbs> V3 is a bit of a blocker for many PRs, so will be nice to clear it off 14:04:03 <josie> per last weeks discussion, I started rewriting #28122 to use the libsecp module, I expect to have that finished soon 14:04:05 <gribble> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake ÷ Pull Request #28122 ÷ bitcoin/bitcoin ÷ GitHub 14:04:14 <josie> I updated the tracking issue to make https://github.com/bitcoin-core/secp256k1/pull/1471 the review priority 14:04:47 <josie> theStack and I have been working on that PR, mostly discussing the interface for the API. would love some feedback, esp from the more seasoned libsecp contributors 14:06:04 <josie> 1471 is marked as a draft, but we could probably mark it as open. not sure if theStack is here, but ill let them make that call 14:06:17 <josie> thats all for me 14:06:39 <achow101> i've updated the priority board to list the libsecp pr as silent payment's priority 14:06:49 <josie> ty! 14:06:51 <achow101> #topic multiprocess updates (ryanofsky) 14:07:03 <ryanofsky> #29409 and #29409 ready for review, but that's all 14:07:05 <gribble> https://github.com/bitcoin/bitcoin/issues/29409 | multiprocess: Add capnp wrapper for Chain interface by ryanofsky ÷ Pull Request #29409 ÷ bitcoin/bitcoin ÷ GitHub 14:07:05 <gribble> https://github.com/bitcoin/bitcoin/issues/29409 | multiprocess: Add capnp wrapper for Chain interface by ryanofsky ÷ Pull Request #29409 ÷ bitcoin/bitcoin ÷ GitHub 14:07:28 <ryanofsky> oops #28929 and 29409 14:07:30 <gribble> https://github.com/bitcoin/bitcoin/issues/28929 | serialization: Support for multiple parameters by ryanofsky ÷ Pull Request #28929 ÷ bitcoin/bitcoin ÷ GitHub 14:07:59 <achow101> #topic Ad-hoc high priority for review 14:08:04 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:08:41 <achow101> Also 27.0 feature freeze is this coming Monday. 14:08:43 <josie> theres a few outstanding PRs for the wallet migration, right? might be nice to add them to the high prio 14:09:15 <josie> (a few prs before dropping the experimental flag for 27.0) 14:09:27 <achow101> yes, I've added those to the tracking issue 14:09:43 <cguida> hi 14:10:08 <cguida> This PR seems to be ready https://github.com/bitcoin/bitcoin/pull/28217, if there's any time left at the end 14:11:09 <achow101> #topic ASMap creation progress (fjahr) 14:11:17 <fjahr> I wanted to share the progress we have made on the data collection and processing steps that can lead to an ASMap file that we trust enough to include it in releases. I had shared the rough concept a few months ago but now you can see what it looks like in action. 14:11:24 <fjahr> The tools used are Kartograf (https://github.com/fjahr/kartograf) and sipaâÂÂs asmap-tool (https://github.com/bitcoin/bitcoin/pull/28793), the repository for the actual data is at https://github.com/fjahr/asmap-data for now, this should probably move into the org at some point if people are happy with this process. 14:11:33 <fjahr> Step 1: Data collection, demoed here: https://github.com/fjahr/asmap-data/issues/9 Multiple contributors first agree to launch the Kartograf mapping process at a specific timestamp, coordinated via an issue. Kartograf now has a feature that makes this comfortable (`-wait`), you just set it and it launches the process when the timestamp is hit. In testing so far we have found that there is a good chance that within a group 14:11:34 <fjahr> of 5 or more the majority of participants will have the same result. That is the threshold I am proposing as well for the start: 5+ participants and >50% match in result. This will not work every time but maybe 4/5 and we can simply have a redo when there is a failure to agree on a result. We can also adjust the values over time as we get more practice. This process can be initiated by anyone, very similar to a Core PR. 14:11:34 <fjahr> Participants that have a matching result could be interpreted as ACKs. If anyone sees something weird in the result or they simply didnâÂÂt get a match, they can ask for the raw data to be shared to investigate further. 14:11:42 <fjahr> Step 2: Compression, demoed here: https://github.com/fjahr/asmap-data/pull/10 Based on the result file a PR can be created that adds the compressed asmap.dat of the previous result to the repo. Similar to our normal PRs, 2-3 reviewers should ensure they get the same result before the file gets merged. 14:11:49 <fjahr> Step 3: Using the asmap.dat files: Users that want to run their node with an asmap file can get regular updates from there. When we decide to include a default asmap.dat file in a release, we can pick one of the recent ones from the repo. 14:12:25 <fjahr> Many thanks to those who participated in all those tests so far! Happy to answer questions :) 14:12:46 <fjahr> (now or later) 14:13:49 <achow101> cool, thanks for the update 14:14:13 <achow101> #topic mailing list archive progress (kanzure) 14:14:37 <kanzure> we have the .mbox files and such, but the announcement email is waiting on a mailing list archive 14:15:00 <achow101> I thought the idea was to use public-inbox? 14:15:01 <kanzure> which i am actively working on-- public-inbox.org default import order is somewhat random and the publicly accessible archive does not look good 14:15:22 <kanzure> yes, but mb2md produces a random order when converted to public-inbox.org's git repository 14:15:34 <kanzure> so anyway, i need to make a commit order that looks reasonable based on the emails in the mbox file 14:15:38 <kanzure> working on it! 14:15:44 <achow101> how long will the archive on linuxfoundation.org be live? 14:15:56 <kanzure> i don't think they will host our new archive :| 14:15:57 <kanzure> we can ask 14:16:34 <kanzure> here is a public-inbox.org demo instance: https://lore.kernel.org/lkml/ 14:17:06 <achow101> didn't _aj_ have a public-inbox demo for the list? 14:17:56 <kanzure> random order: https://gnusha.org/inboxes/bitcoindev/new.html anyway, actively working on it. RubenSomsen might be convinced to send the announcement email anyway. 14:18:04 <achow101> https://github.com/ajtowns/pi-btc-dev-test is the repo 14:18:47 <kanzure> oh these are the .txt.gz archives? 14:18:59 <achow101> presumably? 14:19:44 <achow101> can the mbox be posted somewhere so other people can also make archives? 14:19:59 <kanzure> are there strong opinions about whether headers shuld be stripped? 14:20:40 <achow101> are the headers in what was sent out to the list recipients? 14:20:47 <kanzure> yes 14:20:58 <vasild> headers were not public before (so far)? 14:21:23 <achow101> if people received them in their mail clients, I don't see why they should be 14:21:40 <vasild> I mean public via some web interface / mail archive 14:21:56 <kanzure> only received by list recipients, not published on a mail archive AFAIK 14:22:31 <achow101> oh. if they weren't published in the archive before, then i think it would be fine to not publish them in the new one 14:24:53 <achow101> Any other topics to discuss? 14:25:18 <cguida> Yes, I'd love to know what's left for this to get merged: https://github.com/bitcoin/bitcoin/pull/28217 14:25:35 <kanzure> one reason that the announcement has not been sent yet is a desire to include all new emails in the archive, and that won't work until the public archive is ready 14:25:39 <achow101> cguida: it's controversial 14:26:34 <cguida> achow101: I don't think it is. I think all of the objections have been dealt with. What objections do you think have not been addressed? I'm willing to do whatever work you guys suggest. 14:27:19 <achow101> what's left would be for several of the people who NACK'd to drop their NACKs. And for more active contributors to ACK it. 14:28:41 <cguida> Ok, thanks. Can you suggest a threshold for maximum number of NACKs? And the PR already has 6 ACKs, but I can see if I can get others to add their voices. 14:28:58 <achow101> do not brigade it 14:29:18 <achow101> no, a threshold will not be provided 14:29:19 <josie> cguida: ACKing is not voting 14:29:50 <cguida> I won't, this would just be out of band communication. I think this is an important issue that needs to be addressed somehow. If not this PR, then I hope we can rally around some kind of mitigation for this vulnerability. 14:30:27 <cguida> josie: Yes I understand. I'm just wondering who you guys think I'd need to persuade to ACK. Is it Peter? 14:31:29 <achow101> multiple of the people who are actively working on mempool policy, who currently have not yet commented on the pr 14:31:59 <cguida> Ok, thanks. I appreciate the feedback :) 14:32:18 <achow101> Any other topics? 14:33:41 <kanzure> while that would be a helpful improvement on that PR, it should not be understood to be a guaranteed approval upon those acks 14:34:50 <achow101> #endmeeting