19:01:42 <achow101> #startmeeting 
19:01:43 <core-meetingbot> Meeting started Thu Sep  1 19:01:42 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:01:43 <core-meetingbot> Available commands: action commands idea info link nick
19:01:57 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard b10c 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 larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:01:58 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:02:00 <brunoerg> hi
19:02:02 <hebasto> hi
19:02:18 <ariard> hi
19:02:26 <lightlike> hi
19:02:27 <furszy> hi
19:02:32 <achow101> Welcome to the weekly general meeting
19:02:33 <kouloumos> hi
19:02:36 <b10c> hi
19:02:38 <jonatack> hi
19:02:50 <achow101> There are no pre-proposed meeting topics. Does anyone have any last minutes topics to discuss?
19:02:51 <sipa> hi
19:03:47 <ariard> well happy to talk about full-rbf (#25600)
19:03:49 <gribble> https://github.com/bitcoin/bitcoin/issues/25600 | p2p: Advertise `NODE_FULL_RBF` and connect to 4 outbound full-rbf peers if `-mempoolfullrbf` is set by ariard · Pull Request #25600 · bitcoin/bitcoin · GitHub
19:04:01 <ariard> (sorry for last week, was geeking out about bitcoin in meatspace at conf)
19:04:05 <achow101> let's start with the feature freeze
19:04:06 <achow101> #topic 24.0 feature freeze / milestone
19:04:06 <core-meetingbot> topic: 24.0 feature freeze / milestone
19:04:38 <achow101> Last week we decided to set a hard deadline of today
19:05:43 <gleb> hi
19:05:43 <dongcarl> Just a question: Are packaging PRs like #25975 considered feature?
19:05:44 <gribble> https://github.com/bitcoin/bitcoin/issues/25975 | contrib/init: Better systemd integration by dongcarl · Pull Request #25975 · bitcoin/bitcoin · GitHub
19:06:09 <luke-jr> dongcarl: unless there's an argument for it to be a fix?
19:06:14 <achow101> The only remaining large feature is #19602, and it looks rtm to me
19:06:16 <gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
19:06:28 <dongcarl> luke-jr: Ah okay, fix-only, got it
19:07:24 <jonatack> #25614 has gobs of review and ACKs (and doesn't change behavior)
19:07:26 <gribble> https://github.com/bitcoin/bitcoin/issues/25614 | Severity-based logging, step 2 by jonatack · Pull Request #25614 · bitcoin/bitcoin · GitHub
19:07:48 <jonatack> (would unblock progress that has been stalled for 3 months)
19:09:29 <fanquake> achow101: I think the experimental upgradewallet RPC could be good candidate for final feature merge
19:10:01 <jonatack> In any case, I think 25614 has well enough review that it can be removed from the blockers list.
19:10:36 <luke-jr> fanquake: merge it then? :p
19:10:37 <fanquake> we’ve got some time to flesh out more bugs prior to branch off. Worst case could made it more “hidden” for this release. However would be nice to get in and some amount of testing.
19:11:04 <jonatack> as review isn't what is blocking 25614
19:11:15 <fanquake> luke-jr: I’m afk for the rest of the day
19:11:41 <luke-jr> jonatack: what is?
19:12:34 <jonatack> luke-jr: someone willing to merge, i guess
19:13:10 <achow101> jonatack: I'll have a look at it.
19:13:28 <jonatack> (before, laanwj was merging the work on this)
19:13:32 <jonatack> achow101: cheers
19:13:51 <luke-jr> achow101: maybe merge yours too; I'm hesitant to +1 without reviewing it myself, but fanquake agrees with your rtm assessment, so..
19:14:03 <achow101> luke-jr: will do
19:14:44 <achow101> #topic full-rbf maximalism vs gentle phase-out of opt-in RBF (ariard)
19:14:45 <core-meetingbot> topic: full-rbf maximalism vs gentle phase-out of opt-in RBF (ariard)
19:14:51 <ariard> hey hey
19:15:30 <ariard> so about full-rbf, i'm interested to have it being functional for the node operators willing to enjoy the benefits of it, likely LN nodes for now
19:15:53 <ariard> somehow for it to be functional, you need a) full-rbf propagation paths to the miners b) few miners turning on the option
19:16:32 <luke-jr> pretty sure some miners have mined full RBF for years
19:16:33 <ariard> to solve a) there is either a.1) you connect to other full-rbf peers manually, a.2) full-rbf is turn on by default
19:16:46 <ariard> and c) preferential automatic peering (#25600)
19:16:48 <gribble> https://github.com/bitcoin/bitcoin/issues/25600 | p2p: Advertise `NODE_FULL_RBF` and connect to 4 outbound full-rbf peers if `-mempoolfullrbf` is set by ariard · Pull Request #25600 · bitcoin/bitcoin · GitHub
19:17:10 <luke-jr> ariard: or d) enough users turn on full RBF manually ;)
19:17:14 <ariard> luke-jr: there have been miners mining full rbf in the past, hard to say without more data points collected
19:17:29 <ariard> luke-jr: that's correct, that's also an option
19:18:05 <achow101> users don't tend to change defaults
19:18:06 <ariard> however, as a savy technical user, i would be more interested to have my nodes doing preferential automatic peering, and likewise any full-rbf interested node operators
19:18:09 <luke-jr> I'd have liked to see 25600 in, but it's not ready at a glance :<
19:18:27 <achow101> i would prefer preferential peering
19:18:32 <gleb> what's the objective of discussing it here? we had a bunch of discussion in the PR, do you want just more opinions? Or a more *advanced* discussion?
19:18:43 <gleb> I mean, am i supposed to repeat my comment in the PR? i dunno
19:18:43 <ariard> luke-jr: yeah just seen the comment, non-reliability of the service bit as been discussed during yesterday review club session
19:19:09 <luke-jr> policy is arbitrary node preference. it can never be reliable.
19:19:18 <ariard> gleb: just to bring the awareness of everyone the state of the discussion, there was also a review club session, and if anyone has more thoughts
19:19:25 <luke-jr> so IMO it's a dead argument against it. but there's no ACKs on the current code either  :/
19:19:47 <ariard> luke-jr: likewise tx-relay is not reliable, and still we have a p2p network
19:19:56 <luke-jr> indeed
19:19:58 <lightlike> I don't think anyone suggested to have it as early as 24.0 in any case.
19:20:12 <ariard> though one could argue we could introduce scoring of our p2p peers, in the same way LN is doing for payment paths and ensure HTLC propagation is reliable
19:20:16 <luke-jr> lightlike: well, 24.0 is adding full RBF support
19:20:20 <ariard> (won't argue that now)
19:20:36 <ariard> lightlike: yeah i agree, more for future releases
19:21:29 <ariard> in anycase, doing preferential peering, even imperfect, to increase the effiency of our policy rules could be seen as a process change in the way we're releasing policy
19:21:52 <achow101> we've done preferential peering in the past though, e.g. segwit
19:21:58 <ariard> so i think it's good to have more feedbacks on that (as I'm worried in the future we have more complex L2-and-policy interactions to handle)
19:22:13 <ariard> achow101: sure, it was for consensus though?
19:22:36 <achow101> iirc it was for both consensus and relay
19:22:54 <luke-jr> full RBF service bit is pretty established tho, I don't think it sets a precedent for future ideas
19:22:55 <achow101> so that segwit txs would be properly relayed to miners
19:22:57 <ariard> iirc, to discover enough peers relaying segwit txn
19:23:14 <luke-jr> I thought it was to find peers with segwit blocks ;p
19:24:00 <luke-jr> without access to which we'd have a consensus-level failure
19:24:03 <ariard> luke-jr: i think we could do that for package relay for 1 or 2 releases, to ensure it's robust and works well before to active for everyone
19:24:03 <instagibbs> ^
19:24:12 <ariard> but yeah that's another discussion
19:24:17 <instagibbs> (that was for luke)
19:24:49 <ariard> luke-jr: i don't remember the exact rational, will check
19:25:05 <achow101> in any case, I don't think anyone is against preferential peering?
19:25:20 <luke-jr> achow101: presumably the NACKer is
19:25:32 <ariard> luke-jr: will answer that one on the PR
19:25:40 <instagibbs> achow101, it uses more resources, or narrows the nodes you'll connect to if cannibalizing current slots
19:26:04 <lightlike> achow101: it's not so clear. Some people have expressed that they would prefer changing the default.
19:26:08 <achow101> I suppose I should actually read the pr
19:26:14 <jonatack> ariard: will look into your PR
19:26:28 <jonatack> the discussion on it looks interesting in any case
19:26:56 <lightlike> achow: e.g. https://github.com/bitcoin/bitcoin/pull/25600#issuecomment-1205481722 https://github.com/bitcoin/bitcoin/pull/25600#issuecomment-1205529190
19:28:15 <ariard> lightlike: yes, i think it's different if preferential peering is a) re-using the current outbound slots or b) consuming extra-outbound slots), in case of b) that could be seen as node operator pref in the way you're using your slots
19:28:19 <achow101> even with on by default, I would still like preferential peering as people upgrade
19:28:23 <ariard> assuming you're connecting to full-rbf signaling peers
19:28:33 <achow101> but that seems like a discussion for the pr
19:28:52 <ariard> yeah, i think that's all i wished to bring to awareness :)
19:29:03 <achow101> ok, any other topics to discuss?
19:29:49 <gleb> i was wondering
19:30:31 <gleb> ah nevermind, better ask in the pr
19:30:41 <achow101> #endmeeting