old: `actions-rs/toolchain`
new: `dtolnay/rust-toolchain`
fix
ci(fuzz): change runner to ubuntu-latest
ci: update run syntax in fuzz job
ci: update and run fuzz/generate-files.sh
Recently we introduced a bug in the weight/size code, while
investigating I found that our `Transaction`/`Block` weight/size APIs
were in a total mess because:
- The docs were stale
- The concept of weight (weight units) and size (bytes) were mixed up
I audited all the API functions, read some bips (141, 144) and re-wrote
the API with the following goals:
- Use terminology from the bips
- Use abstractions that mirror the bips where possible
The `network` module deals with data types and logic related to
internetworking bitcoind nodes, this is commonly referred to as the p2p
layer.
Rename the `network` module to `p2p` and fix all the paths.
Last release we added a type alias for `Psbt`, now lets just rename the
type and be done with it.
Includes re-export at the crate root because `bitcoin::Psbt` is clear
and obvious.
We should probably restore this in the future, but we need to rethink
how we fuzz hashes -- right now when cfg(fuzzing) is set, we break all
the hash functions in a way that won't match any other library.
We should probably make this breakage opt-in but this will require
buy-in from rust-lightning and maybe others.
AFAICT we literally never used this; it was available only on the
bitcoin targets and not the honggfuzz ones; AFL has a broken dep
tree (or at least, requires some more MSRV pins that I did not care
to investigate).
Just remove it entirely.
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.
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.
We are attempting to flatten the `util` module; move the `bip152` module
to the crate root out of `util`.
Currently `src/util/` is ignored by the formatter so this move causes
the `bip152` module to be formatted.
02a2b43b2b Remove Default impl for Target and Work (Tobin C. Harding)
cb9893c4a9 Add Target and Difficulty types (Tobin C. Harding)
Pull request description:
Ugh! 1600 lines of green and 1100 of red - my apologies.
Currently we use the `Uint256` type for proof-of-work calculations. It was observed in #1181 that providing a public 256 bit integer type like this implies that it is a general purpose integer type. We do not want to provide a general purpose integer type (see the 1000 arithmetic functions on stdlib integer types for why not :)
Add two new opaque integer types `Target` and `Work`. These are the inverse of each other, both conceptually and mathematically.
There is a lot of code in this PR, sorry about that. At a high level the PR does:
- Add a `pow` module.
- Put a modified version of `Uint256` in `pow`, making it private.
- Add two new wrapper types `Target` and `Work` that provide a very limited API specific to their use case. In particular there are methods on each to convert to the other.
- Only implement methods that we use on each type.
### Note
During development I got mixed up with the word "difficulty", I have discovered this has a very specific meaning in Bitcoin. Please see rustdocs on the `Target::difficulty` function for explanation of this term. For this reason we use the type `Work` defined as the inverse of target, and reserve "difficulty" for the Bitcoin concept.
ACKs for top commit:
apoelstra:
ACK 02a2b43b2b
Kixunil:
ACK 02a2b43b2b
Tree-SHA512: 4d701756a42b832f03b8d542f3a5278b4ca1d5983ffd7d4630577ebd4cc8f47029719f9018185e01fa459d8fb32426b5cb4d6b8d8b588ebbb7b65e4aeee94412
Currently we use the `Uint256` type to represent two proof of work
integers, namely target and difficulty (work).
It would be nice to not have a public integer type that is not fully
implemented (i.e., does not implement arithmetic etc as do integer types
in stdlib). Instead of implementing all the stdlib functions we can
instead add two new wrapper types, since these are not general purpose
integers they do not need to implement anything we do not need to use.
- Add a `pow` module.
- Put a modified version of `Uint256` to `pow`.
- Add two new wrapper types `Target` and `Difficulty`.
- Only implement methods that we use on each type.
Note this patch does not remove the original `Uint256`, that will be
done as a separate patch.
b79c178ea8 Add fuzz test for PrefilledTransaction (Tobin Harding)
Pull request description:
Add a simple deserialization fuzz test for `PrefilledTransaction`.
Fixes: #460 (I think, I'm not sure if any of the other types need fuzzing?)
ACKs for top commit:
apoelstra:
ACK b79c178ea8
Kixunil:
ACK b79c178ea8
Tree-SHA512: 3e5cbda6b17c36f414bce05b562b5648d82433b185853e6c8aa33ec491b58e527626eb09caca2a988120329efd92dfd3aaad60ef99746d6ac41555160efeb9d6
Create a directory `bitcoin` and move into it the following as is with
no code changes:
- src
- Cargo.toml
- contrib
- test_data
- examples
Then do:
- Add a workspace to the repository root directory.
- Add the newly created `bitcoin` crate to the workspace.
- Exclude `fuzz` and `embedded` crates from the workspace.
- Add a contrib/test.sh script that runs contrib/test.sh in each
sub-crate
- Fix the bitcoin/contrib/test.sh script
The identifier 'util' does not convey any information. We have a whole
bunch of modules inside the `util` module.
As part of work to reduce the amount of arbitrary things in the `util`
module move the `address` module to the crate root level.
Modify from_script functions to return result instead of option so that, in case of errors, there is more
information on what went wrong.
Resolves: #1022
5d71a9dd89 Correct input length check for uin128 fuzzer (Matt Corallo)
9c256cc88e Add a fuzz check for `Uint128::increment` (Matt Corallo)
a15f263c4e Move the `increment` fn into the uint macro to add it to Uint128 (Matt Corallo)
d52b88b525 Fix increment of Uint256 with carry (carolcapps)
Pull request description:
This is #578 with review feedback addressed.
ACKs for top commit:
apoelstra:
ACK 5d71a9dd89
sanket1729:
ACK 5d71a9d
Tree-SHA512: 32e5ea6387943ecad8f190a0de336a545fda72b6ff7388d3479037a5f880434276a7d0607f5cf61710d45e984c01954f4e3199a60c542be48b397717afb3d406
In an earlier version of the uint128 fuzz target, there was a byte
which incidated the specific operation to test. However, that was
dropped for the much-more-effective approach of simply testing all
operations in each fuzz iteration.
Tobin C. Harding
Andrew Poelstra
Einherjar
Riccardo Casatta
eunoia_1729
Martin Habovstiak
Matt Corallo
Matt Corallo
Elichai Turkel
Dr Maxim Orlovsky