ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 256 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
belcher has quit [Ping timeout: 240 seconds]
hashfunc1818 has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
<hebasto>
in src/net.cpp#L2623 the message "Cannot provide specific connections and have addrman find outgoing connections at the same." looks wrong at the end -- can someone who knows addrman improve it?
brunoerg has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 272 seconds]
<_aj_>
hebasto: "provide specific connections" == use the -connect option == "Connect only to the specified node"
<_aj_>
hebasto: maybe "Cannot limit outgoing connections to specified nodes [and have..]" or something would be better?
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
AaronvanW has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maxraustin opened pull request #24435: [WIP] test: Refactor subtree exclusion in lint tests (master...#17413-Subtree-Exclude-Dirs) https://github.com/bitcoin/bitcoin/pull/24435
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
TheRec_ has joined #bitcoin-core-dev
TheRec has quit [Read error: Connection reset by peer]
brunoerg has quit [Ping timeout: 245 seconds]
brunoerg has joined #bitcoin-core-dev
yanmaani has quit [Ping timeout: 240 seconds]
yanmaani has joined #bitcoin-core-dev
belcher has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
sudoforge has quit [Ping timeout: 240 seconds]
sudoforge has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
greypw254 has quit [Remote host closed the connection]
greypw254 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
cmirror has quit [Read error: Connection reset by peer]
cmirror has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has quit [Ping timeout: 272 seconds]
hashfunc1353 has joined #bitcoin-core-dev
sudoforge has quit [Ping timeout: 272 seconds]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Guest699 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
* Guest699
Rolls a 6 sided dice and gets 3
Guest699 has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest699 has joined #bitcoin-core-dev
Guest699 is now known as hyper
hyper is now known as jx0
jx0 is now known as Satoshi
Satoshi is now known as Guest8106
Guest8106 is now known as jx0
jx0 is now known as Scripty
grettke has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Scripty has quit [Ping timeout: 256 seconds]
grettke has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grettke has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brunoerg has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
devrandom has quit [Quit: Reconnecting]
devrandom has joined #bitcoin-core-dev
hashfunc1353 has quit [Ping timeout: 240 seconds]
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
sdfgsdfg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
brunoerg has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<laanwj>
luke-jr: i think the reasoning was that including a bit of code from libgcc in the release binary was the same as statically linking libgcc, which we already do; of course IANAL and i'm happy we've got rid of that
<laanwj>
luke-jr: that said, for GPL compliance, i'm happy to provide a copy of the source code upon request, either digitally or through floppies in the mail (there might be some costs and delays involved)
Guyver2 has joined #bitcoin-core-dev
hashfuncc47 has joined #bitcoin-core-dev
<laanwj>
in the longer run static linking against musl libc and using clang will end any potential legal uncertanties around static building against libgcc (though i'm pretty sure we're in the clear)
<laanwj>
"The libgcc library is licensed under the GNU GPL plus the GCC Runtime Library Exception (see COPYING.RUNTIME in your gcc source tree). This roughly means that you are allowed to link in libgcc into your software even if it would normally violate the GNU GPL, as long as you used a non-proprietary version of GCC."
<laanwj>
no proprietary blob of any kind is involved in our build process *apart from apple SDK* which is used for the MacOS builds only, that build uses clang anyway, and there was never any libgcc code in that
hashfuncc47 has quit [Ping timeout: 240 seconds]
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<fanquake>
yes musl + clang is something I plan on looking at soon
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44_ has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
Saloframes has quit [Ping timeout: 272 seconds]
grettke has joined #bitcoin-core-dev
Saloframes has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kexkey has quit [Ping timeout: 240 seconds]
kexkey has joined #bitcoin-core-dev
belcher has quit [Ping timeout: 250 seconds]
<laanwj>
^^
ghost43 has quit [Remote host closed the connection]
rex4539_ has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
cmirror has quit [Ping timeout: 256 seconds]
Guest88 has joined #bitcoin-core-dev
Guest88 has quit [Client Quit]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<laanwj>
seems we've quite massively overestimated due to the size of debug.log files (?)? do you think it's worth reverting that and invalidating ACKs for to adjust it down again
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
<laanwj>
michaelfolkson: thanks, hid the comment and blocked for a month
rex4539_ has quit []
geyaeb has quit [Remote host closed the connection]
geyaeb has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
belcher has joined #bitcoin-core-dev
<fanquake>
laanwj: I think invalidating the ACKs is fine
<fanquake>
It's easy to re-verify
prayank has joined #bitcoin-core-dev
<laanwj>
right, agree, also maybe it's a mistake to combine updating consensus-critical values (nMinimumChainWork, defaultAssumeValid) in the same PR as subjective-ish values about blockchain size
<laanwj>
one proposed meeting topic this week (you can propose meeting topics during the week with #proposedmeetingtopic): Bitcoin Core contributor survey (ajonas)
<laanwj>
any last minute topics?
<laanwj>
as the 23.0 branch-off is planned soon (2022-03-01, in less than a week), it probably makes sense to go over the milestone again
<prayank>
I think I can review, tACK it and WIP can be removed. Will need some clarity from PR author why is WIP mentioned. I had already commented in PR.
<jonatack>
hi
<laanwj>
but WIP is generally before the review phase
<laanwj>
yeah, I'm not sure
kexkey has quit [Quit: kexkey]
<prayank>
It was reviewed by multiple devs and author added WIP 5 days back
<laanwj>
i see, weird
<luke-jr>
laanwj: FWIW, I do have a better "translation memory" I use for Knots - but I'm not sure how easily I can send results from it back to Transifex :x
<michaelfolkson>
Only 1 ACK and 1 utACK currently
<luke-jr>
I think I would have to freeze all the translations, fetch, run my script on them, upload, and unfreeze - but it does take an hour or two
<michaelfolkson>
Worth asking about the WIP regardless of milestone
<prayank>
MarcoFalke: I wanted to suggest something in that PR but that would become controversial. And I was not aware of this survey.
<MarcoFalke>
Another point of feedback was that sometimes pull requests with ACKs aren't merged. Sometimes I see them too, but I din't feel comfortable merging them, because I am not at all familiar with that part of the codebase.
<laanwj>
MarcoFalke: makes sense to ping another maintainer then
<laanwj>
or just, mention it here
___nick___ has quit [Client Quit]
<MarcoFalke>
Ok, maybe this is soemthing we might want to document as well.
___nick___ has joined #bitcoin-core-dev
<prayank>
We can document lot of things for reviewers in which they had to ping in IRC
<laanwj>
yes, in general, don't assume anyone has an overview of all issues and PRs, if there's something that needs to be addressed (or ready for merge) it's best to bring it up here
<MarcoFalke>
Also, it was mentioned that there should be more domain-specific maintainers. I tend to agree, but right now we don't have enough maintainers to assign each one a single domain.
<laanwj>
it doesn't help if the wallet maintainers keep stepping down :)
<laanwj>
yes, that's nothing new, we've tried that since 2012 or so
brunoerg has joined #bitcoin-core-dev
<luke-jr>
XD
<jeremyrubin>
i think also it's helpful if current maintainers make clear areas which are more difficult to review for them -- e.g., i dont think there's that many maintainers who have deep mempool expertise (if i'm wrong here LMK), so i think things on mempool are negatively impacted by lack of reviewers who can prod along ack/merge.
<laanwj>
we've always had, there's a lot of things people want and agree on but no one stepping up to do them, and we don't practice human sacrifice, not even by assigning people to be wallet maintainer :)
<jeremyrubin>
Maybe current maintainers can list out what parts of the code they feel more/less confident on?
<ajonas>
I don't think holding maintainers feet to the fire on what they know or what they don't is going to improve that
<luke-jr>
maintainers are supposed to merge based on review ACKs, not their own personal review
<laanwj>
right, lack of knowledgeable reviewers in certain areas of the code isn't going to be improved by slapping labels on people
<MarcoFalke>
jeremyrubin: Grep for ACK-comments on the commits and create a heat-map, will be less subjective
<prayank>
luke-jr: +1
<luke-jr>
obviously it's good if they're familiar with the scope, but it shouldn't be a barrier in itself
<MarcoFalke>
luke-jr: Maintainers should be able to tell if something is a backdoor or not before merge
brunoerg has quit [Ping timeout: 250 seconds]
<luke-jr>
MarcoFalke: reviewers should
<sipa>
luke-jr: That's true, but I'm not sure it matters that much, because personal knowledge about a part of codebase also correlates with judging reviewer competence in that part.
<achow101>
personally, I don't feel comfortable with merging something if I haven't reviewed it, and I don't feel comfortable reviewing something that I'm not familiar with
<laanwj>
so like, the mempool is notoriously difficult to get people to review for, so, we make glozow mempool maintainer
<MarcoFalke>
luke-jr: No one signs review comments, so a GitHub employee can hijack Bitcoin Core if maintainers blindly click the merge button without thinking
<luke-jr>
maintainers aren't supposed to be a position of privilege
<jeremyrubin>
i dont think i'm advocating holding feet to the fire moreso identifying where our current maintainership is stronger/weaker to aid in identifying where we might improve.
<michaelfolkson>
It isn't just the maintainers knowledge, it is the maintainers' assessment of the reviewers' knowledge
<jeremyrubin>
laanwj: glozow is currently one of the main people writing new mempool code, so her being a maintainer probably doesn't help much
<luke-jr>
MarcoFalke: true, but hopefully the spoofed reviewers would notice before a release
<laanwj>
jeremyrubin: that was exactly my point
<prayank>
laanwj: NACK
<laanwj>
prayank: i'm not asking you
<luke-jr>
…
<prayank>
laanwj: what was it?
<laanwj>
i also don't think brining hijack-ability of github into this is useful now
<jeremyrubin>
laanwj sorry i didn't parse the sarcasm
<ajonas>
re the mempool - I understand the frustration but the reality is that the more sensitive the code and the fewer people understand it, the harder it will be to get in.
<ajonas>
mempool actually has a lot more momentum than it did a year ago
<ajonas>
so review is improving
<laanwj>
the pr review meetings are probably helping!
<MarcoFalke>
jeremyrubin: I don't think this is sacrasm. maintainers are naturally those that review the most. For example, I used to review every test pull request, so I became test maintainer
<ajonas>
it's like p2p 2-3 years ago when it became more of an area of interest
<laanwj>
MarcoFalke: it was like half sarcasm half a serious proposal
<jeremyrubin>
i think the sarcasm was that the talent pool is shallow so right now we'd be making the person writing be in a position to not merge their own thing
<luke-jr>
MarcoFalke: (and you do a good job at it)
<prayank>
laanwj: changing RBF policy in core because of xyz reasons in abc project is not going to improve anything FYI and it doesn't matter who is the maintainer
<luke-jr>
jeremyrubin: maintainers can merge their own thing if it gets reasonable review ACKs
<laanwj>
MarcoFalke: i think it'd be a good idea but not so much to get more review, just to have someone continuously involved with it in the project
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grettke has joined #bitcoin-core-dev
<laanwj>
in any case, concrete proposals for maintainers would be useful
brunoerg has joined #bitcoin-core-dev
<jeremyrubin>
laanwj: that's basically what i'm trying to point out, that it'd be good if our 'maintainership coverage' is documented so that we can better it for different areas of the code
<laanwj>
for different areas
<jeremyrubin>
mempool as an example, but other parts too
<laanwj>
preferably people stepping up themselves and not being sacrificed :p
<luke-jr>
maybe more IRC "rtm" would help
<laanwj>
yes
<laanwj>
more discussion here would help in any case i think
<ajonas>
I guess it's worth recognizing in this discussion and the summary that being a maintainer is hard
<ajonas>
thank you to those that are shouldering that load
<laanwj>
as said, github just has too large volume of activity, no one can keep up with it, if there's anything of note it's good to bring it up here
<jeremyrubin>
one concept: maintainers can delegate explicitly (e.g., on GH) the maintainer decision on a PR if theres not one who feels qualified
<laanwj>
thanks ajonas
<jeremyrubin>
sort of in-between of being a formal maintainer v.s. giving someone else the RTM call
brunoerg has quit [Ping timeout: 240 seconds]
<laanwj>
i mean the first step is just to communicate, are you unsure, ask it, don't wait until someone gets around to your PR by accident :)
<michaelfolkson>
Agreed. I think just more communication is the solution rather than creating new roles
brunoerg has joined #bitcoin-core-dev
<laanwj>
any other topics?
<luke-jr>
I wonder if that bitcoinacks website was helpful
<michaelfolkson>
I think it is fine for a maintainer to say on a PR "I think this is ready to merge but I'm not as familiar as I'd like with this part of the codebase. Any thoughts from Person A, B, C"
<achow101>
luke-jr: I tried using it a few weeks ago and it seemed to be dead
<laanwj>
luke-jr: yes, i think so, the person maintaining it suddenly stopped doing so
<jeremyrubin>
not much to say, but in running the ctv signet people have been having issues with datadirs because any signet goes to the same place
<jeremyrubin>
it might be nice if signets had e.g. a per challenge chainstate directory or something
<jeremyrubin>
or if bitcoin.conf could have multiple [signet.xyz]'s for configging different named signets
<jeremyrubin>
dont really have any idea of how to approach that so if anyone has any thoughts would love them before i spend any time on it
<laanwj>
luke-jr: there was some discussion about it at the time and we moved it into bitcoin-core at some point https://github.com/bitcoin-core/bitcoin-acks , but no one picked it up
<prayank>
jeremyrubin: asking to backup old signet datadir, delete and relaunch can be workaround for now and maybe separate dir in future
sudoforge has quit [Quit: 404]
brunoerg has quit [Ping timeout: 245 seconds]
<jeremyrubin>
prayank: certainly works for now
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<laanwj>
jeremyrubin: yes, that would make sense
<achow101>
signets could be identified by the hash of the challenge, and we make datadirs like "signet_<challenge hash>"?
<jeremyrubin>
i will probably just make the fork that i have make a different dir by default to skirt the problem for now (going to add default params to that branch)
<jeremyrubin>
achow101: one question I had is if challenges can change over time
Talkless has quit [Quit: Konversation terminated!]
<michaelfolkson>
luke-jr: It also had the problem of people not following the review guidance (Concept ACK, Approach ACK, ACK) and using tACK, utACK, crACK etc
<achow101>
jeremyrubin: wouldn't that break validating old blocks?
<sipa>
could they be identified by the hash of the genesis block?
<sipa>
jeremyrubin: Pretty sure they challenge cannot be changed
<jeremyrubin>
achow101: depends, are the old scriptcodes covered in the sig?
sudoforge has joined #bitcoin-core-dev
<achow101>
sipa: IIRC the genesis is shared
<sipa>
jeremyrubin: the signet block hash covers the challenge
<jeremyrubin>
It would also be nice if bitcoin core could have multiple signets in the chain configs
<sipa>
(it's done using a fake transaction which creates a UTXO with scriptPubKey=challenge, and then another transaction spending that UTXO)
<sipa>
so the prevhash of the spending input indirectly is derived from the challenge
<jeremyrubin>
i think nicknames are a little better than hash of signetchallenge, although hash of signetchallenge does guarantee uniqueness
<jeremyrubin>
it'd also be good if 1 bitcoin.conf could configure >1 signet so i think the [signet.xyz] format is probably right
<jeremyrubin>
maybe we can do user configured nicknames, and the directory can be based on the challenge?
<sipa>
i think i'd prefer that
<sipa>
have dirname/configsection be signet_<hash(challenge)>, but then (perhaps later) add a way to configure a nickname for a signet, to allow easy selection on commandline?
brunoerg has joined #bitcoin-core-dev
<jeremyrubin>
and i guess for backwards compat, just signet is the default one?
<sipa>
right
<laanwj>
right, "how to avoid collisions" and "how to configure signets user friendly" are more or less separate problems
<sipa>
laanwj: exactly
<jeremyrubin>
i dont think we need the signet_hashchallenge in the config section
<jeremyrubin>
it's redundant with the signetchallenge field
<jeremyrubin>
so maybe we can just infer it
<jeremyrubin>
[anynameyoulike] signet=1 signetchallenge=x and infer it?
ghost43 has quit [Remote host closed the connection]
<jeremyrubin>
i'll see if i can put something together with that
<laanwj>
we're running out of time
<achow101>
could be problematic if you did [test] signet=1
<achow101>
I liked the [signet.xyz] suggestion, and just parse the xyz name from that
ghost43 has joined #bitcoin-core-dev
<jamesob>
achow: +1
<jeremyrubin>
thanks :)
<laanwj>
achow101: yes, seems better to be explicit
<laanwj>
minimize potential ambigiousness
grettke has joined #bitcoin-core-dev
<laanwj>
anyhow, time to close the meeting, thanks everyone for attending
ronoaldo has quit [Quit: Konversation terminated!]
<michaelfolkson>
Any meeting topics?
ghost43 has quit [Remote host closed the connection]
<prayank>
I did not ask this earlier because it could be OT. Is anyone in touch with it hebasto? I am assuming he was in Ukraine, there are lot of problems there, did not see him active since last 24 hours on Github or Twitter or meeting.
ghost43 has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
<laanwj>
yes, we're in touch with him
brunoerg has quit [Ping timeout: 245 seconds]
brunoerg has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
baakeydow has quit [Quit: baakeydow]
bfsfhkacjzgcytf has quit [Ping timeout: 240 seconds]
Guest3 has quit [Quit: Client closed]
prayank has joined #bitcoin-core-dev
baakeydow has joined #bitcoin-core-dev
<prayank>
laanwj: thanks for sharing. hoping he is okay.