One of the more specific research goals of the genesisExtractor is to see if the coinURI format remains collision-free.
(no 2 coins receive the same coinURI)
It looks like the format is fine, but can we really say by just having looked at 50 coins?
I got the impression that solid mathematical proof will be required for a solution to be deemed acceptable for this particular problem in this particular domain.
IDing altcoins is similar to taxonomy as it happens in biology/geology,
or how a combination of zipcode and street /city name can help you pinpoint a position,
despite having the same city/street names being reused multiple times within the ecosystem.
That's not the problem. (ofcourse there may be confusing situations but they can be resolved)
Again, we are looking for a system that creates a bridge between the
blockchain of a coin and the
design of a coin.
Such a system does not require a mathematical proof.
It just needs to bring as much unique information together as needed to create as little collisions as possible.
That's a bummer but I think it would be unwise to try and ignore the implications.
And even if there remain collisions, they are immediately revealed since a lookup would give back 2 or more results.
At worst, the blockexplorer will not know what logo he has to depict.
Those aren't worrying implications.
Even more so: Since logos will be named using the ID, collisions reveal themselves rightaway (when data is updated) since it's not possible to have 2 files with the same name in a folder.
You will want to consider the issue of duplicate pchMessageStart character arrays (“magicbytes” in your terminology), some of which have already appeared in the posted results on the Spreadcoin forum:
f9beb4d9495fab29 - bitcoind8333;
f9beb4d9495fab29 - omnicore-qt8333;
fbc0b6db4e8eaab9 - feathercoin-qt9336;
fbc0b6db4e8eaab9 - litecoind9333;
I can assure you there are many other instances.
We know, we have barely started, that's why this is an ongoing R&D and why forexample the genesisextractor is also extracting more data at the moment, like
merkleroot, offial port, etc...
we are going to extend this to as much additional info as necessary (genesisblockhash, etc) until a pretty unique ID can be found. (you have to consider all the additional info that we put in our list, like official port, merkleroot, etc..)
We will probably have to consider data that isn't even in the genesisblock but rather in the following blocks.
If the string gets too long we will simply hash it back to a more acceptable size.
Net result, half the data in the proposed magicbytes+datestamp referent is profoundly unreliable and so is unfortunately and inconveniently inappropriate for the intended purpose of contributing to a unique identifier, even a domain-limited one.
We are not ignoring anything, we are continuing our research.
This system will be used for icons and coinnames, don't read anything more into it right now.
Also, I'd be hugely grateful if you could avoid (ab)using the term “coinURI” after I mentioned its prior use in the already-published open source CCY cryptocurrency ontology. I'd much prefer to avoid the sowing of unnecessary potential confusion. TIA.
No problem, I'll probably go with
coinID for now, I'm really not attached to any name right now.
