Why is a CIDv0 converted to CIDv1 not the same as a file added with `--cid-version=1`?

Help
,
1

From my understanding, a CIDv1 is backwards compatible with a CIDv0, but only if that CIDv1 was created with the default settings (base32, sha2-256, etc).

After adding a file using ipfs add ... (defaults to using CIDv0 in go-ipfs), I use ipfs cid base32 <cidv0> to output its CIDv1 equivalent. The v1 hash I get back is not the same as the v1 hash I get if doing ipfs add --cid-version=1 .... Why is this?

I thought this might be because adding a file with CID version 1 forces --raw-leaves=true. Doing the same add but with the long option set to false did change the final v1 hash, but it still wasn’t the same v1 hash output by the v0 cid base32 subcommand.

I also tried comparing both the first and second mentioned CIDv1s with two runs of ipfs cid format <cidv1> -f="Prefix: %P, Multibase: %b, CID: %s" -v=1 -b=base32 but that didn’t provide any clues either as to why they differ. Though on second thought, this may not reveal anything as I think it’s reporting on the output not the input.

Mostly curious and trying to understand IPFS, but my goal is to add some files as CIDv1s and for them to be considered the same as files potentially added by others using CIDv0 (which from using the Web UI import and go-ipfs, is the default, but I’ve also read CIDv1s are supposed to be the preferred CID version to use going forward). Probably missing something as I’m new to this.

Thanks!

2

because when you enable --cid-version=1 IPFS also enables --raw-leaves.
--cid-version=1 --raw-leaves=false should produce the same hash.

3

It doesn’t appear to be the case. You can try this:

ipfs add --only-hash --cid-version=0 <path>
# Outputs a CIDv0

ipfs add --only-hash --cid-version=1 --raw-leaves=false <path>
# Outputs a CIDv1

ipfs cid base32 <the_cidv0>
# Outputs a different CIDv1 compared to the previous command.
4

@Jorropo Is this a bug or am I doing something wrong here?

5

it works for me, you must be doing something wrong:

$ dd if=/dev/urandom count=1 bs=1024 iflag=fullblock of=f
$ ipfs add -n -Q f
QmUEf89QV4bP67rbpJhEbT7TKLuaoHoEoR4er3V2v75fGg
$ ipfs add -n --cid-version=1 --raw-leaves=false -Q f
bafybeicxtunppqw2iiszsejkjjmvf3xycme453oagxezmqftdwou3yq4iu
$ ipfs cid base32 QmUEf89QV4bP67rbpJhEbT7TKLuaoHoEoR4er3V2v75fGg
bafybeicxtunppqw2iiszsejkjjmvf3xycme453oagxezmqftdwou3yq4iu
1 Like
6

@Mesh are you able to reproduce the problem with every file, or just a specific one? What is the file size? Which version of go-ipfs are you running?

2 Likes
7

@lidel Just a specific one. I just tried it with a new plaintext file, and it does work. For some reason, the PNG I was performing the commands on just won’t produce the same CIDv1s.

go-ipfs v0.12.2 on Windows

8

would you mind sharing the file pls ?
Looks like a bug then sorry.

9

Ah I have found out,
When using --cid-version=1 ipfs will use binary CIDv1 in the root block.

10
1 Like
11

Here’s the PNG file just in case.

12

yeah, thx, nvm, any file bigger than the chunk size will have this behaviour

13

Thanks for filing the bug report. I suppose there’s no way around this until it’s fixed?

14

Personally that a WONTFIX (except maybe some docs), having to use --cid-version=0 and then ipfs cid base32 if you care about backward compat doesn’t look too bad.
I belive we just have to be carefull that this behaviour doesn’t happen with #4143.

I would say just use --cid-version=0 and then ipfs cid base32 and then it’s “fixed”.

1 Like
15

Just as a follow-up, when CIDv1 becomes the default, will this mean all of the content people have added over the years as CIDv0 may end up being added by new users as CIDv1s, and since CIDv0s converted to CIDv1s don’t match with CIDv1s created by add --cid-version=1, the old files won’t be considered as sources? What happens when CIDv2s become the standard? Will an identical Cat.jpg exist for every CID version? Or is this backward compatibility issue only present between CID v0 and v1?

1 Like
16

https://github.com/ipfs/go-ipfs/issues/4143#issuecomment-811105386