<laanwj>
i'm not sure, there's always something last minute that could be considered, but that way you'll be doing rc's forever
<fanquake>
laanwj: it was just mentioned in #22720 that we could do it. Although given no review / feedback I'd be happy to drop that change from the PR, and just do the doc change, which wouldn't need a new RC either
<fanquake>
That way we could just merge that PR, with the doc addition, and move onto tagging final
<laanwj>
exactly, the doc change could go in without an rc
<fanquake>
I'll drop the other change out of that PR. We should be getting 0.21.2 out soon.
<laanwj>
sgtm
c_arc has joined #bitcoin-core-dev
<laanwj>
a shorter rc cycle is generally enough for minor releases, as there aren't new features or large changes, no regressions have been reported so i think this one has been long enough
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
earnestly has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 246 seconds]
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
bitcoin/master fa10fbc MarcoFalke: doc: Fix RPC result documentation
<bitcoin-git>
bitcoin/master 3120bce fanquake: Merge bitcoin/bitcoin#23054: Use C++11 member initializer in CTxMemPoolEnt...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake merged pull request #23054: Use C++11 member initializer in CTxMemPoolEntry (master...2109-cpp11MemberInitMempool) https://github.com/bitcoin/bitcoin/pull/23054
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<fanquake>
Chasing opinions in #23060. Increasing our minimum compiler and lib(std)c++ requirements a little is another step towards using std::filesystem, and taking advantage of more C++17.
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] darosior opened pull request #23075: refactoring: Fee estimation functional test cleanups (master...fee_est_test_cleanup) https://github.com/bitcoin/bitcoin/pull/23075
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guyver2 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #23076: Pass CFeeRate and CTxMemPool in-params by reference to const (master...feerate-and-txmempool-fixups) https://github.com/bitcoin/bitcoin/pull/23076
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
bitcoin/master 64e1ddd Martin Zumsande: log: call LogPrint only once with time data samples
<vasild>
that is a nice, unintended side effect! :-D
<jonatack>
yes, on mainnet the most frequent contentions I see are the cs_vNodes ones, and many/most on them were replaced by only a handful of connman.cs_vNodes contention *per hour* instead...grep "connman.cs_vNodes" ~/.bitcoin/debug.log
<vasild>
\o/
<vasild>
How do I add it to hi-prio?
<jonatack>
ask here for it to be added
tripleslash has quit [Remote host closed the connection]
<sipa>
vasild: added
Guyver2_ has joined #bitcoin-core-dev
<vasild>
Thanks!
tripleslash has joined #bitcoin-core-dev
<vasild>
one of those Sock'ification PRs needs a rebase, but I decided to ignore it until I submit the cjdns PR
Guyver2 has quit [Ping timeout: 246 seconds]
<vasild>
IIRC the code emitted a warning on windows which at the time CI was run on the PR was non-fatal, so CI was/is green. However after that master changed treating of warnings on windows to errors, so now if re-run it will fail.
Guyver2_ is now known as Guyver2
<jonatack>
vasild: at any rate am curious if you or others see a reduction in contentions too
<vasild>
must be, but I never ran with -debug=lock
sipsorcery has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
lightlike has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
gleb7 has quit [Quit: Ping timeout (120 seconds)]
gleb7 has joined #bitcoin-core-dev
gleb7 has quit [Client Quit]
c_arc has joined #bitcoin-core-dev
piku has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<darosior>
Can someone re-kick CI on #23075 please? Have a 'Failed to start an instance! CreateContainerError: context deadline exceeded' error
<fi3>
that using a rust library in core is not feasible "until a secure bootstrap without trusted
<fi3>
third party binaries is practical". But if guix is used to build the library you are using a secure
<fi3>
bootstrapped compiler.
<fi3>
What is the procedure to follow in order to request to discuss something in a meeting? ty
c_arc has joined #bitcoin-core-dev
fi3 has quit [Quit: Client closed]
fi3 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<sipa>
#proposedwalletmeetingtopic (by fi3) rust library in bitcoin core (23049)
<fi3>
thanks
c_arc has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 260 seconds]
davterra has quit [Quit: Leaving]
sipsorcery has joined #bitcoin-core-dev
fi354 has joined #bitcoin-core-dev
fi354 has left #bitcoin-core-dev [#bitcoin-core-dev]
fi356 has joined #bitcoin-core-dev
fi3 has quit [Ping timeout: 256 seconds]
fi356 has quit [Client Quit]
fi3 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
fi3: Did you want to discuss in the wallet meeting tomorrow or today's general Core meeting?
<sipa>
... what does this have to do with the wallet?
<michaelfolkson>
#proposedwalletmeetingtopic
<fi3>
hi I think that it is more suited for the today meeting
<sipa>
michaelfolkson: oh, oops!
<michaelfolkson>
#proposedmeetingtopic (by fi3) rust library in bitcoin core (23049)
<michaelfolkson>
sipa: :)
<fi3>
thanks
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
fi3: There may have been advancements since this was discussed last but some context from previous discussions on Rust is here: https://github.com/bitcoin/bitcoin/issues/17090
<laanwj>
#topic rust library in bitcoin core (fi3)
<core-meetingbot>
topic: rust library in bitcoin core (fi3)
<fi3>
What do you think about using rust libraries in core? My understanding is that big blocker was trust
<fi3>
rustc binary. Now that guix is used to build release the that problem should be solved as the
<fi3>
binary to trust are the same for cpp and rust.
<luke-jr>
it's not
<luke-jr>
Rust itself is untrustable
<sipa>
why? it can be bootstrapped with a C compiler?
<dongcarl>
?
<luke-jr>
no, it can';t
<BlueMatt>
yes it can\
<BlueMatt>
and is
<luke-jr>
sorry, I meant Guix there
<fi3>
in guix is bootstrapped from cpp
<BlueMatt>
almost all distro rustc is bootstrapped from cpp
<fi3>
then ocaml
<laanwj>
fi3: is it for an optional feature?
<luke-jr>
Guix requires a trusted third-party binary
<luke-jr>
several IIRC
<BlueMatt>
not anymore, its not built from ocaml, its usually built from mrustc now
<fi3>
yes if for an optional feature
<sipa>
luke-jr: please, not that argument again. Guix is how we build releases.
<laanwj>
i don't think we should require rust for build at this point, but introducing it at some point for optional features sounds fine to me
<luke-jr>
sipa: we support more than just static binaries
<luke-jr>
if we are going to only support Guix, that's just abusrd
<sipa>
luke-jr: of course not
<BlueMatt>
I dunno if stratumv2 as an optional feature makes sense, at least unless there's parallel release builds "for miners"
<BlueMatt>
which I think would be ok
<BlueMatt>
no reason for most nodes to have it built-in, but ideally there would also be release builds with it
<BlueMatt>
if its only available via self-compile I think that'd suck
<fi3>
BlueMatt: why not optional?
<BlueMatt>
i think requiring self-compile does limit peoples' willingness to run things a lot
<BlueMatt>
sadly
<fi3>
ok
<sipa>
one step at a time
<BlueMatt>
but, again, having it be optional with a parallel release track would be fine, and that would hopefully address most concerns?
<laanwj>
'making it optional' and 'making it part of the release binaries' are distinct things
<BlueMatt>
but, sure, also doesn't have to happen for the first release with it
<BlueMatt>
true
<laanwj>
making it optional means that it is still possible to compile bitcoind, albeit lacking some features, on a system without rust installed
<sipa>
^
<laanwj>
which is imo important
<achow101>
it could be optional in the same way the wallet is optional
<BlueMatt>
yea, ok, fair, definitely should be optional in that sense
<fi3>
agree
<laanwj>
tor did a similar thing
<dongcarl>
laanwj: autoconf default=auto is what you mean by "optional"?
<laanwj>
dongcarl: having an autoconf option at all is optional
<laanwj>
but yes, in Tor's case it will simply go through configure (and i suppose, disable some things) if you configure without a rust compiler installed
<BlueMatt>
ok, seems like there's relative agreement that its ok to move forward here, given its optional?
<dongcarl>
right yeah I think that we can all agree on, how about whether to ship it for release binaries?
<sipa>
i did comment on the PR with a few questions
<BlueMatt>
i dont think we need to decide that for first release
<laanwj>
yes, i think it was the same last time, everyone apart from luke-jr probably :)
<dongcarl>
we can also punt the release binaries question for later
<luke-jr>
how about just having it C++ like PR author said he could?
<BlueMatt>
probably answer is no for first release, but definitely want it for release builds sooner rather than later
<BlueMatt>
i guess if the guix changes are ready it can/should go in the first release with it, but no reason to block on that imo
<laanwj>
right, i am not comfortable with making a decision about the release binaries yet
<luke-jr>
at the very least, release binaries would be much more changes, so belong in a later PR
<laanwj>
it depends on just how big a dependency tree is imported by this, it always worries me a bit with rust things
<BlueMatt>
yep
<BlueMatt>
laanwj: fwiw, there is no non-tree dependency here
<luke-jr>
but there's no benefit to Rust over C++, so it would make far more sense to just do it as C++
<BlueMatt>
and the current pr does *not* use cargo
<BlueMatt>
only rustc directly
<michaelfolkson>
This isn't a Rust question but this is the Stratum v2 that Braiins is using? Anyone else? Is this the right time to support Stratum v2 in Core?
<BlueMatt>
(cargo being the thing that fetches code from the internet, rustc being just the compiler)
<luke-jr>
BlueMatt: there's no rust stdlib dep?
<BlueMatt>
yes, rustc bundles libstd
<sipa>
luke-jr: that's a good question - if this is Rust code that is being developed and used by several projects, i think it is preferable to be able to use that code, over demanding a rewrite in C++
<BlueMatt>
michaelfolkson: chicken-and-egg problem. but its not a "just baiins" thing, look at it more as a replacement for getblocktemplate in this case
<BlueMatt>
michaelfolkson: this is only the "provide block template" part
<laanwj>
BlueMatt: that's very good
<BlueMatt>
nothing more than that, and we should expect other pools to switch to this for several reasons over getblocktemplate
<sipa>
if this is Rust code that is being developed now with the sole purpose of using it in Bitcoin Core, I too would prefer it being written in C++
<BlueMatt>
even if no users ever use it it would still be a pretty big win for several reasons
<michaelfolkson>
BlueMatt: Yeah that's fair. Including this could help the chicken and egg problem I'm guessing
<fi3>
luke-jr: that is a rust library that is intended to be used also for other project than core
<fi3>
sipa: same as above
<sipa>
fi3: ok, good
<luke-jr>
miners and pools using only anti-bootstrappable binaries would be a security concern for Bitcoin too
<dongcarl>
luke-jr: Are you unable to bootstrap rust on your own system?
<dongcarl>
luke-jr: Because mrustc doesn't have a powerpc port, is that right?
<luke-jr>
dongcarl: I tried on x86_64 too
<luke-jr>
dongcarl: I have not tried again int he past week since someone apparetnly got ppc64le to work, though
<BlueMatt>
anyway, it seems we can move on from this topic
<laanwj>
yes
<BlueMatt>
i dunno if there's more to be said, the pr discussion is active.
<dongcarl>
👍
<laanwj>
it's always the same bootstrappign discussion, i would be first to agree it's a horrendously difficult problem but we're not going to solve that here
<laanwj>
any other topics?
<luke-jr>
laanwj: we don't have to solve it here, so long as we don't use Rust until they solve it ;)
<laanwj>
luke-jr: so are you bootstrapping your C compiler from TTL logic?
<luke-jr>
laanwj: from some pre-Bitcoin C compiler, ultilately
<luke-jr>
(yes, my migration to PPC64 was done by cross-compiling everything initially)
<jonatack>
fi3: is there a link to more information on other projects that would use the rust implementation? (didn't see one at first glance, sorry if I missed it)
<fi3>
jonatack: the linked github stratum repo in the PR is a big monorepo that contain the libraries as well (not yet) some implementation of the roles defined by Sv2 as Proxy and Pool