Introduce hash-like types#754
Conversation
rustaceanrob
force-pushed
the
hash-like-5-1
branch
2 times, most recently
from
9ee6616 to
f77ab57
Compare
|
Concept ACK, and proc macros aren't too hard to read, especially simple ones like you added. |
rustaceanrob
force-pushed
the
hash-like-5-1
branch
6 times, most recently
from
8537c18 to
161dc92
Compare
rustaceanrob
force-pushed
the
hash-like-5-1
branch
from
161dc92 to
c533b0a
Compare
|
A lot of my work on persistence relies on this change. @ItoroD can I get a review on this so I can respond to any outstanding feedback? |
Sure! will take a look in a bit |
| #[uniffi::constructor] | ||
| pub fn from_bytes(bytes: Vec<u8>) -> Result<Self, HashParseError> { | ||
| let hash_like: $core_type = deserialize(&bytes).map_err(|_| { | ||
| let len = bytes.len() as u32; |
There was a problem hiding this comment.
I tried doing some serializations with this. One observation I have is, when we get a txid from a transaction, in kotlin transaction.computeTxid() we get a 64 char Hex. So I had to convert to a 32 bytes array before passing it in here. So I guess the idea is anyone looking to store will be storing them as bytes (32 bytes) That pretty standard.
The conversion does work well! I can approve if you have no other comments
There was a problem hiding this comment.
Yeah in Kotlin this conversion can be done using the hexToByteArray() extension function. So you could do for example "abcd0123".hexToByteArray() to get your bytes.
There was a problem hiding this comment.
Ideally this type is used across the library, so you would be able to serialize to bytes instead of going through the string implementation
|
ACK c533b0a |
rustaceanrob
force-pushed
the
hash-like-5-1
branch
from
c533b0a to
58a515f
Compare
Types like "Txid", "Wtxid", "BlockHash", "DescriptorId", "TxMerkleNode" are all just 32 byte arrays that represent hashes with different meanings. Currently they are represented as strings at the FFI layer, but they are also meaningful arrays of bytes. Particularly if a user wants to implement persistence over the FFI layer, they would want to efficiently serialize these types. Here I am introducing a new group of types that all implement display, allow serialization to bytes, and may be constructed from an array of bytes. I went with a "rule of 3s" here, and also introduced a macro to do these implementations because there was a lot of boilerplate involved. Note that all of these are included in the wallet changeset, which is required to represent in-full for FFI-layer custom persistence.
rustaceanrob
force-pushed
the
hash-like-5-1
branch
from
58a515f to
22b213c
Compare
|
Itoro's comment made me realize that a follow-up PR could use the I found a few more:
|
5 participants
Types like "Txid", "BlockHash", "DescriptorId" are all just 32 byte arrays that represent hashes with different meanings. Currently they are represented as strings at the FFI layer, but they are also meaningful arrays of bytes. Particularly if a user wants to implement persistence over the FFI layer, they would want to efficiently serialize these types.
Here I am introducing a new group of types that all implement display, allow serialization to bytes, and may be constructed from an array of bytes. I went with a "rule of 3s" here, and also introduced a macro to do these implementations because there was a lot of boilerplate involved.
Note that all of these are included in the wallet changeset, which is required to represent in-full for FFI-layer custom persistence: https://docs.rs/bdk_wallet/latest/bdk_wallet/struct.ChangeSet.html
edit: Added
TxMerkleNode, which may be interesting in the future if merkle inclusion proofs come to the bindings layer at some point for Electrum users.edit: Added
Wtxid, which is how transactions are identified over the p2p network as of SegWit. This is useful for Kyoto users.Notes to the reviewers
bdk_chainis mostly an alias forsha256::HashChangelog notice
Txid,BlockHash,DescriptorId,Wtxid,TxMerkleNodeChecklists
All Submissions:
cargo fmtandcargo clippybefore committing