685e5101ce Add wasm dev-deps using CI script (Tobin C. Harding)
Pull request description:
We only test WASM in CI using a stable toolchain however because we have a target specific dev-dependencies section the wasm deps get pulled in during MSRV builds - this breaks the MSRV build.
Instead of including WASM dev-dependencies in the manifest we can dynamically modify the manifest when running the WASM tests. We do this already to add the `crate-type` section so this is not really that surprising to see in the CI script.
Doing so allows us to stop pinning the transitive `syn` dependency also which is included in the dependency graph because of `wasm-bingen-test`.
Originally part of #2093
ACKs for top commit:
apoelstra:
ACK 685e5101ce
sanket1729:
ACK 685e5101ce. Removing wasm from lock-files is a win
Tree-SHA512: ad607a8a8af329e9830d9284a95a2540bf15a2ceda826b8d1c0312ee094f1f5f54599ee2faa6b611439997c349bdd9a29e6d5ae447bff96a9a538753434e2248
10374af75c Make error types uniform (Tobin C. Harding)
43d3306822 Use explicit error::Error impl instead of the default (Tobin C. Harding)
2512dbafc2 Remove impl_std_error macro (Tobin C. Harding)
6933ca4fc2 Add suffix to HiddenNodes error type (Tobin C. Harding)
2b40ea24fb Add suffix to IncompleteBuilder error type (Tobin C. Harding)
f41416a0ea Add suffix to UnknownMagic error type (Tobin C. Harding)
5658dac024 Add suffix to UnknownChainHash error type (Tobin C. Harding)
2fb71dd943 Move p2p error types to bottom of file (Tobin C. Harding)
39314ad52f Move error code to match conventional layout (Tobin C. Harding)
Pull request description:
PR aims to achieve two things:
- Make error code brain dead easy to read
- Get error code closer to being ready for v1.0
The first 8 patches are pretty basic, and are broken up into really small changes. The last patch is much bigger, it has a long git log to explain it but reviewing should not take too much brain power.
This PR does not introduce anything new, it just applies what we have been doing recently with errors. Before v1.0.0 others will likely want to re go over all the error types. As such I believe this PR can be merged under the one ack carve-out.
### TODOs (future PRs)
We have a few errors that still need splitting up:
- Split up `merkle_tree::block::MerkleBlockError`
- Split up `psbt::error::Error`
- Split up `IncompleteBuilderError`
Also, all error From's should probably have `#[inline]`, I noticed late in the process and did not have the heart to visit every error again.
ACKs for top commit:
apoelstra:
ACK 10374af75c
clarkmoody:
ACK 10374af75c
Tree-SHA512: 4f4f3533f42dc11af8e7978f3272752bb56d12a68199752ed4af0c02a46a87892b55c695b7007bc3d0bdf389493068d068e2be1780e8c3008815efec3a02eedf
be8aee6968 Remove stale link (Tobin C. Harding)
7d54cd3485 Fix typo in docs (Tobin C. Harding)
Pull request description:
Do 2 trivial docs fixes, found while investigating #2103
ACKs for top commit:
vincenzopalazzo:
ACK be8aee6968
sanket1729:
ACK be8aee6968
Tree-SHA512: 8ed50ffc30a01424fb9591c3079c4e107b4783371e5fc95df6183b95ba2bca7db243f5e1408618f7b6c024ed31f9498b68a6d12c2994839107d556246c9e25cf
We only test WASM in CI using a stable toolchain however because we have
a target specific dev-dependencies section the wasm deps get pulled in
during MSRV builds - this breaks the MSRV build.
Instead of including WASM dev-dependencies in the manifest we can
dynamically modify the manifest when running the WASM tests. We do this
already to add the `crate-type` section so this is not really that
surprising to see in the CI script.
Doing so allows us to stop pinning the transitive `syn` dependency also
which is included in the dependency graph because of `wasm-bingen-test`.
On our way to v1.0.0 we are defining a standard for our error types,
this includes:
- Uses the following derives (unless not possible, usually because of `io::Error`)
`#[derive(Debug, Clone, PartialEq, Eq)]`
- Has `non_exhaustive` unless we really know we can commit to not adding
anything.
Furthermore, we are trying to make the codebase easy to read. Error code
is write-once-read-many (well it should be) so if we make all the error
code super uniform the users can flick to an error and quickly see what
it includes. In an effort to achieve this I have made up a style and
over recent times have change much of the error code to that new style,
this PR audits _all_ error types in the code base and enforces the
style, specifically:
- Is layed out: definition, [impl block], Display impl, error::Error impl, From impls
- `error::Error` impl matches on enum even if it returns `None` for all variants
- Display/Error impls import enum variants locally
- match uses *self and `ref e`
- error::Error variants that return `Some` come first, `None` after
Re: non_exhaustive
To make dev and review easier I have added `non_exhaustive` to _every_
error type. We can then remove it error by error as we see fit. This is
because it takes a bit of thinking to do and review where as this patch
should not take much brain power to review.
In a further effort to make the code brain-dead easy to read; use an
explicit implementation of `std::error::Error` that returns `None`
instead of relying on the default trait implementation.
We would like the codebase to be optimized for readability not ease of
development, as such code that is write-once-read-many should not use
macros.
Currently we use the `impl_std_error` macro to implement
`std::error::Error` for struct error types. This makes the code harder
to read at a glance because one has to think what the macro does.
Remove the `impl_std_error` macro and write the code explicitly.
f949fedb6d Bump model-checking/kani-github-action from 0.37 to 1.0 (dependabot[bot])
Pull request description:
Bumps [model-checking/kani-github-action](https://github.com/model-checking/kani-github-action) from 0.37 to 1.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/model-checking/kani-github-action/releases">model-checking/kani-github-action's releases</a>.</em></p>
<blockquote>
<h2>Kani Verifier CI Action 1.0</h2>
<h2>Major Changes</h2>
<ul>
<li>Add <code>kani-version</code> field to github action, which defaults to latest version of <code>Kani</code></li>
</ul>
<h2>What's Changed</h2>
<ul>
<li>Decouple <code>kani</code> version from <code>kani-github-action</code> version by <a href="https://github.com/jaisnan"><code>@jaisnan</code></a> in <a href="https://redirect.github.com/model-checking/kani-github-action/pull/45">model-checking/kani-github-action#45</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a href="https://github.com/model-checking/kani-github-action/compare/v0.37...v1.0">https://github.com/model-checking/kani-github-action/compare/v0.37...v1.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="e621a98d83"><code>e621a98</code></a> Decouple <code>kani</code> version from <code>kani-github-action</code> version (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/45">#45</a>)</li>
<li>See full diff in <a href="https://github.com/model-checking/kani-github-action/compare/v0.37...v1.0">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=model-checking/kani-github-action&package-manager=github_actions&previous-version=0.37&new-version=1.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
ACKs for top commit:
apoelstra:
ACK f949fedb6d
tcharding:
ACK f949fedb6d
Tree-SHA512: b1c169375dddd7a99d8835b73a7c50befa356eab2a42295d53e838bbb899611454fa0d0f7bc5cefcdb719b734921b726025e23cf6650337b3bbbb1ec1b0eb481
752adff9d1 Add method calc_height (Tobin C. Harding)
46f5588646 Add unit test for calc_tree_width (Tobin C. Harding)
Pull request description:
Add a private `PartialMerkleTree::calc_tree_width` function and a unit test to test it.
ACKs for top commit:
apoelstra:
ACK 752adff9d1
clarkmoody:
ACK 752adff9d1
Tree-SHA512: 9c4ad9f6ff47d8faad1c7c1e977427f1528af2712ceffd05357d0c9117b5fdb7b2783afc00a75cb19b853bfbd7b3895baa3a3563bdc496593cc9b06ce80dbbf8
3b60ad5567 example: Modify `taproot-psbt.rs` to make the use of prevouts clearer. (S. Santos)
Pull request description:
The `taroot-psbt.rs` example uses only one input, and therefore the current code may not make it clear that the number of prevout items must correspond to the number of transaction inputs, since the prevout slice is built within a loop.
This PR aims to make this clear to any user who wants to reuse the logic from the example code.
ACKs for top commit:
tcharding:
ACK 3b60ad5567
apoelstra:
ACK 3b60ad5567
Tree-SHA512: afad63782b0e8a459de6cf69712d31fdab860c0d4cf9f3a51c3d85544a067bd50f4febc10ec4046e3a37d9ca518bbf2460c2599f1569549701c07f8a267dfd05
dac627cc09 Feature: Psbt fee checks (junderw)
Pull request description:
Closes#2061
These new methods on Psbt will add checks for high fees by default. The threshold for "high fees" is currently set to 25000 sat/vbyte, which is about 20x higher than the highest next block fees seen on the "Mempool" website.
The primary goal of this change is to prevent users of the library from accidentally sending absurd amounts of fees.
(ie. Recently in September 2023 there was a transaction that sent an absurd amount of fees and made news in the Bitcoin world. Luckily the mining pool gave it back, but some might not be so lucky.)
There are variants of the method that allow for users to set their own "absurd" threshold using a `FeeRate` value. And there is a method that performs no checks, and the method name is alarming enough to draw attention in a review, so at least developers will be aware of the concept.
ACKs for top commit:
apoelstra:
ACK dac627cc09
tcharding:
ACK dac627cc09
Tree-SHA512: ae0beafdb50339ba3efc44a48ba19c0aeeb0a2671eb43867c1e02b807677ce99fb6b4c47b74a9ed2999f827b3edc00a8871fa4730dd12a4cb265be99437c13db
c34c709681 CI: add an automated github releases on new tags (Einherjar)
Pull request description:
Creates a `gh-release.yml` that runs on every new tag using the [`ncipollo/release-action`](https://github.com/ncipollo/release-action), which is one of the recommended actions after [GitHub's official `actions/create-release`](https://github.com/actions/create-release) was archived.
The idea is to just have a release with the source code, no binary (although if wanted I can add that as well).
A little bit of context: tcharding told me yesterday at TABConf that he copied manually all commits titles to the release notes somewhere (I think in crates.io?).
This is an easy way to do it, just copy from the GitHub release.
Finally, it is also positive to generate Releases from Tags since this increases the exposure of the repo (GitHub is highly social) while also signaling maturity.
Here's an [example](https://github.com/oven-sh/bun/releases/tag/bun-v0.8.1) that I've found in a non-related repo that has the same `generateReleaseNotes: true` as this PR proposes
<img width="857" alt="image" src="https://github.com/realeinherjar/rust-bitcoin/assets/136860407/41789514-8abf-4f58-b7ca-d2c352346923">
ACKs for top commit:
apoelstra:
ACK c34c709681
tcharding:
ACK c34c709681
Tree-SHA512: 06bc0276b5aca95e19965eadb79d0a4cf8606b222dce37f095247196fcac023458c34e35cf34fa2344bc274063e642b93b05dc796a27179567052c58ac4bc27a
c34e3cc7cc Re-write size/weight API (Tobin C. Harding)
73f7fbf520 Add code comments to transaction serialization (Tobin C. Harding)
29f20c1d0b Add segwit serialization constants (Tobin C. Harding)
Pull request description:
Audit and re-write the weight/size API for `Block` and `Transaction`. First two patches are trivial, patch 3 contains justification and explanation for this work, copied here:
```
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
```
Please note, this PR introduces panics if a sciptPubkey overflows the calculation `weight = spk.size() * 4`.
Fix#2049
ACKs for top commit:
apoelstra:
ACK c34e3cc7cc
sanket1729:
ACK c34e3cc7cc.
Tree-SHA512: 4944f652e6e362a282a5731140a9438a82d243a4c646b4627d9046a9f9cf13c476881750d432cfbc6b5fe5de1f0c4c9c44ed4569dac4bc11b55a5db28793803c
5901d35095 Add push_p2wpkh function on Witness (Tobin C. Harding)
8cd409d561 Deprecate push_bitcoin_signature (Tobin C. Harding)
Pull request description:
In order to create the witness to spend p2wpkh output one must create a `Witness` that includes the signature and the pubkey, we should have a function for this.
## Notes
The PR originally added a `push_p2wphk` method, this is now instead a constrcutor `Witness:p2wpkh` (after review discussion below).
- Patch 1 changes `push_bitcoin_signature` to take an `ecdsa::Sigtnture` instead of an `ecdsa::SerializedSignature`
- Patch 2 takes a `secp256k1::PublicKey` removing the need for an error path (discussed below).
ACKs for top commit:
sanket1729:
ACK 5901d35095
apoelstra:
ACK 5901d35095
Tree-SHA512: 646014d97daafbf0909106d8990debaf481ac6f3578f0ddf232d739c3e2d55ae1d0275abe5a4a1db1c5c192c8c5f0b5546fc65aac37b91a3729db881c5ad3dec
24e5e19ed0 Add changelog entries (Tobin C. Harding)
79f2157311 bitcoin: Grab changelog entry from 0.30.1 release (Tobin C. Harding)
Pull request description:
Gearing up for the next release add changelog entries for everything merged upto July 24.
ACKs for top commit:
apoelstra:
ACK 24e5e19ed0
clarkmoody:
ACK 24e5e19ed0
Tree-SHA512: 12761623f3d61fea77b5dfe4c505dcdb5041ec4473ae05524b818eb2d4e3cbc3b039b8f1400022916c9f2d1ee97fcccd7e7b6da0bb5f868a1b77bdcfade3d7ed
9fa2111c12 Bump model-checking/kani-github-action from 0.36 to 0.37 (dependabot[bot])
Pull request description:
Bumps [model-checking/kani-github-action](https://github.com/model-checking/kani-github-action) from 0.36 to 0.37.
<details>
<summary>Commits</summary>
<ul>
<li><a href="7c99bc77b4"><code>7c99bc7</code></a> Update Kani version to 0.37.0 (<a href="https://redirect.github.com/model-checking/kani-github-action/issues/49">#49</a>)</li>
<li>See full diff in <a href="https://github.com/model-checking/kani-github-action/compare/v0.36...v0.37">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=model-checking/kani-github-action&package-manager=github_actions&previous-version=0.36&new-version=0.37)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
ACKs for top commit:
apoelstra:
ACK 9fa2111c12
clarkmoody:
ACK 9fa2111c12
Tree-SHA512: fb7e2913718aba03915b3ee3d4644ba6acca12012466c1001fe951f35e2877cefd30db83a29c773807829af3ba3ed9f1d2539e19d107509999e507079c43b926
f31fb08651 Remove default impl from transaction version (Tobin C. Harding)
Pull request description:
There is no logical default for the transaction version number, there is only pre-bip68 (v1) and post-bip68 (v2). Uses should specify the version they want not rely on us making the choice.
(I originally added this impl to support testing, this was in hindsight the wrong thing to do, props to Sanket for noticing.)
Discussed in comments here: https://github.com/rust-bitcoin/rust-bitcoin/pull/2006#issuecomment-1732385464
ACKs for top commit:
clarkmoody:
ACK f31fb08651
apoelstra:
ACK f31fb08651
Tree-SHA512: 1112c35173d6b2e7d6c50f058b1964fc8b633615ae703b0c1231e701a3e322fd55d3a8377c7ea078f28f523b15b7de6e9eca844226fcd19528206161d75dcfdf
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 `Witness::push_bitcoin_signature` method is old and a bit stale.
Bitcoin has taproot signatures now so the name is stale, also we have
the `crate::ecdsa::Signature` type that holds the secp sig and the hash
type so we can use that instead of having two separate parameters.
Add a new, up to date, `Witness::push_ecdsa_signature` function and
deprecate the `push_bitcoin_signature` one.
There is no logical default for the transaction version number, there is
only pre-bip68 (v1) and post-bip68 (v2). Uses should specify the version
they want not rely on us making the choice.
(I originally added this impl to support testing, this was in hindsight
the wrong thing to do, props to Sanket for noticing.)
One of our stated aims is to make it possible to learn bitcoin by using
our library. To help with this aim add to private consts for the segwit
transaction marker and flag serialization fields.
158ba26a8a Feature: Count sigops for Transaction (junderw)
Pull request description:
I copied over the sigop counting logic from Bitcoin Core, but I made a few adjustments.
1. I removed 2 consensus flags that checked for P2SH and SegWit activation. This code assumes both are activated. If we were to include that, what would be a good way to go about it? (ie. If I run this method on a transaction from the 1000th block and it just so happened to have a P2SH-like input, Bitcoin Core wouldn't accidentally count those sigops because the consensus flag will stop them from running the P2SH logic. Same goes for SegWit)
3. Since there's no guarantee that we have an index from which we can get the prevout scripts, I made it into a generic closure that looks up the prevout script for us. If the caller doesn't provide it, We can only count sigops directly in the scriptSig and scriptPubkey (no P2SH or SegWit).
## TODO
- [x] Write tests for transaction sigop counting
~~Edit: The test changes are just to get the 1.48 tests passing. I'll remove them and replace them with whatever solution that is agreed upon in another PR etc.~~
Edit 2: This is the code I used as a guide:
8105bce5b3/src/consensus/tx_verify.cpp (L147-L166)
Edit 3: I found a subtle bug in the implementation of `count_sigops` (https://github.com/rust-bitcoin/rust-bitcoin/pull/2073#issuecomment-1722403687)
ACKs for top commit:
apoelstra:
ACK 158ba26a8a
tcharding:
ACK 158ba26a8a
Tree-SHA512: 2b8a0c50b9390bfb914da1ba687e8599b957c75c511f764a2f3ed3414580150ce3aa2ac7aed97a4f7587d3fbeece269444c65c7449b88f1bdb02e573e6f6febd
e4c7e01a6f Use the new bech32 iterator API (Tobin C. Harding)
Pull request description:
Depend on the newly released version of `bech32`, BOOM!
ACKs for top commit:
apoelstra:
ACK e4c7e01a6f
clarkmoody:
ACK e4c7e01a6f
Tree-SHA512: 91675a830cf67f8dcabd42e7dc1b70d80b669330be5244bb8102e0ec5d1a206d5ead07f73b328a158b761c328bc78d573185af8d31f14183ccc17318d752c02b
95b7a95fc2 test: correct psbt used for regression test (Subhradeep Chakraborty)
Pull request description:
The `unknown` key used in the `Psbt` (in `serde_regression_psbt` test) is not really unknown. Also the `preimages` in the `Input` don't seem to be valid. Though they don't affect the tests because of the `serde::serialize`, the `Psbt` itself is invalid and hence this PR.
ACKs for top commit:
tcharding:
ACK 95b7a95fc2
apoelstra:
ACK 95b7a95fc2
Tree-SHA512: 275320bb273163364640351e55a3f16c34c1eef06e9dde79b72bf40187d313f037edb5e4544f4dce32fb8a7cc552504aa2e4d22a646c89a3dec022f917539219