docs: Add a bunch of project management docs
What changed, and why it matters
This commit only adds and edits project planning documentation (markdown files about crate organization, roadmap, coding policy, keys/crypto, and Taproot). No source code, build scripts, tests, or dependencies were changed. There is no security-relevant behavior introduced or fixed.
No security action needed. This is a documentation-only project-management commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff is limited to documentation files under docs/: crates.md, crypto.md, keys.md, policy.md, roadmap.md, taproot.md. It describes future crate-splitting plans, re-export conventions, and roadmap items. No Rust code, Cargo.toml, CI configuration, or cryptographic logic is modified.
Changed components
Inspect captured patch +265 / −1
diff --git a/docs/crates.md b/docs/crates.md
new file mode 100644
index 00000000..f8d51190
--- /dev/null
+++ b/docs/crates.md
@@ -0,0 +1,46 @@
+# rust-bitcoin stack of crates
+
+The `rust-bitcoin` project is in the, very long, process of crate
+smashing. The original single `rust-bitcoin` crate has already been
+broken into a number of pieces and this work is ongoing. Both current
+and future crates are documented here. Future crates typically have an
+entry in [roadmap.md] and likely also a file of their own.
+
+## Current crates
+
+- `addresses`: **Empty** placeholder (see future crates below).
+- `base58`: Bitcoin base58 encoding and decoding (for pre-segwit addresses).
+- `bitcoin`: The `rust-bitcoin` crate.
+- `chacha20_poly135`: ChaCha20 stream cipher with the Poly1305 MAC.
+- `hashes`: Rust Bitcoin hashes library.
+- `internals`: Used internally by crates in this repo.
+- `io`: Rust Bitcoin I/O library (to support `no_std`).
+- `p2p`: Rust Bitcoin peer to peer message types.
+- `primitives`: Rust Bitcoin primitive types.
+- `units`: Rust Bitcoin unit types.
+
+### Crates in our stack but in different repositories
+
+A few crates are in different repositories, primarily because they were either started by different
+people or they have a (slightly) different set of maintainers and/or merge policy.
+
+- `secp256k1`: https://github.com/rust-bitcoin/rust-secp256k1
+- `bech32`: https://github.com/rust-bitcoin/rust-bech32
+- `hex-conservative`: https://github.com/rust-bitcoin/hex-conservative
+- `miniscript`: https://github.com/rust-bitcoin/rust-miniscript
+
+## Future crates
+
+- `addresses`: Bitcoin addresses (see [address.md])
+- `bip-32`: BIP-32 (and maybe BIP-380) support (see [bip-32.md])
+- `psbt`: PSBTv2 support (see [psbt.md])
+- `keys`/`crypto`: Cryptography stuff or maybe just keys (see [keys.md])
+
+## Re-export policy
+
+See `./policy.md`.
+
+[addresses.md]: ./addresses.md
+[bip-32.md]: ./bip-32.md
+[keys.md]: ./keys.md
+[psbt.md]: ./psbt.md
diff --git a/docs/crypto.md b/docs/crypto.md
new file mode 100644
index 00000000..1c3f44b2
--- /dev/null
+++ b/docs/crypto.md
@@ -0,0 +1,65 @@
+# Bitcoin keys / Bitcoin crypto
+
+Either `bitcoin-keys` and just have keys in it or `bitcoin-crypto` and
+have the other stuff from `bitcoin::crypto` in it.
+
+## `secp256k1`
+
+Both `bitcoin-keys` and `bitcoin-crypto` would depend on `secp256k1`.
+
+Other things that use secp directly or indirectly through keys/crypto:
+
+- `addresses` (for keys only)
+- `bip-32` (for keys only)
+- `psbt` for keys and signing
+- Taproot script extension methods
+- `bitcoin::taproot` module (uses secp directly)
+- `bitcoin::sign_message` module (uses secp directly)
+
+Taproot stuff is quite entangled in various places throughout the
+codebase which in turn entangles secp.
+
+## Keys
+
+Public and private keys.
+
+The reason for splitting this out is so that other crates can depend on keys without depending on
+`bitcoin` e.g., `addresses`.
+
+(Note plural for crate name and singular for current module name, in line with what we did for
+`address` module and `addresses` crate.)
+
+Current public types in `bitcoin::cryto::key`:
+
+- `XOnlyPublicKey`
+- `PublicKey`
+- `SortKey`
+- `PubkeyHash`
+- `WPubkeyHash`
+- `CompressedPublicKey`
+- `PrivateKey`
+- `TweakedPublicKey`
+- `TweakedKeypair`
+- `SerializedXOnlyPublicKey`
+- Various error types
+- `TapTweak` trait
+
+### Current obvious complications
+
+Looking at `bitcoin::crypto::key` there are some obvious things that will need fixing.
+
+#### `NetworkKind`
+
+Currently we are using `bitcoin::network::NetworkKind` in `PriviateKey`.
+
+- Used to get the first byte of WIF format
+- Passed to functions that create addresses e.g., `Address::p2pkh(key, network)`
+
+#### `ScriptBuf`
+
+Possibly ok if we have a dependency on `primitives`. Only used for sciptcode.
+
+#### Taproot stuff
+
+`TapNodeHash` and `TapTweakHash` are used to implement the `TapTweak` trait on `UntweakedPublickey`
+and `UntweakedKeypair`.
diff --git a/docs/keys.md b/docs/keys.md
new file mode 100644
index 00000000..012c2a7e
--- /dev/null
+++ b/docs/keys.md
@@ -0,0 +1,64 @@
+# Bitcoin keys / Bitcoin crypto
+
+Either `bitcoin-keys` and just have keys in it or `bitcoin-crypto` and
+have the other stuff from `bitcoin::crypto` in it.
+
+For now we use term 'keys', above is an open question.
+
+## On `secp256k1`
+
+Both `bitcoin-keys` and `bitcoin-crypto` would depend on `secp256k1`.
+
+Other things that use secp directly or indirectly through keys/crypto:
+
+- `addresses` (for keys only)
+- `bip-32` (for keys only)
+- `psbt` for keys and signing
+- Taproot script extension methods
+- `bitcoin::taproot` module (uses secp directly)
+- `bitcoin::sign_message` module (uses secp directly)
+
+## Related to keys
+
+Public and private keys.
+
+The reason for splitting this out is so that other crates can depend on keys without depending on
+`bitcoin` e.g., `addresses`.
+
+(Note plural for crate name and singular for current module name, in line with what we did for
+`address` module and `addresses` crate.)
+
+Current public types in `bitcoin::cryto::key`:
+
+- `XOnlyPublicKey`
+- `PublicKey`
+- `SortKey`
+- `PubkeyHash`
+- `WPubkeyHash`
+- `CompressedPublicKey`
+- `PrivateKey`
+- `TweakedPublicKey`
+- `TweakedKeypair`
+- `SerializedXOnlyPublicKey`
+- Various error types
+- `TapTweak` trait
+
+### Current obvious complications
+
+Looking at `bitcoin::crypto::key` there are some obvious things that will need fixing.
+
+#### `NetworkKind`
+
+Currently we are using `bitcoin::network::NetworkKind` in `PriviateKey`.
+
+- Used to get the first byte of WIF format
+- Passed to functions that create addresses e.g., `Address::p2pkh(key, network)`
+
+#### `ScriptBuf`
+
+Possibly ok if we have a dependency on `primitives`. Only used for sciptcode.
+
+#### Taproot stuff
+
+`TapNodeHash` and `TapTweakHash` are used to implement the `TapTweak` trait on `UntweakedPublickey`
+and `UntweakedKeypair`.
diff --git a/docs/policy.md b/docs/policy.md
index f38a50a9..c28cb9df 100644
--- a/docs/policy.md
+++ b/docs/policy.md
@@ -47,6 +47,76 @@ use crate::prelude::*; // *NOT* OK
use crate::prelude::{DisplayHex, String, Vec} // OK
```
+## Re-exports
+
+Types should _not_ be re-exported unless it is _really_ helpful. I.e., we considered re-exporting
+types from modules where they appear in the public API but decided against it.
+
+### pub extern crates
+
+Any crate `foo` which exposes a type from crate `bar` MUST publicly re-export `bar` crate at the
+root.
+
+
+For example:
+
+```rust
+/// Re-export the `hex-conservative` crate.
+pub extern crate hex;
+```
+
+Note, can use this exact doc format.
+
+### Special treatment of `bitcoin`, `primitives`, `units`
+
+`bitcoin`, `primitives`, and `units` should each be a superset of the crates below.
+
+E.g for any `units::Foo`, there will be a `primitives::Foo`, and `bitcoin::Foo`. This goes for all
+types and modules.
+
+For these three crates:
+
+- Non-error re-exports use `doc(inline)`.
+- Error re-exports use `doc(no_inline)`.
+- Error types that are directly in the API are re-exported.
+- Other error types are available in an `error` module.
+
+For example in `units`:
+
+```rust
+
+pub mod foo {
+ // SomeError is 'directly' in the API but FooError is not.
+ pub use self::error::SomeError;
+
+ /// A FooBar type.
+ pub struct FooBar { ... };
+
+ /// Some function.
+ pub some_function() -> SomeError {
+ // Example rror logic
+ SomeError::Foo(FooError { ... })
+ }
+
+ pub mod error {
+ /// Example error used 'directly' in the public API.
+ pub enum SomeError { ... };
+
+ /// Abstracts the details of a foo-related error.
+ pub struct FooError { ... };
+ }
+}
+```
+
+Then in `primitives` (and in `bitcoin`) in `lib.rs`:
+
+```rust
+#[doc(inline)]
+pub use units::{foo, FooBar};
+#[doc(no_inline)]
+pub use units::foo::SomeError;
+```
+
## Return `Self`
Use `Self` as the return type instead of naming the type. When constructing the return value use
@@ -89,7 +159,6 @@ impl From<foo::Error> for LongDescriptiveError {
}
```
-
## Errors
Return as much context as possible with errors e.g., if an error was encountered parsing a string
diff --git a/docs/roadmap.md b/docs/roadmap.md
index 0e9b170d..66e8d9a9 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -1,6 +1,8 @@
# `rust-bitcoin` repository roadmap
* ~Release `units v1.0.0-rc.0`~
+* Create `bitcoin-consensus-encoding` `v0.1.0` (see [#4782])
+* Release `bitcoin-consensus-encoding` `v1.0.0-rc.0`
* Release `primitives v1.0.0-rc.0`
* Implement script tagging
* Add support for consensus encoding to `primitives`
@@ -8,8 +10,10 @@
* Split out an address crate (see [addresses.md])
* BIP-32 and BIP-380 (see [bip-32.md])
* PSBTv2 (see [psbt.md])
+* Split out a crypto/keys crate. Includes discussion of `secp256k1`. See [crypto.md]
* Make it possible for `bitcoin` to depend on `miniscript` (see [#2882])
- Requires [bip-32.md] and [psbt.md]
+* Disentangle and stabalize Taproot stuff (see [taproot.md])
## RC cycle
@@ -18,5 +22,7 @@ API of the 1.0 crates. At a minimum this will be 6 months from the release `prim
[addresses.md]: ./addresses.md
[bip-32.md]: ./bip-32.md
+[crypto.md]: ./crypto.md
[psbt.md]: ./psbt.md
+[taproot.md]: ./taproot.md
[#2882]: <https://github.com/rust-bitcoin/rust-bitcoin/issues/2882>
diff --git a/docs/taproot.md b/docs/taproot.md
new file mode 100644
index 00000000..448c6b52
--- /dev/null
+++ b/docs/taproot.md
@@ -0,0 +1,14 @@
+# Taproot
+
+The `Taproot` code was left in `bitcoin` during the creation of
+`primitives` because it is not as close to stable.
+
+Furthermore the Taproot stuff is quite entangled in various places
+throughout the codebase which in turn entangles the `secp256k1`
+dependency.
+
+We likely need to tease apart the Taproot stuff and disentangle the
+bits we aren't yet willing to stabalize. Because of the entanglement
+this effects various other crates (`psbt`, `crypto`) as well as the
+stabalization efforts of script extension methods.
+
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.