search

WebOfTrustInfo / btcr-hackathon-2017

Virtual hackathon to create spec and code for Bitcoin-based Decentralized Identifiers (DIDs)
https://weboftrustinfo.github.io/btcr-hackathon-2017/
14 stars 7 forks source link

When storing the DDO on IPFS how to encode the corresponding hash in the OP_RETURN #35

Closed squarfed closed 7 years ago

squarfed commented 7 years ago

IPFS uses a base58 encoding for the hashes which points to documents, example: QmeNm7hRTtLsYtQA1w8Tu9wHzu8ZfBFc4w59UMuAK3b2ar, which has length 46 bytes. In order to save space in the OP_RETURN one would like to store the raw decoded bytestring.

The above address has decoded representation: 12 20 ee 45 65 85 70 89 4a 2f fe f3 fe 11 de b3 0a ac 08 c4 39 8b e1 bd 25 0d 85 dd bc ca 67 1f 99 bf with length 34. The first byte 12 determines the encoding, sha256 (the standard one in IPFS). The second byte 20 is the length of the hash following it.

Should we keep these two bytes or drop them in the op_return?

Arguments in favour: without them the hash is a random number and censorship resistance improves. We also save space.

Argument against: knowing the hash used improves future compatibility.

kimdhamilton commented 7 years ago

Document as well

ChristopherA commented 7 years ago

I'm in favor of it being that our rule is that if it is a binary 256 bit value, presume that it is an IPFS hash and contruct it. It is the most decentralized and censorship resistance appraoch. If someone wants to refer to the other form, just make it a full URL. Both should work.

kimdhamilton commented 7 years ago

This issue was moved to WebOfTrustInfo/rebooting-the-web-of-trust-fall2017#39