I was not really aware that I had 'announced' anything as such, rather I posed some questions to the community with a possible upgrade schedule.
'My bad' and apologies for any confusion or panic caused.
However, when an alpha Release Candidate is available for download, people often take it as read that they can safely 'upgrade', which is clearly not the case.
I did not add the windows alpha Release Candidate to
https://gapcoin.clubThe new core repository is made available as a link, in the hopes of attracting additional developers to assist Graham ...
[ ...]
We have a Gapcoin testnet.
-
https://bitcointalksearch.org/topic/m.55546099Please don't rush to 'upgrade' on mainnet, before any 'official' release announcements are made.
Graham is continuing to do sterling work in regards to development and I hope others will become more involved with helping as we progress.
Not a 'bad' as such and absolutely no need to apologise (you are doing a sterling job acting as the mainstay of this community project) - it's just that I'm trying to be acutely aware of the general group perception - whilst the chain consensus is fixed by proven code, the community consensus is highly sensitive to changes in sentiment.
If you’ll (all) bear with me, I will take you on a leisurely trip which I believe is necessary if you want to understand the full significance of the destination - which is:
“Gapcoin 0.16.3 is milled from a Minkiz Foundry template, so that’s the version that can and should be released as the one endorsed by the community.” There’s some groundwork I need to lay in order for me to feel comfortable that people actually understand what that means ....
I'll freely confess to not viewing myself as a C++ developer - at least not according to
my standards. I'm a cognitive psychologist by discipline and a cognitive scientist by profession, over my 30-year career in tech, I have acquired some familarity with the tools of computational modelling - in my time, I've coded in COBOL, Z80 assembler, BASIC, Pascal, LISP, POP11, Prolog, Smalltalk, Python and lately C++, not to mention acquiring familarity with the markup languages such as HTML, XSL, XSL, RDF, etc. More importantly, along the way, I've acquired some limited degree of skill in software engineering generally which gives me quite a good grounding for curating altcoin codebases in the (permanent) absence of the original developer.
The basic codebase of the current Gapcoin 0.16 client is derived from a piece of personal (and private) work that I've been pursuing over the last five years. Back in 2014, there was slew of trivial altcoin clones of Bitcoin, differing little from the cloneparent other than in the choice of hash algorithm and I created a piece of online “art” (Minkiz’s Foundry) which (I felt) made some wry commentary on the trend. It’s still up there, unchanged from 2014.
The (allegedly wry) commentary lies in the tongue-in-cheek ebullient description of the (total of 24) hashing algorithms, here’s a pageshot of the first half-dozen, the entirety
are still available to view.
Perhaps understandably, the contents of the page linked to from the
“Try/Buy” button confused some people, although it might
look like a shitcoin generator, it’s non-functioning.
Minkiz Foundry is an extension of the idea behind my original investigation - can altcoin clones be successfully characterised by their differences from the Bitcoin cloneparent? This was (for me, at least) a natural outgrowth of the altcoin classification work I had done in DOACC (
Description of A CryptoCurrency), a semantic web project¹
The
DOACC ontology provides a means of describing the metadata of an altcoin.
Between 2014 and 2017 I spent quite some time collecting and collating
the metadata of around 3500 altcoins of the time, here's an example (rendered in N3):
doacc:D002ce66d-0f79-4bcb-8725-ff14cea1dd85 a doacc:Cryptocurrency,
doacc:Repository ;
rdfs:label "Devcoin"^^xsd:string ;
dc:title "Devcoin"@en ;
doacc:block-reward "5000"^^xsd:string ;
doacc:block-time 600 ;
doacc:comment "established"^^xsd:string ;
doacc:date-founded "2013-08-01"^^xsd:date ;
doacc:expiration "listed"^^xsd:string ;
doacc:image "devcoin_dvc.png"^^xsd:anyURI ;
doacc:incept "2013-08"^^xsd:string ;
doacc:pow doacc:D0441786b-85a1-45a6-a50d-1a9b80ec7b94 ;
doacc:protection-scheme doacc:D451a49d8-c9e7-46e5-8b8d-bcbe16f75c24 ;
doacc:protocol doacc:Db8ade99f-11f1-476b-ae77-03c005c1bb66 ;
doacc:source "https://github.com/Unthinkingbit/charity/blob/master/bitcoinshare.html"^^xsd:anyURI ;
doacc:symbol "DVC"^^xsd:string ;
doacc:total-coins "21000000000"^^xsd:string ;
doacc:website "http://devcoin.org/"^^xsd:anyURI ;
rdfs:comment "SHA-256 based crypto-currency with re-target every 1 day, 50K coins per block, and 21 billion total coins.
Merge-mined with BTC, 90% of generation goes to foundation, 10% to miners Dev Coin - Devcoin Abbreviation: DVC
Algorithm: SHA-256 Date Founded: 8/1/2013 Total Coins: No Limit Confirm Per Transaction: Re-Target Time: Block Time: 10 Minutes
Block Reward: 5,000 Coins Diff Adjustment 2,016 Blocks Website Thread Source up0 users have voted."^^xsd:string ;
skos:prefLabel "Devcoin"@en .
The description is cross-referential - the PoW scheme for Devcoin is
D0441786b-85a1-45a6-a50d-1a9b80ec7b94 which resolves to:
doacc:D0441786b-85a1-45a6-a50d-1a9b80ec7b94 a doacc:PoWscheme ;
rdfs:label "SHA2-256"@en ;
dc:description "NIST SHA2, 2001"@en ;
rdfs:isDefinedBy ;
skos:prefLabel "SHA2-256"@en .
(I use RDF for its sheer representational power, it's appropriate for this task).
And, with the vast majority of altcoins having a Github source to peruse programmatically, I was able to build tables showing the various features of altcoins - here it shows the cloneparent, its version, the (supposed to be unique to the coin²) “magic bytes” and the feature set:
However, behind the scenes, for my private amusement/edification and inaccessible to the public, the actual joke is that Minkiz Foundry
does actually work, it successfully mills full-functioning altcoin clones i.e. includes the creation of the genesis block and the in-wallet miner is capable of generating mainnet blocks.
I've been tracking the Bitcoin cloneparent upgrades and Minkiz Foundry is now milling clones of Bitcoin 0.20. Over time, I've refined the set of choices of hash algorithm, replacing some outdated or less-interesting variants with implementations of more powerful or more interesting modern hash algos --- a handful of NIST first-round candidates that remain secure but never made it the NIST 2nd round and so never had
an ASIC implementation (“In the final round of the competition, there were three complete ASIC implementations of the 256-bit versions of all five finalists”), MD6 (withdrawn by Ron Rivest from the NIST SHA-3 competition but later proven robust against differential cryptanalysis), Rainforest, City (Google’s own) and some algos approved by other-nation NIST equivalents such as the Chinese SM3 and the Russian GOST-Streebog ... (I hope you’ll forgive me for including the full pageshot, I just happened to have one on imgur):
By way of illustration, here's a screenshot of a recent milling of Boat, a couple of nodes mining on a local mainnet:
I’d like to stress the importance of how
close many algo-variant altcoins are to the Bitcoin cloneparent. My approach is to replace all the user-facing coin-specific “Bitcoin” strings (and their case variations) with a Jinja2 template expression:
{{coinname}},
{{coinlcname}}, etc. I do the same for all of the other coin-specific variations (e.g.
{{mainnetport}}) - it's a process that takes a couple of hours. The end result is a Minkiz Foundry template that is amenable to template-engine replacement (courtesy of Python and the Jinja2 templating engine) of all the relevant variations with coin-specific values maintained in a Python dictionary of just a couple of hundred items (of which a good half are merely testnet/regtest values).
Where altcoins vary more substantially from the cloneparent than just in hash algo (e.g. Namecoin, Peercoin, Datacoin, any altcoin with masternodes), my approach is to create a branch variant and apply the same template approach to the variant. For example,
the 0.16.3 version of Datacoin is milled from a Minkiz Foundry branch-variant template.
(It's quite a high-power approach. A few months ago one of the Datacoin folks asked me how difficult it would be to add PoS to Datacoin. In just a few hours I was able to blend the Peercoin branch variant with the Datacoin branch variant and produce a version of Peercoin augmented with Datacoin’s per-transaction data storage and fee structure.)To be honest, maintaining the branch-variants isn’t all
that taxing, thanks to the excellent software engineering tools now available. I use
meld to assist me with maintaining the branch variants as well as identifying the necessary variations. Here’s an example of just how limited the difference is in block structure for a Primecoin-clone such as Datacoin that needs to extend the block structure in order to carry PoW-relevant data about the specific prime chain and its length at that point in the chain:
Gapcoin is a similar branch variant. It’s the same as Bitcoin except that it uses a prime gap search PoW algo instead of a hash algo - it’s quite similar to Primecoin in that the block structure is extended to carry key information about the primes in order to facilitate the PoW calculation and ultimate rendering as a hash:
So, finally, you have the semantics to ground your understanding of what I mean when I write “Gapcoin 0.16.3 is milled from a Minkiz Foundry template”. It's not a trivial statement, there’s a lot of solid work to underpin it.
As regards the reliability of the Gapcoin 0.16.3 client ... the version in my own Github repos has inherited a bit too much from the Minkiz Foundry template. It’s alright for me to muck about in private, trialling code that I believe enhances the appeal to users because I'm not intending to use it in anger. So it’s not really all that surprising that I’ll miss a trick now and again. The reason I made the comment about being caught off-guard was simply to communicate that this wasn’t a random bug but the result of a specific, identifiable - and addressable cause which is highly unlikely to be repeated.
Ideally, I’d prefer that all of the tests in the Gapcoin
unit test suite passed. Unfortunately, quite a lot of the Bitcoin test suite is specific to Bitcoin and amongst the coindevs of my acquaintance, getting the tests to pass is a known PITA. Many’s the time I’ve eagerly examined the test suite of a altcoin newly-launched by a strong dev/team only to discover that the tests I was interested in knowing how to get working had simply been removed.
Let’s face it, the closer the Gapcoin codebase is to a contemporary Bitcoin cloneparent, the more confident we can be in its reliability and robustness. The qualifying term “contemporary” is rather important here - just check the
Bitcoin CVE list from CVE-2015-3641 onwards - you will note that they all apply to the 0.9 client. (And in case you were wondering, the Gapcoin 0.16.3 client is the patched version and is
not vulnerable to the
recently-identified invdos attack.)
Usually, problems only originate when devs make changes to the code without overwhelmingly good reasons. I recently identified this
commit to the Verge codebase as the likely cause of the recent
long range hack in which more than six months worth of transactions and balances vanished from the Verge blockchain. This conjecture was
confirmed by zawy12. (The “coindevs of my acquaintance” that I mentioned earlier are subscribers to the invite-only “CryptoDevs” Discord server of which I’m privileged to be an invited member - there are many highly-skilled and knowledgable subscribers, including zawy12 and some very well-known altcoin devs).
Please bear in mind here that I'm addressing what I perceive to be a community consensus, my perceptions may well not match the reality but unfortunately, there’s no way to find that out.
As regards the 0.16.3 client, I think that for the moment, the best course of action is for me to provide, in the Gapcoin-project repos, a “vanilla” Gapcoin 0.16.3 client, stripped of (nearly all) the extravagant additions of the client in my own Github repos. I write “nearly all” because I imagine the consensus would prefer to retain the in-wallet miner (removed from the Bitcoin codebase back in 0.13 and restored by me for Minkiz Foundry purposes) but not the GUI mining page (use
setgenerate or the external, more readily configured, GapMiner), nor the chart of hash/difficulty on the overview page, nor the GUI block explorer (use
getblock), nor the list of prime gaps (use
listprimerecords), nor the multisig GUI (use
addmultisigaddress), nor the make/showkeypair RPC/API calls, nor the other RPC/API calls that I haven’t mentioned such as
dumptriples,
renderblockhash and
nicely - and the
embellishment of "About Gapcoin".
Please don’t mistake this for a fit of pique, it’s just being realistic about the (rather remote) chance of BitcoinFX managing to persuade someone else to work on the codebase. No-one will want to maintain all the frippery that I have added but a barebones clone with essential coin-specific changes would be a different matter.
And that position is quite readily attainable by milling a basic Minkiz Foundry 0,16.3 variant-branch template. It doesn’t mean that I will delete my Gapcoin repos, far from it, it just increases the likelihood of other people contributing to the mainstream Gaocoin codebase
I'm likely to make available a couple of versions of the enhanced Gapcoin client, a “GT” version with the GUI additions and a "de luxe" version with all the features I addded. As people begin to develop a more extensive model of the Gacoin 0.16.3 codebase, they may well come to appreciate the reliability of the basic codebase and understand that the additions are non-intrusive to the basic functioning of the client.
And, now that I've exposed the back-end workings of the Minkiz Foundry, the existence of a Gapcoin 0.20 client should be less of a surprise ... to give you a hint, here's a screenshot of the Ferrari 0.20 mining page that you might find a little familar:
It may be that not all the additions will get migrated to the 0.20+ codebase (I'll be working on the Minkiz Foundry 0.21 template sometime in the not-too-distant future). In particular 0.20 has seen an extensive rewrite of the network processing code and I ran into some as-yet-unresolved issues when porting over the DANDELION code and I've been informed by one of my coindev colleagues that with 0.20 the wallet code has been strongly modularised (i.e. more self-contained) and correspondingly is a lot more challenging to integrate with the miner. However, on balance, it’s far more important to retain upgrade compatibility with the strongly-developed upstream code (i.e. Bitcoin) and gain the benefit of improved reliablility, transaction security (anticipating stuff like
Schnorr signature aggregation, etc) and all the other benefits accruing from the strength of the Bitcoin developers.
Ultimately, while I will freely confess that I'm not a C++ developer according to my standards, it doesn't mean that I harbour any deep misconceptions about the strength and depth of my technical skillset. From the above you may have formed (the intended) impression that I am highly accomplished and operate at a very high standard. At this level, one doesn’t find people needing to cope with feelings of inferiority by over-extolling their own skills, rather the reverse. People who work at really high-levels of accomplishment are readily characterised by what might appear to the uninitiated as excessive modesty and over-respect for other professionals. It's a bit of a tell-tale as it’s a useful kind of idiot filter; in general, anyone who doesn’t understand the origin of the modesty and reciprocate the respect is, in effect, signalling their relative inferiority on the technical scale of things.
If you’ve followed this leisurely journey all the way to here, then I salute you --- and I thank you, I have been able to communicate a lot of information about the Gapcoin codebase in a way that would be impossible without your understanding of the background and how the Gapcoin 0.16.3 client came to be.
Cheers
Graham
¹ pursuing cognitive science as a profession quickly gets one into “classical” AI, an area I worked in during the late 80s/early 90s in R&D as an HPLabs engineer (back when HP Labs was one of the FAANGs of the time) hence my interest in the semantic web, which is where many classical AI folks are now to be found (notably, e.g.
Pat Hayes).
² A change to the message-identifying “magic bytes” from their Bitcoin-specific values is something of a signifier of an altcoin cloned by a capable and experienced developer. Many script-kiddie altcoin devs were ignorant of the implications of failing to follow this strong recommendation.
