AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 21 Bitcoin

Merge rust-bitcoin/rust-bitcoin#6894: Harden `Copy` policy and apply to all pre-1.0 crates

Public commit record

What the developer wrote

Authored by Andrew Poelstra

100/100 · Strong
Merge rust-bitcoin/rust-bitcoin#6894: Harden `Copy` policy and apply to all pre-1.0 crates

836624fc736cff9382923ae3b512bf6a17aecc55 chacha20_poly1305: drop Copy from Error (satsfy (Renato Britto))
642d545046f5f48ec26e7d4ef9dc28fd38fdec74 p2p: drop Copy from error types (satsfy (Renato Britto))
8c2e6b1841211cff624d2492276066b8bcc1c0db key_expression: drop Copy from bip32 error types (satsfy (Renato Britto))
61677cc71f0e35d2d6bcf3efcee5f969b634fa00 units: drop Copy from OutOfRangeError (satsfy (Renato Britto))
dae6356f31b717a9dce7bdc71dd0954bd86e07a5 policy: say when an error type derives Copy (satsfy (Renato Britto))

Pull request description:

I'm reviewing every trait in units for 1.0. We try to use `Copy` on rust-bitcoin types, but I claim that the errors should not use it.

The old criteria, "`Copy` if and only if not `non_exhaustive`", demands `Copy` on parse errors such as `ParseIntError`, which hold their input as a String and cannot derive it, and forbids it on `NumOpError`, which `NumOpResult` requires, and also misses important observations made previously in rust-bitcoin's history about the `Copy` trait (read the brief history below).

An error that implements `Copy` cannot later be updated to include, say, a `String`, so every `Copy` put into an error is a public commitment that would require a breaking change later, making it valuable to remove before 1.0. The codebase tends to the minimization of Copy usage on errors already, 30+ changes would be required in units alone to satisfy the existing rule in policy.md atm.

The only exception for using `Copy` are in errors that are a field of a type that derives `Copy`. That situation requires `Copy`, e.g.:
```rs
#[derive(Copy, Clone)]
pub enum NumOpResult<T> {
Valid(T),
Error(NumOpError), // a field of a Copy type, so NumOpError must be Copy
}
```

A brief history of `Copy` trait discussions on rust-bitcoin:

- [#843 PR checklist](https://github.com/rust-bitcoin/rust-bitcoin/issues/843): project adds checklist item for every public type and qualifies with "does not implement traits we could regret (mainly `Copy`, `Eq`, `Ord`, `PartialOrd`)".
- [#1127 Add policy section](https://github.com/rust-bitcoin/rust-bitcoin/pull/1127): "error types should not commit to implementing traits they may not be able to implement in the future, especially `Copy`". Turned into our present "if and only if".
- [#3879 Remove Copy from PushBytesError](https://github.com/rust-bitcoin/rust-bitcoin/pull/3879): "it makes the code less maintainable because we must commit to implementing `Copy`".
- [#4076 Derive Copy for NumOpResult](https://github.com/rust-bitcoin/rust-bitcoin/pull/4076): PR makes `NumOpError` `Copy` because the container needs it. The one exception on our new policy.
- [#6347 units: Clean up the api tests](https://github.com/rust-bitcoin/rust-bitcoin/pull/6347): `Copy` asserted on the `Enums`, errors excluded.


ACKs for top commit:
apoelstra:
ACK 836624fc736cff9382923ae3b512bf6a17aecc55; successfully ran local tests


Tree-SHA512: 3569d75dd11f84b6b9afe1806f2fb61a38d41720eaf5083bab9934019468d1caae3a1a861253b6de5599ad534d2306ba18a8009db9ef042987723afeb9afb95f
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit removes the automatic `Copy` trait from several public error types in the rust-bitcoin library and updates the project's written policy to discourage `Copy` on error types. `Copy` is a Rust trait that lets values be duplicated silently by the compiler. The team wants to drop it from errors because once an error type promises to be `Copy`, it can never later hold a `String` or other non-copyable data without a breaking change. This is a forward-looking API-cleanup change, not a fix for an active security bug. It also changes some error methods from taking `self` by value to taking `&self`, which is a minor API adjustment.

Recommended action

No immediate action required. Library consumers who depend on these error types being `Copy` will need to update their code to clone explicitly when upgrading. Reviewers should confirm that no remaining public error types unintentionally retain `Copy` where the new policy forbids it, and that CI passes after the API change.

Security signals we found

01

API hardening: removes `Copy` from public error types to preserve future flexibility

02

Policy update: docs/policy.md now explicitly discourages `Copy` on error types

03

No vulnerability fix: change is defensive/preventive, not reactive to a disclosed issue

04

No unsafe code, no cryptographic changes, no input parsing changes

Risk score

Why this scored 21/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 9/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.