For some applications, such as block explorers, it's useful to be able
to obtain the public key used in case of P2PK. This is considered
general enough for addition into bitcoin library,
so this change adds it.
The public key is returned only when it's valid and the script is P2PK.
To avoid duplicating the logic checking whether a script is P2PK the
logic is moved to a new p2pk_pubkey_bytes() method which returns raw
bytes and is then called from both is_p2pk() and p2pk_public_key()
Clippy emits various warnings of form:
warning: this expression creates a reference which is immediately
dereferenced by the compiler
As suggested, remove the unnecessary explicit reference.
We are trying to flatten the `util` module. The `taproot` module can
live in the crate root. If/when we create a `crypto` module/crate we may
wish to pull some stuff out of this module but for now moving it gets us
closer to removing `util` without making the directory structure any
worse.
Includes adding rustfmt attributes to skip formatting of macros.
2df51dae15 Create crypto module (Tobin C. Harding)
Pull request description:
Done as part of [util flattening](https://github.com/rust-bitcoin/rust-bitcoin/issues/639).
Create a `crypto` module and move into it (out of `util`):
- ecdsa
- schnorr
- key
After review, this PR now includes some type re-names
- EcdsaSig -> ecdsa::Signature
- SchnorrSig -> schnorr::Signature
- EcdsaSigError -> ecdsa::Error
- SchnorrSigError -> schnorr::Error
- InvalidSchnorrSigSize -> InvalidSignatureSize (this is an error enum variant)
ACKs for top commit:
apoelstra:
ACK 2df51dae15
sanket1729:
ACK 2df51dae15
Tree-SHA512: 7cf63d51ed5fdc737cd59767d9bb96b1e3501634e3aee855493f6a51ad5c5397ce4b25c77f9929abd70d6ceb351fc6520e835da108f4c9a46df5b9c2b52ca6b3
f7a6d17143 Add rand feature flag to the example documentation (yancy)
Pull request description:
It's confusing trying to follow the documentation [here](https://docs.rs/bitcoin/latest/bitcoin/util/address/index.html) unless you know to enable the `rand` feature flag. This PR updates the docs so people know to enable the flag.
```
22:35 < control> hello, how can i generate a simple wallet address using rust bitcoin? cant find working example
22:45 < andytoshi> control: do you have a private key?
22:45 < andytoshi> what kind of address do you want to generate?
22:46 < andytoshi> my guess would be that you want to use bdk rather than rust-bitcoin directl
22:48 < control> P2PKH address and generate private key. just as simple as bit library in python does
22:52 < control> im trying to run this example
22:52 < control> https://docs.rs/bitcoin/latest/bitcoin/util/address/index.html
22:52 < control> but it says ^^^^ could not find `rand` in `secp256k1`
```
ACKs for top commit:
apoelstra:
ACK f7a6d17143
Kixunil:
ACK f7a6d17143
Tree-SHA512: 6d94f8ffa7797d1e7720a840d4f8bb0ac274507118597dff60631ad3d28dbe57e2341b87d6101e2a9f5fbcc2b1f0beb6d06f9dde48a480cb10a9a45c887f83a4
d4bfc3d7b1 github: add Kani to Github CI (Andrew Poelstra)
c11645b7e5 amount: use kani to check some arithmetic properties (Andrew Poelstra)
Pull request description:
A first exploration into using Kani. See #1370.
ACKs for top commit:
Kixunil:
ACK d4bfc3d7b1
tcharding:
ACK d4bfc3d7b1
Tree-SHA512: 431ba1c1c42521bc36ab5260ea338c5c8154edd7f037928ba36a6c901551d05e420e8a886f772ea205009f718a16a5793a2e408818de88602968b52492a910cd
Kani can't really handle string processing, and appears to be unable
to check integer multiplication (for now), but we do several checks
for addition and subtraction, and conversion between signedness,
that Kani can easily prove.
57165d3f7f Fix typo in the SHA512 documentation (Calvin Kim)
Pull request description:
Saw the typo and since this typo also exists in crates.io, I thought it'd be good to quickly change it.
Though maybe this should be replaced altogether with the `hash_type` macro since every other hash function implementation is using that.
ACKs for top commit:
Kixunil:
ACK 57165d3f7f
apoelstra:
ACK 57165d3f7f
Tree-SHA512: dba54a71073bf58cafe4a248ec25c5f6a691f565d6bda749d5b50786d353a30cd59f09e10f600cb95b8f635ab1ce38aef8decb178b586c80df1b6cc9a7943a49
Done as part of flattening util.
Currently in `util` module we have a bunch of modules that provide
cryptography related functionality.
Create a `crypto` module and move into it the following:
- ecdsa
- schnorr
- key
To improve uniformity and ergonomics, do the following re-names while we
are at it:
- EcdsaSig -> ecdsa::Signature
- SchnorrSig -> schnorr::Signature
- EcdsaSigError -> ecdsa::Error
- SchnorrSigError -> schnorr::Error
- InvalidSchnorrSigSize -> InvalidSignatureSize (this is an error enum variant)
519db4d951 add Network::to_core_arg() method (connormullett)
Pull request description:
closes: #1207
Adds converting `Network` to its `bitcoind` equivalent.
The arguments for -chain can be found in the documentation and is one of the following:
main, test, signet, regtest
ACKs for top commit:
apoelstra:
ACK 519db4d951
Kixunil:
ACK 519db4d951
Tree-SHA512: 5fd805d654f7c30f87ff877fe90e19490d0deb73b46ce87cc6b43d30595eb9d2de3f646f58a5d72180c3e8cc6a9b614bfe6753ecd6c21b8d193a8d862e3f887f
108a1f73ca Fail CI if docs build throws warnings (Tobin C. Harding)
b014f0fdcb Fix rustdocs build warnings (Tobin C. Harding)
Pull request description:
Currently we do not fail the CI script if the docs build throws warnings, since we are a group of super anal, easily triggered, code cleanliness obsessed devs this causes a mild rash to develop on the lower back [0]. We can easily fix this by checking for build warnings in CI.
[0] - Amusingly my rash has been playing up since Friday but I thought I'd fixed the warnings in an open PR someplace so I was ignoring it, seeing Kixunil's [issue](https://github.com/rust-bitcoin/rust-bitcoin/issues/1403) this morning prompted me to fix it :)
Fix#1403
ACKs for top commit:
Kixunil:
ACK 108a1f73ca
apoelstra:
ACK 108a1f73ca
Tree-SHA512: 0f86c318b2ec8bf7aa6a0d0f355f8fe8e3eb8ad5eb74d95f8dab882d6729c386c3e0ef4cc2378645e15460ff2b9b47d66e3603958f8b188f5e2b07272739d755
Convert all rustdocs build warnings to errors using `-D warnings` and
exit the script with 1 to signal the error.
While we are at it use `--all-features` instead of explicit feature list
when building docs. Without this the docs build fails with:
error: too many file operands
64495cc5fe Drop Network arg from max_money() (Antoine Riard)
Pull request description:
Amount of coins available stay in the same across Bitcoin network: signet, testnet, mainet. From my understanding this is a leftover from some potential multi-chain support.
For more context: https://github.com/lightningdevkit/rust-lightning/pull/1839#discussion_r1019753069
If there is already an existent PR, it can be closed, however didn't find one.
ACKs for top commit:
apoelstra:
ACK 64495cc5fe
tcharding:
ACK 64495cc5fe
Tree-SHA512: 929011ee73c5eda903fb0140438ed5e88c8f5b7378036a87a6a660a8b9138bf204bf59a0ba822c0cd98e37e97d2d0dbbf8c9893a834da9acdf817ba43a5ed5b6
e04a7a926d network: Run cargo fmt (Tobin C. Harding)
dc33c7999f Enable formatting of the network module (Tobin C. Harding)
81f69e846b Exclude from formatting stuff in the network module (Tobin C. Harding)
408d7737fb Run cargo fmt (Tobin C. Harding)
1ecf09359b Add local variable to reduce line length (Tobin C. Harding)
b2e74bc050 Exclude long function call (Tobin C. Harding)
ff5a80dbd3 Exclude formatting of function fmt_satoshi_in (Tobin C. Harding)
308a12b7cf Exclude array from formatting (Tobin C. Harding)
fb7ff46ccc Improve crate root re-exports (Tobin C. Harding)
Pull request description:
The `network` module is not currently included in formatting. Also, at this point in time not much is happening in the `network` module so formatting it should not cause too many merge conflicts with other in-progress PRs.
The first 3 patches are formatting preparation of the repo, the next 2 are formatting preparation of the `network` module. The last patch is the result of running `cargo +nightly fmt`. Can one reviewer please verify the last patch consists only of `rustfmt` changes by running the command on their branch. Thanks
cc luckysori :)
ACKs for top commit:
apoelstra:
ACK e04a7a926d
Tree-SHA512: 49b2873f0bfdd448df97073b462fa860c85b7f3c3094fdb0e16fd86aa467156ea8b2ceec61e2ee99848802cd171fd8abbc17e45c66672889a37c413fa4bea636
9674bf29fe hashes: Fix clippy warnings (Tobin C. Harding)
b9643bf3e9 Import bitcoin_hashes crate into hashes (Tobin C. Harding)
580feab3f9 internals: Add CHANGELOG file (Tobin C. Harding)
bae64e156e Move CHANGELOG to bitcoin crate (Tobin C. Harding)
9a2c856be6 Update gitignore file (Tobin C. Harding)
Pull request description:
#1337 was split out of this in an attempt to help review, I think we can merge this one though now it has some traction.
We would like to bring the `bitcoin_hashes` crate into the `rust-bitcoin` repository. https://github.com/rust-bitcoin/rust-bitcoin/issues/550#issuecomment-1248071843
Import `bitcoin_hashes` crate into `hashes`.
Commit hash that was tip of `bitcoin_hashes` at time of import:
commit 2a78c250f78d391599040223870a4d1d6f6f5482
Please note the commit history of `bitcoin_hashes` is only preserved on the soon-to-be-archived `bitcoin_hashes` repository.
ACKs for top commit:
sanket1729:
ACK 9674bf29fe. Did my best to review the CI code, it looks good, and seems like we are testing everything when we add "hashes" to the root level `./contrib/tests.sh`. I would like other reviewers to confirm the same.
apoelstra:
ACK 9674bf29fe
Tree-SHA512: db3ce6adeb38430c5a9f372da16be9fb048c2e5cff646b701139fb4b5fa76e10261432284ede7fd139b75cd69bb124d55973ceb7eccaa996226a7be4cad9b68a
Amount of coins available stay in the same across Bitcoin network:
signet, testnet, mainet. From my understanding this is a leftover
from some potential multi-chain support.
We just removed the `bitcoin/src/network/` exclude from `rustfmt` config
file. Run the command `cargo +nightly fmt`.
No other changes than those introduced by `rustfmt`.
Remove the exclude for the `bitcoin/src/network/` directory from the
`rustfmt` config file. Do not run formatter as part of this change, this
allows the actual formatting change to be verified more easily.
When we moved to edition 2018 the use of `extern` became unnecessary and
we moved to using `pub use` for re-exports. It was observed however that
`pub extern crate` is more readable.
Improve crate root re-exports by doing:
- Use `pub extern crate foo` to re-export foo.
- Fix docs attribute for optional dependency `bitcoinconsensus`.
- Re-order to how rustfmt would put them.
30888f74c5 Move psbt module to crate root module (Tobin C. Harding)
8a75ff450f Move read_to_end out of util module (Tobin C. Harding)
445b07c94c Move util::Error to error module (Tobin C. Harding)
Pull request description:
In an effort to flatten `util` move things out that can/should be put in submodules of the crate root module. For each, configure `rustfmt` to ignore the module. This pushes the `rustfmt` review nightmare down the road.
ACKs for top commit:
apoelstra:
ACK 30888f74c5
Kixunil:
ACK 30888f74c5
Tree-SHA512: 0d93d60bec822d1dc82d4d67c25854364b0863488e4b35c9a0828a843fc3792286c18abde40a8e9d6ec535cfc7f0f0d6495d35961ce43af3f2605c92aaa0815d
f55c4099d5 Format the merkle_tree module (Tobin C. Harding)
Pull request description:
Run `cargo +nightly fmt` and commit the changes to the `merkle_tree` module. No manual changes, only those introduced by `rustfmt`.
ACKs for top commit:
tcharding:
ACK f55c4099d5
apoelstra:
ACK f55c4099d5
Tree-SHA512: 2f47fc426988b4755408fea5f8c4c47ebe23b53850737a1640fa9477cfd83f0ada046aec734986a92a9effbaaee0f34764ef87d82deff1a594f7b73bf2e93e93
We now have an `error` module but the `util::Error`, which is a general
error, is not in it.
Make `Error` more ergonomic to use by doing:
- Move the `util::Error` to `crate::error::Error`
- Re-export it from the crate root since it is our most general error
- Re-export and deprecated it from `util`
613107298d Move merkleblock into merkle_tree (Tobin C. Harding)
c89d9c48ac Move merkle_tree.rs to merkle_tree/mod.rs (Tobin C. Harding)
Pull request description:
Re-done after review comments below. This is now PR 1 in the `merkle_tree::block` series :)
Move the `merkleblock` module into the `merkle_tree` module in a submodule called `block`. In order to do the minimum amount of changes in this patch DO NOT rename types to improved naming and reduce stutter.
Note:
- block module is private
- the three types are re-exported from `merkle_block`
- the `MerkleBlock` re-export from the crate root is left in place.
This patch purposefully does the minimum amount of changes because there a whole bunch of improvements to the old "merkleblock" module that are coming next in a separate PR.
ACKs for top commit:
Kixunil:
ACK 613107298d
apoelstra:
ACK 613107298d
Tree-SHA512: 7299f605a0408372301642ac6826f7532de187b43a6d934715fc0806379b04cfd1550610428b720cb89095659c25e0f4fc8d6c842a93eafc19c091bbfcd5f35e
Move the `merkleblock` module into the `merkle_tree` module in a
submodule called `block`. In order to do the minimum amount of changes
in this patch DO NOT rename types to improved naming and reduce stutter.
Note:
- block module is private
- the three types are re-exported from `merkle_block`
This patch purposefully does the minimum amount of changes because there
a whole bunch of improvements to the old "merkleblock" module that are
coming next.
In preparation for moving `MerkleBlock` into the `merkle_tree` module;
create a new directory for the module and move `merkle_tree.rs` to
`merkle_tree/mod.rs`.
d78a996bf6 Add `Witness::from_slice()` and depreciate `Witness:from_vec()` (Noah Lanson)
d5bdf5d225 Add non-generic `Witness::push_slice()` method (Noah Lanson)
Pull request description:
Cleanup PR to improve the `Witness` API by:
- Adding `Witness::from_slice()` and depreciating `Witness::from_vec()` methods (#1371).
- Making `Witness::push()` not generic and take in `&[u8]` instead of `AsRef<[u8]>` (#1372).
Note: `Witness::from_vec()` has been marked for depreciation from `0.30.0`. Let me know if this should be different.
ACKs for top commit:
tcharding:
ACK d78a996bf6
apoelstra:
ACK d78a996bf6
Tree-SHA512: 3a0b11b1ea77966a773cf7c9e9853822192897eac495fc0a23068bad3b0c46714fc839b20ceeb6e076aa10ea8ff0c023dfc418feff2f892cf11e8c057e5b0c7d