-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TX hash mismatch for non-canonical TXs #321
Conversation
This only concerns the free-floating `hash_transaction()`. Fixes #314
Why do we have this redundant functionality (both free floating At least now one just refers to the other but it's still a bit weird. Was it easier to map a function over values from WASM or some other WASM-related ease of use? I vaguely remember hearing something about that years ago but I could be wrong. @SebastienGllmt If there's no good reason to have both I would prefer we just have one or the other to make the API simpler. Do we want to provide some functionality for ensuring the entire tx is canonical? We could probably auto-gen or write a |
Use `TransactionBody` instead of of [u8; 32] to be consistent with `hash_transaction()`. Moves all the functions that were added directly to `mod.rs` in #298 files to `utils.rs` files where they should be since they aren't auto-generated.
If I remember correctly, it had to do with supporting multiple eras where the function on the type itself would always use the current era, but the standalone utility functions would be provided for old eras as well. I don't think we need this anymore with our new project configuration though |
It looks like in new CML we only had the standalone and the methods were added in #298 when adding the extra multi-era functionality needed to use in Carp. I moved those to their Do we prefer the standalone or the attached methods if we pick to just have one? What about the other hash functionality (plutus datums, metadatums). |
The way you did it in this PR is my preferred way 👍 |
There are some key things we shouldn't change like the tx metadata and the plutus datum. I think trying to make things canonical could make sense, but it could also introduce subtle issues and so I'm not really sure it's worth touching |
I am reading CIP21, just to make sure I understand this:
Does this mean that the tx body has to be canonical - e.g. the hashes are canonical bytes, but were computed on arbitrary CBOR? And the outer transaction could be encoded as arbitrary CBOR it's just the Earlier in the CIP it says:
which I first interpreted as the whole transaction before (thus metadatums/etc too), not just the body, but maybe it's just ambiguous wording and it just means the body? I guess we can just keep things how they are and assume anyone implementing for HW wallets fully understands CIP21 and CBOR encodings? I'll add a line to the CBOR section of the docs stating that all structures default to canonical CBOR unless created from deserialized bytes just to make it clear. |
This only concerns the free-floating
hash_transaction()
.Fixes #314
Use
TransactionBody
instead of of [u8; 32] to be consistent withhash_transaction()
.Moves all the functions that were added directly to
mod.rs
in #298 files toutils.rs
files where they should be since they aren't auto-generated.