rust-bitcoin

hashes: fold 4-way SSE4.1 SHA256d into round! macro

use a round! macro to cut ~1000 lines from the unrolled version.
each round becomes a single round!(...) call. it almost matches Core
line-by-line, so it's easy to compare and review against sha256_sse41.cpp.

refactor, no behavior change.

hashes: Add 4-way SSE4.1 SHA256d for 64-byte input

add the three transforms for sha256(sha256(64_bytes)) using SSE4.1 SIMD.

SSE4.1 uses 128-bit registers, so we can pack four 32-bit words into
each register and compute 4 independent hashes in parallel with a
single SIMD op.

- Transforms 1 & 2 compute the inner `sha256(64_bytes)`.
- Transform 3 computes sha256(output_of_T1_and_T2).

rounds are fully unrolled (we will use a round! macro to fold them
in the next patch).

crypto: Adjust SerializedLegacyPublicKey docs

The SerializedLegacyPublicKey docs don't mention the maximum size or
the lack of allocations like the ecdsa::SerializedSignature docs do.

Adjust wording of docs to mention lack of allocation and max size of
65 bytes.

Remove io write helpers from ecdsa signatures

In the ecdsa module, the SerializedSignature and Signature types have
helper methods for writing to bitcoin-io Write objects. Since we want
to remove the io dependency entirely, and the SerializedSignature can
already be used in a similar way to a slice, there's no point to
retaining them.

Remove Signature::serialize_to_writer and SerializedSignature::write_to.
Adjust existing io test case to use std traits.

Don't abuse psbt Deserialize

I'm not sure what is the intention of this code or exactly how the
derives are working in the `taproot` module because we are importing
`psbt::serialize::Deserialize` and then using it in `serde` derives?

Also the `TapTree` arbitrary stuff is a bit odd, that is what led me
here while I was attempting to delete the `psbt` module.

So, I don't know if this is a bug or an internal change? Introduced in
commit: `37c9fce2a684 Implement `Arbitrary` for psbt types`.

crypto: Move SerializedLegacyPublicKey to crypto

Now that the SerializedLegacyPublicKey has been re-arranged to remove
the strict dependence on PushBytes, it can be trivially moved to the
crypto crate.

Move SerializedLegacyPublicKey to crypto crate and re-export from
bitcoin.
Move associated test to crypto key module.

Remove dependence on PushBytes for SerializedLegacyPublicKey

The SerializedLegacyPublicKey type currently relies on
Borrow<PushBytes> to implement the Borrow and AsRef for [u8]. Since
PushBytes is only in bitcoin, this prevents the simple move. Instead,
the main reference conversion should be Deref for [u8].

Move Deref impl into encapsulating module and redefine
Borrow<PushBytes> in terms of it. Adjust order of Borrow and AsRef
impls.

crypto: Remove error conversion From impls

From impls for conversions between error types represent a public api
commitment. Since we can't know how the error types may need to change
as the crate progresses, it's best to remove these now and reintroduce
them later if we find them necessary and/or useful for users.

Remove all From<BarError> for FooError in crypto, replacing uses with
map_err where appropriate.

crypto: Re-export key types at crate root

Re-export the key types at the crate root, similar to the re-exports in
bitcoin.

crypto: Add pub extern crate for crates with public api types

In crypto, various types from child crates are present in the public
api, including base58::Error, network::NetworkKind, secp256k1 keys and
io traits. In order to simplify dependency handling, these crates
should be exposed through pub extern crate exports in the root of the
crypto crate.

Add pub extern crate statements for base58, network, io and secp256k1.
Remove comment on hex_stable re-export to match new policy.

Bump crypto crate version

With the move of types complete, the crypto crate is in a suitable
state for release and integration with bitcoin.

Bump crypto version number to 0.1.0.
Update crypto changelog.
Adjust bitcoin cargo TOML to match new version number.
Update lock files.

Move most key types to crypto crate

The key types in bitcoin are largely disconnected from bitcoin outside
of interdependencies within the crypto module. With the other
submodules moved, the keys can now be trivially moved to the crypto
crate.

Move and re-export all crypto key types and relevant errors from crypto
crate.

Split raw_ecdsa_sign_recoverable function to PrivateKeyExt

The raw_ecdsa_sign_recoverable function on PrivateKey exists purely to
provide the low level functionality used in the sign_message module of
bitcoin. Since this is not necessary at this early stage in the crypto
crate, it should be moved to a new extension trait prior to the move.

Introduce PrivateKeyExt and move raw_ecdsa_sign_recoverable to the new
extension trait.

Move ecdsa module to crypto crate

The ecdsa module has no dependencies in bitcoin outside of some in the
sighash module of crypto. Following the previous sighash move, this
entire module can now be trivially moved to the crypto crate.

Move the ecdsa module to the crypto crate.

Fix lint errors in crypto crate

The prior code move introduces a variety of lint errors due to the lax
lint requirements from bitcoin compared to the other crates.

Fix all lint errors in crypto crate's ecdsa module.

Move minimal sighash types to crypto crate

While many of the sighash types are intertwined with taproot and
bitcoin dependencies, some can be moved and re-exported trivially.

Move and re-export EcdsaSighashType, TapSighashType,
InvalidSighashTypeError, NonStandardSighashTypeError and
SighashTypeParseError to crypto crate.

Break split_anyonecanpay_flag functions to SplitAnyoneCanPay trait

The split_anyonecanpay_flag functions are pub(crate). Since we don't
want them to be in the public API, and they're exclusively used by
logic that will remain in bitcoin, we can split them into a pub(crate)
trait to be left behind.

Introduce SplitAnyoneCanPay trait and implement for TapSigHashType and
EcdsaSighashType by moving the corresponding split_anyonecanpay_flag
functions to them.

Return TapSighashType parse error in PsbtSighashType FromStr

The FromStr trait for PsbtSighashType uses the TapSighashType FromStr
to parse from a string. On failure, this generates the same
SighashTypeParseError that is currently returned. Rather than manually
constructing the error, we can just return the error result from
attempting to parse s as a TapSighashType.

Return the error result of the TapSighashType FromStr impl rather than
manually constructing a new error in PsbtSighashType FromStr impl.

Fix lint errors in crypto crate

The prior code move introduces a variety of lint errors due to the lax
lint requirements from bitcoin compared to the other crates.

Fix all lint errors in crypto crate's sighash module.

Split methods to extension traits on public keys

The p2wpkh_script_code functions on FullPublicKey and LegacyPublicKey
rely on functionality only present in the bitcoin crate. Since this
will not be easy to move out, these functions should be moved to
extension traits prior to the move.

Further, the to_bytes method on LegacyPublicKey relies on
SerializedLegacyPublicKey, a type which itself relies on conversions
to and from PushBytes, a type only available in bitcoin. Since the
serialised type cannot be moved at present, the to_bytes must be left
behind in the extension trait for now.

Introduce FullPublicKeyExt and LegacyPublicKeyExt and move the
corresponding p2wpkh_script_code functions to them from the public
key types. Move to_bytes on LegacyPublicKey to LegacyPublicKeyExt.

Improve Arbitrary impl for Xpriv

p2p: add ping pong example

Run the formatter

Add `SerializedLegacyPublicKey`

The legacy public keys can be serialized as compressed or uncompressed
which was annoying to deal with since serializing them involved either a
heap alloction or branches. A stack-allocated type holding any key was
needed for a long tim.

This commit finally adds `SerializedLegacyPublicKey` which behaves
similarly to `SerializedSignature` - holding `ArrayVec<u8, 65>` to be
able to represent any of the keys. While this could've been more
efficient, taking advantage of the first byte encoding length, let's
stick with something simple at least for now.

hashes: Add x86 SHA-NI 2-way dispatch

add x86 sha256d dispatcher that handles 2-way SHA-NI