The only reason we need `hex-conservative` is to parse strings and
format them as hex. For users that do not require this functionality we
can make the `hex-conservative` crate an optional dependency.
The `serde` feature requires `Display` so we enable `hex` from the
`serde` feature.
If `hex` feature is not enabled we still need to be able to debug so
provide `fmt::Debug` functionality by way of macros.
Close: #2654
For the `hashes` crate we would like to make `hex` an optional
dependency. In preparation for doing so do the following:
- Remove the trait bounds from `GeneralHash`
- Split the hex/string stuff out of `impl_bytelike_traits` into a
separate macro.
The `impl_bytelike_traits` macro is public and it is used in the
`hash_newtype` macro, also public.
Currently if a user calls the `hash_newtype` macro in a crate that
depends on `hashes` without the `serde` feature enabled and with no
`serde` dependency everything works. However if the user then adds a
dependency that happens to enable the `serde` feature in `hashes` their
build will blow up because `serde` code will start getting called from
the original crate's call to `hash_newtype`.
Pull the serde stuff out of `hash_newtype` and provide a macro to
implement it `impl_serde_for_newtype`.
Add a unit test that verifies we correctly remove the annex when getting
the tapscript from the witness stack.
Unit test written by Casey, pulled out of #3599.
Co-developed-by: Casey Rodarmor <casey@rodarmor.com>
In #2646 we introduced a bug in the taproot witness stack getter
functions, of which we have three:
- `tapscript`
- `taproot_control_block`
- `taproot_annex`
Each returns `Some` if a possible bytes slice is found (with no other
guarantees).
Use `taproot_annex` combined with getters from `primitives` to implement
the other two getters. This simplifies the code and fixes the bug.
Add an additional getter to `primitives` `Witness::third_from_last`.
Fix: #3598
These re-exports are hard to get right. We (I) recently made an attempt
to make our stack of crates easier to navigate using the idea that
exporting a type from the crate it is defined in adds some additional
information without any loss of clarity. Note however that the module
must be re-exported from the "highest" place possible because we at
times add additional functionality as we move up the stack e.g.,
`bitcoin::merkle_tree` has logic in it that `primitives::merkle_tree`
does not. In order to future proof the codebase default to always using
the highest module up the stack even when that module adds no additional
code e.g., re-export `blockdata::fee_rate` as opposed to
`units::fee_rate` in the event that we later add logic to
`bitcoin::blockdata::fee_rate`.
This patch adds an additional re-export: `sequence` (previously missing).
8098d5ee05 Reword `Address` constructor docs (Jamil Lambert, PhD)
Pull request description:
Change the wording of the Address constructor function docs to be a standard format. Following up on [#3584 comment](https://github.com/rust-bitcoin/rust-bitcoin/pull/3584#issuecomment-2457197066)
ACKs for top commit:
apoelstra:
ACK 8098d5ee055d672fc8f6e4eef3971b66478a61b0; successfully ran local tests
tcharding:
ACK 8098d5ee05
Tree-SHA512: 1027f334d69182465b2ecafd6fcf9f5deb2b299a64d12dea7f09f25379bd98b1e11be52a04fea83c2194164fd428931f6416eee52603f4bc043717b4e4d1b193
3523b8e117 Rename generic parameter and variable (yancy)
Pull request description:
Use W for Write
closes https://github.com/rust-bitcoin/rust-bitcoin/issues/3590
ACKs for top commit:
tcharding:
ACK 3523b8e117
apoelstra:
ACK 3523b8e1171663fc93ab25765271a1070a2d649f; successfully ran local tests
Tree-SHA512: 8dd9f38ee07e7652ebd291eb121a2630ebb09ea9ea70873f87e57241f51e5114106517511d1fe07774ec4f42920e9d0619031a1545787631a30422de12421a67
c61df05916 Fix bip34 number parsing for Block (junderw)
Pull request description:
Fixes#3583
ACKs for top commit:
apoelstra:
ACK c61df059160d3aeef73046de28cb5d5afcb962d2; successfully ran local tests
tcharding:
ACK c61df05916
Tree-SHA512: 3fade122f98c7c9e3b2888c33479d3a9426fb35f212ccee6b89b7cd5c92d2b58c93e165d5c59eda183c0943809d7e633d929000be92b197988a3ceb0ea37514f
1649b68589 Standardize wording to `constructs a new` (Jamil Lambert, PhD)
27f94d5540 Replace `creates` with `constructs` (Jamil Lambert, PhD)
Pull request description:
As discussed in issue #3575 there are various ways of saying a new object is created.
These have all be standardized to the agreed version.
Close#3575
ACKs for top commit:
apoelstra:
ACK 1649b68589834dfe9d5b63812da3e9f0e5930107; successfully ran local tests
tcharding:
ACK 1649b68589
Tree-SHA512: 0ed9b56819c95f1fc14da1e0fdbbe03c4af2d97a95ea6b56125f72913e8d832db5d2882d713ae139d00614e651f3834a4d72528bdf776231cceb6772bf2f9963
There is a range of different wordings used in the docs of constructor
type functions.
Change all to start with `Constructs a new` or `Constructs an empty`.
In functions that act like constructors there is a mixture of the usage
of `creates` and `constructs`.
Replace all occurrences of `creates` with `constructs` in the first line
of docs of constructor like functions.
81d8699b55 units: Put no_std up top (Tobin C. Harding)
3e332c3839 amount: Fix docs on FromStr (Tobin C. Harding)
5bec76aa51 amount: Fix rustdocs (Tobin C. Harding)
41c80cc476 amount: Improve docs on div by weight (Tobin C. Harding)
2b4a61739a Add type to debug output for Amount (Tobin C. Harding)
42e5043b33 Add from_int_btc group of functions (Tobin C. Harding)
Pull request description:
Improve the `amount` module by doing:
- Patch 1: Add/update `from_int_btc` and `from_int_btc_const` functions
- Patch 2: Add type to debug output for `Amount`
- Patch 3: Fix incorrect docs
- Patch 4: Make docs use correct style and be uniform across the two amount types
- Patch 5: Fix docs on `FromStr`
ACKs for top commit:
apoelstra:
ACK 81d8699b55dad570247cb14d2b3eea64270a83cf; successfully ran local tests
jamillambert:
ACK 81d8699b55
Tree-SHA512: ddd6e02b4cd9a9aa8cbdd2d2f7ae289a6bcca9eb002ef0c6d83a6eca950b2cd08f5918286bb33e814f321e3bfe83fdf75ae051cf8f91ee45d3e4abe76c1c2a4c
Is there any advantage trying to lay out the re-exports to give users an
idea of the crate structure?
We have the explicit aim that users who depend on `bitcoin` do not ever
need to reach directly into `primitives` (or `units`) however it is kind
of nice to know where things come from, saves jumping to multiple files
looking for them (for those of us that jump to files manually).
I do not know how all the re-exports interact with other folks IDEs, I
personally open files manually and just remember where stuff is.
85942c355d Re-export block::Header as BlockHeader (Tobin C. Harding)
Pull request description:
For users who want to just grab stuff from the crate root it makes total sense for there to be a `BlockHeader`.
Another nice thing, in the HMTL docs it makes BlockHeader be in the struct list right along with `Block`, `BlockHash`, and `BlockHeight`.
Close: #3548
ACKs for top commit:
apoelstra:
ACK 85942c355dfdcf9ddf9a46202f4db56794dcc85d; successfully ran local tests
jamillambert:
ACK 85942c355d
Tree-SHA512: 6fbaf7936062323d31940179ffcbc62951b21f53955a42dca2e28476bda0cebeb041db0e1b4f1ceeac32e43d94fe5476ef055595ae88dc6cfc266d32082bdf4d
4431df18fe script: remove `unsafe` marker from slice-to-script conversions (Andrew Poelstra)
Pull request description:
The length of the slices is not a safety invariant.
Fixes#3531
ACKs for top commit:
tcharding:
ACK 4431df18fe
Tree-SHA512: 85f745058bc5bf68d312f75c53cef570ead986247ca3cb3fc54b5381dd0214e7df55c1fcb99f06e693b0b9478ec6a9785186cac56886f8007ab7b827d903bd01
The length of the slices is not a safety invariant.
Fairly large diff because I had to remove a bunch of `unsafe` blocks
around calls to this function.
Fixes#3531
Add/update the from_int group of functions to provide one that errors
and one that is const and panics (errors in const context are not useful
because one cannot call `unwrap` in const context).
We have a couple of problems:
1. There are two macros currently for fmt stuff that do similar things,
`arr_newtype_fmt_impl` and `hex_fmt_impl` - the difference is not
immediately obvious, its the way that the byte array is iterated.
2. Our hash types are missing `AsRef<[u8; len]>` and `Borrow<[u8; len]>`.
Introduce a new macro and remove a bunch of other macros. Include
extensive docs but hide the macro from public docs because its not
really for consumers of the library.
The macro requires `$crate::hex` to point to `hex-conservative`.
Note the macro is pretty generic (as in general purpose), `hashes` might
not be the right home for it. Potentially a better place would be in
`hex` itself?
For users who want to just grab stuff from the crate root it makes total
sense for there to be a `BlockHeader`.
Another nice thing, in the HMTL docs it makes BlockHeader be in the
struct list right along with `Block`, `BlockHash`, and `BlockHeight`.
This has been fixed and we use nightly to lint so we have access to the
merged fix.
Removing the attribute uncovers a bunch of real lint warnings, fix
them while we are at it.
a51768af3f key: Deprecate to_bytes (Tobin C. Harding)
3af3239ad0 script: Re-order functions (Tobin C. Harding)
db40297f87 script: deprecate to_bytes (Tobin C. Harding)
c5cd0db493 Revert the change to to_bytes (Tobin C. Harding)
dc2ca785d2 Add to_vec and deprecate to_bytes for array types (Tobin C. Harding)
a6b7ab32a8 Move impl_array_newtype to internal_macros (Tobin C. Harding)
Pull request description:
Use `to_vec` and deprecate `to_bytes`, the opposite of what we did in #2585.
For functions that return a `Vec` by first allocating use function name `to_vec`. This explicitly excludes:
- Functions that return an array (`CompressedPublicKey::to_bytes`)
- Functions that consume self and return a `Vec` without allocating (`ScriptBuf::into_bytes`)
See #3025 for discussion and consensus.
Close: #3025
ACKs for top commit:
apoelstra:
ACK a51768af3f3d4c8e138e1ded250800810bedc903; successfully ran local tests
Tree-SHA512: ee932c13ad2e09c2b76a7833b23c859df175aa307f56e673921f3ae8b5d865518c6f999749e3b627594457b3ca33301b777177ada3520cf006acc0f14e5dacf8
0bf1910980 Remove wildcard from script self re-exports (Tobin C. Harding)
397a4b9382 Remove wildcard in push_bytes module (Tobin C. Harding)
Pull request description:
We thought #3436 was done (well I thought it was), turns out I was wrong.
ACKs for top commit:
jamillambert:
ACK 0bf1910980
apoelstra:
ACK 0bf1910980a13005496244ec4d4adf0553afbc73; successfully ran local tests
Tree-SHA512: 131a4aa4a907099790d14cfc2d19305943a2270cf6852c7dd92e35ea69188c9a40797fb22fd2ed8b2fefc2d6380b884401b5e32f521711f0f7b2da610d0e332f
The private_key_debug_is_obfuscated test is removed because it belongs
in the secp256k1 library, not in the bitcoin library. Keeping it here
is redundant and creates unnecessary maintenance.
As we have been doing in other places deprecate `to_bytes` in favour of
`to_vec`. Note this is only for functions that return a `Vec`, the `key`
module has `CompressedKey::to_bytes` still as it returns an array.
Deprecate the `Script::to_bytes` function in favour of `to_vec` as we
are doing elsewhere.
Note that `ScriptBuf` has `into_bytes` because it does not copy.
Potentially this should be deprecated in favour of `into_vec`?
Note that in regards to the `to_` prefix this naming as valid according
to convention because the `Script` type is borrowed and `to_vec` copies
the underlying bytes.
During this release cycle we deprecated `to_vec` in favour of
`to_bytes`, we have since reversed our position on the name.
Remove the deprecation of `to_bytes` from the three types that had it
and use `to_vec`.
For the array wrapper types (eg `ShortId`) created with the
`impl_array_newtype` macro deprecated the `to_bytes` function and add a
`to_vec` function.
Discussed and decided upon in issue: #3025
dfb76c1e15 Use doc(notable_trait) (Tobin C. Harding)
Pull request description:
There is an unstable feature that puts up a little 'i' in a circle next to any function that returns a type that implements an notable trait. For us this means we can make the extension traits more discoverable.
ref: https://doc.rust-lang.org/unstable-book/language-features/doc-notable-trait.htmlClose: #3232
ACKs for top commit:
apoelstra:
ACK dfb76c1e15933fe0058c1bb69c4b1b9acddceee8; successfully ran local tests
Tree-SHA512: 0fbc7a2a3c8c499a9276d1e86b9966a7ae6bd8a354aff5fd40aa11d07945db589b2a9c2cdfa43ddadfafcee706ae7f68cedc269f74622643307cc43cd07d554f
In the `script` module remove the wildcards and re-export stuff from
`self` explicitly in both `primitives` and `bitcoin`.
Internal change only, everything is re-exported.
The current feature gating is wrong, this bug is unreleased because it
was introduced #2585.
The `impl_array_newtype` macro is only used in the `bitcoin` crate, it
does not need to be in `internals`. Also, other crates have an `alloc`
feature which `bitcoin` does not have so if we ever need it in other
places we'll need a duplicate with the correct feature gating anyways.
Move the macro to `bitcoin::internal_macros` and remove the incorrect
`alloc` feature gating.
WARNING: This is not like all the other extension traits.
Because of the use of generics on various `Transaction` methods it is
not easily possible to use the `define_extension_trait` macro.
Manually create the extension traits (public and private) for the
`Transaction` type. This is quite ugly but c'est la vie
(Includes two in the `transaction` module and one in the
`consensus_validation` module.)
Currently `script_pubkey_lens` returns a generic `Iterator` using `impl`
syntax. This syntax is not supported in traits and we want to move the
function to the soon-to-be-added `TransactionExt` trait.
Add a struct to hold the iterator returned by `Map`, this is ugly but
its the least ugly thing I could come up with.
Split the `Transaction` impl block into three parts:
- The bits going to `primitives`
- The bits staying in a public extension trait
- The bits staying in a private extension trait
Internal change only.
It is acceptable to use a wildcard import in bench code for the same
reasons it is acceptable in the `tests` module.
In preparation for introducing extension traits in the `transaction`
module use wildcard import in the module's bench code.
f2e1a4b16c bitcoin: Add some upgrade notes (Tobin C. Harding)
Pull request description:
While upgrading `miniscript` to use tip of master I made some notes to help users upgrade. Just throw them in the changelog file or now.
ACKs for top commit:
storopoli:
ACK f2e1a4b16c
apoelstra:
ACK f2e1a4b16cb8b71b50da723a20761fbe3822d6fc; successfully ran local tests
Tree-SHA512: 3e7a64445476dce8c716edf127b2594c434948bfff7c301ac74a723fa49b2784cca90cf74d231fe18a9fa8e80ffd5cb43232fb90aeae5943568623d4252fc4ef
c89b816437 psbt: Fix bug in Subtype consensus_encode (Tobin C. Harding)
Pull request description:
In #2906 we switched from using a `u8` for type keys to using a `u64` and encoding as a compact int (inline with the spec). Note that a `u8` encodes to the same bytes as a `u64` when the value is < 252.
In that patch, I introduced a bug because the length returned by `PoprietaryKey::consensus_encode` uses a hard code 1 for the length of the encoding (because of single byte) instead of the variable length for the new compact encoding.
Bug showed up in fuzzing, and was isolated by Jamil - mad props.
Fix: #3501
ACKs for top commit:
jamillambert:
ACK c89b816437
apoelstra:
ACK c89b8164377123eb20476636f2f5271c6a687406; successfully ran local tests
Tree-SHA512: 1b61b6a9ece197d74038ceedb447fd3ca21db8e2a6a96c9281a99ac232c18c3ca55da8e3f46930401714d3575e9a406a36e4f44929ca963208a5df4be6b46cfb
025a8773bf Use fully qualified path in macro (Tobin C. Harding)
Pull request description:
Using fully qualified paths in macros reduces maintenance burden. We have one macro where we use relative path to access the `psbt` module.
Refactor only, no external change.
ACKs for top commit:
apoelstra:
ACK 025a8773bf63aacdaca011ef000f41a85a961567; successfully ran local tests; will one-ACK merge
Tree-SHA512: eb5923a48ae4d82499679a58375ef7d2e8ba85c91671e350f7be19f0372750a269f44dd2f05f4a70ed0c7f277b160400eb41ff1d42b90e6057f1344be7e11a89
66da2266e2 Explicitly re-export stuff from crates down the stack (Tobin C. Harding)
Pull request description:
Up until recently we were using wildcard re-exports for types moved to `units` and `primitives`. We have decided against doing so in favour of explicit re-exports.
Audit `units` and `primitives` using `git grep 'pub enum'` (and `struct`) and explicitly re-export all types.
Remove all wildcards except for the re-exports from `opcodes`, there are too many opcodes, explicitly re-exporting them does not aid clarity.
ACKs for top commit:
apoelstra:
ACK 66da2266e26dfe53947c4606e9d18620931e93cf; successfully ran local tests
Tree-SHA512: 74717f8b127e975e3d131aab884bdfe78e699d88b7ee1db7731ad117437d37684285264001cf6b2182eb1e565171167695e00c4b6aef28a3e26b69d9cebfbb74
9a7b1c232b Wrap the bech32 decoding error (Tobin C. Harding)
Pull request description:
In #2381 we attempted to fully encapsulate the `bech32` crate to help with stabalizing `rust-bitcoin` however we failed to notice the `address:ParseError` has a variant that includes `bech32`. Public enums have public variant internals in Rust. Also the `From<bech32::segtiw::DecodeError` makes `bech32` public.
Closes: #3043
ACKs for top commit:
apoelstra:
ACK 9a7b1c232b494dccdce091a46d916cc411a612a1; successfully ran local tests; will one-ACK merge since this is a gazillion years old and obviously right
Tree-SHA512: b5053aa43107aa47da1fe7e7db0f882cfb231b9769a7b67d8c930532c471df191f588bf98f2b00cc76d5a2e9c74e035ee96128da115363ac3952f96a766494ea
Using fully qualified paths in macros reduces maintenance burden. We
have one macro where we use relative path to access the `psbt` module.
Refactor only, no external change.
In #2906 we switched from using a `u8` for type keys to using a `u64`
and encoding as a compact int (inline with the spec). Note that a `u8`
encodes to the same bytes as a `u64` when the value is < 252.
In that patch, I introduced a bug because the length returned by
`PoprietaryKey::consensus_encode` uses a hard code 1 for the length of
the encoding (because of single byte) instead of the variable length for
the new compact encoding.
Bug showed up in fuzzing, and was isolated by Jamil - mad props.
We do not want `bech32` to appear in the public API of the `address`
module in case `bech32` does not stabalize before the soon-to-be-created
`address` crates does.
We already had a go at removing it but forgot one error variant - wrap
the variant in a new type with a private inner bech32 error field.
Up until recently we were using wildcard re-exports for types moved to
`units` and `primitives`. We have decided against doing so in favour of
explicit re-exports.
Audit `units` and `primitives` using `git grep 'pub enum'` (and
`struct`) and explicitly re-export all types.
Remove all wildcards except for the re-exports from `opcodes`, there are
too many opcodes, explicitly re-exporting them does not aid clarity.
5633b10f5c Manually implement compute_txid and compute_wtxid (Tobin C. Harding)
Pull request description:
We would like to move the `Transaction` type over to `primitives` including the `compute_txid` and `compute_wtxid` functions however currently the implementations, as expected, use `Encodable`.
Manually implement `Encodable` by hashing all the fields in the correct order.
Note we have unit tests already that check the output string of the txid returned so these act as regression tests for this patch.
ACKs for top commit:
apoelstra:
ACK 5633b10f5c826e0b2ac47dd85f697f12710898d7; successfully ran local tests; nice
Tree-SHA512: 66a955d3d896801cfefe0388aade3a31f22fac5b6da7b996be61f374b93772487c0c203320aaf5165fcef26874564bce375ecb364175b0a01c3008b7ea8db981
We would like to move the `Transaction` type over to `primitives`
including the `compute_txid` and `compute_wtxid` functions however
currently the implementations, as expected, use `Encodable`.
Manually implement `Encodable` by hashing all the fields in the correct
order.
Note we have unit tests already that check the output string of the txid
returned so these act as regression tests for this patch.
In preparation for moving the `TxIn` over to `primitives` make the
private `TxIn::BASE_WEIGHT` associated const into a file-scoped constant
because the other alternative is to make it public.
9c2ac46902 Split up ParseError (Jamil Lambert, PhD)
3d994f7bdb Decode an address string based on prefix (Jamil Lambert, PhD)
Pull request description:
When a decoding error occurs for a bech32 address string the error is discarded and the same address string is attempted to be decoded as base58. This then incorrectly returns a base58 error.
Check the string prefix and decode as bech32 or base58 and return the relevant error. If the prefix is unknown return an `UnknownHrpError`.
Close#3044
ACKs for top commit:
tcharding:
ACK 9c2ac46902
apoelstra:
ACK 9c2ac46902ae2e6f2513ee125ea5c89953ac89a2; successfully ran local tests
Tree-SHA512: 40c94328828af86723e84d4196e8949430fb9a15efd8865c18cb5048fe59b8a2514d97f4809d828353b78c010544a8a6d4589a8c9c7fbd75d9d0ecceb3151e8f
bbffa3db43 Remove the IO error from DecodeError (Tobin C. Harding)
713196be0d Return DeserError from encode::deserialize (Tobin C. Harding)
33566ac58c Split encode::Error into two parts (Tobin C. Harding)
b04142c745 Add encode::Error::MissingData variant (Tobin C. Harding)
5a42ef2850 Do not manually map IO error (Tobin C. Harding)
efd7f9f06c Add error constructor parse_failed_error (Tobin C. Harding)
ebfef3f114 Return generic error as Some (Tobin C. Harding)
a6254212dc Move consensus error code to submodule (Tobin C. Harding)
Pull request description:
The `consensus::deserialize` and `consensus::deserilaize_partial` functions should not return an I/O error. Doing so causes various other error types to include an `io::Error` and the `io::Error` is an annoying type to work with.
This PR is a bunch of steps, and it took me a good while with quite a bit of backtracking to get here. As such you may want to review the final state before looking at each patch.
The `consensus` errors can be further cleaned up but I'd prefer not to spend more time on this unless it has some chance of merging.
ACKs for top commit:
apoelstra:
ACK bbffa3db43802b30d23259c0372f16a877a0ef8b; successfully ran local tests
Tree-SHA512: 522fdd29638a214cb7fcee29dd3b9f5c846f041fba087a56a91b83e6d85f033cbed95f659dc4321cd4596943ff233bdd184cdfbfcc787fe89172bb93aa4ab186
Currently `combine_node_hashes` is an associated function, it is also
private. It is called from within other methods of the `TapNodeHash`.
In preparation for moving the `TapNodeHash` to `primitives` while
leaving all the methods in `bitcoin` in an extension trait; move the
associated function out of `TapNodeHash` and make it a stand alone
private function.
e7d326f071 Seal extension traits (Tobin C. Harding)
Pull request description:
The extension traits are temporary just while we try to stabalize `primitives`, they are not intended to be implemented by downstream.
Seal the extension traits so that downstream crates cannot implement them.
Fix: #3231
ACKs for top commit:
apoelstra:
ACK e7d326f071a368389f087ddb10ee9bbf3552c33a; successfully ran local tests; thanks! I know this is tedious and annoying
Tree-SHA512: 365979aeabb7941b9c8fa526f71aaadae3ab1cdd6a39e992c5eea2c1057b4b7c2b3a846ffd96a7eab47b9ad4e3e4de4fb141c24c62747e5cee45c74f52f9a172
The `DecodeError` (badly named) consensus decodes an object from an
iterator that implements `Read`. The `Read` impl never returns a real IO
error, we use the `io::Error` to temporarily wrap the error returned by
the inner iterator and unwrap it in `IterReader::decode`. As such there
is no reason for the `DecodeError` to hold an `encode::Error`, it can
hold an `encode::ParseError`.
The value of this change is easily seen in the removal of calls to
`unreachable`.
The `consensus::encode::Error` contains an IO error but reading from a
buffer only ever errors for EOF. We converted all instances of EOF to
`MissingData` already so now we can split the IO error apart from the
actual encoding errors variants.
The `io::Error` is troublesome because it contains a bunch of stuff that
never happens when reading from a buffer. However the EOF variant can
occur if the buffer is too short. As an initial step towards reducing
usage of the `io::Error` add a `MissingData` variant to the
`encode::Error` and when converting from an IO error map to
`MissingData` if EOF is encountered.
The `encode::Error::ParseFailed` variant holds an inner string, this is
suboptimal.
In an effort to patch the `encode::Error` while mimizing the diffs
required add a helper function that creates the variant. The benefit is
that later patches that effect this variant will only need to update the
constructor function and not every call site.
Internal change only.
The `consensus` module has a bunch of error types, move them all to a
separate module. Add re-exports so the types are still available at the
same place they were. Make the `error` module private and re-export all
errors from the `consensus` module root.
ParseError is too general and the functions returning it do not have an
error path for all variants.
Split out the Bech32 and Base58 related errors into their own enums.
The extension traits are temporary just while we try to stabalize
`primitives`, they are not intended to be implemented by downstream.
Seal the extension traits so that downstream crates cannot implement
them.
Fix: #3231
c1eccfde25 Move Witness to primitives (Tobin C. Harding)
6ce76cd7c8 Add unstable constructor to Witness (Tobin C. Harding)
Pull request description:
Patch 1 introduces a new policy to the codebase, we use `foo__unstable` for public unstable functions and there are zero semver guarantees if you call these functions.
Patch 2 does the move.
Close#3406
ACKs for top commit:
apoelstra:
ACK c1eccfde25fd4c2b19e7ec6759352b46ac246113; successfully ran local tests
Tree-SHA512: 2388066be2b6bb2cf3d6757c8f6334beeda6115ef1ce7c537955d32aa5e466add5162d0d2adee27f416fe622fc93c4e94bd848326463ee55e08d1c0f4e03719c
When a decoding error occurs for a bech32 address string the error is
discarded and the same address string is attempted to be decoded as
base58. This then incorrectly returns a base58 error.
Check the string prefix and decode as bech32 or base58 and return the
relevant error. If the prefix is unknown return an `UnknownHrpError`.
Move the `Witness` over to `primitives` leaving behind any method that
takes or returns a `Script` or a signature.
Includes addition of a feature gate to unit test.
In preparation for moving the `Witness` to `primitives` we need a way to
construct the `Witness` when decoding. In order to maintain the current
performance and not introduce additional allocations we need to be able
to construct a `Witness` from the content buffer, this leaks the
implementation details of `Witness`.
Add a clearly marked unstable constructor to create a `Witness` from
parts. This introduces the concept of `foo__unstable` function names;
add a section to the README describing unstable functions and semver
guarantees.
f37b573290 bitcoin: Set version to 0.33.0-alpha (Tobin C. Harding)
Pull request description:
We would like to create branches in other repos/crates that track master in this repo for testing purposes. In order to do so we need a non-0.32 version otherwise `cargo` pulls from crates.io.
Set the version to `0.33.0-alpha` - try not to get too excited, this release is a looong way away.
ACKs for top commit:
apoelstra:
ACK f37b5732901133eff0b8b11744f743c71533c240; successfully ran local tests; though I think if you try you can make cargo behave better
Tree-SHA512: 08d9f6e658ac575e4d42681ffe3fff2116ee35e31c1150b0f21228cb5ef9fc326ea604a9cfc56378a7da60815c2e6e9add4dd4d96969fea2dda2005d1c9af34f
ff64fa3c46 Move block::Header to primitives (Tobin C. Harding)
65925117a0 Manually implement block::Header::block_hash (Tobin C. Harding)
b02ab25342 Add regression test for block_hash function (Tobin C. Harding)
5614694b69 block: Remove wildcard re-export (Tobin C. Harding)
Pull request description:
- Patch 1: Trivial preparation.
- Patch 2 and 3: Reduce the API surface in a disappointing way due to the orphan rule.
- Patch 4: Do the move.
ACKs for top commit:
apoelstra:
ACK ff64fa3c46 successfully ran local tests; nice!
Tree-SHA512: 8d93de4a12c9f71f9dfbdc023fd8defb78f7d3da995490af8f83a927c2ca6338dd236bc08691311dc7345183fb6d0be61eedce3e4424d4060be2de934facd60a
88a35c8918 test: add test for new sign fn (Chris Hyunhum Cho)
Pull request description:
Follow up https://github.com/rust-bitcoin/rust-bitcoin/pull/3456.
add test to verify the signature generated from newly added `sign` fn.
ACKs for top commit:
apoelstra:
ACK 88a35c8918f48e72f032b73a233a016a1a0056b6; successfully ran local tests; sorry, testing local CI changes..
tcharding:
ACK 88a35c8918
Tree-SHA512: 8c457fbabf1ff86a9369934564874e78660f706714465731c185da16eff5c88a5e680c4373effbcc273394a5653edde9f559558917fee6e438b79bfee6f63b22
Tobin C. Harding
Shing Him Ng
merge-script
yancy
Jamil Lambert, PhD
junderw
Fmt Bot
Diogo Canut
Leo Nash
Casey Rodarmor
ChrisCho-H