<bitcoin-git>
bitcoin/master 3f4b104 Sergi Delgado Segura: test: make sure we are on sync with a peer before checking if they have se...
<bitcoin-git>
bitcoin/master ae9eaa0 glozow: Merge bitcoin/bitcoin#31760: test: make sure we are on sync with a peer be...
<bitcoin-git>
[bitcoin] glozow merged pull request #31760: test: make sure we are on sync with a peer before checking if they have sent a message (master...2025-01-fix-p2p-orphan-halding-requests-check) https://github.com/bitcoin/bitcoin/pull/31760
eval-exec has joined #bitcoin-core-dev
<glozow>
sr_gi: remember to delete the template text before you open a PR, as the full OP is included in the merge commit
<bitcoin-git>
[bitcoin] hebasto opened pull request #31809: Prepare "Open Transifex translations for v29.0" release step (master...250206-translations) https://github.com/bitcoin/bitcoin/pull/31809
pyth has quit [Ping timeout: 248 seconds]
pyth has joined #bitcoin-core-dev
rkrux has quit [Quit: Client closed]
kevkevin has quit [Ping timeout: 244 seconds]
pyth has quit [Ping timeout: 252 seconds]
pyth has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
kevkevin has joined #bitcoin-core-dev
Victor_sueca has quit [Ping timeout: 244 seconds]
Victor_sueca has joined #bitcoin-core-dev
aleggg has joined #bitcoin-core-dev
Earnestly has quit [Remote host closed the connection]
Earnestly has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
VonNaturAustreVe has joined #bitcoin-core-dev
VonNaturAustreVe has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 276 seconds]
Earnestly has quit [Ping timeout: 260 seconds]
Earnestly has joined #bitcoin-core-dev
<jon_atack>
laanwj: great!
eval-exec has joined #bitcoin-core-dev
hernanmarino has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
hernanmarino has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 268 seconds]
eugenesiegel has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 244 seconds]
mcey has joined #bitcoin-core-dev
mcey has quit [Remote host closed the connection]
mcey has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
Earnestly has quit [Ping timeout: 252 seconds]
Earnestly has joined #bitcoin-core-dev
Guest25 has joined #bitcoin-core-dev
VonNaturAustreVe has quit [Quit: Leaving]
<bitcoin-git>
[bitcoin] glozow opened pull request #31810: TxOrphanage: account for size of orphans and count announcements (master...2025-02-orphanage-accounting) https://github.com/bitcoin/bitcoin/pull/31810
bitdex has quit [Ping timeout: 264 seconds]
bitdex has joined #bitcoin-core-dev
infernix has quit [Ping timeout: 246 seconds]
Guyver2 has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<glozow>
#topic Erlay WG Update (sr_gi, gleb, marcofleon)
<theStack>
hi
pablomartin has joined #bitcoin-core-dev
<gleb>
I’m converging my new research results with sergi and I hope we proceed with more implementation work real soon :)
<sr_gi[m]>
I don't have much to report this week, I continued working on some of the proposed improvements after last week's meeting, but no results so far, mostly brainstorming. I did start making the approach and experiments more easily accessible on delving, so people that are not following too closely have an easy access to them
<glozow>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
i'll have something to shill at coredev but no update today
<glozow>
ok
<glozow>
I don't see people for kernel, benchmarking, silent payments, SV2, musig, legacy wallet removal, or multiprocess
<glozow>
I'll go next, please lmk if you want to give a WG update
<glozow>
#topic orphan resolution WG Update (glozow)
<glozow>
I've opened #31810 which does internal tracking for number of announcements and "memory usage" (weight). This has no behavior changes and should be reviewable by anybody. The second PR to actually add *limits* for these things is also coming soon.
<glozow>
yes! extra emphasis on "this should be really straightforward to review"
<glozow>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<sipa>
hello
<sipa>
not much observable review on txgraph (so far?), but i've been getting comments from sdaftuar based on rebasing the full cluster mempool code on top, and making changes/additions to help with those
<sipa>
also we had a nice review club by glozow about it yesterday, the discussion may be interesting for anyone wishing to review
<sipa>
otherwise nothing big happening on my side, just addressing feedback
<achow101>
We might want to consider turning on the limit on new github users
<ajonas>
I modified it a bit and will need to push back my changes
<ajonas>
*a lot
<glozow>
ajonas: you are using the british "a bit"
<glozow>
ok well, everybody, start thinking about who's going to review your PRs for v29 and which ones you'll review. that's all
<glozow>
anything else to discuss?
<stickies-v>
interesting how the mean personal satisfaction < mean project satisfaction. i don't think that would track with many psychology experiments
Diana has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 264 seconds]
<glozow>
stickies-v: I imagine it could be modesty
<glozow>
I don't think I'd ever give myself a 5
<sipa>
or selection bias
<glozow>
#endmeeting
<corebot>
glozow: Meeting ended at 2025-02-06T16:26+0000
<sipa>
"this project sucks!" people might not bother responding
Emc99 has quit [Quit: Client closed]
Diana has quit [Client Quit]
<ajonas>
sipa: that is exactly what I jotted down for everyone who didn't respond
<Murch[m]>
achow101: What restrictions were you considering to add for new users? If there were a way to get rid of "no comment approvals" that would be neat, but then they’d probably just add a garbage comment
<sipa>
ajonas: (that's not the reason i didn't respond, promise)
<stickies-v>
yeah, fair. I was thinking about Dunning-Kruger but I guess skills is different from satisfaction. Easier to be modest on satisfaction :-D
<Murch[m]>
This might be interesting given that we don’t really use the "approve" feature but have our ACKs and NACKs
<achow101>
Can't see the image
<sipa>
same
<Murch[m]>
Moderation Options ⇒ Code review limits ⇒ Limit to users explicitly granted read or higher access.
<Murch[m]>
> When enabled, only users explicitly granted access to this repository will be able to submit pull request reviews that "approve" or "request changes". All users able to submit comment pull request reviews will continue to be able to do so.
<achow101>
Hmm, intersting
<Murch[m]>
Please for the whole org ^^
<Murch[m]>
We have had a lot of spam in the BIPs repository
<bitcoin-git>
[bitcoin] instagibbs opened pull request #31811: test: test_inv_block, use mocktime instead of waiting (master...2025-02-tx_dl_mocktime) https://github.com/bitcoin/bitcoin/pull/31811
<achow101>
There are bip authors who use approvals though
<Murch[m]>
Mh, fair
<achow101>
We can try and see if anyone complains
<Murch[m]>
Maybe do it just for the /bitcoin project and not the org then
<Murch[m]>
Also the "request changes" might be used more often than the approval, while all the spam is empty approvals
<achow101>
i rarely see anyone use request changes, and I believe the few ties i'e seen it, it's been by org members
<achow101>
so anyone who has used it should still be able to
<achow101>
enabled the code review limits on all bitcoin/ repos
<achow101>
although review comments also cannot be deleted
dzxzg has quit [Quit: Client closed]
jarthur has joined #bitcoin-core-dev
<Murch[m]>
<achow101> "i rarely see anyone use request..." <- I think it’s used frequently in the BIPs repo
<Murch[m]>
Okay, let’s see what happens
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 268 seconds]
jespada has quit [Ping timeout: 248 seconds]
jespada has joined #bitcoin-core-dev
<jarolrod>
Apparently my messages didn’t send during the meeting :(
<jarolrod>
Over the past two weeks, contributors on the QML GUI have been planning out next steps as we finalize some of the larger features.
<jarolrod>
want to announce the creation of a working group for the QML GUI to:
<jarolrod>
- Broadcast status updates to core devs who are interested in the progress of the work.
<jarolrod>
- Serve as a place to discuss adjacent work like, QT6 migration, an effective wallet interface for the GUI, what role the QML GUI can play within the multiprocess work, and a redesign for bitcoincore.org (https://youtu.be/e2m1iEWJplM)
<jarolrod>
- Serve as a place where core devs can hear from and interface with the Bitcoin Design Community, who’s been at the heart of a lot of the work
<jarolrod>
If you’d like to be added to the group please DM me here on IRC, over Signal, Twitter, TikTok, wherever you can find me.
<jarolrod>
We also intend to provide weekly updates at the IRC meetings.
<jarolrod>
laanwj: a renewal to 2034 needs a design to last until 2034 🔮
<instagibbs>
https://github.com/bitcoin/bitcoin/pull/31810#discussion_r1945376879 sipa my understanding was that we'd be repeatedly un-announce a particular peer based on the reservation-use ratio (in weight). The trim loop would just keep going until both total (deduplicated) weight usage and total announcement count goes below required levels
<instagibbs>
I guess I never saw the new approach literally written down, so maybe misunderstanding
<sipa>
instagibbs: my understanding was that we'd have two dimensions: the memory one (weight, whose global value is deduplicated orphans weight, and whose local value is sum of announcements' weight) and a cpu one (announcements, whose global count is total number of announcements, local count is announcements per peer)
<instagibbs>
thinking more about my model, yeah might be problematic. Someone could drive up announcement counts with illegitimate tiny txns and punish honest relayers pretty easily
<sipa>
and then we'd separately enforce: if global memory is too high, pick an announcement from the peer with the highest local_weight / reservation to remove
<instagibbs>
it's two resource buckets
<sipa>
if global cpu is too high, pick an announcement from the peer with the highest local_count / reservation to remove
<instagibbs>
agreed, my idea was wrong/insufficient
<sipa>
and i think you missed this part: you can do both in the same loop, by computing max(global_weight / global_reservation, global_count / global_max_count) as global number, and max(local_weight / local_reservation, local_count / local_reservation) as local one to remove from
rishkwal has quit [Quit: Client closed]
<sipa>
but this means you need: (a) global deduplicated orphans weight (b) per-peer announced orphans weight (c) global number of announcements (d) number of announcements per peer
<instagibbs>
yes
<sipa>
and i don't see (c) and (d) being tracked in the current PR yet
<instagibbs>
(c) I think is calculated, but not (d)
andrewtoth_ has joined #bitcoin-core-dev
andrewtoth has quit [Remote host closed the connection]
kevkevin has quit [Remote host closed the connection]
eugenesiegel has quit [Quit: Client closed]
<b10c>
ajonas: stickies-v: Murch[m]: no-comment "Approves" are a "reviewed" event with state=APPROVED and are included in the backup. I haven't checked if these are filtered by the bitcoin-core-contributor-stats tool
<darosior>
It might be confusing to release both a bitcoin-wallet utility and a bitcoin-wallet binary as part of multiprocess?
<darosior>
We could rename the utility, but then it would be nice to at least have one deprecation cycle. Given recent momentum i estimate it's possible we might release multiprocess in 30.0, which means if we want to deprecate the bitcoin-wallet utility name we should do it.. now?
kevkevin has joined #bitcoin-core-dev
pyth has quit [Remote host closed the connection]
<sipa>
bitcoin-wallet-util ?
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
Cory58 has quit [Quit: Client closed]
Cory58 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
johnny9dev584508 has quit [Ping timeout: 252 seconds]