Kaizen_Kintsugi_ has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
<dhruv>
force-pushed to re-trigger. it turns out sometimes cirrus doesn't figure out a new sha was pushed and keeps trying to checkout the old git objects that don't exist on that branch anymore.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
meshcoll- has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
meshcollider has joined #bitcoin-core-dev
Guest22 has quit [Quit: Client closed]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
cold has quit [Quit: Quitting...]
cold has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
<bitcoin-git>
[bitcoin] S3RK opened pull request #25507: wallet: don't add change fee to target if subtracting fees from output (master...correct_target_with_sffo) https://github.com/bitcoin/bitcoin/pull/25507
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Guyver2 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
belcher has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 272 seconds]
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
blkncd has quit [Ping timeout: 256 seconds]
blkncd has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
brunoerg has quit [Ping timeout: 272 seconds]
jespada has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 272 seconds]
AaronvanW has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
test_ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 260 seconds]
meshcollider has quit [Changing host]
meshcollider has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
test_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 272 seconds]
brunoerg has quit [Ping timeout: 255 seconds]
vysn has quit [Read error: Connection reset by peer]
<bitcoin-git>
[bitcoin] fanquake opened pull request #25508: guix: use elfesteem 2eb1e5384ff7a220fd1afacd4a0170acff54fe56 (master...update_elfesteem) https://github.com/bitcoin/bitcoin/pull/25508
brunoerg has joined #bitcoin-core-dev
Guest48 has joined #bitcoin-core-dev
Guest48 has quit [Client Quit]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
AaronvanW has joined #bitcoin-core-dev
blkncd has quit [Quit: Connection closed for inactivity]
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
AaronvanW has quit [Remote host closed the connection]
<laanwj>
ariard: added
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
ronoaldo has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
z9z0b3t1c has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
Kaizen_K_ has quit [Read error: Connection reset by peer]
furszy has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<darosior>
If you have a confirmed transaction, you `gettransaction` it. You then query `listsinceblock`with the 'blockhash' from the result of the `gettransaction` call. The transaction will not be returned. If you pass the blockhash of the previous block, however, it will. Is it the intended behaviour?
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<laanwj>
darosior: it's not clear to me from the RPC help how "since" is to be interpreted
<bitcoin-git>
[bitcoin] MarcoFalke closed pull request #25505: test: passing a negative value to `-peertimeout` should throw an error (master...2022-06-peertimeout-negative) https://github.com/bitcoin/bitcoin/pull/25505
<darosior>
Yes, it looks like this behaviour is tested so it is (hopefully) be intended
<bitcoin-git>
bitcoin/master 748a10e /dev/fd0: rephrase error for invalid timeout
<bitcoin-git>
bitcoin/master bae8a66 MacroFake: Merge bitcoin/bitcoin#25506: Rephrase error message for invalid value of `...
<laanwj>
it could definitely be documented better
<darosior>
I'll open an issue to clarify, as at the very least the documentation is confusing
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25506: Rephrase error message for invalid value of `-peertimeout` (master...peertimeout-error-msg) https://github.com/bitcoin/bitcoin/pull/25506
<laanwj>
right
<laanwj>
i'd personally expect it to be inclusive of the specified block, too
Kaizen_K_ has joined #bitcoin-core-dev
gnaf has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_K_ has quit [Ping timeout: 246 seconds]
<sipa>
I think the behavior makes sense, see my comment.
<darosior>
Yeah your explanation makes sense.
<sipa>
It could certainly be better documented.
<bitcoin-git>
[bitcoin] darosior opened pull request #25510: rpc: explicit the range for listsinceblock's filtering by block hash is exclusive (master...doc_listsinceblock) https://github.com/bitcoin/bitcoin/pull/25510
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<laanwj>
sipa: yes, that makes sense
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jamesob>
Random question: was there ever a rationale for the bitcoin/bitcoin-core github org split? I.e. why isn't everything just under one or the other?
<ariard>
laanwj: thanks
<bitcoin-git>
[bitcoin] brunoerg opened pull request #25511: test: non-positive integer value to `-peertimeout` should throw an error (master...2022-06-peertimeout-positive-integer) https://github.com/bitcoin/bitcoin/pull/25511
<laanwj>
jamesob: ideally everything should be under bitcoin-core, that said, the bitcoin/bitcoin repo name is hardcoded in so many places
Kaizen_K_ has joined #bitcoin-core-dev
<jamesob>
laanwj: ah gotcha
<laanwj>
well, bips is the thing that can be argued to belong under bitcoin itself
<laanwj>
anyhow, old wounds
<jamesob>
right
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
<laanwj>
i guess it becomes relevant again if we ever split up the repo (e.g. in a consensus part and the rest), but that's not even a consideration right now
<jamesob>
for sure
Kaizen_K_ has quit [Ping timeout: 260 seconds]
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
z9z0b3t1c has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
<bitcoin-git>
bitcoin/master d22bd54 brunoerg: test: passing a non-positive integer value to `-peertimeout` should throw ...
<bitcoin-git>
bitcoin/master b6cf0f8 MacroFake: Merge bitcoin/bitcoin#25511: test: non-positive integer value to `-peertim...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25511: test: non-positive integer value to `-peertimeout` should throw an error (master...2022-06-peertimeout-positive-integer) https://github.com/bitcoin/bitcoin/pull/25511
<instagibbs>
does github let you "ACK" someone's comment, so it's re-exposed in your gihub review thread thing?
<instagibbs>
like "yeah this needs to be fixed" without making an entirely new comment
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
sdaftuar has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
kouloumos has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
furszy has quit []
Kaizen_K_ has quit [Ping timeout: 268 seconds]
furszy has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
<kouloumos>
Has anyone ever tried to add tracepoints support for macOS? Except of the kind of related reference in #22238 I couldn't find any other tangible mention.
<bitcoin-git>
bitcoin/master bda8ebe furszy: wallet: don't read db every time that a new WalletBatch is created
<bitcoin-git>
bitcoin/master c892cb7 MacroFake: Merge bitcoin/bitcoin#25383: wallet: don't read db every time that a new '...
<bitcoin-git>
bitcoin/master c318211 furszy: walletdb: fix last client version update
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25383: wallet: don't read db every time that a new 'WalletBatch' is created (master...2022_wallet_db_read) https://github.com/bitcoin/bitcoin/pull/25383
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
sipsorcery has joined #bitcoin-core-dev
furszy has joined #bitcoin-core-dev
furszy has joined #bitcoin-core-dev
furszy has quit [Changing host]
furszy has quit [Remote host closed the connection]
kouloumos has quit [Quit: Connection closed for inactivity]
sipsorcery has quit [Ping timeout: 268 seconds]
realies has quit [Quit: Ping timeout (120 seconds)]
realies has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dergoegge opened pull request #25514: net processing: Move CNode::nServices and CNode::nLocalServices to Peer (master...2022-06-move-services) https://github.com/bitcoin/bitcoin/pull/25514
<laanwj>
MacroFake: depends on how long it has needed rebase imo
<MacroFake>
Yeah, one week seems fine, but if something is sitting for several weeks, I am not sure what reviewers can do
brunoerg has joined #bitcoin-core-dev
<Murch>
hi
<laanwj>
agree
<laanwj>
looks like it has needed rebase since may 6
<laanwj>
so yes removing it for now
<laanwj>
okay, anything else to add/remove, or that is in the list and almost ready for merge?
* luke-jr
squashes a cricket
<laanwj>
(btw, if you have a project board, and want to migrate it to the new github projects beta, let me know, this is possible now)
<laanwj>
#topic glozow for rbf / mempool / validation maintainer
<core-meetingbot>
topic: glozow for rbf / mempool / validation maintainer
<fanquake>
Cool
<laanwj>
ack
<fanquake>
Per the topic, I'm proposing we make Gloria (https://github.com/glozow) a maintainer; over ~ rbf / mempool / policy
<fanquake>
She has been actively working on Bitcoin Core for > 2 years. Predominately in the mempool & validation code.
<fanquake>
Her current project is package rbf/relay, and I know she has a number of thoughts in regards to improving the surrounding code.
<fanquake>
More recently she has also been reviewing / helping improve in /wallet/, which I'm sure achow appreciates
<fanquake>
I think she is a great candidate for being a maintainer
<achow101>
ack
<cfields_>
+1
<hebasto>
ack
<sipa>
The obvious question, glozow: are you interested in helping out with maintaining?
<instagibbs>
lol
<MacroFake>
sipa: sssh
<instagibbs>
(ack)
<luke-jr>
who said she has a choice? /s
<cfields_>
err.. assuming ^^ :)
<glozow>
thanks fanquake, I appreciate the recognition. Yes I'd like to help out in any way I can.
<dongcarl>
ack if she wants it
<michaelfolkson>
Who is currently merging mempool/policy PRs? Marco?
<Murch>
ack
<sipa>
ack, in that case
<b10c>
ack
<MacroFake>
sgtm
<laanwj>
awesome!
<b10c>
nit: brink would then fund 3 maintainers. not that this is a problem, i just want to mention it.
<jeremyrubin>
i am mild nack on it -- i think that Gloria is suitable and qualified, but i think that maintainership might hinder more than help her progress
<jeremyrubin>
since it seems it would largely be her with merge resposnibility over her own work
<dongcarl>
what does glozow think?
<instagibbs>
this seems like a larger question(which is valid) on self-merges
<achow101>
jeremyrubin: the same was with the wallet for me
<MacroFake>
jeremyrubin: Somewhat it is a requirement to have worked extensively on a piece of code before you can maintain it
<cfields_>
jeremyrubin: doesn't seem far off from fanquake's role/work to me.
<cfields_>
right, and achow101.
<luke-jr>
jeremyrubin: I don't know that's a problem. Maintainers tend to work in the area they merge in
<achow101>
at least it will help with getting other people's work in too
<luke-jr>
the process of merging still requires third party review
<sipa>
I think this was brought up with achow101's maintainership as well, and I think the counterpoints are similar: it's better than having their own work merged at all, and that is something other maintainers can still do.
<sipa>
*not merged at all
<glozow>
Spending time in this area of the codebase has led me to understand that we have plenty of non-package-relay limitations to address, and reviewing mempool and policy-related things is often the best use of my time. So I had planned to do more of that anyway. Not that this means dropping package relay, but there are lots of non-package relay things to look after. And if people are not comfortable with me merging my own code, then I won't do
<glozow>
that.
<laanwj>
luke-jr: sipa: exactly
<ariard>
i think it's always okay to say to a maintainer we have found the merge too fast or not matching the historical level of reviews for a critical area of the codebase
<lightlike>
ack
<luke-jr>
ariard: counterpoint, last time that was ignored and the PR not reverted as it ought to have been
<ariard>
luke-jr: as usual, one contributor viewpoint might not express the project consensus
bytes1440000 has joined #bitcoin-core-dev
<luke-jr>
it means there is no consensus; and I certainly was not alone
<jeremyrubin>
well to be clear this is very different role than maybe fanquake or achow
<jeremyrubin>
since this is -- as desrcribed here -- "validation maintainer"
<bytes1440000>
b10c: its a good point and maintainers funded by different orgs is always better for a project like bitcoin core
<sipa>
luke-jr: ignoring specific cases, i agree that nobody should feel restricted from commenting on too-fast-merges.
<luke-jr>
in any case, it's not related to the topic of glozow's role IMO
<ariard>
though to express wider thought on the mempool maintership, imo it's one area of the codebase expected to grow in complexity in the coming years with upper layers requirements
Guest17 has joined #bitcoin-core-dev
<ariard>
like we'll likely have a bunch of other beasts like package relay to land in the coming decade for all the covenants/eltoo stuff
<bytes1440000>
i am not sure if bitcoin core needs another person with commit access with already 6 but always felt it needs more reviewers looking at open pull requests
Talkless has quit [Quit: Konversation terminated!]
<jeremyrubin>
a wallet maintainer affects mostly those who choose to user the software, it's not clear what the scope is of a validation maintainter to me
<laanwj>
mempool maintainer is much clearer
<bytes1440000>
ariard: you could also be a mempool maintainer?
<cfields_>
bytes1440000: that's not the discussion now.
<MacroFake>
I think "validation" is meant in the context of mempool validation? (ATMP is in validation.cpp)
<laanwj>
i'm also not really sure what 'validation maintainer' would be
<jeremyrubin>
maybe we could do a better job of drafting an actual "Job Description" for what glozow is being appiinted as?
<ariard>
bytes1440000: no, i don't intend to be maintainer, i don't have the profile for and when it has been proposed to me for LDK, i did refuse
<sipa>
ariard: I'm not sure that's all that related to specific consensus changes, but sure... i do expect significant complexity and the need for people keeping a good overview over it, regarding tx relay
<fanquake>
I did clarify to mempool / rbf / policy, in the sentences above
<luke-jr>
jeremyrubin: as with all maintainers, it's supposed to be janitorial
<luke-jr>
running a script when there's review and consensus on a PR
<laanwj>
fanquake: makes sense to me said like that
<bytes1440000>
ariard: okay
<fanquake>
i may have said validation in the proposed topic, but not specifically in this discussion
<fanquake>
i did say she had worked on the code in validation
<sipa>
Yeah, I prefer the role to be "mempool / rbf / policy" rather than validation.
<luke-jr>
I'd drop "rbf" - seems like too minor a detail :p
<achow101>
mempool/policy, components of which live in validation.cpp.. our naming sucks
<sipa>
If we're bikeshedding, "mempool and transaction relay policy" ?
<jeremyrubin>
i think it would make sense to draft a Job Description of what the appointment is for and scoping, and have people ack that when it exists.
<cfields_>
jeremyrubin: that would've made sense for every prior nomination as well.
<jeremyrubin>
yeah
<laanwj>
the name can be more abstract it doesn't have to be precise a specfic cpp or so, we've never divided things up like that
<jeremyrubin>
it would have
<ariard>
sipa: sure, my thought was the mempool is a good candidate to get a maintainer in the coming years, if the complexity keeps increasing
<jeremyrubin>
we probably should have done that
<Murch>
mempool+policy sgtm
<jeremyrubin>
as noted, i am not opposed to glozow having some set of responsibilities, it just doesn't seem like we're holding ourselves to a good standard to not do this
<glozow>
Mempool / Policy is a scope I am fine with and plan to review anyway. Maybe we can one day more them out of validation.cpp if that's important to people. It seems the core question is whether or not people think I am knowledgeable enough to gauge whether a PR has enough review to be merged, since that's what a maintainer does.
<michaelfolkson>
ack
<laanwj>
glozow: i'm sure you are!
<luke-jr>
sipa: policy affects more than relay in practice; and often relay isn't even given the priority
<ariard>
jeremyrubin: yes, i agree we might do a Job Description to get the scoping right
* dongcarl
is fully in support of inverting the validation -> mempool dependency
<BlueMatt[m]>
dongcarl: lol good luck
<cfields_>
:)
<laanwj>
we don't have that kind of precise scoping for maintainers, i don't think that's necessary
<luke-jr>
glozow: IIRC you seemed confused about the relation between miners and relay policy; but I may be misremembering, and/or maybe cleared that up
<laanwj>
we all have an idea what mempool+transaction relay is
<sipa>
maintainers also learn, and responsibilities evolve
<achow101>
tbh maintainers have merged things outside of their explicit scopes, and I don't think that's necessarily a bad thing
<dongcarl>
I do like an "inclusionary" list of responsibilities, not an "exclusionary" one
<achow101>
so long as every PR has been reviewed by multiple people and there is consensus for merging, it doesn't particularly matter who is merging
<laanwj>
achow101: right, as long as there is agreement that's fine
<jeremyrubin>
ok so then we aren't discussing adding gloria as a scoped maintainer, it's as a general maintainer?
<jeremyrubin>
that seems like a different discussion, which is also OK to have
<MacroFake>
Agree with achow101 and laanwj
<luke-jr>
x.x
<achow101>
jeremyrubin: all maintainers are basically general maintainers
<achow101>
but have a focus
<laanwj>
achow101: yes, that
<ariard>
okay that might be the discussion, should we evolve towards scoped maintainance
<laanwj>
i'm not sure
<luke-jr>
I don't see that would improve things
<Murch>
It's not like the parts of the codebases are that isolated
<sipa>
i hope we don't need to have discussions about whether or not something was someone's purview to merge
<laanwj>
sipa: +1
<sipa>
the role is janitorial, as already pointed out
<laanwj>
i don't think that has ever happened anyway, and probably shouldn't
<jeremyrubin>
i think i would just like clarity -- you see how it is not good that gloria was proposed to be a scoped maintainer, everyone ACK'd that, and now it's backtracking into well it's always general purpose overall project maintenance?
<sipa>
and i hope that the people given maintainer responsibilities are expected to judge their own expertise in making that decision
<jeremyrubin>
Adding a maintainer is a serious, important thing
<bytes1440000>
+1
<jeremyrubin>
so I think as a project we should communicate more clearly about what exactly is being done and expected
<jeremyrubin>
and if people are ACK voting, they should know what for
<MacroFake>
jeremyrubin: It would be suspicious if glozow went out and merged a ton of build system changes that are reviewed, but not by her
<laanwj>
i don't think that's necessary, but feel free to write something up if you want
<cfields_>
jeremyrubin: as has adding every past maintainer. I think if you're going to call for procedural changes, you need to make it clear why this one's different.
<MacroFake>
However, if she decides to work on the build system in 2 years, that should be reasonable
<jeremyrubin>
cfields_ i have been asking for maintainers to give more clarity for a while
<jeremyrubin>
so i am not personally departing from any prior stance
<luke-jr>
jeremyrubin: people want to spend time on code, not necessarily process
<luke-jr>
at least myself
<laanwj>
luke-jr: +100
<dongcarl>
I'm ACKing for glozow to be focused on mempool / policy but have the ability to act in a general maintainer way as long as it's not repeatedly unilaterally stepping on other maintainers' toes
<achow101>
^ that
<sipa>
dongcarl: +1
<laanwj>
sure, i mean given that she even wants that
<glozow>
Thank you dongcarl. I agree to "be focused on mempool / policy but have the ability to act in a general maintainer way as long as it's not repeatedly unilaterally stepping on other maintainers' toes."
<ariard>
from my viewpoint, the worthiness of a scoped maintainership is when you have a security issue to talk about you know at least whom should be the default interlocutor (even if I know we have a catch-all mailist endpoint)
<laanwj>
that also works for semi-scoped
<Murch>
Well, I'd have rephrased the second half of that to, and "expect to judge their own expertise in making merge decisions" as mentioned by Pieter above
bomb-on has quit [Quit: aллилѹіа!]
<jeremyrubin>
i want to spend time on a beach with a pina colada -- however, process work is a part of the development of the "bitcoin core organization", so you can't just stick your head in the sand and ignore it, especially when it comes to doling out commit access
<laanwj>
if there's some urgent issue you talk to the person who has the focus on a certain area
<laanwj>
no, i don't think adding more bureaucracy and formality makes things better
<luke-jr>
there is no bitcoin core organization
<ariard>
yeah, the "who has the focus on a certain area" might not always be clear, and it's more then whom you should nudge to get covert a fix done
<MacroFake>
As a general rule, if you have an idea to improve the process, suggestions are welcome.
<sipa>
As the project grows, some form of process/organization is expected to come into play. Until a few years ago, maintainers had barely any focus, let alone a well-defined focus. I think it suffices to talk about maintainers with a focus: people who have maintainer rights, but are expected to mostly focus on one aspect.
<sipa>
Let's not rush adding more formality to this, it's already burdensome enough.
<laanwj>
yes
<dongcarl>
That sounds right to me!
<jeremyrubin>
how burdensome is it to write a simple Job Description describing what "mempool / policy / validation / RBF" is so that we know what the focus actually is of the proposed new maintainer?
<michaelfolkson>
I think being willing and available to discuss a controversial merge decision on IRC is important. Beyond that every PR has its own subtleties
<dongcarl>
jeremyrubin: EPARSE
<laanwj>
i think you're dragging things out now jeremyrubin
<laanwj>
any other topics?
<ariard>
anyway, i think a mempool maintainer is a good thing and I think glozow is a valuable candidate, however maybe we could take more time to think about the effective scope and if we have other candidates interested (again: i'm not interested)
<luke-jr>
jeremyrubin: so write it yourself and propose it for merging to project docs in a PR
<dongcarl>
I have a small implementation detail thing that's probs not important enough for the meeting but would like to chat a bit afterwards
<jeremyrubin>
perhaps I am dragging it out -- i would fire back that you're avoiding important discourse on accountability of maintainers, something that you shouldn't shy away from in general. All maintainers should be able to produce 5 sentences on what areas they are focused on.
<cfields_>
jeremyrubin: not 6?
<jeremyrubin>
gotta start somewhere
<michaelfolkson>
Regardless the work Gloria has done on mempool, policy, package relay, PR review club is great. This discussion isn't Gloria related, just process questions
bomb-on has joined #bitcoin-core-dev
<laanwj>
sigh
<bytes1440000>
ariard: +1 will be interesting to see if others are also interested to be a maintainer for different things
<dongcarl>
I think "mempool / policy" is quite clear
<cfields_>
bytes1440000: stop.
<achow101>
jeremyrubin: how specific do you want this description to be? I find "mempool / rbf / policy" to be clear in scope
<jeremyrubin>
generally the more the better -- achow101 has done a good job detailing his course of action / wallet priorities IMO
<achow101>
per file? per line? The codebase is complex enough that a PR in one area still has effects on code in other places that are "out of scope"
* luke-jr
echos laanwj's sigh
<instagibbs>
If I'm made policy maintainer, I'll make sure the snack bar is refilled on consistent intervals
<bytes1440000>
cfields_ : are people not allowed to respond in this channel?
<luke-jr>
lol
<jeremyrubin>
i don
<jeremyrubin>
i don't find that to be sufficiently descriptive personally
* luke-jr
imagines instagibbs flying around the world to each dev's office to refill snacks
<laanwj>
hehe
<jeremyrubin>
glozow is it a problem to write up your intended focus areas and prioritizations for the project?
<laanwj>
if she wants to write something up that's fine ofc
<glozow>
jeremyrubin: I'm sure people have varying ideas of what amount of prioritizing or "roadmapping" would be appropriate, but I did prepare a list of things I consider important and would work on https://gist.github.com/glozow/5b8cfa27945371921dfe4d99b17e0424
<sipa>
FWIW, I think it's a good idea in general for everyone (not just maintainers) to talk about their priorities and current focus.
<MacroFake>
jeremyrubin: I'd say a personal roadmap is different from the tasks of a maintainer
<jeremyrubin>
MacroFake: i think that's a theoretical distinction
<jeremyrubin>
practically, maintainers work on what they are interested in.
<luke-jr>
jeremyrubin: achow101 is great at community/social publication of his work efforts; but that doesn't mean it needs to become a standard everyone has to abide by
<jeremyrubin>
everyone doesn't get to be a maintainer either
<laanwj>
it isn't a theoretical distinction only, as maintainer you're not supposed to only merge what you're working on yourself
<luke-jr>
jeremyrubin: it's a responsibility, not a privilege
<instagibbs>
I guess the question is what is the writeup for, who is the audience
<ariard>
glozow: I think that's a good start, maybe open a GH issue, I would be interested to feed thoughts there and roll the ball forward on mempool maintenance
<sipa>
The role of maintainers, jointly, is merging PRs that are ready. The question of focus is mostly about determining who among them is best placed to judge a particular PR's status.
<laanwj>
sipa: right!
<fanquake>
ariard: I think issues for specific topics would be fine. Although not a single catch-all for discussion of the entire contents of that gist
<jarolrod>
i dont think glozow has to do all of these write-ups, we know what she works on and the idea of what she will be maintaining is fairly clear
<ariard>
I would say we're missing few folks who has spent time on the mempool recently at that meeting: darosior, realtbast, jamesob and maybe few others L2 devs, they might have thoughts on mempool maintenance
<laanwj>
ariard: agree, we don't take final descisions in meetings anyway
<ariard>
fanquake: yeah anything to have more visibility on what are people interested with and allocate review time would be great
<luke-jr>
^
<jeremyrubin>
glozow ariard +1 -- it's a good start
<jeremyrubin>
laanwj: ah, what is the process then for decision on maintainership then?
<jeremyrubin>
I thought it was being decided here
<laanwj>
jeremyrubin: i'm done arguing process with you
<achow101>
ariard: yes, we let people see the pr to add the merge key for a few days / weeks before actually merging it and granting rights
<luke-jr>
jeremyrubin: btw, just to be clear, do you have any reservations with glozow merging PRs with the same expectations for maintainers in general?
<jeremyrubin>
well you just said "ariard: agree, we don't take final descisions in meetings anyway"
<achow101>
ack/nack on the merge key pr is the "final decision"
<fanquake>
because nothing is actually done until a pr has been open, reviewed, merged
<laanwj>
but it's prbably good to let some time pass so people can bring up potential issues they have with glozow being maintainer, or proposed alternatives
<jarolrod>
^ laanwj agree
<luke-jr>
there can always be multiple maintainers - I don't know that alternatives are an objection
<laanwj>
no, that's true
<jeremyrubin>
laanwj: if you can't civilly discuss what process in your decision making you're not suited to be a maintainer... accountability is part of the job.
<laanwj>
jeremyrubin: not everything is about your opinions
<jeremyrubin>
i never said it is
<jeremyrubin>
but you're trying to quash a relevant discussion for what reason?
<laanwj>
jeremyrubin: you keep stating your preferences as some kind of facts that is very annoying to me
<instagibbs>
I'm just going to venture that continuing this isnt helping
<michaelfolkson>
+1
belcher has quit [Quit: Leaving]
<jeremyrubin>
i'm sorry to have annoyed you?
<ariard>
jeremyrubin: i think accountability of maintainers is an interesting topic, however i think it's better to talk about it in a chill venues like coredev or on the mailing list, there is a lot of context IRC might not be the best medium
<achow101>
jeremyrubin: you've been around long enough to see multiple people receive (and renounce) maintainership, I'm surprised that you are not already aware of the process.
<glozow>
I care about the health of mempool/policy and Bitcoin Core, and I take it very seriously so I'm happy to be held to a high standard. All of the work we do is entirely in public, so you are always free to audit me, tell me I've done something wrong, or request I prioritize other things. If you want to test my knowledge or preparedness, please let me know what the standard is beforehand and apply it equally to everyone in the same role.
<ariard>
achow101: sgtm, to have a PR open for a while and see if we have any objections, I think it's worhty to have a discussion there or elsewhere on the scope
<jeremyrubin>
glozow: +1
<jeremyrubin>
re luke-jr: I'd probably want to have a 1-1 convo with gloria about her views on general maintainership before i'd personally endorse, but I don't have a nack presently
<cfields_>
in that case i think we can continue without jeremyrubin's endorsement.
<michaelfolkson>
Demanding a 1-1 conversation before "endorsing" is absurd, gosh. Anyway did dongcarl have a mini project update?
<dongcarl>
Not a mini project update
<MacroFake>
3a/n was merged :party:
<jeremyrubin>
i don't think that's at all unreasonable
<jeremyrubin>
i also work on this part of the code
<jeremyrubin>
why would it be weird to want to get a better sense of how gloria intends philisophically to maintain it?
<cfields_>
jeremyrubin: because there's zero precedent for that and you need to say whatever it is that you really mean or stop derailing.
<ariard>
jeremyrubin: while you wouldn't start a ML post and invite politely glozow to express her thoughts ?
<dongcarl>
MacroFake: 3a/n was merged thanks to all the reviewers who got through the many changes. Thanks!
<instagibbs>
\o/
<jeremyrubin>
well this is the first i'm hearing of a nomination for mempool maintainer
<jeremyrubin>
i think it'd be great to have a ML post or something?
<dongcarl>
I think 3a sets a good example for all the following Argsman decoupling PRs
<jeremyrubin>
cfields_: ...
<MacroFake>
dongcarl: Apologies for my last minute nit-attack, feel free to ignore them when the pr is in a late stage
Kaizen_K_ has quit [Remote host closed the connection]
<jeremyrubin>
there's no hidden agenda or anything here and I don't think it is derailing to ask basic questions like this
<dongcarl>
As for my question... I wanted to ask about the split of -maxsigachesize between InitSignatureCache and InitScriptExecutionCache
<dongcarl>
Is that intended to stay longer term or should I deal with it as I do my decoupling?
<sipa>
the fact that 50% goes to the sigcache and 50% to the script exec cache?
<sipa>
or is this about code orgnanization
<jeremyrubin>
glozow is perfectly eloquent and capable of justifying and explaining herself, and I don't think a pile on which amounts to "we don't need to answer questions" is doing her any favors
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<dongcarl>
sipa: Yup! Wondering if we intend to make 2 separate flags for them, or if splitting 50/50 is good for now
<dongcarl>
Also okay if no one has strong opinions haha
<sipa>
dongcarl: My guideline for "should something be configurable" is: can you clearly express the conditions under which someone should use it.
<sipa>
If you can't do that, how do you expect the user to know better.
<laanwj>
dongcarl: i don't have a strong opinion on it, but adding too many options is overwhelming
<dongcarl>
Okay! I will keep the existing then :-)
<laanwj>
sipa: right
<dongcarl>
yeah one cache doesn't make sense without the other
<laanwj>
like "does anyone want to fine-tune this manually in the first place? why?"
<sipa>
I'm not sure I can even express when someone should change the size of the cache at all, except in very low-memory situations perhaps.
<sipa>
dongcarl: Oh they have very different purposes, one of them without the other is certainly better than nothing. But both is even better.
<bytes1440000>
jeremyrubin: There is nothing unreasonable with your questions or thoughts about the process. Commit access being given is a big thing and anyone reading the chat could understand some people don't like questions or different opinions or freedom to participate in this discussion and share thoughts.
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
bytes1440000 has left #bitcoin-core-dev [#bitcoin-core-dev]
<Murch>
It's a janitorial duty where people assess what's ready to merge and merge it
<michaelfolkson>
The work over 2+ years speaks for itself. Especially if you've worked on this part of the codebase with that person during that time. What can be said in a 1-1 conversation that could change your mind?
<michaelfolkson>
"If you endorse me I'll merge all your PRs"? It is just absurd. Anyway...
jarthur has joined #bitcoin-core-dev
<jeremyrubin>
my comment was w.r.t. luke-jr's comment about *general maintainership*
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Guest17 has quit [Quit: Client closed]
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
Kaizen_K_ has quit [Ping timeout: 246 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<dongcarl>
BTW, I want to reiterate my thanks to all the reviewers for libbitcoinkernel. I can't do it without you guys. If there are things I can improve on in responding to review, feel free to let me know either here or direct message me!
<ariard>
can we have a "libbitcoinkernel" mug plz :) ?
<dongcarl>
ariard: Lmao nice idea! I'll see what I can do :-)
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jeremyrubin>
fwiw for anyone interested, C/F a meeting in Feb-22 https://gnusha.org/bitcoin-core-dev/2022-02-24.log with laanwj pointing out that glozow as mempool maintainer would be a bad idea, given it's her prime area of work
<jeremyrubin>
11:37 < laanwj> so like, the mempool is notoriously difficult to get people to review for, so, we make glozow mempool maintainer
<jeremyrubin>
11:38 < jeremyrubin> laanwj: glozow is currently one of the main people writing new mempool code, so her being a maintainer probably doesn't help much
<jeremyrubin>
11:38 < laanwj> jeremyrubin: that was exactly my point
<laanwj>
i changed my mind
Kaizen_K_ has joined #bitcoin-core-dev
<jeremyrubin>
but do you see how given this was our prior conversation on the matter, it's not odd that i reiterate the question to see what's changed?
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
<laanwj>
asking questions is fine
<cfields_>
that is a reasonable thing to bring up, yes.
<laanwj>
making random demands from people is not
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jeremyrubin>
a random demand would be one unrelated to the work, e/g. "draw an owl"
<jeremyrubin>
if it's related to the work it's not really random...
<jeremyrubin>
anyways i'd be curious to know in particular what made you change your mind about the suitability of glozow as mempool maintainer (e.g., something about the project, about gloria, about the role of maint, etc)
Kaizen_K_ has quit [Ping timeout: 246 seconds]
<cfields_>
jeremyrubin: trying to defuse a bit... please step back and consider that it looks like you're moving the goalposts and you're being met with pushback there because it's generally not in anyone's best interests to engage with such demands.
<jeremyrubin>
which goalpost moved?
<jeremyrubin>
and also what is the random demand in particular that i'd made?
<cfields_>
jeremyrubin: demands for a formal job description and interview as a requirement for your approval.
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
<laanwj>
jeremyrubin: glozow being maintainer doesn't prevent other maintainers from merging her PRs, just like it is done now, it does allow her to merge other people's mempool related PRs so reducing our burden in that regard
<laanwj>
if she was the only person working on the mempool then yeah, it would make very little difference
Kaizen_K_ has quit [Ping timeout: 268 seconds]
<laanwj>
but whether she's officially maintainer or not she's definitely one of the most qualified persons to review mempool PRs at this point
<jeremyrubin>
no doubt!
<dongcarl>
Weird question: is there a reason why we use angled brackets for includes? When I work with the clang suite it seems to prefer double quotes instead. Just curious.
<laanwj>
dongcarl: yes, it forces all include paths to be relative to the project root
<sipa>
dongcarl: we switched to that at some point, you can probably find a rationale in the PR.
<laanwj>
instead of current directory
<cfields_>
dongcarl: we converted them all a while back. There's a PR that should be easy enough to find with a few git blame's.
<sipa>
Ah yes, what laanwj says.
<laanwj>
there were some issues with same-name include files
<dongcarl>
Ah I see!
<dongcarl>
thanks
<laanwj>
this rules out potential ambiguity (except with system headers, but...)
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
sipsorcery has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
Guest17 has joined #bitcoin-core-dev
kexkey has quit [Quit: kexkey]
Guest17 has left #bitcoin-core-dev [#bitcoin-core-dev]
cryptapus_ is now known as cryptapus
kexkey has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 240 seconds]
kexkey has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
rex4539 has quit [Remote host closed the connection]
rex4539 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 255 seconds]
yanmaani has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
yanmaani has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
Kaizen_K_ has quit [Ping timeout: 246 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 246 seconds]
Kaizen_K_ has quit [Read error: Connection reset by peer]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]