Commit Graph

1233 Commits

Author SHA1 Message Date
Christian Reitter 46707eab19 Optimize speed by skipping 4-byte fingerprint generation 2024-04-27 13:14:53 +02:00
Tobin C. Harding dc8b900dec
Document the *_encode_signing_data_to functions
If one writes signing data using one of the two
`*_encode_signing_data_to` functions then creating the message to sign
is slightly nuanced and different for each of the functions. For Taproot
one must use a specific tagged hash and for ECDSA one must use a sha256d
hash.

Add documentation that explains the hashing requirements for each
function.
2024-04-23 18:03:38 +10:00
Andrew Poelstra 4a4e07d66a
Merge rust-bitcoin/rust-bitcoin#2699: Set release version in deprecated attribute
f96bbebdcc Set release version in deprecated attribute (Tobin C. Harding)

Pull request description:

  In preparation for release replace "TBD" with the next release version - `v0.32.0`.

ACKs for top commit:
  apoelstra:
    ACK f96bbebdcc
  storopoli:
    ACK f96bbebdcc

Tree-SHA512: 7478808322357d853fab2bf25a7d42a972d5ee05ed6f206bfb73748efe1154fb392dc76c3d0e1a50314bcfdac3a55a415f3c6d40dfaaab802ae1c69dd1ad9e76
2024-04-23 01:45:04 +00:00
Fmt Bot 3417c576ed 2024-04-21 automated rustfmt nightly 2024-04-21 01:03:30 +00:00
Tobin C. Harding f96bbebdcc
Set release version in deprecated attribute
In preparation for release replace "TBD" with the next release version.
2024-04-19 05:33:42 +10:00
Tobin C. Harding 3a2d86e0c6
Fix example spend amount
In the segwit signing example we are using the incorrect value when
creating the signature - we should be using the utxo amount (input
amount) not the spend amount (output spend amount).

Close: #2680
2024-04-18 09:23:18 +10:00
Andrew Poelstra 7a8dafb748
Merge rust-bitcoin/rust-bitcoin#2692: Add docs for custom signets
30a09670e8 Add docs for custom signets (Tobin C. Harding)

Pull request description:

  We have started using `AsRef<Params>` in a few places as a function parameter. If a user of the library wishes to use these functions they need to create a type that can implement this trait. Because we use `non_exhaustive` on the `Params` struct it is not possible to just construct a `Params` type. This may be surprising for some folk.

  Add module level docs to the `consensus::params` module with an example of how to create a type that can be used to describe a custom signet network. Use fields inspired by Mutiny Wallet's described usage.

  Close: #2690

ACKs for top commit:
  sanket1729:
    ACK 30a09670e8.
  apoelstra:
    ACK 30a09670e8 this is great; would like to see more `const` but for example code no big deal

Tree-SHA512: 50881763aea99641e24871b0eae60650174c48f620742944e7d5617fcf1edff73a20b2a8f043433f6f114ff5f3f4691703fc37b28880c305bb052c2d75d1eeeb
2024-04-17 17:31:03 +00:00
Tobin C. Harding 30a09670e8
Add docs for custom signets
We have started using `AsRef<Params>` in a few places as a function
parameter. If a user of the library wishes to use these functions they
need to create a type that can implement this trait. Because we use
`non_exhaustive` on the `Params` struct it is not possible to just
construct a `Params` type. This may be surprising for some folk.

Add module level docs to the `consensus::params` module with an example
of how to create a type that can be used to describe a custom signet
network. Use fields inspired by Mutiny Wallet's described usage.

Close: #2690
2024-04-17 10:35:32 +10:00
Tobin C. Harding 6e84548b1f
Allow deprecated Params field
I'm not sure why I haven't see this before during the whole test cycle
but while running `cargo kani --only-codegen` we get a bunch of warnings
of form:

  warning: use of deprecated field `consensus::params::Params::pow_limit`

We deprecated the `pow_limit` field but still set it (obviously) in
const structs - just shoosh the warning.
2024-04-17 06:31:41 +10:00
Andrew Poelstra f18bd22489
Merge rust-bitcoin/rust-bitcoin#2677: Allow m prefix in derivation paths
830c1e9cfe Allow m prefix in derivation paths (Tobin C. Harding)

Pull request description:

  Recently in #2451 we disallowed bip32 derivation paths with the leading 'm' variable.

  There is some confusion as to what exactly the bip specifies however Bitcoin Core RPC call `getaddressinfo` returns a derivation path with a leading "m/". This means we need to be able to parse it irrespective of what the bip says.

  Be more liberal in what we accept as a derivation path, including both with and without the leading 'm/'.

  Leave the full investigation of the bip to a later date.

  Change back some of the test strings as makes sense and include test strings to showcase the full current behaviour.

  This PR replaces #2674.

ACKs for top commit:
  apoelstra:
    ACK 830c1e9cfe
  sanket1729:
    ACK 830c1e9cfe
  junderw:
    ACK 830c1e9cfe

Tree-SHA512: 7a4fccd49cb8cd91a6c8db51d758ae116d9d2e98fead7b87520ca302022b37ddbcf3f85453941c5f336f8e934ad224beba99527dc29ce8368fbb1f25508c1615
2024-04-15 12:40:18 +00:00
Tobin C. Harding 830c1e9cfe
Allow m prefix in derivation paths
Recently in #2451 we disallowed bip32 derivation paths with the leading
'm' variable.

There is some confusion as to what exactly the bip specifies however
Bitcoin Core RPC call `getaddressinfo` returns a derivation path with a
leading "m/". This means we need to be able to parse it irrespective of
what the bip says.

Be more liberal in what we accept as a derivation path, including both
with and without the leading 'm/'.

Leave the full investigation of the bip to a later date.

Change back some of the test strings as makes sense and include test
strings to showcase the full current behaviour.
2024-04-11 07:23:30 +10:00
Tobin C. Harding 33ebbac4c8
Improve deprecation notice
The deprecation notice for `is_provably_unspendable` contains "is not
very useful" which is a bit presumptuous to tell to users, it may very
well be useful to them. Use the more helpful text that already exists in
rustdoc on the function.
2024-04-10 11:05:05 +10:00
Andrew Poelstra 163bf64fcc
Merge rust-bitcoin/rust-bitcoin#2668: Automated nightly rustfmt (2024-04-07)
747ca578dd 2024-04-07 automated rustfmt nightly (Fmt Bot)

Pull request description:

  Automated nightly `rustfmt` changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action

ACKs for top commit:
  apoelstra:
    ACK 747ca578dd
  tcharding:
    ACK 747ca578dd

Tree-SHA512: c4387388f2cfcb9b9aacf7023d024379cbf073166f04fcba4b4c0d66972ee109f4c9f66e0d8ed1d57c419266680a9e6953a5e38ecb0aa937e6c368d59aaba976
2024-04-08 22:28:08 +00:00
Andrew Poelstra 12be5c0d27
clippy: fix a couple of nits in `clippy --no-default-features`
We only check clippy in CI with --all-features, which usually is the
best way to get maximum coverage. But if you try a couple other feature
combos, especially those related to nostd, you can hit more code.
2024-04-07 15:16:09 +00:00
Andrew Poelstra 5c56b69eed
Merge rust-bitcoin/rust-bitcoin#2667: Remove deprecated legacy numeric methods
051c358bcb Remove deprecated legacy numeric methods (Divyansh Gupta)

Pull request description:

  As `rustc 1.79.0-nightly (9d79cd5f7 2024-04-05)` is released which solves the issue mentioned , but the release has deperacted legacy numeric methods.
  Thus replaced `u16::max_value()` etc with `u32::MAX` & `core::u16` to directly `u16`.

  fix #2639

ACKs for top commit:
  tcharding:
    ACK 051c358bcb
  apoelstra:
    ACK 051c358bcb thanks! I will remove an equivalent commit from my #2669

Tree-SHA512: c08c856f7f3b281417c29283351eac5e0f75cc1c8d23d9aae58d969219a327b2337fe57932053e53773ebb9dbec04254f90149266b6639a66c5c09f2ad1675ef
2024-04-07 15:15:47 +00:00
Fmt Bot 747ca578dd 2024-04-07 automated rustfmt nightly 2024-04-07 01:03:23 +00:00
Divyansh Gupta 051c358bcb Remove deprecated legacy numeric methods
As `rustc 1.79.0-nightly (9d79cd5f7 2024-04-05)` is released which solves the issue mentioned , but the release has deperacted legacy numeric methods.
Thus replace `u16::max_value()` etc with `u32::MAX` & `core::u16` to directly `u16`.

fix #2639
2024-04-07 01:51:14 +05:30
Tobin C. Harding 0073a17e20
bitcoin: Bump version to 0.32.0-rc1
In preparation for dropping the first release candidate bump the version
and add a changelog.

Please not I went to much more effort that usual with the changelog,
open to review on the overall form - not promising I'll change it but
definitely would like to keep iterating and improving.

If this changelog is appreciated then FWIW I don't think we should
bother automating it, a machine does not have all the context required
to create it.
2024-04-05 08:10:08 +11:00
Andrew Poelstra a5eee3eadc
Merge rust-bitcoin/rust-bitcoin#2655: units: Release tracking PR: `0.1.1`
e06ebd69e7 units: Bump version number to 0.1.1 (Tobin C. Harding)
a2b019f823 Enable internals "alloc" feature (Tobin C. Harding)

Pull request description:

  Fix a minor internal bug in error code in `units` and bump the version number so we can do a point release.

  This can go in after the RC drops as part of the release candidate cycle if its easier - as long as its in and released before the finale `v0.32.0` release.

ACKs for top commit:
  apoelstra:
    ACK e06ebd69e7
  sanket1729:
    ACK e06ebd69e7

Tree-SHA512: b6523fae57ba3becf27c0a11fe0b1d75db9226d01bde527390e2cf1697520d5daabc5ef3909b2c464b14f38ba4f8ab87aa49d17a1d054767920963ef1c3ef3b9
2024-04-04 21:08:22 +00:00
Tobin C. Harding a2b019f823
Enable internals "alloc" feature
We have 2 crates that require an allocator, `bitcoin` and `base58ck` -
these crates should enable the "alloc" feature when depending on
`internals`.

For `units` we use the `internals::error::InputString` but do not enable
the "alloc" feature - this is a bug, it means that the parsed string is
being lost from the error types that use `InputString`.

Enable "alloc" for `bitcoin`, `base58ck`, and `units`.

- `bitcoin` and `base56ck` is just for good measure so we don't get
  bitten later on.
- `units` is a bug fix and requires a point release.
2024-04-04 08:18:51 +11:00
Tobin C. Harding 14040e2ff5
psbt: Return the internal key for key path spend
When signing a Taproot input (in a PSBT) using a key path spend we
currently return the pubkey associated with key that signs. However it
is common to think of the internal key as being the one that signs even
though this is not technically true. We also have the internal key in
the PSBT so matching against it is less surprising.

When using the `Psbt` type to sign a Taproot input using a key path
spend return the internal key.
2024-04-04 07:36:04 +11:00
Tobin C. Harding ffd5664c08
Do not panic if input_index is out of bounds
There is no need to panic if input index is out of bounds because we
have a function to check the validity of the `input_index` argument and
use it in other places already.
2024-04-04 07:27:55 +11:00
Tobin C. Harding f79f20d4e6
Remove stale rustdoc
We recently added support for signing taproot inputs but forgot to
update the docs to reflect this.

Remove stale rustdoc from `Psbt::sign` function.
2024-04-04 07:27:53 +11:00
Andrew Poelstra b5fbdcd68a
Merge rust-bitcoin/rust-bitcoin#2541: Reduce usage of `Network` in the public API
f6467ac98d Minimize usage of Network in public API (Tobin C. Harding)
3ec5eff56e Add Magic::from_params (Tobin C. Harding)

Pull request description:

  Minimize usage of the `Network` enum in the public API.

  See #2225 for context, and https://github.com/rust-bitcoin/rust-bitcoin/pull/1291#discussion_r1492993788 for an interpretation of that long discussion.

  Close: #2169

ACKs for top commit:
  sanket1729:
    reACK f6467ac98d.
  apoelstra:
    ACK f6467ac98d

Tree-SHA512: f12ecd9578371b3162382a9181f7f982e4d0661915af3cfdc21516192cc4abb745e1ff452649a0862445e91232f74287f98eb7e9fc68ed1581ff1a97b7216b6a
2024-04-03 13:50:47 +00:00
Tobin C. Harding f6467ac98d
Minimize usage of Network in public API
A release or so ago we added `non_exhaustive` to the `Network` enum,
this turned out to make usage of the enum un-ergonomic for downstream
users. After much debate we decided that a way forward was to just
minimize the usage of the enum in the public API by instead use
`AsRef<Params>` so that downstream could define their own network enum
based on the networks they support.

Minimize usage of `Network` by using `AsRef<Params>` as a parameter type
instead. "minimize" because the `Network` still appears in some places.
2024-04-03 13:32:39 +11:00
Tobin C. Harding 1bb32febbd
Use manual docs attributes
Currently we are using `Self` (in backticks) in the docs to functions
defined by the `do_iml` macro, this is a bit lazy, we can do better than
that.

Use `doc` attribute and the `$ty` macro variable to construct the docs
to use the type name.
2024-04-03 11:14:32 +11:00
Tobin C. Harding 19f70959e1
Document private from_hex_internal function
Use a code comment to document the calling restrictions of private
function `from_hex_internal`. (Code comment because comment is not well
formed as per convention in this codebase.)
2024-04-03 11:12:45 +11:00
Tobin C. Harding 81a704302c
Improve rustdocs on U256 type
Improve the rustdocs on the private `U256` type by doing:

- Remove link to self within constructors, just use backticks
- Use `U256` instead of `Self` or `self`
- Fix incorrect usage of `CompactTarget` [0]

[0] We knew this was wrong when we merged it but because the docs are
private we elected to do this follow up patch.
2024-04-03 11:09:47 +11:00
Tobin C. Harding e1869340be
Upgrade secp dependency
Upgrade `rust-secp256k1` to the latest version `v0.29.0`. This removes
the duplicate deps as well.
2024-04-03 09:24:41 +11:00
Tobin C. Harding 3ec5eff56e
Add Magic::from_params
Currently `Magic` has per network consts but no way to dynamically get
the magic bytes for a network. Note also that we are currently trying to
reduce the usage of `Network` in the public API.

Add a public constructor to the `Magic` type that accepts a `Params`
parameter to determine the network to use.
2024-04-03 07:58:33 +11:00
Tobin C. Harding f019e24f1f
Add hex parsing to pow types
The `pow` types implement `fmt::LowerHex` but do not implement hex
parsing.

Add inherent methods `from_hex` and `from_prefixed_hex` to the
`pow` types.
2024-04-03 07:10:20 +11:00
Andrew Poelstra 499f36f972
Merge rust-bitcoin/rust-bitcoin#2337: Add check to max difficulty transition threshold
fd6fedc3ad Improve API for max target threshold calculation (Tobin C. Harding)
6e47d57744 Rename difficulty transition threshold functions (Tobin C. Harding)
4121c9a09f Rename Params::pow_limit to max_attainable_target (Tobin C. Harding)
f0f6d3f162 Take Params instead of Network in difficulty function (Tobin C. Harding)
104dee9376 Debug assert that target != zero in difficulty calc (Tobin C. Harding)
c1ba496a07 Document current behaviour of difficulty_float (Tobin C. Harding)
3d01146374 Allow needless-borrows-for-generic-args (Tobin C. Harding)
2a6821b426 Use link to CompactTarget in rustdoc (Tobin C. Harding)

Pull request description:

  When computing the maximum difficulty transition threshold we forgot to check that the returned `Target` is not bigger than the maximum. This value is network specific so keep the original logic but with `_unchecked` on the function name.

  This was noted in the discussion on #2161

ACKs for top commit:
  apoelstra:
    ACK fd6fedc3ad
  sanket1729:
    ACK fd6fedc3ad

Tree-SHA512: 520ee2a07edb251c84b5ce8b48ed6e5a5c1945126dc7bcdb5570e97101ec4a3dc63fa7992725194869e22b21ee4f5955579d5e2499fcb48167637fd1fb3ae74d
2024-04-02 13:18:29 +00:00
Tobin C. Harding fd6fedc3ad
Improve API for max target threshold calculation
The maximum target threshold has a network dependant upper bound.
Currently we are not checking this bound. One complication is that there
is currently heated open debate around the `Network` type.

We can bypass the `Network` issue by using `AsRef<Params>` instead.

Add a function that does the checks based on the `Params` type as well
as an unchecked version.
2024-04-02 11:41:49 +11:00
Tobin C. Harding 6e47d57744
Rename difficulty transition threshold functions
These two functions calculate the min/max threshold transition which is
a _target_ not a "difficulty" number. Using "difficulty" in the function
name is unnecessarily confusing.

Rename and deprecate the functions.
2024-04-02 11:41:38 +11:00
Tobin C. Harding 4121c9a09f
Rename Params::pow_limit to max_attainable_target
The maximum "attainable" target is a `rust-bitcoin` thing, Core use max
unattainable.

Deprecated the `Params::pow_limit` field and add a new field
`max_attainable_target`.

The `Params` type is `non_exhaustive` so this is not an API breaking
change.
2024-04-02 11:41:38 +11:00
Tobin C. Harding f0f6d3f162
Take Params instead of Network in difficulty function
What we really want is the maximum target, but since this is a const in
`Params` use an `AsRef<Params>` argument in the `difficulty` functions.

Requires implementation of `AsRef<Params> for Params`.
2024-04-02 11:41:34 +11:00
Tobin C. Harding 104dee9376
Debug assert that target != zero in difficulty calc
The `difficulty` calculation requires dividing a target value by `self`.
Add an assertion that `self` is not zero to help devs debug this.

Note that this should never really be hit, but its possible there is a
bug somewhere causing the target to be set to zero - so this may help
debugging.

Also, add panics section to rustdocs.
2024-04-02 11:40:46 +11:00
Tobin C. Harding c1ba496a07
Document current behaviour of difficulty_float
Improve rustdocs on the `Target::difficulty_float` function,
specifically the return value if self is zero.
2024-04-02 11:40:45 +11:00
Tobin C. Harding 3d01146374
Allow needless-borrows-for-generic-args
This lint triggers when parsing a reference to a large struct as a
generic argument, which is wrong.

Allow it crate wide because [subjectively] this lint never warns for
anything useful.
2024-04-02 11:40:41 +11:00
Andrew Poelstra 6a2fd96ff6
Merge rust-bitcoin/rust-bitcoin#2581: Implement ArbitraryOrd for relative::LockTime
d91cdd20bf docs: Document ordered feature (Tobin C. Harding)
3520f550f0 Implement ArbitraryOrd for relative::LockTime (Tobin C. Harding)

Pull request description:

  TL;DR As we do for `absolute::LockTime` and for the same reasons; implement `ArbitraryOrd` for `relative::LockTime`.

  locktimes do not have a semantic ordering if they differ (blocks, time) so we do not derive `Ord` however it is useful for downstream to be able to order structs that contain lock times. This is exactly what the `ArbitraryOrd` trait is for.

  Fix: #2566

ACKs for top commit:
  sanket1729:
    ACK d91cdd20bf
  apoelstra:
    ACK d91cdd20bf

Tree-SHA512: 52ace9222e765dfa266d003b4aff3e93e35d1414c9fd579c4a4a36998d6d1b08bf6d4964a6f1c1d769068d65e47a882495daa4aacf254909a35dce8e01c99a9e
2024-04-02 00:36:12 +00:00
Tobin C. Harding 2a6821b426
Use link to CompactTarget in rustdoc 2024-04-02 11:33:26 +11:00
Andrew Poelstra 684b453b7c
Merge rust-bitcoin/rust-bitcoin#2632: internals: Release tracking PR `v0.3.0`
af6dc1db02 internals: Bump version to 0.3.0 (Tobin C. Harding)

Pull request description:

  In preparation for release add a changelog and bump the version number.

  Please note, the changelog is pretty terse.

ACKs for top commit:
  apoelstra:
    ACK af6dc1db02
  sanket1729:
    ACK af6dc1db02

Tree-SHA512: b70d4b9de7de90aba3cbff90dd7f25c5ac801d020dbdfe3e64af4c079347cba726aa783a94fc777e7bf177db8402b54948c2dfd4a766d90c1a7a7a6bdfd36136
2024-04-02 00:09:04 +00:00
Tobin C. Harding d91cdd20bf
docs: Document ordered feature
Add "ordered" to the list of features in the `bitcoin` crate level docs.
2024-04-02 08:10:38 +11:00
Fmt Bot a565db9fdd 2024-03-31 automated rustfmt nightly 2024-03-31 01:03:18 +00:00
Tobin C. Harding af6dc1db02
internals: Bump version to 0.3.0
In preparation for release add a changelog and bump the version number.
2024-03-27 09:44:30 +11:00
Tobin C. Harding 3520f550f0
Implement ArbitraryOrd for relative::LockTime
TL;DR As we do for `absolute::LockTime` and for the same reasons;
implement `ArbitraryOrd` for `relative::LockTime`.

locktimes do not have a semantic ordering if they differ (blocks, time)
so we do not derive `Ord` however it is useful for downstream to be able
to order structs that contain lock times. This is exactly what the
`ArbitraryOrd` trait is for.

Update the rustdocs in `relative` and mirror the docs changes in
`absolute`.

Fix: #2566
2024-03-26 10:36:50 +11:00
Andrew Poelstra 9df59639ce
Merge rust-bitcoin/rust-bitcoin#2621: Release tracking PR: `hashes v0.14.0`
0ca5a43ce5 hashes: Bump version to v0.14.0 (Tobin C. Harding)

Pull request description:

  In preparation for release add a changlelog entry and bump the version.

  Note the hashes 0.13.0 dependency stays in the dependency graph because of secp, we can update secp after releasing `hashes` then update the secp dependency in `rust-bitcoin` thereby removing the `hashes v0.13.0` dependency - phew.

  Note we are right to release this immediately, the two open PRs (#2337 and #2541) that touch `hashes` only add a clippy attribute so can safely be ignored.

ACKs for top commit:
  apoelstra:
    ACK 0ca5a43ce5
  sanket1729:
    ACK 0ca5a43ce5

Tree-SHA512: d1d26acb8fbf13f785b25add3f1dac05bb392b5bdbad16ead2bc5dd26f3d668824c4b653c373f88c3562a37e775146766680606cedd19db40e0f197b26ca86b8
2024-03-25 22:23:30 +00:00
Tobin C. Harding a7a99e06bb
Add a validation variant to `ParseError`
`require_network` is typically called as part of parsing, often in the
same line of code. Counter to our normal errors, it makes
`require_network` more ergonomic to use if we just return a `ParseError`
variant.

Close: #2507
2024-03-25 08:45:19 +11:00
Tobin C. Harding d5c52618a9
Move NetworkValidationError within file
Done in preparation for adding the `NetworkValidationError` as a variant
of `ParseError`.

Move the `NetworkValidationError` type to beneath `ParseError`.

Code move only, no other changes.
2024-03-25 06:54:12 +11:00
Andrew Poelstra c211e7be78
Merge rust-bitcoin/rust-bitcoin#2626: Replace TBD with 0.32.0
fd040f5e38 Replace TBD with 0.32.0 (Tobin C. Harding)

Pull request description:

  We are gearing up for the 0.32.0 release; replace all instances of TBD with the version number of the upcoming release.

ACKs for top commit:
  sanket1729:
    ACK fd040f5e38
  apoelstra:
    ACK fd040f5e38

Tree-SHA512: fe73fd47a794557742f618b21434cd3cc18cde0e861216716723bfcc9135accf63590e1ea60bfeda066acec7312c8b9f1bf09e7454e7161ccaba5ebe60af66fd
2024-03-24 15:15:09 +00:00