19:00:14 <laanwj> #startmeeting 
19:00:14 <core-meetingbot> Meeting started Thu Sep 23 19:00:14 2021 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:14 <core-meetingbot> Available commands: action commands idea info link nick
19:00:29 <achow101> hi
19:00:31 <fi3> michaelfolkson: I think that when was discussed guix wasn't already the way to go for release builds. Is that correct?
19:00:32 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
19:00:34 <laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:39 <kvaciral[m]> hi
19:00:43 <kanzure> hi
19:00:49 <michaelfolkson> hi
19:00:50 <dongcarl> hi
19:00:56 <fi3> hi
19:00:57 <jarolrod> hi
19:00:58 <meshcollider> hi
19:00:59 <jonatack> hi
19:01:16 <laanwj> one proposed topic this week: rust library in bitcoin core (fi3)
19:01:21 <laanwj> any last minute topic suggestions?
19:01:48 <sipsorcery> hi
19:03:02 <laanwj> PSA: 0.21.2 final has been tagged today
19:03:43 <laanwj> time to dust off the gitian builder if you still have one
19:03:59 <laanwj> #topic High priority for review
19:03:59 <core-meetingbot> topic: High priority for review
19:04:30 <laanwj> according to https://github.com/bitcoin/bitcoin/projects/8   9 blockers, 2 chasing concept ACK
19:04:50 <laanwj> anything to add, remove or that is ready for merge?
19:06:10 <laanwj> nothing at all?
19:06:21 <jonatack> #21526 rfm?
19:06:25 <gribble> https://github.com/bitcoin/bitcoin/issues/21526 | validation: UpdateTip/CheckBlockIndex assumeutxo support by jamesob · Pull Request #21526 · bitcoin/bitcoin · GitHub
19:07:02 <laanwj> jonatack: will take a look, thanks
19:07:37 <michaelfolkson> Bitcoin Core PR review club on #22950 next week
19:07:39 <gribble> https://github.com/bitcoin/bitcoin/issues/22950 | [p2p] Pimpl AddrMan to abstract implementation details by amitiuttarwar · Pull Request #22950 · bitcoin/bitcoin · GitHub
19:08:10 <laanwj> michaelfolkson: great!
19:09:06 <laanwj> #topic rust library in bitcoin core (fi3)
19:09:06 <core-meetingbot> topic: rust library in bitcoin core (fi3)
19:09:40 <fi3> What do you think about using rust libraries in core? My understanding is that big blocker was trust
19:09:40 <fi3> rustc binary. Now that guix is used to build release the that problem should be solved as the
19:09:40 <fi3> binary to trust are the same for cpp and rust.
19:09:50 <luke-jr> it's not
19:09:54 <luke-jr> Rust itself is untrustable
19:10:09 <sipa> why? it can be bootstrapped with a C compiler?
19:10:11 <dongcarl> ?
19:10:12 <luke-jr> no, it can';t
19:10:18 <BlueMatt> yes it can\
19:10:21 <BlueMatt> and is
19:10:26 <luke-jr> sorry, I meant Guix there
19:10:27 <fi3> in guix is bootstrapped from cpp
19:10:31 <BlueMatt> almost all distro rustc is bootstrapped from cpp
19:10:33 <fi3> then ocaml
19:10:38 <laanwj> fi3: is it for an optional feature?
19:10:41 <luke-jr> Guix requires a trusted third-party binary
19:10:47 <luke-jr> several IIRC
19:10:50 <BlueMatt> not anymore, its not built from ocaml, its usually built from mrustc now
19:10:54 <fi3> yes if for an optional feature
19:11:05 <sipa> luke-jr: please, not that argument again. Guix is how we build releases.
19:11:13 <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
19:11:14 <luke-jr> sipa: we support more than just static binaries
19:11:31 <luke-jr> if we are going to only support Guix, that's just abusrd
19:11:38 <sipa> luke-jr: of course not
19:11:44 <BlueMatt> I dunno if stratumv2 as an optional feature makes sense, at least unless there's parallel release builds "for miners"
19:11:47 <BlueMatt> which I think would be ok
19:12:01 <BlueMatt> no reason for most nodes to have it built-in, but ideally there would also be release builds with it
19:12:09 <BlueMatt> if its only available via self-compile I think that'd suck
19:12:13 <fi3> BlueMatt: why not optional?
19:12:31 <BlueMatt> i think requiring self-compile does limit peoples' willingness to run things a lot
19:12:33 <BlueMatt> sadly
19:12:40 <fi3> ok
19:12:44 <sipa> one step at a time
19:12:53 <BlueMatt> but, again, having it be optional with a parallel release track would be fine, and that would hopefully address most concerns?
19:12:53 <laanwj> 'making it optional' and 'making it part of the release binaries' are distinct things
19:13:08 <BlueMatt> but, sure, also doesn't have to happen for the first release with it
19:13:16 <BlueMatt> true
19:13:20 <laanwj> making it optional means that it is still possible to compile bitcoind, albeit lacking some features, on a system without rust installed
19:13:31 <sipa> ^
19:13:32 <laanwj> which is imo important
19:13:36 <achow101> it could be optional in the same way the wallet is optional
19:13:39 <BlueMatt> yea, ok, fair, definitely should be optional in that sense
19:14:01 <fi3> agree
19:14:05 <laanwj> tor did a similar thing
19:14:26 <dongcarl> laanwj: autoconf default=auto is what you mean by "optional"?
19:15:03 <laanwj> dongcarl: having an autoconf option at all is optional
19:16:02 <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
19:16:59 <BlueMatt> ok, seems like there's relative agreement that its ok to move forward here, given its optional?
19:17:17 <dongcarl> right yeah I think that we can all agree on, how about whether to ship it for release binaries?
19:17:26 <sipa> i did comment on the PR with a few questions
19:17:30 <BlueMatt> i dont think we need to decide that for first release
19:17:31 <laanwj> yes, i think it was the same last time, everyone apart from luke-jr probably :)
19:17:33 <dongcarl> we can also punt the release binaries question for later
19:17:34 <luke-jr> how about just having it C++ like PR author said he could?
19:17:50 <BlueMatt> probably answer is no for first release, but definitely want it for release builds sooner rather than later
19:18:03 <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
19:18:25 <laanwj> right, i am not comfortable with making a decision about the release binaries yet
19:18:48 <luke-jr> at the very least, release binaries would be much more changes, so belong in a later PR
19:18:49 <laanwj> it depends on just how big a dependency tree is imported by this, it always worries me a bit with rust things
19:18:55 <BlueMatt> yep
19:19:03 <BlueMatt> laanwj: fwiw, there is no non-tree dependency here
19:19:05 <luke-jr> but there's no benefit to Rust over C++, so it would make far more sense to just do it as C++
19:19:07 <BlueMatt> and the current pr does *not* use cargo
19:19:09 <BlueMatt> only rustc directly
19:19:18 <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?
19:19:20 <BlueMatt> (cargo being the thing that fetches code from the internet, rustc being just the compiler)
19:19:25 <luke-jr> BlueMatt: there's no rust stdlib dep?
19:19:35 <BlueMatt> yes, rustc bundles libstd
19:20:00 <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++
19:20:03 <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
19:20:19 <BlueMatt> michaelfolkson: this is only the "provide block template" part
19:20:30 <laanwj> BlueMatt: that's very good
19:20:36 <BlueMatt> nothing more than that, and we should expect other pools to switch to this for several reasons over getblocktemplate
19:20:46 <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++
19:20:48 <BlueMatt> even if no users ever use it it would still be a pretty big win for several reasons
19:20:57 <michaelfolkson> BlueMatt: Yeah that's fair. Including this could help the chicken and egg problem I'm guessing
19:21:02 <fi3> luke-jr: that is a rust library that is intended to be used also for other project than core
19:21:21 <fi3> sipa: same as above
19:21:28 <sipa> fi3: ok, good
19:21:40 <luke-jr> miners and pools using only anti-bootstrappable binaries would be a security concern for Bitcoin too
19:22:04 <dongcarl> luke-jr: Are you unable to bootstrap rust on your own system?
19:22:09 <luke-jr> dongcarl: correct
19:22:25 <BlueMatt> pools have complained that getblocktemplate is horrendously ineffecient for years, it needs to go, plus there's some other nice wins, see eg the second two bullets at https://github.com/bitcoin/bitcoin/pull/23049#issuecomment-926009122
19:22:25 <dongcarl> luke-jr: Because mrustc doesn't have a powerpc port, is that right?
19:22:36 <luke-jr> dongcarl: I tried on x86_64 too
19:22:51 <luke-jr> dongcarl: I have not tried again int he past week since someone apparetnly got ppc64le to work, though
19:23:02 <BlueMatt> anyway, it seems we can move on from this topic
19:23:19 <laanwj> yes
19:23:20 <BlueMatt> i dunno if there's more to be said, the pr discussion is active.
19:23:38 <dongcarl> 👍
19:23:56 <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
19:23:59 <laanwj> any other topics?
19:24:14 <luke-jr> laanwj: we don't have to solve it here, so long as we don't use Rust until they solve it ;)
19:24:29 <laanwj> luke-jr: so are you bootstrapping your C compiler from TTL logic?
19:24:52 <luke-jr> laanwj: from some pre-Bitcoin C compiler, ultilately
19:25:43 <luke-jr> (yes, my migration to PPC64 was done by cross-compiling everything initially)
19:26:01 <laanwj> #endmeeting