rust-bitcoin

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.

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.

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.

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.

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 sighash module.

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.

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.

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

hashes: Interleave two independent hashes for 2-way SHA256d

x86 SHA256RNDS2 has a latency of 4-6 cycles depending on
the architecture. the next SHA256RNDS2 needs the result
of the current one as input, so the CPU has to wait until
it is ready. (in Transform 2 for eg, 3 out of every 4 cycles
are wasted doing nothing)

we fill those wasted cycles by computing a second independent
hash alongside the first.

See https://uops.info/html-instr/SHA256RNDS2_XMM_XMM.html
for per-architecture instruction timings.

hashes: Add optimized x86 SHA256d for 64-byte input

Add the three transforms for sha256(sha256(64_bytes))

Transforms 1 & 2 compute the inner `sha256(64_bytes)`:

- Transform 1: 64 bytes already fill the first block (no
padding needed), so we apply 64 rounds of compression
normally.
After T1: state = state + initial_state

- Transform 2: the message schedule at this step is constant
and known in advance (64 bytes of padding), so
we precompute W[i]+K[i] into MIDS and apply 64 rounds (no
schedule expansion needed).
After T2: state = state + saved_T1_state
(state now contains sha256(64_bytes))

- Transform 3 computes sha256(output_of_T1_and_T2). The output
is 32 bytes, so the block contains 32 bytes and the rest is
known padding. we precompute the message
schedule for the known words (w8-w15) into FINS.
After T3: state = state + initial_state
(state now contains the sha256d result)

hashes: use consistent round numbering in sha256 comments

the 1-way ARM and x86 SHA-NI functions used Rounds 0-3 while
the 2-way ARM function used Rounds 1-4 in the comments.

use this consistently everywhere.

hashes: split sha256 crypto int separate files

since we are planning to add other implementations for sha256: 2-way x86 shani,
4-way SSE4.1, and 8-way AVX2, we can split the file so each impl has
its own file without ending up with a single file that is hard to review.

this is just a code move, no logic change.

Add psbt fuzz target

p2p: Implement ExactSizeEncoder for AddrV2Encoder

For encoders, the use of the encoder_newtype_exact macro allows for
the implementation of the ExactSizeEncoder trait. This provides users
with the ability to determine the encoding length of types without
needing to perform the entire encoding process. Since the AddrV2Encoder
can do the necessary calculation in constant time, this trait should
be implemented for it too.

Implement ExactSizeEncoder for AddrV2Encoder.
Add test cases to confirm correct encoding + length calculation for
all types of AddrV2.

key: Add From conversions for references for secret key types

As with the changes to the from_* functions, there should exist From
impls that take references for all From impls that work on secret key
types. This further simplifies working with the non-Copy secret types.

Add From<&TweakedKeypair> for &Keypair, From<&PrivateKey> for Keypair
and From<&TweakedKeypair> for TweakedPublicKey.

key: Make as_inner pub(super) for secret key types

As part of the long-term goal to remove the need to access the inner
secp types for all key types, the secret keys can now have their
inner accessor functions made pub(super). These functions are still
needed for functionality in the key module, but are no longer
necessary in the bitcoin crate or in the wider ecosystem.

Make as_inner pub(super) on PrivateKey and Keypair.

key: Adjust all from_* functions to take refs

The secret key types in bitcoin are no longer Copy. Since some
conversions to public key types take the key types by value, this makes
the use of private keys fairly unergonomic. Except where necessary,
conversion constructors for all key types (that is, from_* functions)
should always take references. This can help avoid costly copies.

Change from_keypair on TweakedPublicKey, from_private_key on
CompressedPublicKey and from_secret_bytes on PrivateKey to all take
references instead of values.

Add panics section to docs