Skip to content

Conversation

@tcharding
Copy link
Member

@tcharding tcharding commented Jul 30, 2024

Hardware devices like the smallest binary possible, currently if one builds with latest rust-bitcoin and rust-bip39 they get two versions of bitcoin_hashes in the dependency graph because we don't support the latest bitcoin_hashes.

Note using the latest version causes the MSRV to increase to Rust v0.56.1.

@tcharding
Copy link
Member Author

cc @afilini

@afilini
Copy link

afilini commented Jul 31, 2024

ACK, that would be helpful for me, all the other libs like rust-bitcoin and bdk have already upgraded to hashes 0.14

Copy link

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be nice for me even just for cleanness sake.

Cargo.toml Outdated
# Enabling the "rand" feature by default to run the benches
bip39 = { path = ".", features = ["rand"] }
bitcoin_hashes = ">=0.12,<0.14" # enable default features for test
bitcoin_hashes = ">=0.12,<=0.14" # enable default features for test
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This must be >= 0.12, <0.15, otherwise 0.14.1 will be unusable even though it'd be compatible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wow, TIL. Will fix, thanks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to go right ahead and 'trust don't verify'.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The verification is easy, just evaluate 0 < 1 expression in your head. :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I thought we were talking about 0.14 working for 0.14.0 but not for 0.14.1.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0.14 implies 0.14.0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I have no idea what you were talking about in your original comment then. <= 14 is equivalent to < 15

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not. 0.14 == 0.14.0
0.14.1 > 0.14.0
0.14.1 < 0.15.0
And the above implies 0.14.1 > 0.14 which is a negation of 0.14.1 <= 0.14
So for <= 14 to be equivalent to < 15 we require all x to satisfy x <= 0.14 <-> x <0.15 and we have a counter example for x = 0.14.1. QED

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get it now. Seems the confusion started when I wrote "I'm going to go right ahead and 'trust don't verify'." and I have no clue what I was thinking then. Your original review comment is actually perfectly clean.

Just call me retarded :)

Cargo.toml Outdated

# Unexported dependnecies
bitcoin_hashes = { version = ">=0.12, <=0.13", default-features = false }
bitcoin_hashes = { version = ">=0.12, <=0.14", default-features = false }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also needs to be <0.15, it was already broken.

@tcharding tcharding force-pushed the 07-30-update-hashes branch from 46ef0ed to 2b47d40 Compare August 26, 2024 23:34
Copy link

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 2b47d40

@tcharding
Copy link
Member Author

Oh this PR is no good anyway, bitcoin_hashes v14 has an incompatible MSRV.

@tcharding tcharding mentioned this pull request Sep 18, 2024
@tcharding
Copy link
Member Author

Raised #79 to discuss the MSRV bump. Converting to draft until that resolves.

@kayabaNerve
Copy link
Contributor

kayabaNerve commented Feb 4, 2025

Is this a MSRV bump? Anyone who wants an older MSRV can use an older version of bitcoin_hashes. This may cause some automated workflows to fail on first pass? But I wouldn't consider that breaking, as at worst it would be trivially correctable by an extra line in a Cargo.toml of bitcoin_hashes = "=0.12".

As someone who currently has two copies of bitcoin_hashes in-tree, I'd appreciate this.

@Kixunil
Copy link

Kixunil commented Feb 4, 2025

@kayabaNerve that line wouldn't be great, better jut use Cargo.lock correctly.

@kayabaNerve
Copy link
Contributor

Precise updates get overriden upon the next call to update. A line in the toml, next to the line adding this very crate as a dependency, would pin it. That's why I said what I said. It's irrelevant to the larger point I don't believe this is a MSRV break and should be able to move forward regardless though.

@Kixunil
Copy link

Kixunil commented Feb 4, 2025

Precise updates get overriden upon the next call to update.

MSRV doesn't get bumped on update if you use recent cargo. But yes, this is not MSRV break in the sense that it'd justify major version.

@benma
Copy link
Contributor

benma commented Aug 20, 2025

Could you take this PR out of draft and merge and release please? 😄 Seems like a simple change and I need it for the reason @tcharding outlined.

@dmitrmax
Copy link

Could you take this PR out of draft and merge and release please? 😄 Seems like a simple change and I need it for the reason @tcharding outlined.

I second this. The simplest fix is resting on the shelf for more than a year now.

Maintainer, please do the v2.2.1 release.

@benma
Copy link
Contributor

benma commented Sep 3, 2025

Ping @tcharding @stevenroose, please let's merge, it's a simple change and very much needed. Thanks

@tcharding
Copy link
Member Author

I'm not a maintainer here sorry mate. If you have a direct link to Steven you could hassle him.

@benma
Copy link
Contributor

benma commented Sep 21, 2025

@tcharding I guess the first step would be for you to rebase it (there are conflicts) and take it out of draft.

@tcharding tcharding force-pushed the 07-30-update-hashes branch 2 times, most recently from 1ca2e1b to 26683c2 Compare September 21, 2025 23:01
@tcharding
Copy link
Member Author

No sweat, done.

@tcharding tcharding marked this pull request as ready for review September 21, 2025 23:02
@tcharding tcharding marked this pull request as draft September 21, 2025 23:03
@tcharding
Copy link
Member Author

Oh this cannot be undrafted because of the MSRV bump. At the risk of being rude, and @stevenroose you can slap me in person when you see me next, I'd suggest one of the following:

  • Someone pester Steven to maintain his lib (I'm not going to do this, I've hassled him enough about other libs more important to me).
  • Suggest to him to bring on another maintainer, or offer to be one.
  • Fork the crate and sort it out.

I'm not the don of the rust-bitcoin org but I do feel in someway responsible that we have crates in the org that are not maintained. I don't know the solution to that problem.

No one is required to do anything round here, so props to Steven for writing the crate, and all due respect.

@tcharding tcharding force-pushed the 07-30-update-hashes branch 2 times, most recently from 5994a4c to 1357566 Compare October 26, 2025 22:33
@tcharding tcharding marked this pull request as ready for review October 26, 2025 22:33
@tcharding tcharding changed the title Enable bitcoin_hashes v0.14.0 Enable bitcoin_hashes v0.14.0 Oct 26, 2025
@tcharding
Copy link
Member Author

We have @tnull as a crate owner on crates.io now. And if my private conversation with @stevenroose is correct then @elsirion has been invited to be a crate owner also. I assume both of you were also given merge perms here so this PR should be able to make some progress now please.

@tcharding tcharding mentioned this pull request Oct 26, 2025
@elsirion
Copy link
Collaborator

elsirion commented Oct 27, 2025

I don't have merge perms or an crates.io invite yet as far as I can tell. Happy to take on the responsibility, but also respect if @stevenroose doesn't want too many people as maintainers.

- `bitcoin_hashes v0.13`: MSRV v1.48.0
- `bitcoin_hashes v0.14`: MSRV v1.56.1

When using older version of Rust, you might have to pin the versions of several crates, for an up-to-date list refer to [`contrib/test.sh`](contrib/test.sh):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this no longer true, i.e., why don't we have to pin back the other dependencies below?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly a faulty rebase conflict resolution? I made changes to these lines in #86 and this PR was open forever. @tcharding

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I just clobbered them because over the last year (since edition 2018 came into rust-bitcoin) I've barely ever had to pin anymore. Admittedly not the best reason for the change, I've put it back how it was.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it depends which MSRV you are targeting, a lot of the bip39 deps seem to have bumped their MSRV in minor version releases. I only had to pin for the old rust version tests back then.

Copy link
Collaborator

@stevenroose stevenroose left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

Copy link
Collaborator

@elsirion elsirion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like to clarify if the README.md changes were intentional before merging, I have a strong suspicion that they weren't and the described pinning isn't sufficient.

Hardware devices like the smallest binary possible, currently if one
builds with `rust-bitcoin v0.32` and `rust-bip39` they get two versions
of `bitcoin_hashes` in the dependency graph because we don't support
`bitcoin_hashes v0.14`.

Note that using `bitcoin_hashes 0.14` bumps the MSRV to Rust v1.56.1
@tcharding tcharding force-pushed the 07-30-update-hashes branch from 1357566 to e30b544 Compare October 27, 2025 20:48
@tcharding tcharding requested a review from elsirion October 27, 2025 20:49
@tcharding
Copy link
Member Author

tcharding commented Oct 27, 2025

I don't have merge perms or an crates.io invite yet as far as I can tell. Happy to take on the responsibility, but also respect if @stevenroose doesn't want too many people as maintainers.

@apoelstra can you add @elsirion and @tnull as a maintainers please. @stevenroose has confirmed this by signal message with me. He has added them both as owners on crates.io already. @tnull said he would message you directly on signal also about this.

For anyone reading @stevenroose does not check GitHub notifications so will likely not read this message any time soon. You'll just have to believe me that I talked with him.

https://crates.io/crates/bip39

@tcharding
Copy link
Member Author

Hey Tobin! Talked to Steven and it seems he can't add me as an owner of the bip39 crate on Github as it's part of the org now. Could you add me and elsirion?

This via signal from @tnull to me.

@elsirion elsirion dismissed their stale review October 27, 2025 22:13

Docs were fixed, still need to test MSRV though, so no full ACK yet.

There are multiple MSRVs in this crate because of the `bitcoin_hashes`
dependency and also the `zeroize` feature.

Add MSRV test jobs for the three MSRVs effected by `bitcoin_hashes`
and also one for the `zeroize` feature.
@tcharding
Copy link
Member Author

Docs were fixed, still need to test MSRV though, so no full ACK yet.

Good eye, thanks. I've added 4 MSRV jobs which is pretty ugly but should get the coverage we want.

@tnull
Copy link
Collaborator

tnull commented Oct 28, 2025

I don't have merge perms or an crates.io invite yet as far as I can tell. Happy to take on the responsibility, but also respect if @stevenroose doesn't want too many people as maintainers.

@apoelstra can you add @elsirion and @tnull as a maintainers please. @stevenroose has confirmed this by signal message with me. He has added them both as owners on crates.io already. @tnull said he would message you directly on signal also about this.

For anyone reading @stevenroose does not check GitHub notifications so will likely not read this message any time soon. You'll just have to believe me that I talked with him.

https://crates.io/crates/bip39

Can confirm I was added now.

Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good, one nit, one comment.


When using older version of Rust, you might have to pin the versions of several crates, for an up-to-date list refer to [`contrib/test.sh`](contrib/test.sh):

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Spurious whitespace here.

fi

# Pin dependencies as required if we are using MSRV toolchain.
if cargo --version | grep "1\.48"; then
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No super strong opinion, but in LDK we use such a pattern (just an example, see https://github.com/lightningdevkit/rust-lightning/blob/0.2/ci/ci-tests.sh):

RUSTC_MINOR_VERSION=$(rustc --version | awk '{ split($2,a,"."); print a[2] }')

# The backtrace v0.3.75 crate relies on rustc 1.82
[ "$RUSTC_MINOR_VERSION" -lt 82 ] && cargo update -p backtrace --precise "0.3.74" --verbose

Seems this could be a bit cleaner/less error prone if we start handling even more different rust versions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just hope that once we hit rust version 1.480 in 45 years we won't be testing 1.48 anymore 😆

@elsirion
Copy link
Collaborator

LGTM, just some syntax errors in the workflow file

Screenshot 2025-10-28 at 05-49-43 Enable `bitcoin_hashes v0 14 0` · rust-bitcoin_rust-bip39@b3f9c4d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants