Repository navigation
build(hashes)!: move to bitcoin_hashes 1.x - #1320
Conversation
|
Important Review skippedToo many files! This PR contains 157 files, which is 57 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry.
|
|
Waiting for bot review — coderabbitai not yet. Wait for the missing reviews, or a writer can post |
|
/self-reviewed |
|
This PR has merge conflicts with the base branch. Please rebase or merge the base branch into your branch to resolve them. |
Depend on `bitcoin_hashes` from the same `rust-bitcoin` git revision as `bitcoin-crypto`, `bitcoin-units` and `base-sdk`, so the hash types unify across them. The 1.x `Hash` trait only converts to and from byte arrays. `hash_newtype!` implements it like upstream's macro and adds the conversions as `const` inherent functions. Newtypes keep `from_slice` and `all_zeros` as inherent functions, since Dash uses zero hashes as protocol values, but no longer get `hash`, `engine` or `from_engine`. The X11 hash gets the inherent surface of the upstream hash types plus `from_slice` and `all_zeros`, and its engine implements `finalize`. 1.x dropped `FromSliceError`, so this crate defines its own with the same shape and message, still also exported as `Error`. `sha256t_hash_newtype!` is removed. Nothing used it and upstream deprecated its counterpart in favour of implementing `sha256t::Tag` by hand. `sha256t` is now upstream's module.
`PubkeyHash` no longer has `hash`, so hash the key through `hash160::Hash` and wrap the result.
Newtypes hash through their inner hash type and its engine: `T::from_raw_hash(sha256d::Hash::hash(..))`, or an engine from `sha256d::Hash::engine()` finished with `finalize`. Upstream hash types lost `all_zeros`, `from_slice` and indexing, so those call sites go through the byte array instead. `BlockHash` wraps X11 or SHA256d depending on `core-block-hash-use-x11`, so a crate private `BlockHashEngine` alias picks the matching engine for `Header::block_hash`. `merkle_tree::calculate_root` and `calculate_root_inline` now require `T: From<sha256d::Hash>` and always combine nodes with double SHA256. 1.x has no engine on the `Hash` trait, and every Dash merkle tree is SHA256d. `from_hex` on the hash newtypes parses through the inner hash's `FromStr`, which now reports the same `hex-conservative` 1.x error.
`HmacEngine` is now parameterized by the engine type and finished with `finalize`. Upstream hash types no longer index into bytes, so fingerprints and chain codes read through `as_byte_array`. Tests hash newtypes through their inner hash and build upstream zero hashes with `from_byte_array`.
Hash newtypes are built from their inner hash instead of the removed `hash`, and upstream zero hashes use `from_byte_array`. Imports of the `Hash` trait that only served the newtype functions are dropped.
Drop the `Hash` trait imports the 1.x inherent functions no longer need and hash `Txid` through `sha256d::Hash`.
Finish engines with `finalize` and compare the hashes directly, since upstream hash types no longer index into bytes.
029b5e6 to
9401c9f
Compare
|
Waiting for bot review — coderabbitai not yet. Wait for the missing reviews, or a writer can post |
|
/skip-bots |
|
Bots are done — your move: post |
|
/self-reviewed |
|
Policy satisfied — this can merge. |
dashpay/rust-dashcore#1320 moves `dashcore_hashes` onto `bitcoin_hashes` 1.x from the rust-bitcoin rev that `bitcoin-crypto` uses. The crates.io `bitcoin_hashes` 0.14 no longer gets its `io` feature, so the crates.io `bitcoin-io` and `bitcoin-consensus-encoding` 1.3.0 that took `bitcoin-internals` 0.7.0 from crates.io leave the graph. Since dashpay/rust-dashcore#1224 the same already held for `base58ck`, `bitcoin_hashes` and `bitcoin-units`. No crates.io dependency asks for a version the git rev provides, so the whole patch section goes. `Cargo.lock` is unchanged and `cargo vendor --locked` succeeds. Closes #5648.
dashpay/rust-dashcore#1320 moves `dashcore_hashes` onto `bitcoin_hashes` 1.x from the rust-bitcoin rev that `bitcoin-crypto` uses. The crates.io `bitcoin_hashes` 0.14 no longer gets its `io` feature, so the crates.io `bitcoin-io` and `bitcoin-consensus-encoding` 1.3.0 that took `bitcoin-internals` 0.7.0 from crates.io leave the graph. Since dashpay/rust-dashcore#1224 the same already held for `base58ck`, `bitcoin_hashes` and `bitcoin-units`. No crates.io dependency asks for a version the git rev provides, so the whole patch section goes. `Cargo.lock` is unchanged and `cargo vendor --locked` succeeds. Closes #5648.
dashpay/rust-dashcore#1320 moves `dashcore_hashes` onto `bitcoin_hashes` 1.x from the rust-bitcoin rev that `bitcoin-crypto` uses. The crates.io `bitcoin_hashes` 0.14 no longer gets its `io` feature, so the crates.io `bitcoin-io` and `bitcoin-consensus-encoding` 1.3.0 that took `bitcoin-internals` 0.7.0 from crates.io leave the graph. Since dashpay/rust-dashcore#1224 the same already held for `base58ck`, `bitcoin_hashes` and `bitcoin-units`. No crates.io dependency asks for a version the git rev provides, so the whole patch section goes. `Cargo.lock` is unchanged and `cargo vendor --locked` succeeds. Closes #5648.
Moves
dashcore_hashesand every crate that uses it frombitcoin_hashes0.14 to 1.x. This replaces the Dependabot bump in #1314, which fails CI because 1.x is an API redesign, not a drop-in upgrade.bitcoin_hashesnow comes from the samerust-bitcoingit revision asbitcoin-crypto,bitcoin-unitsand thebase-sdkcrates, not from crates.io. The workspace already pulled 1.2.0 from that revision through those crates, so our hash types now unify with theirs. Platform already patches crates.iobitcoin_hashesto the same revision. The 0.14 and 0.16 copies stay in the tree becausebip39andbip324have no 1.x release yet.In 1.x the
Hashtrait only converts to and from byte arrays. Our hash newtypes keepfrom_sliceandall_zerosas inherent methods, andhashes::Error/FromSliceErrorkeep their 0.14 shape and message, so most existing callers compile unchanged. Hashing a newtype now goes through its inner hash:Txid::from_raw_hash(sha256d::Hash::hash(..)), or an engine fromsha256d::Hash::engine()finished withfinalize().No hash output changes. The X11, tagged SHA256, SipHash, sighash, txid, merkle and block hash vectors all pass unchanged.
Breaking changes
hash,engineorfrom_engine. They gain const inherentfrom_byte_array,to_byte_arrayandas_byte_array, so manyuse dashcore::hashes::Hashimports become unused.HashEngineusesfinalize(), andmidstate()/MidStateare gone.HmacEngine<T>is parameterized by the engine type, andHmac::from_engineis replaced byfinalize().sha256tis upstream's module.sha256t_hash_newtype!, thesha256t_hash_newtype_tagmacros andsiphash24::Stateare removed. Nothing in this repo or Platform uses them.sha256d::Hashloseall_zeros,from_sliceand indexing, and print a differentDebug. Our newtypes keep their exact 0.14 formatting.merkle_tree::calculate_rootandcalculate_root_inlinerequireT: From<sha256d::Hash>and always combine with SHA256d. Every caller already passes SHA256d hashes.Platform impact
Counted in Platform's
packages/:engine()/from_engine()onQuorumSigningRequestId(rs-drive-abci) andSpecialTransactionPayloadHash(rs-platform-wallet). Each becomes a hash throughsha256d::Hashwrapped withfrom_raw_hash.dashcore::hashes::Hash::all_zeros()through the trait. They becomeTxid::all_zeros().Hashimports fail under-D warnings.cargo clippy --fixremoves them.Testing
cargo fmt --check,cargo clippy --workspace --all-features --all-targets -D warnings, default and--no-default-featureschecks,just doc, the 1.89 MSRV check,cargo denyand the pre-push hooks pass.test_runtime_add_with_tip_advance_during_rescan, was a dashd RPC timeout in the test harness under heavy machine load. It passed on rerun.PR Hygiene ·
9401c9fWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.