19:01:43 <laanwj> #startmeeting 19:01:43 <core-meetingbot> Meeting started Thu Jun 16 19:01:43 2022 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings. 19:01:44 <core-meetingbot> Available commands: action commands idea info link nick 19:02:05 <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:02:07 <laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 19:02:12 <achow101> hi 19:02:37 <luke-jr> hi 19:02:54 <laanwj> welcome to the weekly general bitcoin-core-dev meeting 19:03:03 <ariard> hi 19:03:10 <jeremyrubin> hi 19:03:31 <laanwj> there have been no topics proposed in advance (you can propose topics at any time during the week with #proposedmeetingtopic) 19:03:37 <laanwj> any last minute ones? 19:03:59 <ariard> yes, full-rbf: what should be the color of the bike and the number of cycles :) 19:04:36 <laanwj> hehe 19:05:12 <laanwj> let's start with high prio as usual 19:05:19 <laanwj> #topic High priority for review 19:05:19 <core-meetingbot> topic: High priority for review 19:05:48 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 has 8 blockers, 2 chasing concept ACK 19:05:58 <laanwj> anything to add / remove? 19:06:21 <laanwj> i think #22558 is getting close 19:06:23 <gribble> https://github.com/bitcoin/bitcoin/issues/22558 | psbt: Taproot fields for PSBT by achow101 ÷ Pull Request #22558 ÷ bitcoin/bitcoin ÷ GitHub 19:08:13 <laanwj> #23443 and #24232 need rebase 19:08:19 <gribble> https://github.com/bitcoin/bitcoin/issues/23443 | p2p: Erlay support signaling by naumenkogs ÷ Pull Request #23443 ÷ bitcoin/bitcoin ÷ GitHub 19:08:23 <gribble> https://github.com/bitcoin/bitcoin/issues/24232 | assumeutxo: add init and completion logic by jamesob ÷ Pull Request #24232 ÷ bitcoin/bitcoin ÷ GitHub 19:08:43 <laanwj> and #21702 19:08:46 <gribble> https://github.com/bitcoin/bitcoin/issues/21702 | Implement BIP-119 Validation (CheckTemplateVerify) by JeremyRubin ÷ Pull Request #21702 ÷ bitcoin/bitcoin ÷ GitHub 19:10:29 <laanwj> #24058 hasn't had review for quite a while, it definitely needs some more eyes on it, same for #23443 i think 19:10:33 <gribble> https://github.com/bitcoin/bitcoin/issues/24058 | BIP-322 basic support by kallewoof ÷ Pull Request #24058 ÷ bitcoin/bitcoin ÷ GitHub 19:10:36 <gribble> https://github.com/bitcoin/bitcoin/issues/23443 | p2p: Erlay support signaling by naumenkogs ÷ Pull Request #23443 ÷ bitcoin/bitcoin ÷ GitHub 19:11:28 <laanwj> but if there's no other suggestions, let's move on 19:11:44 <laanwj> #topic full-rbf: what should be the color of the bike and the number of cycles (ariard) 19:11:45 <core-meetingbot> topic: full-rbf: what should be the color of the bike and the number of cycles (ariard) 19:12:00 <luke-jr> I don't think BIP 322 itself is ready 19:12:11 <laanwj> luke-jr: right 19:12:40 <ariard> so #25353 is proposing to introduce a `-fullrbf` option 19:12:42 <gribble> https://github.com/bitcoin/bitcoin/issues/25353 | Add a `-fullrbf` node setting by ariard ÷ Pull Request #25353 ÷ bitcoin/bitcoin ÷ GitHub 19:12:46 <laanwj> ok so we have two competing PRs for fullrbf now 19:13:07 <ariard> there have been a lot of eyes, on both to the best of my understanding the diff between the 2 are: 19:13:15 <ariard> a) the name of the option and config args 19:13:43 <ariard> and b) the range of the options 19:14:17 <ariard> i believe in #25353, there is one demand to potentially add a `-disableRBF` by the same occasion 19:14:20 <gribble> https://github.com/bitcoin/bitcoin/issues/25353 | Add a `-fullrbf` node setting by ariard ÷ Pull Request #25353 ÷ bitcoin/bitcoin ÷ GitHub 19:14:23 <luke-jr> #25373 is just the RBF options supported since 2016 19:14:24 <gribble> https://github.com/bitcoin/bitcoin/issues/25373 | Support ignoring "opt-in" flag for RBF (aka full RBF) by luke-jr ÷ Pull Request #25373 ÷ bitcoin/bitcoin ÷ GitHub 19:14:49 <ariard> like i said in #25373, as long as we had a `fullrbf` option, i'm happy 19:14:51 <gribble> https://github.com/bitcoin/bitcoin/issues/25373 | Support ignoring "opt-in" flag for RBF (aka full RBF) by luke-jr ÷ Pull Request #25373 ÷ bitcoin/bitcoin ÷ GitHub 19:15:03 <ariard> there is also a more deeper question of recactoring a bit the mempool settings code 19:15:08 <luke-jr> it doesn't make sense to special-case each configuration as a dedicated option 19:15:24 <ariard> s/recactoring/refactoring/g 19:15:48 <sipa> i expect that over time we'll only want the most incentive-compatible option, though i don't know when that'll be 19:16:10 <luke-jr> sipa: that's one opinion, and shouldn't have a monopoly 19:16:21 <luke-jr> sipa: also, incentives vary; miners vs non-miners in this case 19:16:35 <sipa> sure, every node operator is free to implement whatever policy they want, but that doesn't need to mean we need to support anything anyone can come up with 19:16:42 <ariard> luke-jr: could you precise, do you mean each _imaginable_ replacement policy shouldn't have a dedicated option? 19:16:52 <sipa> why not? node operators will want to have policy that matches miners' policies 19:17:06 <luke-jr> ariard: I mean for mutually exclusive policies, a single option makes sense with multiple values 19:17:23 <luke-jr> sipa: no, miners will want to have policy that matches nodes' policies 19:17:37 <ariard> luke-jr: here i agree, i don't think to implement `mempoolrbf=disable,full` for 25353 19:18:10 <sipa> luke-jr: I don't think that makes sense. If there is a tangible economic benefit for both miners and wallets to use a certain policy, it will be adopted. If full nodes choose to ignore it for their own mempools, they'll be bypassed. 19:18:13 <sipa> And then everyone is worse off. 19:18:31 <ariard> luke-jr: in anycase, core is a software for both node and miners operators, what's the dynamics of the bitcoin system w.r.t policy adoption are beyond the scope of the discussion? 19:18:34 <luke-jr> sipa: compact blocks was only acceptable because miners are incentivised to match nodes' policies, and not vice-versa. 19:18:36 <sipa> The incentives for transaction relay are very different than for block acceptance. 19:19:42 <sipa> I don't think this discussion is going anywhere. 19:20:06 <achow101> imo mempoolreplacement is not a good name 19:20:21 <achow101> unless the idea is to have replacement policies other than rbf 19:20:32 <laanwj> well, we have optin 19:20:55 <ariard> do we have people who really want disablerbf ? not even optin 19:21:06 <luke-jr> achow101: mempoolreplacement is the name it's always used.. and makes sense, since non-fee-based policies exist 19:21:09 <laanwj> no 19:21:29 <sipa> adding an option for full-rbf makes sense to me, and discussions around experimenting with wallets using it. I don't care about the name, but I don't think we should spend much time about accomodating even more policies right now 19:21:32 <luke-jr> ariard: I don't have any way to tell if anyone uses it with Knots 19:21:40 <laanwj> sipa: +1 19:21:59 <laanwj> i do think the option name should be prefixed with mempool though 19:22:07 <ariard> okay, good if anyone has more ideas on the name setting, please express so on 25353 19:22:12 <achow101> luke-jr: considering that the option currently does not exist in the codebase, I would not say "always" 19:22:13 <ariard> yeah, prefix good 19:22:34 <luke-jr> achow101: it's in older Core versions, and has been in Knots the entire time 19:22:50 <ariard> i won't consider `disablerbf` for 25353, if we think `disablerbf` isn't worthy 19:22:53 <laanwj> apart from that, yes, it seems what could have been a simple quick to mereg PR has been hijacked by bikeshedding and competing PR 19:23:20 <luke-jr> ariard's being the competing one. I don't know why there was a desire to rewrite what has existed for years.. 19:24:12 <ariard> okay, i'll take the refactoring suggestion in 25353 19:24:12 <luke-jr> and then even make it incompatible needlessly 19:24:38 <ariard> luke-jr: should we OTS our PR opening next time :p ? 19:24:39 <laanwj> incompatible with an option that hasn't existed for years 19:24:50 <luke-jr> laanwj: yes, it has 19:25:01 <laanwj> luke-jr: in your implementation, not core 19:25:02 <achow101> the args manager makes the option that has beenremoved for years to already be incompatible 19:25:04 <luke-jr> gratuitous incompatibility seems like a recurring problem in Core. 19:25:11 <achow101> it literally errors on unknown options 19:25:19 <laanwj> achow101: right 19:25:22 <luke-jr> achow101: not in the config file 19:25:42 <laanwj> ok, any other topics? 19:26:02 <luke-jr> ariard: original PR is #7219 19:26:05 <gribble> https://github.com/bitcoin/bitcoin/issues/7219 | Make RBF policies optional by luke-jr ÷ Pull Request #7219 ÷ bitcoin/bitcoin ÷ GitHub 19:26:07 <laanwj> or, would anyone like to talk about what they're working on? 19:26:39 <sipa> Not much has changed on what I'm working on compared to the last time we did this. 19:27:01 <fanquake> IâÂÂve made some LTO related progress, and am circling back to musl builds 19:27:16 <sipa> What are the prospects around musl? 19:27:26 <ariard> luke-jr: sure, i think what matters between our 2 PRs, which are really equivalent, is making things well encapsulated 19:27:42 <fanquake> sipa: My current PR will build you a fully static musl based bitcoind 19:28:00 <sipa> Nice. Does the binary also work? ;) 19:28:05 <fanquake> Still need to expand it for all hosts, building on non x86-64 etc 19:28:23 <fanquake> I have done a sync with the binary ð 19:28:29 <laanwj> haha :) 19:29:07 <laanwj> but great to hear that 19:30:05 <laanwj> fully static LTO'ed binaries are getting closer 19:30:28 <sipa> Great. 19:30:51 <ariard> oh, i've a message from gleb who can't log in the chan apparently.. 19:30:58 <ariard> gleb "I just wanna mention that we had a good momentum with #23443 getting acks or near-acks from antoine and gloria, but then kinda lost it a month ago :( " 19:31:01 <gribble> https://github.com/bitcoin/bitcoin/issues/23443 | p2p: Erlay support signaling by naumenkogs ÷ Pull Request #23443 ÷ bitcoin/bitcoin ÷ GitHub 19:31:02 <fanquake> and we can build those with a from src bootstrapped Guix 19:31:11 <ariard> "I will rebase tomorrow, and the review is very very welcome to make progress on the first batch, perhaps one or two pair of extra eyes could make a big difference" 19:31:31 <ariard> (sorry for the interruption) 19:31:55 <fanquake> ariard: thanks for the update 19:32:36 <laanwj> yes, thanks for the update, the IRC problem is strange, maybe not logged into nickserv? 19:33:05 <ariard> yeah dunno what he's done with his IRC setup, i'll relay 19:33:52 <laanwj> we had to enable posting for only logged in users, because of anonymoous off topic drive-by posting, a while ago 19:34:49 <laanwj> i think that concludes the meeting, thanks for the updates! see you next week 19:34:52 <laanwj> #endmeeting