rust-bitcoin

Split Target and Work in to extension traits

In order to reduce the move to units to a simple type definition, the
existing logic in bitcoin's pow module needs to be moved into
extension traits.

from_compact is required for the From impl for CompactTarget to Target,
and as such, is retained in the Target impl.
to_compact_lossy is retained as the inverse operation for from_compact.

Introduce TargetExt and WorkExt extension traits and move most struct
content into them.

Move U256 tests to units

As part of ensuring that the hex parsing on U256 is only needed in
units (to simplify error conversions), the test cases for u256 that
currently rely on the U256Hex trait should be moved to units. This move
also ensures that the type is tested at the most upstream point it is
used, not only in bitcoin, potentially helping to catch bugs earlier.

Move all u256-specific test cases to units.
Remove U256Hex trait from bitcoin.
Fix lint errors in test cases.

Update API files

Following the move of the pow types to units, the api files for
both units and primitives will be out of date.

Update API files for units and primitives.

Move Target and Work to units

With all the prior work complete, the pow types can now be moved to
units. Since units has no hex feature, hex formatting for the U256
(and thus the Target and Work types) is implemented manually.

Move Target and Work to units, using include! to introduce U256.
Move and improve relevant tests to kill mutants.
Fix lint errors to satisfy stricter requirements.

Deprecate the to_hex implementation on Work and Target

Types in stable crates should not include the to_hex function. Since
this type is coming from bitcoin, this may be unintuitive to users.
For now, we'll keep the to_hex functionality on the types using the
bitcoin extension traits, but label them as deprecated.

Deprecate the Work and Target to_hex implementations.

Adjust pow impls to remove private access

With the move to units, the use of the Target() and Work() constructors
will no longer be possible, and neither will access to the inner U256.
However, since these types retain the to_/from_le_bytes, we can convert
them to the locally include!d U256 to perform the various complex
operations on them.

Convert all functions in TargetExt and WorkExt to use to_/from_le_bytes
instead of directly constructing or accessing the inner U256.

Move U256 to shared include and use include! in pow

As part of stabilising the proof-of-work types, various functionality
needs to be computed in bitcoin without access to the inner type.
Since U256 should not be in the public API, the U256 struct logic
needs to be (at least partially) duplicated. In order to avoid having
multiple direct copies of the same code, we can use the include!
macro with a shared file.

Add include/u256.rs and move U256 struct definition to it. Use
include! to retain the logic in bitcoin's pow module.

Split hex parsing on U256 into a second impl

The hex parsing on U256 is only used for the constructors of the Target
and Work types. Since we want to remove the From impls on the hex
errors, we need to remove the usage of them from outside of units.
Since U256 will be a shared module, we need to break out the hex parsing
into a separate impl that we can eventually move into units.

Introduce a second U256 impl and move hex parsing functionality from
U256 into it.

Remove hex_conservative from U256 serde

The serde implementation for U256 relies on hex_conservative features
for the human readable implementation. Since units won't always have
access to the hex_conservative crate, it's better to change the serde
implementation to function without it.

Replace hex parsing to use units::parse_int module instead of
hex_conservative for U256 serde implementation.

Exclude aarch64-gated merkle code from mutation

the new batched merkle root functions are behind
cfg(target_arch = "aarch64") and are not compiled on the x86_64
CI runner, which cause these mutants to appear

exclude these mutants until x86 SIMD support lands (#5540)

benches: benchmark merkle root computation

benchmark with consecutive odd and even counts to calculate the
cost of adding the last transaction in the odd case

primitives: add test comparing batch and stacked-based merkle root

compare the old stack-based approach to calculate the merkle root
against the new batched level-by-level approach.

primitives: use optimized sha256d for 64-byte in merkle root computation

currently we are using stack-based approach to calculate the root.
instead of that, we can batch all pairs at each tree level into one
`hash_64_many()` call

we gate this for aarch64 to use the new batched algorithm. We will
widen to support x86 once we add a 2-way SHA-NI implementation.

for no-alloc we will always keep using the old stack-based approach

Re-export locktime encoders and decoders

For all `units::foo::Foo` there should exist a `primitives::foo::Foo`
and `bitcoin::foo::Foo`. We forgot about the new locktime encoding
types.

FTR we have issue #5969 to investigate how this happened.

Remove public re-exports of old consenus traits

In the `absolute` module for some reason we publicly re-export the old
consensus encoding traits. This is unusual and wrong.

Uncovered in discussion between Andrew and Nymius on PR 5965

Remove the public re-export but keep the import statement.

Add panics section to docs

Docs cleanup

Add a couple of missing full stops and capital letters.

bitcoin: Move key module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from key module into error submodule and re-export.

bitcoin: Move transaction module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from transaction module into error submodule and
re-export.

bitcoin: Move ecdsa module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from ecdsa module into error submodule and re-export.

bitcoin: Move sighash module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from sighash module into error submodule and re-export.

bitcoin: Move script module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from script module into error submodule and re-export.

bitcoin: Move block module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from block module into error submodule and re-export.

bitcoin: Move witness_program module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from witness_program module into error submodule
and re-export.

bitcoin: Move witness_version module errors to error submodule

At present, some modules in bitcoin separate error types into
submodules with re-exports while others simply define the error types
in the module. This inconsistency is confusing and makes the docs vary.
All error types for each top-level module should be moved into a
relevant submodule and re-exported without inline docs.

Move error types from witness_version module into error submodule
and re-export.