2001f44e46 Try to fix up sighash export mess (Tobin C. Harding)
Pull request description:
Recently we moved a few types from `transaction` to `sighash`, while doing so I erroneously annotated code with the `deprecated` attribute hoping it would give downstream users a gentle upgrade experience. It turns out `deprecated` only works on functions.
During that same work, we re-exported from the crate root a bunch of types from the `sighash` module that probably should not have been re-exported. We are currently trying to create a nice clean API surface, in an effort to move in the right direction we should remove the re-exports and just re-export the `sighash` module.
Try to clean up the sighash export mess by doing:
- Remove the re-exports from the `transaction` module
- Remove crate level re-exports of `sighash` module types
- Re-export `sighash` module
Note, this patch is a breaking API change, justified by the fact that there is no good way to gently lead downstream when moving types since types cannot be deprecated with the `deprecated` attribute.
ACKs for top commit:
apoelstra:
ACK 2001f44e46
Kixunil:
ACK 2001f44e46
Tree-SHA512: 42a08bc15bacd4cf7c3fec002ddb29afe5b1be3c4eb74fbd8c63a9333c0d45cbc8493027532f5db6a3930d49b1e83048826371e0ed7d4ac3dc611e5885540bce
8bed2ddffe Run formmater on bip32 (Tobin C. Harding)
34113c9558 Move bip32 module to crate root (Tobin C. Harding)
Pull request description:
We are attempting to flatten the `util` module.
Move the `bip32` module to the crate root out of `util`.
Currently `src/util/` is ignored by the formatter so this move requires `bip32` module to be formatted. Formatting is done as a separate patch so reviewers can run `cargo +nightly fmt` and compare the diffs if so desired.
ACKs for top commit:
apoelstra:
ACK 8bed2ddffe
Kixunil:
ACK 8bed2ddffe
Tree-SHA512: dadea31be0459fd10e71927bd21dc44b59428f695a6df7093052ca7257b6590d5dd5b1343a89869ac9f4d7805dbca7558b475048ea9387c36265f14246cc6852
8aa94bd0b2 Improve docs on is_implied_by (Tobin C. Harding)
b8721bf244 Add method relative::LockTime::is_implied_by (Tobin C. Harding)
d5492b8a25 Add absolute::LockTime::is_implied_by method (Tobin C. Harding)
98cbdb5a5c Increment lock value (Tobin C. Harding)
Pull request description:
Patch 1 is a docs improvement.
Patch 2 commit log:
When implementing the absolute lock time API we decided on _not_
supporting checking lock satisfaction with another lock, instead we
provided a pattern in the docs for doing so. Fast forward a months and
I, the primary author, then forgot to use the correct pattern when using
the API in `rust-miniscript` - this is a sure sign that the API is too
hard to use. In this time we worked on the relative lock API and came up
with a `is_satisfied_by_lock` method - this is identical to the required
use case in the absolute lock time module.
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`).
ACKs for top commit:
Kixunil:
ACK 8aa94bd0b2
apoelstra:
ACK 8aa94bd0b2
Tree-SHA512: 5c7efa1727a846248783c9e6044bf8b0a7550d298ca1b5d3274ef325cf82efa33392ad14ef7e3e9aa91423ba56e8a3e7f4a38a966be38f673dccefd46465ad51
The `user_enum` macro is only used a single time. The macro includes
custom serde logic which can be trivially derived instead.
Remove the `user_enum` macro and just implement `Network` the old
fashioned way. Doing so simplifies the code.
We are attempting to flatten the `util` module; move the `bip32` module
to the crate root out of `util`.
Currently `src/util/` is ignored by the formatter, this patch does not
do formatting, will be done later.
The lock time methods are a source of endless confusion; make an attempt
at improving further the documentation on the two `is_implied_by`
methods (one on absolute lock time and one on relative).
As we just did for `absolute::LockTime` add a method `is_implied_by` and
deprecate `is_satisfied_by_lock`.
Reasoning: it is odd to think of a lock satisfying another lock but it
is clear to see that satisfaction of one lock can imply satisfaction of
another.
Recently we moved a few types from `transaction` to `sighash`, while
doing so I erroneously annotated code with the `deprecated` attribute
hoping it would give downstream users a gentle upgrade experience. It
turns out `deprecated` only works on functions.
During that same work, we re-exported from the crate root a bunch of
types from the `sighash` module that probably should not have been
re-exported. We are currently trying to create a nice clean API surface,
in an effort to move in the right direction we should remove the
re-exports and just re-export the `sighash` module.
Try to clean up the sighash export mess by doing:
- Remove the re-exports from the `transaction` module
- Remove crate level re-exports of `sighash` module types
- Re-export `sighash` module
Note, this patch is a breaking API change, justified by the fact that
there is no good way to gently lead downstream when moving types since
types cannot be deprecated with the `deprecated` attribute.
Done as part of flattening the `util` module.
We have a function in `util::misc` that operates on scripts, it is an
implementation of `FindAndDelete` from Bitcoin Core and is primarily
useful for supporting `CODESEPARATOR`, which we do not support.
Move the public `script_find_and_remove` function out of `util/misc.rs` and into
`util/mod.rs`, delete the testing and deprecate the function.
92ef41b663 Make `ChainHash::using_genesis_block` constant (Jeffrey Czyz)
Pull request description:
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.
Follow-up suggested in [#1283](https://github.com/rust-bitcoin/rust-bitcoin/pull/1283#issuecomment-1249418809).
ACKs for top commit:
apoelstra:
ACK 92ef41b663
Kixunil:
ACK 92ef41b663
Tree-SHA512: 71f95877c8e5335012ad0339e1f8691e3b33344fa02ecc24c3d4d728232cb7b0de62aec20eb1855b23eeccfbc2eeab920b21ee2243d95c6c89fa8ad5bc846975
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
Andrew Poelstra
Tobin C. Harding
Jeffrey Czyz
Noah