995c797e0d feat: generate PrivateKey (kshitjj)
Pull request description:
added a function to generate a private key
Resolves: #1823
ACKs for top commit:
apoelstra:
ACK 995c797e0d
tcharding:
ACK 995c797e0d
Tree-SHA512: 29ba54be8cb777e71a4683835686cbf2978b23736f629d7bbff468074235fece261ca170c23f358d1bd878987566d09e4488c3f1a106c59a5c8bdf52b98abffe
Numbers with only zeros after decimal points are valid if they are also
multiples of `10^precision` (e.g. 1000 for msats). These were
artificially disallowed as "too precise" which was at least misleading.
This change allows parsing such numbers.
8e6f953aa7 Expose valid (min, max) difficulty transition thresholds (Wilmer Paulino)
Pull request description:
Once `U256` was made private, we lost the ability to check whether a valid difficulty transition was made in the chain, since `Target` doesn't expose any operations. We only choose to expose `Shl<u32>` and `Shr<u32>` such that we can compute the min and max target thresholds allowed for a difficulty transition.
This is something we realized was missing after bumping to `rust-bitcoin v0.30.0` in `rust-lightning`, specifically for our `lightning-block-sync` crate. It may also be worth having a helper in `rust-bitcoin` that checks a header properly builds upon the previous, but that can be left for future work.
ACKs for top commit:
Kixunil:
ACK 8e6f953aa7
sanket1729:
ACK 8e6f953aa7 . Sorry, was confused by some details.
apoelstra:
ACK 8e6f953aa7
Tree-SHA512: 740dd64089426463dc6a19726d5a562276bd0966e0e31af8e1e67b28d18945644ac0e50be3cf0cc7fa604acc3d2c5b912a77a7caa69d8cff85f70fd57e5328c5
dff757d7db Comment predict_weight (yancy)
Pull request description:
I've been reading over the `predict_weight` function since it is one of the biggest challenges for coin-selection. IE choosing inputs and constructing an optimal selection strategy requires predicting the weight to get the best selection. It's great this work has been done but there are some things I don't understand well enough to comment.
1) why are we looking at the size of VarInt struct here
> let script_size = script_len + VarInt(script_len as u64).len()
2) [predict_weight_internal](36500b4451/bitcoin/src/blockdata/transaction.rs (L1245)) has a bunch of magic numbers. I'd like to be able to comment this as well but I don't fully understand that function.
Also, `Transaction.rs` is a big file and it seems like all of the prediction stuff could be moved to a separate module or maybe a separate crate?
ACKs for top commit:
tcharding:
ACK dff757d7db
Kixunil:
ACK dff757d7db
Tree-SHA512: 8ffa16d500075d691528ce1819b9352a148af431889bebbd7cddcf470bd4e3048ec53a5e778bc3659e33d8c25b68422a93dac1d46b9489ff56f41d88d7f05433
d57ec019d5 Use Amount type for TxOut value field (yancy)
Pull request description:
Propose using `Amount` type for the `TxOut` `value` field. I only implemented `Decodable ` and `Encodable` enough to compile but this needs to completed obviously if using `Amount` seems like a good idea.
ACKs for top commit:
tcharding:
ACK d57ec019d5
apoelstra:
ACK d57ec019d5
Tree-SHA512: df3fd55294d5f9392ca90bb920be8fbb9d7d285d97669412e07d5a099f70f81fd73e7e259679de9c8ce5c6c855e64f62213700f0fb7db415e0c706c509485377
ed6421c939 address: Add generic serde::Serialize for Address (Steven Roose)
814b9917da address: Add Sync, Send, Sized and UnPin marker traits on NetworkValidation (Steven Roose)
Pull request description:
With the new rewrite of Address, `serde::Serialize` is only implemented on `Address<bitcoin::address::NetworkChecked>` and `Address<bitcoin::address::NetworkUnchecked>`. But the compiler has no way of knowing that that are all the possible versions of `Address`, so the generic `Address<impl bitcoin::address::NetworkValidation>` doesn't implement `serde::Serialize`.
ACKs for top commit:
Kixunil:
ACK ed6421c939
tcharding:
ACK ed6421c939
Tree-SHA512: 65e43dff244c94fe08ccb2d985781a2687a1e2db186960a35d4ae89f3b31c5af66892630a3ebaac9cecdc83638487425afa17374869d278648b348869e0ba091
2f7bf1e7be readme: Document that we do not support altcoins (Tobin C. Harding)
5d66f72e5c readme: Enforce 100 column width (Tobin C. Harding)
Pull request description:
Improve the readme by doing:
- Patch 1: Enforce column width to 100
- Patch 2: Update policy on altcoin support (or lack of)
Excuse the OCD leading to patch one, its formatting only no content change.
ACKs for top commit:
Kixunil:
Enthusiastic ACK 2f7bf1e7be
apoelstra:
ACK 2f7bf1e7be
Tree-SHA512: e63a2fba5a2334742bd6f701b04d37af8ffcc85de71e0ca40457a1198eff2d26b673a718a352ba2129e5168c69ee723c78dc45ecd3dda9eaed9446ae7f4df2e0
Once `U256` was made private, we lost the ability to check whether a
valid difficulty transition was made in the chain, since `Target`
no longer exposes any arithmetic operations.
6cab7beba3 Deprecate min/max_value methods (Tobin C. Harding)
5fbbd483ea Use MIN/MAX consts instead of min/max_value (Tobin C. Harding)
3885f4d430 Add MIN/MAX consts to amounts (Tobin C. Harding)
Pull request description:
The new MSRV (1.48.0) uses associated consts MAX/MIN instead of functions, we had functions to be compliant with the old MSRV.
~Remove all methods `min_value` and `max_value` including calls to these methods on stdlib types.~
PR is now split into three patches:
- patch 1: Add missing associated consts MIN/MAX as needed
- patch 2: Use consts instead of method calls
- patch 3: Deprecate methods `min_value` and `max_value`
ACKs for top commit:
sanket1729:
ACK 6cab7beba3
apoelstra:
ACK 6cab7beba3
Kixunil:
ACK 6cab7beba3
Tree-SHA512: 60949d1bb971e0dfbab7f573b4447f889b5fa1a5f1c9ac9325a2970fe17a19ccc93418dba57f07bed7e13864b130de48b6b3741d1d80266c6144237dd4565ff7
The readme has gotten a bit messy with various contributors using
different collum width. Make it all 100 so that new contributors have
some chance of keeping it tidy.
On top of that, use "natural" line breaks if it assists reading/editing
i.e., don't be dogmatic about column length.
c4c64c0dc5 Test with minimal dependency versions (Martin Habovstiak)
d5655d503a Bump core2 dependency from 0.3.0 -> 0.3.2 (Tobin C. Harding)
Pull request description:
This is work originally done by Kixunil in #1272, I picked it up to help out. The only changes I made were rebasingg, updating the recent lock file, adding `--locked` to hashes contrib file, and adding a co-developed-by tag for accountability.
It could happen that we unknowingly depend on a new version of a crate without updating `Cargo.toml`. This could cause resolution issues for downstream users. It's also unclear for outsiders to know with which dependencies did we test the crate.
This change commits two lock files: `minimal` and `recent`. `minimal` contains minimal dependency versions, while `recent` contains dependency versions at the time of making the change.
Further, this adds CI jobs to test with both lock files, CI job for `internals` crate, removes old `serde` pinning and prints a warning if `recent` is no longer up to date. (We may have to override it somehow if any crate breaks MSRV.)
The documentation is also updated accordingly.
Closes#1230
ACKs for top commit:
apoelstra:
ACK c4c64c0dc5
Kixunil:
ACK c4c64c0dc5
Tree-SHA512: 7d386e96ab747f6a6bafeea828ac65bd8bb11975eaa3408acecac369cd2f235f6e9d4c57202be18a3dc2eeb2a2df532d73e4d35cd1f3fbf092eb6414c55b1524
Our previous MSRV did not support MIN/MAX associated consts so we had
methods min/max_value. Now that our MSRV is Rust 1.48.0 we can use the
consts.
Deprecate min/max_value methods in favor of MIN/MAX associated conts.
We currently use the functions `min_value` and `max_value` because the
consts were not available in Rust 1.41.1, however we recently bumped the
MSRV so we can use the consts now.
It could happen that we unknowingly depend on a new version of a crate
without updating `Cargo.toml`. This could cause resolution issues for
downstream users. It's also unclear for outsiders to see which
dependencies we tested the crate with.
This change commits two lock files: `minimal` and `recent`. `minimal`
contains minimal depdendency versions, while `recent` contains
dependency versions at the time of making the change.
Further, this adds CI jobs to test with both lock files, CI job for
`internals` crate, removes old `serde` pinning and prints a warning if
`recent` is no longer up to date. (We may have to override it somehow if
any crate breaks MSRV.)
The documentation is also updated accordingly.
Co-developed-by: Tobin C. Harding <me@tobin.cc>
Closes#1230
ab4a48c8ba ci: use new fuzzing cfg flags when fuzzing bitcoin (but not hashes) (Andrew Poelstra)
6649e15193 add README note explaining how to disable crypto for fuzzing (Andrew Poelstra)
283b7d6e51 hashes: rename fuzzing cfg parameter to bitcoin_hashes_fuzz (Andrew Poelstra)
Pull request description:
A custom `cfg` flag can be turned on or off by the user. Our current use of `cfg(fuzzing)` is impossible to turn off when using honggfuzz, which makes it impossible to fuzz without the broken crypto. This causes trouble for some downstream crates and also makes it hard for us to fuzz our own library.
Companion to rust-secp PR (TODO open this) which does effectively the same thing.
Fixes#1587.
ACKs for top commit:
tcharding:
ACK ab4a48c8ba
Kixunil:
ACK ab4a48c8ba
Tree-SHA512: c873fbd7d39fc74ae4e67a28534b253b4a09b37b5985fefde944a3c2fbe74da7200ab666b8eae6b6a4916ceff3a8d0c6278d12abd3ae85884017de1c69c5dffe
1c3bbd4bf2 internals: Remove attribution from all files (Tobin C. Harding)
99673ab5c4 hashes: Introduce SPDX license identifiers (Tobin C. Harding)
984fe69448 bitcoin: Remove attribution from all files (Tobin C. Harding)
Pull request description:
Please note, whether or not we need a per-file license comment is out of scope for this PR. This PR leaves us with the most simple per-file solution possible and leaves the merit of per-file license comment to be discussed on another day.
Simplify the per-file license stuff by doing:
- Remove the attribution line from each file.
Currently we have a mishmash of attribution lines accompanying the SPDX identifier. These lines are basically meaningless because:
- The date is often wrong
- The original author attributed is not the only contributor to a file
- The term "rust bitcoin developers" is basically just noise
- Introduce SPDX license identifiers into `hashes` and remove attribution line (ie, make `hashes` uniform with `bitcoin`)
Required before merge please:
- [x] ack from apoelstra because as the library original author many of the changes in this PR remove his name
- [x] ack from Kixunil because he had some concerns in the issue descussion
Fix: #1816
ACKs for top commit:
Kixunil:
ACK 1c3bbd4bf2
sanket1729:
ACK 1c3bbd4bf2
apoelstra:
ACK 1c3bbd4bf2
Tree-SHA512: c5ac05c5eb23b3b6a760f707c344b22f5871a4dedee4990b1840f57e4cee1d38560ff4507c354bbf29bc8ff05a179d95d7e100fcf19bd93c5362344a352c7b5a
fc7c251502 Move weight constants in the `Weight` type (Riccardo Casatta)
Pull request description:
deprecate constants::MAX_BLOCK_WEIGHT and constants::MIN_TRANSACTION_WEIGHT to nicely redirect users to the constants in the Weight type
ACKs for top commit:
Kixunil:
ACK fc7c251502
apoelstra:
ACK fc7c251502
Tree-SHA512: 4072688671a1471a87845afa842351db96c321a48cb33ab67bf1ff92ec3914bbb910bfb43be562ea3920416fa038967f81f180d51fc1ade6801cce0c1977a2a7
As we did for the `bitcoin` crate, remove attribution from all files in
the `internals` crate.
While we are at it add an SPDX line to the few files missing it, whether
this license nonsense is even needed is left as an argument for another
day.
Justification:
Currently we have a mishmash of attribution lines accompanying the SPDX
identifier. These lines are basically meaningless because:
- The date is often wrong
- The original author attributed is not the only contributor to a file
- The term "rust bitcoin developers" is basically just noise
Just remove all the attribution lines and be done with it.
Whether or not every file needs an explicit license comment is out of
scope for this patch; in the `bitcoin` crate we use SPDX identifiers
because they are a single line with no loss of "benefit" over any longer
form.
Use SPDX identifiers in `hashes`. Drop the mention of re-licensing code
from Apache to CC0-1 (because the original code was written by Andrew
as well as the copied code then if the argument ever comes up it can be
easily countered).
Currently we have a mishmash of attribution lines accompanying the SPDX
identifier. These lines are basically meaningless because:
- The date is often wrong
- The original author attributed is not the only contributor to a file
- The term "rust bitcoin developers" is basically just noise
Just remove all the attribution lines and be done with it. While we are
at it add an SPDX line to the few files missing it, whether this license
nonsense is even needed is left as an argument for another day.
dd4ad9444e Hardcode expected weight in txin_txout_weight_tests (Peter Todd)
Pull request description:
Rational: the expected weight is fixed so this both ensures we don't accidentally change it somehow, and makes it easier to re-use these test cases in other codebases (eg python-bitcoinlib).
ACKs for top commit:
apoelstra:
ACK dd4ad9444e
tcharding:
ACK dd4ad9444e
Kixunil:
ACK dd4ad9444e
Tree-SHA512: 4769a4bb8695f4f4c95e258bb5f06a232090b14c3d9159d6d5de2d09d7fc934a1b920b90cc09677a88fc0cf37ac21ed27794692dff2c73df4252c9551dc10fc2
2860aae1a5 fuzz: don't fuzz hashes against RustCrypto (Andrew Poelstra)
6467728202 fuzz: disable tests unless 'cfg(fuzzing)' is passed; update README for reproducing failures (Andrew Poelstra)
6e2ee5be66 fuzz: run 'cargo fmt' on all the fuzz targets (Andrew Poelstra)
9cfc0fcd81 fuzz: add contrib/test.sh so we at least 'cargo test' it in CI (Andrew Poelstra)
933ecb19e1 fuzz: fix warnings, clippy lints, 1.48.0 failures (Andrew Poelstra)
fd88e48696 fuzz: remove AFL support (Andrew Poelstra)
ab467cb091 fuzz: make hongfuzz fuzzing the default feature (Andrew Poelstra)
6f754df231 fuzz: add fuzzing README (Andrew Poelstra)
f093765efe fix fuzz.sh and cycle.sh to use generated lists of targets (Andrew Poelstra)
6534f22362 fuzz: auto-generate CI and Cargo.toml files (Andrew Poelstra)
8021034d86 rename travis-fuzz.sh to fuzz.sh; partially patch CI (Andrew Poelstra)
0be75f7edc move hashes/fuzz into main fuzz/ directory (Andrew Poelstra)
5a891dec2d move bitcoin fuzz targets into bitcoin/ subdirectory (Andrew Poelstra)
e3111c748b move bitcoin/fuzz into repo root; add to workspace (Andrew Poelstra)
Pull request description:
Several big changes here:
* Moves fuzzing to its own workspace with a `contrib/test.sh` etc so that CI will check that it compiles
* FIx all warnings, clippy lints, MSRV problems, etc.; mostly move to Rust 2018
* Merge `hashes/` fuzztests into workspace
* Rewrite all scripts; add file that auto-generates CI fuzz job and Cargo.toml so we don't have to manually keep these in sync
* Remove bitrotted and partial AFL support.
Supercedes #1422
I suspect the hashes fuzztests will actually fail since we haven't touched them in so long. Will address that if CI fails here.
ACKs for top commit:
sanket1729:
ACK 2860aae1a5
tcharding:
ACK 2860aae1a5
Tree-SHA512: b1aa3d6fac75fee51966f1d3f3245784e331bdea2a3fa7d6609bc4196c34f81acb7701faf8f269c3741568ea100438f24a2f06e75c8d01cb84c8b22d7886f1dd
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.
Rational: the expected weight is fixed so this both ensures we don't
accidentally change it somehow, and makes it easier to re-use these test
cases in other codebases (eg python-bitcoinlib).
Andrew Poelstra
kshitjj
Martin Habovstiak
Wilmer Paulino
yancy
Tobin C. Harding
Riccardo Casatta
Peter Todd