chore: rebase on rust-bitcoin v0.32.7 #21
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…gle()` incompatibility with Bitcoin Core 18c2cad Add test for sighash_single_bug incompatility fix (Liu-Cheng Xu) 068c3f2 Fix `is_invalid_use_of_sighash_single()` incompatibility with Bitcoin Core (Liu-Cheng Xu) Pull request description: Backport rust-bitcoin#4113 Cherry-picked the 2 commits and manually fixed merge conflicts. ACKs for top commit: apoelstra: ACK 18c2cad; successfully ran local tests Tree-SHA512: 9ddc3950e6f35c1fb6d44156a26a8111fe73e6189b1e6c57464173671ce1fab95558485844f72abb33f632b5015089733f3a0e4acdb11005c06c58d466a63706
The `taproot_control_block` did not properly detect whether it deals with script spend or key spend. As a result, if key spend with annex was used it'd return the first element (the signature) as if it was a control block. Further, the conditions identifying which kind of spend it was were repeated multiple times but behaved subtly differently making only `taproot_control_block` buggy but the other places confusing. To resolve these issues this change adds a `P2TrSpend` enum that represents a parsed witness and has a single method doing all the parsing. The other methods can then be trivially implemented by matching on that type. This way only one place needs to be verified and the parsing code is more readable since it uses one big `match` to handle all possibilities. The downside of this is a potential perf impact if the parsing code doesn't get inlined since the common parsing code has to shuffle around data that the caller is not intersted in. I don't think this will be a problem but if it will I suppose it will be solvable (e.g. by using `#[inline(always)]`). The enum also looks somewhat nice and perhaps downstream consumers could make use of it. This change does not expose it yet but is written such that after exposing it the API would be (mostly) idiomatic. Closes rust-bitcoin#4097
The previous commit fixed a bug when `taproot_control_block` returned `Some` on key-spends. This adds a test case for it which succeeds when applied after the previous commit and fails if applied before it.
We already have `tapscript` method on `Witness` which is broken because it doesn't check that the leaf script is a tapscript, however that behavior might have been intended by some consumers who want to inspect the script independent of the version. To resolve the confusion, we're going to add a new method that returns both the leaf script and, to avoid forgetting version check, also the leaf version. This doesn't touch the `tapscript` method yet to make backporting of this commit easier. It's also worth noting that leaf script is often used together with version. To make passing them around easier it'd be helpful to use a separate type. Thus this also adds a public POD type containing the script and the version. In anticipation of if being usable in different APIs it's also generic over the script type. Similarly to the `tapscript` method, this also only adds the type and doesn't change other functions to use it yet. Only the newly added `taproot_leaf_script` method uses it now. This is a part of rust-bitcoin#4073
Now that an alternative exists we can deprecate the method with an expalantion of what's going on.
9e87bc5 Deprecate the `Witness::tapscript` method (Martin Habovstiak) 730baeb Add `taproot_leaf_script` methood to `Witness` (Martin Habovstiak) 74138d5 Add a test case checking `taproot_control_block` (Martin Habovstiak) 39e280a Fix key/script spend detection in `Witness` (Martin Habovstiak) Pull request description: This backports fixes from rust-bitcoin#4100 ACKs for top commit: tcharding: ACK 9e87bc5 apoelstra: ACK 9e87bc5; successfully ran local tests Tree-SHA512: 3d2928dc09c39dbe1d8a6f34e41e86ed47e9b257994eb308a70841db437e19f0947353d325b511304567b59cc6b17beefe0b257bfad3b50847d0cb304b284914
The corresponding PR on master is rust-bitcoin#4387, but this doesn't really resemble that PR. Rather than changing all the error enums, this just adds a new variant to the #[non_exhaustive] bip32::Error enum and returns that when adding 1 to 255 when deriving child keys. This is therefore not an API break and can be released in a minor version. Although it does change the error return on private derivation from a "succeeds except with negligible probability" to "there is an error path you may need to check for". Fixes rust-bitcoin#4308
…ttempting to derive past maximum depth 315750d bip32: return error when attempting to derive past maximum depth (Andrew Poelstra) Pull request description: The corresponding PR on master is rust-bitcoin#4387, but this doesn't really resemble that PR. Rather than changing all the error enums, this just adds a new variant to the #[non_exhaustive] bip32::Error enum and returns that when adding 1 to 255 when deriving child keys. This is therefore not an API break and can be released in a minor version. Although it does change the error return on private derivation from a "succeeds except with negligible probability" to "there is an error path you may need to check for". Fixes rust-bitcoin#4308 ACKs for top commit: tcharding: ACK 315750d Tree-SHA512: 8224a3462169ab1e31211b4b00b423d11b8778452096617eaf384ef8ec3dd5f8325b7a0e29519db1660ea4bc5620828b996fca329272900145b96486e2a7e653
… signing This commit enhances PSBT signing functionality by: 1. Added new KeyRequest::XOnlyPubkey variant to support direct retrieval using XOnly public keys 2. Implemented GetKey for HashMap<XOnlyPublicKey, PrivateKey> for more efficient Taproot key management 3. Modified HashMap<PublicKey, PrivateKey> implementation to handle XOnlyPublicKey requests by checking both even and odd parity variants These changes allow for more flexible key management in Taproot transactions. Specifically, wallet implementations can now store keys indexed by either PublicKey or XOnlyPublicKey and successfully sign PSBTs with Taproot inputs. Added tests for both implementations to verify correct behavior. Added test for odd parity key retrieval. Closes rust-bitcoin#4150
Backport rust-bitcoin#4373, authored by Shing Him Ng. Original gitlog: For TweakedKeypair, `to_inner` is also renamed to `to_keypair` to maintain consistency. Similarly, `to_inner` is renamed to `to_x_only_pubkey` for TweakedPublicKey Co-authored-by: Shing Him Ng <[email protected]>
c67adcd backport: Add methods to retrieve inner types (Shing Him Ng) Pull request description: Backport rust-bitcoin#4373, authored by Shing Him Ng. Original gitlog: For TweakedKeypair, `to_inner` is also renamed to `to_keypair` to maintain consistency. Similarly, `to_inner` is renamed to `to_x_only_pubkey` for TweakedPublicKey ACKs for top commit: apoelstra: ACK c67adcd; successfully ran local tests shinghim: ACK c67adcd storopoli: ACK c67adcd Tree-SHA512: 310f0f99c3ffd0937b83739d30998afec471b0e41d9af2f4863e8405ffc4f4ee6650d1e73d170bf93cefee59a89331eff4d93984fc3ab3dfcbe3830e559ce659
…T key retrieval and improve Taproot signing 95eb255 Add XOnlyPublicKey support for PSBT key retrieval and improve Taproot signing (Erick Cestari) 2858b6c Support GetKey where the Xpriv is a direct child of the looked up KeySource (Nadav Ivgi) d005ddd Refactor GetKey for sets to internally use Xpriv::get_key() (Nadav Ivgi) b75b2e3 Fix GetKey for sets to properly compare the fingerprint (Nadav Ivgi) Pull request description: Backport two PRs: - rust-bitcoin#3356 - rust-bitcoin#4238 The first includes a bug fix in a `GetKey` impl and the second is a feature we want to release. And the three refactor patches touch code that rust-bitcoin#4238 builds on so I figured we should backport them all. All 5 patches required a small amount of massaging to get in. The first 4 was just adding a `?` to the calls to `derive_priv`. The last patch needed a few calls in the unit test changing. ACKs for top commit: storopoli: ACK 95eb255 apoelstra: ACK 95eb255; successfully ran local tests Tree-SHA512: 5b73c4cd3ddfeef5d4e64a6e236c905c39c560dc704dba8d925f636d3c9b12c0706f27c3e4b29d92ab9e2d15ddbee8bbe5d0955836529d72461d6ee505d899c5
In preparation for release bump the version, add a changelog entry, and update the lock files.
916982a bitcoin: Bump version to 0.32.6 (Tobin C. Harding) Pull request description: In preparation for release bump the version, add a changelog entry, and update the lock files. ACKs for top commit: apoelstra: ACK 916982a; successfully ran local tests storopoli: ACK 916982a Tree-SHA512: 922dc8af49479d7777ee73ddf142f62372c6423af17ce367bf66b9d2c933cff648153856a35f1ba3a10ec61844c897d4c5a25e4c216d17c1f899f39d9cbc47c0
Manually backport rust-bitcoin#4538. If we use a `u32` then the constructor no longer panics. 32 bits is plenty for an sane usage.
…stead of _unchecked c7b20f4 backport: Use _u32 in FeeRate constructor instead of _unchecked (Tobin C. Harding) Pull request description: Manually backport rust-bitcoin#4538. If we use a `u32` then the constructor no longer panics. 32 bits is plenty for an sane usage. ACKs for top commit: apoelstra: ACK c7b20f4; successfully ran local tests Tree-SHA512: c247ad0b95ed1b193626fd5d6cb6dba287b779be4bfc90602972921f1dd4a064b15bf4233f0496d238af4fcff2639bd9b3e52adbff0a370a0d67ea7eeb51b2ff
Manually backport PR rust-bitcoin#4111. Of note, here we put `new_p2a` on `ScriptBuf` instead of on the `script::Builder` because that seems to be where all the other `new_foo` methods are in this release. Note the `WitnessProgram::p2a` is conditionally const on Rust `v1.61` because MSRV is only `v1.56.1`. From the original patch: Add support for the newly created Pay2Anchor output-type. See bitcoin/bitcoin#30352
c2481e4 backport: Add support for pay to anchor outputs (Tobin C. Harding) Pull request description: Manually backport PR rust-bitcoin#4111. Of note, here we put `new_p2a` on `ScriptBuf` instead of on the `script::Builder` because that seems to be where all the other `new_foo` methods are in this release. From the original patch: Add support for the newly created Pay2Anchor output-type. See bitcoin/bitcoin#30352 ACKs for top commit: apoelstra: ACK c2481e4; successfully ran local tests Tree-SHA512: 016919914750adf6f8226acb4e6b36c0dcd8ce230df8cca13f19bcc97709caf07a076be367c76f9519a421fc93fdf73caa078ee65a85a750af7a9d9e6c757e75
Issue rust-bitcoin#2225 is long and has many valid opposing opinions. The main argument for having non_exhaustive is that it helps future proof the ecosystem at the cost of pain now. The main argument against having non_exhaustive is why have pain now when adding a network is so rare that having pain then is ok. At the end of the thread Andrew posts: > I continue to think we should have an exhaustive enum, with a bunch of > documentation about how to use it properly. I am warming up to the > "don't have an enum, just have rules for defining your own" but I think > this would be needless work for people who just want to grab an > off-the-shelf set of networks or people who want to make their own enum > but want to see an example of how to do it first. In order to make some forward progress lets remove the `non_exhaustive` now and backport this change to 0.32, 0.31, an 0.30. Later we can add, and release in 0.33, whatever forward protection / libapocalyse protection we want to add. This removes the pain now and gives us a path to prevent future pain - that should keep all parties happy.
… from `Network` 3cf4a91 Remove non_exhausive from Network (Tobin C. Harding) Pull request description: This is rust-bitcoin#4640 backported manually. Remove `non_exhaustive` from `Network` enum. ACKs for top commit: apoelstra: ACK 3cf4a91; successfully ran local tests Tree-SHA512: 690cdcf82a9e87f2100aa8e996583bd54f969d8d55eba062ace66bdf2ae9ae1c482d6220bb26690ebfaf3a35ca3f5ce0ecaac3a79b4061c75e9fb7adbe032f48
In preparation for release bump the version, add a changelog entry, and update the lock files.
571cd7f bitcoin: Bump version to 0.32.7 (Tobin C. Harding) Pull request description: In preparation for release bump the version, add a changelog entry, and update the lock files. ACKs for top commit: apoelstra: ACK 571cd7f; successfully ran local tests Tree-SHA512: c1a9ddaebe60c3d048220855543de50757a0465ebd2f5d45e0794c9b0a617a82a521c04ab420719838e15dff66566cbbee0903e11c740faad4fcc8654a0fe947
This reverts commit 7adbf29.
[XC-374](https://dfinity.atlassian.net/browse/XC-374?atlOrigin=eyJpIjoiM2VjNTk4OWNmNzY1NDUzZmEwODE1ODI0NWVkMTJkMmMiLCJwIjoiaiJ9): this PR adds the Apache-2.0 license to the dogecoin module while preserving the CC0-1.0 license for code inherited from upstream rust-bitcoin. [XC-374]: https://dfinity.atlassian.net/browse/XC-374?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
[XC-383](https://dfinity.atlassian.net/browse/XC-383?atlOrigin=eyJpIjoiZGIzYzllMDQ4M2U0NDc2MjllMWJmYzFmOTYwYmYwZWMiLCJwIjoiaiJ9): This PR adds 1) Dogecoin consensus parameters used in block validation and 2) genesis transaction/block parameters which will be used for testing purposes. [XC-383]: https://dfinity.atlassian.net/browse/XC-383?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
#8) This PR adds methods required for implementing Dogecoin's difficulty adjustment algorithm (DAA). In particular it adds the method `from_next_work_required_dogecoin()` which computes the target value for the next difficulty adjustment period, based on the `timespan` between start and end of period and the `last` target value. Note: this PR only adds the required logic to compute targets in block period 0-5,000 (see https://github.com/dogecoin/dogecoin/blob/51cbc1fd5d0d045dda2ad84f53572bbf524c6a8e/src/dogecoin.cpp#L41 for complete algorithm). A following PR will add the logic for further periods and in particular for the Digishield algorithm used in later periods.
Since dogecoin uses different prefixes and only supports P2PKH and P2SH address types, this PR introduces separate implementations for Address related types, which are adapted from the bitcoin ones.
Support dogecoin in p2p messages by making NetworkMessage type parameterized by Block type. Also add `with_version()` methods to a few types to allow changing protocol version number.
…1-144,999) (#9) [XC-431](https://dfinity.atlassian.net/browse/XC-431?atlOrigin=eyJpIjoiNGZlYzIwYTg0NmE2NGNhOWE2NmUxZTBiNTdjNzE2NGIiLCJwIjoiaiJ9): This PR adds the correct difficulty calculation for pre-digishield blocks (i.e. blocks 5,001-144,999). It follows the previous PR #8 which added the logic for block period 0-5,000. The main change is the addition of the correct `min_timespan` for a difficulty adjustment interval allowed for a given block height, as defined by [dogecoin's difficulty adjustment algorithm](https://github.com/dogecoin/dogecoin/blob/51cbc1fd5d0d045dda2ad84f53572bbf524c6a8e/src/dogecoin.cpp#L57). The relevant code can be found here: 09daa88#diff-874f3e7cfb3e02a8a906534570346fd48a5a58615069afa5a60ceaf4b9542d0eR471-R478 [XC-431]: https://dfinity.atlassian.net/browse/XC-431?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Changes to Dogecoin parameters, in preparation for DigiShield difficulty adjustment PR #11: - replace `struct Params` encapsulating `bitcoin_params` and `dogecoin_params` into unified `Params` structure. - change `timespan` and `pow_target_timespan` types from `u64` to `i64`. The motivation is twofold: 1) [Dogecoin core](https://github.com/dogecoin/dogecoin/blob/51cbc1fd5d0d045dda2ad84f53572bbf524c6a8e/src/consensus/params.h#L67) is using `int64_t` type throughout, 2) manipulating negative `timespan` is easier and safer to handle, which is going to be the case when switching to DigiShield where difficulty adjustment interval is only 1 block. - change `pow_target_spacing` type from `u64` to `i64` for consistency with Dogecoin.
[XC-434](https://dfinity.atlassian.net/browse/XC-434?atlOrigin=eyJpIjoiZjk1YjYwOGE4MDgxNDFkZjg2YTQ5NWU2NTZmMDlhMmIiLCJwIjoiaiJ9): Adds digishield difficulty adjustment algorithm. Ref: https://github.com/dogecoin/dogecoin/blob/2c513d0172e8bc86fe9a337693b26f2fdf68a013/src/dogecoin.cpp#L51 [XC-434]: https://dfinity.atlassian.net/browse/XC-434?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Pass protocol version explicitly when constructing network messages. Remove the previous addition of `with_version` method because it could be confusing when to use it. This is not a compatible change, but modifications required are fairly minimum. Hopefully it will not be a problem in the future.
[XC-435](https://dfinity.atlassian.net/browse/XC-435): Adds AuxPow validation used in merged mining. References: - Dogecoin core: https://github.com/dogecoin/dogecoin/blob/51cbc1fd5d0d045dda2ad84f53572bbf524c6a8e/src/auxpow.cpp#L81 - Merged mining specification: https://en.bitcoin.it/wiki/Merged_mining_specification [XC-435]: https://dfinity.atlassian.net/browse/XC-435?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Because Dogecoin's Header type is now different than Bitcoin's, The NetworkMessage type has to take Header as a parameter too.
This PR adds additional tests for the `from_next_work_required_dogecoin` method and `params` module. The goal is to replicate the tests found in Dogecoin core [dogecoin_tests.cpp](https://github.com/dogecoin/dogecoin/blob/master/src/test/dogecoin_tests.cpp).
Updates the README.md file to references the upstream rust-bitcoin README file and list the main differences between rust-dogecoin and rust-bitcoin.
Following upstream commit rust-bitcoin@3f33240, the `doc_auto_cfg` feature is removed to fix the docs.rs build. Additionally, we enable the `doc_notable_trait` feature flag, following upstream commit rust-bitcoin@dfb76c1
Pull Request Test Coverage Report for Build 20457624899Details
💛 - Coveralls |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.