also the mayority part of the listed pools dont work at all... better to have the list here on the forum, more easy to update
Excellent point, I was planning to do exactly that. 1. Mooncoininfo “Official” list of poolsMultipoolsOther pools2. Recent arrivals as yet unadded to the mooincoininfo list3. P2PoolsAutomagically discovered by the Mooncoin-P2Pool-Scanner : | IPs | Hashrate | Fee | Uptime | Location | | 148.251.13.168:9664 | 2.13 Mh/s | 1.00% | 57.0 days | Germany | | 107.170.43.103:9664 | 0.00 Mh/s | 1.00% | 17.0 days | United States | | 144.76.107.241:9664 | 0.00 Mh/s | 0.80% | 15.6 days | Germany | | 5.45.105.66:9664 | 3.98 Mh/s | 1.50% | 0.3 days | Germany |
Cheers, Graham Edit: added bemining |
|
|
|
Hi guys anyone knows why i can't do transactions of more than 99.999.999 mooncoins? I think its too short, imagine if you have 6.000.000.000 mooncoins....  If that were the case then I would agree. Fortunately, your assumption that Mooncoin's MAX_MONEY parameter is set to 99999999 is demonstrably incorrectThat line of code is the variable binding and has the comment: // Mooncoin: maximum of 100B coins (given some randomness), max transaction 10,000,000,000 for now
So, you're only going to feel unduly constrained if and when your token count exceeds 10 billion . Cheers Graham |
|
|
|
I would like to thoroughly understand the algorithms for a university research project to discuss the development of crypto currencies, I can find some info on keccak, but not much on X11 or X13.
There's a list of algorithms for CPU mining which has some info about x11 (but read on). You'll definitely want to visit the SHA3 Zoo maintained by the IAIK Krypto group of Graz University of Technology. The crypto group there maintains a complete record of the official NIST communications for each candidate hash function along with the zipped file of sphlib-compatible C reference implementation and full documentation, right down to the hardware details. I'd guess that neither x11 nor x13 would be recognised as algorithms as such by your typical crypto worker/researcher, although strictly speaking it's not a wildly incorrect description. To use a musical analogy, they are more akin to arrangements than compositions. The terms "x11" and "x13" in this context refer to the programmatic chaining of the sequential application of a fixed set of hash functions, 11 in total in the case of x11 (BLAKE, Blue Midnight Wish, Grøstl, JH, SHA3, Skein, Luffa, CubeHash, SHAvite-3, SIMD, ECHO) and unsurprisingly, 13 in the case of x13 - as x11 with the addition of Fugue and Hamsi (the latter is a very questionable inclusion, given the information available at the SHA3 Zoo). As is sadly typical in the altcoin tech cesspit, the respective spec for x11 and x13 is the implementation itself, you need to consult the C++ source code itself. It's not difficult to read, given the highly restricted domain of discourse. x11 - Wavecoinx13 - Peercoinc11 - ChaincoinAs a grace note: Chaincoin was released at pretty much the same time as Darkcoin, Chaincoin's "c11" chains the same 11 hash function as x11 but in a slightly different order and it could be mischievously claimed as the only 11-chain-algo altcoin that hasn't been PnD'd  My current count is 111 altcoins using X11 for proof of work, 22 altcoins using (the up-and-coming) x13 and just the single instance of c11. HTH Cheers, Graham |
|
|
|
Brands are for trademarks.
You are apparently experiencing some lingering anachronism arising from your time trip. A contemporary description is available from wikipedia: Brand is the “name, term, design, symbol, or any other feature that identifies one seller's product distinct from those of other sellers.”
The broadening of scope has been accompanied by the development of more sophisticated and effective techniques. The current global retail market for air fresheners has been so expertly cultivated that it is now over $8 billion a year and considered to be one of the strongest growth areas. It's an outstanding example of social anxiety marketing at its most polished and successful. Cheers, Graham |
|
|
|
3. the concept 'nomen est omen'
These days, those who work with the concept use the labels "brand identity", "brand values" and "brand experience". As regards “unifying force”, I can't help but conclude that the only unifying force that this community experiences collectively is gravity. Cheers, Graham |
|
|
|
Has anyone else here gotten [...] something similar? Please have a look at my new game.
all beta testers will get a free lesson in life
For me it seems like someone wants to get bad code (virus, trojan etc.) onto someone else's computer via bitcointalk-PM ... Just a warning. I also received one. I came to the same conclusion. This will become a (very) brief growth area. Cheers Graham P.S. Hiro blagged Silkcoin's blockbrowser to add to Hirocoin (despite moaning about the code quality). I snaffled it in turn and added it to the code in the branch where I'm working on an enhanced Mooncoin wallet for the upcoming anniversary celebration. It works okay, pace Hiro's complaints:  Cheers, Graham |
|
|
|
Here is one way to prevent scam coins with the community, offer a bounty for coin inspection from newly made coins, to check if the code is legit or not
That's what the proposal BinaryClock from Dedicated Pools is working on is about: Committee for Development and Sustainability of the Altcoin Industry http://dedicatedpool.com/draft1.pdfI applaud the CfDaDofAI for the accuracy of their assessment as to where might be the right area to start and the soundness of their assessment that there is a fair chance that the domain might benefit significantly if its practitioners could successfully be motivated to adhere to an agreed set of standards. The Committee's effort may be well-intentioned but it is also unfortunately profoundly and fatally flawed; it provides none of the crucial operational definitions that would enable the scheme actually to be implemented. The consequences of this omission are fundamentally destructive to the intention --- in essence it guarantees that all of the quality assertions stated in the document will reduce to purely personal subjective opinion. The recent Poloniex/Supercoin kerfuffle was an entirely predictable result of Poloniex neglecting to provide even themselves with a reliable operational definition of the software standards they are attempting to impose. I can't seem to find evidence in the draft that the CfDaDofAI did any desk research whatsoever before attempting to set forth what is, in essence, a software engineering standards proposal. The end result suggests that they omitted to inform themselves of even a sliver of the vast amount of existing work on standards in software engineering, their construction, validation and implementation. I would hope that it is very clear to most that the only feasible starting point for such an effort is: “what is the nature of the problem?” That stance has at least a chance of avoiding the ineffectual cargo-culting that currently characterises all the efforts I'm aware of. I find it enormously instructive and, I hope, eventually modestly profitable that the entire industry is apparently oblivious to the fact that the primary issue is not technologic in origin but actually mostly psycho-social and any mooted solution that arises from a single domain can trivially be rejected as insufficiently broad-based to be demonstrably effective. As yet, I've not come across any public manifestation of the problem that doesn't essentially boil down to some people hurling imprecations of “Scaaaaaam!!!” at some other people. (As far as I can make out, the only agreed convention seems to be that periodically they change ends.) Whilst this in itself is unremarkable, unsurprising and quintessentially human, it does leave a lot to be desired in terms of characterising the different factors involved and their interrelationships --- a necessary (but not sufficient) precondition for the identification of a set of candidate solutions, one of which might even include some software standards ... if we're lucky. Agreed, I could have chosen to couch this response in a more gentle auctorial voice but the signal-to-noise ratio of bct rarely rises above the proportion of gold in seawater and experience informs me that mild == ignored. This Committee of apparently anonymous people is potentially in the right position to exert some positive influence but it will need to raise its game substantially if that potential is to have a significant chance of being realised. My idiosyncratic definition of “constructive criticism” in this context is: i) draw attention to a fundamental omission and its logical implications, ii) maybe help people to avoid wasting time pursuing an activity that can be objectively and cogently argued as futile and ii) gesture vaguely in a direction where a remedy might be found. Cheers, Graham |
|
|
|
what do you think, would it be possible to implement some kind of paper-wallet-generator into the Mooncoin-wallet? Maybe a more than useful feature.
I was just reading about that before, same bitcoin wiki page: Tips for making paper wallets - 1. Disconnecting from the Internet guarantees that that the paper wallet generator is truly self-contained and isn't transmitting your keys online.
- 2. Verifying the integrity of the code (and the trustworthiness of the author) is important to make sure a hacker hasn't modified the HTML so that it generates predictable addresses instead of truly random keys.
- 3. Using a very basic printer is advisable since high-end office printers may have WiFi or internal storage that keeps a cache of printed documents.
Practicalities restrict us to simply recommending that Mooncoin holders follow 1. and 3. there isn't much more we can do. However, it's possible that we could improve the Ux by actually tackling 2 instead of making totally unrealistic demands of users. Apart from the woeful laxity of undefined terms such as "predictable" and "truly random", it blithely ignores the fact that users are not generally in a position to verify the integrity of program code (nor are currency exchange operators, apparently). But anyway, the codebase has moved on and there are now strong imprecations against creating paper wallets, e.g. this one from Pieter Wuille: “As of the 0.8.x series, the reference client does not support paper wallets. You can export individual keys, and print them to paper, but you are very likely to shoot yourself in the foot unless you're familiar with the implementation details.
In particular, change (the difference in value between coins used to create your transaction, and the amount being sent) is sent to a fresh address in order to increase privacy of the system. When you're using a paper wallet, you will likely miss these, as well as key pool entries.
There is support planned for deterministic wallets (BIP32), which means a single backup of a wallet seed will be enough to create the wallet. This may or may not end up in 0.9, though.
The reason why no "Export wallet to PDF" exists, is exactly because in the current model, this would result in many misconceptions and lost coins. Without deterministic key generation, no immutable dump of the wallet can survive (a series of) spends.”
Mooncoin could follow Dogecoin's example and plot a course to migrate to the Bitcoin Core 0.9.x codebase. Then, if/when BIP32 is implemented in the 0.9 series, Mooncoin would be in an excellent position to adopt the tech. Cheers, Graham P.S. Some altcoin devs are offering extended "user-facing" wallet functionality by including additional tabs. For example, Silkcoin has a block explorer built in to the wallet, as does AllAgescoin, although with 8 tabs, I think Mike may have got a bit carried away. I hear he's planning to include a TV guide . We could take a sober look at what's available to adapt. Bellacoin has an expanded set of wallet tabs. Most of them are quite simple, using Qt's webhandler to render http-retrieved content a la browser. However, this is also verging on creeping centralism; control of the remote domain means control over the rendered content of the wallet tab - so it's only really suitable for a trusted, actively-defended remote source such as a well-run Foundation or a currently- favoured exchange. P.P.S. Bellacoin's website is an excellent example of high-quality altcoin user support, many props. |
|
|
|
And for sure i'll backup the wallet.dat
I strongly recommend reading the Bitcoin wiki entry on Securing your wallet, there's a potential “gotcha” that you should be aware of. Cheers Graham |
|
|
|
No exchanges, no attention, no support, no block explorer, no dev, 0 value... Yes, it's dead.
Sincere thanks for taking the trouble to contribute to a potential definition of "dead". I'm hoping to develop further my understanding of the mental models that people construct and it's a reasonably reliable phenomenon that definitions nearly always raise interesting and useful questions, the answers to which often shed light on the underlying assumptions and semantic associations. From your post, I receive confirmation of my otherwise tentative conclusion that a characterisation of exchanges is required; any old exchange won't necessarily be acceptable so clearly there are further details to be elicited. Pretty much the same goes for "attention" and "support"; both are quite widely-used terms but there is no corresponding widely-agreed consensus of what they actually mean (at least in terms of motivating the generation of an answer specific to pNut). Thanks to your post, I'm now prompted to go away and consider "attention from whom" and "what kind of attention". Generating useful definitions of "support" and "dev" that will be comprehensible to the technically uninformed presents a tough challenge and neither have a trivial solution. As for "value", I'm going to treat that as a user-supplied function for which the parameters and contextual attributes are beyond characterisation. Thanks again. Cheers Graham |
|
|
|
That's not even remotely amusing. I don't feel comfortable leaving you apparently to labour under such a profound misapprehension --- you must know that's an appallingly insensitive use of that image, as I'm sure a moment's reflection will confirm. I shudder to contemplate the kind of cultural milieu that would alienate you from your own kind so profoundly as to allow you to believe that this image presents anything other than a very sobering reminder of the casual tragedy that genetics can inflict on people who, given a miniscule difference in the way the odds played out, would be otherwise pretty much indistinguishable from any of us. They are people, not sideshow freaks and this is 2014, not 1914. Despite your apparent indifference to innocent misfortune, I can only hope that you will be able to find the fortitude necessary to deal with similarly catastrophic misfortune should it ever attend you. It's not that hard to be a decent human being, the bar's set pretty low and billions manage it all the time. Sadly but hopefully, Graham Edit: clumsy phrasing. |
|
|
|
From a business perspective, in order to have any success in attempting to impose quality standards, the first task you must undertake is to produce operational definitions of your criteria. Otherwise your decisions are vulnerable to being challenged as arbitrary - as in this instance - and, without a clear definition of your terms of reference, you will struggle to gain the authority to support your assessments. Acknowledging that the OP was unfortunately an informal post (being precise with language has its merits), I would nevertheless press you to supply definitions for the following (italicised) words and phrases from your post:
disturbing
code review
evidence of an existing hidden premine
extra coins could potentially be minted all at once at the end of the PoW phase, sent to exchanges via the "anon" feature, and dumped.
other concerns
the proposed method of anonymity
shenanigans with the maximum supply
sufficient
Any business has the right to choose not to trade with specific parties. If something smells fishy to you or your staff, simply do what everyone else does and privately assess whether it meets the criteria you set for your business standards and act accordingly. I suggest that what Poloniex does not need to do is to take it upon itself to be a crusading public arbiter of software engineering quality ( please believe me on this*). Cheers, Graham * http://cs.hbg.psu.edu/cmpsc487/IEEEStds_List.htm |
|
|
|
Riecoin is not a modified clone of primecoin. It is a direct fork of bitcoin and it has nothing to do with primecoin.
I stand corrected. Thanks for that, I'd completely missed that rather important difference. Cheers, Graham |
|
|
|
Not to get too far off topic but there wasn't a lot of quark clones either, right? I can think of just frozen and offerings...
<sings>Ah, yes, I remember it well</sings> Cheers, Graham |
|
|
|
Or are there some?
There are four that I'm aware of: And Riecoin is a modified clone of PrimeCoin, it uses prime constellations for PoW: Cheers, Graham Edited url for Riecoin's bct ref |
|
|
|
{"chain":"Chaincoin","code?":"CHC", "address_version":"?", "magic":"?"},
My reading of the runes prompts me to suggest the following config: {
"chain": "Chaincoin",
"code3": "CHC",
"address_version": "\u001c",
"magic": "\u00a3\u00d2\u007a\u0003"
}
For the code3 value, I always consult the source code directly, for canonical accuracy: https://github.com/chaincoin/chaincoin/blob/master/src/qt/bitcoinunits.cpp#L37address_version is the JSON representation of the hexadecimal representation of the decimal integer which maps to the specified address prefix / leading symbol, i.e. "C" for "Chaincoin". (No, really, I am not making this up). Here's the necessary map of leading symbols to decimal integers: https://en.bitcoin.it/wiki/List_of_address_prefixes. It yields 'C' = 28, the integer value that is bound to PUBKEY_ADDRESS in https://github.com/chaincoin/chaincoin/blob/master/src/chainparams.cpp#L72A spell of "render unto JSON" is described in the Abe FAQ https://github.com/bitcoin-abe/bitcoin-abe/blob/master/doc/FAQ.html#L64; in this specific case, decimal 28 becomes hexadecimal 1c and then that is rendered as JSON by prefixing with a backslash, a lowercase u and a coupla zeroes - thus "\u001c" in the JSON code above. By "magic", I'm guessing that they mean the sequence of four hexadecimal numbers which together form the content of the message start string "pchMessageStart": https://github.com/chaincoin/chaincoin/blob/master/src/chainparams.cpp#L26 ... // The message start string is designed to be unlikely to occur in normal data.
pchMessageStart[0] = 0xa3;
pchMessageStart[1] = 0xd2;
pchMessageStart[2] = 0x7a;
pchMessageStart[3] = 0x03;
Those four hexadecimal numbers (a3, d2, 7a and 03) are rendered as JSON in the manner described above and the results concatenated (preserving the order), i.e. "\u00a3\u00d2\u007a\u0003". I haven't tested it, so it's only my best guess. I took my bearings on "magic" from the Abe config for Litecoin given here http://www.jevon.org/wiki/Litecoin which matches precisely the Litecoin pchMessageStart value: https://github.com/litecoin-project/litecoin/blob/master-0.8/src/main.cpp#L3082. Seems a safe bet. HTH. Cheers, Graham |
|
|
|
Sorry, but could I press you for some more detail on "help me out" ... According to the github repos, Chaincoin is a clone of Zetacoin, itself a clone of Bitcoin 0.8.2, which doesn't offer getnetworkhashps. To get that functionality, the feature would need to be copied across from say, Litecoin 0.8.6.2. And I was curious whether this was as straightforward as it appeared and that does indeed seem to be the case: https://github.com/gjhiggins/chaincoin/commit/863404d4d55ce1995022e4fae320b85ac8ad8e91So, I can report the following initial results, lord knows whether they're accurate or not, does 4Mh/s sound about right for what's basically x11? gjh@ashpool:~/minkiz/coinage/coins/ChainCoin.bis$ ./chaincoind -daemon
Chaincoin server starting
gjh@ashpool:~/minkiz/coinage/coins/ChainCoin.bis$ ./chaincoind getinfo
{
"version" : 89909,
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 0.00000000,
"blocks" : 142479,
"timeoffset" : 1,
"connections" : 7,
"proxy" : "",
"difficulty" : 0.09931863,
"testnet" : false,
"keypoololdest" : 1398481919,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"errors" : ""
}
ta-da gjh@ashpool:~/minkiz/coinage/coins/ChainCoin.bis$ ./chaincoind getmininginfo
{
"blocks" : 142479,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.09931863,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespersec" : 30650,
"networkhashps" : 4829498,
"pooledtx" : 0,
"testnet" : false
}
Seems to be quite well-supported with >3 nodes - a good sign unless you're interested in low-diff fossicking. gjh@ashpool:~/minkiz/coinage/coins/ChainCoin.bis$ ./chaincoind getpeerinfo
[
{
"addr" : "162.243.84.210:11994",
"services" : "00000001",
"lastsend" : 1402656218,
"lastrecv" : 1402656263,
"bytessent" : 6855,
"bytesrecv" : 22840,
"conntime" : 1402655403,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.11/",
"inbound" : false,
"startingheight" : 142466,
"banscore" : 0,
"syncnode" : true
},
{
"addr" : "146.185.148.114:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656263,
"bytessent" : 7783,
"bytesrecv" : 18628,
"conntime" : 1402655404,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.10/",
"inbound" : false,
"startingheight" : 142466,
"banscore" : 0
},
{
"addr" : "5.9.158.79:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656263,
"bytessent" : 9498,
"bytesrecv" : 32044,
"conntime" : 1402655432,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.8/",
"inbound" : false,
"startingheight" : 142466,
"banscore" : 0
},
{
"addr" : "62.210.178.237:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656263,
"bytessent" : 2636,
"bytesrecv" : 16000,
"conntime" : 1402655461,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.11/",
"inbound" : false,
"startingheight" : 142467,
"banscore" : 0
},
{
"addr" : "66.172.10.28:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656263,
"bytessent" : 2941,
"bytesrecv" : 23632,
"conntime" : 1402655484,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.11/",
"inbound" : false,
"startingheight" : 142467,
"banscore" : 0
},
{
"addr" : "91.199.10.2:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656230,
"bytessent" : 3930,
"bytesrecv" : 21744,
"conntime" : 1402655531,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.8/",
"inbound" : false,
"startingheight" : 142468,
"banscore" : 0
},
{
"addr" : "208.107.176.95:11994",
"services" : "00000001",
"lastsend" : 1402656263,
"lastrecv" : 1402656229,
"bytessent" : 2941,
"bytesrecv" : 31909,
"conntime" : 1402655546,
"version" : 70001,
"subver" : "/Satoshi:0.8.99.11/",
"inbound" : false,
"startingheight" : 142468,
"banscore" : 0
}
]
(Lots of compiler warnings about overflows when compiling the extra hashfns; suggests those sources might benefit from an update.) Out of further curiosity (it'll be the ruin of me, one day) - what's your interest in Chaincoin? - technology connoisseur, historian, hodler? Cheers, Graham |
|
|
|
|
Show Posts
