<glozow>
I've also been working on the p2p changes, making progress on TxDownloadMan fuzzing. But as discussed at coredev, waiting until the mempool stuff is finished before opening
<theStack>
hi
<josie>
hi
<glozow>
Same thing with v3 stuff - waiting until after 26711 is in
<glozow>
That's it for my updates
<Murch[m]>
glozow: I’ll start reviewing that today
<glozow>
Murch: awesome thanks :D
<achow101>
#topic BIP 324 updates (sipa)
<sipa>
hi!
<sipa>
big stuff done
<glozow>
\o/
<achow101>
what's left to do? a few followups and the tests?
<laanwj>
congrats!
<sipa>
indeed
<sipa>
and enabling by default
<laanwj>
what's the plan for that? will the first release with it will have it disabled by default?
<sipa>
laanwj: i think so
<achow101>
The tests pr is #28374? are there any open followup prs (I know the 16 byte prefix stuff was merged yesterday)?
<laanwj>
@achow101 yea imo, it's good to have it in 26.0 so enthousiasts can test it, then when there's confidence in it (likely enough to be in another 6 months) it makes sense to enable it by default
<theStack>
laanwj: +1
<achow101>
I think nothing has really changed for kernel this week, and TheCharlatan appears to not be here
<achow101>
#topic assumeutxo updates (jamesob)
<fjahr>
Not sure if jamesob is here for his victory lab ;) The big one was merged here too.
<fjahr>
There is a list of follow-ups in #28562 I will address feedback and rebase shortly.
<fjahr>
And there is #28590 from ryan which we should try to get into 26. It changes the RPC
<luke-jr>
still needs something so it doesn't display transactions as confirmed prematurely, right?
<gribble`>
https://github.com/bitcoin/bitcoin/issues/28590 | assumeutxo: change getchainstates RPC to return a list of chainstates by ryanofsky · Pull Request #28590 · bitcoin/bitcoin · GitHub
<luke-jr>
or did that get in somewhere already?
<fjahr>
luke-jr: I don't think so, I don't know what PRs we have open on that off the top of my head
<Sjors[m]>
luke-jr: it can't be used on mainnet without recompile
<fanquake>
fjahr: were you planning on including all the post-merge review from 27596 in that PR? Or will be following up with other changes?
<fanquake>
Quite a lot of post-merge review comments have been left
<fjahr>
Yeah, I will comment in 27596 and not keep adding more stuff afterwards, so it says reviewable
<Sjors[m]>
I plan to continue reviewing the original PR and then look at the followup PRs.
<fjahr>
*so that 28562 stays reviewable, it already has 9 commits, I don't want to grow it much further
<Sjors[m]>
Seems fine to have multiple followup PRs.
<luke-jr>
Sjors[m]: I assume that's the goal, though, right?
<fjahr>
There will surely be more follow-ups
<achow101>
luke-jr: can you open an issue for that problem?
<fanquake>
I think we also need to follow up with the release notes/rpc helps, and comparison to assumevalid etc Decide on exactly how this is presented.
<luke-jr>
ok
<Sjors[m]>
I haven't really tested GUI behavior for assumeutxo recently, but we should - at least before this becomes easier to use.
<fanquake>
Multiple followups is fine, as long as we don't make post-branch-off changes to things like the rpc interface
<fanquake>
Lets make sure most of that is done, if we're going to keep changing it
<sipa>
fanquake: i guess that qualifies as an error code!
<_aj_>
an assert in the gui is a bit obnoxious?
<_aj_>
(or is it caught?)
<luke-jr>
I don't think it's caught at least
<achow101>
it's at least an attended process (the user had to be there to start it, and is presumably still there)
<achow101>
for the vast majority of people, it should work correctly
<fanquake>
luke-jr: yea, i just assume some people are going to avoid it with real funds, while it's still marked experimental
<achow101>
#topic erlay (gleb)
<gleb>
I wanted to share that i'm back to work after some absence. Amiti told me she saw some interest in Erlay at core dev, so that makes sense to continue moving it forward
<sipa>
gleb: great to hear!
<gleb>
It is already reviewable (#26283 and 21515), and a couple places with data and benchmarking results. I intend to make reviewing it easier. One thing is a tracking issue with FAQ.
<gribble`>
https://github.com/bitcoin/bitcoin/issues/26283 | p2p: Fill reconciliation sets and request reconciliation (Erlay) by naumenkogs · Pull Request #26283 · bitcoin/bitcoin · GitHub
<gleb>
Do you have any initial thoughts on it? Anything particular that prevents you from reviewing to be covered?
<achow101>
tracking issue would be good
<gleb>
esp. sipa dergoegge brunoerg aureleoules ariard glozow mzumsande — those who already looked at the current PR piece.
<josie>
gleb: welcome back!
<sipa>
gleb: i'll review again after 26 branch-off
<cfields>
👋
pablomartin has joined #bitcoin-core-dev
<gleb>
Thank you.
<gleb>
For others — It’s not to late to jump on this train. Later on it might be harder to start following it
<glozow>
Nice that you're back gleb! Yeah I think a tracking issue would be great
<luke-jr>
harder in what sense?
<gleb>
Luke-jr you’ll have to review previous pr parts which are already merged.
<glozow>
I suppose a tracking issue would help with that too - people would be able to review the merged PRs if they need to catch up
<gleb>
Yeah
<lightlike>
same - I plan to get back to reviewing it in the next weeks!
<brunoerg>
same here
<gleb>
Alright, we can move on if there are no comments. Feel free to text me later on — say if you need a call to discuss the code or whatever
<gleb>
Thank you for your commitments to review.
<achow101>
#topic cmake pings (cfields)
<cfields>
Hi all. Sorry for being away for the last 2 weeks, I'll be back at my computer starting tomorrow.
<cfields>
A quick CMake announcement: At coredev we discussed pinging people individually to test CMake before merge (still a few weeks away at minimum). Not necessarily to get individual ACKS, but to do a rough check to see if your build setup will have any problems post-merge.
<cfields>
So, once hebasto and I suspect that things are in decent shape, we'll start doing pings for feedback. This is in addition to the PR review itself.
<cfields>
The goal here is to try to address developers' concerns specifically, since we tend to build with the most non-standard configs. As a random example, if you're building libbitcoinkernel on FreeBSD x86-64 for Linux risc-v, you might run into an edge-case we haven't seen yet.
<cfields>
tl;dr: if you get a ping request to try your day-to-day workflow with CMake, via IRC, Github, Signals, whatever, please please try to do so. That is a good chance to complain, not after merge :)
<luke-jr>
cfields: my build system is quite abnormal now, so I'll plan on it (might need a reminder)
<cfields>
luke-jr: ack, you'll get a ping for sure :)
Chris_Stewart_5 has quit [Ping timeout: 272 seconds]
<luke-jr>
where is the current codebase btw?
<cfields>
still a few weeks out. Just wanted to everyone to know it's coming.
<sipa>
cfields: what is the minimum supported cmake version (assuming there are no additional build dependencies or changes to minimum versions of existing one)?
brunoerg has quit [Remote host closed the connection]
Chris_Stewart_5 has joined #bitcoin-core-dev
<hebasto>
3.13
<cfields>
luke-jr: review is currently happening at hebasto's repo. There's an ubrella PR open in the core repo, but i'm not sure if it's current (sorry, I've been away this week)
<fanquake>
If branch of is Sunday, do we have a cut off for how long we are willing to wait, before merging something? i.e 1 month post, then we push it again?
<hebasto>
however, I will suggest 3.16 considering the time of merging
<fanquake>
We don't want to do this too deep into the new release cycle.
<cfields>
sipa: ^^. Definitely up for discussion if it turns out a newer vers would have big benefits though.
<fanquake>
I assume people are also already working on all the downstream intregrations etc. So that we don't end up with broken downstreams for too long.
<sipa>
the oldest system i regularly build on is an ubuntu 20.04, which has cmake 3.16
<cfields>
at coredev we said ~2 weeks after would be reasonable. That puts us about a month from now.
<hebasto>
sipa: exactly!
<fanquake>
Ok.
<cfields>
That seems reasonable to me, but I must admit I'd hoped to have this week for review and wasn't able, so I'm personally a week behind. But I'll try to catch up next week.
<achow101>
Any other topics to discuss?
<fanquake>
Yea
<cfields>
So say 4 weeks from now we decide to merge, short extension, or punt?
<luke-jr>
(on that note, should I just close #28564 or does anyone care to give it a quick review to fix current versions?)
<gribble`>
https://github.com/bitcoin/bitcoin/issues/28564 | Bugfix: configure: Correct check for fuzz binary needing a main function by luke-jr · Pull Request #28564 · bitcoin/bitcoin · GitHub
<achow101>
cfields: ack
<fanquake>
cfields: that sounds ok, just don't want scope for this to start dragging out
<hebasto>
ack :)
<fanquake>
luke-jr: all build PRs are still relevant, it's not like cmake fixes the bugs in the branches we have to maintain for the next few years
<fanquake>
so changes to the current build system are still needed, and useful
<_aj_>
were we going to start polling for priority projects?
<cfields>
fanquake: ack.
<cfields>
_aj_: ah, right.
<luke-jr>
ok, but absent additional changes, this bug amounts to a minor configure output thing IIUC
* luke-jr
shrugs
<achow101>
_aj_: next week I think
<achow101>
I guess I can put up the issue for collecting possible projects
<_aj_>
sounds good; seems like cmake is already a priority project :)
<fanquake>
_aj_: if we have to pick 3, I'd kinda hope not. We have bitcoin problems to solve heh
<_aj_>
well, if it's finished in four weeks time, nbd :)
<achow101>
darosior: sipa: any thoughts on how to deal with migrating a legacy wallet that has a hybrid pubkey?
<darosior>
Error cleanly, tell the user they must create a new descriptor wallet and send the funds there?
<achow101>
I'm leaning towards just giving an error that tells them to open an issue. it shouldn't be something that anyone actually uses
<josie>
achow101: dont
<sipa>
achow101: you'd need to have imported a hybrid pubkey manually, as watch-only (as there is no corresponding private key for it, in the CKey sense)
<darosior>
So they don't even have to send any funds
<_aj_>
as long as DEFAULT_FEE > mempool min fee, that's okay though
<darosior>
Yes
<_aj_>
at leat in my tests, when mempool min fee > child feerate, i get a reject
<darosior>
That's what i was thinking from reading the code, so `submitpackage` can be used with a package that is not a CPFP. That's what i was telling Murch[m]
<glozow>
I think some of us are thinking about the "child lower than package feerate and mempool minimum feerate" case, and some of us are just thinking about the "child lower than package feerate in general"
<sipa>
what if the child has higher feerate than the mempool, but after submitting the parent, the mempool feerate increases to be higher than the child's?
<darosior>
glozow: yes
<glozow>
sipa: LimitMempoolSize() is not called until the end of `AcceptPackage`
<glozow>
so that should not happen
<darosior>
achow101: Maybe proceed with migrating all the rest and return a warning in the command result / log about how imported hybrid keys couldn't be migrated. In my opinion this should be so rare that it's not worth going out of your way. As long as there is a clear warning / error somewhere. Worst case it's in the log they don't notice it but no funds
<bitcoin-git>
bitcoin/master 5d84693 Andrew Chow: test: Add helper functions for checking node versions
<bitcoin-git>
bitcoin/master 313d665 Andrew Chow: test: Fix 0.16 wallet paths and downgrade test
<bitcoin-git>
bitcoin/master 53f35d0 Andrew Chow: test: Remove w1_v18 from wallet backwards compatibility
<bitcoin-git>
[bitcoin] fanquake merged pull request #28027: test: Fixes and updates to wallet_backwards_compatibility.py for 25.0 and descriptor wallets (master...2023-07-test-wallet-back-compat-updates) https://github.com/bitcoin/bitcoin/pull/28027
pablomartin4btc has quit [Ping timeout: 255 seconds]
<darosior>
glozow: could you expand on your answer to sipa? How is it that you can't have a very large parent (say your mempool is 280MB, parent is 20MB) and a child whose feerate would position it at the very bottom of the mempool before accepting the parent, such as when you reach LimitMempoolSize() the child would get dropped and the minimum mempool
<darosior>
feerate increased by 1sat/vb?
<_aj_>
can't have parent/ancestors more than 400k weight?
<darosior>
The example works with smaller sizes.
* darosior
afk
<vasild>
hebasto, cfields: so, to test my workflow with cmake, should I merge hebasto/cmake-staging into some local branch of mine and then "work as usual"?
<vasild>
well, "work as usual" / modulo using cmake instead of autotools of course
<hebasto>
vasild: no, merging will cause silent conflicts
<vasild>
hum?
<vasild>
conflicts between what? there is no cmake files in master now
<hebasto>
there were changes in source file organisation
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
<vasild>
ok, this is the hebasto/230916-linear branch
<hebasto>
correct
<vasild>
is this the one to test?
<glozow>
darosior: so walking through the scenario. I assume in this situation the large parent is higher feerate than the child. Parent gets in by itself, and we exceed the 300mb maximum temporarily. If we were to do a `TrimToSize()` perhaps the minimum feerate would change, but we're not. So we submit the child, and then we call `TrimToSize` at the end and evict by worst descendant score.
<vasild>
shouldn't I also test unreviewed commits?
<glozow>
iiuc sipa's question was whether the mempool minimum feerate can change in the middle of `AcceptPackage`, and the answer is no since #28251
<hebasto>
vasild: yes. that branch is a rebase of reviewed commits
<hebasto>
and it is supposed to be new staging branch after acking
<vasild>
hebasto: ok, I can test directly hebasto/230916-linear but this is a bit boring. I want to test it together with my PR, for this I guess I should merge one way or another. git diff --stat origin/master...hebasto/230916-linear looks pretty innocent wrt to merge conflics - just ++++ lines adding cmake stuff.
<_aj_>
hebasto: what do you do to build that branch?
<hebasto>
vasild: any conflict will and a cmake error. I'll make a fresh rebase for you
<vasild>
hebasto: So, hebasto/230916-linear is based on master from Sep 12. You are worried that if there were build related changed in master after Sep 12 that are included in my local branch, then hebasto/230916-linear will not be adapted to that?
<hebasto>
correct
<vasild>
I see
<_aj_>
hebasto: how do i enable debug, Werror and c++20?
<vasild>
ok, for now I will play with hebasto/230916-linear only
<hebasto>
_aj_: `-DCXX20 -DCMAKE_BUILD_TYPE=Debug` ; Werror not implemented yet
<_aj_>
so `cd build; cmake -S ..; cd ../src; touch net.h; cmake --build ../build -j 20` seems like it works okay
<_aj_>
ccmake is pretty great
<vasild>
well, hebasto/230916-linear compiles on freebsd
<hebasto>
cool
<_aj_>
how do i tell ctest where to look if i'm in src/ rather than build/ ?
dberkelmans has joined #bitcoin-core-dev
<hebasto>
`--test-dir`
<_aj_>
-test-dir ../build ?
<_aj_>
seems to work, also seems like it orders the test by whichever took longest last time?
<hebasto>
did not check the order
<_aj_>
seems very nice, anyway
<hebasto>
thanks!
brunoerg has quit [Remote host closed the connection]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
<Murch[m]>
<darosior> "feerate increased by 1sat/vb?" <- If the child gets dropped, _if_ that child had a higher feerate than the package, the parent would then also be below the dynamic minimum feerate and would also get dropped?
<Murch[m]>
That’s why I was asking whether we generally restricted to packages where the child has a higher feerate than the package
Talkless has joined #bitcoin-core-dev
<glozow>
^it's more that the parent would have a lower descendant score than the child, so parent+child would be selected before child for eviction. We don't proactively trim everything below our new minimum.
<glozow>
No we don't explicitly enforce that
<instagibbs>
darosior in general we will be gossiping packages that arent necessarily CPFPs, and we have to handle them in a good way
<Murch[m]>
But I thought we were talking about the more narrow functionality of #27609?
<instagibbs>
Murch[m] feel free to recap your question to me, think I missed something
<Murch[m]>
If the intended purpose for making the submitpackage RPC available in this release is to give to Lightning users with commitment transactions stuck on feerates below the dynamic minimum feerate an avenue for submitting their commitment tx and a bumping child to a node, why would we care in this context about packages where the child has a lower feerate than the package?
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
<Murch[m]>
I guess you could have a construction where a grandparent tx has a high feerate, a parent tx has a low feerate, and the child has a medium feerate that is lower than the package, but then the grandparent would have been eligible by itself in the first place
Guest36 has joined #bitcoin-core-dev
<Murch[m]>
And then you could only submit parent and child which would fulfill the criteria of the child having a higher feerate than the package
Guest36 has quit [Client Quit]
<instagibbs>
it's not important for the rpc per se I guess, but when gossiping we need to support arbitrary things where a node comes back online, gets the low fee child, is missing the parent, and fetches the ancestors
<Murch[m]>
Sure, but that’s #27611, which I gather is not slated to be in v26
<instagibbs>
with a LN wallet "of course" the child will be high feerate, that's the point of the wallet logic
<glozow>
are you proposing to add this restriction to packages that are submitted via submitpackage? because that's not something you can easily check prior to calling `AcceptPackage`
<instagibbs>
26711 "merely" makes the logic for acceptance smarter to avoid edge cases, and make it safe for non-tree
<Murch[m]>
right
<Murch[m]>
And from staring a bunch at packages in the context of candidate sets and miniminer in the last year, my suspicion would be that even a lot of the edge cases with diamonds mostly trigger around situations where a parent pays for a child
<Murch[m]>
If the lowest descendant has a higher feerate than the package, wouldn’t that already preclude many/most/all of these edge cases, i.e. perhaps a decent way to shore up submitpackage for early release?
<instagibbs>
ah, you mean master + check child for higher feerate? that's not sufficient
<instagibbs>
it's in the graveyard of ideas in the tree PR IIRC
<glozow>
my point is also that this is way more involved to check than a simple topology restriction
<glozow>
you don't know what the feerates are until you pass it to validation
<instagibbs>
yeah, that too. checking topo is very cheap + easy to remove later
<instagibbs>
you need PreChecks to get fee info
<Murch[m]>
I thought packages were topologically restricted to having a single transaction descending from all other package members?
<glozow>
correct, they have to be a child with unconfirmed parents
<Murch[m]>
So wouldn’t it just amount to adding up the total package size and total package fees, and comparing that to the individual feerate of the latest descendant?
<glozow>
how are you getting the fees though
<instagibbs>
you can have weird fee structures in the subpackages
<instagibbs>
that master + child check won't catch iirc
<Murch[m]>
You mean a sub-ancestry that is self-sufficient and has a higher feerate by itself?
<Murch[m]>
glozow: Child with unconfirmed parents, or child with all unconfirmed ancestors?
<glozow>
parents
<instagibbs>
maybe not, I've been focusing on 26711 and the comments look pretty stale unfortunately. things are really non-obvious
<Murch[m]>
So the problem case would be if you had two parents and one has a high feerate and the other has a low feerate, and the child would have a lower feerate than the package?
<Murch[m]>
And we’d reject the package because the child fails the criteria, even though the high-feerate parent would be self-sufficient and then from the remainder the child would be of course higher feerate than the secnd parent?
<instagibbs>
no, we'd accept the high feerate parent first in individual evaluation
<glozow>
No I think worst case scenario is accepting a below-minfeerate child (as illustrated in that example)
<Murch[m]>
My suggestion would be that the example you linked would be rejected because the child has a lower feerate than the package
<glozow>
(that's not something we need to solve for the RPC imo, which I think people agree with)
<instagibbs>
I'm not sure that would be sufficient, is my point. Tree topo is, and 26711 subsumes it
<sipa>
So is the idea that 26711 only changes things for non-tree topologies?
<glozow>
Well, 26711 also allows all ancestor packages, so a 3-generation tree is now permitted when it wasn't before
<instagibbs>
for tree topos, the eval should be very close yes
<instagibbs>
parents evaluaated one by one, then child, if all parents succeeded
<instagibbs>
or all parents didnt get disallowed*
<instagibbs>
s/succeed/dont fail for non-fee related reasons/
<sipa>
i have a slightly uncomfortable feeling that this RPC access is being rushed, and i'd like to just see 26711 make it in instead
<Murch[m]>
I see, so the point that I’m missing is that even in the experimental submitpackage RPC we want to support situations in which subsets of the package are eligible
<sipa>
but i'm still trying to wrap my head around what the additional restrictions in 27609 mean... if it's the case that 26711 only changes things for things that 27609 doesn't permit anyway, then it obviously doesn't matter
<instagibbs>
hm?
<glozow>
Murch: I don't think your suggestion is a restriction that we can easily tack on / remove later, as you'd need to do it within validation. I also don't think it's sufficient as you can still add another tx under the diamond with the same feerate as the package
<glozow>
26711 would not change things for a child-with-parents package that is tree-shaped
<sipa>
glozow: ok, thanks
<Murch[m]>
aah, I see what I was missing
<bitcoin-git>
[bitcoin] achow101 opened pull request #28602: descriptors: Disallow hybrid and uncompressed keys when inferring (master...migrate-hybrid-keys) https://github.com/bitcoin/bitcoin/pull/28602
<glozow>
that being said I wouldn't want to propose the RPC if it makes people uncomfortable
<Murch[m]>
We have the topology of the package because we see the outpoints being spent by descendants of other transactinos, but we don’t know the amounts of the spent UTXOs because we’d have to first look up the UTXOs and thus we can’t get the fees
* Murch[m]
facepalms
<_aj_>
trying to think about 26711 at the same time doesn't seem super helpful; the rpc just takes a super simple case (some unreleated parents and a child) and allows them to be added as a package. all the complex topologies are just disallowed
<instagibbs>
Murch[m] yeah you need `PreCheck`s for that
<instagibbs>
deep in eval territory
<glozow>
Murch: 👍
<Murch[m]>
So it’s easy to restrict to parents + child, or only tree but no diamond, but not easy to check for the feerate
<Murch[m]>
gotcha
<glozow>
Yeah to be clear, the restriction of child+parents only is already in there
<glozow>
However, given the fact that parents can spend parents, child-with-parents is not that much simpler than tx-with-ancestors when thinking about edge cases.
<glozow>
That's why 26711 is so big, haha
<Murch[m]>
Yeah, but in #27609 we do not allow parents to spend other parents, right?
<bitcoin-git>
bitcoin/master a9ef702 Ryan Ofsky: assumeutxo: change getchainstates RPC to return a list of chainstates
<bitcoin-git>
bitcoin/master 0b2c93b Andrew Chow: Merge bitcoin/bitcoin#28590: assumeutxo: change getchainstates RPC to retu...
<bitcoin-git>
[bitcoin] achow101 merged pull request #28590: assumeutxo: change getchainstates RPC to return a list of chainstates (master...pr/getchain) https://github.com/bitcoin/bitcoin/pull/28590
mudsip has joined #bitcoin-core-dev
mudsip has quit []
OP_NOP has joined #bitcoin-core-dev
OP_NOP has quit [Ping timeout: 240 seconds]
jonatack has quit [Ping timeout: 255 seconds]
jonatack has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<bitcoin-git>
[bitcoin] achow101 closed pull request #20892: tests: Run both descriptor and legacy tests within a single test invocation (master...better-descriptor-tests) https://github.com/bitcoin/bitcoin/pull/20892
abubakarsadiq has joined #bitcoin-core-dev
pablomartin4btc has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Zenton has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 246 seconds]
vysn has quit [Remote host closed the connection]
brunoerg has quit [Remote host closed the connection]
jQrgen has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
bugs_ has quit [Quit: Leaving]
brunoerg has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
<bitcoin-git>
bitcoin/master 5b9087a glozow: [rpc] require package to be a tree in submitpackage
<bitcoin-git>
[bitcoin] achow101 merged pull request #27609: rpc: allow submitpackage to be called outside of regtest (master...open-submitpackage) https://github.com/bitcoin/bitcoin/pull/27609
bitdex has joined #bitcoin-core-dev
benwestgate has quit [Quit: Leaving.]
brunoerg has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] achow101 opened pull request #28604: test: Use feerate higher than minrelay fee in wallet_fundraw (master...fix-fundraw-test-intermittent) https://github.com/bitcoin/bitcoin/pull/28604