Target Rust version for crate stabilization

[Kixunil]

Newer Rust versions allow us to make the API better in ways that would require breaking the API if we wanted to improve it later. However we don't want to wait infinitely long since any release may add such possibility. So we should set some MSRV we want to stabilize at.

Interesting versions:

• 1.46 - not sure if it actually helps the API but allows AsRef<T> for all [T; N] we're already at 1.48
• 1.51 - const generics; unfortunately we still can't write [u8; Self::LEN] instead of Self::Inner in Hash.
• 1.54 - allows casting arrays to slices in const fn - could improve const API, not sure how relevant
• 1.59 - default const parameters - probably not significant
• 1.60 - weak dependencies, this is significant but probably less so if we manage to remove no-std feature
• 1.65 - GAT

[apoelstra]

1.64 gets us std::ffi::c_uchar which we need for rust-secp.

[Kixunil]

Only for -sys I suppose?

[apoelstra]

Correct.

[tcharding]

1.56 gets us edition 2021 which is the main cause of all the MSRV breakage we get, preventing that would be super awesome.

[tcharding]

An was release in October 2021: https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html

[junderw]

I agree that edition 2021 would be a good cut off, and the version is almost 2 years old.

However, if we go by Debian stable versions, stable has 1.63, old-stable has 1.48 and the oldest still active LTS has 1.41.1

I think 1.63 is a good cut off, will get us quite a few new features including edition 2021, and overall seems like a good choice.

[sanket1729]

+1. I think 2021 will have less maintenance for MSRV related issues.

[Kixunil]

I don't think this is related. We can still bump MSRV when stable, it's just that some MSRVs affect how nice the API can be.

That being said 1.63 is something I would like a lot due to weak dependencies and being in Debian stable.

[tcharding]

I was patching base64 to use MSRV of Rust 1.48 and writing the reasoning for my PR - turns out Debian stable ships Rust 1.63 now. Are we sticking with the two year rolling window or is the bar "its in Debian stable"?

Rust 1.63 allows use to depend on base64 v0.21.2 (latest version, MSRV 1.57)

[yancyribbens]

cool, thanks!

[junderw]

It's not required to update the Debian OS to run 1.63 hopefully.

Currently, Debian 12 "Bookworm" has 1.63, but Debian 12 was only released recently.

Debian 11 "Bullseye" has 1.48

Debian 10 "Buster has 1.41.1

Debian users tend to only install things through the package manager for security concerns (rustup is basically a bash script you download from a website (that can be compromised) which downloads pre-built binaries for rustc, cargo, etc. from other websites (that can be compromised)... so some people will never use rustup.

Asking people "hey, you need to be on the LATEST stable Debian or else you can't build anything that depends on rust-bitcoin" is a bit much... however, by the time v1.0.0 is released, Bookworm will have been out for quite a bit... so it is reasonable to set MSRV to 1.63.

[yancyribbens]

This is a little off topic, but binaries downloaded from a package manager can be compromised.. To me, the safest is to compile from source since there's a chance to audit the source code that's being installed.

[junderw]

binaries downloaded from a package manager can be compromised

The risk of the debian package manager being compromised is much, MUCH lower than the risk of rustup's domain and the various domains it downloads binaries from being compromised.

Case and point: Metamask, MyEtherWallet, and many other "crypto" wallets have fallen victim to BGP attacks which have lost people tons of money. Their IP addresses were hijacked and HTTPS certs were newly obtained by the hacker.

Debian package manager does not have this problem, the maintainer GPG keys are pre-installed, and the ISO downloads are all signed with trusted keys that are signed in the PGP WoT.

"HTTPS with a domain owned by a trusted entity" is secure enough for a lot of things. I think it is secure enough in most cases. I personally think rustup is great.

But saying "well, nothing is 100% secure, so might as well use something that's 3% secure vs. something that's 99.999% secure" would be the same as if you said "well, /dev/urandom COULD produce garbage entropy, so using the current timestamp to seed a PRNG is fine."

Security conscious people would disagree. Their opinion is a valid one, and as library maintainers there needs to be a balance struck between maintainability and accommodating security conscious users of the library.

[Kixunil]

FTR I have lately started experimenting with using debian-vendored crates (external dependencies) and it works surpisingly well in bookworm.

[tcharding]

As we start to release v1.0 of our crates starting at the bottom (hex-conservative, rust-bech32 etc.) do we need to have this MSRV thing resolved? Or can we drop v1.1.0 with the MSRV bump?

[Kixunil]

We only need MSRV for that crate. So if e.g. bech32 API doesn't need any fancy feature from newer Rust we can use the current MSRV. For the crates that would greatly benefit from newer version we need to decide if we want to bump.

[apoelstra]

Agreed. For the bottom crates I'd maybe even look into reducing the MSRV if it were possible and unlikely to cause us too much trouble.

[Kixunil]

I think weak dependencies are a pretty big deal. Any crate that has anything else than std and alloc as a dependency probably needs them.

[Kixunil]

FTR LDK is bumping their MSRV to 1.63. I think we should target no less than that for stabilization which will still take a long time.

[tcharding]

Can we start doing this as soon as we are ready to drop the first 1.0 crate (hex-conservative or rust-bech32 perhaps)?

[tcharding]

Or we drop the 1.0 and don't depend on it in rust-bitcoin until we do the MSRV bump, but that kinda sucks.

[apoelstra]

I would not like to go to 1.63 (or 1.64 which might be better, though I don't feel strongly about it) until it meets our "2 years old, in debian stable" rule. They will be 2 years old in late 2024.

I'd be fine stablizing edge crates at a lower MSRV if we wanted to get 1.0 out early.

Alternately we could release a 0.99, which we promise will be "1.0 except for MSRV". Which maybe something we want to do anyway, as a sort of long-term RC.

[Kixunil]

"1.0 except for MSRV"

I don't understand this. Stable doesn't mean no MSRV bumps ever. Did you think it did or do you have something else in mind? Oh, I think I get it. The only API change will be the one allowed by newer MSRV and we will know exactly what it will be? I could get behind something like that.

[Kixunil]

I've been thinking about push_decode lately and came to conclusion that GAT would be incredibly useful. It's a huge bummer it's not in Debian Bookworm.

[apoelstra]

Heh, so that's a vote for 1.65?

[Kixunil]

I'm really tempted to wait for the next Debian release and use that one..