Pages:
Author

Topic: [ANN] Orbitcoin v1.6.0.0 ~ NeoScrypt ~ Green Stake ~ 4 Years Old - page 77. (Read 201256 times)

legendary
Activity: 3556
Merit: 1126
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
legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
Could you point me to the original commit for this serialize.h patch?
legendary
Activity: 3556
Merit: 1126
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=500

so 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:

Code:
   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#L128

https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cpp

It 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=579

There was a combination of changes needed, in the orb coind as well as client/coind submit on the stratum side.


Code:
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:

Code:
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 > CSerializeData;
807c812
<     typedef CSerializeData vector_type;
---
>     typedef std::vector > 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 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
<     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!
legendary
Activity: 3556
Merit: 1126
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=500

so 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:

Code:
    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#L128

https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cpp

It 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...
legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
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=500

so 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:

Code:
    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#L128

https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cpp

It 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.
legendary
Activity: 3556
Merit: 1126
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=500

so 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:

Code:
    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#L128

https://github.com/tpruvot/yiimp/blob/yiimp/stratum/coind_submit.cpp



 
legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
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=500

so 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:

Code:
    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?
legendary
Activity: 3556
Merit: 1126
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=500

so now.... back to ORB... any ideas?
legendary
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
Oh nice! bleutrade deactivated my account and steals my coins, not much but a few which i buy over the last dump there

approx 500 ORB
legendary
Activity: 3556
Merit: 1126
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.
legendary
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
and https://www.ipominer.com/ too

OrbitCoin (ORB) stratum+tcp://pool.ipominer.com:4403
legendary
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
ghost read this
https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6
edit: https://bitco.in/forum/threads/buip015-decentralize-mining-with-the-fair-pow-algorithm-and-an-user-configurable-pow-setting.809/

edit: https://github.com/bitcoinclassic/bitcoinclassic/pull/6 "This solves mining centralisation by enabling GPU miners to be the leading-edge again. (Hopefully the next generation of ASIC miners will have learned their lesson, so we don't need to do this again.)" Grin

so why not neoscrypt?

I guess Luke is trolling them with this PoW change patch. There is no chance those people behind Classic approve something like this. However if their fork succeeds which is possible, Luke may re-use this patch for Core Smiley


yes, but it is a good option for more democracy in Bicoin



add https://safecex.com to OP (the price of ORB was short in 0.0005 there Tongue) and their pool http://hashpower.co/

OrbitCoin
(ORB)

0.00011216 BTC

-a algo -o stratum+tcp://hashpower.co:port -u wallet_address -p x

Currencies

We support payments using these currencies at the specified conversion rates. Select the currency you want to get paid in and use your wallet address in the -u parameter on your miner's command line. Make sure the currency you choose is actively mined. You can use your exchange's deposit address.


Example: -u ORB adress -p c=ORB
legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
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.
legendary
Activity: 3556
Merit: 1126
is gbt supposed to return something?

$ orbitcoind getblocktemplate
error: {"code":-1,"message":"getblocktemplate [params]\nReturns data needed to construct a block to work on:\n  \"version\" : block version\n  \"previousblockhash\" : hash of current highest block\n  \"transactions\" : contents of non-coinbase transactions that should be included in the next block\n  \"coinbaseaux\" : data that should be included in coinbase\n  \"coinbasevalue\" : maximum allowable input to coinbase transaction, including the generation award and transaction fees\n  \"target\" : hash target\n  \"mintime\" : minimum timestamp appropriate for next block\n  \"curtime\" : current timestamp\n  \"mutable\" : list of ways the block template may be changed\n  \"noncerange\" : range of valid nonces\n  \"sigoplimit\" : limit of sigops in blocks\n  \"sizelimit\" : limit of block size\n  \"bits\" : compressed target of next block\n  \"height\" : height of the next block\nSee https://en.bitcoin.it/wiki/BIP_0022 for full specification."}

same output from gbt on phoenix but it find blocks...


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...
legendary
Activity: 3556
Merit: 1126
orbitcoind -debug

01/24/16 01:11:15 ThreadRPCServer method=getinfo
01/24/16 01:11:15 keypool return 3
01/24/16 01:11:15 ThreadRPCServer method=getdifficulty
01/24/16 01:11:16 ThreadRPCServer method=getinfo
01/24/16 01:11:16 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=getinfo
01/24/16 01:11:17 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=listtransactions
01/24/16 01:11:47 ThreadRPCServer method=getinfo
01/24/16 01:11:47 keypool return 3
01/24/16 01:11:47 ThreadRPCServer method=listtransactions
01/24/16 01:12:17 ThreadRPCServer method=getinfo
01/24/16 01:12:17 keypool return 3
01/24/16 01:12:17 ThreadRPCServer method=listtransactions
01/24/16 01:12:48 ThreadRPCServer method=getinfo
01/24/16 01:12:48 keypool return 3
01/24/16 01:12:48 ThreadRPCServer method=listtransactions
01/24/16 01:13:15 ThreadRPCServer method=getinfo
01/24/16 01:13:15 keypool return 3
01/24/16 01:13:15 ThreadRPCServer method=getdifficulty
01/24/16 01:13:19 ThreadRPCServer method=getinfo
01/24/16 01:13:19 keypool return 3
01/24/16 01:13:19 ThreadRPCServer method=listtransactions

There are getinfo, getdifficulty and listtransactions. Where are getblocktemplate or submitblock? If the daemon doesn't report them in debug.log, must be something wrong with the call syntax or endianness. Your pool also reports invalid mode. If it works for PXC which has no TX messages, disable them.


You said not to use submitblock...

But here it is, the same as it does on mainnet.

01/24/16 01:13:49 keypool return 3
01/24/16 01:13:49 ThreadRPCServer method=listtransactions
01/24/16 01:14:24 ThreadRPCServer method=submitblock
01/24/16 01:14:24

******* exception encountered *******
orbitcoind[0x524e0b]
orbitcoind[0x41fa8c]
orbitcoind[0x423078]
orbitcoind[0x47680f]
orbitcoind[0x4995e1]
orbitcoind[0x49e9d1]
orbitcoind[0x4e6c04]
orbitcoind[0x4b6a85]
orbitcoind[0x4b9f4a]
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0(+0xba4a)[0x7f503a159a4a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f5039357182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f503886447d]
01/24/16 01:14:32 ThreadRPCServer method=submitblock
01/24/16 01:14:32

legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
orbitcoind -debug

01/24/16 01:11:15 ThreadRPCServer method=getinfo
01/24/16 01:11:15 keypool return 3
01/24/16 01:11:15 ThreadRPCServer method=getdifficulty
01/24/16 01:11:16 ThreadRPCServer method=getinfo
01/24/16 01:11:16 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=getinfo
01/24/16 01:11:17 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=listtransactions
01/24/16 01:11:47 ThreadRPCServer method=getinfo
01/24/16 01:11:47 keypool return 3
01/24/16 01:11:47 ThreadRPCServer method=listtransactions
01/24/16 01:12:17 ThreadRPCServer method=getinfo
01/24/16 01:12:17 keypool return 3
01/24/16 01:12:17 ThreadRPCServer method=listtransactions
01/24/16 01:12:48 ThreadRPCServer method=getinfo
01/24/16 01:12:48 keypool return 3
01/24/16 01:12:48 ThreadRPCServer method=listtransactions
01/24/16 01:13:15 ThreadRPCServer method=getinfo
01/24/16 01:13:15 keypool return 3
01/24/16 01:13:15 ThreadRPCServer method=getdifficulty
01/24/16 01:13:19 ThreadRPCServer method=getinfo
01/24/16 01:13:19 keypool return 3
01/24/16 01:13:19 ThreadRPCServer method=listtransactions

There are getinfo, getdifficulty and listtransactions. Where are getblocktemplate or submitblock? If the daemon doesn't report them in debug.log, must be something wrong with the call syntax or endianness. Your pool also reports invalid mode. If it works for PXC which has no TX messages, disable them.
legendary
Activity: 1242
Merit: 1020
No surrender, no retreat, no regret.
ghost read this
https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6
edit: https://bitco.in/forum/threads/buip015-decentralize-mining-with-the-fair-pow-algorithm-and-an-user-configurable-pow-setting.809/

edit: https://github.com/bitcoinclassic/bitcoinclassic/pull/6 "This solves mining centralisation by enabling GPU miners to be the leading-edge again. (Hopefully the next generation of ASIC miners will have learned their lesson, so we don't need to do this again.)" Grin

so why not neoscrypt?

I guess Luke is trolling them with this PoW change patch. There is no chance those people behind Classic approve something like this. However if their fork succeeds which is possible, Luke may re-use this patch for Core Smiley
legendary
Activity: 3556
Merit: 1126

Could you experiment with the testnet? It's less expensive than to mine blocks on the livenet which get rejected for some reason. There are two active testnet nodes at seed1.orbitcoin.org:25298 and seed2.orbitcoin.org:25298

Start the daemon with debugging on and look at debug.log to see why it rejects them actually.


I'll try some yeah.

Haven't had time to test on testnet, but FWIW, I installed and tested PXC and was able to generate blocks just fine without submitblock enabled.

Not much is even showing up in the orbit logs...

This is the stratum logs (submitblock disabled, txmessages enabled)

20:11:46: ERROR: rpc_do_call: coind:5790 500
20:11:46: ERROR Orbit Invalid mode
20:11:46: *** REJECTED Sad Orbit 4055
20:11:46: block 02000000bca041e0ac111c7290a53767cdcde31898b788fd2134d52f8b3fb2ae0aea09eb2aec96e 168b1e700f4dc2f997817fca507ad2e7cfe94e93911f8adfeb88c7002c624a4563a1b3b1e000dee ea0102000000c624a45601000000000000000000000000000000000000000000000000000000000 0000000ffffffff1d02d70f062f503253482f04b424a4560881004290000000007a706f6f6c0000 00000140420f0000000000232103e417aed9e859978a89e36a094ce558f9a118efb2f73b76ec2c2 03439720b0d30ac0000000000
20:11:46: --------------------------------------------------------------
20:11:46: submit 95.156.52.70 13700, 00000000, 56A424C6, 4000310B
20:11:46: 1532b6d108d7db7d actual
20:11:46: 3fffc00000000000 target
20:11:46: 3b1b39fffffffe00 coin
20:11:46: ERROR: rpc_do_call: coind:5790 500
20:11:46: ERROR Orbit Invalid mode
20:11:46: *** REJECTED Sad Orbit 4055
20:11:46: block 02000000bca041e0ac111c7290a53767cdcde31898b788fd2134d52f8b3fb2ae0aea09eb8f2f2da f4a982ba4d7dfba8a9b5b492c67880cf691449d3850e9eb7265a670aac624a4563a1b3b1e0b3100 400102000000c624a45601000000000000000000000000000000000000000000000000000000000 0000000ffffffff1d02d70f062f503253482f04b424a4560881003e47000000007a706f6f6c0000 00000140420f0000000000232103e417aed9e859978a89e36a094ce558f9a118efb2f73b76ec2c2 03439720b0d30ac0000000000
20:11:46: --------------------------------------------------------------
20:11:46: submit 216.48.95.60 13699, 00000000, 56a424ae, 7000d37a
20:11:46: 1b54c9c85f13b9c6 actual
20:11:46: 1fffe00000000000 target
20:11:46: 000053d799000000 coin
20:11:47: submit 71.63.90.121 13700, 00000000, 56a424c6, 4bba1500
20:11:47: 03a8b51380cf45e4 actual
20:11:47: 07fff80000000000 target
20:11:47: 3b1b39fffffffe00 coin
20:11:47: ERROR: rpc_do_call: coind:5790 500
20:11:47: ERROR Orbit Invalid mode
20:11:47: *** REJECTED Sad Orbit 4055
20:11:47: block 02000000bca041e0ac111c7290a53767cdcde31898b788fd2134d52f8b3fb2ae0aea09eb987389b 5f629add128dd2aef8595f72986ad1d380df336d824534a525db337a9c624a4563a1b3b1e0015ba 4b0102000000c624a45601000000000000000000000000000000000000000000000000000000000 0000000ffffffff1d02d70f062f503253482f04b424a456088100428f000000007a706f6f6c0000 00000140420f0000000000232103e417aed9e859978a89e36a094ce558f9a118efb2f73b76ec2c2 03439720b0d30ac0000000000
20:11:47: --------------------------------------------------------------
20:11:47: submit 71.63.90.121 13700, 00000000, 56a424c6, c0c21300
20:11:47: 05ff5b4c457dbae5 actual
20:11:47: 07fff80000000000 target
20:11:47: 3b1b39fffffffe00 coin
20:11:47: ERROR: rpc_do_call: coind:5790 500
20:11:47: ERROR Orbit Invalid mode
20:11:47: *** REJECTED Sad Orbit 4055
20:11:47: block 02000000bca041e0ac111c7290a53767cdcde31898b788fd2134d52f8b3fb2ae0aea09eb2aec96e 168b1e700f4dc2f997817fca507ad2e7cfe94e93911f8adfeb88c7002c624a4563a1b3b1e0013c2 c00102000000c624a45601000000000000000000000000000000000000000000000000000000000 0000000ffffffff1d02d70f062f503253482f04b424a4560881004290000000007a706f6f6c0000 00000140420f0000000000232103e417aed9e859978a89e36a094ce558f9a118efb2f73b76ec2c2 03439720b0d30ac0000000000
20:11:47: --------------------------------------------------------------

orbitcoind -debug

01/24/16 01:11:15 ThreadRPCServer method=getinfo
01/24/16 01:11:15 keypool return 3
01/24/16 01:11:15 ThreadRPCServer method=getdifficulty
01/24/16 01:11:16 ThreadRPCServer method=getinfo
01/24/16 01:11:16 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=getinfo
01/24/16 01:11:17 keypool return 3
01/24/16 01:11:17 ThreadRPCServer method=listtransactions
01/24/16 01:11:47 ThreadRPCServer method=getinfo
01/24/16 01:11:47 keypool return 3
01/24/16 01:11:47 ThreadRPCServer method=listtransactions
01/24/16 01:12:17 ThreadRPCServer method=getinfo
01/24/16 01:12:17 keypool return 3
01/24/16 01:12:17 ThreadRPCServer method=listtransactions
01/24/16 01:12:48 ThreadRPCServer method=getinfo
01/24/16 01:12:48 keypool return 3
01/24/16 01:12:48 ThreadRPCServer method=listtransactions
01/24/16 01:13:15 ThreadRPCServer method=getinfo
01/24/16 01:13:15 keypool return 3
01/24/16 01:13:15 ThreadRPCServer method=getdifficulty
01/24/16 01:13:19 ThreadRPCServer method=getinfo
01/24/16 01:13:19 keypool return 3
01/24/16 01:13:19 ThreadRPCServer method=listtransactions
legendary
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
We are the world..

we are the children...

lol
If I have contributed to this comprehension, then I have done everything!
What I could.

to also like the current debate, black or white! How sick!?
https://www.youtube.com/watch?v=F2AitTPI5U0


So ghost is the developer and I think he uses ORB in the future, that's befits for ORB!

Coincidence? Or foresight? it seems incredible
Michael Jackson - Stranger In Moscow
legendary
Activity: 1302
Merit: 1000
ORB has a good chance to grow.
We are the world..

we are the children...

lol

i'm too old for a children, but I can leave a better world Smiley
And get my personal peace!
Pages:
Jump to: