Look on Vanilla coin (VNL) - new vanilla blake algo - ccminer use it now. profit is not bad now... I start it now!
Yes I'm looking into adding this Thanks!
|
|
|
Not sure if the X15 EverGreen wallet/daemon has gone down, X15 has disappeared from the main page, but one of my miners thinks X15 is the best algo to mine and thus is doing no work, just waiting for it. Looks like the profitability on the connection side of things has not got set to zero when all coins in an algo is down.
I noticed that. Will have to see if something can be added to make sure if no coins are active to clear the profit data. Thanks, I hope you make this one high priority as although I might have saved a bit of electricity, the heating went off during the night! lol. X15 gone again. Please add another X15 coin if this is the quickest way to resolve the issue. yeah I'm trying to find one... any ideas? HTML5 but neither exchange has a viable orderbook.
|
|
|
I have 980GTX and 960GTX. My local Blakecoin hashrate 4.8Ghash, on pool accepted hashrate is 4.6 Mhash!!!!!! (no rejects). It is no good...
Display issue, if you remove the unit, values are almost the same (4.8 vs 4.6). As elbandi mentioned, it's simply a miss calculation and display issue. And my sharerate and profit can be calculate correct? yes, give it a try now and see if it is better. Price point to Gh and hashrate shows in Mh... Ok, I'll need to look into this a bit further. But the bottom line is, it's just a display issue, your sharea submitted is the same as any other miners share and is split up proportionally.
|
|
|
I have 980GTX and 960GTX. My local Blakecoin hashrate 4.8Ghash, on pool accepted hashrate is 4.6 Mhash!!!!!! (no rejects). It is no good...
Display issue, if you remove the unit, values are almost the same (4.8 vs 4.6). As elbandi mentioned, it's simply a miss calculation and display issue. And my sharerate and profit can be calculate correct? yes, give it a try now and see if it is better.
|
|
|
Hi, We've added JIF to the miners multipool: www.zpool.caCheers!
|
|
|
I found that UIS can be traded here - https://www.banx.io/trade?c=UIS&p=BTCNot sure about this exchange though, never heard of it. Do your own research and trade with caution. P.S. Might be useful to contact them about the coming fork and let them know that they should upgrade their wallets. Yes it looks like it is there. We'd prefer to have it stay on polo so several pool ops are lobbying them to keep it. Hope they do, of the coins polo is delisting, this actually has developments so it's kinda frustrating.
|
|
|
I have 980GTX and 960GTX. My local Blakecoin hashrate 4.8Ghash, on pool accepted hashrate is 4.6 Mhash!!!!!! (no rejects). It is no good...
Display issue, if you remove the unit, values are almost the same (4.8 vs 4.6). As elbandi mentioned, it's simply a miss calculation and display issue.
|
|
|
Thank you crackfoo for your support. It looks a really good pool . Hi, We've added BSTY to the miners multipool: www.zpool.caCheers! Thanks! We've found our first block already along with some UIS ones which we're merge mining on yescrypt as well.
|
|
|
Hi, We've added ZET to the miners multipool: www.zpool.caCheers!
|
|
|
Hi, We've added BSTY to the miners multipool: www.zpool.caCheers!
|
|
|
Hi, We've added TROLL to the miners multipool: www.zpool.caCheers! Ty sir! Had some problems with TROLL in the beginning and no blocks were being found, but all is sorted now. Cheers!
|
|
|
We'll be adding DMD to our groestl algo on www.zpool.ca and merge mining it when it's available. Cheers!
|
|
|
Hi,
I'm trying get a pool working but I get errors...
Can anyone confirm what I need to have for stratum settings?
[STRATUM] algo = yescrypt difficulty = 0.1 max_ttf = 40000
reports these errors:
08:13:41: Possible yescrypt error, hash starts with 3cc0d8c1 08:13:41: ERROR Invalid share, 127.0.0.1 subs 0, job 6, 81000001, id 0, 4, 00000000, 56a770d8 8f260040 08:13:43: submit 127.0.0.1 6, 00000000, 56a770d8, de1e0000 08:13:43: Possible yescrypt error, hash starts with a23d32ce 08:13:43: ERROR Invalid share, 127.0.0.1 subs 0, job 6, 81000001, id 0, 4, 00000000, 56a770d8 de1e0000
|
|
|
Added Netcoin to the pool
Why? Isn't this coin dead? It doesn't appear to have a dev, marketing, unique niche, or anything that would make it a desirable currency... Requested by my miners and there's markets for it.
|
|
|
Could you point me to the original commit for this serialize.h patch?
It was copied from another coin, but not sure what one now. here is the whole file: http://hastebin.com/ufegawosov.cpp
|
|
|
07:55:38: delay rpc_call coind:3070 getblocktemplate in 2057 ms 07:55:38: *** ACCEPTED Phoenixcoin 912122 07:55:38: -------------------------------------------------------------- 07:55:38: hash1 a0955803273dbb89ae34036aebf5a96d22e057feb3e519cc407edd919a591274 07:55:38: hash2 000000074fa2b41019ae42ff6a5846bb491c70ffad7025d37963cf6d6164dc6b
everything else I run gets a proper gbt output...
Could you try HAL? It has no TX messaging, otherwise quite similar to ORB in what comes to NeoScrypt. Block hash is also BLAKE2s while PXC employs SHA-256d, though I doubt it matters in this case. I'll give it A try too and let you know. HAL works, www.zpool.ca/site/block?id=500so now.... back to ORB... any ideas? I don't see much difference in the GBT code apart of TXDB vs. UTXO and some cosmetics which is unrelated. This code fails in your case: std::string strMode = "template"; if (params.size() > 0) { const Object& oparam = params[0].get_obj(); const Value& modeval = find_value(oparam, "mode"); if (modeval.type() == str_type) strMode = modeval.get_str(); else if (modeval.type() == null_type) { /* Do nothing */ } else throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode"); }
if (strMode != "template") throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode");
So, what JSON data do you submit in case of ORB and HAL? I think these would be the relevant parts... though its out of my realm... https://github.com/tpruvot/yiimp/blob/yiimp/stratum/client_submit.cpp#L128https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cppIt describes submitting through RPC submitblock or RPC getblocktemplate mode submit on the pool's side. That's fine. It seems your pool attempts to submit incompatible data. Maybe it has something to do with TX messages. Do you add any of them to coin base? A JSON dump of what your pool sends to the daemon before receiving this invalid mode error would make it clear. Ok, I'll see if I can get debug of that. I have the ability to enable or disable tx messages and have tried all combinations of enabled/disabled with and without submitblock etc... ORB is now working. www.zpool.ca/site/block?id=579There was a combination of changes needed, in the orb coind as well as client/coind submit on the stratum side. CC = gcc -CFLAGS = -O2 -fomit-frame-pointer +CFLAGS = -g +++ b/src/rpcmining.cpp @@ -202,7 +202,7 @@ Value getwork(const Array& params, bool fHelp) { Value getblocktemplate(const Array& params, bool fHelp) { - if (fHelp || params.size() != 1) + if (fHelp || params.size() > 1) throw runtime_error(
And a diff of a new serialize.h and orbs: 57d56 < 158,160c157,164 < < < --- > #ifndef THROW_WITH_STACKTRACE > #define THROW_WITH_STACKTRACE(exception) \ > { \ > LogStackTrace(); \ > throw (exception); \ > } > void LogStackTrace(); > #endif 238c242 < throw std::ios_base::failure("ReadCompactSize() : size too large"); --- > THROW_WITH_STACKTRACE(std::ios_base::failure("ReadCompactSize() : size too large")); 241a246 > 309,310c314,316 < #define FLATDATA(obj) REF(CFlatData((char*)&(obj), (char*)&(obj) + sizeof(obj))) < #define VARINT(obj) REF(WrapVarInt(REF(obj))) --- > > #define FLATDATA(obj) REF(CFlatData((char*)&(obj), (char*)&(obj) + sizeof(obj))) > #define VARINT(obj) REF(WrapVarInt(REF(obj))) 797d802 < typedef std::vector<char, zero_after_free_allocator<char> > CSerializeData; 807c812 < typedef CSerializeData vector_type; --- > typedef std::vector<char, zero_after_free_allocator<char> > vector_type; 991c996 < throw std::ios_base::failure(psz); --- > THROW_WITH_STACKTRACE(std::ios_base::failure(psz)); 1091,1095d1095 < < void GetAndClear(CSerializeData &data) { < data.insert(data.end(), begin(), end()); < clear(); < } 1160c1160 < throw std::ios_base::failure(psz); --- > THROW_WITH_STACKTRACE(std::ios_base::failure(psz)); 1219,1362d1218 < } < }; < < /** Wrapper around a FILE* that implements a ring buffer to < * deserialize from. It guarantees the ability to rewind < * a given number of bytes. */ < class CBufferedFile < { < private: < FILE *src; // source file < uint64 nSrcPos; // how many bytes have been read from source < uint64 nReadPos; // how many bytes have been read from this < uint64 nReadLimit; // up to which position we're allowed to read < uint64 nRewind; // how many bytes we guarantee to rewind < std::vector<char> vchBuf; // the buffer < < short state; < short exceptmask; < < protected: < void setstate(short bits, const char *psz) { < state |= bits; < if (state & exceptmask) < throw std::ios_base::failure(psz); < } < < // read data from the source to fill the buffer < bool Fill() { < unsigned int pos = nSrcPos % vchBuf.size(); < unsigned int readNow = vchBuf.size() - pos; < unsigned int nAvail = vchBuf.size() - (nSrcPos - nReadPos) - nRewind; < if (nAvail < readNow) < readNow = nAvail; < if (readNow == 0) < return false; < size_t read = fread((void*)&vchBuf[pos], 1, readNow, src); < if (read == 0) { < setstate(std::ios_base::failbit, feof(src) ? "CBufferedFile::Fill : end of file" : "CBufferedFile::Fill : fread failed"); < return false; < } else { < nSrcPos += read; < return true; < } < } < < public: < int nType; < int nVersion; < < CBufferedFile(FILE *fileIn, uint64 nBufSize, uint64 nRewindIn, int nTypeIn, int nVersionIn) : < src(fileIn), nSrcPos(0), nReadPos(0), nReadLimit((uint64)(-1)), nRewind(nRewindIn), vchBuf(nBufSize, 0), < state(0), exceptmask(std::ios_base::badbit | std::ios_base::failbit), nType(nTypeIn), nVersion(nVersionIn) { < } < < // check whether no error occurred < bool good() const { < return state == 0; < } < < // check whether we're at the end of the source file < bool eof() const { < return nReadPos == nSrcPos && feof(src); < } < < // read a number of bytes < CBufferedFile& read(char *pch, size_t nSize) { < if (nSize + nReadPos > nReadLimit) < throw std::ios_base::failure("Read attempted past buffer limit"); < if (nSize + nRewind > vchBuf.size()) < throw std::ios_base::failure("Read larger than buffer size"); < while (nSize > 0) { < if (nReadPos == nSrcPos) < Fill(); < unsigned int pos = nReadPos % vchBuf.size(); < size_t nNow = nSize; < if (nNow + pos > vchBuf.size()) < nNow = vchBuf.size() - pos; < if (nNow + nReadPos > nSrcPos) < nNow = nSrcPos - nReadPos; < memcpy(pch, &vchBuf[pos], nNow); < nReadPos += nNow; < pch += nNow; < nSize -= nNow; < } < return (*this); < } < < // return the current reading position < uint64 GetPos() { < return nReadPos; < } < < // rewind to a given reading position < bool SetPos(uint64 nPos) { < nReadPos = nPos; < if (nReadPos + nRewind < nSrcPos) { < nReadPos = nSrcPos - nRewind; < return false; < } else if (nReadPos > nSrcPos) { < nReadPos = nSrcPos; < return false; < } else { < return true; < } < } < < bool Seek(uint64 nPos) { < long nLongPos = nPos; < if (nPos != (uint64)nLongPos) < return false; < if (fseek(src, nLongPos, SEEK_SET)) < return false; < nLongPos = ftell(src); < nSrcPos = nLongPos; < nReadPos = nLongPos; < state = 0; < return true; < } < < // prevent reading beyond a certain position < // no argument removes the limit < bool SetLimit(uint64 nPos = (uint64)(-1)) { < if (nPos < nReadPos) < return false; < nReadLimit = nPos; < return true; < } < < template<typename T> < CBufferedFile& operator>>(T& obj) { < // Unserialize from this stream < ::Unserialize(*this, obj, nType, nVersion); < return (*this); < } < < // search for a given byte in the stream, and remain positioned on it < void FindByte(char ch) { < while (true) { < if (nReadPos == nSrcPos) < Fill(); < if (vchBuf[nReadPos % vchBuf.size()] == ch) < break; < nReadPos++; < }
Thanks to elbandi and tpruvot!
|
|
|
07:55:38: delay rpc_call coind:3070 getblocktemplate in 2057 ms 07:55:38: *** ACCEPTED Phoenixcoin 912122 07:55:38: -------------------------------------------------------------- 07:55:38: hash1 a0955803273dbb89ae34036aebf5a96d22e057feb3e519cc407edd919a591274 07:55:38: hash2 000000074fa2b41019ae42ff6a5846bb491c70ffad7025d37963cf6d6164dc6b
everything else I run gets a proper gbt output...
Could you try HAL? It has no TX messaging, otherwise quite similar to ORB in what comes to NeoScrypt. Block hash is also BLAKE2s while PXC employs SHA-256d, though I doubt it matters in this case. I'll give it A try too and let you know. HAL works, www.zpool.ca/site/block?id=500so now.... back to ORB... any ideas? I don't see much difference in the GBT code apart of TXDB vs. UTXO and some cosmetics which is unrelated. This code fails in your case: std::string strMode = "template"; if (params.size() > 0) { const Object& oparam = params[0].get_obj(); const Value& modeval = find_value(oparam, "mode"); if (modeval.type() == str_type) strMode = modeval.get_str(); else if (modeval.type() == null_type) { /* Do nothing */ } else throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode"); }
if (strMode != "template") throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode");
So, what JSON data do you submit in case of ORB and HAL? I think these would be the relevant parts... though its out of my realm... https://github.com/tpruvot/yiimp/blob/yiimp/stratum/client_submit.cpp#L128https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cppIt describes submitting through RPC submitblock or RPC getblocktemplate mode submit on the pool's side. That's fine. It seems your pool attempts to submit incompatible data. Maybe it has something to do with TX messages. Do you add any of them to coin base? A JSON dump of what your pool sends to the daemon before receiving this invalid mode error would make it clear. Ok, I'll see if I can get debug of that. I have the ability to enable or disable tx messages and have tried all combinations of enabled/disabled with and without submitblock etc...
|
|
|
Hi, We've added NET to the miners multipool: www.zpool.caCheers!
|
|
|
07:55:38: delay rpc_call coind:3070 getblocktemplate in 2057 ms 07:55:38: *** ACCEPTED Phoenixcoin 912122 07:55:38: -------------------------------------------------------------- 07:55:38: hash1 a0955803273dbb89ae34036aebf5a96d22e057feb3e519cc407edd919a591274 07:55:38: hash2 000000074fa2b41019ae42ff6a5846bb491c70ffad7025d37963cf6d6164dc6b
everything else I run gets a proper gbt output...
Could you try HAL? It has no TX messaging, otherwise quite similar to ORB in what comes to NeoScrypt. Block hash is also BLAKE2s while PXC employs SHA-256d, though I doubt it matters in this case. I'll give it A try too and let you know. HAL works, www.zpool.ca/site/block?id=500so now.... back to ORB... any ideas? I don't see much difference in the GBT code apart of TXDB vs. UTXO and some cosmetics which is unrelated. This code fails in your case: std::string strMode = "template"; if (params.size() > 0) { const Object& oparam = params[0].get_obj(); const Value& modeval = find_value(oparam, "mode"); if (modeval.type() == str_type) strMode = modeval.get_str(); else if (modeval.type() == null_type) { /* Do nothing */ } else throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode"); }
if (strMode != "template") throw JSONRPCError(RPC_INVALID_PARAMETER, "Invalid mode");
So, what JSON data do you submit in case of ORB and HAL? I think these would be the relevant parts... though its out of my realm... https://github.com/tpruvot/yiimp/blob/yiimp/stratum/client_submit.cpp#L128https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cpp
|
|
|
|