Currently in this module we have a distinction between an "index" which
is a number between [0, 2^31 - 1] which indexes into the set of normal
or hardened child numbers. We also have a child *number*, which within
the library is an opaque type, but can be freely converted into/out of a
u32 in the consensus encoding which uses the MSB as a normal/hardened
flag and the other bits to encode the index.
Probably we want to change ChildNumber::From<u32> to some sort of
from_consensus_u32 method, but that's out of scope for this PR. What is
*in scope*, though is fixing the error types.
In the existing code we have three problems:
* Our error type for a bad index is called InvalidChildNumber, rather
than InvalidIndex, and the error message reflects this, which is wrong
and confusing. (Some with InvalidChildNumberFormat.)
* The InvalidChildNumberFormat is always constructed from a ParseIntError
from stdlib, but we always throw that away rather than preserving it.
* These two error variants only appear when parsing child numbers, or
derivation paths which are lists of child numbers, but they are part
of the main error enum.
This is a breaking change to the API of the deprecated `derive_pub`
function, but it's in a way that's unlikely to break consumers (who are
probably just .expect'ing the result) so we will retain the deprecated
function.
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
2b37583ca5 test: add test for push slice minimal (ChrisCho-H)
Pull request description:
Following https://github.com/rust-bitcoin/rust-bitcoin/pull/4322.
Test `push_slice` and `push_slice_nom_minimal` from OP_1...OP_16 and OP_1NEGATE.
ACKs for top commit:
apoelstra:
ACK 2b37583ca55195965ce2f129d75a1fc114d8b5f6; successfully ran local tests
Tree-SHA512: 6d8e96d522d317d7ede2f1bc133050d98ccbc1816c59fe3589003de249828367314f751d3a75d6b58b0c90b1b735f85650c0d7acebaf5da21a38fb651ab4177d
73317c1c31 rename try_into_taptree into try_into_tap_tree - docs(taproot): hide deprecated try_into_taptree (aagbotemi)
Pull request description:
The PR introduces a new function `try_into_tap_tree()` to replace `try_into_taptree()`. `try_into_taptree()` has been deprecated.
This PR fixes#4364
ACKs for top commit:
apoelstra:
ACK 73317c1c31271b65eb50c45353bf7393eba1154b; successfully ran local tests
Tree-SHA512: 5d853ea05a8cacfc0a27a93bed4351409abf5f93e53b308d62efdc3966c8403a4a857e39882eb84e511b637763ddb9629be832c2079057d81fa1c1984bcb8ad7
f6105ea417 Use InputWeightPrediction to calculate effective_value (yancy)
Pull request description:
closes: https://github.com/rust-bitcoin/rust-bitcoin/issues/2455
Also, what about moving `effective_value` to `InputWeightPrediction`?
Marking as a draft until we can add api changes again.
ACKs for top commit:
apoelstra:
ACK f6105ea4171a85ce21443d7eb76b7aa9cadab53a; successfully ran local tests; yeah, this API does look nicer
Kixunil:
ACK f6105ea417
Tree-SHA512: 20592e49cb93343b1aefa340c3c870e2e21c747711da68a6aa57342f59ff2981c30e9c91de7eab32bcd11da33f040f9df62008db991d93b549079f91a6908055
354e1e42ad fix: enforce minimal push for push_slice (ChrisCho-H)
Pull request description:
Currently `push_slice` doesn't check the standard minimal push rule, which could result in possible money loss(e.g. if non minimal push is used in output script of p2wsh or p2tr).
Introduce `push_slice_non_minimal` to provide the way to push as now, and change `push_slice` logic to follow standard minimal push rule.
99a4ddf5ab/src/script/script.cpp (L366)
ACKs for top commit:
tcharding:
ACK 354e1e42ad
apoelstra:
ACK 354e1e42ad98c7968827d03be563bc14d764a983; successfully ran local tests
Tree-SHA512: 01f53dbd2a1a3c9a9e4387f0aaa7801f9c4570996054503a38d09ed1646ab65a3249d227adcf4139ac37a111d795e6cf986c4c273d5660c20820d1b36ba46f57
c4ff2baa5a Capitalize Taproot in rustdocs (Jamil Lambert)
Pull request description:
Some recent additions to the rustdocs used a lowercase t in taproot.
Capitalize all cases of Taproot in rustdocs to be consistent.
Closes#4354
ACKs for top commit:
tcharding:
ACK c4ff2baa5a
apoelstra:
ACK c4ff2baa5a7c841ecdfe0e8a92b0a1a664f203ae; successfully ran local tests
Tree-SHA512: 620ccf769a6dad3bcdfec8a0460f6f1bbf90780e280ca94317f6048117aaad06c41a90cd3ee00d670f799459316c1f84e96e4ce3ef3a44818243b21c2f41924b
793920d6bf minor docstring fixups message.rs (Bilog WEB3)
Pull request description:
Please fix this error, thank you
ACKs for top commit:
apoelstra:
ACK 793920d6bf7437e6f4f24d794818e885094992d8; successfully ran local tests
Tree-SHA512: 5e152299ceab2962ac841a3935877a2264654e7f1d296c0486b2548f57f9cc9106590f6fc92b0a4adaba44d909457e932cd706e76ab814067c5972afa4d8ab93
d0e1cd72fe chore: Fix the typos in the comments and variables (dufucun)
Pull request description:
Fix the typos in the comments and variables
ACKs for top commit:
apoelstra:
ACK d0e1cd72fec87276034476f1f28c62124cf63c25; successfully ran local tests
Tree-SHA512: 267d2b6b47e5a4f9466507e9dceb62ce94c848b3edefee65b85c3ce31560d1be880ef1c03ffd7dac54198f1f470695b70e06a505f91174f2990639bc20bf86e4
0498f7b7b7 Remove Option return from `minimal_non_dust` (jrakibi)
Pull request description:
Closes#4221
This removes the `Option` return type from `minimal_non_dust
Overflow is only possible in 2 cases:
- `dust_relay_fee` would need to be excessively high
- script size would have to exceed ~6.15 × 10¹⁵ bytes (≈ 6 petabytes)
we now panic with the same message we had before in cf12ba262a/bitcoin/src/blockdata/script/borrowed.rs (L412)
ACKs for top commit:
tcharding:
ACK 0498f7b7b7
apoelstra:
ACK 0498f7b7b7d43cc015d6788efe826df25d6156a5; successfully ran local tests
Tree-SHA512: 826a5d4ebb9c237cdd261f7d8b25fb2118cfba7d79b031839a619e12c440cbd34bbf830ffe513c104ef34e8ae50320e314c736a55be9ba7a82ae50f6022b9cf0
we replace Option<Amount> return type with Amount in minimal_non_dust
- Use `.expect("dust_relay_fee or script length should not be absurdly large")` to handle overflow from .checked_mul()
`.expect()` is only triggered if the value calculateed overflows u64
such an overflow would require a script size exceeding ~6.15 petabytes
52f9c13358 Implement Copy for Address and AddressInner (tushar994)
Pull request description:
solves #4237
ACKs for top commit:
apoelstra:
ACK 52f9c13358c97c358543f3302b325f37ac49392f; successfully ran local tests
Tree-SHA512: 007092c57b893cfa62a6185c21b8839daf946a5b8ca505fc7d5f3b78c056fc5ce44cfb32936469f1955d535f4798506ea20a936218f0bf6808b17506e87836f2
InputWeightPrediction can be used to determine the weight needed
to calculate the effective_value. This simplifies the process for api
consumers by allowing an easier interface with which to use to predict
the weight. Prior to this change, it was required to manually calculate
the predicted weight for whichever input type was to be used.
ebaf162a96 Add push_relative_lock_time() and deprecate push_sequence() (Erick Cestari)
Pull request description:
This pr improves the script builder API to better align with Bitcoin semantics when working with relative timelocks:
- Add `push_relative_lock_time()` method that takes a `relative::LockTime` parameter, which correctly represents the semantic meaning when working with CHECKSEQUENCEVERIFY
- Deprecate `push_sequence()` in favor of `push_relative_lock_time()` to avoid confusion between sequence numbers and relative timelocks
This addresses a potential confusion point in the API where developers might incorrectly push raw sequence numbers in scripts when what they actually need is to push a relative locktime value that will be checked against the transaction's sequence numbers by CHECKSEQUENCEVERIFY.
Closes#4301
ACKs for top commit:
apoelstra:
ACK ebaf162a962494329c6cb5f6d375a6a4a97fe83b; successfully ran local tests
tcharding:
ACK ebaf162a96
Tree-SHA512: 52c37b6e8bbcaa3f9346c5fd5db26eba69169bce13f915906df95fdc65204067fd75f803f8b5adad76978c9baad553c99281628736db4d1d317b149ab257d81f
157fe48dfd minor docstring fixups (planetBoy)
Pull request description:
ACKs for top commit:
apoelstra:
ACK 157fe48dfdc4029a0db63b393d8d9fd32a197e30; successfully ran local tests
Tree-SHA512: 29fe6168ff729f0f65f32a2c6ad28d45e36e0761cac4455b57b891f9c0bd2622db51a21b4961d33fa5a8934302eefca4a77c20732bf047e2721a5bc5d655c340
This commit improves the script builder API to better align with Bitcoin
semantics when working with relative timelocks:
- Add push_relative_lock_time() method that takes a relative::LockTime
parameter, which correctly represents the semantic meaning when working
with CHECKSEQUENCEVERIFY
- Deprecate push_sequence() in favor of push_relative_lock_time() to avoid
confusion between sequence numbers and relative timelocks
This addresses a potential confusion point in the API where developers
might incorrectly push raw sequence numbers in scripts when what they
actually need is to push a relative locktime value that will be checked
against the transaction's sequence numbers by CHECKSEQUENCEVERIFY.
7b193b5125 fix err P2WPKH to P2WSH (planetBoy)
Pull request description:
The correction is important because “P2WPK” is not a valid name. In the BIP141 specifications, the correct terms are “P2WPKH” and “P2WSH”.
ACKs for top commit:
Kixunil:
ACK 7b193b5125
apoelstra:
ACK 7b193b5125336263f672f2e2c69447cc3ae58926; successfully ran local tests
Tree-SHA512: 951bcde2c28e2086a69043c1ed27bde0935df0918f418c5f6f89ed476ba9e182e99eec545a438f79ca4e1704ce496d443b5bc9e368a53dd583a884f1da405865
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.
e966335447 chore: remove explicit into iteration (jike)
Pull request description:
```
warning: it is more concise to loop over containers instead of using explicit iteration methods
--> bitcoin/src/psbt/serialize.rs:209:21
|
209 | for cnum in self.1.into_iter() {
| ^^^^^^^^^^^^^^^^^^ help: to write this more concisely, try: `&self.1`
```
ACKs for top commit:
Kixunil:
ACK e966335447
apoelstra:
ACK e9663354476b0b9b2ec52ce034de5ab9223f9d29; successfully ran local tests
Tree-SHA512: 32fced1a5aba2caa6e48a2e586bf00dcf3d4b82b6b530d9c7f535b530737a40e24d5c05a7cea40747df4c7c4698ec141683b9416583b185b1ff6461f3c8f667f
fb29aadc47 Remove bip158 types from crate root (Tobin C. Harding)
Pull request description:
BIP-158 (Compact Block Filters for Light Clients) is not so common as to require re-exorting its types at the crate root - remove them.
ACKs for top commit:
apoelstra:
ACK fb29aadc47367ba8579f0004e97cd1fd7fd8236f; successfully ran local tests
Kixunil:
ACK fb29aadc47
Tree-SHA512: 8a2edaad858b18feded8cc9e1d15f03a76980bd41524fa34b91b4055b236788c6d828940c6293e086a8c8e33baadc5765a1a60920513fdff2de22e9d94c0e541
Andrew Poelstra
Fallengirl
Shing Him Ng
Fmt Bot
aagbotemi
ChrisCho-H
Alex Pikme
Jamil Lambert
Bilog WEB3
dufucun
jrakibi
Maxim Evtush
yancy
tushar994
planetBoy
Erick Cestari
Martin Habovstiak