19:00:45 <laanwj> #startmeeting 
19:00:59 <jarolrod> hi
19:01:01 <ariard> hi
19:01:02 <dergoegge> hi
19:01:04 <hebasto> hi
19:01:04 <stickies-v> hi
19:01:06 <NorrinRadd> Hi
19:01:07 <glozow> hi
19:01:08 <achow101> hi
19:01:10 <brunoerg> hi
19:01:14 <lightlike> hi
19:01:20 <luke-jr> hi
19:01:27 <laanwj> #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
19:01:29 <laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:31 <laanwj> hi
19:01:32 <kanzure> hi
19:01:37 <vasild> hi
19:01:47 <instagibbs> hi
19:02:01 <LarryRuane> hi
19:02:15 <_aj_> hi
19:02:48 <ajonas> hi
19:03:09 <laanwj> four meeting topics have been proposedin advance this time: Drop GUI repo and bring GUI work back to the main repo for now (achow101), Adding (more) maintainers as GitHub org owners (achow101), Moratorium on refactors that are not part of larger projects that bring tangible features and fixes (achow101), defer fullrbf for 24.0(or not) (instagibbs)
19:03:41 <laanwj> any last minute ones?
19:03:57 <b10c> hi
19:04:38 <laanwj> #topic High priority for review
19:04:39 <core-meetingbot> topic: High priority for review
19:04:59 <laanwj> https://github.com/orgs/bitcoin/projects/1 has 4 blockers, 6 chasing concept ACK
19:05:07 <laanwj> anything to add/remove?
19:05:37 <LarryRuane> could you add #16981 for me?
19:05:39 <gribble> https://github.com/bitcoin/bitcoin/issues/16981 | Improve runtime performance of --reindex by LarryRuane · Pull Request #16981 · bitcoin/bitcoin · GitHub
19:06:01 <furszy> hi
19:06:25 <laanwj> LarryRuane: added
19:07:19 <sipsorcery> hi
19:08:09 <kouloumos> hi
19:08:12 <laanwj> btw PSA: rc2 binaries were uploaded a few days ago, please help testing https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide
19:08:23 <dergoegge> #25515 has quite a few concept acks now, so no longer chasing i guess
19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/25515 | net, test: Virtualise CConnman and add initial PeerManager unit tests by dergoegge · Pull Request #25515 · bitcoin/bitcoin · GitHub
19:08:41 <laanwj> dergoegge: move it to blockers?
19:08:45 <dergoegge> sure
19:08:55 <stickies-v> LarryRuane: should we wait with (re-)reviewing until you've added the benchmark test, as you just announced?
19:09:20 <LarryRuane> yes good idea, thanks
19:10:12 <bitcoin-git> [bitcoin] NorrinRadd opened pull request #26356: test: Use a consistent assert functions: ref #23119 (master...issue/23119/part-1) https://github.com/bitcoin/bitcoin/pull/26356
19:10:36 <laanwj> #topic Drop GUI repo and bring GUI work back to the main repo for now (achow101)
19:10:36 <core-meetingbot> topic: Drop GUI repo and bring GUI work back to the main repo for now (achow101)
19:11:11 <jarolrod> i don't have a strong opinion on wether we move in the development from bitcoin-core/gui into bitcoin/bitcoin
19:11:25 <achow101> I was speaking with some contributors last week at CoreDev about repo separation, and some dissastisfaction with the current GUI repo split was discussed. In particular, some contributors felt that the separation makes it difficult to work on the GUI as it is not that obvious that there is a separate GUI repo. This has lead to things in the GUI repo getting little review since many forget that it even exists. It is also confusing to new
19:11:26 <achow101> contributors as the GUI is in the main repo, so work can be done in a fork of the main repo before realizing that the GUI repo exists. There was also a concern about funding as some funders may not recognize that the GUI repo is in fact part of Bitcoin Core.
19:12:27 <luke-jr> a fork of the main repo can push to the GUI repo just as well…
19:12:41 <achow101> While I agree that we should want to have components of Bitcoin Core separated into separate repos, I think doing so now is premature. We should perhaps wait until it is possible to fully separate componenets before doing so. That way, cloning the main repo does not fetch the GUI repo, and work on each specific component requires going to each individual repo to even get the code.
19:12:49 <vasild> it is somewhat confusing for me too
19:12:51 <glozow> fanquake is asleep, so i'm relaying this gist from him on the topic https://gist.github.com/fanquake/2448cfac814c633c9109670ed4152ea8
19:12:52 <luke-jr> and funding issues should be sorted out at the funding level, which really should not be specific to Core at all, much less a single repo :/
19:12:52 <hebasto> quoting fanquake from oct 15 "I think merging GUI development back into the main repo would quite be a regression. As far as I'm aware, for non-GUI contributors, it's been a great filter for keeping all the not-related-to-bitcoin GUI stuff out of their inboxes (probably similar for the thousands of bitcoin/bitcoin subscribers)."
19:13:01 <laanwj> it's mostly to have the PRs and issues separate, we can't really move them back
19:13:23 <hebasto> agree with fanquake
19:13:27 <jarolrod> The reality with gui development is that sometimes trivial things are discussed or trivial pr's are opened, if it's really annoying for some to see these discussions pop up, then it's best to keep the repo's as they are
19:13:34 <laanwj> it would involve closing everything and reopening it in the main repo, which, yeah seems a lot of hassle
19:13:38 <luke-jr> I don't feel strongly for keeping them split, but I don't think all the reasons are great for a re-merge
19:13:39 <ariard> i think you're point is bundling few different things: a) a communication issue about the component existence, b) the management of interdependency and c) the social/professional recognition of working on the GUI
19:13:39 <achow101> luke-jr: AFAICT GitHub does not allow you to open PRs unless the repo is a direct fork
19:13:50 <luke-jr> achow101: you can still push your git repo to the fork of the GUI
19:14:16 <achow101> luke-jr: yes, but this may be confusing to new contributors
19:14:39 <hebasto> re "is not that obvious that there is a separate GUI repo" it is clearly documented, starting from https://github.com/bitcoin/bitcoin/blob/master/README.md
19:14:54 <achow101> hebasto: personally there are some gui things that I would like to review, but they always fall off my list because I forget it's existence
19:14:57 <luke-jr> perhaps better docs?
19:15:02 <luke-jr> and/or getting Github to fix it
19:15:09 <luke-jr> if we move to Gitlab, does that resolve it?
19:15:13 <achow101> I would find it easier if its issues and prs would be in the same repo
19:15:15 <laanwj> add a link in the top-level README maybe?
19:15:32 <laanwj> if there isn't, i wouldn't know
19:16:01 <achow101> I don't think "user education" (dev education I guess) is really a good solution. It's just not intuitive
19:16:29 <ariard> achow101: tbh, few contributors have already to live in a multi repo world, in the sense monitoring libsecp256k1, the bips repo, the bolts repo, maybe a lightning implem, maybe bitcoin-inquisition, sounds more a question of personal time-management
19:18:44 <jarolrod> I would be ok with either option, but in terms of not redoing a time of work moving between repo's, I'd think that we should keep the repo's as they are
19:18:53 <jarolrod> another point brought up was on the qml gui and the future of the gui
19:18:56 <brunoerg> jarolrod: +1
19:18:59 <jarolrod> information on that has been condensed here: https://bitcoincore.app/
19:19:14 <jarolrod> development on bitcoin-core/gui-qml has been slow, at times it's only been me working on it, but that is where the future of the gui is
19:19:24 <jarolrod> What I can promise is i'll be spending as much time as possible as I can to finish this before the next release, it doesn't mean we'd include it in core at that time, but the conversation can start on what we're going to do with the gui in terms of the development process and the structure of repo's
19:19:39 <jarolrod> We're building something special there, if you're interested in seeing how we're progressing you can join in on our calls every wednesday at 14 UTC here: https://meet.jit.si/BitcoinCoreAppDesignCall
19:19:47 <achow101> re trivial stuff in gui: I don't think that's a strong argument. we get lots of dumb and trivial stuff in the main repo too
19:20:17 <achow101> I don't think it would be any more annoying than it already is
19:20:25 <hebasto> merging repos is going to bring more dissatisfaction among developers then now...
19:20:26 <luke-jr> jarolrod: I'm against prematurely deciding QML is going to replace Widgets..
19:20:50 <jarolrod> ^ of course, not dictating, just my opinion :D
19:21:40 <achow101> ariard: for the most part, those repos don't share any code. right now, the main repo and the gui repo are completely clones of each other, so if you want the gui, you can still get it in the main repo. this is not the case for the others you mentioned
19:21:58 <achow101> my point was that repo separation should follow with code separation
19:22:11 <luke-jr> achow101: I don't think you've made a strong argument for that
19:22:24 <luke-jr> half of the reasons seem frankly like reasons _to_ keep them separated
19:23:02 <laanwj> right it's just an organizational thing, so you an ignore GUI stuff if you want to
19:23:10 <achow101> people forget that it exists and it's harder for new contributors is a reason to keep them separate??
19:24:33 <ariard> achow101: at least, they share libsecp256k1; though my point was more an answer to "oh wait i've to remember there is a GUI repo" thought, it sounds to belong more to one's workflow and personal priorities
19:24:38 <laanwj> if new contributors file a GUI pr/issue in the main repo it's not a big deal they usually just get pointed to the right one
19:24:43 <luke-jr> achow101: no, those are the arguments to re-merge; but ultimately problems better dealt with other ways even then
19:25:18 <luke-jr> I need to go pick up kids from school; but FWIW: there are some maintainers I don't trust with org ownership (and others I would); no opinion on refactor freeze; and against "anti-feature" fullrbf changes
19:26:15 <furszy> I personally haven't seen much movement on the current GUI repo, which pulled me down from continue contributing there. Not sure if that is because of the separated repository or because all our resources are focused on the QML project (which make sense if we are just going to replace the GUI entirely)
19:26:16 <laanwj> there's still 3 other topics left, we might want to move to a next one
19:26:30 <glozow> (meta-meeting comment: i wonder if we'll run out of time to discuss v24.0 full rbf? not to discount achow's proposed topics, but perhaps worth reordering based on urgency...?)
19:26:58 <laanwj> glozow: agree
19:27:04 <NorrinRadd> achow101 would it help if the gui code is removed from the main report and instead referenced?
19:27:05 <ariard> glozow: +1, we're already half-meeting time, and other subjects could be post-pone to next meetings
19:27:09 <achow101> glozow: yes (my topics are not urgent)
19:27:19 <instagibbs> glozow, sounds like volunteering to take on the topic]
19:27:25 <instagibbs> logs off
19:27:44 <NorrinRadd> anecdote: I'm a very new comer and I came across the documentation that teh gui is maintained in a different repo
19:28:03 <achow101> NorrinRadd: I think so. If we could get to a point where the gui could be removed from the main repo, and put into it's own repo with just the gui, then I think repo separation makes sense there
19:28:33 <laanwj> yes, true gui repo separation would definitely be better
19:28:47 <laanwj> i think that's something to work towards, not going backwards
19:28:59 <hebasto> our release process should be modified for that
19:29:04 <glozow> agree working towards true separation would be great
19:29:07 <jonatack> hi
19:29:18 <laanwj> hi
19:30:31 <laanwj> ok, ew can continue this next meeting if needed, going for next topic
19:30:36 <laanwj> #topic defer fullrbf for 24.0(or not) (instagibbs)
19:30:36 <core-meetingbot> topic: defer fullrbf for 24.0(or not) (instagibbs)
19:30:45 <instagibbs> mempoolfullrbf in mainnet(or not): #26323 does two things: disables mempoolfullrbf on mainnet until ~6 months from now, then switches the argument to default true. The intention was to get it into 24.0 This needs to be decided
19:30:47 <gribble> https://github.com/bitcoin/bitcoin/issues/26323 | Make full RBF default, but defer mainnet enablement by ajtowns · Pull Request #26323 · bitcoin/bitcoin · GitHub
19:31:28 <ariard> this mail published today is a good resume of the alternatives and dimensions of analysis https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021075.html
19:31:33 <instagibbs> specifically the "disable on mainnet" or not part, due to release. I have my own opinion, and there are many others of course
19:31:33 <achow101> nack-ish. I don't like that I can't turn it on before the flag day.
19:32:48 <ariard> instagibbs: i think there are still voices of 0confs operators who sounds to oppose full-rbf itself, maybe a preliminary concern to think about before the deployment method we pick up
19:33:25 <instagibbs> ariard, I feel pretty safe not stalling to people who dont understand it's changing eventually
19:34:00 <achow101> I feel like we had this conversation 7 years ago
19:34:43 <instagibbs> Anyways, this is about the release specifically. If there's general consensus against disabling, we should just say we're not doing that
19:34:52 <instagibbs> then work on part 2 which is flag day window/strategy
19:34:57 <ariard> instagibbs: i think this is reasonable outcome, evaluating we have done a satisfying work of communication ahead, and those folks are running after a subject already reaching majority of opinions
19:35:05 <ariard> just notifiying the existence of those voices
19:35:08 <_aj_> achow101: wasn't the result of the conversation 7 years ago that people who wanted rbf would opt-in to it, per bip 125?
19:35:31 <instagibbs> I'd rather not relitigate, this is about 24.0 :)
19:36:53 <instagibbs> If we need more time to discuss flag day, we need more time to discuss it and should just work that direction
19:37:06 <ariard> i don't think 7 years ago the pinning issues which are affecting lightning/coinjoins and have been the original technical motivation of this renewed full-rbf deployment  were known by the community, to be fair
19:37:47 <achow101> I don't mind a flag day so long as it is _only_ to change the default to true. a flag day for disabling the option is nack from me
19:38:10 <achow101> but then in that case, it doesn't seem to be much different from just releasing 25.0 with -mempoolfullrbf=1
19:38:16 <instagibbs> so I motion to keep arg static and false, and continue conversation about flag day
19:39:01 <jonatack> (fwiw, i found the serge kotliar (bitrefill) ML post on the topic (relating to FX volatility in addition to zero conf) interesting as well, though i haven't finished parsing it; suggest reading it along with the post by dario (muun wallet) regarding zero conf
19:39:17 <glozow> I think whatever option we take, it should be made abundantly clear to users that Core does not control whether full RBF happens or not. We could revert 25353 and it could still happen. We could do a flag day activation and it could happen sooner than that. I imagine that a coordinated full RBF activation is the smoothest/safest if everybody reasonable agrees to it, but then others might yell at Core for "dictating policy."
19:39:34 <ariard> let's phrase the discussion in another way; do we think the activation of full-rbf X months from now would cause unsolvable dangers for 0confs apps/services ?
19:39:42 <instagibbs> achow101, heck 26.0. It's simpler yes
19:39:56 <ariard> in the sense, do we think the issues raised by full-rbf on their services, are technicall solvable if they allocate the engineering and operational efforts
19:41:04 <achow101> ariard: I think all of the issues these services have raised are solvable, with the most basic solution that most services have decided to use being wait for a confirmation
19:41:24 <instagibbs> "solve the free option problem" is a bit out of scope for Core
19:41:40 <glozow> the free option problem is already a thing, according to Sergej's ml post
19:41:44 <_aj_> ariard: for muun, which is lightning focussed anyway; 6 months sounds fine; for bitrefill, seems like it would take 2 years or more to get lightning adoption high enough to be smooth
19:41:54 <_aj_> ariard: (going from what they've said on list)
19:42:06 <instagibbs> _aj_, it would tie policy directly to a specific L2 protocol, so I nack on any metric like this
19:42:23 <ariard> instagibbs: to me, that's a bit of the crux of the discussions between core and business, what is the scope of policy mechanisms and from what they should be responsible of?
19:42:34 <_aj_> instagibbs: huh?
19:42:58 <instagibbs> _aj_, "my deposits must be X% in this specific type"
19:43:06 <ariard> _aj_: yes, the last muun replied also underscore other 0confs services, with less manpower/engineering resources might need more time
19:43:09 <_aj_> instagibbs: it'd tie policy to having some replacement for on-chain zeroconf; with lightning being the most likely replacement
19:43:29 <_aj_> instagibbs: if fedimint or something comes along and takes over in the meantime, that's fine too?
19:43:35 <instagibbs> failed TTP business-y ideas have been around for almost 8 years
19:43:46 <glozow> ariard: the technical issues are solvable, it sounds like muun just wants more time. Bitrefill is able to detect payment replacements and already has some double spend protections, the problem there is UX
19:44:34 <ariard> glozow: i'm converging, though note a bad UX might be a source of users funds loss or freezing or mistakes, especially if they have to shipped it fast
19:44:57 <instagibbs> _aj_, well, if they said "2 years", maybe I'd be fine
19:45:11 <glozow> i mean they also told me they had revert using bech32 addresses because most users couldn't pay them
19:45:17 <glozow> back in the day
19:45:36 <_aj_> instagibbs: ziggamon just said "years", definitely not 2
19:45:47 <instagibbs> _aj_, 1.01 years
19:45:52 <ariard> on the other hand, advocating the coinjoin/lightning-side, the pinning vector has been exercised on mainet https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020737.html
19:46:23 <ariard> and as we see more collaboritve constructions applications, we could deanonymizing attackers leveraging this vector during the next X months/years period of full-rbf transition, just saying
19:47:26 <ariard> s/collaboritve/collaborative/g
19:49:23 <NorrinRadd> have the workarounds for 0 conf operators been documented in any one place where they can be easily referenced?
19:49:41 <_aj_> there aren't workaround, though?
19:49:47 <ariard> NorrinRadd: no single point documentation i'm aware of
19:50:09 <ariard> _aj_: distributed monitoring of network mempools, Bitrefill does something like this iiuc
19:50:32 <_aj_> ariard: they do that for txs that don't opt-in to rbf; things that are rbf-able just get excluded from zeroconf
19:50:53 <NorrinRadd> 'waiting for confirmation' doesn't seem desirable.  stores with large foot traffic would have people standing around for an hour sometimes waiting for their payment to confirm.
19:51:36 <NorrinRadd> if bitrefill is waiting to see if replacement transactions appear, then they're essentially not doing zero conf anymore?
19:52:10 <ariard> _aj_: so i'm following correctly, if full-rbf happens and all the incoming transaction traffic is repleacable such protection would still allow to accept 0conf traffic
19:52:12 <NorrinRadd> _aj_ oh thanks
19:52:57 <NorrinRadd> so once everything is rbf it would effectively kill their zero conf transactions.
19:53:15 <ariard> okay as we're reaching end of meeting, do we think we prefer to go with a smooth, uncoordinated deployment or a flag day activation ?
19:53:34 <instagibbs> achow101, makes a reasoanble point, why not just flip it for future release
19:53:39 <instagibbs> like.... 26.0
19:53:41 <ariard> #26305 or #26323
19:53:42 <gribble> https://github.com/bitcoin/bitcoin/issues/26305 | Enable `mempoolfullrbf=1` by default by ariard · Pull Request #26305 · bitcoin/bitcoin · GitHub
19:53:44 <gribble> https://github.com/bitcoin/bitcoin/issues/26323 | Make full RBF default, but defer mainnet enablement by ajtowns · Pull Request #26323 · bitcoin/bitcoin · GitHub
19:53:56 <_aj_> ariard: at the moment, 15% of their txs are lightning, 20% are opt-in rbf, and the remaining 65% aren't rbf-able. of the 65% -- 60% are treated as zeroconf, 5% are excluded from zeroconf due to negative signals from the monitoring. with fullrbf, that entire 65% gets excluded from zeroconf, and lightning is the only way to get instant confirmations
19:53:59 <achow101> 26305 for a future release
19:54:19 <instagibbs> right
19:54:34 <_aj_> if we're not going to remove the mempoolfullrbf option from 24.0, we're going for an uncoordinated deployment either way
19:54:48 <instagibbs> im already running full rbf with preferential peering...
19:55:12 <instagibbs> ship has sailed, the question is will 5%+ set a variable. I suspect not
19:55:20 <ariard> _aj_: that's a correct, though i don't think it's something like binary, more uncoordinated with the option existent or something like preferential peering
19:56:31 <_aj_> instagibbs: uasf uacomment demonstrated it's easy to get ~11% to set a variable in just a couple of weeks
19:56:37 <lightlike> i think that if a meaningful number of node operators and miners want a specific policy, it shouldn't be on the devs to tell them "you can't have that now". Devs can and should give a recommendation (by picking the default), but providing options to informed users should never be a problem.
19:57:00 <bytes1440000> if 24.0 has mempoolrbf, devs have lot of time to discuss and convince a few nodes and miners to run it. no default required or will have better insights.
19:57:01 <laanwj> lightlike: +1
19:57:01 <bytes1440000> making default on signet, testnet still makes sense for testing
19:57:02 <instagibbs> _aj_, exception that proves the rule
19:57:07 <ariard> _aj_: about the 65% aren't rbf-able, what i don't understand is if Bitrefill is aware that you can still double-spend not rbf-able transactions, it's just higher technical bar?
19:57:23 <ariard> (well i think they're aware of, what they say is they don't see that happening)
19:57:46 <vasild> lightlike: +1
19:57:56 <ariard> lightlike: that was the original thinking with #25600
19:57:58 <_aj_> ariard: "can" equates to "less than a 0.0001% chance of it actually happening" according to ziggamon
19:57:59 <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:58:42 <bytes1440000> 25600 is the worst possible way to make fullrbf default
19:58:54 <instagibbs> 2 minutes
19:58:59 <ariard> _aj_: so according to that statement, they might be still be fine to not exclude this future 65% traffic from zero-conf acceptance
19:59:13 <_aj_> ariard: no
19:59:17 <b10c> i think only having an option defaulting to false for 24 (no preferable peering) won't result in a lot of node operators actually enabling it. Especially if no Umbrel/RaspiBlitz/etc enables it by default
20:00:22 <NorrinRadd> someone can link to a document that shows the arguments for fullrbf?
20:00:26 <laanwj> we'll have to close the meeting in a minute... but feel free to continue afterwards ofc
20:00:26 <instagibbs> We'll put a blanket ban on hats in the interim
20:00:57 <ariard> _aj_: let me read again Sergej mails, what's Bitrefill position if full-rbf become the norm? (we might def invite 0confs operators to irc meetings)
20:01:35 <ariard> NorrinRadd: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
20:01:53 <glozow> ariard: my impression is an agreement that it is inevitable, but if it happens before users have a lot of access to LN, it might just make Bitcoin worse
20:02:39 <lightlike> b10c: I think enabling it for the miners is more critical anyway. Anyone could set up some manually adjusted full-RBF nodes that make hundreds of outbound connections  to all reachable peers at quite low costs.
20:03:50 <NorrinRadd> ariard i read it.  it basically kills zero conf but he also said there's something worse; replacements will be further incentized by changes in exchange rates, where customers will adjust their sats paid lower if bitcoin goes up in price after the purchase was made.  which creates business risk for the zero conf merchants.
20:04:08 <NorrinRadd> ariard thank you
20:04:28 <ariard> glozow: and letting dual-funded lightning channels susceptible to a DoS vector might slow down further the access to LN, maybe a bit of "chicken-and-eggs" here...
20:05:29 <ariard> NorrinRadd: yeah see instagibbs thought expressed earlier, is fiat volatility risk really in the scope of Core, dik
20:05:30 <glozow> ariard: i agree.
20:05:32 <ariard> idk
20:06:10 <NorrinRadd> Sergej did also mention that when they've asked people to pay in bech32 before, instead of filing issues, they simple left the site.  so his thought is that if he's asking customers for LN, they will not seek out an LN wallet.  They'll simple leave and go somewhere else.
20:06:26 <glozow> quoted from Sergej's post about the american call option, "It's already possible to execute this form of abuse with opt-in RBF"
20:06:48 <instagibbs> I noted that its in their incentive structure to CPFP if the price goes their way...
20:07:06 <instagibbs> Merchants can only offload so much of their business complexity to others, sorry
20:07:15 <ariard> NorrinRadd: i can opinate here, deploying a LN infrastructure server-side is a hard requirement on merchants, managing funds safety/liquidity, a different key management, hopefully we don't centralize the merchant ecosystem with short-timed full-rbf deployment
20:07:37 <_aj_> instagibbs: easy to diss on stakeholders that aren't present...
20:08:01 <instagibbs> not a diss, and I've personally discussed this issue with sergej many times
20:08:47 <ariard> _aj_: i share the sentiment, sounds we don't have the right crowd to have a best-informed technical view
20:08:50 <instagibbs> We just have different goals, and that's ok!
20:10:19 <instagibbs> when goals conflict, we try for maximum understanding, and that's what we're doing I hope
20:10:22 <jonatack> it may still be good to have this discussion with them present and participating
20:10:37 <ariard> okay as it would be better to end the meeting at some point, i'm thinking to reply to last Dario's mail, saying while full-rbf is still liked people, there is no emergening majority opinion on the deployment method and what's an adequate timeframe would still benefit from more feedbacks from the merchant community
20:10:39 <jonatack> instagibbs: yes!
20:10:46 <instagibbs> the email thread is pretty high quality
20:11:01 <glozow> i guess something that should be said is "for the people who want to turn full rbf on their own nodes, does it matter if the -mempoolfullrbf option doesn't go in v24.0?"
20:12:41 <ariard> glozow: i think full-rbf setting is already used by at least one electrum server operator, and few other services
20:14:25 <laanwj> #endmeeting