<bitcoin-git>
[bitcoin] aureleoules opened pull request #24804: Sanity assert GetAncestor() != nullptr where appropriate (master...assert_get_ancestor_rebase) https://github.com/bitcoin/bitcoin/pull/24804
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
rex4539 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 240 seconds]
yanmaani has quit [Ping timeout: 240 seconds]
yanmaani has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
rex4539 has quit []
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
mekster66949 has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
mekster66949 has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
Guest64 has joined #bitcoin-core-dev
Guest64 has quit [Client Quit]
hashfunc14a0 has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
hashfunc14a0 has quit [Ping timeout: 260 seconds]
dviola has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
dviola has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
dviola has quit [Max SendQ exceeded]
dviola has joined #bitcoin-core-dev
dougefish has quit [Ping timeout: 250 seconds]
sipsorcery has joined #bitcoin-core-dev
vysn has quit [Quit: WeeChat 3.4]
dougefish has joined #bitcoin-core-dev
<vasild>
timediff stats from my node: almost all are +/- a few seconds, and 6 peers are +/- ~60 seconds
jonatack has quit [Ping timeout: 272 seconds]
dviola has quit [Ping timeout: 246 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 248 seconds]
dviola has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
<fanquake>
have invited https://github.com/t-bast to the orgs, so it's easier to requests package related reviews
bomb-on has quit [Ping timeout: 256 seconds]
sipsorcery has quit [Ping timeout: 248 seconds]
dviola has quit [Ping timeout: 248 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 246 seconds]
gribble has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
jonatack is now known as Guest7037
gribble has joined #bitcoin-core-dev
z3r0day has joined #bitcoin-core-dev
<z3r0day>
kanzure: biggest attack on bitcoin is gatekeepers like you
z3r0day has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest7037 has quit [Quit: Connection closed]
jonatack has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
<laanwj>
fanquake: sgtm
<MarcoFalke>
Hi, catching up on yesterdays meeting. My thinking is that removing network time from addrman is largely not risky, as it shouldn't affect your node's ability to connect to peers and sync blocks and txs.
<MarcoFalke>
I didn't open a consensus change for adjusted time, as I want to think more about it and collect data points.
<MarcoFalke>
Maybe we can open a data-point collection issue to share findings? Obviously taking into account #23695 to filter the data appropriately.
<vasild>
What about environments where the user running bitcoind does not have root access on the machine and thus not in control of the system clock / fixing ntp?
<vasild>
some limited hosting may be like that, but also most smartphones? Maybe too exotic to worry about...
<_aj_>
vasild: they also can't email someone with root access?
dviola has joined #bitcoin-core-dev
<vasild>
_aj_: yeah, probably one could ask the admin/root user to fix the clock
<_aj_>
vasild: or find a new hosting provider, or find an LD_PRELOAD shim that corrects the time
<vasild>
:)
dviola has quit [Ping timeout: 246 seconds]
<jonatack>
planning to add a timeoffset column to the -netinfo dashboard (for my own use, at least) to get more of an idea of behavior
dviola has joined #bitcoin-core-dev
<jonatack>
most all my inbounds have offsets
bomb-on has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 246 seconds]
Guest57 has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
greypw2546 has quit [Quit: I'll be back!]
greypw2546 has joined #bitcoin-core-dev
<_aj_>
jonatack: really? i have 17x -1 offset, and 43x 0 offset, for currently connected peers
dviola has quit [Ping timeout: 248 seconds]
Guest57 has quit [Quit: Client closed]
dviola has joined #bitcoin-core-dev
<_aj_>
get occassional connections that have the date hardcoded to 2019-12-12T01:57+00:00
<jonatack>
25 of 27 yesterday after the meeting, 24 of 27 now, various ip/tor/i2p/cjdns, some of them are peers that i know. but i'd like to look at it in more detail, e.g. breakdown by network or peers that i know versus unknown ones
<_aj_>
tor/etc probably should have a few seconds offset just due to lag?
<jonatack>
possibly yes but i haven't looked further than the jq
<laanwj>
jonatack: heh, i don't think we should put that in a release, adding the timeoffset to netinfo gives the wrong idea that this information is important (beyond this particular survery)
dviola has quit [Ping timeout: 260 seconds]
dviola has joined #bitcoin-core-dev
<jonatack>
laanwj: yes, just a patch branch for myself and anyone else
yanmaani has quit [Ping timeout: 240 seconds]
bomb-on has quit [Ping timeout: 246 seconds]
dviola has quit [Ping timeout: 246 seconds]
dviola has joined #bitcoin-core-dev
<laanwj>
vasild: smartphones tend to have various time sync sources (GSM, GPS, ...), if anything they're probably more precise in timekeeping on average than consumer PCs
jonatack has quit [Quit: Connection closed]
<laanwj>
as for VPSes and containers that don't allow setting the time, and have it drift, that's a really lousy VPS and it's probably a bad idea to run a bitcoin node on it, expecting user-space software to work around kernel level problems is pretty unreasonable
yanmaani has joined #bitcoin-core-dev
meshcollider has quit [Changing host]
meshcollider has joined #bitcoin-core-dev
<vasild>
laanwj: right
<laanwj>
dhruv: #24792 bumping secp256k1 probably helps with BIP324? (i see it conflicts with about every BIP324 PR but don't know if they're the same changes)
<bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #24697: refactor: Use type-safe time for address relay (master...2203-refactor-addr-relay-time-🌦) https://github.com/bitcoin/bitcoin/pull/24697
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jonatack has joined #bitcoin-core-dev
<fanquake>
laanwj: there’s a shared commit for fixing the MSVC build. Otherwise mine is some build cleanups
mekster66949 has quit [Quit: Ping timeout (120 seconds)]
mekster66949 has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
<MarcoFalke>
Is it time to tag rc4? I think all known bugs are fixed?
dviola has joined #bitcoin-core-dev
<MarcoFalke>
If nothing else comes up, we could tag final on April 20th or so
dviola has quit [Max SendQ exceeded]
dviola has joined #bitcoin-core-dev
<laanwj>
yes, sgtm
<laanwj>
though I think it would benice to have #24770 in
<gribble>
https://github.com/bitcoin/bitcoin/issues/24770 | Put lock logging behind DEBUG_LOCKCONTENTION preprocessor directive by jonatack · Pull Request #24770 · bitcoin/bitcoin · GitHub
<laanwj>
i'm still not comfortable with the try_lock/lock on every lock in the release
mudsip has joined #bitcoin-core-dev
<fanquake>
I think you aren't the only one
<fanquake>
We could have that in as the last backport, baring no other issues. The other 2 PRs could be removed from the 23.0 milestone.
<laanwj>
so let's review that quickly and merge it and backport it and do rc4
<laanwj>
agree
<laanwj>
i suppose we just didn't get agreement (or even enough people to care to be for or against) on #24294
<gribble>
https://github.com/bitcoin/bitcoin/issues/24294 | RPC: Switch getblockfrompeer back to standard param names blockhash and nodeid by luke-jr · Pull Request #24294 · bitcoin/bitcoin · GitHub
mudsip has quit [Client Quit]
<fanquake>
I think it was bought up quite late, and the "new" names are probably fine. There's a weak NACK, and also a NACK for the usage of nodeid
<laanwj>
right
<_aj_>
no response to the nodeid comments. could open an alternate PR to just change block_hash
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke closed pull request #24294: RPC: Switch getblockfrompeer back to standard param names blockhash and nodeid (master...getblockfrompeer_param_names) https://github.com/bitcoin/bitcoin/pull/24294
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
that's ok, but i don't think we want to block rc4 on that
mekster66949 has quit [Ping timeout: 272 seconds]
<MarcoFalke>
So all places that consume a block hash are named blockhash?
<_aj_>
yeah
<_aj_>
MarcoFalke: (btw, re #24697 it would probably be even better to use std:chrono:clocks so that we have type checking on whether we're using mockable time or a steady clock (for scheduling eg). better to get rid of adjustedtime first though imo)
<MarcoFalke>
Eh, I don't know what to do. One is saying I should change adjusted time before, another is saying I should do it after the refactors. Guess I'll open two conflicting pulls and let reviewers decide?
<jonatack>
yes wrt blockhash, the block_hash arg came about from my getblockfrompeer review feedback, based on how I read the RPC interface guidelines in the developer notes. maybe they could be clarified (i don't plan to tho :)
<MarcoFalke>
Personally I find it easier after the refactors, as it can be done with a scripted-diff
<laanwj>
MarcoFalke: if this is the first introdcutino of a new parameter name for an existing thing it makes sense to avoid it
<MarcoFalke>
ok, maybe someone can open a pull for that?
<laanwj>
but only if we can just agree on it, not if it's going to be bikeshedding all the way
<laanwj>
ah yes the only other occurence of block_hash on the RPC interface is "window_final_block_hash" in a result
<_aj_>
MarcoFalke: not sure if i'm confused because of multiple threads; so will restate. using "std::chrono::microseconds now" is great, but having "mockable_time::now()" generating a std::chrono::time_point would be even better, so that we have type checking to differentiate "now" that's a mocktime and "now" that's used for the scheduler.
<MarcoFalke>
_aj_: The "Eh, ..." was in reply to "better to get rid of adjustedtime first though imo"
<_aj_>
MarcoFalke: but the std::chrono::*seconds stuff now is fine, and getting rid of adjustedtime now so we don't have 3+ different clocks to try to implement seems sensible
Guest2213 has joined #bitcoin-core-dev
<MarcoFalke>
I mean, if we change to ::clock, it might be better to do it right away. Rather than changing all 300 lines twice
<_aj_>
let me see if i can find the old branch i had
mekster66949 has joined #bitcoin-core-dev
<laanwj>
is monotonic time appropriate here at all? it's only used for durations, not to compare against absolute time values?
<MarcoFalke>
Don't we have arg aliases? Can do blockhash|block_hash
<laanwj>
MarcoFalke: but why
<MarcoFalke>
sorry, wasn't serious
<_aj_>
laanwj: we need monotonic-ish time for the scheduler and iirc some low-level net things
<laanwj>
_aj_: oh for the scheduler ! yes
<fanquake>
if no-one else wants to, i'll just cherry-pick the commit and drop the nodeid change
<fanquake>
then we can merge than and the lock change
<fanquake>
and tag rc4
<_aj_>
ack
<fanquake>
great
<laanwj>
_aj_: i don't think monotonic time makes sense in the places adjusted time is used right now, which are timestamps coming from the network, but sure that makes sense
<laanwj>
ack
<jonatack>
mentioned it, as adjustedtime() being non-monotonic was an argument advanced for moving away from it, iirc
<_aj_>
laanwj: what? no, monotonic and adjusted are oil and water
<_aj_>
i couldn't think of two things that don't go together as badly as adjusted time and monotonic time
<laanwj>
i'm really confused never mind
<_aj_>
we need two clocks, monotonic-ish for the schedule, mockable for most things; and if we still have adjusted time, we need a third clock for that, and three is too many
<MarcoFalke>
_aj_: Currently there is *no* clock in the codebase, only durations. The clocks part is implicit
<_aj_>
MarcoFalke: yeah
<MarcoFalke>
I think it is fine to add one clock for addrman time
<MarcoFalke>
and then figure out the other clocks in a later release or later commit
<_aj_>
MarcoFalke: oh, that's a clever idea!
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #24806: RPC: Switch getblockfrompeer back to standard param name blockhash (master...use_bloch_hash) https://github.com/bitcoin/bitcoin/pull/24806
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<jonatack>
laanwj: MarcoFalke: ok seems clear, will write an update to the developer note rpc guideline
<laanwj>
jonatack: thanks! i guess we need something like "please consider whether there is already a convention for an argument or return field name in the RPC API, if so, try to use that"
bitcoin-git has joined #bitcoin-core-dev
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
i'm sure we don't achieve perfect consistency in the RPC API, ever, but on a best-effort basis when introducing new RPC calls or arguments makes sense
<bitcoin-git>
bitcoin/master e0680bb fanquake: Merge bitcoin/bitcoin#24806: RPC: Switch getblockfrompeer back to standard...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
bitcoin/master 88917f9 Luke Dashjr: RPC: Switch getblockfrompeer back to standard param name blockhash
<fanquake>
ok
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake merged pull request #24806: RPC: Switch getblockfrompeer back to standard param name blockhash (master...use_bloch_hash) https://github.com/bitcoin/bitcoin/pull/24806
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<fanquake>
if someone else wants to merge the backports
<fanquake>
we could just about do an rc4
AaronvanW has joined #bitcoin-core-dev
<laanwj>
i'll do
<laanwj>
though it might make sense to wait for CI first
<willcl_ark>
Is there any documentation for building for macOS-arm64? installed a few brew deps with `arch -arm64 brew install...` but the linker still complains about building for x86_64 but using macOS-arm64 deps. Do i need to use `--host=HOST`?
AaronvanW has quit [Quit: Leaving...]
<fanquake>
building on m1 or x86
<willcl_ark>
m1
<fanquake>
you shouldn't have to do anything special. either for our build or when installing brew deps
<fanquake>
it just works
<fanquake>
not sure how you'd end up in a situation where the linker thinks you're cross-compiling for x86_64 if you haven't told it too
AaronvanW has joined #bitcoin-core-dev
<willcl_ark>
interesting, thanks. It's not my machine so I am remote debugging but it certainly didn't seem to like a pretty standard build sequence: https://pastebin.com/76QQ3XXK
<willcl_ark>
Hmmm re-reading that, perhaps the linker is just notifying that it is going to use the right file, and the error is something else?
<fanquake>
That looks like they are trying to cross-compile for x86_64 while building on arm64 (M1)
<willcl_ark>
OK, but that shouldn't happen unless `--host` was configured, right? I will check their configure output now anyway...
<fanquake>
Can you confirm what they are actually trying to do, and the ./configure invocation they are using
<willcl_ark>
My understanding was simply following doc/build-osx.md on a M1 macbook (although we changed configure to `./configure --without-bdb --with-gui=no` I think), but will confirm
<fanquake>
Yes, that will work fine, if they are building for M1, on M1, or for x86_64 on x86_64.
<willcl_ark>
gotcha, thanks. Will see if this is somehow not the case
<fanquake>
However it looks like they are trying to cross-compile, for x86_64, while on M1, in which case, they should do a depends build for HOST=arm64-apple-darwin, and then CONFIG_SITE=/blah/blah ./configure
<fanquake>
ahh
<fanquake>
HOST=x86_64-apple-darwin
dviola has quit [Remote host closed the connection]
yanmaani has quit [Ping timeout: 240 seconds]
<willcl_ark>
We are not trying to cross compile, just get a native build on an M1
dviola has joined #bitcoin-core-dev
<fanquake>
Which branch?
<willcl_ark>
Can I PM you a config.log?
<fanquake>
sure
mekster66949 has quit [Ping timeout: 272 seconds]
mekster66949 has joined #bitcoin-core-dev
yanmaani has joined #bitcoin-core-dev
mekster66949 has quit [Ping timeout: 272 seconds]
mekster66949 has joined #bitcoin-core-dev
mekster66949 has quit [Client Quit]
mekster66949 has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
whitehorse[m] has joined #bitcoin-core-dev
<achow101>
There's a wallet meeting later today, but I'm going to be unable to attend. Someone else can chair it, or we can skip this week.
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #24808: doc: update RPC argument and field naming guideline in developer notes (master...update-developer-notes-rpc-argument-and-field-naming-guideline) https://github.com/bitcoin/bitcoin/pull/24808
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
bitcoin/23.x 69cc83d Jon Atack: Add DEBUG_LOCKCONTENTION documentation to the developer notes
<bitcoin-git>
bitcoin/23.x 6374e24 Jon Atack: Put lock logging behind DEBUG_LOCKCONTENTION preprocessor directive
<MarcoFalke>
Would also be good to include if the uaagent is 23.x or not
<MarcoFalke>
at least for the outgoing connections
<MarcoFalke>
Mabye also for incoming to see if they are running on a mobile device or server
<dhruv>
laanwj: #24792 brings in secp master, but BIP324 depends on secp/#979 and scp/#982 which are still pending review. The conflict is likely because the tree changes iiuc.
brunoerg has quit [Remote host closed the connection]
___nick___ has joined #bitcoin-core-dev
___nick___ has quit [Client Quit]
___nick___ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 272 seconds]
dviola has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 260 seconds]
dviola has quit [Ping timeout: 268 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 268 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
dviola has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
dviola has quit [Max SendQ exceeded]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 248 seconds]
sudoforge has joined #bitcoin-core-dev
dviola has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 248 seconds]
dviola has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
NovaCoiner has joined #bitcoin-core-dev
<S3RK>
wallet meeting?
<S3RK>
ok, I see it's canceled
NovaCoiner has quit [Quit: Client closed]
dviola has quit [Ping timeout: 246 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Max SendQ exceeded]
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Empact opened pull request #24811: refactor: Prepare for moving ArgsManager out of util/system (master...2022-03-util-args-manager-prep) https://github.com/bitcoin/bitcoin/pull/24811
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
flooded has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
_flood has quit [Ping timeout: 268 seconds]
dviola has quit [Max SendQ exceeded]
sipsorcery has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 248 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Max SendQ exceeded]
___nick___ has quit [Ping timeout: 272 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 272 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 272 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 260 seconds]
metallicc has quit [Quit: Leaving]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dviola has joined #bitcoin-core-dev
hashfunc14a0 has joined #bitcoin-core-dev
dviola has quit [Max SendQ exceeded]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 246 seconds]
dviola has joined #bitcoin-core-dev
Lightsword has quit [Quit: ZNC]
Lightsword has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 248 seconds]
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
hashfunc14a0 has quit [Ping timeout: 268 seconds]
dviola has quit [Ping timeout: 256 seconds]
Talkless has quit [Quit: Konversation terminated!]
dviola has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
bomb-on has quit [Quit: aллилѹіа!]
bomb-on has joined #bitcoin-core-dev
bomb-on has quit [Ping timeout: 256 seconds]
AaronvanW has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 256 seconds]
AaronvanW has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
dviola has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 248 seconds]
dviola has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
dviola has quit [Remote host closed the connection]
dviola has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 268 seconds]
bomb-on has quit [Ping timeout: 268 seconds]
brunoerg has quit [Remote host closed the connection]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
mudsip has quit []
dviola has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] aureleoules opened pull request #24812: util/check: Add CheckNonFatal identity function and use it in src/rpc (master...check_non_fatal_identity) https://github.com/bitcoin/bitcoin/pull/24812
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 268 seconds]
dviola has quit [Ping timeout: 256 seconds]
dviola has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[gui] hebasto opened pull request #579: Getting ready to Qt 6 (2/n). Remove `QApplication::globalStrut()` (master...220409-strut) https://github.com/bitcoin-core/gui/pull/579
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]