39e528fdfc Add CentiBitcoin to denominations (yancy)
Pull request description:
I was looking to maintain compatibility easily with core tests, and many of the tests use [cent](40e1c4d402/src/test/util/setup_common.h (L74)) denominations. It would be nice to be able to use cent as a denomination in rust-bitcoin as well.
ACKs for top commit:
apoelstra:
ACK 39e528fdfc
tcharding:
ACK 39e528fdfc
Kixunil:
ACK 39e528fdfc
Tree-SHA512: 0514592c9924cbae2370a6186e36d5bac825be59a1fcfdb007fd1f0f08d6ff952a04c0ab0cc7736c29ff6fd0cb7ee96f27f09a79ca3f29ed5775fe3446701889
The `hashes` module contains a bunch of arrays, mostly formatted with 8
hex bytes on a line; add `rustfmt::skip` to keep the formatting of
arrays as is.
Remove the exclude for the `hashes` crate. Do not run the formatter,
that will be done as a separate patch to aid review.
Add `rustfmt::skip` attribute in a couple of places and then remove the
exclude for the `blockdata` module. Do not run the formatter, that will
be done as a separate patch to aid review.
Currently we have a code comment that is supposed to assist devs in
maintaining the `network::constants::Network` type by failing to build
if a new variant is added. This plays havoc with the formatter because
the comment is hanging at the bottom of a match block and the formatting
thinks its for the proceeding line of code.
Instead of using a code comment add a panic so the unit test fails if a
new variant is added to `network::constants::Network`.
In preparation for running the formatter introduce a couple of local
variables to reduce the line length and inhibit function call from being
split over multiple lines.
Refactor only, no logic changes.
bef7992ce5 Update readme to mention pin for 1.47 (Tobin C. Harding)
58033cf14e pin serde dep on 1.47 (Tobin C. Harding)
f5f4a33fa9 pin serde dep on 1.41 (Andrew Poelstra)
ee9b297e98 ci: update dupe check to whitelist syn (Andrew Poelstra)
6aa640ff8d update rust-secp to 0.27.0 (Andrew Poelstra)
Pull request description:
Also remove the spurious dev-dependency copy of rust-secp, which should've been updated to remove the "recovery" feature in https://www.github.com/rust-bitcoin/rust-bitcoin/pull/545 and then been removed entirely in https://www.github.com/rust-bitcoin/rust-bitcoin/pull/1387
ACKs for top commit:
Kixunil:
ACK bef7992ce5
tcharding:
ACK bef7992ce5
Tree-SHA512: 7d1bf062dc6920bcafa85311b4b5ed348e31fb20aa21156e545bf7a4cc4c194e2b6dcfd0d3c6db3df337e4e2cd0f7b74f41ea421549521f07080feb88fbd9382
00b46d6d9d Indent functions (Martin Habovstiak)
d56d202aeb Support weight prediction in `const` context (Martin Habovstiak)
Pull request description:
**Notes for reviewers:**
This is something that I want to use in my code and hopefully reasonably easy to review, so if this can get into 0.30 that'd be really nice. No hard feelings if it doesn't.
I tried to put extra effort into making review easier by:
* intentionally "mis-formatting" the first commit so diff is smaller and easy to understand - see individual commits.
* copying patterns from non-const fn to const fn so it's obviously correct (includes same variable names)
* not bothering with the array trick in `VarInt::len` and simply accepting the limitation of Rust 1.46+ (I use 1.48 BTW).
**Description**
Some smart contracts or simplified wallets statically know the sizes of
transactions or inputs. The possible approaches to handling them so far
were re-computing the values (and hoping the optimizer will const fold
them) or using a simple constant which may be harder to understand and
get right. It's much nicer to just use a `const` but our code didn't
support it until now.
This change adds methods that can compute the prediction in `const`
context for Rust versions >= 1.46.0 which allow use of loops (and
conditions but those could be workaround anyway).
As a side effect of this, the change also adds `const` to `VarInt::len`
in Rust 1.46+. While this one could be made unconditional using array
trick it's probably not worth it because of the planned MSRV bump.
ACKs for top commit:
apoelstra:
ACK 00b46d6d9d
tcharding:
ACK 00b46d6d9d
Tree-SHA512: 5509886a68b4de5227db0e28d92a40be8de64592e0b189c519213db21bcfe98ca03d9a1936b1024729b97db69e8ec0b55fac870a7ce9bab0d0c9a47b2087990f
33ee7a58af Add README build docs for std and no-std (Steve Myers)
Pull request description:
Building this crate requires the `std` and/or `no-std` features be enabled. This PR documents this build constraint in the README ~~and gives an error is anyone tries to build without enabling one or both of these features~~.
See discussion in rust-bitcoin/rust-miniscript#533.
ACKs for top commit:
tcharding:
ACK 33ee7a58af
Kixunil:
ACK 33ee7a58af
apoelstra:
ACK 33ee7a58af
Tree-SHA512: 4c0f46681ee09a1d63d269c84ec69bd12944129c94a62f62f78694ae428566f3dfee9a36ac2742e02502b184c4ec0d6aec60a0c0760df3d75587700cb8a76ad2
2961c0c589 Exclude usage of atomic types if not supported for the target (Salvatore Ingala)
Pull request description:
Hi! I'm still a beginner with both Rust and cross-compilation, so please take the rest with a few grains of salt!
I'm setting up a project targeting `riscv32i-unknown-none-elf`, which seems not to support atomic types. Even with `--no-default-features` and `no-std`, I would get this error:
```
error[E0432]: unresolved import `alloc::sync`
--> rust-bitcoin/bitcoin/src/blockdata/script/mod.rs:52:12
|
52 | use alloc::sync::Arc;
| ^^^^ could not find `sync` in `alloc`
error[E0432]: unresolved import `alloc::sync`
--> rust-bitcoin/bitcoin/src/lib.rs:163:114
|
163 | pub use alloc::{string::{String, ToString}, vec::Vec, boxed::Box, borrow::{Borrow, Cow, ToOwned}, slice, rc, sync};
| ^^^^ no `sync` in the root
|
= help: consider importing one of these items instead:
bitcoin_hashes::_export::_core::sync
core::sync
```
This PR gates the usage of `Arc` so that it's only enabled with the `std` feature.
ACKs for top commit:
apoelstra:
ACK 2961c0c589
Kixunil:
ACK 2961c0c589
Tree-SHA512: c864fb8363fca6a020472b3bdfe488bc2f33d52df98d88f0bc90ebdaa2e9f58b91cc6578eb4fc36f434ff1c50ff9c222a752bd3a72f6b9351244ad5827061e8f
Some smart contracts or simplified wallets statically know the sizes of
transactions or inputs. The possible approaches to handling them so far
were re-computing the values (and hoping the optimizer will const fold
them) or using a simple constant which may be harder to understand and
get right. It's much nicer to just use a `const` but our code didn't
support it until now.
This change adds methods that can compute the prediction in `const`
context for Rust versions >= 1.46.0 which allow use of loops (and
conditions but those could be workaround anyway).
As a side effect of this, the change also adds `const` to `VarInt::len`
in Rust 1.46+. While this one could be made unconditional using array
trick it's probably not worth it because of the planned MSRV bump.
Note: this commit is intentionally unformatted to make diff easier to
understand. Formatting will be done in future commit.
a6188a90c0 Improve QR code formatting documentation (Martin Habovstiak)
Pull request description:
It wasn't obvious that displaying address with alternate formatting upper cases bech32 addresses.
This change adds information about this and also a note about the compatibility of various wallets.
BTW why do we prefix upper case `BITCOIN` only in case of bech32? Proper BIP21 should support it for all addresses. (And yest, it still does save space.)
ACKs for top commit:
apoelstra:
ACK a6188a90c0
tcharding:
ACK a6188a90c0
Tree-SHA512: b62b17664f12d4ce05296131cde9f307311b8114c457970f8e3f1beb4d6fd397981045c61c44e1da573623842b74b73d088f757f9ff063eb783ab69145102cd7
It wasn't obvious that displaying address with alternate formatting
upper cases bech32 addresses.
This change adds information about this and also a note about the
compatibility of various wallets.
2158f88f1d Add a method to `pow::Target` for returning difficulty as an f64. (junderw)
Pull request description:
Closes#1703
This adds a conversion function to U256 to get an f64. We use the method shown in the following blog post.
https://blog.m-ou.se/floats/
Target::MAX was converted to a f64 and set as a const that is verified in a unit test.
The code is rather confusing, so I took a crack at explaining it in my comments as well. Please let me know if you want it cleaned up some more.
ACKs for top commit:
apoelstra:
ACK 2158f88f1d
tcharding:
ACK 2158f88f1d
Tree-SHA512: 7c0e82bd1756950c1c6dfb9da91fd71b276e2e7dc8a33e69112f87b87e358240f0f7c4894d24ab228e149d862938833a2e65e345ce2712a78dc86dec197da34f
9dd4c54a74 Fix CI builds where default features are added accidentally (Steven Roose)
Pull request description:
ACKs for top commit:
Kixunil:
ACK 9dd4c54a74
tcharding:
ACK 9dd4c54a74
apoelstra:
ACK 9dd4c54a74
Tree-SHA512: 7c63b33c2cc7aa988194150e6fb3dacec894f7aeccb90992a9255fcde2312793f4e2556b00d600241e481399445c0434009dd06207783ee592acd5d96452063f
f0a3aad5b8 Add tests to Weight type (yancy)
Pull request description:
Add tests for Weight type
ACKs for top commit:
Kixunil:
ACK f0a3aad5b8
apoelstra:
ACK f0a3aad5b8
Tree-SHA512: 12875cd774762743c53b55f1c56494cd4c3995fc481dd5653810efb363627dfa770bd1e147dacd452a6a61d3906910dc974c979a4a3c41655f8a32a4b4a14ef4
This adds a conversion function to U256 to get an f64. We use the method shown in the following blog post. https://blog.m-ou.se/floats/
Target::MAX was converted to a f64 and set as a const that is verified in a unit test.
Tobin C. Harding
Martin Habovstiak
junderw
Andrew Poelstra
yancy
Steve Myers
Salvatore Ingala
Steven Roose