[ANN] Orbitcoin v1.6.3.0 ~ NeoScrypt ~ Green Stake ~ 10 Years Old

[Mario241077]

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

[1714023168]

1714023168

[crackfoo]

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?

[ghostlander]

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?

[crackfoo]

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



 

[ghostlander]

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.

[crackfoo]

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...

[crackfoo]

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<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!

[ghostlander]

Could you point me to the original commit for this serialize.h patch?

[crackfoo]

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

[Mario241077]

the coin rushing begins doge jumps by about 100%

where can just jump ORB?

 

http://exchangewar.info/coinprice?DOGE_BTC

[Mario241077]

you can mine ORB here is a list

direct ORB Pool's

main pool

https://orb.dnb.io/

backup privat pool

https://hobbyistpool.ddns.net

https://www.ipominer.com/ direct port OrbitCoin (ORB) stratum+tcp://pool.ipominer.com:4403

multipool

you can mine ORB with scrypt and SHA256 Miner over payout option

http://www.zpool.ca/

    -o stratum+tcp://mine.zpool.ca:PORT -u WALLET_ADDRESS -p xx
    WALLET_ADDRESS must be a valid BTC address. Incorrect addresses will result in forfit of earning.
    You can also use any valid wallet address from any of the coins we mine. This feature has had minimal testing so use at your own risk
    Non-BTC payouts depend on that coin being mined as your BTC balance is traded internally by our system to your currency of choice. If we have not or are not mining that currency your payouts will be delayed until the pool has mined the blocks for you to get paid. If you notice in the pools status that the currency is red, it means there is not sufficient amount of the currency to pay miner(s). It's recommended to use BTC.
    Use -p "c=SYMBOL" if zpool does not recognize the currency correctly.
    See the "Pool Status" area on the right for PORT numbers. Algorithms without associated coins are disabled.

http://hashpower.co

Crypto altcoins mining pool with auto exchange to Bitcoin.
Get the best return for your mining rig.
We distribute hashpower in real time among the best altcoins.
No registration required. You can start mining right away.
Blocks are distributed proportionally among valid submitted shares.
Detailed statistics for the last 24 hours.

We also allow payouts in any currency we mine.

-a algo -o stratum+tcp://hashpower.co:port -u ORB wallet_address -p c=ORB
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 wallet_address -p c=ORB

[Mario241077]

https://twitter.com/OrBitcoinLove

my account.. see the conversation.. help ORB to grow


CriptoPay
‏@CriptoPay

@OrBitcoinLove thank you! we will considerate it

[Mario241077]

the coin rushing begins doge jumps by about 100%

where can just jump ORB?

 

http://exchangewar.info/coinprice?DOGE_BTC

crazy doge  1,480.07 BTC 0.00000086 BTC

a small part of it for ORB

[thefix]

Nice to see Orbitcoin on Bittrex

I think more and more people will take an interest in this coin with its long track record and stable dev.

You also have to love the green staking and low supply of this coin!

Congratulations to Orbitcoin!


https://bittrex.com/Market/Index?MarketName=BTC-ORB

[Mario241077]

i find ORB here

http://coincap.io
http://marketcapcoin.com/

thanks for support

[Mario241077]

Nice to see Orbitcoin on Bittrex

I think more and more people will take an interest in this coin with its long track record and stable dev.

You also have to love the green staking and low supply of this coin!

Congratulations to Orbitcoin!


https://bittrex.com/Market/Index?MarketName=BTC-ORB

we need poloniex. The US-boys make the market. see Doge

Ghost maybe we should buy us a entry

[thefix]

Nice to see Orbitcoin on Bittrex

I think more and more people will take an interest in this coin with its long track record and stable dev.

You also have to love the green staking and low supply of this coin!

Congratulations to Orbitcoin!


https://bittrex.com/Market/Index?MarketName=BTC-ORB

we need poloniex. The US-boys make the market. see Doge

Ghost maybe we should buy us a entry

Poloniex is a good idea and having orbitcoin on more exchanges is good for Orbitcoin and the community.

The main thing is to keep volume up and give people a reason to want to stick with Orbitcoin

A legit gambling site from a trusted name using Orbitcoin would work wonders for this coin.

This coin has been around and stable with a low supply, so its a coin people should take a look at.

[juanjosear]

Hi, how I can know if my wallet is working?


I've updated after a year

coins say:
highest priority
stanking enabled
13 inputs weight 12323

[thefix]

Hi, how I can know if my wallet is working?


I've updated after a year

coins say:
highest priority
stanking enabled
13 inputs weight 12323

What size are your stacks

Have you looked at this? https://bitcointalk.org/index.php?topic=586674.msg7744291#msg7744291

[juanjosear]

28 to 148 coins

debug.log
01/31/16 20:38:39 ProcessBlock: ACCEPTED
01/31/16 20:38:39 ProcessSyncCheckpoint: sync-checkpoint at de0eb944cb35d1ccdd28e8e87486a22db9edad00941de400d08bf362e4092e87
01/31/16 20:38:39 trying connection 94.180.51.35:15298 lastseen=194.1hrs
01/31/16 20:38:41 getblocks -1 to 00000000000000000000 limit 1000
01/31/16 20:38:41 Flushing wallet.dat
01/31/16 20:38:41 Flushed wallet.dat 77ms
01/31/16 20:38:42 getblocks -1 to 00000000000000000000 limit 1000
01/31/16 20:38:44 connection timeout
01/31/16 20:38:45 trying connection 213.49.226.92:15298 lastseen=133.2hrs
01/31/16 20:38:50 connection timeout
01/31/16 20:38:50 getblocks -1 to 00000000000000000000 limit 1000
01/31/16 20:38:50 trying connection 81.184.126.146:15298 lastseen=125.1hrs
01/31/16 20:38:51 getblocks -1 to 00000000000000000000 limit 1000
01/31/16 20:38:55 connection timeout
01/31/16 20:38:56 trying connection 105.103.91.32:15298 lastseen=134.7hrs
01/31/16 20:39:01 connection timeout
01/31/16 20:39:01 trying connection 122.248.102.113:15298 lastseen=125.2hrs
01/31/16 20:39:06 connection timeout
01/31/16 20:39:07 trying connection 187.132.131.58:15298 lastseen=175.7hrs
01/31/16 20:39:08 getblocks -1 to 00000000000000000000 limit 1000
01/31/16 20:39:12 connection timeout
01/31/16 20:39:12 trying connection 75.129.177.46:15298 lastseen=4.0hrs
01/31/16 20:39:17 connection timeout
01/31/16 20:39:18 trying connection 114.198.13.191:15298 lastseen=37.1hrs
01/31/16 20:39:23 connection timeout
01/31/16 20:39:23 trying connection 81.191.41.44:15298 lastseen=4.0hrs
01/31/16 20:39:25 received block 57c419c1a75991bd00f6 height 1636144
01/31/16 20:39:25 Committing 1 changed transactions to coin database...
01/31/16 20:39:25 SetBestChain: new best=57c419c1a75991bd00f6  height=1636144  trust=245157781678511 blocktrust=1064064964  tx=2442937  date=01/31/16 20:38:46

it's working?
Thanks