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
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
4e9ff972ad Improve checksum documentation (Tobin C. Harding)
0f01cb9f51 Use rustdoc summary (Tobin C. Harding)
6151d4c841 base58: Rename public functions (Tobin C. Harding)
a94af5c052 base58: Re-order code (Tobin C. Harding)
d362e6286a base58: Improve rustdocs (Tobin C. Harding)
a43234e7ab base58: Make SmallVec methods private (Tobin C. Harding)
27f2cba623 base58: Use alternate form to print hex (Tobin C. Harding)
f659a7aca3 base58: Remove key related errors (Tobin C. Harding)
Pull request description:
Do some clean up work to the `base58` module in preparation for splitting it out into its own crate.
- Patches 1-6: Basic clean up.
- Patch 7: Re-names the public API functions.
- Patch 8: Fixes rustdoc comment as suggested during review.
- Patch 9: Improves documentation on checksum, also as suggested during review.
ACKs for top commit:
apoelstra:
ACK 4e9ff972ad
sanket1729:
ACK 4e9ff972ad. Left some naming nits.
Tree-SHA512: 0fb1e5a964bd197fcb3ef5e9ecd6f8c6b35439af46528e8dbe654d9d10f7c8ed3ca1461593caf6efd0be1cd3a1c24fed1a176931114846a394b396bed6a2411d
49d7b0bfe1 Remove deprecated re-exports (Tobin C. Harding)
Pull request description:
Recently we added a bunch of deprecated re-exports while moving things out of the util module. Turns out while the code reads like it works, `deprecated` actually only works for functions, not types or modules etc.
Remove the non-functional deprecated lines and elect to _not_ re-export things we moved. Release 0.30 is going to break a lot of code but there is no real nice way to resolve that. We will need good release notes and a public apology probably :)
Fix import statements that still rely on `util::bip32` - these should have been fixed when we moved the `bip32` module.
ACKs for top commit:
Kixunil:
ACK 49d7b0bfe1
apoelstra:
ACK 49d7b0bfe1
Tree-SHA512: 2b6a6d2d001f6124585f692315c48654b4fd0f5047b9fcef92b25829a27c8a02b3d187c8d363e9304b3998b652ead1ad368a7bf68ea23c984d1973074df2af21
00c7b6e06f Witness: Fix nits from PR 1323 (junderw)
Pull request description:
Ref: #1323
This is just to quickly fix some of the smaller nits. Larger changes (deprecations, adding / refactoring of methods) should be in a separate PR.
ACKs for top commit:
Kixunil:
ACK 00c7b6e06f
tcharding:
ACK 00c7b6e06f
sanket1729:
ACK 00c7b6e06f
Tree-SHA512: 5f661187a7003060669d15d873e323c017c905a00b62eb56ca3afc2fc27084b245ad62dfcf6d2fd14eac361430be954e7636f6b9ff668aefaad0424789a2f826
Recently we added a bunch of deprecated re-exports while moving things
out of the util module. Turns out while the code reads like it works,
`deprecated` actually only works for functions, not types or modules
etc.
Remove the non-functional deprecated lines and elect to _not_ re-export
things we moved. Release 0.30 is going to break a lot of code but there
is no real nice way to resolve that. We will need good release notes and
a public apology probably :)
Fix import statements that still rely on `util::bip32` - these should
have been fixed when we moved the `bip32` module.
Recently clippy was updated and now new warnings are generated for the
`hashes` crate.
Clippy emits 3 warnings of form:
warning: this expression borrows a value the compiler would automatically borrow
As suggested, remove the explicit borrow.
We would like to bring the `bitcoin_hashes` crate into the
`rust-bitcoin` repository.
Import `bitcoin_hashes` into `rust-bitocin/hashes`, doing so looses all
the commit history from the original crate but if we archive the
original repository then the history will be preserved. We maintain the
same version number obviously and in the changelog we note the change of
repository.
Commit hash that was tip of `bitcoin_hashes` at time of import:
commit 54c16249e06cc6b7870c7fc07d90f489d82647c7
Includes making `embedded` and `fuzzing` per-crate i.e., move them into
`bitcoin` as hashes includes these also.
NOTE: Does _not_ enable fuzzing for `hashes` in CI.
Notes on CI:
Attempts to merge in the github actions from the hashes crate however reduces
coverage by not running hashes tests for beta toolchain. Some additional
work could be done to improve the CI to increase efficiency without
reducing coverage. Leaving for another day.
3c0d5aed73 Add get_tapscript to Witness (junderw)
4226d60205 Add Index<usize> and nth(index) to Witness (junderw)
Pull request description:
Ref: https://github.com/rust-bitcoin/rust-bitcoin/pull/672#issuecomment-980636502
[Add Index<usize> and nth(index) to Witness](4226d60205)
[4226d60](4226d60205)
Arbitrary indexing into Witness fixes the API of last and second_to_last to be more flexible.
This patch started off as an addition of third_to_last, but ended up evolving
into arbitrary indexing to allow for future use cases.
A list of the indices of the start byte for each witness element is stored as an ordered
contiguous group of u32s represented as 4 bytes each in the Vec<u8> contents.
The bytes are stored using to_ne_bytes for performance reasons. A helper function is added
to the tests to allow for easier contruction of the contents Vec in test vectors. u32 was
chosen because 22 bits are needed to store 4,000,000 which is the maximum weight limit for
a block. This might need to be reworked in the event of consensus limits increasing, but
u32 can hold 1000x the current limit, so it should be fine for the forseeable future.
The push and consensus_deserialize functions utilize rotate_left and rotate_right to move
the indices to the end of the new allocation. Depending on the size of the data, this
might be more of a performance hit than just allocating a new temporary Vec to store the
indices and append them after parsing is completed. However, for a majority of cases
rotating the indices should be faster. Suggestions to use VecDeque instead of Vec for
contents necessitate other considerations, since it is not a public facing change,
those optimizations can be dealt with in future patches.
The Index<usize> trait is implemented using the new nth method with expect.
The Iter struct is reworked to make use of the new data representation. This new data
structure makes it trivial to implement DoubleEndedIterator and other such traits, but
I have decided to leave this as out of scope for this patch.
---
[Add get_tapscript to Witness](a7501d9599)
[a7501d9](a7501d9599)
This new method will check the last witness element to see if it starts with 0x50, and
depending on the result it will return the second to last or third to last witness
element according to BIP341.
In its current state, Witness can not know what type of script it is fulfilling,
so it is up to the caller to verify if the previous output is a taproot output or not.
---
Edit: This is the previous PR body:
> In a taproot script payment with annex, quick access to the 3rd to last element (which is the actual script in this case) is convenient.
>
> This feels like kicking the can down the road again, but I think it's a nice to have method.
>
> RCasatta dr-orlovsky were discussing this issue. I would like to ask if they have any thoughts on the addition of this.
ACKs for top commit:
tcharding:
ACK 3c0d5aed73
apoelstra:
ACK 3c0d5aed73
Kixunil:
ACK 3c0d5aed73
Tree-SHA512: 0038eed6ad56786b8dd6d98db0d1846753b8b25de0bc1089cdc75d5850d0ccc66dde9a10be7fe09589ad7db118fd50ee9f7993695968df5c389457ccfcdaa761
Recently we added a workspace but left the CHANGELOG file at the
repository root, this is incorrect because the CHANGELOG is a per crate
thing since it is updated along with crate release.
Calvin Kim
Andrew Poelstra
Tobin C. Harding
connormullett
Antoine Riard
Noah Lanson
sanket1729
Casey Rodarmor