I could not compile "prerelease"
/usr/include/c++/6/array:90:12: note: template<class _Tp, long unsigned int _Nm> struct std::array
struct array
^~~~~
makefile.unix:134: recipe for target 'obj/net.o' failed
make: *** [obj/net.o] Error 1
Noted. What OS are you using for the build? Cheers Graham |
|
|
|
I transcribed Peter Bushnell’s “Stealth addresses” branch of Deepcoin into a Slimcoin “feature.stealthaddress” branch. As one might expect with such a speculative venture, the added code didn't all work. I could create stealth addresses but not send money to them because of an inbuilt sanity check in the “send coins” code which checks that the destination address length == 20 chars (stealth addresses are at least twice that length). So, nearly, but no cigar. I've been shepherding my ducks into a line, tidying things up in preparation for a release and, whilst reviewing the commit history, saw that the PPCoin codebase had seen various commits after the date of the “common commit” between the PPCoin and Slimcoin codebase that I exploited to bring Slimcoin up to PPCoin 0.4 In both instances, you need to scroll down to the commit labelled “Fix calculation of account balance.” (the common point). In the PPcoin repos, there's a series of later commits, some with opaque labels which mask their significance but broadly, everything up to the top of that page is relevant to Slimcoin and I spent yesterday evening working my way through the sequence, fixing conflicts from cherrypicking the commits i.e. apply just the selected commit and ensuring that the result compiles (instead of the simpler but cruder approach of merging all the commits in one indigestible chunk). In the process of managing the conflicts introduced, I noticed that the “address.length == 20” sanity check was replaced by a check which (presumably) will accept stealth addresses (represented as OP_RETURN data) of a length > 20 chars. So, if it all works out, I should be able to successfully add stealth address support to Slimcoin. Also, some of the GUI additions will become more robust as they typically assume that the codebase support the abstractions introduced in the “Merge some Bitcoin code as preliminary step to support coin control features” commit
New data structures:
-CPubKey
-CKeyID
-CScriptID
-CTxDestination
(cherry picked from commit 4708d16)
And it's these new data structures that I reported previously that I managed to “smuggle in” to allow the GUI code to function, e.g. in the Deepcoin stealth address code: https://github.com/Deepcoinbiz/Deepcoin/commit/51221031e8aa4ec0b9bd25bab1508a7a71df2fd9#diff-c04bd6830c6c2f5dac54b1559805f906R482
std::map<CTxDestination, std::string>::iterator mi = wallet->mapAddressBook.find(address_parsed.Get());
It remains to be seen whether these later PPcoin commits actually support the integration of coincontrol (not achieved yet in PPcoin, I believe) but we do have an existing model in the Sprouts codebase: (scroll down to “Fix calculation of account balance” as before, subsequent commits should be cherry-pickable). The coincontrol additions are in the commit labelled Merge pull request #1 from sproutcoin/coincontrol (list of commits, scroll down to the label). There are a lot of changes and it's very definitely speculative work but it just might provide an opportunity to re-seat the Slimcoin code in a much more recent codebase, so I reckon it's worth a go. On a tangent, I have mischievously selected some contents of https://github.com/smith7800/ for your delectation ... I think it is entertainingly suggestive that the original dev is still active but has no active interest in Slimcoin. And, if true, would seem to put the kibosh on any speculation that the original dev was someone notable in the crypto[graphy|currency] scene. Cheers Graham |
|
|
|
Great update and thanks a lot for your work!
As I saw a bit of activity on the repository I played with a few of the branches during the last few days.
The master branch didn't compile, but ...
Thanks for the feedback, that is most useful. I'll attend to master and ensure that it compiles (temporarily ignoring the auto_ptr deprecations) and (all but two of) the tests succeed (below is a description of how to compile and run the tests) . cd slimcoin/src
make -f makefile.unix test_slimcoin
./test_slimcoin
I found it just a little too tedious to keep all the branches merged with master and frankly, once ported, there isn't much to do other than add tests, so I merged the lot into prerelease and will then merge that with master to create a release (which, on Github, opens the opportunity to provide OSX/Win binaries downloadable from the GH repos “Releases” tab. That's the overall plan at any rate. Just a word about the OP_RETURN features. Did you hear about AKASHA ( http://akasha.world)? .. This project may go in the direction of that "collective intelligence" you talked about in some of your previous posts. Thanks for drawing my attention to AKASHA. I did see it and I passed it by - I'm being brutalist; any social-networking-oriented effort that is insensible to the implications of a 99.9999:0.0001 m/f ratio can safely be ignored as doomed to fail. (see Simon Baron-Cohen’s work on the “Extreme Male Brain” and note carefully that this a spectrum [1, 2]) As for Slimcoin, still a huge fan and looking forward to the OSX release. Right now I'm moving all the Slimcoins from the linux machines (including the raspberry PI) to the OSX version, in which I enabled staking. So mining and burning is done on Linux and staking only on the visual client.
OP_RETURN debugging continues - I'm beginning to suspect that (at least part of) the problem lies in what I've coded to be written as OP_RETURN data rather than what's being read but neverthess, OP_RETURN txs are being correctly recognised by the code:  The (lifted from Torrentcoin) code correctly reads the OP_RETURN data and (incorrectly in our case) splits the data by space characters and assigns the (expected) third chunk (the split is 0-indexed) to be processed. It's not getting what it expects and there's no clue in the Torrentcoin code as to what was written originally as OP_RETURN data (I can only assume there was a separate RPC script that did the heavy lifting) so I'm obliged to use the C++ code to build an understanding of what the code expects to see - and then decide whether that's actually suitable for Slimcoin's particular use of OP_RETURN. There is an overall direction to the work I'm doing on the Slimcoin code. The codebase is now (reasonably? arguably?) stable - but what are we going to do with it? So, I'm looking at “Server-less & domain-less websites updatable via torrents and bitcoin blockchain.” https://github.com/elendirx/web2web/I've already got this running (on a 0.13.X Core codebase) using the Qt5 WebEngineWidget. The disadvantage is that QWebEngineWidget uses the Chromium JS engine and (so) there is no MXE cross-compilation path to Windows. I'm given to understand that native compilation on Windows is feasible using a recent version of VS but I'm not really in a position to go down that route, so it's tentative at best. However, it's a pure soft fork, uses the standard OP_RETURN tx feature and doesn't need anything out of the ordinary, so QWebEngine-capable Linux and OS X “publish-by-torrent” Slimcoin clients can happily co-exist with vanilla WIndow clients [1] https://iancommunity.org/cs/understanding_research/extreme_male_brain [2] https://en.wikipedia.org/wiki/Empathizing–systemizing_theory “Here comes the science ...” According to Baron-Cohen, females on average score higher on measures of empathy and males on average score higher on measures of systemizing. This has been found using the child and adolescent versions of the Empathy Quotient (EQ) and the Systemizing Quotient (SQ), which are completed by parents about their child/adolescent,[11] and on the self-report version of the EQ and SQ in adults.
More recently, Simon Baron-Cohen, a prominent autism researcher at Cambridge University, has proposed the extreme male brain theory of autism, which attempts to explain the remarkable similarities between traits generally associated with human "maleness" and traits associated with the autism spectrum.
What are these traits? For one thing, typically developing males tend to show strengths in mathematical and spatial reasoning and the ability to discriminate details from a complex whole. Compared with typically developing females, however, males tend to be at higher risk for language impairment and at a disadvantage on social-judgment tasks, measures of empathy and cooperation, and imaginary play during childhood. 12 Many of the traits associated with ASDs could be thought of as an extreme profile of "typical male" strengths and challenges. Where, on average, typical men may be good at detail-oriented processing, people with ASD may be incredibly good at perceiving detail...and impaired when it comes to seeing "the big picture." Where typical men may be less able than women to make social judgments or empathize with others, people with ASDs are literally disabled in these areas.
It's a spectrum which prompts me to think objectively about the implications for altcoin communities which are, in practical terms, all-male groups. Cheers Graham |
|
|
|
@gjhiggins: Do you think the 0.4.1 client is stable enough now to consider it the "stable" release (to not say the "official" one  )? I haven't tested it very thoroughly but for me it seems stabler than 0.3x. But I keep having sync problems, although only on one machine now (on the other one it's doing pretty well). Long answer (surprise, surprise), I'll respond to your particular comments before waffling on at length about irrelevancies ... It's difficult to offer informed help with sync issues, I haven't experienced any sync issues with the 0.4.1 client. AFAICT, under typical network conditions, I'm not seeing anything exceptional in terms of number of orphans. However, in common with many small altcoin networks, Slimcoin’s slim number of nodes renders it much more vulnerable to instability from large and sudden changes in hashrate so I'd be rash if I were to attempt to make predictions about future stability. CPU demand is directly related to a relatively large number of coins being staked and the (often consequent) large number of stake transactions in the wallet: the more coins staked, the more processing is required. I have successfully reduced Slimcoin's CPU usage to its previous level by raising my reservebalance. On the topic of a possible release - I have been merging my exploratory git branches into the prerelease branch and have something to offer the community ... I recently dallied with Sprouts, my interest being sparked by their experience of seeing “block too old, contact dev” warnings in the RPC output and the GUI - as Slimcoin has experienced in the past. This, I discovered while playing around with the Sprouts code, is because it inherited Sunny King’s centralised “sync checkpoint” scheme which relies on the sync checkpoint private key holder to regularly and frequently generate fresh sync checkpoints. If that process ceases, the warnings will inevitably appear. Slimcoin’s original release inherited the same code+problem: https://github.com/slimcoin/slimcoin/blob/master/src/checkpoints.cpp#L410 // Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex *pindexSync = mapBlockIndex[hashSyncCheckpoint];
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
}
For the 0.4.1 preparatory work, I just nuked it: https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/checkpoints.cpp#L378 // Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
//FIXME : always too old
return false;
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
}
and left myself a note to find out why it was failing. Now that I know why these warnings were appearing, I can safely disable the sync checkpoint test: https://github.com/slimcoin-project/Slimcoin/commit/e4d69b7f28e6c6325eab93b43e8aea980112ec7d#diff-c33d3ce1a2a004536aaf1b90f6458900R377 /*
https://talk.peercoin.net/t/the-removal-of-checkpointing/2121/18
d5000 writes:
My problem with the actual checkpointing approach is that it adds a
possible attack vector: let's call it the "CheckpointPrivateKey hack attack".
Any malicious individual which hacks the computer of the private key holder
can control the network and double-spend. Even worse, the computer with the
private key must be connected to the Internet to send the checkpoints, so
this key cannot be stored in offline cold storage (except if Sunny has some
kind of brainwallet mechanism).
*/
// Is the sync-checkpoint too old?
bool IsSyncCheckpointTooOld(unsigned int nSeconds)
{
/* Disabled due to infeasibility of meeting maintenance requirements
LOCK(cs_hashSyncCheckpoint);
// sync-checkpoint should always be accepted block
assert(mapBlockIndex.count(hashSyncCheckpoint));
const CBlockIndex* pindexSync = mapBlockIndex[hashSyncCheckpoint];
return (pindexSync->GetBlockTime() + nSeconds < GetAdjustedTime());
*/
return false;
}
I applied the suppression to the Sprouts wallet, they're happy bunnies again. Which is nice because Slimcoin actually came out well ahead in the deal ... It transpires that Sprouts was launched a few months after Slimcoin and is one of the rare altcoins that was a genuine fork (i.e. contains the commit history) and buried deep in the full history was a little gem of a commit with the unprepossessing title “Merge some Bitcoin code as preliminary step to support coin control features” and was commented thus. New data structures:
-CPubKey
-CKeyID
-CScriptID
-CTxDestination
(cherry picked from commit 4708d16)
These data structures are the basic origin of the genetic difference between ppcoin and peerunity. We can merge upstream PPcoin code into Slimcoin but not Peerunity code. Slimcoin remains a PPcoin clone because it doesn’t have the above-mentioned data structures defined. The other thing that Sprouts has are some might-be-nice-to-have GUI additions such as support for both signing and verifying messages (Slimcoin 0.4 only has support for signing) and support for creating multisig transactions. So I had a go at applying the “preliminary step” commit but had to abandon the task because it proved more demanding than I had hoped. However, I did manage to smuggle in just enough of the new data structures to be able to integrate the GUI improvements into Slimcoin. Here's a feature parade ... Drop-down menu contents, reservebalance value included in overview I changed the relatively lightly-used “Burn coins” GUI component from a tooltab to a dialog box, reducing the demand for mainwindow horizontal space. Block browser and transaction decoder Simple RPC-driven blockchain browser and transaction decoder (copy'n'paster the tx id from the tx history listing). I'm investigating the possibility of extending it a tad to show tx type (i.e. identify OP_RETURN inscription txs). Migrated Burn coins dialog Standard “Burn coins” dialog, as a dialog. Inscription dialog A simplified dialog box for creating OP_RETURN txs. A tx value of 0 identifies the tx as an OP_RETURN tx, as according to the Bitcoin devs’ intentions. Some integration work still to be done, difficult to say how much but see below. Sign message Standard bitcoin feature of proving ownership of an address by signing (hashing) a message. Verify message Verify that hashing a message with an address matches a given hash. Create multisig address Completely untested but it’s ostensibly “just” a GUI presentation of basic client functionality normally accessed via JSON-RPC, so what could possibly go wrong?  Spend multisig transaction Again untested and again, “just” a GUI presentation of basic client functionality. “Torrent” listing Work in progress. Originally a(n apparently non-functioning) component of Torrentcoin, this GUI listing of “inscribed” torrent entries will scan the blockchain for OP_RETURN txs from address of the default wallet account. Reserve Balance editing spinbox in options dialog I've also been experimenting with providing GUI support for editing the reservebalance value and have made some progress. To make a decent fist of this turned out to be more complicated than it first seemed. Still working on this but it's basically functional in that - in the absence of an overriding setting either via config file reservebalance or via command-line option, editing the value in the options dialog works. Until I can work out why the summary display doesn't update, you have to restart the client to see the changed reservebalancevalue. Just briefly, back to the commits ... If we unwind a bit to a slightly more recent commit, we get to “Relay OP_RETURN data TxOut as standard transaction type” --- which is a much neater separation of the concerns than the one I distilled for myself previously for enabling OP_RETURN in Slimcoin. I was able to use this commit to check the OP_RETURN implementation I completed earlier which was apparently producing nonsense:
gettransaction 7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920
{
"amount" : 0.00000000,
"fee" : -0.01000000,
"confirmations" : 0,
"txid" : "7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920",
"time" : 1484194638,
"comment" : "",
"from" : "",
"message" : "",
"to" : "",
"details" : [
{
"account" : "",
"address" : "msQd2xVVsXPEPkaUKegVwd531mXyKSnFax",
"category" : "send",
"amount" : -0.01000000,
"fee" : -0.01000000
},
{
"account" : "",
"address" : "1Wh4bh",
"category" : "send",
"amount" : 0.00000000,
"fee" : -0.01000000
},
{
"account" : "inscription",
"address" : "msQd2xVVsXPEPkaUKegVwd531mXyKSnFax",
"category" : "receive",
"amount" : 0.01000000
}
]
}
and there's some cause for hope in that it may just be an issue with the implementation of gettransaction rather than some underlying problem because the results from getrawtransaction make much more sense.
getrawtransaction 7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920 1

{
"hex" : "010000004e0377580121251f2c2af4baeb9369cc57e44ef6c821e3bed8c968fd6719e
8703c3b098c69000000004a493046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5
af6a51871c56b25783cbee60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb68
3f4ae799f882f1d601ffffffff035076f200000000001976a91479dc215797b4b61ec29fe325230 9
fbd96f8d4a5d88ac10270000000000001976a914826eef9b08e72c682285a6a54e5a9ec746e8
fa8388ac00000000000000000a6a08face010060d6870100000000",
"txid" : "7206eb9f2e7acf03d9d9d909065cec79b63f7fbe131bea4ea8d868881b4f9920",
"version" : 1,
"time" : 1484194638,
"locktime" : 0,
"IsBurnTx" : false,
"vin" : [
{
"txid" : "698c093b3c70e81967fd68c9d8bee321c8f64ee457cc6993ebbaf42a2c1f2521",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5af6a51871c56b25783cb
ee60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb683f4ae799f882f1d601",
"hex" : "493046022100ebca2724051e4d95f7f9bbf97e3cc42614a9f46f5af6a51871c56b25783cbe
e60221008ccdf9bb2d5d2c8b56fddacc853a36ecf00a78fd0650cb683f4ae799f882f1d601"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 15.89000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 79dc215797b4b61ec29fe3252309fbd96f8d4a5d OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : ["mrdHmBZZazjYsV81xbh1r915EbLzBtApvx"]
}
},
{
"value" : 0.01000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 826eef9b08e72c682285a6a54e5a9ec746e8fa83 OP_EQUALVERIFY OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : ["msQd2xVVsXPEPkaUKegVwd531mXyKSnFax"]
}
},
{
"value" : 0.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "OP_RETURN face010060d68701",
"type" : "nulldata"
}
}
]
}
Quite promising really. Next step is to create and make available testnet-only prerelease Windows and OS X apps and get the testnet up and running (testnet is easy to mine, doesn't use the expensive dcrypt hash). Cheers Graham |
|
|
|
So i just posted here that PIvx appears to be a new version of dash without the bad start
I posted a response to a newbie-created thread asking about OWL and BOScoin. Thread completely vanished and my response doesn't appear in my post history. (But that's probably normal for bitcointalk) Cheers Graham Edit. I thought to check my drafts: looked into the most public implementation project at the moment, BOScoin.
As written, the BOScoin white paper is nonsensical conjecture. The authors are hallucinating a requirement for a procedural extension to a declarative representation. Wrt OWL and ontologies - fwiw, the blockchain is a directed acyclic graph (DAG) and in consequence, it maps straight into an RDF model. Unlike BOScoin, I can offer a proof-of-concept, see the DOACC ontology, developed from Melvin Carvalho's initial CCY ontology: DOACC docs: https://doacc.github.io/DOACC repos: https://github.com/DOACCDOACC ontology https://github.com/DOACC/doacc/blob/master/doacc.owlDOACC population: https://github.com/DOACC/individualsIf you're interested in exploring OWL and the subset DLs and you're not already aware of Stanford's FOSS ontology authoring app, Protege, then obtaining a copy and working through the basic ?how to create an ontology? tutorials will give you a +5 spell of immunity from BOScoin-style bloviation. Cheers Graham Thread: https://bitcointalk.org/index.php?topic=1825607.0The above (posted) response has disappeared completely - no deletion advice, nothing. The only trace is in my drafts. Probably a database hiccup and, I suspect, perfectly normal for bitcointalk. Cheers Graham |
|
|
|
Hi, 1. Re reports of burn orphans, I also saw a small handful of burn orphans for a couple of days around that time, seems to have settled down now. 2. Setting reservebalance to an aggressively high value calmed Slimcoin's CPU use. 3. Slimcoin is not the only PoS alt with a CPU usage issue, the current BeecoinV2 client has the same “problem”: The new DEV should check the code of the Windows wallet because the staking process is driving the cpu to throttle at almost 100% continuously.
I had to restart my BeeCoin2 node with an empty wallet not to stress the cpu.
With an empty wallet there are no coins to stake for and the cpu is then running low.
But isn't this part of the design? The more coins I stake (in the expectation of increasing my holdings via mint-by-proof-of-stake), the more work my CPU has to perform. AIUI, this is how PoS is designed to protect the public ledger. Cheers Graham |
|
|
|
..Secondly, as has been recently mentioned: what vision?
..
Well, this one to start with More longer-term, this one
I would not characterise these as visions but as (perfectly valid and rational) technical development directions because they don't focus on the user but on the technology/service. For me, a vision needs to be i) user-focused and ii) something “other”. Cheers Graham |
|
|
|
If you’re interested in the details of the changes, just drop me a PM. <- offer open to all.
No problem about the tech itself, it is that the explorer's wallet is now returning in its getinfo API "errors" : "Warning: This version is obsolete, upgrade required!" which is why I asked (that message also gets reflected in the explorer) Ahh, I wasn't aware of that. Thank you. Cheers Graham |
|
|
|
I like this fork idea where spreadcoin exists as a separate entity for georgem's tinkering and the main branch having an updated codebase that functions with a greater emphasis on coin's vision.
It sounds sensible until one begins to pick apart the entailments: Firstly, it would risk making an orphan of georgem's work unless the efforts were synchronised, which is not on the table because georgem needs pretty much total freedom in order to meet his responsibilities to his Patreon funders. Secondly, as has been recently mentioned: what vision? Cheers Graham |
|
|
|
Wallet is saying the 0.9.0 is obsolete, and there are indeed some nodes showing 0.9.2.2, however the github repository still only contains 0.9.0...
Is there a newer repository?
We're quietly working to upgrade the coin all the way to Bitcoin Core 0.13.x ( https://github.com/gjhiggins/vcoincore), continuing the policy of staying very close to the core upstream code - so the change shouldn’t have any untoward impact on a block explorer beyond that of a standard upgrade from a Bitcoin 0.9.x codebase to a Bitcoin 0.13.x codebase. Schedule-wise, we're not expecting to make an announcement for at least a couple of months yet - we'll need to give it a bit of a hammering on testnet first. If you’re interested in the details of the changes, just drop me a PM. <- offer open to all. Cheers Graham Edit: extended offer. |
|
|
|
|
ISTR someone observing (correctly at the time) that Spreadcoin lacked a “public vision”.
I pondered that for a long time and eventually arrived at some conclusions:
i) a “vision” can be misleading - ANNs for pump-and-dump runs typically feature ambitious (albeit spurious) visions, presumably to draw in the punters
ii) the notion of an overall directing “vision” is untenable in the context of a peer-to-peer networked cryptocurrency
iii) a functioning Teal organisation will evolve its own vision common purpose as an emergent property of the social consensus
Visions have an unfortunate habit of vaporising when the dev loses interest (examples abound). I'd argue that they signify an elevated risk of failure, the more detailed and extensive the vision, the more damage if/when it proves vacuous.
Cheers
Graham
|
|
|
|
Please reference the new Emercoin source code / recent upgrade : The rarely experienced freezing of a wallet with a large number of transactions has been eradicated. Seems to be applicable to the Slimcoin wallet issue that myself and a few other's have reported. Unfortunately, it’s a bridge too far, so to speak. The Slimcoin codebase isn’t amenable to an approach that exploits the Emercoin development in this instance. According to my reading of the runes, it would seem that the remedy came via the importing of the Bitcoin 0.10.2 GUI and the optimization of block upload protocol: - New GUI from Bitcoin 0.10.2 (including control of transaction inputs)
...
- Optimized block upload protocol (headers are uploaded first, and then the blocks are uploaded asynchronously).
- Faster block uploading due to parallel processing provided by multiple peers.
- More responsive block uploading, preventing freezing of the GUI.
- http://emercoin.com/2016-09-24-Emercoin_0.5.0_Release_NotesThe Emercoin codebase development is on an entirely different level to Slimcoin's, the former is the result of a sustained development effort by a stable and competent team, e.g. “merge with bitcoin 0.10.4”. Relatedly - I note that the CPU usage of my locally-running copy of the GUI has risen to a typical 50% of its thread, reaching 80% at times. I shall try setting reservebalance to a significant value, see whether that affects its CPU usage. Cheers Graham |
|
|
|
The principle of the POB is good but it is not very motivating. During 15 days I do not win a single block with a very little use network. If the networks become popular it would take years to win a block. http://imgur.com/a/Nwxz8The best POS system is for me the Cryptobullion POSP. This makes the staking really appealing. If we could combine the POB with the POSP, slimcoin would be a very much more attractive currency How would you approach the calculation of redefining the balance between mint-by-proof-of-work, mint-by-proof-of-burn and mint-by-proof-of-stake? https://github.com/slimcoin-project/Slimcoin/tree/slimcoin/simulationsCheers Graham |
|
|
|
From the main thread: ... just a little happy spread tidbit (i take my alt coin crypto very seriously doncha know, )
a few months back i posted that i couldn't get that damn vanity gen thing working.
...
ShitQUc37GvDwVce9DP6D326A4gAw8y61z
The vanity generator address feature is one that, as a cognitive psychologist with extensive knowledge of and experience in UI principles, I would strongly dis-recommend for adoption in any independent development effort because, in the context of WIF-serialised addresses, it is a UI antipattern. Vanity addresses open up an opportunity to exploit the fact that human memory is in fact a dynamically reconstructive process, not a lookup table. An agent could offer an apparent-seeming match: ShitQUjQfAHjSHnmw9Qf3W2T3YQTjTtjBf (either maliciously or inadvertently) which would be vulnerable to known limitations of attentional resources and optimisation “features” of the perceptual process to the extent that it would effectively promote the “fooling” of a momentarily-inattentive user into not double-checking the address and potentially sending coins to a destination different to that intended. Vanity addresses are dis-recommended from a security perspective too, as they leak information about the trading activities of the holder of the privkey. Co-incidentally, I haven’t yet managed to come up with a plausible-seeming answer to my (self-imposed) question of: what role do vanitygen addresses have in an HD-capable wallet such as Bitcoin Core 0.13.2 that offers full BIP32 functionality? In the same arena, would anyone be up for having a go at generating the appropriate SPR BIP32 version bytes? The version bytes are hard-coded into the protocol so the prefix is common and cannot be readily (ab)used as an exploit. Cheers Graham |
|
|
|
I don't want to continue to be name called for FUD and Trolling. Its rather tiresome when I feel I'm asking perfectly constructive questions.
I admit to being less constructive but other than that, you reflect my sentiments exactly. My continued interest in the different stances adopted by the disparate elements of the original inclusive Spreadcoin community is based on my respect for the perspicacity of the original community members. Broadly, if they were savyy back then about Mr Spread's take on things, then they'll be just as savvy today - possibly about things that I don't yet have a good understanding of and it behooves me to pay heed. I (like to think that I) ask questions (of myself, of the corpus of empirical work, of knowledgeable others) in an effort to deepen my understanding of the techno-socio-econo-political phenomenon that is the shared ledger. Whenever I get “pushback” from that activity (myself including), it invariably means the vulnerability is profound and reaches right down into the foundations of the effort. (Being equally harsh with own fanciful notions helps me keep my feet closer to where I think the ground might be). I seem to have an unfortunate facility for pressing georgem’s button. It’s not the first time I’ve encountered this in my technical career, far from it (as you might reasonably suspect). The contradiction between the position he affects and the immaturity of his communication style is significant and not one that I ignore. As to revitalising the original Spreadcoin project as an alternative development path (to be pursued independently of - but not necessarily excluding - whatever georgem and his funding group decides to work on/release) ... I’m not aware of any well-founded arguments for the continued development of the 0.8.X clone versus focusing the development on one of the clones of Bitcoin Core, so I'm assuming an underpinning Bitcoin Core implementation. But which? Each version brings its own improvements and enhancements which are just as useful to users of a cloned alt such as SPR as they are to BTC holders. To segwit or not to segwit is the question being discussed elsewhere (c.f. Blockchain mechanic, LItecoin, et al.) Can Mr Spread's 0.8.X-hosted implementation of an overlay network be readily refactored/upgraded to be integrated with 0.13.2 or does the mass of accumulated changes to the core implementation class structure present a significant barrier in terms of technical knowledge and effort? (hint: yes, it does). Where is the “competition” and what problems are they aiming to solve (in order to be able to mount a defence against - “why bother, just switch to a more promising horse”) An influential PIVX member and code contributor posted this as their alt's set of attributes: Here's something I posted on Slack a while back for the newcomers to PIVX. (slightly updated) It's just a list of stuff as I see it. I tried to stick with facts only. Hopefully it's useful to some. What sets apart PIVX from other digital currencies? (or just good in general) 01. PIVX is a open source crypto currrency based on DASH so it inherited its core technologies such as Masternodes, Private transactions and Instant Transactions. 02. PIVX uses Blackcoin's improved Proof of Stake 2.0 protocol instead of Proof of Work. So it is more efficient in keeping the network secure than PoW. 03. PIVX had no ICO nor existing pre-mine as it was publicly burnt. 04. PIVX is based on Bitcoin 0.10.x core (and currently going to 0.13.2) which means it is more up to date than most other PoS digital currencies that commonly use a lower Bitcoin core version. 05. PIVX employed a professional media company for its new logo and website development. (Go live ETA end of Feb) 06. PIVX uses an innovative variable Seesaw Reward Balance System that dynamically adjusts its reward to masternodes and staking nodes. 07. There is a technical whitepaper for the above feature. https://docs.google.com/document/d/1G58gtDdQtT-8kV8Fu7_764Fxn0i5fs0jGURvz8KJlTE/08. PIVX has an active community on multiple social networking sites such as BCT, Slack, Reddit, Twitter, Riot etc. 09. PIVX community also uses Trello for publicly accessible task planning and management. 10. PIVX has a highly active, accessible and responsive development team. (always open to new devs) 11. PIVX is available to trade on multiple exchanges including Bittrex with plans to be added to larger exchanges. 12. PIVX currently has a monthly decreasing block reward inflation with it reaching its final low inflationary rate of approx. 4.8% pa beginning mid-May 2017. 13. PIVX has a repository of guides with more planned including video guides and materials. https://darknet-crypto.atlassian.net/wiki/display/DG/Darknet+Guides14. PIVX has had consistently higher profitability percentage compared to other digital currencies utilizing masternodes such as DASH since launch and even now. 15. PIVX will remove coinjoin method of DASH and implement a modified libzerocoin protocol and will be used full-time. It will utilize performance degradation. What would be required and how long would it take for an independent Spreadcoin development effort to be able to match (at least) most of those statements? Cheers Graham |
|
|
|
This has been the official spreadcoin thread for quite some time now.
I must be failing to express myself clearly. I'll try again (my father would say, in his inimitable unreconstructed style, “If a man doesn’t understand, he hasn’t been told properly.”) The term “official” pertains to utterances of a duly constituted officer of a legally recognised entity. It has no meaningful semantics outside a legally-recognised organisation with a formalised hierarchy of control. I'm curious to know what attribute(s) of this particular bitcointalk thread prompt you to misperceive it as “the official spreadcoin thread” as opposed to, say, the main thread on spreadcointalk - isn't that also the “official” Spreadcoin thread on the “official” Spreadcoin discussion board? I find myself wondering whether I should be reading it instead as “officious”. It would seem to be a more plausible interpretation. Cheers Graham |
|
|
|
official Spreadcoin
Stop trolling the community. Spreadcoin is an open source project, in the context of which the term “official” is semantically vacuous. Doesn't the code need to be shared to make it open source? It's not open source yet... I'll respond to your question in the “other” thread, I don’t intend to disturb the waters here. My admonishment of georgem for his casual abuse of “official” was in pursuit of a mature level of discussion *. Cheers Graham * Edit: A futile gesture, I fear. |
|
|
|
official Spreadcoin
Stop trolling the community. Spreadcoin is an open source project, in the context of which the term “official” is semantically vacuous. Cheers Graham |
|
|
|
|
Show Posts
