We have a convention in `rust-bitcoin` to use external crates directly
when importing them not via `crate::foo`.
Update all the import paths for `io` to use this form.
fcc4c40a1c Rename from_vb_const (yancy)
Pull request description:
The new function is more clear because the purpose of the function is to return a value that doesn't need to be unwrapped. The current MSRV does not allow unwrap() in const context.
ACKs for top commit:
apoelstra:
ACK fcc4c40a1c
Kixunil:
ACK fcc4c40a1c
Tree-SHA512: 62bbd61800e9f29768d884dbe3bca14fea9b51b8f413131e0f29bfc0f0d0e20631d30489e078cc948f2dba0c5d7d9d7c229b4bb7187faef23083a88337efb6a6
The new function is more clear because the purpose of the function is to
return a value that doesn't need to be unwrapped. The current MSRV does
not allow unwrap() in const context.
Its not immediately obvious why we nest the whole `io` code in an `io`
submodule within `lib.rs`. As far as I can tell we can inline it and
re-export from `rust-bitcoin` same as we do for our other dependencies.
This change would effect other users of the crate but since the `io`
crate is unreleased this effects no-one except us.
In preparation for inlining the `io` molule, move the public macros to a
private `macros` module.
Includes removal of the public re-export of `std` as `_std` - flaggin
this because I do not understand why it is here in the first place, we
can use `std::io::Write` in code that is feature gated on "std".
761de886be Remove imports of TryFrom and TryInto (Tobin C. Harding)
4d5415f835 Add rust-version to the workspace manifests (Tobin C. Harding)
a41e978855 Update to edition 2021 (Tobin C. Harding)
d9cc724187 Bump MSRV to Rust version 1.56.1 (Tobin C. Harding)
Pull request description:
Rust version 1.56.0 introduced edition 2021. Shortly afterwards, on October 21 2021 Rust version 1.56.1 was released.
Debian stable is currently shipping `rustc 1.63.0`. Our stated MSRV policy is: In Debian stable and at least 2 years old. Therefore our MSRV policy is met by Rust version 1.56.1 and we can strat to bump our MSRV org wide. Start by bumping the `rust-bitcoin` and `hashes` MSRV to Rust 1.56.1
Start by bumping the `rust-bitcoin` and `hashes` MSRV to Rust 1.56.1, includes:
- Update docs.
- Update CI and remove pinning.
- Update the build files and remove now stale cfg attributes rust_v_1_x for values less than the new MSRV.
- Use new `IntoIterator` for arrays so we no longer need to allocate a vector to iterate.
Links:
- https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html
- https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
- https://packages.debian.org/stable/rust/rustc
ACKs for top commit:
Kixunil:
ACK 761de886be
apoelstra:
ACK 761de886be
Tree-SHA512: 3a81c8bfa37d8cec0ec794f516f014da67ae8e437decf149c9681aa547885acac0ee07ea2c0f42e4f6bfd6f7ed1695fcf4747f53cc50e5f4e70ce3fe7bcba4e9
fa104aefa5 bitcoin: Add signing examples (Tobin C. Harding)
Pull request description:
Add two signing examples to showcase signing a simple one input two output transaction using both segwit v0 outputs and taproot outputs.
This patch is the result of the recent rust-bitcoin TABConf workshop, with bug fix by Sanket, updated to use APIs from tip of master branch.
This code, depending on v0.30.0 is what was added to the cookbook.
ACKs for top commit:
realeinherjar:
ACK fa104aefa5
apoelstra:
ACK fa104aefa5
Tree-SHA512: ce0d5b8291c94387c68b5e1cf740d3267fc00c997af5b96f5be525f348140d9a9af17ab66d556990f09bf081a5a812374cb633ea276100c7c21f218b85eae3fd
f41ebc2149 Add test for input weight predictions (conduition)
4514a80a23 Fix the InputWeightPrediction constants for DER signatures (conduition)
b5ce219c62 add weight method to InputWeightPrediction (conduition)
Pull request description:
The `P2WPKH_MAX` constant assumed DER signatures in the witness have a max length of 73. In practice, their maximum length is 72, because [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) forbids nodes from relaying transactions which contain non-canonical ECDSA signatures (i.e. TX sigs must have an $s$ value of less than $\frac{n}{2}$).
This means $s$ is never encoded with a leading zero byte, and the signature as a whole never exceeds 72 bytes in total encoded length. The `ground_p2wpkh` function was already correct; only the constant needed to be corrected.
Technically 73 bytes *is* the upper limit for signatures, as nothing forbids miners from including such non-standard transaction signatures in blocks, but for the purposes of fee estimation and input weight prediction, 72 is the number which 99.9% of implementations should use as their ceiling. We already use it as the ceiling for the `ground_p2wpkh` function - `ground_p2wpkh(0)` returns a prediction which uses a witness signature of length 72.
Reference:
- https://bitcoin.stackexchange.com/questions/77191/what-is-the-maximum-size-of-a-der-encoded-ecdsa-signature
- https://bitcoin.stackexchange.com/questions/106435/are-high-s-ecdsa-signatures-forbidden-in-segwit-witnesses
- https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
To enable testing, I added a `weight()` method to `InputWeightPrediction` and made it public but i'm not sure whether it has a use-case. Let me know if I should make it private instead.
ACKs for top commit:
tcharding:
ACK f41ebc2149
apoelstra:
ACK f41ebc2149
Tree-SHA512: 10e837bad9881c0efebb0598eaefd4ab039f2a6ececead75a68e253d84f5e85cb30496a6069eee8dfe9714773f3aa23cfe373f5d88d1c5609e1b1be1ff142e37
Rust version 1.56.0 introduced edition 2021. Shortly afterwards, on
October 21 2021 Rust version 1.56.1 was released.
Debian stable is currently shipping `rustc 1.63.0`.
Our stated MSRV policy is: In Debian stable and at least 2 years old.
Therefore our MSRV policy is met by Rust version 1.56.1 and we can strat
to bump our MSRV org wide.
Start by bumping the `rust-bitcoin` and `hashes` MSRV to Rust 1.56.1,
includes:
- Update docs.
- Update CI and remove pinning.
- Update the build files and remove now stale cfg attributes rust_v_1_x
for values less than the new MSRV.
- Use new `IntoIterator` for arrays so we no longer need to allocate a
vector to iterate.
Links:
- https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html
- https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html
- https://packages.debian.org/stable/rust/rustc
75c490c60f hashes: Remove default features from schemars dep (Tobin C. Harding)
1105876423 Remove whitespace character from string (Tobin C. Harding)
a6d7d542ab bitcoin:: Remove dev dependency serde_derive (Tobin C. Harding)
Pull request description:
Done while investigating removal of `serde_derive` dependency.
- Patch 1: Do trivial dev-dep removal
- Patch 2: Manually implement `JsonSchema` and remove default dependencies from "schemars" dependency (transitively depends on `serde_derive`)
ACKs for top commit:
apoelstra:
ACK 75c490c60f
Tree-SHA512: aab5bd622a76fc24259933af2f20f863d20c8ccf6e69e68246c374266c540e483ced8a769532582a184b922996857db7320a6b08ae9b5b95503eac752ef9d301
321d3923b8 Add from_vb_const function (yancy)
Pull request description:
This function is can be used to construct a Weight type from_vb in const context. Note I don't think it's possible to test the panic case since it's a compile time error work around currently to panic.
ACKs for top commit:
tcharding:
ACK 321d3923b8
apoelstra:
ACK 321d3923b8
Tree-SHA512: dc11409f0e3079400da261a8c9f580ef0527b77643ce1a5dda65c0975db19c2f2da46ac693e6a2bf49e0105b8b096e1ee51f09f5d1c78d634e4e274d7467ee05
The P2WPKH_MAX constant assumed DER signatures in the witness have
a max length of 73. However, their maximum length in practice is 72,
because BIP62 forbids nodes from relaying transactions whose ECDSA
signatures are not canonical (i.e. all sigs must have an s value of
less than n/2). This means s is never encoded with a leading zero
byte, and the signature as a whole never exceeds 72 bytes in total
encoded length. The ground_p2wpkh function was already correct;
only the constant needed to be corrected.
Currently we derive `impl Debug for PrivateKey` for "std" builds and
manually implement an obfuscated version for "no-std" builds. Since
we enable the `hashes` feature of `rust-secp` this is unnecessary
because secp takes care of obfuscating the secret for us.
We are trying to get rid of the `serde_derive` dependency from our
dependency graph.
Stop using default features for the `schemars` dependency which includes
`schemars_derive` which depends on `serder_derive`.
Manually implement `schemars::JsonSchema` instead of deriving it.
We do not need this dependency because we can get the serde derives
directly from `serde`.
diff --git a/bitcoin/Cargo.toml b/bitcoin/Cargo.toml
index 3868bd08..db7fb322 100644
--- a/bitcoin/Cargo.toml
+++ b/bitcoin/Cargo.toml
@@ -53,7 +53,6 @@ actual-serde = { package = "serde", version = "1.0.103", default-features = fals
[dev-dependencies]
serde_json = "1.0.0"
serde_test = "1.0.19"
-serde_derive = "1.0.103"
bincode = "1.3.1"
[target.'cfg(mutate)'.dev-dependencies]
add371d263 Remove `core2` dependency entirely (Matt Corallo)
b7dd16da99 [IO] Use our own io::Error type (Matt Corallo)
c95b59327a Explicitly use `std::io::Error` when implementing `std` traits (Matt Corallo)
9e1cd372cb Use `io::Error::get_ref()` over `std::error::Error::source()` (Matt Corallo)
3caaadf9bb [IO] Replace the `io::Cursor` re-export with our own `Cursor` (Matt Corallo)
141343edb4 [IO] Move to custom `Read` trait mirroring `std::io::Read` (Matt Corallo)
7395093f94 Stop relying on `Take`'s `by_ref` method (Matt Corallo)
2364e1a877 Stop relying on blanket Read impl for all &mut Read (Matt Corallo)
6aa7ccf841 [IO] Replace `std::io::Sink` usage with our own trivial impl (Matt Corallo)
7eb5d65bda [IO] Provide a macro which implements `io::Write` for types (Matt Corallo)
ac678bb435 [IO] Move to custom `Write` trait mirroring `std::io::Write` (Matt Corallo)
5f2395ce56 Add missing `?Sized` bounds to `io::Write` parameters (Matt Corallo)
2348449d2a Stop relying on `std::io::Write`'s `&mut Write` blanket impl (Matt Corallo)
5e0209569c Use `io::sink` rather than our custom `EmptyWrite` utility (Matt Corallo)
a0ade883b6 [IO] Move io module into selected re-exports (Matt Corallo)
27c7c4e26a Add a `bitcoin_io` crate (Matt Corallo)
Pull request description:
In order to support standard (de)serialization of structs, the
`rust-bitcoin` ecosystem uses the standard `std::io::{Read,Write}`
traits. This works great for environments with `std`, however sadly
the `std::io` module has not yet been added to the `core` crate.
Thus, in `no-std`, the `rust-bitcoin` ecosystem has historically
used the `core2` crate to provide copies of the `std::io` module
without any major dependencies. Sadly, its one dependency,
`memchr`, recently broke our MSRV.
Worse, because we didn't want to take on any excess dependencies
for `std` builds, `rust-bitcoin` has had to have
mutually-exclusive `std` and `no-std` builds. This breaks general
assumptions about how features work in Rust, causing substantial
pain for applications far downstream of `rust-bitcoin` crates.
This is mostly done, I'm still finalizing the `io::Error` commit at the end to drop the `core2` required dep in no-std, but its getting there. Would love further feedback on the approach or code-level review on these first handful of commits.
ACKs for top commit:
tcharding:
ACK add371d263
apoelstra:
ACK add371d263
Kixunil:
ACK add371d263
Tree-SHA512: 18698ea8b1b65108ee0f695d5062d2562c8df2f50bf85d93442648da3b35a4184a5d5d2a493aed0adaadc83f663f0cd2ac735c34941cc9a6fa58d826e548e091
9282cc4dad Implement standard conversions `Network`->`Params` (Martin Habovstiak)
9a8694fae5 Add `params` method to `Network` (Martin Habovstiak)
Pull request description:
Writing `network.params()` is less annoying than `Params::network()`, so this adds it. Making it return a static could also improve performance.
Didn't do `Params` -> `Network` conversions because of #2173
ACKs for top commit:
tcharding:
ACK 9282cc4dad
apoelstra:
ACK 9282cc4dad
Tree-SHA512: 6455956fd2c937b7212c9bab6ac7cfa05fb99b5da955f4f6690d7056cbe3902a3dadf94352c76b6866655b2e34a936191362a1cc81b33a5b252dd21dbc84d7b6
3bebecc7ea Add policy section to docs (Tobin C. Harding)
Pull request description:
In an effort to consolidate knowledge spread out over time in various places on GitHub add a `Policy` section to `CONTRIBUTING.md`.
Add initial sections on import statements, errors, rustdocs,attributes, and licensing.
ACKs for top commit:
apoelstra:
ACK 3bebecc7ea
Kixunil:
ACK 3bebecc7ea
Tree-SHA512: fb1afd220a0afae962cd9c7a01df7d440eaa1406b446765af209e3b7840b36aa8a1254d57f9ff0c3783479111470828da3c76b5858ce5969519c96cdba71c7f3
c745c97e5f add input weight predictions for p2pkh outputs (conduition)
Pull request description:
Adds input weight prediction constant and `ground_p2pkh_*` methods, mirroring those for `P2WPKH`. This seemed to be missing.
ACKs for top commit:
tcharding:
ACK c745c97e5f
apoelstra:
ACK c745c97e5f
Tree-SHA512: 69b4484686ecf761b766d2a7d7408c784981a9ba8c4aa8abd9d8655bd9421eb882e346ece232530edf9edff602d2fe1570992a5eb7b420b928d8b13397d2f60f
Adds missing prediction constants and const fns for
predicting the weights for P2PKH transaction inputs,
covering both compressed and uncompressed public keys.
7d695f6b41 Improve public re-exports (Tobin C. Harding)
33774122e0 Remove public re-exports from private module (Tobin C. Harding)
Pull request description:
Improve the public exports in two ways:
1. Inline re-exports into the docs of the module that re-exports them.
2. Separate public and private use statements
Recently we discussed a way to separate the public and private import statements to make the code more clear and prevent `rustfmt` joining them all together.
Separate public exports using a code block and `#[rustfmt::skip]`. Has the nice advantage of reducing the number of `#[doc(inline)]` attributes also.
1. Modules first, as they are part of the project's structure.
2. Private imports
3. Public re-exports (using `rustfmt::skip` to prevent merge)
Use the format
```rust
mod xyz;
mod abc;
use ...;
pub use {
...,
};
```
This patch introduces changes to the rendered HTML docs.
ACKs for top commit:
apoelstra:
ACK 7d695f6b41
Tree-SHA512: dc9121c0fe282e3035d862beadb89e2d5a374a7dab6b1c3147a9b5960f8bc2f5af49892f0f713f55c645c46f53464c32daf390c11d85c75553b3ea7e0efc8246
6c6c08ca50 add second test case (conduition)
0c56131819 fix: FeeRate::checked_mul_by_weight should scale output down by 1000 (conduition)
Pull request description:
Fixes a bug in https://github.com/rust-bitcoin/rust-bitcoin/pull/1864. The `FeeRate::checked_mul_by_weight` and by extension the `FeeRate::fee_wu` methods were returning fee amounts scaled up by a factor of 1000, since the internal representation in `FeeRate` is sats per 1000 weight units.
This PR fixes `checked_mul_by_weight` and its unit tests by scaling the output of these methods down by 1000, so that `X sat/vbyte * Y vbytes = X * Y sats`, instead of `X * Y * 1000 sats` as before.
## Before
This code would pass without panic before this PR.
```rust
let weight = Weight::from_vb(3).unwrap();
let rate = FeeRate::from_sat_per_vb(3).unwrap();
assert_eq!(weight * rate, Amount::from_sat(9));
assert_eq!(rate.checked_mul_by_weight(weight), Some(Amount::from_sat(9000)));
```
## After
```rust
let weight = Weight::from_vb(3).unwrap();
let rate = FeeRate::from_sat_per_vb(3).unwrap();
assert_eq!(weight * rate, Amount::from_sat(9));
assert_eq!(rate.checked_mul_by_weight(weight), Some(Amount::from_sat(9)));
```
ACKs for top commit:
Kixunil:
ACK 6c6c08ca50
Tree-SHA512: aa7b0b6237d9b18057dd7c5df12740f87bd9601acc0cac588b73a2d7a1c35b1581532d0de888230296623fa166baff4b9df89d1f2f73399f44a24dcb9c75eac4
In order to move towards our own I/O traits in the `rust-bitcoin`
ecosystem, we have to slowly replace our use of the `std` and
`core2` traits.
This is the final step in removing the explicit `core2` dependency
for I/O in no-std - replacing the `io::Error` type with our own.
Sadly the `std::io::Error` type requires `std::error::Error` as a
bound on the inner error, which is rather difficult to duplicate in
a way that allows for mapping to `std` and back.
To take a more general approach, we use bound on any `Debug`
instead.
Tobin C. Harding
Andrew Poelstra
yancy
conduition
apoelstra
Vojtěch Toman
Matt Corallo