14:00:09 <achow101> #startmeeting 14:00:16 <glozow> hi 14:00:18 <RubenSomsen> hi 14:00:20 <hebasto> hi 14:00:20 <murch[m]> Hi 14:00:23 <fjahr> hi 14:00:24 <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:27 <Sjors[m]> hi 14:00:29 <brunoerg> hi 14:00:33 <darosior> hi 14:00:34 <furszy> hi 14:00:36 <vasild> hi 14:00:52 <gleb> hi 14:00:56 <achow101> There are 2 pre-proposed meeting topics, any last minute ones to add to the list? 14:01:04 <kanzure> hi 14:01:14 <RubenSomsen> I'll do another silent payments update 14:01:41 <achow101> #topic package relay updates (glozow) 14:01:43 <sipa> hi 14:01:49 <glozow> 2 PRs are open for review: #28848 and #28948. 14:01:50 <glozow> The game plan is in 2 tracks mempool and p2p: v3 (#28948), then package RBF for 1p1c (#25038), then EA (#26403). And 1p1c package relay (#28970), then more robust orphan resolution (#28031), then orphanage protection. 14:01:52 <gribble> https://github.com/bitcoin/bitcoin/issues/28848 | bugfix, Change up submitpackage results to return results for all transactions by instagibbs ÷ Pull Request #28848 ÷ bitcoin/bitcoin ÷ GitHub 14:01:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow ÷ Pull Request #28948 ÷ bitcoin/bitcoin ÷ GitHub 14:01:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow ÷ Pull Request #28948 ÷ bitcoin/bitcoin ÷ GitHub 14:01:57 <gribble> https://github.com/bitcoin/bitcoin/issues/25038 | policy: nVersion=3 and Package RBF by glozow ÷ Pull Request #25038 ÷ bitcoin/bitcoin ÷ GitHub 14:01:59 <gribble> https://github.com/bitcoin/bitcoin/issues/26403 | policy: Ephemeral anchors by instagibbs ÷ Pull Request #26403 ÷ bitcoin/bitcoin ÷ GitHub 14:02:00 <gribble> https://github.com/bitcoin/bitcoin/issues/28970 | [WIP] p2p: opportunistically accept 1-parent-1-child packages by glozow ÷ Pull Request #28970 ÷ bitcoin/bitcoin ÷ GitHub 14:02:04 <gribble> https://github.com/bitcoin/bitcoin/issues/28031 | Package Relay 1/3: Introduce TxDownloadManager and improve orphan-handling by glozow ÷ Pull Request #28031 ÷ bitcoin/bitcoin ÷ GitHub 14:02:54 <theStack> hi 14:03:38 <_aj_> hi 14:03:43 <glozow> The very exciting thing is weâÂÂll have 1p1c package relay at the end of this. And then cluster mempool! 14:03:52 <b10c> hi 14:04:02 <achow101> cool 14:04:49 <achow101> #topic silent payments updates (RubenSomsen) 14:05:02 <RubenSomsen> Still actively taking review on BIP352, responding to feedback, and wanting review on #25273. 14:05:04 <gribble> https://github.com/bitcoin/bitcoin/issues/25273 | wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101 ÷ Pull Request #25273 ÷ bitcoin/bitcoin ÷ GitHub 14:05:21 <RubenSomsen> A change we're considering in outpoint hashing (to make things simpler for hardware wallets) has an issue with forced collisions (worst case is address reuse), a possible fix is being discussed at https://github.com/bitcoin/bips/pull/1458#discussion_r1395934177 14:05:31 <RubenSomsen> Could use more eyes on that 14:05:55 <sipa> fwiw, we've been having some of our cluster mempool discussions on delving: https://delvingbitcoin.org/c/implementation/wg-cluster-mempool/9 14:06:02 <maxedw> hi 14:06:27 <murch[m]> Nice to see the discussion accessible in public! 14:07:19 <achow101> #topic multiprocess updates (ryanofsky) 14:09:11 <achow101> looks like the tracking issue was updated and several new PRs have been opened 14:09:44 <achow101> #28921 seems to be next 14:09:46 <gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky ÷ Pull Request #28921 ÷ bitcoin/bitcoin ÷ GitHub 14:09:52 <ryanofsky> Hi, yes there are a few new prs opened 14:10:27 <ryanofsky> Currently working on a design doc which I want to post in a new PR this week 14:10:57 <ryanofsky> Tracking issue is https://github.com/bitcoin/bitcoin/issues/28722 if anyone is looking what to review 14:11:57 <achow101> #topic Ad-hoc high priority for review 14:12:03 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:12:48 <gleb> can you add #28765? 14:12:51 <gribble> https://github.com/bitcoin/bitcoin/issues/28765 | p2p: Fill reconciliation sets (Erlay) by naumenkogs ÷ Pull Request #28765 ÷ bitcoin/bitcoin ÷ GitHub 14:13:25 <achow101> gleb: added 14:13:30 <gleb> thanks 14:13:59 <_aj_> #27432 has concept acks, could be dropped from there, presumably? 14:14:01 <gribble> https://github.com/bitcoin/bitcoin/issues/27432 | contrib: add tool to convert compact-serialized UTXO set to SQLite database by theStack ÷ Pull Request #27432 ÷ bitcoin/bitcoin ÷ GitHub 14:14:01 <maflcko> Can I have #28924 ? (It is a blocker for a bugfix) 14:14:03 <gribble> https://github.com/bitcoin/bitcoin/issues/28924 | refactor: Remove unused and fragile string interface from arith_uint256 by maflcko ÷ Pull Request #28924 ÷ bitcoin/bitcoin ÷ GitHub 14:14:41 <hebasto> #26762 seems almost rtm? 14:14:43 <gribble> https://github.com/bitcoin/bitcoin/issues/26762 | bugfix: Make `CCheckQueue` RAII-styled (attempt 2) by hebasto ÷ Pull Request #26762 ÷ bitcoin/bitcoin ÷ GitHub 14:14:53 <achow101> _aj_: maflcko: done 14:15:02 <maflcko> thanks 14:15:10 <theStack> can i have #28336 added? 14:15:12 <gribble> https://github.com/bitcoin/bitcoin/issues/28336 | rpc: parse legacy pubkeys consistently with specific error messages by theStack ÷ Pull Request #28336 ÷ bitcoin/bitcoin ÷ GitHub 14:15:22 <achow101> hebasto: yes, going to try to get to that soon 14:15:42 <murch[m]> Chasing concept acks: https://github.com/bitcoin/bitcoin/pull/27877 14:15:44 <hebasto> achow101: thanks 14:15:45 <achow101> theStack: done 14:15:49 <murch[m]> Also, related to my topic later 14:15:54 <_aj_> achow101: #28592 should be easy to review, and basically RTM 14:15:55 <gribble> https://github.com/bitcoin/bitcoin/issues/28592 | p2p: Increase tx relay rate by ajtowns ÷ Pull Request #28592 ÷ bitcoin/bitcoin ÷ GitHub 14:16:35 <achow101> murch[m]: done. _aj_: will look 14:16:49 <murch[m]> Thanks 14:17:43 <theStack> achow101: thx 14:18:02 <achow101> #topic Deficient coin selection behavior at high feerates (murch[m]) 14:18:35 <murch[m]> The mempool hasnâÂÂt cleared since end of April, and generally the blockspace market has seen a lot of demand in that time. 14:19:01 <murch[m]> We recently had a period of time when the feerates peaked above 300â¯ṩ/vB, but they generally were significantly higher than usual for long stretches this year. 14:19:06 <instagibbs> _aj_ might be helpful to know what the potential downsides are to the PR (I have not thought about this stuff deeply) 14:19:47 <murch[m]> Bitcoin Core wallet currently uses three different coin selection algorithms and generates up to ~12 candidate input sets from those in the first attempt, then picks the least wasteful among those per the waste heuristic. 14:19:48 <_aj_> instagibbs: ie, why there's a limit at all? 14:20:29 <instagibbs> _aj_ ð 14:20:29 <murch[m]> However, when wallets have a very large UTXO pool, it may be that even the "least wasteful" candidate set uses a ton of inputs. 14:21:12 <murch[m]> We recently had another user submit disbelief when their Bitcoin Core wallet used over 500 inputs at a feerate of 75â¯sat/vB, when they had multiple UTXOs that could have funded the transaction by itself. 14:21:40 <murch[m]> This wallet behavior is unexpected to users and can cause significant unnecessary cost 14:22:31 <murch[m]> While adding a different coin selection algorithm would be a new feature and therefore not something that weâÂÂd put out in a point release, could we please at least aim to improve this behavior by the time of the next release? 14:23:17 <sipa> concept ack, but the devil is in the details 14:23:17 <murch[m]> I have had a pull request open with #27877 since July that would minimize the weight of the input set on transactions over 30â¯sat/vB 14:23:19 <gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus ÷ Pull Request #27877 ÷ bitcoin/bitcoin ÷ GitHub 14:23:29 <Sjors[m]> Why don't any of the three algo's come up with a more sane result? 14:24:13 <murch[m]> BnB doesnâÂÂt always have a solution, Knapsack optimizes for the least overshoot, i.e. minimizes the difference in satoshis between target+min_change and selection amount, and SRD is random. 14:24:39 <murch[m]> If you have a huge number of UTXOs, with a few large ones, BnB might strike out, and the other two just give back crap. 14:24:53 <murch[m]> It is by the way my opinion that Knapsack is utterly useless and should be destroyed. 14:25:20 <theStack> :D 14:25:45 <murch[m]> And especially at high feerates e.g. above 30 sat/vB or 50 sat/vB, the wallet should be more thrifty for the sake of our usersâ financial outcome. 14:25:59 <achow101> ack CoinGrinder, ack delete knapsack :) 14:26:36 <sipa> Sjors[m]: there is a difficulty here, i think, because the waste metric (which we nomiminally optimize for) doesn't account for "wallet composition health" so there is a concern that having something too minimizy might actually "win" (by waste metric) too much and result in a terrible wallet utxo set over the long term 14:27:29 <murch[m]> Anyway, if people agree that itâÂÂs insane our wallet might use 500+ inputs above 75 sat/vB, when a single one suffices, I would appreciate if such people consider taking a look at #27877 which has been chasing concept review since July 14:27:29 <achow101> I'm slightly concerned that users are going to always want to use CoinGrinder since it should always produce small input sets, at the expense of grinding coins to dust 14:27:31 <gribble> https://github.com/bitcoin/bitcoin/issues/27877 | wallet: Add CoinGrinder coin selection algorithm by murchandamus ÷ Pull Request #27877 ÷ bitcoin/bitcoin ÷ GitHub 14:27:34 <murch[m]> Thanks :) 14:28:02 <sipa> coingrinder is much better at finding small inputs, but i'm a bit concerned that if we'd always enable coingrinder, long term wallets would degrade for exame 14:28:51 <murch[m]> I have another idea, which would limit the input set to use 3 more inputs than the minimal necessary by iterating over a random shuffle of the UTXO pool and dropping the UTXOs with the least effective value until it has sufficient 14:29:09 <murch[m]> IâÂÂll probably be opening a PR with that in the next couple weeks 14:29:26 <fjahr> i guess there needs to be a plan for the extreme case where we never go below 30 sat/vB again (or whatever the limit will be) 14:29:35 <achow101> murch[m]: have you run simulations with CoinGrinder? 14:29:51 <murch[m]> A very fragmented wallet would then probably end up using 3 more inputs than necessary, which would at least be a net-negative of 2 UTXOs per transaction (after accounting for the change) and it should be much simpler to review 14:30:10 <vasild> murch[m]: picking the one input instead of the 500 ones would create smaller/cheaper tx now, but does this not delay the usage of the 500 smaller inputs? it is inevitable, we would have to use them at some point. Plus at 80sat/vbyte maybe the best time to do that if the fee rates have been e.g. 150 sat/vbyte one week before and will be 150 one week later, e.g. 80 may be a temporary dip where it 14:30:16 <vasild> is good to spend the 500 small inputs 14:30:57 <achow101> vasild: unfortunately we haven't figured out how to accurately predictthefuture 14:30:58 <murch[m]> vasild: Yes, if this point were the lowest feerate it would be good to use many, but thatâÂÂs not even true across the last few weeks 14:31:08 <sipa> vasild: always using the largest utxo(s) necessary would result in smallest input set right now, but in the long term, grind down your wallet utxos to dust 14:31:22 <murch[m]> Feerates have been going below 30â¯sat/vB nightly, and about a month ago were below 15 sat/vB every day 14:31:30 <vasild> sipa: yes 14:31:36 <murch[m]> When the feerates are high, we should use few UTXOs, but many utxos at low feerates 14:31:58 <sipa> but on the other hand, at times of extremely high fee, nobody is going to want to pay for a hihe excess in input set just for some abstract long term wallet health concern - the price for it is just too high 14:32:08 <murch[m]> Always using largest first is a terrible strategy, as I have show with my master thesis in 2016 14:32:27 <vasild> my point is "high" and "low" is relative, don't bind that to actual numbers, e.g. 75 is "high", because over time 75 may become the new "low" 14:32:33 <murch[m]> CoinGrinder does not use largest first, it uses the input set with the least weight, and on ties prefers the one with a lower total amount 14:32:47 <_aj_> 500 inputs seems like a lot even when feerates are low 14:32:58 <instagibbs> 500 inputs is like.. we need a consolidate rpc 14:33:08 <sipa> vasild: we have the long-term fee estimate whose algorithm is currently "return 10 sat/vb;", but in theory, this value influences the waste metric 14:33:22 <_aj_> instagibbs: "sendall" 14:33:38 <murch[m]> vasild: Yes, youâÂÂre right in principle, but 75 sat/vB is a high feerate across the last year, including the last few months. 14:33:40 <sipa> vasild: coingrinder in the current PR triggers based on a multiple of the long-term feerate estimate 14:33:50 <instagibbs> _aj_ that is triggered by utxo health metric or something :P 14:34:34 <_aj_> instagibbs: "bitcoin-cli wallet-wizard" - evaluates the health of your wallet utxos, and autoconsolidates 14:34:40 <sipa> i think i like this "look for randomish solution not exceeding N extra inputs over optimal" idea more than coingrinder, as i don't think it needs guards like "only at high feerate" 14:35:10 <sipa> instagibbs: if we'd have a wallet health metric we could optimize for it directly 14:35:51 <murch[m]> Yeah, we can bikeshed over the exact strategy later, I mainly just would like to see if people agree that people unintentionally consolidating their wallet at high feerates is a bug 14:36:19 <sipa> i guess that is a bug, though not a regression 14:36:41 <achow101> I think we've known about this bug for about a decade 14:37:02 <_aj_> murch[m]: bug/misfeature, sure 14:37:10 <sipa> well i think it has become more concrete - it's been known since forever that coin selection is suboptimal 14:37:21 <fjahr> what sipa said, yes, but the devil is in the details 14:37:38 <sipa> but "it's spending two orders more UTXOs than necessary at very high feerate" is still something else than "suboptimal" 14:38:47 <_aj_> sipa: "do your utxo sizes follow a log-normal distribution" would be my guess at a metric 14:39:08 <murch[m]> Yeah, personally IâÂÂd be pretty pissed if my wallet spent 25â¯mBTC in fees more than necessary. 14:40:07 <achow101> #topic Stratum v2 (Sjors[m]) 14:40:29 <Sjors[m]> Basically I plan to take over #27854 14:40:32 <gribble> https://github.com/bitcoin/bitcoin/issues/27854 | [WIP] add a stratum v2 template provider by ccdle12 ÷ Pull Request #27854 ÷ bitcoin/bitcoin ÷ GitHub 14:40:43 <Sjors[m]> I already managed to rebase it, will make a PR shortly. 14:40:55 <sipa> Sjors[m]: oh cool 14:40:55 <Sjors[m]> And then actually try understand what it's doing and read the spec :-) 14:41:14 <Sjors[m]> I have a little vintage s9 to test with too. 14:41:41 <achow101> have you talked to the original author? 14:42:52 <Sjors[m]> Nobody has in the past several months unfortunately 14:43:01 <Sjors[m]> I did talk to the Stratum v2 folks on their discord. 14:43:14 <Sjors[m]> There's a newer branch by Fi3 that I'm starting from. 14:43:24 <sipa> Sjors[m]: i'd at least comment on the PR to announce your intention 14:43:47 <fjahr> apparently jonatack spoke with them: https://github.com/bitcoin/bitcoin/issues/28642#issuecomment-1765248677 14:44:37 <Sjors[m]> Yes, and we can even leave that PR open for a bit. 14:45:00 <fanquake> sounds like someone has spoken to them in the past several months then? 14:45:05 <fanquake> and the response was "a six-month window for refactoring, adding a lot more tests and structuring the proposed changes in a way that is easier for contributors to review sounds doable to me." 14:45:13 <fanquake> what's the impetus to take the PR over? 14:45:45 <fanquake> Or is the above no-longer true, and the author no-longer working on it? 14:45:59 <Sjors[m]> fanquake: Pavlenex asking me to 14:46:36 <achow101> fanquake: he hasn't really responded to any of the previously left review 14:47:32 <maflcko> I think it would be better if you offered to the author to help or take it over. Just opening an alternative and closing seems a bit rushed, without any prior communication. 14:47:51 <sipa> yeah, i think it'd be good to discuss the plan, whatever it is, on the currently open PR 14:48:23 <sipa> maybe there is a miscommunication, or unclear expectations, because from that comment linked to, it doesn't sound like the author has given up on it at all 14:48:43 <Sjors[m]> Miscommnication is certainly possible. 14:48:49 <sipa> but the lack of activity is worrying 14:48:55 <Sjors[m]> I'll leave a link to my branch on that PR and wait to see what happens. 14:49:32 <achow101> any other topics to discuss? 14:49:43 <Sjors[m]> This is the branch people are currently testing with: https://github.com/bitcoin/bitcoin/compare/master...Fi3:bitcoin:PatchTemplates 14:50:15 <Sjors[m]> Last commit from original author on that one is Oct 26, which isn't ages agao. 14:50:36 <sipa> right 14:52:14 <achow101> #endmeeting