< fanquake> promag: thanks. If you want to cross-compile and take the binaries onto M1 hardware, that'd be great
< hugohn> @luke-jr can you take another look at https://github.com/bitcoin/bips/pull/1097 ? Thanks.
< luke-jr> hugohn: sorry, I'm very backlogged on bips :/ I'll try to get to it soon
< hugohn> @luke-jr No worries. Appreciate it!
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0ab6ff5e3759...db2990d01f3c
< bitcoin-git> bitcoin/master faf30f2 MarcoFalke: doc: Update bips.md for 0.21.1
< bitcoin-git> bitcoin/master db2990d MarcoFalke: Merge bitcoin/bitcoin#21925: doc: Update bips.md for 0.21.1
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21925: doc: Update bips.md for 0.21.1 (master...2105-docBips) https://github.com/bitcoin/bitcoin/pull/21925
< promag> fanquake: will do sir
< bitcoin-git> [bitcoin] promag opened pull request #21939: refactor: Replace memset calls with array initialization (master...2021-05-msghdr) https://github.com/bitcoin/bitcoin/pull/21939
< promag> wumpus: ^
< wumpus> promag: thank you!
< promag> wumpus: have you checked the other constructor?
< edcba> hi ppl, are there proposals already about energy consumption issue ?
< bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/db2990d01f3c...386ba92e8363
< bitcoin-git> bitcoin/master c30dd02 t-bast: refactor: remove redundant fOnlySafe argument
< bitcoin-git> bitcoin/master 386ba92 Samuel Dobson: Merge bitcoin/bitcoin#21910: refactor: remove redundant fOnlySafe argument...
< bitcoin-git> [bitcoin] meshcollider merged pull request #21910: refactor: remove redundant fOnlySafe argument (master...refactor-fonlysafe) https://github.com/bitcoin/bitcoin/pull/21910
< wumpus> promag: not really, but see no reason why the same principle doesn't hold there
< wumpus> promag: I could check it though
< promag> I'd expect same 3 memsets, worth noting that then 2 arrays get copied over
< bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/386ba92e8363...a31a1ceec721
< bitcoin-git> bitcoin/master 29c9e2c Hennadii Stepanov: wallet: Do not iterate a directory if having an error while accessing it
< bitcoin-git> bitcoin/master a31a1ce Samuel Dobson: Merge bitcoin/bitcoin#21907: wallet: Do not iterate a directory if having ...
< bitcoin-git> [bitcoin] meshcollider merged pull request #21907: wallet: Do not iterate a directory if having an error while accessing it (master...210510-win) https://github.com/bitcoin/bitcoin/pull/21907
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21940: refactor: Mark CAddrMan::Select const (master...2105-addrmanConstSelect) https://github.com/bitcoin/bitcoin/pull/21940
< wumpus> promag: oh uhm oops seems I was checking the wrong binary, have retracted the ACK for now and will redo the check
< promag> wumpus: right, I force pushed
< wumpus> promag: this is the actual generated assembly (for both constructors) https://0bin.net/paste/I6dz6xG0#gVmtOavoCSeoiuDTwa6XnQ1wAmeLojCqQtuAkAEL48z , it's not generating memsets at all but (as far as I can see) correct movX $0x0,(%reg) to clear the memory in question
< wumpus> promag: updated my github post, it checks out anyway
< wumpus> it appears that even with optimization disabled, gcc does some kind of optimization for clearing small data structures
< promag> Thanks wumpus
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21941: fuzz: Call const member functions in addrman fuzz test only once (master...2105-fuzzAddrConst) https://github.com/bitcoin/bitcoin/pull/21941
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/8584a4460d52...58c07426326d
< bitcoin-git> bitcoin/0.21 deff4e7 Kittywhiskers Van Gogh: depends: update Qt 5.9 source url
< bitcoin-git> bitcoin/0.21 58c0742 W. J. van der Laan: Merge bitcoin/bitcoin#21932: [0.21] depends: update Qt 5.9 source url
< bitcoin-git> [bitcoin] laanwj merged pull request #21932: [0.21] depends: update Qt 5.9 source url (0.21...patch-1) https://github.com/bitcoin/bitcoin/pull/21932
< bitcoin-git> [bitcoin] klementtan opened pull request #21942: docs: improve make with parallel jobs description. (master...docs/improve-jX) https://github.com/bitcoin/bitcoin/pull/21942
< bitcoin-git> [bitcoin] vasild opened pull request #21943: Dedup and RAII-fy the creation of a copy of CConnman::vNodes (master...raiify_copying_vnodes) https://github.com/bitcoin/bitcoin/pull/21943
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a31a1ceec721...4741aec1dd28
< bitcoin-git> bitcoin/master 105941b Vasil Dimov: net: use stronger AddLocal() for our I2P address
< bitcoin-git> bitcoin/master 4741aec W. J. van der Laan: Merge bitcoin/bitcoin#21914: net: use stronger AddLocal() for our I2P addr...
< bitcoin-git> [bitcoin] laanwj merged pull request #21914: net: use stronger AddLocal() for our I2P address (master...i2p_local) https://github.com/bitcoin/bitcoin/pull/21914
< bitcoin-git> [bitcoin] prayank23 opened pull request #21944: wallet: Fix issues when `walletdir` is root directory(Windows) (master...wallet-win-root) https://github.com/bitcoin/bitcoin/pull/21944
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4741aec1dd28...b34bf2b42caa
< bitcoin-git> bitcoin/master 1c9255c João Barbosa: refactor: Replace memset calls with array initialization
< bitcoin-git> bitcoin/master b34bf2b W. J. van der Laan: Merge bitcoin/bitcoin#21939: refactor: Replace memset calls with array ini...
< bitcoin-git> [bitcoin] laanwj merged pull request #21939: refactor: Replace memset calls with array initialization (master...2021-05-msghdr) https://github.com/bitcoin/bitcoin/pull/21939
< bitcoin-git> [bitcoin] theStack opened pull request #21945: test: add P2PK support to MiniWallet (master...202005-test-miniwallet-support-p2pk) https://github.com/bitcoin/bitcoin/pull/21945
< Arvidt> What is that version "v22.0" on the last line of https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md ? Is it not Bitcoin version (they all start with v0.) ? Would make sense, since V.0.22 is not released yet and there are backports to 0.20 and 0.21 ongoing.
< achow101> Arvidt: we've dropped the leading 0. from the version number for the next release
< bitcoin-git> [bitcoin] ariard opened pull request #21946: Document and test lack of inherited signaling in RBF policy (master...2021-05-rbf-noinheritance) https://github.com/bitcoin/bitcoin/pull/21946
< luke-jr> Arvidt: master = not released yet
< provoostenator> The bitcoinbuilds.org macOS CI seems to be consistently failing, e.g. https://github.com/bitcoin-core/gui/pull/325
< Arvidt> Thanks, is there any announcement of the version scheme change, and maybe a link to it's discussion? Did not find anything about it.
< sipa> #20223
< gribble> https://github.com/bitcoin/bitcoin/issues/20223 | build: Drop the leading 0 from the version number by achow101 · Pull Request #20223 · bitcoin/bitcoin · GitHub
< provoostenator> Meeting? Or not because Ascension Day?
< wumpus> #startmeeting
< core-meetingbot> Meeting started Thu May 13 19:00:07 2021 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< jonasschnelli> hi
< provoostenator> hi
< hebasto> hi
< wumpus> let's just try, it can be a short meeting i guess
< achow101> hi
< fjahr> hi
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< jonatack> hi
< michaelfolkson> hi
< ariard> hi
< meshcollider> hi
< wumpus> no proposed topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt (fwiw, you can propose a topic at any time in the week with #proposedmeetingtopic <topic>)
< wumpus> any last minute topics?
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< jnewbery> hi
< wumpus> 9 blockers in https://github.com/bitcoin/bitcoin/projects/8 , no bugfixes, no PRs chasing concept ACK
< dongcarl> #topic If possible: Guix dress rehearsal
< sipa> hi
< wumpus> anything that should be added/removed, or is ready for merge?
< midnight> hi
< fjahr> #21726 please for me, I am resolving the conflict at the moment
< gribble> https://github.com/bitcoin/bitcoin/issues/21726 | Add prune blockers to BlockManager by fjahr · Pull Request #21726 · bitcoin/bitcoin · GitHub
< fanquake> hi
< wumpus> fjahr: added (please do take it out of draft)
< fjahr> wumpus: thanks, done
< michaelfolkson> fjahr: Does this still apply? "This is only a VERY rough draft currently, as I am interested in concept/approach feedback."
< kanzure> hi
< wumpus> anything else to add/remove?
< fjahr> michaelfolkson: no, I will change the message in a moment, was just surprised by the conflict
< wumpus> #topic Guix dress rehearsal (dongcarl)
< core-meetingbot> topic: Guix dress rehearsal (dongcarl)
< dongcarl> We’re nearing the start of the contingency buffer period for Guix, in fact, #21239 should be the last piece needed before we reach feature-parity with Gitian.
< gribble> https://github.com/bitcoin/bitcoin/issues/21239 | guix: Add codesignature attachment support for osx+win by dongcarl · Pull Request #21239 · bitcoin/bitcoin · GitHub
< dongcarl> I’d like to do a full dress-rehearsal (with codesigning) of some commit (perhaps just a version of #21239) this week or the next. I’ve already tried with my personal developer certs with win/osx to make sure there aren’t any glaring issues, but perhaps having others try it out will reveal some UX hiccups that can be addressed somewhat easily.
< gribble> https://github.com/bitcoin/bitcoin/issues/21239 | guix: Add codesignature attachment support for osx+win by dongcarl · Pull Request #21239 · bitcoin/bitcoin · GitHub
< wumpus> sounds good to me!
< sipa> ack
< achow101> ack
< dongcarl> I'd be curious if there'd be problems with codesigning an intermediary commit with our certs? I'm guessing that might lead to problems if people get a hold of the resulting binary?
< wumpus> dongcarl: why would that lead to problems?
< achow101> dongcarl: considering the current cert is expired, I don't see why not. the only problem might be in making the signature
< achow101> still working on getting a new cert
< dongcarl> Oh! Signing with expired certs should be fine then...
< wumpus> i mean, we're not going to upload it to bitcoincoreorg, but even if so, it'd be like a pre-rc
< dongcarl> I'm just worried people might try to pass it off as a new release of core or something...
< wumpus> nah, doubtful
< dongcarl> Okay :-)
< dongcarl> Once we have enough review on the codesigning PR
< dongcarl> We can decide on a commit and do the dress rehearsal
< wumpus> i don't think it is code signing that makes the difference in people's minds there
< dongcarl> wumpus: Heh that's true
< wumpus> things like announcements, articles, release notes, etc are
< wumpus> right, let's try to review and merge 21239 soon
< dongcarl> Incidentally, does it matter that osslsign defaults to using sha1 as the digest?
< wumpus> then pick a commit
< dongcarl> I noticed when checking my self-signed binary...
< wumpus> isn't sha1 very broken?
< dongcarl> Right, that's why I was curious... We can supply a flag and choose another digest easily tho
< achow101> If the default is sha1, then that's what we've been using
< dongcarl> Just wanted to make sure if there were any justifications or if it was just overlooked
< wumpus> maybe some old version of windows supports only sha1? i don't know what is the minimum we support nowadays
< dongcarl> I think the codesigning scheme in windows supports having multiple digests
< dongcarl> So we can also just do sha1+sha256
< wumpus> does that complicate the attachment?
< dongcarl> Hmmm, unsure. We can check if the older versions that only support sha1 are too old for us. Anyway, I can open an issue abt this :-)
< wumpus> I think we should initially try with a modern, non-broken digest
< wumpus> if any problems come up i'm sure we'll hear about it
< dongcarl> That too :-)
< dongcarl> That's it from me!
< wumpus> thank you!
< jnewbery> wumpus: I have a couple of requests/announcements.
< wumpus> any other topics?
< wumpus> #topic Requests/announcements (jnewbery)
< core-meetingbot> topic: Requests/announcements (jnewbery)
< jnewbery> 1. I think it's probably time to merge https://github.com/bitcoin/bips/pull/1116 (adding Kalle as BIP editor). It was proposed three weeks ago, has 15 ACKs, and no substantive opposition.
< jnewbery> Luke is still backlogged on BIP PR maintaining, so it'd be nice if he could get a bit of help: http://www.erisian.com.au/bitcoin-core-dev/log-2021-05-13.html#l-37.
< jnewbery> Is there anything else required before we can go ahead and merge that PR?
< luke-jr> not sure how to handle the NACK(s?) on it
< luke-jr> :/
< jnewbery> There are no serious NACKs
< luke-jr> gmaxwell withdrew his?
< jnewbery> yes
< luke-jr> great
< jnewbery> "I endorse Harding's recommendations."
< michaelfolkson> Is there an argument to wait until Taproot has activated (hopefully soon) in case drama on that starts up again? Unfair on Kalle to drop him in it otherwise
< michaelfolkson> Whatever Kalle's preference I guess
< jnewbery> Kalle has ACKed
< jnewbery> luke-jr: are you going to merge this PR?
< michaelfolkson> luke-jr can chat to Kalle and work out whatever is best. I think everyone is happy with Kalle
< jnewbery> luke-jr: if you're not prepared to merge it, does it make sense for someone else with commit access to the repo to merge the PR?
< luke-jr> I'm sorry I am behind, but I don't think breaking process or merging without looking at it properly is an appropriate route to take
< jnewbery> The process has been followed. This has achieved community consensus
< michaelfolkson> If Kalle is happy to sort it out with Luke I don't see the problem. Kalle can flag if he's uncomfortable with his discussions with Luke or how fast it is going
< wumpus> after you've merged it, kallewoof can help you, so it makes sense to prioritize it maybe
< luke-jr> wumpus: yes
< jnewbery> If you're unwilling to merge, then I propose that someone else with merge access go ahead and add kallewoof
< wumpus> ok, anything else?
< jnewbery> wumpus: what's the plan here?
< jnewbery> luke-jr is very clearly blocking something that has overwhelming support
< wumpus> i don't know, please don't ask too much from me now
< fjahr> michaelfolkson: not sure what needs to be sorted out, as jnewbery said, kalle has acked :)
< luke-jr> jnewbery: I propose you stop trolling
< michaelfolkson> Kalle flags if he's uncomfortable with anything. We' re all happy with Kalle and he can discuss with Luke
< jnewbery> wumpus: I'm not asking very much at all. Just that what has overwhelming support gets done
< michaelfolkson> If Kalle comes here and says Luke is blocking the progress then we have a problem. If he doesn't and he's happy with how discussions are going with Luke I don't think we have a problem
< michaelfolkson> Up to Kalle
< ariard> jnewbery: what's the worst-case scenario if this PR isn't merged and things stay as they are? anyone is free to fork and start maintaining a bip repo if they don't like current editorship
< jnewbery> ariard: luke-jr doesn't own the bips repo. He's the steward of a shared resource. He's abusing that stewardship
< luke-jr> no, I am not, liar
< luke-jr> you are acting maliciously now
< ariard> jnewbery: a shared resource which is super easy to fork :)
< luke-jr> I have better things to do than put up with this abuse, ttyl
< michaelfolkson> We doing this again? Just leave it to Kalle. If he's uncomfortable with anything he can raise it. Everyone has agreed to give responsibility to Kalle, trust his judgement
< wumpus> i don't think this is going anywhere like this, any other topics?
< jnewbery> wumpus: I'm still curious what's required to get this merged
< wumpus> there is really not that much hurry to make it heated like this
< michaelfolkson> You should have proposed yourself as a BIP editor if you don't trust Kalle to move this along jnewbery
< jnewbery> michaelfolkson: stop playing games. It's 4:30am in Japan right now. Kalle isn't here.
< wumpus> why does it have to happen here and now
< jnewbery> he's ACKed the PR and is ready to be editor
< michaelfolkson> Games? For trusting Kalle? Rather than imposing my judgement on him? SUre
< jnewbery> wumpus: I'm just asking what needs to happen to get the PR merged
< wumpus> luke-jr already said he's going to merge it
< michaelfolkson> I think we're done
< wumpus> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu May 13 19:34:03 2021 UTC.
< bitcoin-git> [bitcoin] luke-jr closed pull request #21399: Genericide BIP9 in variable/type names and comments (master...vbits_rename) https://github.com/bitcoin/bitcoin/pull/21399