- Move network::encodable::* to consensus::encode::*
- Rename Consensus{En,De}codable to {En,De}codable (now under
consensus::encode)
- Move network::serialize::Error to consensus::encode::Error
- Remove Raw{En,De}coder, implement {En,De}coder for T: {Write,Read}
instead
- Move network::serialize::Simple{En,De}coder to
consensus::encode::{En,De}coder
- Rename util::Error::Serialize to util::Error::Encode
- Modify comments to refer to new names
- Modify files to refer to new names
- Expose {En,De}cod{able,er}, {de,}serialize, Params
- Do not return Result for serialize{,_hex} as serializing to a Vec
should never fail
- Add serialize::Error::ParseFailed(&'static str) variant for
serialization errors without context
- Add appropriate variants to replace network::Error::Detail for
serialization error with context
- Remove error method from SimpleDecoders
- Separate serialize::Error and network::Error from util::Error
- Remove unneeded propagate_err and consume_err
- Change fuzzing code to ignore Err type
Previously this structure was unused, it's now being used by the `TxIn`
structure to simplify the code a little bit and avoid confusions. Also
the rust-lightning source code has an `OutPoint` similar to this one
but with the `vout` index as an `u16` to avoid unsafe conversions.
I've added to new methods to `OutPoint`:
- `null`: Creates a new "null" `OutPoint`.
- `is_null`: Checks if the given `OutPoint` is null.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
The `serde_struct_impl!` macro has been modified to be compatible
with the serde 1.0 crate, we use this macro and not the `serde_derive`
crate because the latter doesn't support Rust 1.14.0 which is shipped
on Debian stable and we should remain compatible with it.
Two new features were added:
- "serde": enables serialization/deserialization for common types, it pulls
the serde 1.0 dependency.
- "serde-decimal": enables serialization/deserialization for `UDecimal`/`Decimal`,
this pulls the strason 0.4 depdendency and the serde 1.0 dependency.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
- Add derive_pub to ExtendedPubKey
- Add derive_priv to ExtendedPrivKey
- Removed from_path from ExtendedPrivKey as it is superseded by
derive_priv
- Add checking of derive_pub and derive_priv to test_path
- Add checking of correct error when invoking ckd_pub on a hardened
ChildNumber
- Add test vector 3 from BIP32 specification
There seemed to be some confusion as to whether the internal
represenation of a ChildNumber is supposed to be the index (0..2^31-1
for _both_ Normal and Hardened) or the actual number (0..2^31-1 for
Normal and 2^31..2^32-1 for Hardened). This commits fixes this
confusion.
- Make clear that the internal representation is the index rather
than the actual number
- Make the internal representation non-public
- Provide methods for creating valid ChildNumbers
- Change relevant callers and tests to conform to this new ChildNumber
My rationale for using index rather than the actual number as internal
representation is that the difference between the two enum variants
already encode wether a ChildNumber is a normal one or a hardened one,
so the only bit of extra information left to be encoded is its index.
ExtendedPubKey and ExtendedPrivKey implemented `ToString` directly but
Rust documentation says to implement `Display` and get the `ToString`
implementation for free.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
Addresses #96.
Turns out it was being used for hex encoding/decoding, so replaced that with the `hex` crate.
i chose to import the `decode` method as:
```
use hex::decode as hex_decode
```
so that it is clear to the reader what is being decoded when it is called. "decode" is such a generic sounding function name that it would get confusing otherwise.
In a project of mine I needed to check the merkle root before
moving some Vec<Transaction>s around, so need to be able to
calculate the merkle root on a Vec<Sha256dHash> directly.
This resolves an very unergonomic API by allowing iteration over a
Transaction being signed's inputs without needing to take a
conflicting reference to the transaction.
The API is still relateively unsafe in that its very easy to
generate bogus sighashes with it, but this is much better than it
was, and its not clear how to fix it further.
This is needed to for a sane BIP143 implementation. Should be exactly equivalent to
serializing data into a vector then hashing that vector for all types.
Matt Corallo
Carl Dong
Sebastian Geisler
Andrew Poelstra
Kaz Wesley
Steven Roose
Jeff Barg
evgeniy.scherbina
Thomas Eizinger
Jean Pierre Dudey
Aleksei
Dawid Ciężarkiewicz
Savil Srivastava
Franck Royer
Sebastian Geisler
Roman Zeyde
Matt Corallo
Igor Aleksanov
Igor Aleksanov
Tamas Blummer