Consider bumping MSRV

[tnull]

Unfortunately rustls recently decided to bump their MSRV to 1.71 (see rustls/rustls#2239). While they now at least intermittently reverted the MSRV and pushed out version 0.23.19 that fixes RUSTSEC-2024-0399 without at bumping MSRV at the same time, they are commited to re-bump their MSRV to 1.71 with the follow-up (i.e., 0.23.20) release.

Given how security-critical TLS libraries are, I don't think an MSRV of 1.63 for the dependent crates can be maintained through pinning, as users might miss out on critical security patches. That puts any dependent crates in a tough spot, and essentially forces them to bump their MSRV to at least 1.71, too.

In LDK we're probably going to introduce a separate MSRV just for the lightning-transaction-sync crate (currently depending on rustls), which will have further consequences, such as bumping MSRV on LDK Node and other dependent projects down the dependency chain. We might also re-evaluate whether native-tls can be made to work on Android/Kotlin bindings.

I'm opening this discussion topic as BDK probably also needs to act on this in one form or another, i.e., either bumping MSRV in general, or introducing a separate MSRV for anything depending on rustls.

It probably would also make sense to figure out a common MSRV target for the affected crates to at least somewhat maintain a standard that users can lean on here. It might just be 1.71, but then again rustls's newly defined MSRV policy would 'allow' (not that they seem to care too much in general) them to bump up to 1.73 currently.

[LagginTimes]

Historically, it appears that BDK's MSRV has been aligned with the version of rustc available in Debian stable (see: #331 and https://tracker.debian.org/pkg/rustc), which as of 12/1/2024 is still 1.63. It looks like this alignment is still maintained. Afaik, it should not be overly complicated to bump the MSRV to 1.71 or 1.73 in order to benefit from future security patches.

[tnull]

Historically, it appears that BDK's MSRV has been aligned with the version of rustc available in Debian stable (see: #331 and https://tracker.debian.org/pkg/rustc), which as of 12/1/2024 is still 1.63. It looks like this alignment is still maintained.

Yes, and Debian stable would continue to be a great MSRV target, IMO. That is, if upstream crates wouldn't effectively take the decision out of our hands.

[evanlinjin]

+1 on this. This will decrease the maintenance burden on MSRV.

[tnull]

This just became relevant again as rustls 0.23.20 was released, bumping MSRV to 1.71.0.

I'd appreciate if we could work out a new common MSRV target for projects depending on it.

(cc @notmandatory)

[tnull]

After having a closer look, I'm considering to bump LDK Node's and lightning-transaction-syncs MSRV to 1.75.

I arrived at that as:

a) it's > 1 year old
b) it provides a buffer to 1.71, i.e., if some crate bumped to a version > 1.71, there is a chance we don't immediately have to react again
c) it stabilized async fns in traits (see
https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html), which might become handy for the new rust-electrum-client work? (cc @evanlinjin ?)

Would bumping the affected crates' MSRV to 1.75 work for you guys too?