rust-bitcoin

[to squash] remove some old doccomments from consensus_encoding

Add empty consensus_encoding crate

Add an empty `consensus_encoding` crate so we can grab the name on
crates.io

## Aims of the crate

This crate will hold the encoding traits and be depended on by
`units`, `primitives`, and `bitcoin` where implementations of the
traits will live.

All this will be feature gated so users can opt in. This nicely
bypasses the `Read`/`Write` vs `BufRead`/`BufWrite` problem because
later we can add an additional crate for the buffered stuff and users
can opt in to the one they want to use.

This crate will be no-std by default and depend on `bitcoin-io` for
I/O.

First release will just bring everything as it is from `bitcoin` over
here, then we can implement the traits in the various other crates,
then iterate - like its our job.

primitives: Use new import policy

Now we want to only import using crate re-exports if possible in
`bitcoin` and `primitives`. We fixed `bitcoin` already, now do
`primitives`.

Fix typos in deprecated method names

- Fix deprecation note: from_hex_string_no_length_prefix() → from_hex_no_length_prefix()
- Fix comment in script example: from_hex_string_prefixed → from_hex_prefixed

Add a unit test for `sha3`

All tests are sourced from NIST via the Cryptographic Algorithm
Validation Program. They include namely:
1. the null data case
2. Input cases just above, equal, and below the rate block in bytes
3. Additional randomly sized vectors

ref: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/secure-hashing

Add the SHA3-256 hash function

There is a substantial amount of bitcoin listening nodes only reachable
by Tor. This is backed by some relatively old research, but I would
imagine this remains the case today. When it comes to peer-to-peer
gossip, Tor nodes are reachable by a 32-byte ed25519 public key. In
practice, most applications will run a Tor daemon, and other
applications will communicate with Tor via a Socks5 proxy. With Socks5,
you may connect to an IPv4, IPv6, or domain.

The problem is to go from Tor public key to onion address (domain), you
must take a Sha3-256 hash of a public key and some concatinated data. In
effect this makes Tor nodes unreachable for those that do not want to
use `RustCrypto` or god forbid the Arti project.

Here I propose we add this hash to `bitcoin_hashes`. While it is not
explicitly a hash used in bitcoin, many bitcoin nodes use Tor, and more
importantly, accept inbound connections using Tor. Others are of course
free to use this hash however their heart desires.

As far as implementation, from a high level, the hash is a number of
permutation operations on a state array of 1600 bits. These bits can be
visualized/represented as a 5x5 matrix of 64-bit "lanes." I will leave
the rest to the code comment in the file. The Keccak team designed this
function to be robust theoretically but easy to implement. Each of these
lanes may be mutated directly, and I also try to abuse `for_each` to
give SIMD hints. To review the implementation, you may follow the
psuedo-code provided by the Keccak team, linked below.

ref
Psuedo-code: https://keccak.team/keccak_specs_summary.html
Full Keccak reference: https://keccak.team/files/Keccak-reference-3.0.pdf
Tor spec: https://spec.torproject.org/rend-spec/encoding-onion-addresses.html
Tor post: https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-dev/2017-January/011816.html
P2P data: https://github.com/virtu/p2p-metrics

Update roadmap.md

Add encoding section to primitives 1.0.0 doc

Consensus encoding work is ongoing, add a quick and dirty section
linking to the discussion and initial work.

doc: Document primitives v1.0.0

`primitives 1.0.0-rc.0` may or may not be done by the summit in
Nashville in 5 weeks.

- If it is: this document can serve as the first place folk look to
understand any design decisions we made and/or upgrade
considerations.
- If it is not: this document can serve as the canonical list of whats
left to do (any hard bits anyways).

Add a design document for the upcoming `primitives 1.0.0` release.

bitcoin: add `push_int` and friends to `ScriptBuf`

Move the implementations of `push_int`, `push_int_non_minimal`, and
`push_int_unchecked` to `ScriptBuf` with copies of their current
documentation and make `script::Builder` call them.

bitcoin: add test for `push_int` with largest and smallest valid numbers

docs: Add clause to import policy section

CI: Enforce policy

Recently we have started documenting repository coding policy in
`docs/policy.md` to help contributors.

Introduce a script that can be used to enforce the policy rules. At
this stage only enforce a subsection of import statement policy.

units: Do not export hidden macros

These macros are no longer used outside of `units`. Lets not export
them - they are doc hidden already so this is not a breaking change.

With this applied there are no more exported macros in `units`.

Re-name units::parse to parse_int

The `pares` module now only does one thing, parses strings (hex or
otherwise) to get integers. It can be re-named to `parse_int` to
better describe this and also so that when re-exported in `primitives`
and `bitcoin` the name is not misleading but nicely descriptive.

Rename TxOut::value to amount

There is a draft naming BIP [0] and in it `amount` is favoured over
`value`. Since we are attempting to do a 1.0 stable release now is the
time to lock things like this.

Also consensus reached on this re-name in #1824

[0] https://github.com/murchandamus/bips/blob/2022-04-tx-terminology/bip-tx-terminology.mediawiki

remove some pointer casts

I grepped the codebase for `as \*` and found a few places where we were
doing explicit pointer casts but we could've been using std methods. The
methods are safer because they don't allow changing mutability (unless
we use cast_const or cast_mut, which don't allow changing the type).

There are a few instances remaining where we cast to pointers to unsized
types. These are actually fat raw pointers and they don't have std
methods. Now they stand out because of the use of `as *`.

This commit might require a bit of thought to review, and it turns out
it has nothing to do with the MSRV bump (which gave us cast_const and
cast_mut, but actually we don't use those, thankfully..).

As a bit of trivia, though, the new cast_mut and cast_const methods were
originally proposed and implemented by our own Kixunil:

https://github.com/rust-lang/rust/pull/92657

clippy: fix new clippy links

There is one `is_some_and` usage, but everything else is about using the
new `div_ceil` method. I didn't look closely at any of these but there were
a lot of them and I'll bet at least one was actually a panic bug that's
fixed now.

internals: update MSRV to 1.74

...and delete all conditional compilation based on earlier MSRVs.

revert #4838 and #4847 using div_ceil

In #4838 we used saturating addition to simulate `div_ceil`, which gives
incorrect results on extreme values but at least doesn't panic. Similar
in the followup PR #4847. (These aren't detected by clippy, but I remember
them.)

docs: fix grammar issues

update MSRV to 1.74 everywhere except in internals

If I update it in internals, our uses of `rust_version!` with values below
1.74 break. In particular the cond_const! macro breaks. So I will do that
in the next commit, so the diff for this one is simple.

We may want to put some work into getting a single source of truth here...
I had to change this constant in 29 files, plus internals/Cargo.toml.

docs: fix typos

Automated update to Github CI to rustc nightly-2025-08-29

docs: remove redundant "a" in CONTRIBUTING.md