<bitcoin-git>
bitcoin/master f87594d Hennadii Stepanov: build: No need to provide defaults for darwin-specific tools
<bitcoin-git>
[bitcoin] fanquake merged pull request #24866: build: No longer need to hack the `PATH` variable in `config.site` (master...220415-tools) https://github.com/bitcoin/bitcoin/pull/24866
Guyver2_ has joined #bitcoin-core-dev
Guyver2 has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 240 seconds]
bitdex has joined #bitcoin-core-dev
yanmaani has quit [Remote host closed the connection]
yanmaani has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
evanlinjin has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
belcher has quit [Ping timeout: 272 seconds]
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
ZeroMaster has quit [Ping timeout: 260 seconds]
belcher has joined #bitcoin-core-dev
ZeroMaster has joined #bitcoin-core-dev
Evel-Knievel has quit [Ping timeout: 246 seconds]
Evel-Knievel has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #25067: validation, refactor: make MainSignalsInstance() a class, move to h (master...make-MainSignalsInstance-a-class-and-move-to-header-file) https://github.com/bitcoin/bitcoin/pull/25067
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
Zenton has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
ZeroMaster has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
remyers[m] has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
szkl has quit [Quit: Connection closed for inactivity]
Guyver2__ has joined #bitcoin-core-dev
Guyver2_ has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
bitdex has quit [Quit: = ""]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Guyver2__ has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
mudsip has quit []
SpellChecker has quit [Quit: bye]
SpellChecker has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<fanquake>
cleaned up all the spam PRs and other crap
<achow101>
fanquake: I noticed some wiki vandalism from that user
<sipa>
They were already blocked on the bitcoin org; I also blocked them from the bitcoin-core org.
<achow101>
bips wiki specifically
<fanquake>
I haven't seen anything in the wiki other than spam as of late. Mostly randoms/spammers creating pages. It'd be good to try and lock that down in some way?
<fanquake>
*bips wiki
Guest42 has joined #bitcoin-core-dev
<lightlike>
could also cleanup after Miminlaili (24410)
xyephy has joined #bitcoin-core-dev
Guest42 has quit [Quit: Ping timeout (120 seconds)]
xyephy has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 276 seconds]
seejee has quit [Ping timeout: 252 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 248 seconds]
evanlinjin has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
csknk has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
sipsorcery has joined #bitcoin-core-dev
<theStack>
are there currently any alternative concepts availabe or for discussion for BIP322? i'd like to focus more on generic signing support and wonder if there's a reason why the BIP322 PR (#24058) didn't get more traction yet
<glozow>
Hi! I originally planned to propose a proposal + roadmap, but I haven't had as much time to prepare for expected questions as I hoped, so I'll defer that to another week.
<glozow>
I can give updates on what I’m working on, but no proposal this week. So my apologies for the disappointment if anybody came specifically expecting to see a proposal.
<glozow>
I’ve split the project into two groups: mempool logic and p2p relay stuff. Since all the mempool logic apart from package RBF is done, I’m working on a p2p package relay BIP + implementation.
<laanwj>
no problem, we can bring back the topic next week if you prefer that
<glozow>
that would be lovely, thanks so much
<glozow>
#24836 is the PR open for review if anybody wants to help out. #25038 is also open for browsing as well. Unfortunately there is a pinning attack that it doesn’t fix, so I am working out what to do about it. That’s why it’s a draft.
<sipa>
I'd expect cases where temporaries are accidentally passed to be the ones that are most likely to be missed through code review.
<MarcoFalke>
Only at run time: valgrind, msan, asan, etc
<laanwj>
(besides switching to another programming language)
<laanwj>
so i'd say this is the "Better than nothing" category then
<laanwj>
combine it with run-time approaches
Talkless has quit [Quit: Konversation terminated!]
<sipa>
And even if the analysis isn't all that strong, they're still useful as developer documentation.
<laanwj>
and don't add functions that are clearly dangerous like return string views *ducks*
<MarcoFalke>
I think it can be applied pretty broadly, basically everywhere where a pointer/reference is passed and the pointer/reference lifes on after the functions returns
<laanwj>
yes
<MarcoFalke>
So I think if we start applying them, the code will become a bit more verbose
<MarcoFalke>
Just wanted to see if anyone would want to object that
csknk has quit [Quit: leaving]
<sipa>
Just in function/constructor declarations, rights?
<laanwj>
i mean there's clearly some degree of verbosity where it just becomes silly make-work and isn't worth it compared that what is gained
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<MarcoFalke>
I think it is missing any stuff that was recently added at least: m_params references, and potentially more CBlockIndex passing
<laanwj>
jonatack: that doesn't look bad
<laanwj>
sipa: seems so then?
<MarcoFalke>
Right, it only attaches to functions or function parameters
<laanwj>
also important is how difficult it is to maintain, e.g. can we expect a lot of false positives when people compile with a different compiler
<sipa>
Yeah, I don't mind adding them. I don't think we go start hunting down every last place where such an attribute could be added, but there seem to be very little downsides to adding them where appropriate.
<laanwj>
(remembers -Wshadow)
<sipa>
it preprocesses to nothing on non-clang compilers
<laanwj>
right
<MarcoFalke>
When I added it in #22278 for CScript I actually ran into the bug before, but for other places, I am less sure if it will be equally useful
<MarcoFalke>
I did some odd CScript{ stuff } in tests and broke valgrind
<josibake>
if it's encouraged to add them where appropriate, can we add something to the developer docs? perhaps a brief explanation of why to use them?
<sipa>
hmm
<josibake>
s/them/it
<MarcoFalke>
Probably was []{return CScript{} << 1;}()
<MarcoFalke>
Ah no, []-> decltype(auto) {return CScript{} << 1;}()
<MarcoFalke>
Pretty obscure
<sipa>
Is that returning a `CScript` or a (const) `CScript&`?
<sipa>
(the latter would actually be a lifetime issue)
<MarcoFalke>
operator<< returns &
<MarcoFalke>
sipa: Yeah, that was the reason I added LIFETIMEBOUND
<sipa>
Yes, but doesn't `-> decltype(auto)` return a non-reference?
<MarcoFalke>
no, IIRC
<sipa>
ok
<sipa>
Sounds like the lifetimebound is doing its job then.
<jonatack>
josibake: good point. i'll propose a doc along with another (non-contentious) developer notes improvement i have in mind