c11772a768 Accept flexible input types for Taproot-related functions (Erick Cestari)
2a518d62e6 Wrap secp256k1::XOnlyPublicKey to improve error handling (Erick Cestari)
Pull request description:
This PR addresses issue #4361 by creating a wrapper type for XOnlyPublicKey instead of directly re-exporting it from the secp256k1 library.
### Key Changes
1. Created a new `XOnlyPublicKey` struct that wraps `secp256k1::XOnlyPublicKey`
2. Implemented custom error types:
- `ParseXOnlyPublicKeyError` for handling parsing errors
- `TweakXOnlyPublicKeyError` for tweaking an `XOnlyPublicKey`
3. Updated all imports and usage throughout the codebase
4. Implemented necessary traits and methods for compatibility
Closes#4361
ACKs for top commit:
apoelstra:
ACK c11772a768eefd89dcc0e3b1a369d535c191f94a; successfully ran local tests
tcharding:
ACK c11772a768
Tree-SHA512: c8da3486e7ffcab6c24cc08f9b2f964dd9158449ef2bd720e54d56176bc7027052314ea23cac3f673d217fa785238ea8a9b5323ba57f02199f20e56df5893965
Refactor Taproot functions to accept any type implementing `Into<XOnlyPublicKey>`,
instead of requiring `XOnlyPublicKey` directly. This improves ergonomics when working
with compatible types, avoiding unnecessary `.into()` conversions at call sites.
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
I'm not sure why we do not use consensus encoding currently for encoding
and decoding scripts to/from hex strings. Many tests include hard coded
hex which do not include the length prefix.
- Add a pair of encoding functions to encode/decode to/from hex without
the length prefix.
- Make `to_hex` and `from_hex` expect the length prefix i.e., use
consensus encoding.
This makes the API easier to use because the various encoding APIs can
be use together now eg `consensus::encode_hex` and `ScriptBuf::from_hex`.
c009a42e60 Update internal_macros.rs (GarmashAlex)
a4253fa5d9 Update mod.rs (GarmashAlex)
604b095540 Update serialize.rs (GarmashAlex)
024f87e655 Update error.rs (GarmashAlex)
1af34f92c5 Update message_compact_blocks.rs (GarmashAlex)
f554b01e82 Update params.rs (GarmashAlex)
Pull request description:
This PR addresses several minor issues across the codebase, including:
- Fixing typographical errors in comments and documentation (e.g., "deserilaization" → "deserialization", "send" → "sent").
- Improving sentence clarity and grammar in doc comments (e.g., correcting sentence structure and word choice).
- Enhancing code readability without changing any logic or functionality.
These changes are purely cosmetic and aimed at improving maintainability and developer experience.
ACKs for top commit:
apoelstra:
ACK c009a42e60f0b4302506f5fc104af38a6c15be21; successfully ran local tests
Tree-SHA512: 915e2c9444d8f2810ba5cd51d3066685aea5a39d98303c793a854aea6da016cab2c457dd71c0b6549d29d6443db1292ebdb06d25f693741b2eca3979bf67cfab
3319e6ef6d Add ControlBlock constructor that takes a hex string (Shing Him Ng)
Pull request description:
Closes#4362
ACKs for top commit:
Kixunil:
ACK 3319e6ef6d
apoelstra:
ACK 3319e6ef6dd964f40e6e880843648c112a6b74ed; successfully ran local tests
Tree-SHA512: 230e4607402b3df6a8c5fe1e03209573baffbd08ca9d28e1208bff1464668a083ddb5ae72781eceb2546bc99b150dd2f832d122570d55aa323c603481c5eff93
87d1210156 accessing XOnlyPublicKey from bitcoin::taproot (aagbotemi)
Pull request description:
This PR fixes#4363
`XOnlyPublicKey` is now made available from `bitcoin::taproot`.
ACKs for top commit:
apoelstra:
ACK 87d1210156f6a39b1e59f098bc520dba6f02a5b4; successfully ran local tests
Tree-SHA512: 7ea0ee330d32e5413d06deb70d920396ebd275ce65841d6eadac318aab4e728629c57c828722df4e1cb3130bb72f4170f32218ec25ec243d99f0094094d8f9da
492073f288 Strengthen the type of `taproot_control_block()` (Martin Habovstiak)
e8a42d5851 Unify/reduce usage of `unsafe` (Martin Habovstiak)
d42364bd9d Swap around the fields in `Address` (Martin Habovstiak)
7a115e3cf1 Make `Address` obey sanity rules (Martin Habovstiak)
bc6da1fe07 Swap around the fields in `sha256t::Hash` (Martin Habovstiak)
8ee088df74 Make `sha256t` obey sanity rules (Martin Habovstiak)
Pull request description:
Well, I thought this PR will be just the last commit... 😅
Anyway, this implements a bunch of changes to allow returning `ControlBlock` from `Witness` method(s). One cool side effect is that this PR also reduces the number of `unsafe` blocks.
ACKs for top commit:
apoelstra:
ACK 492073f28876406f8fe5a07a8a2495c8e0ba1fb3; successfully ran local tests
Tree-SHA512: 11979517cc310abf25644fc93a75deccacae66af8ba2d9b4011fdc3f414b15fac7e748399c7eef492ca850c11b7aacc3f24ec46fccf95e6d57a400212979637e
The type returned by `Witness::taproot_control_block()` was just `&[u8]`
which wasn't very nice since users then had to manually decode it which
so far also required allocation. Thanks to previous improvements to
`ControlBlock` it is now possible to return a `ControlBlock` type
directly.
To avoid expensive checks, this change adds a new type
`SerializedXOnlyPublicKey` which is a wrapper around `[u8; 32]` that is
used in `ControlBlock` if complete checking is undesirable. It is then
used in the `ControlBlock` returned from
`Witness::taproot_control_block`. Users can still conveniently validate
the key using `to_validated` method.
It then uses this type in the recently-added `P2TrSpend` type. As a side
effect this checks more properties of `Witness` when calling unrelated
methods on `Witness`. From correctness perspective this should be OK: a
witness obtained from a verified source will be correct anyway and, if
these checks were done by the caller, they can be removed.
From performance perspective, if the `Witness` was obtained from a
verified source (e.g. using Bitcoin Core RPC) these checks are wasted
CPU time. But they shouldn't be too expensive, we already avoid
`secp256k1` overhead and, given that they always succeed in such case,
they should be easy to branch-predict.
Since the introduction of `Script` `unsafe` started slowly creeping in
as more types with similar semantics were added. The `unsafe` in these
cases is just for trivial conversions between various pointer-like
types. As such, it's possible to move these into a single macro that
takes care of the conversions at one place and avoid repeating the same
`unsafe` code in the codebase. This decreases the cost of audits which
now only need to happen in `internals`, focuses any changes to happen in
that single macro and decreases the chance that we will mess up
similarly to the recent `try_into().expect()` issue (but this time with
UB rather than panic).
The new macro accepts syntax very similar to the already-existing struct
declarations with these differences:
* The struct MUST NOT have `#[repr(transparent)]` - it's added by the
macro
* If the struct uses `PhantomData` it must be the first field and the
real data must be the second field (to allow unsized types).
* The struct must be immediately followed by an impl block containing at
least on conversion function.
* If the struct has generics the impl block has to use the same names of
generics.
* The conversion functions don't have bodies (similarly to required
trait methods) and have a fixed set of allowed signatures.
* Underscore (`_`) must be used in place of the inner type in the
conversion function parameters.
The existing code can simply call the macro with simple changes and get
the same behavior without any direct use of `unsafe`. This change
already calls the macro for all relevant existing types. There are still
some usages left unrelated to the macro, except one additional
conversion in reverse direction on `Script`. It could be moved as well
but since it's on a single place so far it's not really required.
Previously we've used `try_into().expect()` because const generics were
unavailable. Then they became available but we didn't realize we could
already convert a bunch of code to not use panicking conversions. But we
can (and could for a while).
This adds an extension trait for arrays to provide basic non-panicking
operations returning arrays, so they can be composed with other
functions accepting arrays without any conversions. It also refactors a
bunch of code to use the non-panicking constructs but it's certainly not
all of it. That could be done later. This just aims at removing the
ugliest offenders and demonstrate the usefulness of this approach.
Aside from this, to avoid a bunch of duplicated work, this refactors
BIP32 key parsing to use a common method where xpub and xpriv are
encoded the same. Not doing this already led to a mistake where xpriv
implemented some additional checks that were missing in xpub. Thus this
change also indirectly fixes that bug.
The new unsized type is more flexible and so are the references to it.
Just like we pass around `&str` instead of `&String` we should be
passing `&TaprootMerkleBranch` instead of `&TaprootMerkleBranchBuf`.
`TaprootMerkleBranchBuf` previously derefed to a slice which lost the
information about length being valid. This commit changes the type
which, while API-breaking, is not disruptive because the type has API
very similar to slice.
`TaprootMerkleBranchBuf` being a vec introduced intermediate allocation
when creating or decoding `Witness`. However the representation on the
wire is the same as in-memory (aside from `#[repr(transparent)]`) so
this allocation wasn't really needed.
This commit introduces `TaprootMerkleBranch` type which is unsized and
can be used in place of `TaprootMerkleBranchBuf` within `ControlBlock`.
Aside from removing the intermediate allocation, this improves the API a
bit: the conversion from array to other type is no longer needed because
it's performed by `ControlBlock` in its methods. Thus, consumers who
have an array can simply set it as `merkle_branch` field and then encode
the `ControlBlock` into witness. A convenience method is also provided
to push the `ControlBlock` along with other parts at the end of the
`Witness`.
In the past we've been using `chunks_exact` because const generics were
unstable but then, when they were stabilized we didn't use `as_chunks`
(or `array_chunks`) since they were unstable. But the instability was
only because Rust devs don't know how to handle `0` being passed in. The
function is perfectly implementable on stable. (With a tiny,
easy-to-understand `unsafe` block.) `core` doesn't want to make a
decision for all other crates yet but we can make it for our own crates
because we know that we simply never pass zero. (And even if we did, we
could just change the decision.)
It also turns out there's a hack to simulate `const {}` block in our
MSRV, so we can make compilation fail early.
This commit adds an extension trait to internals to provide the methods,
so we no longer have to use `chunks_exact`. It also cleans up the code
quite nicely.
f80cf2cb2a update secp256k1 to 0.30.0 (19年梦醒)
Pull request description:
ACKs for top commit:
apoelstra:
ACK f80cf2cb2aa318978da3a6c5df49d82c49344763; successfully ran local tests
tcharding:
ACK f80cf2cb2a
Tree-SHA512: 83b8bb72372025c4a4b81c2b7973a7808a4a1d9d6450adef8b60a890e128b2559b55832159c25fa91daac1856049b070cd910d87313fed2851ced9e72ae5ddf5
bb8f833ca0 Update instruction.rs (kilavvy)
0ce622e668 Update message.rs (kilavvy)
f61941bbe6 Update serialized_signature.rs (kilavvy)
1d2de62e01 Update mod.rs (kilavvy)
Pull request description:
This PR fixes several typos in comments across multiple files:
- Fixed typo `interpretted` -> `interpreted` in `blockdata/script/instruction.rs`
- Fixed typo `neccessity` -> `necessity` in `p2p/message.rs`
- Fixed typo `underlflow` -> `underflow` in `taproot/serialized_signature.rs`
- Fixed typo `ambigous` -> `ambiguous"` in `units/src/amount/mod.rs`
These changes only affect comments and documentation, no functional code changes.
ACKs for top commit:
apoelstra:
ACK bb8f833ca01688eaae75e0fa322f698d34243185; successfully ran local tests; though all these commits could be squashed IMO
Tree-SHA512: d73dc2a86b20de87c0c5efb3e5042e3901c846236670e3a6501f4c93fd54328fef08bfeca276b93642e7b51d04cb8b9c8e1af558f3aabc3c924d60a61e58b031
cf12ba262a Move taproot back to bitcoin crate (Tobin C. Harding)
Pull request description:
I don't know what I was thinking when I move the taproot hash types to `primitives`. As correctly pointed out by Kix we agreed to only have blockdata in `primitives`.
Move the taproot hash types back to `bitcoin::taproot` and remove the extension traits.
ACKs for top commit:
Kixunil:
ACK cf12ba262a
apoelstra:
ACK cf12ba262a646a6341098ee3f4c178a52fc90211; successfully ran local tests
Tree-SHA512: 0c5eabf395c05a93603a46b277c6ea2cc547f3894eef182fceb80f309123d67fe457936a388bac0249ec24cae7521eaef3bf8bd8facca5282e4ce2ea6fafd5f7
I don't know what I was thinking when I move the taproot hash types to
`primitives`. As correctly pointed out by Kix we agreed to only have
blockdata in `primitives`.
Move the taproot hash types back to `bitcoin::taproot` and remove the
extension traits.
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 #4073
We would like it if two different pre-tagged engines were considered
different types so it is not possible to mix them up.
Add a new `sha256t::HashEngine<T>` where `T` is a tag the same as on
`sha256t::Hash<T>`.
Now we have an associated const we can do away with the `engine` trait
method all together. Users can call `Hash<FooTag>::engine` instead. This
is better because its an API more similar to the other hash types and
therefor easier to discover and remember.
New nightly lint warning "called `Iterator::last` on a
`DoubleEndedIterator`; this will needlessly iterate the entire iterator"
Code that gives the warning is correct, allow the lint to remove the
warning.
Update rustc nightly to 2025-01-16
Rust macros, while at times useful, are a maintenance nightmare. And
we have been bitten by calling macros from other crates multiple times
in the past.
In a push to just use less macros remove the usage of the
`impl_from_infallible` macro in the bitcoin, units, and internals crates
and just write the code.
There is a loose convention in Rust to not use `test_` prefix. The
reason being that `cargo test` outputs 'test <test name>' using the
prefix makes the output stutter.
This patch smells a bit like code-churn but having the prefix in some
places and not others is confusing to new contributors and is leading me
to explain this many times now. Lets just fix it.
Remove the prefix unless doing so breaks the code.
These lints are valuable, lets get at em.
Changes are API breaking but because the changes make functions consume
self for types that are `Copy` downstream should not notice the breaks.
In commit: `39f7dcb Reduce API surface of tagged wrapped hash types` I
introduced a typo in the tagged hash tag type. Fortunately it has no
effect because the tag type controls how an engine is created (when the
tag is input into the engine) and has no effect on the call to
`from_engine`. However the typo makes the code confusing.
This bug is currently unreleased.
Fix: #3649
Luis Schwab
merge-script
Erick Cestari
Fmt Bot
Shing Him Ng
Tobin C. Harding
GarmashAlex
aagbotemi
Bilog WEB3
Martin Habovstiak
yancy
19年梦醒
kilavvy
Jamil Lambert, PhD