Closed ttmc closed 6 years ago
@sbellem Looking at your PR https://github.com/bigchaindb/bigchaindb/pull/1899 it seems the answer to my first question is that there is an "id" key-value pair in the thing-to-be-signed, and that is also included in what gets hashed to compute the id. I will update this PR accordingly.
Regarding the id
field I decided to stay consistent with the fulfillment
field which we also set to null
before fulfilling.
Regarding whether to hash the message (transaction) before fulfilling I have not modified this right now. I am not sure about what is best, and what difference it makes.
@sbellem You're right, having the "id":null key-value pair is consistent with "fulfillment":null
I just updated this pull request (on how to construct a valid transaction), after you approved it... I changed it so the thing-to-be-signed now includes the "id":null key-value pair. (That key-value pair is also in the thing-to-be-hashed later.) Can you take another look at this PR before I merge it?
We've changed how to build a valid transaction in version 2.0 of the transaction spec. Now we sign (fulfill) first and compute the transaction ID (i.e. hash the transaction) last.
@sbellem I'm not sure of some things. Please read the steps with a critical eye. In particular:
utx_bytes
(i.e. the bytes of the unfulfilled transaction), do you first compute a hash ofutx_bytes
and sign that? I think you mentioned something like this. If the answer is yes, is it a SHA3-256 hash?