Done as is single patch to make sure all the docs and CI are in sync and
correct.
We currently pin the `schemars` dependency using `<=0.8.3` as well as a
the `dyn-clone` transient dependency in the manifest (`hashes` and the
extended test crate). This is incorrect because it makes usage of the
crate klunky (or possibly impossible) if downstream users wish to use a
later version of `schemars`.
Observe also that we do not have to pin `schemars`, we do however have to pin
the `serde` crate if either `serde` or `schemars` features are enabled.
Do so in CI and document in the readme file within hashes.
Currently we have a pin remaining from the old MSRV (`syn` due to use
of `matches!`).
Fix pinning by:
- Remove pin in manifest for `schemars`
- Fix pinning for MSRV in CI and docs (this includes documenting pinning
requirements for `schemars` feature because it is related to the other
pin of `serde`) in both `hashes` readme and main repo readme.
8f6317fbab Add predict_weight test for witness address types (yancy)
Pull request description:
Add a predict_weight test for address types with witness data
ACKs for top commit:
Kixunil:
ACK 8f6317fbab
apoelstra:
ACK 8f6317fbab
Tree-SHA512: 954908f068d6b0e8f7cc6bc6bffd110d490d7165cf2544ff0f936264761cb1f8e4da1e37fd5a6a34fd8b05f8d72817a3b340bbf968b29c9f538f10853347fdf0
3d524e06e4 Add Inventory::network_hash() method (Steven Roose)
Pull request description:
I'm not positive we won't ever had inv items that are not `sha256d::Hash`, though. I would expect them to stay like that, but we never know.
Would accept that as a reasonable objection against this helper.
ACKs for top commit:
apoelstra:
ACK 3d524e06e4
tcharding:
ACK 3d524e06e4
Tree-SHA512: 97d64b08ff99dbec2d907bdb98aa41ede4a15b988551ad8dd87a10ac5c9750ae4d516bb558c1e4f2171612777355c2baf1ffbe671cb92320a1af64d73bd150dd
b3b57518a0 ci: Check for remaining NEXT_RELEASE in the release script (Steven Roose)
Pull request description:
The intention here is that we can use the deprecation tag
`#[deprecated(since = "NEXT_RELEASE")]` and fill in the version number
at release time.
Not sure if there is a good place to mention this somewhere in developer docs. I looked into CONTRIBUTING.md but didn't really found a suitable section for this.
ACKs for top commit:
tcharding:
utACK b3b57518a0
apoelstra:
ACK b3b57518a0
Tree-SHA512: 7c077ee6569d38cf4c518cd5003ba0c09fdf7f98f4fb14fd28b49eb2e1b43eec7833de7abd1e35b9b14451f37de8e36a740a6445e3a5feb34a79cbfb7e63ee9f
e223cbe6df CI: Only run release job for release PRs (Tobin C. Harding)
Pull request description:
Currently we run the release jobs for all PRs, this leads to red CI runs any time we have unreleased changes in one crate used by another i.e., basically days after a release comes out.
Add a `release.sh` script that has more smarts to try and figure out if the patch series currently ontop of tip of mater contains changes that imply its a release PR. To do so we check for changes to the version field in the manifest of each crate.
ACKs for top commit:
stevenroose:
ACK e223cbe6df
apoelstra:
ACK e223cbe6df
Tree-SHA512: cc5503f68f9d275989acf8d2e8ff3b2b4ceb73606b8b823e408e4cf0bccbbb6dce0c583917d4dcb4b1b7f1b0bc34293251247d088943a5a6d5e06bf5af2ee8c3
088fa24be8 hashes: Derive traits on the sha512::Hash type (Tobin C. Harding)
Pull request description:
For all the other hash types we use derive, by way of the `hash_type!` macro, unless I'm missing something we can do the same for `sha512::Hash`.
ACKs for top commit:
apoelstra:
ACK 088fa24be8
Kixunil:
ACK 088fa24be8
Tree-SHA512: 3849261a8208c8c6108f4ecc5643940d38289f791d1b360ef4b13d60f72b365cd29f07f625a2d320f188defde848ddd64c8532cae5979e54afbf62f741927185
fabcde036f Use package in manifest and shorten import (Tobin C. Harding)
Pull request description:
We can use `package` to rename `bitcoin_hashes` to `hashes` and `bitcoin_internals` to `internals`. This makes imports more terse with no loss of meaning.
ACKs for top commit:
apoelstra:
ACK fabcde036f
Kixunil:
ACK fabcde036f
Tree-SHA512: bc5bff6f7f6bf3b68ba1e0644a83da014081d8c6c9d578c21cb54fdd56a018f68733dd1135d05b590ba193ed9efd12fa9019182c1fed347e604d8548f6ef9103
29cb34eed7 Refactor Address struct and its methods (Harshil Jani)
Pull request description:
Closes#1755
In this PR the `as_unchecked` is added to the Address struct, which returns a reference to the same address but with the type Address<NetworkUnchecked>. Similarly, the `assume_checked_ref` is added to Address<NetworkUnchecked>, which returns a reference to the same address but with the type Address.
ACKs for top commit:
tcharding:
ACK 29cb34eed7
apoelstra:
ACK 29cb34eed7
Tree-SHA512: 75ba40883d9fb31026b0e94e8d3fdcf808ff38a4d10f61f99a1e14ddc48358da86bad44cd78563dc67aa5d39382a5493e73c03891317f361f590e39b6257cb84
Currently we run the release jobs for all PRs, this leads to red CI runs
any time we have unreleased changes in one crate used by another i.e.,
basically days after a release comes out.
Add a `release.sh` script that has more smarts to try and figure out if
the patch series currently ontop of tip of mater contains changes that
imply its a release PR. To do so we check for changes to the version
field in the manifest of each crate.
91f45a214f Replace hardcoded values with compile-time hashing (Martin Habovstiak)
095b7958dd Make `sha256t_hash_newtype!` evocative of the output. (Martin Habovstiak)
Pull request description:
The Rust API guidelines state that macros should be evocative of the
output, which is a sensible recommendation. We already had this for
`hash_newtype!` macro but didn't for sha256t version.
This changes the macro to have this syntax:
```rust
sha256t_hash_newtype! {
// Order of these structs is fixed.
/// Optional documentation details here. Summary is auto-generated.
/*pub*/ struct Tag = raw(MIDSTATE_BYTES, LEN);
/// Documentation here
#[hash_newtype(forward)] // optional, default is backward
/*pub*/ struct HashType(/* attributes allowed here */ _);
}
```
Closes https://github.com/rust-bitcoin/rust-bitcoin/issues/1427
Depends on #1769
How do you like the syntax? Is weird `struct Foo = bar(..);` acceptable?
ACKs for top commit:
tcharding:
ACK 91f45a214f
apoelstra:
ACK 91f45a214f
Tree-SHA512: f6b555b20311a4c1cb097bc296c92459f6fbe16ba102d8c977eb2383dbcae3cc8ffce32e3cb771e7e22197fda26379971aa4feaadc5e2e70d37fa690ae8b8859
873501a85f Use slice patterns (Martin Habovstiak)
Pull request description:
Some code looks better with slice patterns. This changes `bip32` to use them.
ACKs for top commit:
apoelstra:
ACK 873501a85f
tcharding:
ACK 873501a85f
Tree-SHA512: 2e91b21d0f943c04f592112f241444ba3b1b1dad47ea6bea162f62cfbcaf98e383257cad144072b3807aaa0c122dabab638ac10b1cc1f5179727a5f05aac0659
42d3ae05be Implement computing SHA256 in const context (Martin Habovstiak)
Pull request description:
Computing hashes in const fn is useful for esily creating tags for `sha256t`. This adds `const fn` implementation for `sha256::Hash` and the algorithm for computing midstate of tagged hash in `const` context.
Part of #1427
I'd like to make sha256t evocative of the output after this which would also do the thing we want to do with #1427 (awkward language to bypass GH automatically closing it...) I'm thinking of this:
```rust
sha256t_newtype_hash! {
// optional attrs
/*pub*/ struct TagName = "tag_str"; // weird syntax but I guess OK-ish?
// optional attrs
/*pub*/ struct HashName(_); // allowed to elide the type because it's implied; maybe also allow writing it?
}
```
What do you think? I was also thinking about this alternative:
```rust
sha256t_newtype_hash! {
// optional attrs
/*pub*/ struct TagName;
const TAG: Tag = from_str("tag_str"); // allows for having from_raw([...]) or even from_hex([...])
// optional attrs
/*pub*/ struct HashName(_); // allowed to elide the type because it's implied; maybe also allow writing it?
}
```
Which looks more natural but maybe too much boilerplate? Which one do you like? Any better ideas? Heads up sanket1729
Also FYI tcharding this is the kind of post-1.48 change I was thinking about. :)
ACKs for top commit:
apoelstra:
ACK 42d3ae05be
tcharding:
ACK 42d3ae05be
Tree-SHA512: 437f3160e53104fcdf94c6e09ca6722ea2fe1032429b4701e578dded665cb9cab45cc68ee718b8925075c05dff231c0b898dc03949ef57b831666c68e38950a6
8b4280d5ef Update clippy MSRV configuration (Martin Habovstiak)
Pull request description:
We've upgraded MSRV but didn't update clippy config, so some things that could be improved aren't caught by clippy. This updates the config and fixes the new issues.
I also `rg '1\.41\.1'`ed for interesting changes and found one additional improvement.
ACKs for top commit:
apoelstra:
ACK 8b4280d5ef
tcharding:
ACK 8b4280d5ef
Tree-SHA512: 337ca099ca1a4b8b5d230c802bc455a5e0bbc3436066e41577c5b67f8d7fedede6f7a446b208da067ffc2cc2cebcbc187404846c295e9d89798f11dc66d34e34
This commit refactors the Address struct and its methods to improve
its functionality and usability.The AddressInner struct now holds
the payload and network, and the PhantomData<V> type is used to track
the network validation state.
Also as_unchecked and assume_checked_red methods are added to allow
conversion between checked and unchecked network validation state.
Signed-off-by: Harshil Jani <harshiljani2002@gmail.com>
Previous changes enabled passing the string used as a tag into
`sha256t_hash_newtype!` macro rather than hard-coding midstate. This
commit takes advantage of it and replaces the hard-coded values with
compile-time executed (`const`) hashing.
The Rust API guidelines state that macros should be evocative of the
output, which is a sensible recommendation. We already had this for
`hash_newtype!` macro but didn't for sha256t version.
This changes the macro to have this syntax:
```rust
sha256t_hash_newtype! {
// Order of these structs is fixed.
/// Optional documentation details here. Summary is auto-generated.
/*pub*/ struct Tag = raw(MIDSTATE_BYTES, LEN);
/// Documentation here
#[hash_newtype(forward)] // optional, default is backward
/*pub*/ struct HashType(/* attributes allowed here */ _);
}
```
Closes#1427
We've upgraded MSRV but didn't update clippy config, so some things that
could be improved aren't caught by clippy. This updates the config and
fixes the new issues.
I also `rg '1\.41\.1'`ed for interesting changes and found one
additional improvement.
Computing hashes in const fn is useful for esily creating tags for
`sha256t`. This adds `const fn` implementation for `sha256::Hash` and
the algorithm for computing midstate of tagged hash in `const` context.
Part of #1427
1187e10299 Add per crate release notes link (Tobin C. Harding)
Pull request description:
In #1759 we fixed the link to the bitcoin changelog, we can go one step further and add links for each of the crates.
ACKs for top commit:
apoelstra:
ACK 1187e10299
Kixunil:
ACK 1187e10299
sanket1729:
ACK 1187e10299
Tree-SHA512: 10c79c2e633c130855b321d7644b639d7f5fde9dbe94ee54005c34f7ac0821bab714d8a09a6480bfc5363cadc05eeb6dc052409b62e744aae130b7955d9d250d
a189942c64 Use doc_auto_cfg (Tobin C. Harding)
Pull request description:
If we use `#![cfg_attr(docsrs, feature(doc_auto_cfg))]` instead of `#![cfg_attr(docsrs, feature(doc_cfg))]` we no longer need to manually mark types with `#[cfg_attr(docsrs, doc(cfg(feature = "std")))]`.
Sweeeeeet.
Props to pezcore for the lesson :)
ACKs for top commit:
apoelstra:
ACK a189942c64
Kixunil:
ACK a189942c64
Tree-SHA512: 1ced1e09f5d1733b362b83ca650d3f52c89eb57e78e8437f74c496d89776548f8c50feab6750352342e2abe680434681de2c126ce36a81dda21397b9695d4d4e
91863c8a78 Feature (hashes): Add from_bytes_ref and from_bytes_mut to all Hash types (junderw)
Pull request description:
Closes#1756
I added tests to one of the Hash types, let me know if this seems reasonable as a test and I'll add it for all the other Hash types.
ACKs for top commit:
apoelstra:
ACK 91863c8a78
tcharding:
ACK 91863c8a78
Tree-SHA512: e1fc278eab4c13b04462636d424b05c599d8f75d76ac8c50cff195085af5ab71aee8a74386d58a457a7ab528226ff4686b3fd0c0019530835709ac1c9577281e
046bda321b comparing NetworkUncheck addresses (Harshil Jani)
Pull request description:
Closes#1754
This PR adds an implementation of the PartialEq trait for the `Address` struct with NetworkUnchecked. The newly implemented function checks if two addresses are equal based on their network and payload. This implementation is useful when comparing an Address with NetworkUnchecked to another Address with NetworkUnchecked
ACKs for top commit:
Kixunil:
ACK 046bda321b
apoelstra:
ACK 046bda321b
Tree-SHA512: 9db28bd9fe6721c754515812bf8b7ca6a2a1285501e3e998298bb430cc129971dc03b9b9ed4a764aa1ebd9d3cb0b06cc5e7fdb9196682410e795c57211672b87
Signed-off-by: Harshil Jani <harshiljani2002@gmail.com>
implementation of PartialEq<Address> for Address<NetworkUnchecked>
Signed-off-by: Harshil Jani <harshiljani2002@gmail.com>
If we use `#![cfg_attr(docsrs, feature(doc_auto_cfg))]` instead of
`#![cfg_attr(docsrs, feature(doc_cfg))]` we no longer need to manually
mark types with `#[cfg_attr(docsrs, doc(cfg(feature = "std")))]`.
Sweeeeeet.
bbda9599fa [Docs] Update internal project link to changelog (David A. Harding)
Pull request description:
The changelog was moved in[1], but the link to it in README.md wasn't updated. I don't see any other outdated links to it in this project via a quick git grep.
---Not your usual Harding
[1] bae64e156e
ACKs for top commit:
tcharding:
ACK bbda9599fa
apoelstra:
ACK bbda9599fa
Tree-SHA512: d2b94f4b1afe161357f6dd1fd85fa641be9aa927d48c1ef6d0c49b982633dbcb1e47caa75ebd7f81ef0706617024d0810bcde6d2b7e9149ea978a3c05a71ab1b
ed80df5ebc Add `ChainHash::from_genesis_block_hash` (Martin Habovstiak)
Pull request description:
This improves readability of converting `BlockHash` into `ChainHash`. It's useful in e.g. Electrum protocol which sends `BlockHash` (serialized backward).
Closes#1751
ACKs for top commit:
apoelstra:
ACK ed80df5ebc
tcharding:
ACK ed80df5ebc
Tree-SHA512: b03eb9ca0a1eb38196cc8e43751c2def0d00b463b774003c5319bf56599db598ddd4bb0e2ad0bd3803f21a925135992d421848e7b1ba5e7bab3a405f60fc973c
We can use `package` to rename `bitcoin_hashes` to `hashes` and
`bitcoin_internals` to `internals`. This makes imports more terse with
no loss of meaning.
82b6332b91 create a set of recognized denomination forms (yancy)
Pull request description:
I took a stab at restricting the acceptable forms here. There was some consensus that "BtC" was confusing that was discussed in a previous pr https://github.com/rust-bitcoin/rust-bitcoin/pull/1715.
Also, personally I felt that the `PossiblyConfusingDenomination` enum variant was itself confusing. I think it's probably cleaner to just maintain a list of acceptable forms and treat everything else as unknown. For now I just created a const of possibly confusing forms.
ACKs for top commit:
Kixunil:
ACK 82b6332b91
apoelstra:
ACK 82b6332b91
Tree-SHA512: f3c212046e4d8a34ce2d50f34065b1778ae190ca80dd9ad73ef41eb5925705c88c0a764ec149d731eb1735d670c5542415953633a7f3f672d0c1e46b6e004d0b
This improves readability of converting `BlockHash` into `ChainHash`.
It's useful in e.g. Electrum protocol which sends `BlockHash`
(serialized backward).
Closes#1751
9ade4f3620 add SECURITY.md (Andrew Poelstra)
Pull request description:
Draft of a SECURITY.md. Right now it only lists me -- if you are willing to be an alternate, don't be afraid to ask. Pretty-much any of the major regular contributors would be fine.
Fixes#1718
ACKs for top commit:
sanket1729:
ACK 9ade4f3620
tcharding:
ACK 9ade4f3620
Tree-SHA512: 8c6ca4e511a23efc132f2ceee7538f38116d815c20bd81b3650cddfa32e695cb812167964f2f0a0c94d6499c037b72a7c8464e5427fd77a8035540ef9e6b6b65
122188f7dd Use shorter import statements (Tobin C. Harding)
Pull request description:
Just patch 2, patch 1 is #1728
From the commit log of patch 2
Use shorter import statements
As per discussion [0] use the shorter form for importing crates that we
re-export (`hashes` and `secp256k1`).
[0] https://github.com/rust-bitcoin/rust-bitcoin/discussions/1661
ACKs for top commit:
apoelstra:
ACK 122188f7dd
sanket1729:
utACK 122188f7dd
Tree-SHA512: 3f540464d38c72ba9d68f8ceda8600540bd0c3eef0ba67531c87fa1e0e4f757af7035cf80a1a5f17aa05604a17fdd9ef59bb6bece6b4145d540dac1e5362fc01
99cb83c3e9 ci: do dry-run releases in CI (Andrew Poelstra)
Pull request description:
Will set this to "allow failure" since I think it'll fail during large parts of development, but this will be useful to avoid last-minute problems with releases.
ACKs for top commit:
tcharding:
ACK 99cb83c3e9
Kixunil:
ACK 99cb83c3e9
Tree-SHA512: 32a3e541deba26c0ef3b70a5cf9b4cf8efcebcb962258dd50ff77bd78b38cd9e749246e37133e9ddb806c558faa9cbbc9d8039061cbe888e8abb247c673325a6
Add the `mutate` attribute to mutate `mul_u64`. Add non-doc comments
listing the two false positives. These are identical but we list them
twice so when devs grep for `mutagen false pos` the same number of lines
for each function is displayed as is displayed by the `mutagen` run.
This coding false positives thing is also introduced in PR #1655.
1dc04fe10f Remove rust_v_1_46 (Tobin C. Harding)
71fa9e81e7 Bump MSRV to 1.48.1 (Tobin C. Harding)
Pull request description:
Just patch 2, patch 1 is #1728
From the commit log of patch 2
Bump MSRV to 1.48.1
As per discussion [0] bump our MSRV for all crates in `rust-bitcoin`
repo to 1.48.1 [1].
[0] https://github.com/rust-bitcoin/rust-bitcoin/discussions/1329
[1] https://blog.rust-lang.org/2020/11/19/Rust-1.48.html
ACKs for top commit:
apoelstra:
ACK 1dc04fe10f
sanket1729:
ACK 1dc04fe10f
Tree-SHA512: 533470c55f7aeede88382db8245033dac9317d75b38ced2ad8256d38319632a524335f893044e96300a1e60048f9aaca2d1634735eb324eb8ed9ad3c9ab2f872
Steven Roose
Tobin C. Harding
Sergi Delgado Segura
Andrew Poelstra
yancy
Harshil Jani
Martin Habovstiak
junderw
David A. Harding