Clarification of address prefixes

In the data-visualization repo, src/components/App/App.test.js, we have half a dozen hard-coded addresses prefixed by 0xDAG and I don’t know what’s the source of those. Example in the json:

signers: [
        "0xDAG6jScEJp1FnZtxM6JEDbctwcUADU6BYzhV8d3U",
        "0xDAG3FFi4xgHFHAWLGZyL4bPFCQhUkhjoTD4PsWhq",

The hash contains small and capital letters. There’s the keyHashToAddress function in src/main/scala/org/constellation/crypto/KeyUtils.scala in the constellation repo but I can’t find if that utility function is actively used right now.

• What’s the hash from the key? It appears after DAG follows a digit - is that always the case?
• ! If the hash is not actually displayed in hex, I’m very much against a prefix with a wrong type annotation. For parsers, they’ll not survive the G and it’s long and misleading. You could go with 0DAG or DAG (works especially if the char after DAG is a digit but I’d rethink even DAG if that’s not necessarily followed by a digit). I’m not sure how far the cryptography decision in the file are (seems under construction), but I’d refrain from a technically wrong annotation.
• Does the name keyHashToAddress derive from somewhere? Can’t find it on github in another project or on the BitcoinJ repo that’s linked to.
• Were those utils used to generate the hashes for the visualization? Can you point out which util functions aren’t actually interwoven in the code/necessary for compilation? Might help with audits.

[Nikolaj-K]

@tynes What I wanted to get at is that you can’t write 0x5g88jb1e as 5g88jb1e is not hex. That’s a wrong type annotation. The first row in your bitcoin link e.g. speak about the prefix xprv for 0x0488ade4, but they don’t mix things up. The sequence 0488ade4 is a valid hex number. That number 0x0488ade4 has properties, like being divisible by 22 (i.e. by the number twenty-two). Meanwhile, 0x5g88jb1e is just a sequence of characters. In the testnet-visualizar and the keyHashToAddress function, Constellation currently prefixes the address (which isn’t hex) with 0xDAG. You can’t, in any case, follow 0x by something that has a G in it or the other digits that the hash is using. Ethereum can use 0x because the addresses don’t contain character beyond f (i.e. sixteen). That’s why I proposing at the very least dropping that x to mitigate confusion. It’s a small operation now and you’ll be less wrong in the long run.

[ryle-goehausen]

Fixed here: https://github.com/Constellation-Labs/constellation/pull/151 thanks @Nikolaj-K