14:00:13 <achow101> #startmeeting 14:00:33 <TheCharlatan> hi 14:00:36 <sdaftuar> hi 14:00:48 <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:51 <sipa> hi 14:00:54 <abubakarsadiq> hi 14:01:03 <achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add? 14:01:07 <furszy> hi 14:01:14 <dergoegge> hi 14:01:17 <LarryRuane> hi 14:01:24 <stickies-v> hi 14:01:31 <kanzure> hi 14:01:35 <achow101> #topic package relay updates (glozow) 14:01:50 <maxedw> hi 14:01:51 <josie> hi 14:01:55 <glozow> #28948 is the priority. It seems to be maturing 14:01:56 <cfields> hi 14:01:57 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow ÷ Pull Request #28948 ÷ bitcoin/bitcoin ÷ GitHub 14:02:05 <kanzure> mailing list migration is still in progress, linuxfoundation.org has delivered the mbox file and i have stopped inbound emails for now 14:02:25 <achow101> kanzure: we can do that as a topic later 14:02:27 <glozow> We're looking to hear back from some more people on #29319 14:02:28 <gribble> https://github.com/bitcoin/bitcoin/issues/29319 | Cluster mempool, CPFP carveout, and V3 transaction policy ÷ Issue #29319 ÷ bitcoin/bitcoin ÷ GitHub 14:02:53 <theStack> hi 14:03:00 <kanzure> achow101: i am AFK, just wanted to drop in. feel free to send questions or bug RubenSomsen. 14:03:19 <glozow> #28950 review club next week 14:03:20 <gribble> https://github.com/bitcoin/bitcoin/issues/28950 | RPC: Add maxfeerate and maxburnamount args to submitpackage by instagibbs ÷ Pull Request #28950 ÷ bitcoin/bitcoin ÷ GitHub 14:03:20 <kevkevin> hi 14:03:28 <hebasto> hi 14:03:46 <achow101> glozow: comments in 29319 shouldn't affect 28948, yes? 14:03:57 <sipa> #28948 14:03:58 <Murch[m]> hi 14:03:59 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow ÷ Pull Request #28948 ÷ bitcoin/bitcoin ÷ GitHub 14:04:28 <glozow> v3 shouldn't be blocked by it 14:04:32 <RubenSomsen> hi 14:04:50 <sdaftuar> but if somehow the v3 proposal doesn't meet the needs of LN we should give some thought to how to proceed 14:04:55 <fjahr> hi 14:05:08 <sdaftuar> as the parameters have been chosen to be compatible with that usecase 14:05:32 <glozow> That's true. 14:05:44 <achow101> ok, makes sense 14:06:16 <achow101> #topic silent payments updates (josie) 14:06:35 <josie> #28122 is the priority for review 14:06:38 <gribble> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake ÷ Pull Request #28122 ÷ bitcoin/bitcoin ÷ GitHub 14:07:23 <josie> also, theStack opened a draft silentpayments libsecp module in secp256k1/#1471 14:07:24 <gribble> https://github.com/bitcoin/bitcoin/issues/1471 | Add new P2P command and response: "getcmds", "cmdlist" by jgarzik ÷ Pull Request #1471 ÷ bitcoin/bitcoin ÷ GitHub 14:07:34 <josie> looking for feedback on the module API 14:08:20 <achow101> what's the secp module for? 14:08:53 <josie> all the crypto parts of silent payments, basically 14:09:27 <achow101> iirc libsecp has enough stuff exposed to implement silent payments, so it's just to abstract some of that away? 14:10:01 <sipa> not efficiently 14:10:11 <josie> yeah, not efficiently and not ideal 14:10:13 <willcl-ark> hi 14:10:14 <fjahr> Does #28122 use the module already? 14:10:16 <gribble> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake ÷ Pull Request #28122 ÷ bitcoin/bitcoin ÷ GitHub 14:10:38 <sipa> and it'd be using fairly low-level operations (pubkey addition) which we'd like to get rid of 14:11:06 <sipa> the trend in libsecp256k1 has been to focus on higher-level, hard-to-abuse, APIs 14:11:06 <josie> fjahr: nope, but thats a good question.. when we spoke about it last coredev, the expectation was that a secp module would move slower and its fine to continue with the PR as is with the plan to use the module when its ready 14:11:14 <fanquake> sounds like something we don't want to start doing in our codebase. If it's going to be a blocker to upstream making changes and or us pulling updates 14:12:26 <josie> sipa: which is good for other implementations as well! if we had a high level, hard to abuse api, it de-risks wallets outside of core implementing bip352 14:12:50 <sipa> indeed 14:12:56 <achow101> i'd much rather not have to review basically 2 different implementations 14:13:10 <achow101> so if the secp is likely to happen, then it should go first 14:13:20 <achow101> and 28122 should use it 14:13:43 <josie> im fine with that! and agree that reviewing two in tandem is gross. honestly wasnt expecting the secp module to make progress as quickly as it did (h/t theStack) 14:13:56 <fjahr> yeah, if the module is used right away that will motivate more people to review secp faster as well. 14:14:36 <josie> cool, well then per this discussion ill update #28122 to use the libsecp module 14:14:39 <gribble> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake ÷ Pull Request #28122 ÷ bitcoin/bitcoin ÷ GitHub 14:14:56 <josie> which should help make the API discussion more productive, since we will have at least one user of the API 14:15:37 <josie> thats all for me 14:15:59 <achow101> #topic multiprocess updates (ryanofsky) 14:16:18 <ryanofsky> #28921 was merged, #28929 is out for review, and I will open a new PR soon with 3 commits from the multiprocess branch #10102 exposing interfaces::Chain over IPC 14:16:20 <gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky ÷ Pull Request #28921 ÷ bitcoin/bitcoin ÷ GitHub 14:16:21 <gribble> https://github.com/bitcoin/bitcoin/issues/28929 | serialization: Support for multiple parameters by ryanofsky ÷ Pull Request #28929 ÷ bitcoin/bitcoin ÷ GitHub 14:16:24 <gribble> https://github.com/bitcoin/bitcoin/issues/10102 | Multiprocess bitcoin by ryanofsky ÷ Pull Request #10102 ÷ bitcoin/bitcoin ÷ GitHub 14:16:46 <ryanofsky> That's all for me 14:17:01 <achow101> #topic Ad-hoc high priority for review 14:17:05 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:17:39 <achow101> Or any other topics to discuss? 14:17:42 <sipa> i'd like to briefly bring up #29284 14:17:43 <gribble> https://github.com/bitcoin/bitcoin/issues/29284 | Choose earliest-activatable as tie breaker between equal-work chains by sipa ÷ Pull Request #29284 ÷ bitcoin/bitcoin ÷ GitHub 14:17:59 <achow101> sipa: as a topic? 14:18:48 <sipa> in theory, it's a huge change, in practice i don't think it'll really affect anything 14:18:55 <sipa> but i'd like to draw some attention to it 14:19:01 <sipa> that's it, unless people have questions 14:20:49 <vasild> hi 14:22:22 <sipa> s/huge/fundamental/ 14:22:51 <achow101> anything else to talk about? 14:22:59 <josie> if there are no other topics, is there q update on the mailing list? 14:23:06 <vasild> where is the mailing list migrating to? 14:23:49 <achow101> last I heard, mailing list is actually shutting down imminently and will be moving to groups.io. Maybe RubenSomsen can provide more details? 14:23:55 <sipa> kanzure: i am baffled to hear "i am AFK" coming from you 14:24:23 <_aj_> sipa: neuralink announced its first human subject the other day? 14:24:35 <RubenSomsen> I found some issues with groups io, we've been talking with them to get it resolved 14:24:39 <Murch[m]> Good point, I thought kanzure and his keyboard were a permanent cybernetic system 14:25:08 <achow101> RubenSomsen: can you say what kind of issues? 14:25:15 <RubenSomsen> We might still opt for Google groups depending on how it pans out 14:25:43 <josie> in the meanwhile, is delving the best place for soliciting feedback on proposals? 14:26:03 <RubenSomsen> Emails had an unsubscribe link that required no authentication. Forwarding an email would allow whoever received the email to unsubscribe you. 14:26:13 <sipa> RubenSomsen: ouch 14:26:24 <sipa> delving seems to be starting to get a pretty good crowd 14:27:12 <RubenSomsen> Imo the mailing list should continue to exist, and delving alongside it 14:27:40 <achow101> any idea when the migration will be completed? 14:28:14 <achow101> no longer being able to send to the list now is kinda bothersome, especially for conversations that were happening on the list and not elsewhere 14:29:14 <vasild> what would a migration look like? a migration of some web-archive of past emails, or would existent subscribers would automatically be subscribed to e.g. bitcoin@groups.io? 14:29:33 <RubenSomsen> The bug was just fixed. I just tested and confirmed. We want to finalize things soon. Especially if we're stopping emails on the current list that forces us to do something asap. 14:30:38 <sipa> great 14:32:20 <RubenSomsen> vasild: to be determined, but it may be cleaner to let people re-subscribe. We have a lot of weird subscribers that are probably spam. 14:32:52 <achow101> presumably there'll be a final email on the current list with instructions 14:33:03 <RubenSomsen> yeah 14:33:37 <vasild> ok, so it looks like there is nothing to be migrated? just a new list people can use (subscribe and send emails to)? 14:33:55 <sipa> given the mbox comment, i guess the history will be imported? 14:34:51 <vasild> right, which I guess will be available via some kind of web ui? 14:34:57 <achow101> wherever the new official archive is, I think history will also be imported there too, so it'll all be in one place. otherwise, it's just a new mailing list 14:35:02 <RubenSomsen> I think that's more for archiving purposes than importing. 14:35:20 <sipa> RubenSomsen: oh, unfortunate 14:35:55 <RubenSomsen> We have to archive the new mailing list somewhere too, so maybe that place can host both the new and old archive 14:37:34 <achow101> anything else to discuss? 14:38:04 <RubenSomsen> I'd be curious to hear if anyone has strong objections to Google groups. We're currently experimenting with both. 14:39:02 <maxedw> Is one free and one not? Does that factor? 14:39:13 <vasild> is it going to be this one https://groups.io/g/bitcoindev ? 14:39:34 <RubenSomsen> If we're going with groups io then yes, but that's to be determined 14:39:43 <vasild> RubenSomsen: not sure if that counts as "strong objection", but I would not subscribe to google groups 14:40:47 <RubenSomsen> groups is unfortunately paid per subscriber, which could potentially be an issue if we get mass subscription spam 14:41:16 <RubenSomsen> vasild: it would be helpful to know why you wouldn't 14:42:42 <sipa> how many subscribers does the current list have? 14:42:53 <vasild> RubenSomsen: because I think it is against bitcoin mindset (at least my mindset) and also against an attempt to de-google myself 14:42:59 <RubenSomsen> 2000 14:43:08 <_aj_> if groups.io fixes things when you complain, that seems like it's probably better than what you'd get from google? 14:43:30 <vasild> (not trying to focrce my opinion on anybody, I don't mind if people are happy with google groups, it is just that I will not use it) 14:43:55 <RubenSomsen> _aj_: Yes, we're happy with how responsive they've been. 14:45:23 <RubenSomsen> Sorry 4000, misremembered 14:45:52 <vasild> $0.04 per member per month, that is $160/month (https://groups.io/static/pricing) 14:46:11 <achow101> i guess the main thing is that groups.io could get expensive? 14:46:53 <RubenSomsen> We can easily find people to sponsor that amount, but if we get spammed with subscribers that could become an issue 14:46:55 <sipa> i do agree with vasild' sentiment about google groups, though pragmatically, i would still subscribe 14:47:35 <vasild> achow101: yeah, that $0.04 may be rised in the future 14:47:37 <_aj_> setup a btcpay store and require people to pay 50c to stay subscribed after a year? 14:47:47 <sipa> and groups.io is probably not that different from a cost for hosting ourselves if we need to pay people to maintain things 14:48:03 <hebasto> if there is possibility to spam some adversary will use it 14:48:36 <sipa> RubenSomsen: is there some kind of spam protection we could get? like if there is a sudden influx of subscribers that get kicked quickly, we don't get billed for it? 14:48:51 <vasild> too many spam/unwanted subscribers should be a common problem for any group at groups.io, how do they solve it? 14:49:20 <sipa> maybe this discussion belongs elsewhere, though 14:49:31 <_aj_> on the mailing list? :) 14:49:34 <RubenSomsen> sipa: I sent them my concern about mass subscription and am awaiting the reply. Hopefully they have some thoughts. 14:49:53 <sipa> _aj_: i thought there was an IRC channel about discussing the migration too 14:49:56 <vasild> even groups.io have incentive to sneak some moderate dummy subscribers themselves 14:49:57 <achow101> There's a ##bitcoin-dev-lists channel 14:50:05 <RubenSomsen> Yeah let's take this there 14:50:57 <achow101> seems like there wasn't anything else to discuss for today 14:50:59 <achow101> #endmeeting