Don't need either. One other insight I can bring: people don't scale, they form clumps. There's plenty of compositional material (people online) and so there's more than one collective intelligence around, (even if it's only oddballs like me that categorise them as such). So they form groups of collective intelligences with shared meta-collective models.Sound a bit esoteric? Not at all, here's an example: "What do Deepcoiners think about the Shibes?" Same thing, just without the meta-level jargon. But it's at the meta-level where the insights start to pay off. Ascend a level of abstraction or two and you get to view an "altcoin community" as yet another fancy label for "online special interest group" and suddenly, theres a whole raft of practical advice gained from long experience, a hefty corpus of empirical work on the topic and an entertaining set of fanciful theories about the interrelationship between the individual and the group with a catalytic dose of awkard questions surrounding identity and its construction in the modern "post-truth" abstraction that we call "the world". And, the killer is ... YMMV.

I'm brown-bagging again with even more earnest pleas for forgiveness if you don't find the first section relevant to Deepcoin (although that may not be entirely my fault).

---

I haven't yet solved the problem of getting the updated Core 0.16 Deepcoin client to successfully neogtiate the algo changeover and re-set the difficulty modifier but it's "just" a matter of me improving my understanding of the problem. atm, I'm forced to conclude that I'm holding it wrong.

Cheers

Graham

That's encouraging - and not just from a personal perspective but objectively. With apologies for brown-bagging, I'll include a previous post I made today on the Clams thread (hopefully save you a couple of clicks) ...

---

You might consider the general orientation inferrable from my declared interests as forming the material on which to base the preface of a treatise that I'm not going to actually write down (just have fully articulated in my mental model) which could plausibly be titled: "Understanding the why of Dogecoin's continued success."

Cheers

Graham

I see what you inadvertently did there, you introduced a magical "relevance" gatekeeper module. So you're not envisaging a decentralised solution and believe the future of science publishing lies in corporate-controlled permissioned chains? Or "databases" as they are also known.

Otherwise, if you can drop the "relevance" qualifier, find someone prepared to foot the biil for all that storage, then Bob's your free-for-all, must-publish-any-old-dross-or-lose-my-tenure uncle.

Cheers

Graham

Not on current evidence, no.

The "technical aspects" are the only aspects of an altcoin clone that are objectively (or near offer) available to investors for informing their assessessment of the potential ROI.

However, to use the term "investment" in the context of swapping tokens of a clone of Bitcoin for bankable fiat is stretching the semantics of the term well beyond its breaking point. If the reality of the context were to be honestly acknowledged, then a far more accurately descriptive term would be "speculation".

(for Google translate: use your common sense, it's not "investment" but "speculation")

There is no point in trying to discuss psychological matters (such as "appeal") on bitcointalk but I have rounded up some of my observations in a single post a different perspective on cryptocurrency.

For background, I'm a cognitive scientist currently engaged in investigating the informational requirements of the typical tasks performed by an online collective intelligence and, for me, the technical aspects are more pertinently addressed elsewhere, including for example the psychology of money and the empirical work (open access) done by Kathleen Vohs and collaborators, for one:

"No Match for Money: Even in Intimate Relationships and Collectivistic Cultures, Reminders of Money Weaken Sociomoral Responses,"
"Money Cues Increase Agency and Decrease Prosociality Among Children: Early Signs of Market-Mode Behaviors,"
"Money Priming Can Change People’s Thoughts, Feelings, Motivations, and Behaviors: An Update on 10 Years of Experiments," <- that's a decade

and Elinor Ostrom for another.

(Coincidentally, this reference The Future of Management Is Teal turned up on HackerNews a few days ago, if you're interested in Teal in a broader context).

Cheers

Graham

You'll need to pry it from my cold, dead, hands.  I dunno if you recall but a while ago I mentioned that in the interests of testing client performance on mainnet, I took the opportunity to grab a large buncha coins off've an exchange to create a wallet sufficiently adequately-funded to put stress on the client. Before iguanadon1's optimisation, it ran 100% of its thread, 100% of the time and the GUI response was even slower than glacial, tectonic even. Inarguably unusable.

Since switching to iguandaon1's optimisation of the staking, that same wallet is now occupying around 35-40% of its thread, frequently rising to 100% but briefly and then settling back down - so overall performance is very acceptable, even with the client showing 25,245 transactions. GUI response is occasionally interrupted for several seconds but essentially the GUI remains usable. This is under stress conditions. When running with a few tens/hundreds of transactions the GUI responds with its normal promptness.

I'm getting a steady daily stream of stake rewards, interspersed with the occasional burn reward and all conveniently accessible in a single wallet so ... cold, dead, hands.

Anyone else noticing the marked improvement in performance shown by the iguanodon1 client?

Cheers

Graham

Cloudflare spotting an opportunity: https://www.theregister.co.uk/2018/09/18/cloudflare_backs_interplanetary_file_system_with_gateway/

Now, in addition to using the Slimcoin blockchain to inscribe indelible torrenthashes as indexes to published content, the same applies to ipfshash  - the latter at the cost of using (atm) a single, centralised service.

Cheers

Graham

port is for the main consensus protocol, i.e. passing around of headers, txs, etc. all the busywork needed to maintain consensus.

rpcport (Remote Procedure Call) is a means of issuing commands such as getinfo and sendto to a running client.

If I want to cross-connect two clients:
bitcoind -port=12000 -rpcport=12001 -datadir=/tmp/datadir1 -connect=127.0.0.1:13000

bitcoind -port=13000 -rpcport=13001 -datadir=/tmp/datadir2 -connect=127.0.0.1:12000

rpc calls to the first client need to go to 127.0.0.1:12001 and those to the second client need to go to 127.0.0.1:13001

AIUI, the miner uses the rpcport to issue getwork (or getemplate or whatever) commands and uses the port to submit its candidate blocks to the consensus protocol -- which is why it needs the values for both port and rpcport.

(Were the Bitcoin dev team not self-avowedly "primarily systems engineers", then port might have been more self-evidently labelled as "protocolport")

HTH

Cheers

Graham

I see the idea is catching on, as torrentfreak reports ..

OpenPGP Keyservers Now Store ‘Irremovable’ Torrent Magnet Links

Cheers

Graham

Any chance of posting it somewhere less intrusive?

Cheers

Graham

These things bears close reading before taking the time to respond. Its anodyne nature reveals it to be machine-fabricated for the purpose of account farming (an inference supported by the poster's history). It's as devoid of specific semantics as a corporate mission statement. Mechanically-augmented social exploitation is with us here and now.

Graham's dictum: A Turing test is best performed offline and face-to-face.

Cheers

Graham

There never has been "a dev" engaged in the project as such, at least not in the usual type of "resident dev/team" model that most altcoins follow. It might help if you think of deepcoinbiz as the equivalent of a movie producer - organises funding, logistsics and ad hoc commissions of specialists to perform specialised tasks as and when needed.

As far as I can make out, deepcoinbiz commissioned Peter Bushnell (https://github.com/Bushstar) to create the clone (https://github.com/Deepcoinbiz/Deepcoin/commit/66ef7fefe8da3cbebf0e7e48486877b2e45c5773) and do further development work, including implementing a change in algo (https://github.com/Deepcoinbiz/Deepcoin/commit/0b8c28067c210e5c54bb48b264f70c8739fc7d9e) and and subsequent revisions (https://github.com/Deepcoinbiz/Deepcoin/commit/1a926a7e7c41cfc01f60d3a3c7791c7316effe11). There's also a nearly-complete "stealth addresses" branch (https://github.com/Deepcoinbiz/Deepcoin/commits/new-sx-0.8.7).

I don't find it profitable to speculate about this past phase of development, I'm interested only in its impact on the here and now. I believe Peter is open to commissions but that doesn't offer a resolution to the question "we need dev?" That answer to that question lies in uncovering the group's collective understanding of the role fulfilled by "the dev".

I'm afraid that I'm prone to asking "difficult" questions such as "Exactly how much dicking about with the Bitcoin codebase do you think is actually needed to support your clone?" Okay, Dash's masternode system is complex enough to require a resident dev/team but it's a far less compelling argument when the clone is almost identical except for the algo and the emissions/reward schedule.

Hence: https://github.com/gjhiggins/deepcoincore, a work-in-progress of transplanting the Deepcoin-specific elements into a Core 0.16 codebase. The rebranding is trivial, the actual first step in the process of discovering the reality behind "well, just how hard can it be?" is to replicate the genesis block and then read the blockchain. I'm halfway at the moment. The genesis block is correctly replicated and the Core 0.16 client reads the blockchain up to the hard fork at 76800. Then there's a sequence of 10 blocks for which the difficulty is calculated differently in order to prime the backwards-looking NiteGravityWell difficulty modifier. And that's not happening, which is what I am currently investigating.

So, if you fancy a play, check out the sources - careful to git checkout deepcoin and compile it up. To generate yourself a readable bootstrap.dat of blocks 0-76800, apply the following changes to the current client's contrib/linearize/example-linearize.cfg to get yourself a linearize.cfg to use.

Then run ./linearize.py linearize.cfg, copy the resulting bootstrap.dat to the datadir of your choice and fire up the client. Wait while it reads the bootstrap then clean out the datadir and try it again with a bootstrap.dat of 0-76801. Check the debug log for the rejected, out-of-order block. That's where I'm at.

I'll post notes on further progress as and when I manage to make any, assuming no-one else figures it out in the interim.

As far as I'm concerned, the answer to "Exactly how much dicking about with the Bitcoin codebase do you think is actually needed to support your clone?" is ... "As little as possible."

I'll throw this is in, in case I haven't mentioned it before: A different perspective on cryptocurrency, with the challenge - if I do manage to upgrade Deepcoin to Core 0.16 - what comes after that?

Cheers

Graham

Not that I know of. If you track upstream a ways, you'll find sporadic posts on the topic by BitcoinNational. As for your last question, I'm not sure why you asked, it's an unanswerable question.

Cheers

Graham

?? Where are you seeing that? Do you have a pointer - and are you sure you have the right altcoin?

The original VCoin release and immediate abandonment: https://github.com/vcoindev/vcoin

The rescue (courtesy of @chrisvl) is here: https://github.com/vcoin-project/vcoin

Some time ago I reconnected the VCoin clone back to its Zetacoin cloneparent, recovering the entire Zetacoin and (importantly) Bitcoin commit history: https://github.com/vcoin-project/vcoin0.8zeta-dev and used that to leverage some extensive merging from Bitcoin, to bring the coin up through the various successive versions. Anyone still using the client atm is likely to to be using the interim Core 0.9 version but in the relative quietude of this unimportant spiral arm of the altcoin galaxy, I've working on the Core 0.16 version, taking a radically different approach.

One problematic issue is that as a name, "VCoin" was a complete non-starter in the first place. Rumour has it that the OP was JP and must have failed to do basic desk research on the name because a SE Asian company called VCoin were already operating in the fintech/cryptocurrency space - which is probably why the coin was so quickly abandoned. VCoin remains a non-starter as a name because the namespace is so crowded (e.g. https://app.vcoinexchange.com/).

Contempating this issue, I noted that the prevalence of the naming scheme (*)coin was becoming a fairly reliable defining characteristic of vapid "meetoo" clones (incl. VCoin, tbh). I also noted the fact that over 4000 altcoins had been launched and as far as I could see, none had much of a distinctive collective "persona", let alone one with a persona solidly grounded in the online SIG that animates the blockchain. As far as I could make out, it's wall-to-wall pretend SV startups, complete with scale model CTO/dev or a pretend C-Suite "core team" (or other such absurd imports from tightly-centralised organisational models) and scale model ambitions to match.

As VCoin remained just one more "meeeetoooo" altcoin extra in a cast of thousands, then its undisturbed trajectory has been an eminently predictable high-value-start-followed-by-gradual-decline-into-obscurity hockey stick typical of the vast majority of alts - such Ziftrcoin https://coinmarketcap.com/currencies/ziftrcoin/ and Quotient https://coinmarketcap.com/currencies/quotient/ - to pick out two examples at random. although the latter is currently in Yobit zombiecoin mode by which I mean that, according to the takeover ANN, its continued existence is apparently justified solely by the fact it can be traded on Yobit: “We have Officially taken over XQN, it can be traded on Yobit.” (https://bitcointalk.org/index.php?topic=1766310.0)

Yes, VCoin is listed on Yobit https://yobit.net/en/trade/VCOIN/BTC so in the context of the trading of electronic tokens, it too is a Yobit zombiecoin, the coininfo section references the original abandoned GH repos and yes, coinmarketcap lists it as "inactive" - probably correctly according to their limited criteria.

I'm very comfortable with this situation. VCoin as a name is unviable for an alt and Yobit is widely reputed to be unresponsive (but I haven't checked), so that's their problem if they miss the upcoming hard fork.

So, if not "VCoin" then what?

I'm a pragmatist and decided to just drop the problematic bit: "Coin" ... welcome to V.

Admittedly, the down side could be argued that online search will be an absolute bitch but on the up side: it confers immunity from index engine bullying, eliminates domain name squabbles and renders imposter domains pointless.

Right now, no peer-to-peer networked cryptocurrency can be a legally-recognised entity, i.e. it is constitutionally unable to own IP. In consequence, it would be futile to choose a name that could have IP value because as far as IP is concerned, decentralised communities are defenceless against even casual appropriation of IP by a legally-recognised entity. Contrariwise, V is easy to remember, works across cultures and occupies a namespace that is legislatively forbidden to all effective legally-recognised entities.

Without going into reams of tedious detail, the rest of V's approach is similarly iconoclastic. V recognises the social profundity of TANSTAFFL, borrows heavily from E. E. van Vogt's auctorial evocation of Nexialism, leans hard in the direction of Harry Harrison's wirr and, as a peer-to-peer networked cryptocurrency, is a pure Teal organisation, free of the crippling centralising distortions introduced into Holacracy, for example. V is an instance of Wooley's c, the collective version of Spearman's g (c.f. “Evidence for a Collective Intelligence Factor in the Performance of Human Groups” http://science.sciencemag.org/content/330/6004/686) and one of the current reseach topics is the elicitation of user task requirements where the user is an empowered collective intelligence.

For a flavour of the group ethos, see A different perspective on cryptocurrency. BTW, that is a temporary home, pending the construction and inscription of a TrustyURI (spec: https://github.com/trustyuri/trustyuri-spec, Python implementation using RDFLib: https://github.com/trustyuri/trustyuri-python) on the V blockchain.

I apologise to those in the loop who have been patiently waiting for some actual progress. The preparatory work is very nearly complete (see branches various in https://github.com/gjhiggins/vcoincore) and, after an overly-long period of auto-didactisim, I am now more confident that the groundwork is sufficiently comprehensive and detailed to enable V to follow a very different trajectory.

tl;dr no lucrative "investment" opportunities, no lucrative centralised mining consortia because the emission schedule is complete and block reward is 1 now VCN (algo is bog-standard Bitcoin SHA2-256D). In essence, there's nothing to interest the usual altcoiner here - and we sort of keep it that way by design because different requirements apply in order to be free of the distorting influence of such agencies during the establishment of a strongly pro-social group identity, a necessary but not sufficient condition for the development of more powerful expressions of c ... (Hint: “Finally, c was significantly correlated with the proportion of females in the group, with groups having more females being more collectively intelligent.”)


Cheers

Graham

The last mention of this was a long way up-thread but basically, development proceeds according to funding. I don't know the current state of either, tbh - but if development is on hold, it may be that the funding has dried up.

Cheers

Graham

Out of sheer curiosity, I let clamd sync from 0 on my XPS laptop. Took a couple of days and one restart but it synced up satisfactorily, giving me a clean, orphan-free blockchain.

AIUI, the standard linearizehashes and dumpbootstrap chain admin facilities won't work out of the box for Clams because the block parser in dumpbootstrap is written for PoW, not PoS and must be adapted to parse Clam blocks in order to function.

Cheers

Graham

I can't see it being anything other than Cryptopia's call, however the launch/PoW-PoS transition goes - aiui, they're in the loop but dont' feel any pressure to be specific about time periods.

Cheers

Graham

Ah, one of the legion of latterday flamebaiters, a fine tradition but you're a poor exponent. You're not going to get any jollies winding up people here, you might as well sling your hook and see if you can get satisfaction from indulging your attention craving disorder in another thread.

Cheers,

Graham

It's merged into the develop branch code, so when you check that out, you'll have a chance to check out the functioning of iguanadon1's code (which seems to be working just fine for me).

Cheers

Graham

Some occasional contributions ...

I came across a coherent commit for adding coincontrol to a peercoin fork (I've mislaid the pointer) which I thought seemed a likely proposition, so I had a go at applying the commits (aka "cherrypicking") to the Slimcoin codebase. It was an unexpectedly good fit (it's not the first time I've had a go at adding coincontrol to the Slimcoin wallet, so I found the exercise instructive in that respect) and it appears to function as expected, although please note, I've not yet actually tried using it but it does sanely report my UTXO set.


The presence of the "custom change address" option may be cause for cautious optimism that this change might help resolve the exchange's issues with the API. I haven't done any testing so expectations should be contained for now.  

In pursuit of getting a clean (i.e. orphanless) and more tractable mapping of the blockchain to RDF, I added a couple of chain admin utilities, linearizehashes and dumpbootstrap, producing respectively, a file of linearized (i.e. orphanless) hashes and a file of linearized (i.e. orphanless) blocks in sequence. As part of the same exercise, I added some wallet maintenance facilities - checkwallet, repairwallet and zapwallettxes. This is the RPC-API view:




and this is the GUI view:


Be warned, it is untested. However it did repair (a copy of) my wallet, OTOH, I suspect zapwallettxes is actually zapwallet, 'cos that's what it seemed to do to (a copy of) my wallet but I could be mistaken, it seemed to work okay the second time (and the advice is correct, it is a slow process - many hours to rescan 1.4-odd million blocks ) ... and anyway, I need to take another, closer look at the db calls, just out of principle.


Not at all coincidentally and with barrystyle's guidance, I managed to complete the forensic analysis of the Slimcoin genesis block and, with the assistance of dumpbootstrap, was able to extend the analysis to include all of the (linearized) blockchain. The end result is a kind of generalised access utility for reading blocks out of the blockchain and processing them. I have an idiosyncratic model of TDD and do most of my rapid prototyping development from within Sublime Text, using a Build Process to execute a Python unittest class and tests, of which this is one pertinent example showing basic use. slmoffsets.txt is a file of linearized sequential offsets into the linearised, sequential blocks in bootstrap.dat, which I wantonly press into service as a noncommittal lookup table via the shell utilities head and tail. In these fragments, mentions of datadir are, confusingly, actually references to the bootstrap.dat file. It is a work-in-progress ...

I created the offset map with

Full deal, including a premilled offsets up to ... hang on ..
block 1477565 are in contrib/toolbag in the "develop" branch of the Slimcoin repos.

There's a blockreader.py which I'm now using and a blockreader-workings-out.py in case I've gone down a developmental rabbit hole and later need to restore to a previous save point and try another route.

The develop branch includes the pos-optimization contrib, the coincointrol feature and the chain/block management features. Handle with care.

Cheers

Graham

My sentiments exactly in your case.

And this, in your own words is the evidence that engenders those sentiments.

The Helium opening public ledger will effect the results of the SPR UTXO snapshot script, the latter's composition, execution and results were all made public before, during and after the exercise: https://gist.github.com/gjhiggins/692cf73c0f2b6bde406fc29f427777b0 and https://github.com/heliumchain/helium/tree/master/contrib/sprledgerxfr and extensive posts on the Helium Slack. There is no "seed wallet", as you could have trivially ascertained for yourself and, albeit a presumably novel experience for you, been in possession of some facts. Which wouldn't be a bad thing as they resolve this rather pointless and increasingly personally offensive discussion. I've launched the coin privately several times for development and testing purposes. So have others. A few trial runs have been conducted publicly - and strangely, without the fear of some complete and utter boneheaded, clueless moron launching it on his own because, well, he'd have to be close to a vegetative state not to appreciate that the rest of the Helium group and Cryptopia would just laugh and increment the protocol version.


Right now, I can't be arsed to take exception to your rashly-exposed public accusations of fraud as it must now be clear to everyone subscribing to this thread that if anyone's "a complete and utter boneheaded, clueless moron", it's you although I will credit you with passable punctuation.

Cheers

Graham