You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge #288: Introduce bitcoin-consensus-encoding 1.0 and implement traits for Transaction and subtypes
5eb4f8d add fuzztest for equivalence between new and old transaction decoding (Andrew Poelstra)
faf6ab5 implement Encode/Decode for Transaction (Andrew Poelstra)
b7b5886 implement Encode/Decode for TxInWitness (Andrew Poelstra)
d72094a implement Encode/Decode for TxIn (Andrew Poelstra)
02ab70d implement Encode/Decode for TxOutWitness (Andrew Poelstra)
28a3d6d implement Encode/Decode for TxOut (Andrew Poelstra)
a61cbab transaction: introduce PeginWitness type (Andrew Poelstra)
0b8fa43 transaction: strongly type script_witness (Andrew Poelstra)
9f82b4b serde: remove impls for PSET and Transaction (Andrew Poelstra)
c13d392 rename transaction to transaction/mod.rs (Andrew Poelstra)
c7e16cd confidential: implement Encode and Decode for rangeproof/surjectionproof (Andrew Poelstra)
aacd081 confidential: implement Encode/Decode for confidential commitments (Andrew Poelstra)
6baad08 hashes: remove deprecated macro (Andrew Poelstra)
dca9bb0 update bitcoin dependency to 0.32.102, hashes to 1.1 (Andrew Poelstra)
Pull request description:
This is a big PR. Please forgive me.
The goal is to replace the `Encodable` and `Decodable` traits from rust-elements with the new [`Encode` and `Decode` traits from bitcoin-consensus-encoding](https://docs.rs/bitcoin-consensus-encoding/latest/bitcoin_consensus_encoding/index.html). There are many benefits to this:
* Unlike the old rust-bitcoin traits, these ones are designed to be used by the general public for wire encoding formats, so we don't need to create our own duplicate crate and add a bunch of shim implementations; we can also write generic code that works between Bitcoin and Elements...
* ...but we largely won't need to, because `bitcoin-consensus-encoding` ships with functions for decoding/encoding to `std::io` types, unbuffered `std::io` types, Vecs/slices, and hex strings, while `bitcoin-hashes` ships with functions for encoding into hash engines, and `bitcoin-io` with functions for decoding/encoding into `bitcoin::io` types.
* These traits use the "sans-IO paradigm", meaning that they can be used in no-std environments without the need for shim crates like `core2` (deleted from crates.io) or `bitcoin-io`, whose types tend to pollute every codebase that touches them.
* The traits also require no allocators: it is easy to encode even complex objects like `Transaction` without needing to copy any data into auxliary buffers, and some for decoding. If an object does not itself hold a `Box` or `Vec` it should be possible to encode/decode it completely allocator-free. Again, without shim crates like `ArrayVec` or whatever. Coupled with allocator-free encoders like `rust-bech32`, it is now possible to write arbitrary error correcting codes and encode bitcoin/elements types into them without needing any auxiliary buffers
* Because these traits are defined by a stable 1.0 crate, after *years* of the rust-bitcoin ecosystem fighting over API breakage and promising not to 2.0 basic stuff, they should remain stable across rust-elements versions. Since rust-elements is far from stable, this should make upgrades *much* easier since it will be increasingly possible to interoperate multiple versions of it.
* It paves the way for us to replace `Sequence` and `LockTime` with `bitcoin-units 1.0` types; this may invite type confusion between "bitcoin locktimes" and "elements locktimes" but in exchange we get stable types that have had years of bugfixes and API improvements. (And locktimes in Bitcoin, and therefore Elements, are notoriously fickle and hand to use correctly. Every API improvement we shipped found bugs in rust-miniscript.)
* Along the way, I made many API improvements to rust-elements that aren't directly related to encoding, but without which it was quite difficult to implement. These increase the size of this PR but they're all changes that need to be made eventually.
ACKs for top commit:
delta1:
ACK 5eb4f8d; tested locally
Tree-SHA512: 2796f84295db4bf784e45a672eb108ece4406982fd897cd3dfc218d93d4b345ce6c742a7e9b6fef1e3ecaf48ec64f21fb5a10c20eeed9dc744a66d088330220e
0 commit comments