We do not have a policy to re-export things from other modules just
because they are in the public API - I don't see any other reason to
re-export this error, users should go to the `validation` module
directly to get the error type.
6ab8f99731 ci: fix semver-checks master (Jose Storopoli)
Pull request description:
Ok now I think I've nailed this! 🚀Closes#3018.
## Summary
This PR fix the permissions by adding a secondary job, `semver-checks-pr-label`, that runs only if the `semver-checks` completes and does not fail, i.e. we have either Semver API breaks.
This is a secure job according to internal discussions and https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
## Implementation notes
We split the semver checks into the actual check and labeling. This is due to the fact that we were having several permission issues and the original implementation was insecure. Also it is currently failing on several PRs.
1. `semver-checks.yml`: checks for API semver breaks. Upon finding API semver-checks, it creates a file named `semver-break` that has the PR number inside. If this file is present we upload an artifact representing that the API semver was broken with the PR number.
2. `semver-checks-pr-label.yml`: runs after the `semver-checks.yml` is completed. It uses `actions/github-script` (in JavaScript) to list the previous workflow artifacts and, if finds that an API semver break is present, adds a corresponding label and a comment to the PR that is inside the file `semver-break`. We sanitize the hell out of the thing to be a number only, both in BASH but also in JavaScript.
## How I tested this?
1. I merged this PR to my `master` branch in my `storopoli/rust-bitcoin` repo.
2. I've set the following settings in the repo settings to mimic what we have for `rust-bitcoin`:

3. I've made a PR (cherry-picked from Toby) that breaks semver, see https://github.com/storopoli/rust-bitcoin/pull/10. It correctly labelled as `API break` and added a comment to the PR

ACKs for top commit:
Kixunil:
ACK 6ab8f99731
apoelstra:
ACK 6ab8f99731 thanks for sticking with this\!\!
Tree-SHA512: 27385d6d4a40b5ffc3b95f00ad34010fabe5f1f9442d258b4cb433807bc663fc70b98c7c632048f05929cad073fd81ac6217f72016740b72db7575dac9d3939b
Now that the `define_extension_trait` can handle function parameters on
individual lines revert the manual formatting that was introduced in
PR #2955.
Refactor only, no logic changes.
The `define_extension_trait` macro currently does not allow for a
trailing comma in the function paramater list, this occurs when the
function paramaters are put on individual lines (eg by `rustfmt`).
Extend the macro to support function paramaters being on individual
lines. This should have been done originally instead of my manual
override of formatting - bad Tobin no biscuit.
86f82b487d Remove unused variable from LockTime example (Shing Him Ng)
Pull request description:
Following up on [a comment](https://github.com/rust-bitcoin/rust-bitcoin/pull/3026#discussion_r1676744486) from #3026 and removing an unused variable from the LockTime example
ACKs for top commit:
tcharding:
ACK 86f82b487d
Kixunil:
ACK 86f82b487d
Tree-SHA512: 526d42e68297e9670953f7aadfbf624b7bc20f1bf95b3e5ff66a58871967e38eca917d9ee9c385cf40ed7d9a867cb081ef17f2aa3683138f6fc55a74414a83f6
2169b75bba Use lower case error messages (Jamil Lambert, PhD)
Pull request description:
Error messages should be lower case, except for proper nouns and variable names. These have all been changed.
~~They should also state what went wrong. Some expect error messages were positive, giving the correct behaviour or correct input. These have been changed so that they are now negative, i.e. saying what went wrong.~~
EDIT: After further discussion it was decided not to change the expect messages.
ACKs for top commit:
Kixunil:
ACK 2169b75bba
tcharding:
ACK 2169b75bba
Tree-SHA512: 92442c869e0141532425f6fca5195fd319b65026f68c4230a65ad70253565d98931b2b44ee202975c307280525c505147e272297dc81207312e40c43d007021c
7874db8fc3 Throw error instead of panic when from_second_ceil input is too large (Shing Him Ng)
Pull request description:
Update `from_second_ceil` per [comment](https://github.com/rust-bitcoin/rust-bitcoin/issues/3029#issuecomment-2227459248) and add unit tests
Resolves#3029
ACKs for top commit:
Kixunil:
ACK 7874db8fc3
tcharding:
ACK 7874db8fc3
Tree-SHA512: 0d60397f867d4536ff00b81441c27ea3dc4bf9e5ecc2fb5afbe50cb3153101df54c2bb5056da1916d83c3e84367f987f5bac07a381b7433a5701a0ea8a587f95
580c2cf246 Automated update to Github CI to rustc nightly-2024-07-14 (Update Nightly Rustc Bot)
Pull request description:
Automated update to Github CI workflow `rust.yml` by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action
ACKs for top commit:
tcharding:
ACK 580c2cf246
Tree-SHA512: 0b01575733d6b4d70be9b00d55d53670db33324498cef991e5beca052a3b59bcbb128351a677ab83773855b3b57cacd4c7f08e93079387d67229d1014666cfae
84dd04cf60 Rename variable assignment (yancy)
Pull request description:
The type created after assignment is a Weight type. Using a var name vb which is short for virtual byte is incorrect.
Pulled this out of stale PR 2215
ACKs for top commit:
shinghim:
ACK 84dd04cf60
apoelstra:
ACK 84dd04cf60
Kixunil:
ACK 84dd04cf60
Tree-SHA512: 1bfc875f53037b2c1e8da25fe44e9ca3303981bdce4e48661a8fb2061833e3cd90318d854f7119c805e861cd8a591697378f829f32eb74ac99a71dc4c947abde
301fe9fad9 Move impl above tests (yancy)
Pull request description:
It's common in other modules for the tests to be at the end of the file. Moving the tests to the bottom helps the code base uniformity.
Pulled from stale PR 2215
ACKs for top commit:
shinghim:
ACK 301fe9fad9
tcharding:
ACK 301fe9fad9
Kixunil:
ACK 301fe9fad9
Tree-SHA512: c749c4c2c5fba2c8a57fe034d4ef5d34ff26baddb1b2148b9778dc554c955ad31c7bc83b89a3647228bf5f175adddb03105a1e494b28f5a7955369abaa11cfd1
64c31cfb97 Move locktimes and Sequence to primitives (Tobin C. Harding)
Pull request description:
The `absolute` and `relative` locktimes as well as the `Sequence` are all primitive bitcoin types.
Move the `Sequence`, and `locktime` stuff over to `primitives`.
There is nothing surprising here, the consensus encoding stuff stays in `bitcoin` and we re-export everything from `blockdata`.
Note please `Sequence` is no longer publicly available at `bitcoin::transaction::Sequence` but it is available at `bitcoin::Sequence`.
ACKs for top commit:
Kixunil:
ACK 64c31cfb97
apoelstra:
ACK 64c31cfb97
Tree-SHA512: 968aa595bfb53e8fcfa860dae797ec5381ed49c67326a8ef9494086ec65d737502dffe4b24143e159042d07c59c5109d50103029082f87e1c3c26671e975f1b3
02e7933fe4 Rename key field in Key to key_data (Shing Him Ng)
Pull request description:
Follow-up change from [a comment](https://github.com/rust-bitcoin/rust-bitcoin/pull/3022#issuecomment-2226166039) in #3022 that updates the `key` field in the PSBT `Key` to `key_data`, which more closely follows the doc
ACKs for top commit:
tcharding:
ACK 02e7933fe4
Kixunil:
ACK 02e7933fe4
Tree-SHA512: 67cc621e9f5b326f96c3f08e340acecf60b1d03d25bbd012998bab34f49e96c4dca9f5dc24047f743f1a1b6fcaa5d3c166f2e4cf2ea96d4375c9b1b041d3196f
2b56f763d0 hashes: Remove to/from/as_raw_hash (Tobin C. Harding)
Pull request description:
In an effort to shrink the API of `hashes` remove the `from_raw_hash`, `to_raw_hash`, and `as_raw_hash` inherent functions from types created with the `hash_newtype` macro.
There are a few reasons why this is favourable:
- It allows stable crates to use the macro and not expose unstable `hashes` types in their API.
- It makes types created with the macro less "general" in the sense that its more obscure to just hash any data into them. This allows us to write cleaner APIs in `rust-bitcoin`.
ACKs for top commit:
Kixunil:
ACK 2b56f763d0
apoelstra:
ACK 2b56f763d0
Tree-SHA512: 3d73aa8250dd775994623c9201dd819256acf2ec82526b3537da74c9e19c2ac5e8bba358a2171f7b02342804cb6b4d5ac4dca88d912b3d46d14e3bc35dd5cb91
The `absolute` and `relative` locktimes as well as the `Sequence` are
all primitive bitcoin types.
Move the `Sequence`, and `locktime` stuff over to `primitives`.
There is nothing surprising here, the consensus encoding stuff stays in
`bitcoin` and we re-export everything from `blockdata`.
164b72e07b Update Key documentation (Shing Him Ng)
Pull request description:
The documentation for `Key` was a bit confusing since `<key> := <keylen> <keytype> <keydata>` was right above the `key` field, when in reality the `key` field represents the key data. Moving the documentation that describes a `Key` as a whole to the struct itself and specifying that `key` represents key data will hopefully clear things up a bit
ACKs for top commit:
Kixunil:
ACK 164b72e07b
tcharding:
ACK 164b72e07b
Tree-SHA512: 33c2b24d3006a0ed85a5d96351e0a01c1365c8ea01472233b024de54941319cdbefa0126f8b9538385e8f33ba7e2e3895f0dc5b6a36a1c501c8b97ebbede6502
8dcecfc144 Remove midstate from the GeneralHash and HashEngine traits (Tobin C. Harding)
Pull request description:
Midstates are not generic objects; they don't have universal cryptographic properties and if you are using them you should be using a specific midstate type. Therefore it shouldn't be part of `GeneralHash` or `HashEngine`. Furthermore, in practice it seems like `sha2` midstates are the only ones that anybody uses, at least in bitcoin.
Remove the midstate stuff from the `GeneralHash` and `HashEngine` traits. Keep the `midstate` functionality as inherent functions if it is used internally. Keep the functionality on `sha256` as inherent public functions.
Done as a first step towards #2918.
ACKs for top commit:
apoelstra:
ACK 8dcecfc144
Kixunil:
ACK 8dcecfc144
Tree-SHA512: 495fe6a4d852ecf51c21acc1ae7215f1914f6d12377eb7e6da678b8ffb2c3c8b06976aa5290010a88d5a9cbc56752fcbdf740cb27b22ada8079a69dcf2e32dc0
bcf6d2839e Introduce scriptPubkey extension traits (Tobin C. Harding)
ee333defa4 Remove path from ScriptBuf (Tobin C. Harding)
Pull request description:
Done in preparation for moving the script types to `primitives`.
Add three public traits, one each for the three `script` types: `Builder`, `ScriptBuf`, and `Script`.
ACKs for top commit:
Kixunil:
ACK bcf6d2839e
apoelstra:
ACK bcf6d2839e
Tree-SHA512: 0ad11e474ddf1183d0119e36454cb4fd18d49a68655d274df800c6ef20afa7f8d0fdecd415c02595ea67a011e3a842b7ccc23c2d58f92ed9acbdc7f277fbd217
e2b0fd33be Specify required_height in variable name when comparing to other height (Shing Him Ng)
Pull request description:
Update the variable names for `h`/`height` to `required_height` in instances where it was being used to create another height or used comparatively i.e. `required_height + 1` or `required_height < height`
Resolves#2553
ACKs for top commit:
Kixunil:
ACK e2b0fd33be
tcharding:
ACK e2b0fd33be
Tree-SHA512: 05fa8df721148d9bbc6eaa2b14c2583d3415c3ab0d53b8fdf39d7b9e9a28463265e43abfc430dfc7f6d0b53cd17767f5cad83c2de73b8a153aeb6befeeac84bc
In an effort to shrink the API of `hashes` remove the `from_raw_hash`,
`to_raw_hash`, and `as_raw_hash` inherent functions from types created
with the `hash_newtype` macro.
There are a few reasons why this is favourable:
- It allows stable crates to use the macro and not expose unstable
`hashes` types in their API.
- It makes types created with the macro less "general" in the sense that
its more obscure to just hash any data into them. This allows us to
write cleaner APIs in `rust-bitcoin`.
Done in preparation for moving the script types to `primitives`.
The script types have a bunch of functionality to support scriptPubkeys,
and scriptPubkeys are an address thing.
Create a module under `address` and in it create a bunch of extension
traits to hold all scriptPubkey functionality.
Includes adding an ugly-as-hell macro to create the traits.
Midstates are not generic objects; they don't have universal
cryptographic properties and if you are using them you should be using a
specific midstate type. Therefore it shouldn't be part of `GeneralHash` or
`HashEngine`. Furthermore, in practice it seems like `sha2` midstates are
the only ones that anybody uses, at least in bitcoin.
Remove the midstate stuff from the `GeneralHash` and `HashEngine`
traits. Keep the `midstate` functionality as inherent functions if it is
used internally. Keep the functionality on `sha256` as inherent public
functions.
360d1fb1bb hashes: Use $crate in macro (Tobin C. Harding)
Pull request description:
Depending on types being in scope when calling macros is bad practice but we have mistakenly done so in `internal_macros` when using the `FromSliceError`.
Use `$crate::FromSliceError` in the macro and remove import statements.
ACKs for top commit:
Kixunil:
ACK 360d1fb1bb
apoelstra:
ACK 360d1fb1bb
Tree-SHA512: e93264ed7313e6f128cc9a441f68100fe423263aa9677c194d768cf1b04058bfc840027540e1c9d82ff5e925ddc165f34b2c6926987f610caa1686ea27a955eb
ac4db6369d witness: Add Witness::witness_script inspector (Steven Roose)
6cc6c8621a witness: Add Witness::taproot_annex (Steven Roose)
b0848022eb witness: Add Witness::taproot_control_block (Steven Roose)
ef336e1387 witness: Improve Witness::tapscript (Steven Roose)
e48a2e4225 script: Add Script::redeem_script inspector (Steven Roose)
Pull request description:
Bundled these because they are very similar. Got a bunch of larger changes coming up based on these. I've been using these for a while for TXHASH work.
ACKs for top commit:
apoelstra:
ACK ac4db6369d but will need to wait for next release. I think we should merge these as-is although they will be much clearer after we do script tagging.
tcharding:
ACK ac4db6369d
Tree-SHA512: e1590d1bdc8b91aeba137453f0cdaa7e1ae6df3c8e9e1e0f087ed9be1a6beaf2286818379247d26c5dd27d07c12c10433db1c9b9a71667ab4d8d37c7deff1373
e2c3694184 rustfmt: Use show_parse_errors (Tobin C. Harding)
Pull request description:
There are no behaviour changes with this patch applied.
In https://github.com/rust-lang/rustfmt/pull/5961 the `hide_parse_errors` was changed to `show_parse_errors` with default `true`.
Since we run the formatter with nightly we are getting the following warning
Warning: the `hide_parse_errors` option is deprecated. Use
`show_parse_errors` instead
Rename the variable and keep the default value `true`.
ACKs for top commit:
Kixunil:
ACK e2c3694184
storopoli:
ACK e2c3694184
apoelstra:
ACK e2c3694184
Tree-SHA512: f75f3abf194d65e0ef2a1bef2544bc94ed1c4911b94cbc6bc5700ecb8e6ec87c5564b9711a7dde8ca1a83400e1bf3154d25574a485e9893049be0a46f2c95e33
Depending on types being in scope when calling macros is bad practice
but we have mistakenly done so in `internal_macros` when using the
`FromSliceError`.
Use `$crate::FromSliceError` in the macro and remove import statements.
dc96475f58 Add/fix alloc features (Tobin C. Harding)
Pull request description:
Eventually we would like all our crates other than `bitcoin` to be able to be used without an allocator. Currently, and during crate smashing, this is not that useful because so much of the code comes from `bitcoin` and relies on the availability of an allocator.
As an initial step, add the `alloc` feature to `addresses` , `base58`, and `primitives`.
In order to to keep `--no-default-features` builds working make the crates empty if the `alloc` feature is not enabled. This is a suboptimal solution because the error messages users will get when they forget to enable `alloc` will be confusing (eg something like primitives does not contain Transaction). However our CI script (`run_task.sh`) expects `--no-default-features` to build cleanly (as do I).
ACKs for top commit:
apoelstra:
ACK dc96475f58
Kixunil:
ACK dc96475f58
Tree-SHA512: 28006ad638e72d3c712becaf94f6aaddc559fb2f7e7ad0d0810348fe979fb61e32f53e5b20894e472c5ac9e2b7f80cba6a3f0e12b766b817f412a927957ae3a2
40bee24de7 Run the formatter (Tobin C. Harding)
Pull request description:
I don't want to wait for the bot, just run the formatter now.
No manual changes.
ACKs for top commit:
apoelstra:
ACK 40bee24de7 fine by me, but will give Kix 2 days to express displeasure, at which point the bot will pretty-much be ready to run
Kixunil:
ACK 40bee24de7
Tree-SHA512: a9e54305062900dc18f73c61deef0af74702c17f7040614f5f8697a47dd084d07a9c321878c5e29910e2a8d129bac23b95ee1023176beddf2e915544b13e7b0c
9933fa0dd5 contributing: fix instructions for the semver CI (Jose Storopoli)
213566f34b ci: semver-checks should run on rust stable (Jose Storopoli)
0fa2b0b16a ci: add all-features semver-checks (Jose Storopoli)
Pull request description:
Crates missing:
- `bitcoin_hashes`
- `bitcoin-units`
- `bitcoin-io`
Also adds:
1. corrects a small error in the CONTRIBUTING.md; and
2. runs on `stable` since `cargo-semver-checks` do not support `nightly` (rustdocs JSON format breaks almost daily)
Closes#2999.
ACKs for top commit:
Kixunil:
ACK 9933fa0dd5
tcharding:
ACK 9933fa0dd5
Tree-SHA512: c5251cec7c7189e7ef16a657ef35723b2c3e8fa7262c452fc83828dc16215107259d445f911916ec0716ea6e20ce59d0910b9a4fa004f150322fd4fcd00d15c5
d05723c401 Optimize base58 on small inputs (Martin Habovstiak)
Pull request description:
Most base58 strings in Bitcoin are somewhat short. There was previously an "optimization" putting part of the input on stack which was removed in #2759 because it actually made the code slower. This appears to be mostly because of branches caused by using `iter::Chain`.
Manually splitting the iterations into two helped bring the performance close to what #2759 achieved but that still wasn't worth it. But given that we know the input length in many cases (it's just a slice) we can determine whether it'll fit a buffer upfront and then just call different functions which don't have the branches in loops. To avoid having two functions this uses generics instead. Further, we increase the buffer length to 128 and use `ArrayVec` from `internals` which internally avoids initializing the buffer thanks to `MaybeUninit`
In total this increases performance by around 4% on my machine.
ACKs for top commit:
tcharding:
ACK d05723c401
apoelstra:
ACK d05723c401
Tree-SHA512: a12fa15ef2b58282a69545685dbbe027d4e73a285651a9fe05de5a039a11c5da2fc1000eb369801e77584cd403bb0e972f5f01bcab0d1e62624f054992b8b83d
Most base58 strings in Bitcoin are somewhat short. There was previously
an "optimization" putting part of the input on stack which was removed
in #2759 because it actually made the code slower. This appears to be
mostly because of branches caused by using `iter::Chain`.
Manually splitting the iterations into two helped bring the performance
close to what #2759 achieved but that still wasn't worth it. But given
that we know the input length in many cases (it's just a slice) we can
determine whether it'll fit a buffer upfront and then just call
different functions which don't have the branches in loops. To avoid
having two functions this uses generics instead. Further, we increase
the buffer length to 128 and use `ArrayVec` from `internals` which
internally avoids initializing the buffer thanks to `MaybeUninit`
In total this increases performance by around 4% on my machine.
1324ae88ee Automated update to Github CI to rustc nightly-2024-07-10 (Update Nightly Rustc Bot)
Pull request description:
Automated update to Github CI workflow `rust.yml` by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action
ACKs for top commit:
tcharding:
ACK 1324ae88ee
Tree-SHA512: 8689a061a578f6f435d4e3f885d6b952b8d7d0c618928ba5b7f7a92ad2311f2799251f72ab3b2170f97ae390605f2b6b29b1249c70b7e53933006be23b3ae6cf
There are no behaviour changes with this patch applied.
In https://github.com/rust-lang/rustfmt/pull/5961 the
`hide_parse_errors` was changed to `show_parse_errors` with default
`true`.
Since we run the formatter with nightly we are getting the following
warning
Warning: the `hide_parse_errors` option is deprecated. Use
`show_parse_errors` instead
Rename the variable and keep the default value `true`.