Good catch.

All those commits are from the Bitcoin dev team and were made before Deepcoin was started.

Deepcoin is what's termed a “full fork” of Bitcoin, one which includes the prior commit history of the repository, hence the 4000-odd commits.

Many devs strip off this history in a misconceived attempt to ... well, I don't know why to be honest. It's one of those ludicrous superstitions that typically develops amongst people with a relatively weak grasp of technology. It's a rather quaint notion that it somehow helps to mask the fact that they've copied a 2-year old codebase and royally mucked about with it. Experienced pros such as Peter know better, Peter has nothing to hide and making a full fork means that any fixes or enhancements to Bitcoin that are made after Deepcoin was forked can be straightforwardly (usually) embraced by a “merge” (kind of opposite of fork), so Deepcoin gets to nom, for free, all the good stuff produced the upstream Bitcoin devs for as long as the two codebases remain usefully common.

Cheers,

Graham

+10

Happy to help with the testing (Ubuntu trusty 64bit, OS X 10.6).

Cheers

Graham

More pertinently, the commit record - a full fork, a model of transparency and a rock-solid technical foundation for the coin.

https://github.com/Deepcoinbiz/Deepcoin/commits/master-0.8

(Tips hat in acknowledgement of a surgically clean approach)

Cheers

Graham

The primary claims are couched in classic marketing-speak

“The Groestl algorithm is possibly the single most GPU-efficient algorithm implemented in any cryptocoin on the market.”

“A comparison between many different algorithms shows that it has the lowest power consumption, heat, and noise of the array of newer ones being implemented in cryptocoins.”

I prefer more more traditional promotional vacuities: “The Groestl algorithm: farm fresh and quality assured.”

I meant something more like Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition, something that affords a more nuanced understanding. I found sections 5.1 Software performance, 5.2 Hardware performance and 5.3 Discussion to be invaluable in their coverage and clarity. There doesn't seem to be anything in there which singles out Groestl as particularly efficient other than a mild observation that it has good throughput/area - but that's a quality of the ASIC implementation in hardware, not of the GPU implementation in software. All of the SHA-3 final round candidate hash functions were implemented as ASICs, the NIST committee was slightly apologetic that they could only afford the 256-bit versions.

That was worth following up, TIL quite a lot and I discovered the delights of the iacr eprint list. Thanks utahjohn for prompting me to ask awkward questions.

So ... x11? Yeah, maybe - if there's a well-supported argument that can be made then I think the community can be offered a stimulating change. I'm very sympathetic to any change that benefits the Moonie-on-the-Clapham-bendibus.

I'm particularly keen to see a balanced discussion. Thus far, all the discussion has been about changing the coin's economics to better suit the objectives of the miners. Basically, this one-sidedness is increasing the risk that the tilt in favour of miners, already noticeably acute, will become even more angled away from the non-miner and with billions of MOON to be generated, the only way this coin can survive is by embracing the community of coin-users that gave the currency the velocity that was assumed in the original formulation and who now, after much Mooncoin inaction, understandably have found other interests to pursue.


Cheers,

Graham

Ah, the penny's just dropped for me, the difference is due to changes in the implementation on GPU architecture. ofc.


Cheers

Graham

I'd be grateful for some help, I can't find a mention of Groestl on any of the pages of that thread, which of the pointers should I follow?

Cheers

Graham

Thanks for the suggestion and pointer, apologies for subsequent hiatus, I needed to dig deep into the cryptographic underpinnings of folklore combiners such as x11.

I'm currently looking at a couple of sources of hard data.

1. The original Classification of the SHA-3 candidates, including reported performance statistics in cpb (cycles per message block) for 256 and 512 output lengths (sometimes labelled "-32" or "-64") on 32 & 64-bit host architectures:

Name_of_hash_function	32-bit_arch	Class'n	64-bit_arch	Class'n
ARIRANG-256	20	A	55.3	E
ARIRANG-512	14.9	AA	11.2	B
AURORA-256	24.3	B	15.4	B
AURORA-512	46.9	B	27.4	E
BLAKE-32	28.3	B	16.7	B
BLAKE-64	61.7	C	12.3	B
Blender-32	105.8	E	105.8	E
Blender-64	122.4	E	164.2	E
BMW-256	8.6	AA	7.85	AA
BMW-512	13.37	AA	4.06	AA
Cheetah-256	15.3	A	10.5	A
Cheetah-512	83.8	D	15.6	C
Chi-256	49	C	26	D
Chi-512	78	D	16	C
CRUNCH-256	29.9	C	16.9	B
CRUNCH-512	86.4	D	46.9	E
CubeHash8/1-256	14	A	11	A
CubeHash16/1-512	14	A	11	A
DynamicSHA-256	27.9	B	27.9	D
DynamicSHA-512	47.2	B	47.2	E
DynamicSHA2-256	21.9	B	21.9	C
DynamicSHA2-512	67.3	C	67.1	E
ECHO-256	38	D	32	D
ECHO-256	83	D	66	E
Edon-R-256	9.1	AA	5.9	AA
Edon-R-512	13.7	AA	2.9	AA
EnRUPT-256	8.3	AA	8.3	A
EnRUPT-512	5.1	AA	5.1	AA
Essence-256	149.8	E	19.5	B
Essence-512	176.5	E	23.5	D
Fugue-256	36.2	C	61	E
Fugue-512	74.6	D	132.7	E
Grøstl-256	22.9	B	22.4	D
Grøstl-512	37.5	A	30.1	E
Hamsi-256	22	B	25	D
JH-256	21.3	B	16.8	B
JH-512	21.3	AA	16.8	D
Keccak-256	35.4	C	10.1	A
Keccak-512	68.9	C	20.3	D
LANE-256	40.4	D	25.6	D
LANE-512	152.2	E	145.3	E
Lesamnta-256	59.2	E	52.7	E
Lesamnta-512	54.5	B	51.2	E
Luffa-256	13.9	AA	13.4	A
Luffa-512	25.5	AA	23.2	D
Lux-256	16.7	A	28.2	D
Lux-512	14.9	AA	12.5	B
MD6-256	68	E	28	D
MD6-512	106	D	44	E
NaSHA-256	39	D	28.4	D
NaSHA-512	38.9	A	29.3	E
SANDstorm-256	62.5	E	36.5	D
SANDstorm-512	296.8	E	95.3	E
Sarmal-256	19.2	A	10	A
Sarmal-512	23.3	AA	12.6	B
SHA-256	29.3	C	20.1	C
SHA-512	55.2	C	13.1	C
Shabal-256	18.4	A	13.5	A
Shabal-512	18.4	AA	13.5	C
SHAvite-3-256	35.3	C	26.7	C
SHAvite-3-512	55	B	38.2	E
SIMD-256	12	AA	11	A
SIMD-512	118	E	85	E
Skein-256	21.6	A	7.6	AA
Skein-512	20.1	AA	6.1	AA
TIB3-256	12.9	AA	7.6	A
TIB3-512	17.5	AA	6.3	AA
Twister-256	35.8	C	15.8	B
Twister-512	39.6	A	17.5	D
Vortex-256	46.2	D	69.4	E
Vortex-512	56	C	90	E

This is, of course, a preliminary classification performed in 2009.

2. Contemporary detail is less accessibly presented:

http://cryptography.gmu.edu/athenadb/asic_hash/table_view

http://bench.cr.yp.to/results-sha3.html

Looking at those benchmarks, I can't immediately see anything that might explain why x11 should run cooler. You're probably closer to the x11 details than I am, (I'm still ploughing my way through the relevant literature on folklore and other combiners to see if there's any traction there), did Euan provide a technical appreciation for the choice and ordering of the chain of hash fns for x11?

Zooko Wilcox-O'Hearn has provided (IMO) the clearest description of the trade-offs in a choice of basic folklore combiner.


My rapid review of the x11/GPU issue (hands-off, I'm afraid; my altcoin experience is circumscribed by my entry-level Acer Sandybridge) suggests that there were contemporaneous changes to the coding of the mining app. This would be unfortunate if true; it introduces a confounding factor that undermines the credibility of claims of improved efficiency accruing from the introduction of the x11 combiner in that it's impossible to disentangle the relative contributions of performance gains from i) enhancements to the application code and/or ii) the change in combo.

But it's an ill wind that blows no good - I now have at least a plausible explanation of the difference in reception between c11 and x11 ---  I've had a very hard time persuading myself that such a significant effect was due to a simple change in the batting order. Given what I now know, Occam's Razor tells me that it probably isn't and I should look elsewhere for the source of the difference in reception/perception. If there's any reliable, robust data which points to the opposite conclusion, I'd really appreciate a pointer.

Perhaps the most significant element to emerge from my consideration of a switch to x11 is that it would come at the cost of completely ruling out any possibility of merge-mining with our current altcoin kith and kin.

Cheers

Graham

Edit: extended header for more tabular space. enumerated

Ah so. Good point.

I'll credit them with at least having a unique combination: one round of Whirlpool and one of SHA-256.

Cheers

Graham

“WhirlCoin uses the Whirlpool algorithm, and is the first to do so.”

Categorising this as “nothing new to offer” seems a bit misleading, even arguably wrong by objective standards.

Cheers

Graham

The good news is ... Abe serves the metadata for block 0. The not-so-good news is that it only sees block 0.

Abe has read the blockchain and created a coherent-looking sqlite3 db. I'm working to identify the cause of the problem.

Cheers

Graham

I set up a github org as a “safe house” that would better support common ownership and direction of the resources and intellectual property - https://github.com/qubitcoin-project (feel free to request membership). I made forks of the original qubitcoin github repos and added QubitCoinQ2C which is the 0.8.4.1 version (well, based on an 0.8.3 version of SIFcoin, actually) merged up to the latest in the bitcoin 0.8 series, 0.8.6.

I added a plot of the difficulty to decorate the overview page; something to look at whilst syncing --- but a fishtank screensaver would probably be more effective.

Comme ci:



After a bit more tinkering and some prettification, I'll release PC & OS X binaries.


Cheers

Graham

You would have to write down exactly what you meant by “proof”, showing positive and negative examples, otherwise you're setting up a condition that's impossible to verify.

After you finished, you'd have to do it all over again, this time for “sufficient”.

The list is the OP's purely personal take on altcoins; the criteria are subjective and inconsistently applied. In the absence of a more rigorous attempt to provide definitions, it can only ever be a personal list of dislikes, posted to stimulate some discussion. To attempt to subject it to more exacting requirements would be a mistake, the list is simply not up to the job.

Please don’t mistake my intention: it's a nice list and I’m sure many people also find it instructive but the content is the result of purely personal opinion and cannot be taken to be “proof” of anything.

Starter for 10: produce a definition of "scamcoin" to a standard such that we would both produce the same list if we made our choices independently but strictly according to the definition.

It is an impossible task, so I could've made it “starter for 10 thou” and I'd still be safe. But the take-home message is the old, old saw: “One man’s meat is another’s poison” --- the best working (and, yes, personal) definition of scamcoin that I've managed to come up with so far is: “appeals to those interested in a high risk/reward ratio”. At least it acts to point me to the potentially fruitful area of applying risk assessment techniques to illuminate the playing field better.

Cheers,

Graham


 

1315 “created”, where I could find a logo and an algo - very relaxed criteria, more of a celebration than an analysis. The data is published as Linked Open Data and is downloadable in a variety of formats, from n3 triples to csv.

I've concentrated on facts rather than value judgements, can't make reliable value judgements without a basis of fact, or at least something that behaves like a fact when you lean on it.

I made an effort to record the obvious emergent features: distribution scheme (ipo, pow, poc) versus the protection scheme (pos, pow, pob) and then the variants of PoW scheme - combos such as nist5, qubit, x11, single hash functions, e.g. fugue, groestl, etc.

But it all grinds to a halt when it hits PoS schemes - apparently there aren't any readily-identifiable individual approaches or categories to be articulated. This is likely due to the fact that the only representation is the implementation --- and there lies epistemological trouble.

All that can reliably be said is: "claims to use a PoS scheme". It's not trivial to determine if the code actually functions as such and assessing whether it performs better or worse than an alternative implementation is a formidable technical challenge.

By contrast, consider the labels springing up to describe the various difficulty re-targeting algorithms: KGW, DGWv2, DigiShield.

PoW has labels, difficulty retargeting has labels, there are labels to apply to coin generation approaches, e.g. “an inflationary version”.

I'm now keenly interested in discovering why PoS schemes are apparently so intractable to classification.

Cheers

Graham

Go on, spoil yourselves; glory in the exuberance, high and low art

All the coinz

Have fun.


Cheers,

Graham

That'll be because up until now, Qubitcoin has been the only altcoin to use the qubit algo exclusively --- some of the myriads offer qubit as part of their repertoire.

If you're looking for off-the-beaten-track combos, other near neighbours are the two new “nist5” coins, Icebergcoin and Talkcoin, they use the same direct chaining combination H0(H1(H3(H4(H5))))) as qubit but they use a different set of 5 NIST candidates: (BLAKE - Grøstl - JH - Keccak - Skein) instead of qubit's (Luffa - CubeHash - SHAvite - SIMD - Echo).

I've no comment to make on any of the other qualities of these two altcoins, this is merely an objective description of the hash fns in the combo.

Cheers,

Graham

Edit: corrected reference

The bitcoinunits.cpp source still reads "ChC"

Whilst I'd be really pleased to see trading symbols using the full range of unicode, I suspect that the exchange operators will be uninterested.

So, the coin unit string needs to be changed to CHCO as in the OP because CHC is comprehensively pre-used, (I have extensive metadata) - a query on CHC for symbol returns:

name	symbol	incept
"Chaincoin"	"CHC"	"2014-01"
"CHC coin"	"CHC"	"2014-05"
"Helveticacoin"	"CHC"	"2014-05"

Cheers,

Graham

I'm surely not the only person to note the June 27th. launch of a Qubit-algo coin?

Deepcoin - https://bitcointalk.org/index.php?topic=667470.0


Name : Deepcoin
Ticker : DCN
Algorithm : Qubit
Total coins : 99 000 000
Premine : 0 %
Block time : 1 Minute


Cheers,

Graham

That would be an ecumenical matter.

Qubitcoin is listed on Poloniex, blocks are being chained, the network's seeing the same modest but persistent hashrate as is typical with mature altcoins, there's a handful of persistent nodes. To my untutored eye, the depth chart on Poloniex suggests that the price could be quite labile at this level.

I'd say Qubitcoin is “as well as can be expected” for an altcoin that’s deep into the halving sequence, has an absent dev and isn't operating to any particular plan.

There appears to be a hard core of persistent residual belief in the validity of the notion of a “technical altcoin”, even if no-one’s quite sure what that actually is, just that Qubitcoin is one.

It's not that Qubitcoin is especially neglected as an altcoin, there're loads of others just bumbling along with a community that is basically not overly dissatisfied with the situation and not seeming to experience any pressing urge to change things in case it upsets the applecart mainly because no-one's quite sure why the situation pertains as it does so no-one's quite sure how to proceed and doing nothing seems to be a course that puts assets at least immediate risk.

But then someone comes along and asks “Is this coin dead?” My response is “Define ‘dead’ and maybe I can give you an answer.” But that’s a bit of a cheat, I know you can’t provide a definition of “dead” (it’s ostensive), so I can’t give you the answer you seek, other than to point to a collection of instances and suggest you develop your own notion, then come back and ask a more focussed version of the question.

Qubitcoin hodlers might recognise my userid from earlier posts and recall that I've been maintaining a “plan B” repository; part backup, part sandpit.

It's what I use to try out experiments, such as using a chain of the 256bit versions of the hash functions --- instead of a chain of 512bit versions of those hash functions and then throwing away half of the hash before returning.

The Merckle tree implementation in the Bitcoin reference client is coded to use uint256 so the uint512 returned by a SHA3-512 hashfn has to be trimmed to fit -- in effect throwing away some (but, importantly, not all) of the advantages accruing from the use of NIST candidates. Some of the NIST candidate hash functions are faster in 512 than in 256, nearly all candidate SHA3-512s are faster than SHA2-256, so most of the speed advantage is retained, almost no matter which NIST candidates are chosen.

I idly questioned: is there a more felicitous selection of 5 NIST hashfns that brings maximum speed for a pure 256 solution and how does that compare with a truncated 512 solution?

A visit to the SHA-3 Zoo and a tour of the pertinent NIST candidates brings up the documentation that accompanies the reference implementation, optimisations, etc. that each candidate is obliged to make available in an associated submission zipfile, e.g. http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/documents/Lesamnta.zip. I happily collected the lot. (Sorry but this is what’s typically entailed if we’re to treat the term “technical” with any degree of seriousness).

The other piece of Qubitcoin work I'm pursuing is a re-release of the original codebase as a full fork of the bitcoin codebase that was used for the original history-less commit.

This technique re-inserts the particular altcoin codebase back into the commit history as branch of the official repos so it can assume the full benefits of its heritage. I've done this for Mooncoin, paving the way for a simple iterated merge of the developments of the upstream version tree, right up to the latest master.

To keep you all in the loop, Zeljko and I are carrying on a “what do we do now to secure the immediate future of the coin” discussion which involves ugly topics such as Q2C2fiat points - DNSSeed nodes must be hosted: hosting == fiat, Q2C won't cut it.

Just so's that visitors don’t get the wrong impression about Qubitcoin's vitality, I'll set up an alternate github org project, qubitcoin-project (same as I've done for Mooncoin) which you're all welcome to sign up to. I'll ensure that everyone knows where the spare keys are kept and we'll work out some arrangement for community ownership of the IP of the various properties involved (official web site, block explorer, DNSSeed nodes, official p2pool, whatever).



Cheers

Graham

I think we may be at cross-purposes here.

I thought I saw a mistaken perception emerging that the repository contained a “new Republicoin”.

I wanted to make it crystal clear that a “Full fork of Bitcoin 0.8.6, branding and parameters separated out as per obvious.” is exactly the same code as the original, except with the prior commit history intact.

There's nothing “new” about the coin at all. I set up a new repository, holding the old code.

Claro?

Cheers,

Graham

Just for the record - it's exactly the same code as the original, the only difference is that the repository is a “full fork” and the prior commit history is intact.  This will allow RepublicCoin to benefit properly from its heritage via the controlled integration of upstream improvements in the bitcoin codebase.

Cheers,

Graham