When compiling the daemon, just use the standard make -f makefile.unix
Thanks! The compilation works now with Boost 1.54. Unfortunately, the daemon still crashes (segfaults) about ~10 minutes after startup (as before, last sign of life in debug log is the "CBlock" line). I will test the newest code now on my other machine. That's clearly unsatisfactory, I shall investigate further. AIUI, this is on Ubuntu Trusty? Is that on a 32-bit or 64-bit architecture? (I seem to have acquired two “Trusty” VMs, one for a 64 bit arch, one for a 32-bit but I have little idea whether the difference has any effect unless the actual machine on which I'm running it is 32-bit). Just a small question about the version numbering: Am I right that the "prerelease" branch would be the "stable" 0.4 version and the master branch is meant to be 0.5? Or are both 0.5? It's because I plan to update the OP a bit with the newest developments.
Now that the dust is beginning to settle on the codebase, we can switch the default github repos back to "master" and use the 0.5 tag to distinguish the supported Linux “0.5 release” build and use the release page to offer downloadable 0.5 binaries for Windows and OS X. Then we can return to the standard “developers work in their own branch” approach. The current “slimcoin” branch can simply be renamed to “slimcoin 0.4”. As far as I can figure out from reading the source code, the release version advertised by the running app is taken from the last git tag (which explains why changing the version number in version.h seems to have no effect). Locally, I could tag my clone as 0.6.6.6, compile the app and the running app would report 0.6.6.6. If I were to push that tag to the public repos, all subsequently cloned+compiled apps would advertise themselves as 0.6.6.6. There's a 6th-level git wizard's spell of push-release-tag-to-public-repos to be uttered at some point (RTFM, Graham). After this, the GitHub repos “release” page can then be loaded with the (correctly-functioning) platform-specific binaries of Slimcoin 0.5 for Windows and OS X. Organic life-forms are advised not to try this with Linux binaries because, basically, there's only one supported latest version of Windows and OS X and therefore static libs are reliable on those platforms whereas that is not the case with Linux where dynamic libraries are the norm (AIUI). I could offer Linux builds that link against dynamic system libraries but I'm not in a position to offer support for local deployment on arbitrary Linux systems with arbitrarily-different dynamic libs. What I can offer is a standalone deployment script using Vagrant (for an optional VM-based build) and ansible provisioning. Ansible is a Python+YAML devops tool which scripts the d/l+compile sequence to either localhost or a Vagrant VM using standard apt-get install to provision the host appropriately to the specific Linux distro and version (g++, Qt, openssl, miniupnpc, qrencode, etc). Even if folks don't want to go as far as a VM build, the Ansible “playbook” spells out each step in excruciating detail, f'rinstance this stanza is from the companion MXE-compile-Slimcoin playbook (step-by-step cross-compile build from source on a VM for increased peace-of-mind) that retrieves Qt sources, nukes the mysql references and compiles: ---
- name: remove mysqllib from Qt5 compilation
action: shell cd /mnt/mxe; grep -v -- '-mysql' src/qtbase.mk | sed -e 's/libmysqlclient //' > /tmp/foo; mv /tmp/foo src/qtbase.mk;
- name: compile Qt5
action: shell cd /mnt/mxe; make MXE_TARGETS="i686-w64-mingw32.static" qttools
register: qtreport
- debug:
msg: '{{ qtreport }}'
This is just an illustrative example in which I tested my hypothesis that the mysql references could be relatively trivially removed from the standard MXE cross-compile build were it to prove desirable. (And yup, it did run all the way through and created a Windows binary from freshly-compiled libs but I admit to not having the patience to wait for the emulated binary to read the blockchain+index. Perhaps I'll let it play out sometime over the w/e while Ngaio and I are enjoying re-watching John Carpenter's much-overlooked 1974 directorial debut film Dark Star, recently re-posted to youtube in good-quality form.) Cheers Graham |
|
|
|
Does anyone have a windows vcoin wallet with coin control? It is a little annoying with the older version (0.9.0.0-beta).
I might have. What's it worth to you? Cheers Graham |
|
|
|
Unless there are strenuous objections (if so, please communicate them), I intend to revert the addition of stealth addresses to Slimcoin 0.5.0
In the absence of (promptly notified) strenuous objections, I have effected this reversion. That's OK for me. Thought a bit about it but I think it doesn't make a significant difference. Note for users of 14.04: due to differences in support for C++ versions, to compile successfully with 14.04, use the following:
qmake RELEASE=1 USE_QRCODE=1 FIRST_CLASS_MESSAGING=1 USE_UPNPC=1 USE_OLDC=1
Does this also work when compiling the daemon alone? I don't want to install QT on my small cloud vserver  When compiling the daemon, just use the standard make -f makefile.unix The Travis CI log shows all the commands executed and the results - the slimcoind binary is compiled first, then (atm) the test_slimcoin is compiled and run, then finally the Qt wallet is compiled. Cheers Graham Edited for brevity |
|
|
|
I didn't make it too far yet from the article when i saw they compare it to learning chinese from learning just the words alone. i find that funny i know exactly what that means, since i am chinese and i know a little chinese and have struggled getting "meanings" of words across all kinds of medium be it (voice, write, type, local dialect, traditional-simplified..etc)..to even my mother, who i have had an argument over this very thing this morning. *very interesting article, need to reread multiple times.
We've drifted into some deep waters. A better starting point than Harnad's ruminations would be the wikipedia entry on Searle's “Chinese Room” thought experiment. Working through the references and bibliography for that article alone would occupy the best part of a decade, there are some very deep thinkers listed there. <digression>I do hope that we Westerners have now completely gotten over the fact that other cultures use other notation forms that they find as natural to work with as we do with our alphabet - IMO, Perl would have been a quite acceptable substitute as an arbitrarily impenetrable symbol set  </digression>. you can't express meaning through words a lone true, there for no "meaning" can come out of software engineering, only function...does that sound a little deflating?.
For me, that's where the fascination lies - it's a showstopper for the reductive models that we create in mathematical-logical notation but it doesn't seem to bother human cognition one bit. as we get back the consensus problem. I have read a little bit of Byteball's implementation of using 12 trusted 'witnesses' for verification purposes. I propose we use 12 top exchanges as 'witnesses' for the bitcoin price, and the timestamp UTC.
granted still require a bit of trust, but decentralized trust on a decentralized price. the altcoins purposes is basically TO put a price on anything and everything. BTC can be the bridge for everything that can and will have a "price".
Unfortunately, that shifts the playing field from pristine cryptography to public theatre. Cheers Graham |
|
|
|
have you opened the wallet fine sir ?
Have you? https://github.com/PIVX-Project/PIVX/commit/ba4334e453ee7878f28fc7357b9a84d718533f70for further clarification what aspect of the shitcoin in question would you like me to elaborate on ?
You're evidently not in a position to elaborate on anything substantive, I'd be remiss if I taxed you further. Subscribers to this thread will be in no doubt as to how to assess your utterances. Cheers Graham |
|
|
|
the wallet has a crappy exchange api that was "revolutionary" 2 years ago , is not helping faith,,, were did i first see that oh yeah ,,, cloak coin
So, not something in your capacity to address then? Feel free to continue jeering from the sidelines in your impotent social inadequacy. Cheers Graham it was addressed, just because you say it wasn't does not make it so Back at ya, let's see some evidence, sunshine. Cheers Graham |
|
|
|
the wallet has a crappy exchange api that was "revolutionary" 2 years ago , is not helping faith,,, were did i first see that oh yeah ,,, cloak coin
So, not something in your capacity to address then? Feel free to continue jeering from the sidelines in your impotent social inadequacy. Cheers Graham |
|
|
|
Wallet compiled successfully in Ubuntu 14.04!!!
phew! that's a relief. Edit: What need more to have final release? Thank you
I may have to strip out the torrent stuff. Although it only uses SQlite for local storage, Qt drags in mysqlclient libs (spit), resulting in: /usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libcrypto.a(sha256.o):sha256.c:(.text+0x2d0): multiple definition of `SHA224'
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libmysqlclient.a(my_sha2.cc.obj):my_sha2.cc:(.text+0x180): first defined here
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libcrypto.a(sha256.o):sha256.c:(.text+0x630): multiple definition of `SHA256'
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libmysqlclient.a(my_sha2.cc.obj):my_sha2.cc:(.text+0x100): first defined here
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libcrypto.a(sha512.o):sha512.c:(.text+0x13f0): multiple definition of `SHA384'
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libmysqlclient.a(my_sha2.cc.obj):my_sha2.cc:(.text+0x80): first defined here
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libcrypto.a(sha512.o):sha512.c:(.text+0x1cb0): multiple definition of `SHA512'
/usr/lib/mxe/usr/i686-w64-mingw32.static/lib/libmysqlclient.a(my_sha2.cc.obj):my_sha2.cc:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile.Release:448: recipe for target 'release/slimcoin-qt.exe' failed
which is a bit of a show-stopper. In MXE, the conjunction of crypto and database in Qt is not exactly a well-trodden path by the looks of it as I can't even find any hints of a reported issue. I will cast around for different approaches, maybe use a more recent version of MXE, maybe clone the repos and compile a version of MXE without the issue, maybe see if I can find an example that uses BerkeleyDB instead, maybe try the build on 14.04 / 15.10 / 17.04. Maybe not bother with DB storage at all. Cheers Graham |
|
|
|
so if we take a snapshot of bitcoin price at a certain day and time. it becomes the most trusted seed for a random generator. can the bitcoin use this for itself some way?
self referencing time...C++ pointers nightmares.
If you're familiar with the old joke where the Lone Ranger and Tonto are surrounded by hostile injuns and the Lone Ranger says to Tonto, "Looks like we're surrounded", to which Tonto turns to the Lone Ranger and replies "Whaddya mean ‘we’, paleface?" The “we” in your statement isn't grounded and cannot be. Have some private intellectual fun, put on a “Mission Impossible” hat and be creative about how such a scheme could be gamed. Then slip on an engineer's short-sleeved shirt and pocket protector and you can get to work on solving the issue of global agreement on “certain day and time” - it'll be a full time job just finding a level of precision that the (oops, sorry, see below - innumerable) population can agree on (using a provably-correct consensus mechanism). Software “knows” nothing. We “know” nothing. It's all modelling and the map is not the territory. As an old-skule AI-er, I know it as the symbol grounding problem. “most trusted” suffers from multiple issues when it comes down to implementation (first choose your modelling tool): “most” requires a population count and so is profoundly problematic when no-one can know the base population. Because we only have a mathematical hammer can trust be nailed down to numbers? But this isn't something than can be answered by a mathematician (and, if Simon Baron-Cohen is correct, probably shouldn’t even be attempted). Human cognition doesn't use numbers natively, mathematics is an invented, internally consistent modelling notation that must first be learned. Trust is idiosyncractic and contextual, a really wicked problem and a non-numeric representation isn't even in sight. This stuff is way more tricky than it might seem. If it were as easy as it looks, it'd be well sorted by now, given the amount of effort expended. Cheers Graham |
|
|
|
using the first sha512 hash's value to randomize determine the order of the algorithm chain (for that particular block)
That makes the sequence unpredictable and thus problematic for a hardware implementation but it cannot be random. Cheers Graham |
|
|
|
Unless there are strenuous objections (if so, please communicate them), I intend to revert the addition of stealth addresses to Slimcoin 0.5.0
In the absence of (promptly notified) strenuous objections, I have effected this reversion. Tests still pass. Importantly, this latter fact can be verified by consulting the Travis CI build record: https://travis-ci.org/gjhiggins/slimcoin-dev/builds/218075235The Travis CI build uses Ubuntu Trusty (14.04) - both slimcoind and Slimcoin-Qt now compile successfully under Ubuntu 14.04. I'm still refining this phase of automating the build process, hence the use of an alternative repos. https://travis-ci.org/slimcoin-project/SlimcoinPlease note, the changes enabling compilation under 14.04 have not yet been propagated to Slimcoin master.https://github.com/slimcoin-project/Slimcoin/commit/a010f8e1dcf0a893bf75c88671920612d9a4e43cNote for users of 14.04: due to differences in support for C++ versions, to compile successfully with 14.04, use the following: qmake RELEASE=1 USE_QRCODE=1 FIRST_CLASS_MESSAGING=1 USE_UPNPC=1 USE_OLDC=1Cheers Graham |
|
|
|
so here's the roulette coin's roulette hashing function.. https://github.com/roulettecoin/roulettecoin/blob/master-0.8/src/roulette.hlike i said c++ not my strongest, can some one explain in syntax terms what they are doing here? unsigned char hash[64];
sph_sha512_init(&ctx_sha);
sph_sha512(&ctx_sha, static_cast<const void*>(&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]));
sph_sha512_close(&ctx_sha, hash);
stuff before that and after that is pretty straight forward to me. (I'm no C++ programmer, so feel free to ignore this) ... AIUI, that is a standardised calling format (for NIST candidates?): 1. Initialize 2. Transform(s) 3. Finalize see: https://github.com/chaincoin/chaincoin/blob/master/src/hash.h#L212Cheers Graham |
|
|
|
Whilst hunting around for the meaning of stealth_version_byte (a bitcoin address prefix, it transpires), I found the following summary of stealth addresses/transactions on Bitcoin stackexchange: As I understand it, the "stealth address" is intended to address a very specific problem. If you wish to solicit payments from the public, say by posting a donation address on your website, then everyone can see on the block chain that all those payments went to you, and perhaps try to track how you spend them.
With a stealth address, you ask payers to generate a unique address in such a way that you (using some additional data which is attached to the transaction) can deduce the corresponding private key. So although you publish a single "stealth address" on your website, the block chain sees all your incoming payments as going to separate addresses and has no way to correlate them. (Of course, any individual payer knows their payment went to you, and can trace how you spend it, but they don't learn anything about other people's payments to you.)
But you can get the same effect another way: just give each payer a unique address. Rather than posting a single public donation address on your website, have a button that generates a new unique address and saves the private key, or selects the next address from a long list of pre-generated addresses (whose private keys you hold somewhere safe). Just as before, the payments all go to separate addresses and there is no way to correlate them, nor for one payer to see that other payments went to you.
So the only difference with stealth addresses is essentially to move the chore of producing a unique address from the server to the client. Indeed, in some ways stealth addresses may be worse, since very few people use them, and if you are known to be one of them, it will be easier to connect stealth transactions with you.
It doesn't provide "100% anonymity". The fundamental anonymity weakness of Bitcoin remains - that everyone can follow the chain of payments, and if you know something about one transaction or the parties to it, you can deduce something about where those coins came from or where they went.
(my italics) Unfortunately, the client handles this quite poorly, stealth addresses are very much longer than WIF addresses and this wrecks the GUI comprehensively, the label is truncated in the display and the rest of the space is filled with (let's not be too coy about this) random characters of a profoundly uninformative and uncommunicative nature: e.g. SfSLMCoinMainNetworkBurnAddr1DeTK5vs dooGjSHpy846JJtVcxfCxVoA2o9aaPsC98cJvpRiqrtAAyXwkcUDFEpTFNpppx7ENMHBx6yDrEyhLHX NsdLvwwYbet4pLvtqAbweDBUnless there are strenuous objections (if so, please communicate them), I intend to revert the addition of stealth addresses to Slimcoin 0.5.0 for the following reasons: a. the core functionality already exists in the Slimcoin codebase b. the imported code introduces additional, untested cryptography c. receipts and payments to stealth addresses are not shown in the GUI d. there are no tests e. 102-character addresses overwhelm the GUI's layout algorithms Cheers Graham |
|
|
|
Now it says this :
"blockchain redownload required approaching or past v0.4 upgrade deadline."
The warning is a harmless inheritance from the Peercoin code: https://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L3238and there seems no objection to my suggestion of removing it from the Slimcoin 0.4.[0|1] codebase. The warning doesn't appear in the 0.5.0 version of Slimcoin that I am preparing for contribution. Cheers Graham |
|
|
|
Yes that was April's fool and now it's over.
I should 'fess up and admit to being taken in for a short while but I didn't go down without a fight (retrieved from drafts): Not sure how, but looks like this account has a Dash symbol?
Is there a ref doc on the icons?
I find I no longer care. I see it as a timely reminder from Theymos to be aware that inaccurate metadata manifests as misrepresentation and that, in turn, suggests dissembling. In keeping with the basic principles of cypherfunk-derived cryptocurrency, it can only be a pointed suggestion to create a fresh bitcointalk subscriber address for each posting. I can't think of any other sane reason for abusing user profiles in such a manner. Cheers Graham |
|
|
|
The concept of a dynamic hashing algorithm is bouncing around in my head.
Has to remain deterministic in order for the hash to be recalculated for verification porpoises. The fanciest pants in this arena belong to the unregarded Roulettecoin: https://bitcointalk.org/index.php?topic=592251.0new randomized mining algorithm (Roulette): block is hashed with sha2, then 16 rounds of hashing are performed, each round with randomly chosen algorithm from the set of 16 hashing algorithms: blake bmw cubehash echo fugue groestl hamsi jh keccak luffa sha2 shabal shavite simd skein whirlpool
The DOACC RDF dataset (*) contains an extensive list of PoW hash schemes used in altcoins. I picked 'em out for convenience, here's an N3 serialisation. https://pastebin.com/7x4HW5ewThere's also a more accessible rendering in the DOACC documentation: https://doacc.github.io/facts/powschemes.html (Expect the latter to exercise your machine a little because it loads the DOACC RDF graph from github into your browser and uses javascript libraries to run an in-browser query on the graph and render the results. The in-list DOACC-id links aren't usefully clickable, sry) Cheers Graham (*) Abandoned, last updated a couple of years ago. |
|
|
|
So is it safe to say CHC is one of the most ASIC resistant if not THE most ASIC resistant coin out there at the moment?
Not really. Simply chaining algos doesn't evade the fact that the program code is deterministic and so can be (reasonably straightforwardly) implemented in hardware (i.e. an ASIC), assuming adequate economic incentives exist. For background technical reading, I like the Graz TU's SHA-ZOO for its comprehensive treatment. It's worth noting that reaching NIST Stage 3 involved an ASIC implementation - i.e. every NIST 3rd-round hash algo has an ASIC implementation: “In this paper we present the implementation results for all five SHA-3 third round candidate algorithms, BLAKE, Grøstl, JH, Keccak, and Skein in a standard-cell-based ASIC realized using 65nm CMOS technology” - http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/March2012/documents/papers/GURKAYNAK_paper.pdf (and that was back in 2012). With enough money at stake, any deterministic program can be implemented in hardware. One can only dissuade, not defeat. One approach to dissuading speculators is to ring the changes on hashing params - a technique used by many scrypt-based algos (scrypt-n, scrypt-n-f, scrypt-j-n, etc). Another approach is to exploit the fact that computers are rich in on-board RAM whereas that is a scarce and, importantly, fixed resource for any ASIC solution, so changing memory requirements also pushes up the costs/risks of an ASIC implementation - IIRC, Vertcoin's LyraRE algo ( PDF whitepaper) takes this approach, as does Axiom ( https://bitslog.files.wordpress.com/2013/12/memohash-v0-3.pdf). (Another view maintains that the appearance of specialised hardware is a Good Thing(tm) in terms of protecting the public ledger.) I see smart contracts as pretty interesting solution for this decentralized funding and spending....but i have not done enough research to testing to see if that's possible.
gmaxwell has stated that the (not Turing-complete) scripting language implemented in the Bitcoin codebase is quite capable of expressing “smart contracts”. There are issues a-plenty, more than enough to fascinate any software engineer (which I'm not). Cheers Graham |
|
|
|
According to the symbol under my username I've been awarded the rank of Clams fanboy... which allows me to come here and post random stuff together with buying some on an exchange  Welcome Not sure how, but looks like this account has a Dash symbol? Is there a ref doc on the icons? I was obliged to check the Meta thread - 1st April, sigh. Cheers Graham |
|
|
|
Thanks for the detailed reply Graham!
Just a clarification, Chaincoin was released before Darkcoin and was originally based on Zetacoin/Bitcoin, so the 11 chained hashing algo was first done by Chaincoin. Chaincoin only later adopted the Dash code base.
It's just my own idiosyncratic take on things. Tsk tsk, I knew I should have checked the actual commit dates. I stand corrected, thank you. Cheers Graham |
|
|
|
1. what are the 11 hashing algorithms chained and what are the benefits of such chaining.
2. can we start the masternodes remotely like other masternode coins, and do we need a unique ip for each or just a different port.
3. and research or plans to expand the masternodes to do elastic computing instead of mining. "elastic chains" sounds great.
4. can the dev team introduce he/she/themselves?
1. what are the 11 hashing algorithms chained and what are the benefits of such chaining.C11 -> https://github.com/chaincoin/chaincoin/blob/master/src/hash.h#L194 (for reference, also see Darkcoin-now-Dash): X11 > https://github.com/dx11/darkcoin/blob/master/src/hashblock.h#L62The benefits are at best arguable and in peer-reviewed cryptography papers the technique (of serially chaining the output of different hash algorithms) has been characterised as “folklore”. The characterisation is accurate, as far as I can ascertain, according to my understanding of the bitcointalk origins of the approach: The original notion of chaining the output-to-input of different hash algos (as opposed to Satoshi's double-wrapping of SHA2 to elide a speculated-upon length extension vulnerability) was proposed by the Russian developer(s) of SIFCoin, ANN, here translated informally: hesh function for the signature block header changed from sha-256 (sha-256 ()), on the daisy chain of the candidates / finalists and winner sha-3. Blake, BMW, Groestl, JH, Keccak, Skein. All functions of the 512-bit, but the end result is truncated to 256 bits. (Rejection of the sha-256 and scrypt - to protect against a possible startup sharp influx, and then just as sharp outflow capacity miners from other currencies, and the subsequent "paralysis." Complication chain to a length of 6 different hash functions and increased bit depth to intermediate 512 - an attempt to protect from further development of highly efficient Mh / s gpu-algorithms and theory, "simple" Gh / s devices).
I've highlighted the key sentence - the aim was anti-ASIC, they ignore any implications for the integrity of the cryptography. The notion was picked up by the developers of QuarkCoin, who threw in another algo: https://github.com/quark-project/quark/blob/1c0961810b65226bf74ba98e7c0a11ada8b7cd32/src/hashblock.h#L18and then stirred 'em up a bit: https://github.com/quark-project/quark/blob/506b294665eb61033cee7bf7404235a93db4e535/src/hashblock.h#L18Unfortunately, it was at this point that the bogus claim for strengthened security appeared in the bitcointalk ANN for Quarkcoin: Super secure hashing: 9 rounds of hashing from 6 hashing functions (blake, bmw, groestl, jh, keccak, skein). 3 rounds apply a random hashing function.
(my emphasis) Although the claim of “super secure hashing” was later quietly dropped from the Quarkcoin rubric (presumably as indefensible), the fiction quickly spread amongst altcoin devs, starting with Darkcoin (which didn't even change the copy'n'pastad function name --- ”Hash9”): https://github.com/dx11/darkcoin/blob/master/src/hashblock.h#L62and a short time later, Chaincoin, which used the same algos but two appear in a slightly different sequence to Hash9. https://github.com/chaincoin/chaincoin/blob/893af8e4bd73344c007b61c20e9b97b2a1cf7b02/src/hashblock.h#L54Subsequently, according to the MOAR-HASHES!!! principle - I don't have any cryptography literature to reference, only psychological literature which, if you'll forgive me, I presume is probably outside your bailiwick - the fiction was developed up to and including X19 (IIRC). I haven't any evidence that there has been a C11 ASIC released thus far but I understand there are one or two X11 ASIC offerings around. From a cryptography standpoint, the approach fails on first principles - not only can the technique not be proven to strengthen the cryptography, it cannot be proven not to weaken it. For a more informed discussion, see http://crypto.stackexchange.com/a/3763, one example amongst many in the literature. 2. can we start the masternodes remotely like other masternode coins, and do we need a unique ip for each or just a different port.Chaincoin 0.9.2 is based on Dash 0.9.2, you get whatever Dash was offering at the time, so the answer is probably “no-yes-no” (testnet is your friend). 3. and research or plans to expand the masternodes to do elastic computing instead of mining. "elastic chains" sounds great.i) This is bitcointalk, talk is cheap and plans even cheaper. ii) Chaincoin is open source software iii) Ask yourself, is there a budget? You may conclude: if there is an unadvertised research effort, it will remain opaque to casual enquirers. OTOH, if there is no public research effort, anyone is free to initiate one. 4. can the dev team introduce he/she/themselves?i) After you ii) I encourage you to reflect on where you first encountered the notion of “ the dev [team]” w.r.t to an altcoin and whether this also might be a popular fiction, given the open source context. Cheers Graham |
|
|
|
|
Show Posts
