2986e1f983
I noticed that the little/big endian hex string functions for Sha256dHash did not match my intuition. What we should have is that the raw bytes correspond to a little-endian representation (since we convert to Uint256 by transmuting, and Uint256's have little-endian representation) while the reversed raw bytes are big-endian. This means that the output from `sha256sum` is "little-endian", while the standard "zeros on the left" output from bitcoind is "big-endian". This is correct since we think of blockhashes as being "below the target" when they have lots of zeros on the left, and we also notice that when hashing Bitcoin objects with sha256sum that the output hashes are always reversed. These two functions le_hex_string and be_hex_string should really not be used outside of the library; the Encodable trait should give access to a "big endian" representation while ConsensusEncodable gives access to a "little endian" representation. That way we describe the split in terms of user-facing/consensus code rather than big/little endian code, which is a better way of thinking about it. After all, a hash is a collection of bytes, not a number --- it doesn't have an intrinsic endianness. Oh, and by the way, to compute a sha256d hash from sha256sum, you do echo -n 'data' | sha256sum | xxd -r -p | sha256dsum |
||
---|---|---|
src | ||
.gitignore | ||
.travis.yml | ||
Cargo.toml | ||
LICENSE | ||
README.md |
README.md
Rust Bitcoin Library
This library is badly incomplete --- though at this point it is perhaps stable enough that pull requests could be accepted.
Currently development is following the needs of the Wizard's Wallet, which is a "lite" wallet which does SPV validation but maintains a full UTXO index. Its purpose is to be a usable-though-risky wallet which supports experimental user-facing features.
Pull requests to generalize the library or introduce new use cases would be great.
Building
To build, start by obtaining cargo. Then just run cargo build
.
To run the test cases, do cargo test
. Note that the tests must pass (and reasonably
complete unit tests provided for new features) before any submissions can be accepted.