Skip to content

Conversation

@nyonson
Copy link
Collaborator

@nyonson nyonson commented Nov 14, 2025

First two patches just get the code compiling again, some fallout from the BufRead -> Read change in rust-bitcoin. The rest of the patches use the 1.60+ rust features for a cleaner feature flag interface with less footguns for users.

Supersedes #36
Closes #32

@tcharding
Copy link
Owner

Thanks! All good except a1e6753

  • Doesn't really do anything
  • bitcoin 0.32 still has this actual_serde kludge but the MSRV here is 1.63 and there is 1.56 (I went digging for the PR that removed it but couldn't find it. I don't know which MSRV allowed getting rid of it.)

I'd say just drop that patch and we remove the whole kludge once we upgrade to bitcoin 0.33

@nyonson
Copy link
Collaborator Author

nyonson commented Nov 17, 2025

Thanks! All good except a1e6753

  • Doesn't really do anything

My intention was to hide the actual-serde flag from the end user, which I think is what cargo does when we introduce the dep: usage, it turns off the implicit flag for the dependency.

  • bitcoin 0.32 still has this actual_serde kludge but the MSRV here is 1.63 and there is 1.56 (I went digging for the PR that removed it but couldn't find it. I don't know which MSRV allowed getting rid of it.)

I started experimenting with this and it got a little hairy, which is why I thought it would be worth to at least clean up the interface for now.

@tcharding
Copy link
Owner

Ah no worries, TIL.

Copy link
Owner

@tcharding tcharding left a comment

Choose a reason for hiding this comment

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

ACK fa93071

@nyonson
Copy link
Collaborator Author

nyonson commented Nov 18, 2025

I'm dealing with some dependency issues atm, still teasing it apart. I think easiest to just bump the bitcoin dep to 0.32.7, but learning the whys.

The underlying consensus encoding trait was "loosened" from requiring
a BufRead to just a Read.
@nyonson nyonson force-pushed the feature-flags branch 3 times, most recently from ccf55ed to 348c69a Compare November 21, 2025 22:15
@nyonson
Copy link
Collaborator Author

nyonson commented Nov 21, 2025

@tcharding I went kinda ham on this and made the leap to rbmt, but I have higher confidence it will pass CI now. Is there a reason the workflow doesn't auto-run here?

@tcharding
Copy link
Owner

Is there a reason the workflow doesn't auto-run here?

I assume its the 'don't run CI for first time contributors setting' but I didn't bother checking.

@tcharding
Copy link
Owner

I went kinda ham on this and made the leap to rbmt,

Mad, happy to use this repo as a testbed.

@tcharding
Copy link
Owner

I invited you as a collaborator to the repo, can make you a maintainer if you like?

@nyonson
Copy link
Collaborator Author

nyonson commented Nov 21, 2025

@tcharding I think collaborator is fine. Do you want to ACK these PRs before merge or should I just go wild?

Separately, should we bump the MSRV here to 1.74 as well?

@tcharding
Copy link
Owner

tcharding commented Nov 23, 2025

@tcharding I think collaborator is fine. Do you want to ACK these PRs before merge or should I just go wild?

We want to have at least one review before merge. Lets use the ack with commit hash same as in rust-bitcoin and then merge with Core's merge script. Do you know about that?

@nyonson
Copy link
Collaborator Author

nyonson commented Nov 23, 2025

We want to have at least one review before merge. Lets use the ack with commit hash same as in rust-bitcoin

Sounds good!

merge with Core's merge script. Do you know about that?

Nope, what's that?

(just noticed The min versions are still broken, i'll iron that out)

@tcharding
Copy link
Owner

tcharding commented Nov 23, 2025

It comes from Core's maintainer tools repo. I have a local copy, I don't track its developement.

https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/github-merge.py

Its what I use to merge into any repos I control. Andrew used to use it but now he has a custom tool for merging into rust-bitcoin.

@nyonson nyonson changed the title Clean up dependencies and feature flags Clean up dependencies, feature flags, kick the tires on the code to bring it up to date Nov 24, 2025
Comment on lines +450 to +453
let signature = {
let mut rng = thread_rng();
secp.sign_schnorr_with_rng(&msg, &key_pair, &mut rng)
};
Copy link
Owner

@tcharding tcharding Nov 24, 2025

Choose a reason for hiding this comment

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

Why this change please?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ah, i think I was getting tripped up on not having rand-std enabled or something. Let me see where I got confused.

@tcharding
Copy link
Owner

In 984eacd there are changes BufRead / Read but the patch is about secp.

# master branch uses hex-conservative 0.3.0+ which has the fix.
#
# This override can be removed when upgrading to bitcoin 0.33.0 or later.
hex-conservative = { version = "0.2.1", default-features = false }
Copy link
Owner

Choose a reason for hiding this comment

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

Can we keep the optional deps separated by a line of whitespace below the non-optional ones please?

Cargo.toml Outdated
Comment on lines 36 to 31
actual-serde = { package = "serde", version = "1.0.103", default-features = false, features = [ "derive", "alloc" ], optional = true }
actual-serde = { package = "serde", version = "1.0.103", default-features = false, features = ["derive", "alloc"], optional = true }
Copy link
Owner

Choose a reason for hiding this comment

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

Excuse me in advance, I'm in a state today.

If you put random whitespace changes like this in a patch it makes the reviewer have to spend some clock cycles trying to workout why the diff contains these lines, and what exactly changed. As a general principle just throw whitespace changes in a separate patch up front. Thanks

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yea, my bad man, I ran with this one too long tryin to get it a happy spot. I'll try to clean up the commits.


cargo install --quiet --git https://github.com/rust-bitcoin/rust-bitcoin-maintainer-tools \
--rev "$RBMT_VERSION" \
rust-bitcoin-maintainer-tools
Copy link
Owner

Choose a reason for hiding this comment

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

This script could live in rust-bitcoin-maintainer-tools repo also, right? Is it here for a reason? And we could install rmbt duing the prepare job, would that be better? Open questions, I'm in no way implying how you should proceed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yea, I am not sure the best way to integrate the tooling yet. I originally thought it would be nice to have the hash set in Cargo.toml in a dev-dependency, but after some trial and error, realized it is kinda difficult to run a binary from there (please let me know if I am mistaken there).

If the script lived over in rust-bitcoin-maintainer-tools we would need to like, curl it over here at somepoint or something right?

Copy link
Owner

Choose a reason for hiding this comment

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

Oh I meant the install-rbmt.sh script could live there. Its going to be the same everywhere, right?

# Tests each feature alone, all pairs, and all together.
# Note: rand is a little weird until we can upgrade secp256k1 to v0.30.0
# Note: miniscript is not included here as it has its own no-std handling
features_without_std = ["serde", "base64"]
Copy link
Owner

Choose a reason for hiding this comment

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

Whip time again, sorry bro. In patch 99c1db8 you add empty arrays for exact_features and features_with_no_std then later in the PR they are removed. In general please don't make changes to a series of patches like this because it makes reviewers who review with there terminal (read: proper geeks) jump over to github to add a review suggestion only to find the change no longer exists. Each patch should be discreet both in what it does and in how it is reviewed. Just slap me for the sermons, I warned you I was in a state.

Copy link
Owner

@tcharding tcharding left a comment

Choose a reason for hiding this comment

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

ACK b5fd7f2

@tcharding
Copy link
Owner

I whinged alot there, I guess I'm not exactly sure what level of review you want. I'm also totally happy for you to just patch this repo however you like. We don't have to be super anal if you want to just go wild.

@nyonson
Copy link
Collaborator Author

nyonson commented Nov 24, 2025

I whinged alot there, I guess I'm not exactly sure what level of review you want. I'm also totally happy for you to just patch this repo however you like. We don't have to be super anal if you want to just go wild.

Eh, I got sloppy here. Let me clean it up. Now that I know its possible to get the builds to pass I can take my time gettin the code and history right.

@nyonson nyonson force-pushed the feature-flags branch 4 times, most recently from e0a9510 to 4ffcab3 Compare November 25, 2025 00:00
@tcharding
Copy link
Owner

Thanks man

@nyonson nyonson marked this pull request as draft November 25, 2025 01:17
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.

Docs on import version are wrong

2 participants