rust-bitcoin

p2p: add V1MessageHeader constructor

Adds a constructor to `V1MessageHeader` which also computes the 4 byte
checksum as defined by protocol docs. This constructor is used to
compose a network header that can be transmitted over the network stream.

Any network message (payload) must be directly preceded in the network
stream by a header. In that way, the receiving client knows how many
bytes to read, and what message to interpret.

A working code example might be a Pong response:
```
let message = bitcoin_p2p_messages::message::Pong(nonce);
let msg_header = V1MessageHeader::new(magic, &message, "pong");

// write the header to stream
encoding::encode_to_writer(&msg_header, &stream);

// write message to stream
encoding::encode_to_writer(&message, &stream);
```

Note that Currently, CommandString wraps a Cow<'static, str>, so the
lifetime of `cmd` must match the static lifetime. However, the protocol
documents define this as a 12 byte field, so this can and should be
changed at some point.

The fields defined in `V1MessageHeader` is the first four fields of a
message structure. An example given in the docs of message header is
given as:

```
Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
35 8d 49 32 - payload checksum (byte order)
```

crypto: Change to_public_key to return FullPublicKey

In general, modern bitcoin code should be using either the compressed
FullPublicKey or the XOnlyPublicKey. Users should try to avoid the
legacy optionally-compressed public key. To this end, the types were
renamed. To further consolidate this, the to_public_key methods
throughout the key module should also return FullPublicKey, with the
existing behaviour relegated to new to_legacy_public_key.

Change all to_public_key functions to return FullPublicKey and
introduce corresponding to_legacy_public_key functions to return
LegacyPublicKey where necessary.

fuzz: add max_total_time option to fuzz.sh

bitcoin: cut down on exact_features test matrixes

The Github CI runner is timing out when running all the feature sets
on the older MSRV compiler. The current list of exact_features in the
bitcoin crate was a conserative "include everything" when we switched
over to cargo-rbmt. This cuts it down ~50% and focuses on core
interactions we want to always cover. This puts more responsibilites on
cargo-rbmt's random feature subsets it runs on every commit.

Add fuzz target comparing consensus encoding to bitcoin 0.32

Since bitcoin 0.32, consensus encoding has been rebuilt from the ground
up with the consensus_encoding crate. In order to confirm that it
functions identically to the original encoding implementations, the
two should be differentially fuzzed.

Introduce a fuzz target that compares encodings using serialize from
bitcoin 0.32 against encode_to_vec from consensus_encoding.

Introduce CI action to enforce encodable fuzzing

With the introduction of the Encodable differential fuzz target, it's
important to ensure that all new implementations of Encodable types
are compared against existing implementations from bitcoin 0.32.

Add Encodable-coverage action to check compare_consensus_encoding
target for inclusion of all Encodable types on branch and bitcoin 0.32.

Assisted-by: Claude Opus 4.5

crypto: Remove unused test from ecdsa

In ecdsa, the write_serialized_signature test was used to test the
serialize_to_writer method on the ecdsa::Signature. Since this was
removed as part of the bitcoin-io dep removal, the test should also
be removed.

Remove write_serialized_signature test case from ecdsa tests module.

Re-name consensus_encoding main traits

When we did the first implementation of the `consensus_encoding` crate
we used the same names for the public traits as the old encoding code.

In hindsight we should have used the more Rusty terms `Encode` and
`Decode` instead of `Encodable` and `Decodable`.

Bonus points the new names are easier to spell.

Do trivial-ish rename. Leave the `EncodableBytesIter` as is because
the fix to it is non-trivial. Leave the old encoding traits as they
are because they are destined for the grave very soon anyways.

crypto: Bump version to 0.2.0

Bump the `crypto` version. Update the dep in `bitcoin` and add an
explicit version number in `taproot-primitives`.

In preparation add a changelog entry, bump the version number, and
update the lock files.

Delete psbt module

In #6055 we deprecated the `psbt` module on the `0.32.x` branch. Now
we can delete it from master.

### Context

Development of the PSBT has moved to a separate crate. Hosted on the
new Forgejo instance at:

https://git.rust-bitcoin.org/rust-bitcoin/rust-psbt

Crate name is `psbt-v2` because it has initial support for PSBTv2. The
crate also includes all code from the `0.32.x` branch (as well as
miniscript code). In other words the crate is a drop in replacement
for the `Psbt` type and its functionality.

During release of `psbt-v2 v0.3.0` we attempted to ensure feature
parity with `0.32.x` since the actual migration was done a while back.

The road map for dev of `psbt-v2` is loosely:

- Improve PSBTv2 stuff
- Continue work on supporting Silent Payments
- Use crate as a test bed for the process of upgrade of `bitcoin 0.32.x`


Exact strategy of the last point is being worked on. We are
investigating creating a bunch of step-by-step releases to help the
process. To prove (and develop) the process we plan on using:

- miniscript
- psbt-v2
- corepc

fuzz: Migrate p2p fuzz targets to new encoding

p2p: remove deprecated encoders in V1NetworkMessage constructor

`payload.consensus_encode()` is deprecated. Replace with
newer sans/IO `hashes::encode_to_engine()`.

Also, updated the doc comment now that encode no longer has a panic
path.

hashes: Add x86 AVX2 8-way dispatch

add dispatcher that handles 8-way

hashes: fold 8-way AVX2 SHA256d into round! macro

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

refactor, no behavior change.

hashes: Add 8-way AVX2 SHA256d for 64-byte input

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

AVX2 uses 256-bit registers, so we can pack eight 32-bit words into
each register and compute 8 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).

Run the formatter

Use drain instead of flush

The term 'flush' has meaning already in respect to a std writer thus
impiles that a function with 'flush' in the name would call
`writer.flush()` but we do not.

After debate we reached consensus on the verb 'drain' to replace
'flush'.

Rename all 'flush_to_writer' functions to be `drain_to_writer`
repository wide. To keep our API uniform also re-name `flush_to_vec`
to be `drain_to_vec`.

Move import

There is an unrelated lint warning, no clue how it started showing up
but its a trivial fix. Move import from one feature gated scope to
another.

crypto: Remove bitcoin-io dependency

With the removal of the io-dependent functions from the key and
signature types, the bitcoin-io dependency can be entirely dropped from
the crypto crate.

Remove bitcoin-io dependency from manifest and update lock files.
Remove io re-export from crate root.

Remove io methods on public key types

The read_from and write_into functions on the public key types rely on
the bitcoin-io Read and Write traits. Since we want to remove the
dependence on io for the crypto crate, these methods must also be
removed. With the Serialized* types, the write_into methods are trivial
to replace inline.

Remove read_from and write_into methods from public key types and test
case for them.

hashes: change engine parameter to be mutable reference

Allow engine parameter to be less restrictive in use. By changing the
parameter to `&mut`, the calling function no longer needs give up
ownership of engine.

The return value is removed since the caller can simply use existing
ownership of variable instead of the return value.

hashes: Add 4-way dispatcher

add x86 sha256d dispatcher that handles 4-way SSE4.1

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.