f9beb4d9495fab29 - bitcoind8333;
f9beb4d9495fab29 - omnicore-qt8333;
fbc0b6db4e8eaab9 - feathercoin-qt9336;
fbc0b6db4e8eaab9 - litecoind9333;
I think that's the brilliant thing about a simple ID like the one we are currently testing: The biggest problem altcoins are having, is that they have that stigma attached to them that most of them are shitcoins, meaning they are mere copypastes of other coins. And nothing says copypaste like seeing that a "dev" didn't even care to update the magic bytes, the timestamp, or the port, NOTHING.  As the example you posted shows very clearly. I mean, I get that devs reuse the same magic bytes, since those values are pretty arbitrary anyway. So I let that slip. But creating a clone of another coin and still leave the same genesisblock creation date there, although obviously the clone should have a later date, ... that is a pretty bad move. Same for using a port that is already used by the original coin, it's a bad move and shows carelessness! I can assure you there are many other instances.
Absolutely, as there are many more shitcoins than there are "real" coins. I can assure you that all the coins that have actual development behind them do have a very unique genesisblock, since it's like the dev's signature in a way. Dash has it, Litecoin has it, Spreadcoin has it, etc... Maybe we should take this into consideration right away and do some filtering about what coins we even want to "recommend for usage" within the decentralized blockexplorer. And that's where these collisions that are already happening add a benefit immediately, and are not a problem! No good coin is currently colliding, it's only the shitcoins that are causing collisions.Let's call them "beneficial collisions" or "revealing collisions" since they reveal a lot about the nature of a coin immediately. I love this. That's exactly why we are doing this "altcoin taxonomy" project.  |
|
|
|
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. |
|
|
|
Hey georgem, what exactly do you need to complete this phase of testing?
I mean, maybe a few of us could setup a bounty to give to who ever submits unique daemon information?
5 or more gets over 200SPR?
10 and over get 300SPR?
How many coins do you need? I'm sure we can do without 10's and 10's of shit coins... Can't we set a target say of top 50-100 coins?
 http://spreadcointalk.org/index.php?topic=735.0The idea is to build an ongoing R&D area (what we call "altcoin taxonomy") to get a picture of the whole ecosystem out there. It'll have to go on forever, since there will always be new coins. (I certainly hope) 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? Also, please note, that this coinURI is just a small subset of "altcoin taxonomy" (we need coinURIs for the upcoming decentralized blockexplorer), but there is much more research to be done within altcoins. (that's why it's its own "reserved" R&D area) I'm fascinated by altcoins in general, and as you correctly assume, there are 10's and 100's of shit coins out there. Maybe we can help the crypto society to better recognize shit coins with a review/rating system? (based on actual mathematics that analyze/compare blockchains and sourcecode) But I'm just thinking out loud here and giving you a glimpse into a possible future, I'm just saying that "altcoin taxonomy" will consist of much more than just naming / IDing each altcoin. I do have a few ideas, and everyone's feedback and contributions is welcome. PS: Look at "altcoin taxonomy" as an R&D area that we have now initialized and that will stay with us forever. Same counts for Big Data btw. |
|
|
|
You would be surprised how many Dash people are starting to invest in Spreadcoin. Get SN out earning some rewards and quite a lot of people I know, who like me have several MN's, will pile into Speadcoin in a big way. Remember that DRK didn't chase after any exchanges? Get SN's out, let people start accumulating rewards and the price increase will get us listed on Polo and other places. You can then take some time to build the first services while we builds SN's and the price. A ten fold price increase here is more likely to happen in the next months than Dash going up by that much. But it will only happen when people see and start setting up SN's. It is a good time to get in and build a nice pot, but you know people really want to have something to download, setup and play with before throwing lots of money around. Thanks for your encouraging words. I am not holding anything back here. Development is progressing nicely, I will soon be working on spreadcoin fulltime! |
|
|
|
Great work guys. Couldn't find the reference to your forum so posting it here: Diamond's data for the explorer.  e4e8dbfd51e04f3e;diamond-qt-2057;e4e8dbfd;aaaa88b5c5c937bcd7709c86903197009e02495dba5b919488d996dec10d26c4;1373654846;17771;
Thanks for your help. You will find everything "altcoin taxonomy" related here: http://spreadcointalk.org/index.php?board=21.0And you need to copypaste the data here: http://spreadcointalk.org/index.php?topic=731.0If you aren't registered in the forum, I can do it for you. EDIT: I just did. |
|
|
|
Yep, it has already been brought to my attention earlier: Never actually thought I would see Cryptsy die. But zero transactions and it looks like it has flat lined   Speaking of exchanges, let's get listed on some more! Err, let's create our own...no, wait - how would we get listed? Being listed on YoBit is really easy. Just send them a request throught CoinAdd. Even if I usually buy my spreadcoins throught Bittrex, being able to buy them from YoBit would really cool ! I could buy more ! Salut, Erkallys, Je pense que Spreadcoin est déjà listé sur Yobit. https://yobit.net/en/trade/SPR/BTC |
|
|
|
But if you were to add spreadcoin's coinURIs to your DOACC then we could reuse ALL your data within the blockexplorer.  That’s neither desirable nor necessary. The “giant database” over-simplification is doing you a disservice. DOACC is expressed as an RDF graph and the effect you describe can be achieved quite straightforwardly by creating a graph of Spreadcoin referents linked to DOACC's referents, such as the one I created from the postings to the Spreadcoin forum thread and dropped onto pastebin. SPARQL trivially enables querying the union of the graphs. Minki (a savvy lass) provides a SPARQL endpoint configured to use the DOACC dataset as default graph. If the Spreadcoin reference is : <http://purl.org/net/bel-epa/ccy#C9aeefa4f-c5e8-4056-8b8c-99da124ad07a> then the query would be: PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
PREFIX doacc: <http://purl.org/net/bel-epa/doacc#>
SELECT ?doaccuri ?label ?symbol ?algo
FROM <http://pastebin.com/raw/UQZdHtiP>
WHERE {
ccy:C9aeefa4f-c5e8-4056-8b8c-99da124ad07a ccy:cryptocurrency ?doaccuri .
?doaccuri skos:prefLabel ?label .
?doaccuri doacc:symbol ?symbol .
?doaccuri doacc:pow ?ps .
?ps skos:prefLabel ?algo .
FILTER LANGMATCHES(LANG(?label), "EN")
}
Here's a clickable version of the SPARQL query URL that performs the search and forwards to the results page. As regards terminology, the CCY ontology uses the term “coinURI” to model the coin payment URIs, e.g. bitcoin:12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu?amount=1.2&message=Payment&label=Satoshi&extra=other-param
Cheers Graham Somebody already uses the term coinURI for something else? Well, I'll be damned. Thanks for all your info, I'll have to digest this. |
|
|
|
|  |  | Decentralized Blockexplorer
Competitive collateral servicenodes each running a UBA module will enable spreadcoin's first decentralized service:
A decentralized blockexplorer operating from within the spreadcoin wallet, allowing servicenodes to host any coin they like.
The ongoing "Altcoin Taxonomy Project" and its implementation of coinURIs will create the largest best reviewed database of altcoins,
encouraging a more informed decision-making among both users and servicenode operators.
| | | | | | | | |  | | Anonymous & Decentralized Big Data Methodology
Big Data done the wrong way can pose a great danger to both privacy and decentralization.
Therefor preliminary research is currently done to explore privacy, security and validity issues.
Note that the potential monetization and profitability of Big Data is completely irrelevant at this stage.
It is entirely possible that Big Data will turn out to be incompatible with true decentralization principles,
in which case we will limit the use of all analyzed network data to merely improve the operation of servicenodes.
| | | | | | | | |  | | Proof Of Bitcoin Node / Proof Of Any Node
Proving that a full bitcoin node is exclusively installed and used by a single servicenode requires a
solution similar in complexity and about as groundbreaking as solving the double-spend problem in bitcoin.
Solving PoBN will likely allow the creation of a decentralized exchange and (should a valid big data methodology be found) a big data market. |
|
|
|
|
It will grow even faster once the blocksize limited is eg. set to 2 MB.
It currently hits the 1 MB blocksize limit from time to time ...
So in a few years 2 MB times 144 blocks a day = 288 MB up to ~ 100GB growth a year
It looks like your figures correlate to the 5% growth rate chart? I've just realised how important this project is to me:  pretty scary graphs! |
|
|
|
So the difference between your project and mine is:
Yours is a giant database regarding the "Description of a Cryptocurrency".
While the "altcoin taxonomy" project is about giving coins a unique collision-free identifier (coinURI), derived simply by reading its blockchain.
The goal is to tie the "blockchain of a coin" to the "design of a coin" (what is in DOACC) with the use of those coinURIs.
I thought you might be able to re-use the DOACC coinURIs but I was mistaken. Cheers Graham But if you were to add spreadcoin's coinURIs to your DOACC then we could reuse ALL your data within the blockexplorer. These coinURIs could be the bridge between blockchains and our databases so to speak. Currently, for our project, we are going with a combination of the 4 magic bytes of a coin's blockchain and the 4 bytes of the timecode of the genesis block's creation. This leads for example to the following coinURIs: Spreadcoin = 4f3c5cbb53d75160 Bitcoin = f9beb4d9495fab29 Dash = bf0c6bbd52db2d02 Litecoin = fbc0b6db4e8eaab9 We still need to process more coins, just to be 100% sure that there are no collisions between different coins. But it looks good so far! Think of it this way: we are creating a standard ID (coinURI) that isn't awarded by a human being, but that can simply be deduced from a coins blockchain (Magicbytes + time) even by a machine. This coinURI then serves as a key we can use in a database to search for the correlating coin specification/description. Only requirement would be that available databases start adapting coinURIs. BTW: nice sideeffect of adding coinURIs to your database is that it immediately adds knowledge to it (magicbytes and when the coin's genesisblock was created, you just need to convert hex to unix timestamp) |
|
|
|
Thanks, I'll look into it. So the difference between your project and mine is: Yours is a giant database regarding the "Description of a Cryptocurrency". While the "altcoin taxonomy" project is about giving coins a unique collision-free identifier (coinURI), derived simply by reading its blockchain. The goal is to tie the "blockchain of a coin" to the "design of a coin" (what is in DOACC) with the use of those coinURIs. |
|
|
|
Awesome, I'll add the info everywhere. |
|
|
|
Yeah, I was made aware of your fantastic project 2 weeks ago. Nice piece of work. Very inspiring! Sadly, I can't use it since your metadata doesn't include info about the more hidden things I need, like blockchain related data (magic bytes, hash, creation time of genesis block, etc..) or official P2P port, etc... That's why I created this tool here that automatically extracts this information: GenesisExtractorhttp://spreadcointalk.org/index.php?topic=731.0https://github.com/servicenodes/genesisextractorWould you like to take a look? I would love to collaborate with you on this. If it adds any value to your database, you are ofcourse free to use this tool for your project. Plus, it's just the first version, I'll add features over time. I'd love to get your feedback! |
|
|
|
Could you give a rough estimate of what kind of hardware specs a SN machine will need? The specs will of course affect the VPS prices, especially if you are going to go for good enough equipment (so it doesn't melt) and a reliable provider (that doesn't throttle you down).
Well, we'll have to find out in testnet. All I can say: for the first testnet sessions it will possible to run a servicenode on your normal computer. But if you run your servicenode on a server it will get a much better score. One of the many things I'm currently working on is how this score will be derived. Just as a reminder: 1) The seat is what enables you to even be considered for a reward. 2) But the score (actual performance of your servicenode) is what will ultimately determine the payment-schedule of your reward. BTW, 2) is not so much about rewarding top servicenodes even more, but rather about punishing servicenodes that do a crappy job, like having timeouts, not being available (uptime), etc.. |
|
|
|
Is there anywhere else I can read up to "prepare" for running a SN?
Currently much help is needed in the "altcoin taxonomy" project: http://spreadcointalk.org/index.php?board=21.0If you get involved more in the forum, it will be there where we will have more in-depth discussions. That makes sense then. I also can't help notice the underlying erotic tone here. LOL.
it's the horny hamster. |
|
|
|
I suppose we won't know the specifics until we have been through testnet.
yes, lots of parameters to be discussed! |
|
|
|
OK, cool. I have never run a full node of anything before, but I saw the posts mentioning the computer and bandwidth requirements some pages back. Will SN server machines run "heavy" like a machine that is mining, with wicked CPU/GPU load etc., or is it mostly data flowing to and from teh internets? This info will come in handy when I go to get some intel from a VPS provider I have in mind.
Lots of CPU (and disk) load because of constant indexing and hashing/structuring of all the blockchain data coming from all the daemons you will run. Quite some bandwidth because of all the communications that the servicenodes will have with each other, with the spreadcoin network, and ofcourse all the daemons will cause their own respective traffic too. No GPU load. |
|
|
|
Hey@ geoegem, this is camosoul, like for real: HAHAHA! I believe you, that is so him! gunthreadadapters, lol  |
|
|
|
|
Show Posts
