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.
248f9a3b4b Use capital letters for Bitcoin Core (Tobin C. Harding)
832169eb8d Add to/from_consensus methods to Version type (Tobin C. Harding)
24984f095f Make block::Version inner value private (Tobin C. Harding)
7e146ede96 Make types in block module more terse (Tobin C. Harding)
Pull request description:
After initial attempt and review this PR has been re-written.
- Patch 1: Make types in `block` more terse, this is preparatory clean up based on suggestion below.
- Patch 2: Make inner value of `Version` private to hide the i32/u32 discrepancy
This is a follow up to #1240
ACKs for top commit:
Kixunil:
ACK 248f9a3b4b
apoelstra:
ACK 248f9a3b4b
Tree-SHA512: ee031035288a2bcc246a9837a6028c254c51daf78a5cc2441b467ab7f183f1700a63911a2e78b84a20674ce0a83851a7c3bb7e46644a56fdd255685b9a0bf7f2
2157e69857 Document the `all` module (Tobin C. Harding)
Pull request description:
Improve documentation on the `all` module by doing:
- Document guarantee that `all` will only ever contain opcode constants
- Fix stale/incorrect code comment
Done as follow up to #1295
ACKs for top commit:
apoelstra:
ACK 2157e69857
Kixunil:
ACK 2157e69857
Tree-SHA512: 4df091bbdce7b9ba73caabd74b80f9e8c0a30fa2f9a20ed9b75542e71a204e5cd82698a74bebbd6f0beab55ecd807154d1b7d27a787cc9dede7abbd20a0a4ad5
8c4fa5ec3d Remove into_bytes from impl_array_newtype (Tobin C. Harding)
Pull request description:
All the types that we define with `impl_array_newtype` are `Copy` so the correct conversion method to get the underlying byte array is `to_bytes`. We currently provide `into_bytes` as well as `to_bytes`, with one of them calling `clone` - this is unnecessary and against convention.
Remove `into_bytes` and for `to_bytes` just return the inner field. Add code comment to remind devs of correct usage of the macro in regards to deriving `Copy` and `Clone`.
ACKs for top commit:
Kixunil:
ACK 8c4fa5ec3d
apoelstra:
ACK 8c4fa5ec3d
Tree-SHA512: 619acbccc5d86afeaea9f69e4b8d4290dcd8d2ccb09d5bb22f475a47f703d63a45c059b0261b1cc3d4c8d9ef0a508263e1e836fd3ba6fa08ff67ebb23eb63309
The `Version` type uses a signed 32 bit integer inner type but we bit
twiddle as if it was a `u32`. We recently made the inner type private to
hide the data type because of this oddness.
Add methods `from_consensus` and `to_consensus` to facilitate any
possible thing users may want to do with a consensus version value.
The Bitcoin block version is a signed integer for historical reasons,
but we bit twiddle it like an unsigned integer and during consensus
encode/decode we cast the signed value to an unsigned value.
In order to hide this confusion, make the inner value private and add a
couple of constants for v1 and v2 block versions.
Currently the types in the block module have longer names than
necessary, "header" and "version" identifiers contain the word "block",
this is unnecessary because we can write `block::Header` instead of
`BlockHeader` when context is required. This allows us to use the naked
type `Header` inside the `block` module with no loss of clarity.
We are stuck with `BlockHash` because the type is defined along with all
the other hash types in `hash_types`, leave it as is for now but
re-export it from the `block` module to assist in putting types that are
used together in scope in the same place, making import statements more
ergonomic.
The `all` module enables usage of a wildcard import statement without
muddying the scope with any other types defined in `opcodes`, in other
words if one wants to use the `All` type `opcodes::All` is the most
clear way to use it, however usage of naked `OP_FOO` types is perfectly
clear.
Add documentation stating that we guarantee to never put anything else
in the `all` module so folks are confident using a wildcard import will
not bring any rubbish into scope.
Expected usage in downstream applications that need types in `opcodes`
as well as the opcodes:
```
use bitcoin::opcodes::all::*;
use bitcoin::opcodes;
```
Also, we do no implement `Ord` or `PartialOrd`, document this including
HTML tags hiding an example bug from Bitcoin Core that shows why not.
9a1623c1dc Re-export hashbrown when enabled (Tobin C. Harding)
Pull request description:
`hashbrown` used to be exported until commit 23ee0930c7 which removed the `pub extern crate` declaration.
Found thanks to afilini (#1342)!
ACKs for top commit:
apoelstra:
ACK 9a1623c1dc
Kixunil:
ACK 9a1623c1dc
Tree-SHA512: 0363781dc06211eec59246ce54582220674d5ab2bd6e62ad15eeb97b0df6435cdf23df8306131c176b6003dde31d1e376f52981f2e69e9d2529876d3ada727e0
b6f9e47dba Fix `no_std` when `bitcoinconsensus` is enabled (Martin Habovstiak)
Pull request description:
`default-features = false` was missing previously but blindly adding it would lead to subtle risk of breaking when a crate not needing `std` depends on `bitcoinconsensus` and simultaneously another crate not needing `bitcoinconsensus` depends on `std` and another crate depends on them both.
This change fixes it by introducing `bitcoinconsensus-std` feature flag and provides a fallback if the flag is off. Unfortunately the fallback has to use a bit of reasonable `unsafe` due to limitations of upcasting.
The only safe alternatives are not do it and provide worse experience for crates that are affected by the problem above or break the API, which couldn't be backported and would be more annoying to use.
Closes#1343
This is considered PoC PR as I realized the possibility of the hack (and necessity of `unsafe`) at the last moment. Things like tests and modifying CONTRIBUTING to change the stance on `unsafe` will be added if `unsafe` is ACKed.
ACKs for top commit:
tcharding:
tACK b6f9e47dba
apoelstra:
ACK b6f9e47dba
Tree-SHA512: 3a2845f4701c94ff6214749fa490aecf3fd96089df31b15f9d3e0afe3c74329ff2b9054d51244358a79f928aa9d4cf4001fc3ec40a9b0e189323544c4480c709
b84e1d46c0 Move amount module out of util (Tobin C. Harding)
Pull request description:
Done as part of flattening the `util` module. Simply move the `amount` module out of the `util` module and to the crate root. Justified by the fact that the `Amount` type is more-or-less a "primitive" bitcoin type.
ACKs for top commit:
apoelstra:
ACK b84e1d46c0
Kixunil:
ACK b84e1d46c0
sanket1729:
ACK b84e1d46c0
Tree-SHA512: 9ec707f49b7ab29f573be22b366d2ea9c1a8e4b27e80350d521b9c6607fca4142f079648cb739ba8590edd97c21a00029c3647c4c8cebe47cc2dfee1b10b8b39
All the types that we define with `impl_array_newtype` are
`Copy` so the correct conversion method to get the underlying byte array
is `to_bytes`. We currently provide `into_bytes` as well as `to_bytes`,
with one of them calling `clone` - this is unnecessary and against
convention.
- Remove `into_bytes` and for `to_bytes` just return the inner field.
- Add a method that causes build to fail if `Copy` is not implemented.
29df410ea3 Document state after call to calculate_root_inline (Tobin C. Harding)
2dbc7fdf21 Rename merkle_root functions (Tobin C. Harding)
22dd904735 Rename util::hash module (Tobin C. Harding)
Pull request description:
Done as part of flattening `util`.
The `util::hash` module only provides two functions, both to calculate the merkle root of a list of hashes.
1. Rename `util::hash` -> `crate::merkle_root`
2. Change function names to `calculate[_inline]` so usage becomes `merkle_root::calculate`
Done as two separate patches so we can bikeshed the names, can squash if needed.
ACKs for top commit:
Kixunil:
ACK 29df410ea3
apoelstra:
ACK 29df410ea3
Tree-SHA512: 17ace90c7700b5d7adf8b95731c9a348b5c92863806cc88bc40730547f457e44160efb19985e025970b59fea86d68f0bf4be0af17717a65ae44f11c8d10ec4c6
1050fe9cae Remove unnecessary borrow (Tobin C. Harding)
3966709336 Use is_none() (Tobin C. Harding)
d192052519 Remove unnecessary dereference (Tobin C. Harding)
624cda07b3 Remove unnecessary casts (Tobin C. Harding)
Pull request description:
Clippy has been updated and new warnings are being triggered in our codebase. This PR does all warnings using nightly since they all looked like reasonable things to fix.
Needed for CI to pass in other open PRs.
ACKs for top commit:
Kixunil:
ACK 1050fe9cae
sanket1729:
ACK 1050fe9cae.
Tree-SHA512: 7dcfb6a72a0aae51b49b417bb94cbe1becb1095d1bf0011921b1834a10f792cfcdeee37993ab9b103bd2dfcc9cd3c26cd7f1bb80b06b0d1aa4aaa454bfb0b3f0
d6ca7e4b9f Add a test parsing transaction with a huge witness (Martin Habovstiak)
Pull request description:
This transaction broke past versions of `rust-bitcoin` and LND so this adds a test to avoid reintroducing the problem in the future.
See also https://github.com/romanz/electrs/issues/783
I'm publishing this immediately for research purposes. I can clean it up later if required (low on time rn) or we may even not merge it if there is a better test.
ACKs for top commit:
tcharding:
ACK d6ca7e4b9f
Tree-SHA512: cfa9f5c82be0885a82bddb0c15f3177e05feedb369a931e58bf48d90b26eab85bc501d84d17927fa72b42ad4f1016e6042ad318662403271c738eaa91cee7748
cc0b1f1804 Add a CHANGELOG entry for 0.28.2 (Matt Corallo)
Pull request description:
I'm not actually sure if we want this - we don't seem to (consistently) add entries for point releases, but figured I'd put it up in case we want it.
ACKs for top commit:
tcharding:
ACK cc0b1f1804
Kixunil:
ACK cc0b1f1804
sanket1729:
ACK cc0b1f1804
Tree-SHA512: b41f647cfea925a5acd8eaa8568692e7393dabbfd6c75e9dad9e18f34847353363cadaad9109b41a7b1e5851030fefc0180e6b824a2eaaf8f58b4d62fd4bc68f
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.
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.
This transaction broke past versions of `rust-bitcoin` and LND so this
adds a test to avoid reintroducing the problem in the future.
See also https://github.com/romanz/electrs/issues/783
In order that we can safely change/maintain de/serialization code we
need to have regression tests with hard coded serializations for each
type that implements serde.
It is enough to test a single serde data format, use JSON for `opcodes`
and bincode for other types.
Do regression testing in a newly added `tests` module.
The `base58` module is for encoding and decoding, it makes sense for the
public functions to be called `encode` and `decode`. We also have some
functions that operate on data with a checksum, for these it makes sense
to tack `check` onto the _end_ of the function name.
With this applied the public API is:
- decode
- decode_check
- encode
- encode_check
- encode_check_to_fmt
Code is arguably easier to read if the most important stuff comes first.
In the old days, when writing C, we had to put definitions before they
were used but in Rust this is not the case
Re-order the `base58` file so that the public API functions are up the top
then other helper functions are defined _after_ they are called.
Refactor only, no logic changes.
Currently we are manually adding `0x` in calls to `write!`, this is
unnecessary since the alternate form already adds the `0x`.
Was verified with
```
#[test]
fn bad_checksum_error_hex_format() {
let want = "invalid base58 character 0xab";
let got = format!("{}", Error::BadByte(0xAB));
assert_eq!(got, want)
}
```
Use alternate form to print hex.
The key related errors are incorrect because they are circular, we have
a base58 error variant in `key::Error` and two key error variants in
`base58::Error`.
Remove the key errors from the `base58::Error` type.
The function call `calculate_root_inline` calculates the merkle root
using the input array as a scratch buffer, i.e., we trash the data
during recursive calls to `merkle_root_r`.
Add explicit documentation to the function so its super clear not to use
the hashes again after calling this function.
Recently we renamed the `hash` module to `merkle_root`, this makes the
public functions provided stutter if used with one layer of path as is
Rust convention:
`merkle_root::bitcoin_merkle_root`
We can improve on this by renaming the functions to 'calculate', then we
get
- `merkle_root::calculate()`
- `merkle_root::calculate_inline()`
Noah Lanson
Andrew Poelstra
sanket1729
Casey Rodarmor
Tobin C. Harding
junderw
Matt Corallo
Martin Habovstiak