Skip to content
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

Two questions: Size is de facto in first byte sometimes? Formal standard? #23

Closed
ttmc opened this issue Mar 2, 2016 · 3 comments
Closed

Comments

@ttmc
Copy link

ttmc commented Mar 2, 2016

At ascribe, we'd like to make BigchainDB interoperate with IPFS. One step will be identifying BigchainDB transactions by their multihash. (Currently we assume all hashes are sha3-256, but that's easy enough to change, and it would be nice to allow for future hash functions.)

We currently have two questions about multihash:

  1. The first byte identifies the hash function, so for example 0x16 means sha3-256. The second byte is the digest size in bytes, but wait, isn't that already encoded in the first byte (at least in this case)? Is the second byte as digest size just there for hash functions where the output size must be specified independently (as with SHAKE128)?
  2. Is multihash going to be proposed as a formal standard with some standards body (such as an RFC)?

We created a related issue on the BigchainDB repository: bigchaindb/bigchaindb#100

@Nemo157
Copy link

Nemo157 commented Jun 14, 2016

There's an answer for 1 at #1 (comment)

@jbenet
Copy link
Member

jbenet commented Aug 13, 2016

@ttmc

  1. as @Nemo157 said, it's not enough to base on the standard hash output. many people truncate or extend hashes.
  2. yes it is. it's likely going to IETF. we're working on more formal specs now.

@jbenet
Copy link
Member

jbenet commented Aug 14, 2016

Started larger spec in #41 -- follow along there.

@jbenet jbenet closed this as completed Aug 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants