ChainHash::using_genesis_block can't be `const` if it uses a `match`
expression prior to Rust 1.46. Use an array mapping to work around this
limitation.
96dfcdf3b7 Implement From for hash types (Noah)
Pull request description:
Reopening #1280 on the right branch + implemented `From` for references of types that were done in #1280.
ACKs for top commit:
Kixunil:
ACK 96dfcdf3b7
apoelstra:
ACK 96dfcdf3b7
Tree-SHA512: ad762032390f060b87cdd24033a5fc13a4c5297c55d7091ed89c5ca240be2f57998c0be084f40f9b04833920756b93a3ca4576a2ef944872354d1b3607734228
7a1aa2098a Remove code deprecated last release (Tobin C. Harding)
Pull request description:
We give one release cycle for deprecating old code so as to make the upgrade path easier for downstream users.
Remove code deprecated during the last release (v0.29.0).
(Check out my diff stats - all red ;)
ACKs for top commit:
apoelstra:
ACK 7a1aa2098a
Kixunil:
ACK 7a1aa2098a
Tree-SHA512: d4b9c65d0d8a0aac31cf94d826e8a6084d4f5427a26da2ad5a3973c7f5931fa10695214dc602261e9079e1c06c6dc3f5b5dcdb8d20b5c39eaadd9a33d23746dd
`ChainHash::using_genesis_block` can't be made `const` because it uses a
`match` expression, which is only valid in Rust 1.46. Add individual
constants as a workaround so that `ChainHash` can be used in `const`
contexts.
We give one release cycle for deprecating old code so as to make the
upgrade path easier for downstream users.
Remove code deprecated during the last release (v0.29.0).
Currently we attempt to have deprecated key types in the `schnorr`
module. The `deprecated` attribute does not work on types, only on
functions.
Remove the broken deprecation logic and re-export key types instead of
using type alias', this allows a bunch of qualified paths to be
simplified also.
Add `pub use` re-exports of all secp256k1 types that are part of the
public API of the `schnorr` module. This makes the module more ergonomic
to use.
When filtering it is necessary to check two lock times against each
other, we currently provide a patter for doing so in the docs but we can
do better.
It was observed that satisfaction of a lock time 'implies' satisfaction
of another lock time if the lock times are the same unit and one locks
value is less than the others - this is exactly the code pattern we
suggest for filtering.
Add a method on `absolute::LockTime` for checking a lock against another
lock, add rustdoc comment explaining the methods function in filtering
prospective lock time values (how we use it in `rust-miniscript`).
Currently in one of the rustdoc examples showing lock satisfaction we
use two locks with the same value, this obfuscates which lock is doing
the satisfying and which lock is being satisfied.
Increment the value in one of the locks so it is obvious which lock is
which.
Add a new crate `bitcoin-internals` to be used for internal code needed
by multiple soon-to-be-created crates.
Add the `write_err` macro to `bitcoin-internals`, nothing else.
This patch uses a `path` dependency which means `rust-bitcoin` cannot be
released in its current state, will need to be changed once we release
the `bitcoin-internals` crate on `crates.io`.
Create a directory `bitcoin` and move into it the following as is with
no code changes:
- src
- Cargo.toml
- contrib
- test_data
- examples
Then do:
- Add a workspace to the repository root directory.
- Add the newly created `bitcoin` crate to the workspace.
- Exclude `fuzz` and `embedded` crates from the workspace.
- Add a contrib/test.sh script that runs contrib/test.sh in each
sub-crate
- Fix the bitcoin/contrib/test.sh script
Jeffrey Czyz
Andrew Poelstra
Noah
Tobin C. Harding