Andrew Poelstra f6d983b2ef Merge rust-bitcoin/rust-bitcoin#1532: Improve Psbt error handling ... e7bbfd3913 Improve Psbt error handling (DanGould) Pull request description: ## Separate `encode::Error` and `psbt::Error` recursive dependency This initial work attempts to fix #837's first 2 points > - The current psbt::serialize::Deserialize has an error type of consensus::encode::Error. I think we should cleanly separate consensus encoding errors from application-level encoding errors like psbt. > - There is a recursive dependence between encode::Error and psbt::Error which would need to be cleanly dissected and separated so that there is no dependence or only one-way dependence. ## Better `ParseError(String)` types arturomf94 how compatible do your #1310 changes look to address #837's third point with this design? > - There are a lot ParseError(String) messages that could use a better type to downflow the information. I think your prior art would completely address this issue now. ## On handling `io::Error` with an associated error `encode::Error` has an `Io` variant. now that `Psbt::deserialize` returns `psbt::Error` and produces an `io::Error`, we need an `Io` variant on `psbt::Error`. Except that doing so breaks `#[derive(Eq)]` and lots of tests for `psbt::Error`. Kixunil, I'm trying to understand your feedback regarding a solution to this problem. > I believe that the best error untangling would be to make decodable error associated. > I meant having associated `Error` type at `Decodable` trait. Encoding should only fail if the writer fails so we should have `io::Error` there (at least until we have something like `genio`). > > > [it] is a problem to instantiate consensus::encode::Error in [the psbt] module for `io::Error`? > > It certainly does look strange. Maybe we should have this shared type: > > ```rust > /// Error used when reading or decoding fails. > pub enum ReadError<Io, Decode> { > /// Reading failed > Io(Io), > /// Decoding failed > Decode(Decode), // consensus and PSBT error here > } > ``` > > However this one will be annoying to use with `?` :( We could have `ResultExt` to provide `decode()` and `io()` methods to make it easier. > > If that's not acceptable then I think deduplicated IO error is better. Kixunil didn't we just get rid of Psbt as `Decodable`? Would this make more sense to have as an error associated with `Deserialize`? Or did we do the opposite of what we should have by making Psbt only `Serialize`/`Deserialize` because of #934, where only consensus objects are allowed to be `Decodable`? I wonder if we prioritized that strict categorization and are stuck with worth machinery because of it. My goal with #988 was to get to a point where we could address #837 and ultimately implement PSBTv2. ACKs for top commit: tcharding: ACK e7bbfd3913 apoelstra: ACK e7bbfd3913 Tree-SHA512: 32975594fde42727ea9030f46570a1403ae1a108570ab115519ebeddc28938f141e2134b04d6b29ce94817ed776c13815dea5647c463e4a13b47ba55f4e7858a		2023-01-24 14:18:25 +00:00
..
contrib	Remove rand-std dev-dependency from secp256k1	2022-12-23 08:33:21 +11:00
embedded	Patch hashes and update the code	2022-12-18 14:33:55 +01:00
examples	Use marker type to enforce validation of `Address`'s network	2023-01-11 19:27:10 +08:00
fuzz	Use marker type to enforce validation of `Address`'s network	2023-01-11 19:27:10 +08:00
src	Merge rust-bitcoin/rust-bitcoin#1532: Improve Psbt error handling	2023-01-24 14:18:25 +00:00
tests	Use as_ref() instead of costly clone()	2023-01-09 23:17:04 -05:00
CHANGELOG.md	add some documentation clarifying the locktime ordering shenanigans in #1330	2022-12-15 23:12:03 +00:00
Cargo.toml	bip158: Replace usage of HashSet with BTreeSet	2023-01-23 08:38:08 +11:00
build.rs	Implement consensus encoding adapter for serde	2022-12-02 10:48:05 +01:00