19:04:29 <laanwj> #startmeeting 
19:04:31 <meshcollider> hi
19:04:33 <sipa> hi
19:04:35 <cfields> hi
19:04:35 <hebasto> hi
19:04:36 <michaelfolkson> hi
19:04:38 <kvaciral[m]> hi
19:04:48 <ariard> hi
19:04:49 <jonatack> hi
19:04:54 <lightlike> hi
19:04:58 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
19:05:00 <laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:05:10 <achow101> hi
19:05:11 <jamesob> hi
19:05:12 <jonasschnelli> #proposedmeetingtopic some personal information from myside
19:05:24 <josibake> hi
19:05:44 <sipa> #proposedmeetingtopic : 23306 proposes (and is a first step towards) getting rid of the prefer-port-8333 policy on the network
19:06:45 <laanwj> other proposed meeting topics: tag 0.20.3-final (fanquake) Encouraging people to propose meeting topics for the weekly IRC Core dev meetings (michaelfolkson) Attempting to transition to full RBF over multiple major versions (michaelfolkson)
19:07:25 <laanwj> #topic High priority for review
19:07:33 <fjahr> hi
19:07:41 <michaelfolkson> Mine aren't urgent and can be pushed to another week
19:08:05 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 has 10 blockers, 1 chasing concept ACK
19:08:39 <laanwj> anything to add/remove, that is ready for review, or that you'd like to give an update on?
19:09:27 <meshcollider> I'd quite like to have #16807 on there
19:09:29 <gribble> https://github.com/bitcoin/bitcoin/issues/16807 | Let validateaddress locate error in Bech32 address by meshcollider · Pull Request #16807 · bitcoin/bitcoin · GitHub
19:10:18 <ariard> maybe either #22674 or #23121, i think the former is more ready
19:10:20 <gribble> https://github.com/bitcoin/bitcoin/issues/22674 | validation: mempool validation and submission for packages of 1 child + parents by glozow · Pull Request #22674 · bitcoin/bitcoin · GitHub
19:10:21 <gribble> https://github.com/bitcoin/bitcoin/issues/23121 | [policy] check ancestor feerate in RBF, remove BIP125 Rule2 by glozow · Pull Request #23121 · bitcoin/bitcoin · GitHub
19:10:27 <laanwj> meshcollider: added
19:10:33 <meshcollider> Thanks!
19:11:09 <laanwj> ariard: i don't have an opinion which one, maybe someone else has
19:11:25 <ariard> yeah if glozow is around :)
19:12:03 <cfields> just a quick note: #23114 (minisketch integration, already listed as hi prio) is ~ready, but also requires review of minisketch itself. So... review beg for minisketch itself as well :)
19:12:05 <gribble> https://github.com/bitcoin/bitcoin/issues/23114 | Add minisketch subtree and integrate into build/test by fanquake · Pull Request #23114 · bitcoin/bitcoin · GitHub
19:12:17 <sipa> ACK minisketch!
19:12:19 <sipa> hdies
19:12:27 <sipa> *hides
19:12:43 <josibake> reading that as sip dies was much more dramatic
19:13:18 <michaelfolkson> Definite ACK for Minisketch. You mean on the Core PR cfields?
19:13:52 <sipa> i meant mine as: i'm obviously ack on the minisketch code itself, but i doubt it counts for much
19:14:01 <michaelfolkson> https://github.com/bitcoin/bitcoin/pull/23114
19:14:06 <cfields> michaelfolkson: I mean the minisketch impl itself also needs review, not just the concept of merging it into core.
19:14:23 <laanwj> ariard: ok, added #22674 as it is more clearly a blocker for further work
19:14:24 <michaelfolkson> So that is reviewing the Minisketch repo rather than a particular PR?
19:14:25 <gribble> https://github.com/bitcoin/bitcoin/issues/22674 | validation: mempool validation and submission for packages of 1 child + parents by glozow · Pull Request #22674 · bitcoin/bitcoin · GitHub
19:14:53 <michaelfolkson> That's great that the Minisketch build stuff is ~ready
19:15:07 <laanwj> i'll have a look at the minisketch impl
19:15:31 <michaelfolkson> Repo: https://github.com/sipa/minisketch
19:16:11 <sipa> FWIW, there have been two review clubs on the minisketch algorithm and code; https://bitcoincore.reviews/minisketch-26-2 and https://bitcoincore.reviews/minisketch
19:16:51 <laanwj> neat
19:17:03 <cfields> sipa: ah, thanks, good to know. I missed those.
19:17:22 <cfields> anyway, didn't mean to turn it into a topic, just a quick note.
19:17:28 <michaelfolkson> And post those reviews of the repo generally on #23114
19:17:30 <gribble> https://github.com/bitcoin/bitcoin/issues/23114 | Add minisketch subtree and integrate into build/test by fanquake · Pull Request #23114 · bitcoin/bitcoin · GitHub
19:18:07 <sipa> oh, there were three; https://bitcoincore.reviews/minisketch-26 too
19:18:31 <laanwj> haah
19:18:38 <jonatack> those were really interesting review clubs. i recall testing and reviewing minisketch, will return to it
19:19:06 <laanwj> so it's not exactly that it had a lack of review
19:19:11 <ariard> yeah i read the paper a while back https://eprint.iacr.org/2003/235.pdf, it was fun
19:20:00 <sipa> regarding testing, there are exhaustive tests for various small fields (smaller than the one we'd use, but most code is shared across)
19:20:11 <cfields> heh, ok, review beg retracted. I was just responding to a few "reviewed the integration but not the impl" on that PR, but apparently review has been happening too :)
19:20:28 <michaelfolkson> cfields: A few months ago :)
19:21:00 <laanwj> cfields: it wasn't entirely clear to me either so it's good to have brought it up imo
19:21:10 <michaelfolkson> +1
19:21:50 <laanwj> #topic Some personal information from myside (jonasschnelli)
19:22:01 <jonasschnelli> As most of you have probably recognized, I was pretty inactive during the last months
19:22:12 <jonasschnelli> Today, I'd like to inform you that I will step down as maintainer and contributor
19:22:20 <sipa> jonasschnelli: sad to see you go
19:22:20 <cfields> :(
19:22:21 <jonasschnelli> I will remove my committer rights immediately
19:22:35 <laanwj> hope you'll be back some day!
19:22:40 <jonasschnelli> The reasons are mostly a shift in interest as well as rising legal risks (it wasn't you :)
19:22:40 <laanwj> but i get it
19:23:08 <jonasschnelli> and who know,... i might come back later down the road.
19:23:09 <cfields> jonasschnelli: hope everything's ok. there will always room for you here :)
19:23:12 <jamesob> Sad to see you go jonasschnelli but enjoy what other things life has to offer
19:23:17 <jamesob> Come back anytime :)
19:23:27 <sipa> and of course, good luck on wherever your path may lead
19:23:34 <jonasschnelli> thanks all.
19:23:35 <jonasschnelli> As for the macOS signing keys, I think either achow or fanquake would be a good fit
19:23:36 <hebasto> come back soon :)
19:23:54 <luke-jr> aren't the signing keys held by a corporate entity?
19:24:03 <laanwj> yes,good luck in whatever else you're going to do
19:24:21 <jonasschnelli> luke-jr: legaly yes,.. but technically someone needs to sign it
19:24:24 <jonasschnelli> I’ll remain the legal „president“ of the „Bitcoin Core Code Signing Association“ in Switzerland (the construct for getting code sign certificates, currently active for macOS but only a backup for the Delaware LLC that holds the win certificate)
19:24:44 <jonasschnelli> Off course, I’ll stick around here and can help where requested.
19:24:59 <jonatack> sad to hear that but understandable...i hope you'll be catching some waves and enjoying life
19:25:19 <cfields> jonasschnelli: also, thanks for being responsible and being willing to revoke your own access. much appreciated.
19:25:30 <laanwj> jonatack: that's good to hear
19:25:31 <jonasschnelli> sure things!
19:25:33 <laanwj> cfields: +1
19:26:03 <sipa> indeed
19:26:26 <jonasschnelli> If someone likes to continue bitcoinbuilds.org, please DM me (server costs are covered)
19:26:34 <meshcollider> Thanks for all your work over the years jonasschnelli! Best of luck for whatever comes next for you :)
19:26:40 <jonasschnelli> thanks meshcollider!
19:26:52 <achow101> sad to see you go, and good luck with whatever else you decide to do
19:27:00 <michaelfolkson> +1
19:27:03 <luke-jr> jonasschnelli: does it need much babysitting?
19:27:22 <jonasschnelli> luke-jr: yes... it need some tweaking (and some love)
19:27:37 <ariard> Yeah thanks for the numerous years of hard work, hope you'll be back
19:27:42 <achow101> in terms of the macOS code signing key, I can take that over if everyone feels that isn't too centralizing
19:27:49 <laanwj> jonasschnelli: re if no one else does it i'm ok with doing it
19:27:56 <achow101> I can also get one issued to the Delaware LLC
19:27:56 <laanwj> +bitcoinbuilds
19:28:07 <luke-jr> achow101: we shouldn't be putting trust in these keys either way *shrug*
19:28:08 <josibake> echoing everyone else, thank your for your contributions and best of luck in whatever you do next
19:28:12 <luke-jr> laanwj: thanks
19:28:22 <josibake> thank you*
19:28:32 <jonasschnelli> laanwj: great to hear. It's quite a mess and someone really loving shell scipts and virtualization should tackle it
19:28:44 <fjahr> jonasschnelli: thank you also from me for all the things already mentioned!
19:30:13 <laanwj> #topic Getting rid of the prefer-port-8333 policy (sipa)
19:30:51 <sipa> just a very short topic
19:30:53 <laanwj> [#23306 proposes (and is a first step towards) getting rid of the prefer-port-8333 policy on the network]
19:30:54 <gribble> https://github.com/bitcoin/bitcoin/issues/23306 | Make AddrMan support multiple ports per IP by sipa · Pull Request #23306 · bitcoin/bitcoin · GitHub
19:31:13 <sipa> it's all in the PR, i just wanted to make sure people saw
19:31:28 <laanwj> will check it out!
19:31:34 <sipa> as it's a potentially far-reaching policy change (the PR doesn't actually change the policy, but it's a preparation for it)
19:31:34 <jonatack> +1
19:32:20 <sipa> unless someone has questions/comments, that's it for my topic
19:32:23 <laanwj> concept ack anyhow
19:33:11 <michaelfolkson> I would guess there are some lazy habits where 8333 is etched into people's minds.
19:33:30 <michaelfolkson> But not a strong rationale for not changing that
19:33:47 <laanwj> i'll skip fanquake's topic as i think he meant 0.20.2, and that already happened Oct 18
19:34:13 <fanquake> yes I’ve made that tag already
19:34:32 <fanquake> we’ve had a few signed builders for 0.20.2 as well
19:34:51 <laanwj> i also built it but not uploaded sigs yet, will do
19:35:40 <laanwj> #topic Encouraging people to propose meeting topics for the weekly IRC Core dev meetings (michaelfolkson)
19:35:53 <fanquake> jonasschnelli: ! Hope you are doing ok, and maybe back to Core dev some day.
19:36:36 <josibake> are there any existing guidelines for what a "good" topic is?
19:36:38 <michaelfolkson> Ok very short one. Just to encourage people to propose meeting topics for this meeting. The number of topics have been pretty sparse in recent weeks/months and it is much better to have too many than next to none
19:36:56 <michaelfolkson> We can always push non-urgent to future weeks
19:37:15 <michaelfolkson> josibake: No but that sounds like a good idea
19:37:40 <michaelfolkson> It can be a PR though or a mini Core project though (imo)
19:37:55 <michaelfolkson> There is the Core PR review club too of course
19:38:00 <laanwj> josibake: dunno, you know you can always just ask in the channel
19:38:23 <michaelfolkson> And we are doing an online livestreamed session on AssumeUTXO
19:38:42 <laanwj> if it's relevant to current development in the repository and there's people willing to talk about it it's a good topic, that's pretty wide
19:38:52 <sipa> i like having short meetings tbh
19:39:06 <michaelfolkson> You can leave early though sipa :)
19:39:18 <sipa> i mean: we don't need to fill meetings because meetings should be filled
19:39:27 <michaelfolkson> The P2P ones have effectively been cancelled
19:39:28 <sipa> sure, if there is a topic, let's discuss it
19:39:30 <josibake> laanwj: thanks
19:39:41 <ariard> michaelfolkson: some people are attending multiple meetings, lightning, etc, short meetings are good :)
19:39:56 <michaelfolkson> I guess but people can leave if they aren't interested in the topic
19:40:09 <laanwj> i like short meetings but also, it's good if the time available is used in a productive way
19:40:42 <laanwj> if it ends with "high priority for review" every time it's also a bit demotivating
19:40:49 <jamesob> yeah, agree
19:40:54 <michaelfolkson> Just a thought that there are avenues for getting more review on your PR if you are frustrated (which imo includes this meeting)
19:41:06 <jamesob> I'm going to go on a tirade about nits at some point, so I'll queue that up for a future meeting :)
19:41:15 <laanwj> hehh
19:41:18 <michaelfolkson> PR review nits?
19:41:21 <jamesob> yes
19:41:29 <michaelfolkson> The TL;DR?
19:41:41 <laanwj> i mean some things you acn also bring up outside meeting, not everything needs to be in the meeting
19:41:50 <laanwj> just depends
19:41:59 <jamesob> ugh I don't know. They can just be really demotivating and distracting, but I need to collect my thoughts and figure out if I have any actually-actionable things to say
19:42:07 <michaelfolkson> Ok
19:42:07 <laanwj> any cast this gets veeeery meta
19:42:09 <jamesob> it was 40% a joke
19:42:27 <michaelfolkson> Haha ok next topic (as we've got ariard here and he doesn't like meetings)
19:42:44 <michaelfolkson> Let's cover the full RBF topic
19:42:56 <laanwj> #topic Attempting to transition to full RBF over multiple major versions (michaelfolkson)
19:43:17 <laanwj> jamesob: 40% joke is the best approach to things
19:43:21 <jamesob> lol
19:43:24 <ariard> ahah
19:43:48 <michaelfolkson> Ok I'm happy to pass this over to ariard but he previously posted this to the mailing list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
19:44:07 <luke-jr> how about just stop trying to dictate to users what policies they can or can't use? <.<
19:44:16 <jonatack> jamesob: (i see nits ideally as suggested lightly, and up to the author and that's, that really)
19:44:41 <michaelfolkson> luke-jr: Core has to pick a default
19:44:50 <laanwj> luke-jr: i understood that's the idea with full RBF, it drops a fair amount of policy restrictions
19:44:50 <ariard> luke-jr: if you mean simplifying our policy, this proposal is going in that sense ? but ultimately we *do* have to pickup defaults and they're free of implications
19:44:53 <luke-jr> michaelfolkson: not really; and right now, Core is forcing its "default" on users
19:44:59 <sipa> my view is generally: come up with an actual workable and worked-out policy, and propose it - beyond that it seems like a ML discussion primarily
19:45:48 <laanwj> you can't really get rid of policy entirely because we need it for anti-DoS etc
19:46:00 <sipa> at a very high level, i'm concept ack - i think it's inevitable long term that the network will tend to more rational policies, and full RBF is a step towards that
19:46:04 <luke-jr> Knots has configurable RBF, and I'm happy to re-open the Core PR if people are willing to accept/review it
19:46:05 <michaelfolkson> sipa: It has been proposed by ariard. And I think he's right to attempt a roadmap for changing it
19:46:07 <sipa> but it all depends on the details
19:46:11 <ariard> michaelfolkson: do you have a link towards achow101 BerkeleyDB deprecation plan you were mentioning offline last week ?
19:46:16 <sipa> michaelfolkson: i don't see a concrete policy, but i may have missed it
19:46:28 <sipa> "full RBF" isn't a policy, it's an aspiration :)
19:46:46 <achow101> ariard: #20160
19:46:47 <gribble> https://github.com/bitcoin/bitcoin/issues/20160 | Proposed Timeline for Legacy Wallet and BDB removal · Issue #20160 · bitcoin/bitcoin · GitHub
19:46:57 <michaelfolkson> Right ^
19:47:39 <michaelfolkson> I think a similar roadmap could be attempted for full RBF by default (though I hadn't considered configurable option)
19:47:39 <ariard> achow101: thanks, i'll look at it and see how to adapt for full-rbf, i'll open a PR soon with config knob full-rbf=false
19:47:48 <luke-jr> https://github.com/luke-jr/bitcoin/tree/fullrbf
19:47:51 <laanwj> ariard: +1
19:47:55 <michaelfolkson> There still has to be a default even with configurable option
19:47:58 <luke-jr> ariard: ^
19:48:15 <luke-jr> ariard: the code already exists, just a matter of people accepting/reviewing it for Core
19:48:22 <sipa> i have some thoughts, but i'll respond on the ML
19:48:30 <ariard> luke-jr: for now, i'll only to propose a config knob with full-rbf=false, i don't think you can configure that for now ?
19:48:48 <michaelfolkson> There will be some business opposition but if we think long term this is the right thing to do we should attempt to change it over multiple versions giving people plenty of advance warning
19:48:50 <luke-jr> ariard: yes, that's one of the 3 configurations in that branch/Knots
19:49:02 <laanwj> having a config know for it in core at all is a start
19:49:13 <laanwj> changing the default is much further away
19:49:25 <laanwj> and probably much more controversial
19:49:38 <luke-jr> mempoolreplacement=none / fee,optin / fee,-optin
19:49:46 <josibake> laanwj:+1 just adding it as a config option shouldn't be controversial, right?
19:49:54 <ariard> yes i'm still worried about the Dos against multi-party funding transactions but we have years ahead before i think it starts to be a real issue
19:49:54 <luke-jr> josibake: it was last time I tried
19:49:59 <laanwj> josibake: not to me at least, given how many people want this
19:50:12 <michaelfolkson> Right, there will be some opposition. I have tried speaking to some Lightning businesses to understand their use of Lightning zero conf channels
19:50:20 <laanwj> luke-jr: when was that? 2015?
19:50:28 <luke-jr> laanwj: probably
19:50:34 <ariard> luke-jr: ah okay for the branch, gonna look
19:50:50 <michaelfolkson> Maybe last words but I think that was wrapped up in the block size drama. I am hoping a long(ish) term plan this time around will be less controversial
19:51:32 <michaelfolkson> But we'll see. I think we should attempt this long term (over multiple major versions) transition to full RBF
19:51:40 <laanwj> luke-jr: it does seem attitudes changed a bit since then
19:51:41 <michaelfolkson> It may fail
19:51:41 <luke-jr> ariard: just pushed the latest rebase (Oct 8th)
19:51:47 <luke-jr> laanwj: great
19:51:49 <ariard> michaelfolkson: though i've been reached out privately by a exchange operator disagreeing with full-rbf after posting on the ML
19:52:11 <cfields> ariard: suggest they respond publicly :)
19:52:24 <sipa> +1
19:52:29 <michaelfolkson> Right, I think the discussion should be out in the open
19:52:47 <michaelfolkson> If people really don't want it then the attempt may fail
19:53:00 <ariard> cfields: yeah will ping them back once PR is open!
19:53:02 <michaelfolkson> Or at least summarize their arguments ariard
19:53:14 <cfields> ariard: great, thanks!
19:53:14 <michaelfolkson> We don't need to know who it is if they want to stay anonymous
19:53:23 <luke-jr> michaelfolkson: eh? it's not a consensus change
19:53:46 <luke-jr> anyone can run full RBF today if they want to. or block RBF entirely if they prefer that.
19:54:10 <michaelfolkson> luke-jr: Right but we should still consult? If people really don't want it?
19:54:19 <michaelfolkson> At least collect those arguments
19:54:22 <luke-jr> michaelfolkson: if people don't want it, they can just not enable it..
19:54:30 <laanwj> right, but it's good to give people time to adapt to it at least before changing the default
19:54:32 <sipa> luke-jr: i don't think that's a useful response
19:54:45 <sipa> luke-jr: in their mind - for good or bad reasons - the problem is others enabling it
19:54:48 <sipa> (presumably)
19:54:56 <luke-jr> sipa: but they have no say over what other people do
19:55:04 <michaelfolkson> I think generally if we expect opposition/controversy it is good to reach out
19:55:16 <michaelfolkson> Even if it isn't consensus change
19:55:20 <laanwj> no, they don't, but a default change would not be something done lightly
19:55:23 <sipa> luke-jr: which is much easier to address publicly :)
19:55:59 <luke-jr> laanwj: perhaps, but that's down the road past just an option ;)
19:56:07 <laanwj> clearly for your own nodes you can run with whatever policy you want
19:56:16 <michaelfolkson> Also whether we like it or not we are going to have to consider policy more seriously because of Lightning and higher levels
19:56:21 <laanwj> and i definitely expect miners to start acting rationally in this regard
19:56:22 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #23334: fuzz: Descriptor wallet (master...2110-fuzzWall) https://github.com/bitcoin/bitcoin/pull/23334
19:56:41 <luke-jr> michaelfolkson: anything that depends on policy for security, is broken by design
19:56:43 <sipa> laanwj: yeah, it may take a few halvings, though
19:57:08 <laanwj> i mean, it's not something you can just post a rant against on the mailing list then ignore
19:57:19 <michaelfolkson> luke-jr: It isn't optimal sure. But I still think having Lightning ecosystem is better than ignoring it
19:57:30 <luke-jr> michaelfolkson: Lightning shouldn't depend on policy
19:57:34 <michaelfolkson> But anyway, let's move it to GitHub issue an mailing list
19:57:41 <michaelfolkson> luke-jr: But it does!
19:57:49 <luke-jr> last I heard, quite a few nodes and miners already use full RBF for years
19:58:03 <luke-jr> michaelfolkson: they should fix it then, regardless of this discussion
19:58:04 <michaelfolkson> It is suboptimal but the best we can do currently for Lightning design
19:58:05 <sipa> i feel like this is a bit like the Linux mantra "don't break userspace"; userspace may be depending on un-guaranteed behavior for dumb/bad reasons, but that doesn't mean you can just go and break it
19:58:06 <ariard> luke-jr: can you make the expectation that the most economically-rational policy is going to be run in majority over the p2p network ?
19:58:37 <luke-jr> ariard: no
19:58:40 <laanwj> i'd prefer to leave it at adding an option for now as well
19:58:45 <laanwj> 1 minute to go
19:58:49 <michaelfolkson> Ok we should wrap up. Want to respect people's time
19:58:58 <michaelfolkson> Thanks
19:58:59 <laanwj> michaelfolkson: please leave time management to me
19:59:06 <michaelfolkson> Sorry :)
19:59:34 <laanwj> but you're right anyhow
19:59:49 <laanwj> #endmeeting