Compiling-errors

[coinflow]

Compiling with

./autogen.sh
./configure --disable-wallet
make -f Makefile USE_UPNP=- USE_IPV6=- USE_QRCODE=-

gives some errors (only two copy&pasted):

main.cpp: In function 'CAmount GetBlockValue(int, const CAmount&, uint256)':
main.cpp:1406:16: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (nHeight > 5432099999) {
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-self-assign" [enabled by default]

...

script/interpreter.cpp: In function 'bool IsLowDERSignature(const valtype&, ScriptError*)':
script/interpreter.cpp:169:18: warning: unused variable 'nLenS' [-Wunused-variable]
unsigned int nLenS = vchSig[5+nLenR];
^
script/interpreter.cpp:170:26: warning: unused variable 'S' [-Wunused-variable]
const unsigned char *S = &vchSig[6+nLenR];
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-self-assign" [enabled by default]

It finishes the process and the wallet is usable afterwards, but would be worth to check that out and correct it, in order to get a flawless compiling-process ...

Furthermore: Have you checked/specified the correct ports for RPC and P2P in the code?

See https://github.com/realmooncoin/mooncoin
-->
Ports
RPC 44663 P2P 44664

[barrystyle]

Hi Coinflow,
These are compiler warnings and can be safely ignored; the first refers to the fact that nHeight cannot deal with such large numbers as 5432099999, however this was included to show that there will technically be an end to the coinsupply. Second; the variable 'nLenS' is initialized but not used elsewhere in the code.
This code currently runs on my primary and secondary nodes; as well as some very high volume instances such as the wallets at Bleutrade etc.
And yes; i'm sure I got the RPC/P2P ports correct there :)
I'm not sure how many wallets you've compiled in the past (and this comes before a QT-compiled wallet, which are again something else entirely), but in comparison this code compiles very cleanly.
james

[mooncoindev]

Compiler warnings are safe to ignore.

[coinflow]

I'm not sure how many wallets you've compiled in the past (and this comes before a QT-compiled wallet,

Quite some. Qt is only the second step and not needed for a daemon.

Compiler warnings are safe to ignore.

Would be better to not have them. Moreover: warnings and errors are different things as you know.

And yes; i'm sure I got the RPC/P2P ports correct there :)

The reason for the question:
rav3np2pool has problems to connect to the wallet, even if the ports are explicitly specified in Mooncoin.conf and calling like described here: https://github.com/Rav3nPL/p2pool-rav, which was not needed with the older versions of Mooncoin-wallets (by adding rpcport=44663 and port=44664 to Mooncoin.conf and starting p2pool with options --bitcoind-p2p-port 44664 --bitcoind-rpc-port 44663)

Error-message from p2pool: "Check failed! Make sure that you're connected to the right bitcoind with --bitcoind-rpc-port!"

[mooncoindev]

I had moonrush.org up and running (once synced) within about 10 minutes.
I'll bet its either the rpc port not being bound to the right IP/allowing right IP to connect to it, or the rpc password not being long enough.

Heres the launch parameters I use on moonrush.org:
./Mooncoind -listen -server -daemon -rpcuser= -rpcpassword= -rpcbind=127.0.0.1 -rpcallowip=127.0.0.1

RPC password is 30 characters long, as short passwords would not let my stratum authenticate to the daemon (this was an issue with the older clients too).
I'd advise that he try the above, also try 'lsof -i' from the bash prompt to see what interface the RPC port has bound to and listening; additionally try using curl to manually authenticate against the daemon.

[mooncoindev]

oh dear, p2pool doesnt rely on getwork does it still

[coinflow]

RPC password is 30+ characters long.

lsof -i gives

Mooncoind ... IPv4 ... TCP ip6-localhost:44663 (LISTEN)
Mooncoind ... IPv6 ... TCP *:44664 (LISTEN)
Mooncoind ... IPv4 ... TCP *:44664 (LISTEN)

For Novacoin, the output on the same machine looks like this, for example:

novacoind ... IPv6 ... TCP *:8344 (LISTEN)
novacoind ... IPv6 ... TCP *:7777 (LISTEN)
novacoind ... IPv4 ... TCP *:7777 (LISTEN)

Novacoin p2pool connects seamlessly, as did both older mooncoind.
Seems, as if new Mooncoind (notice, that you have changed to capital M, whereas previous versions used the "standardized" lowercase) listens, but because of that restriction to ip6-localhost, the p2pool-software does not get through (maybe Mooncoind not really listening on 127.0.0.1) ...? Any idea?
Adding rpcbind=127.0.0.1 to Mooncoin.conf did not help. rpcallowip=127.0.0.1 was already set, as was listen=1, server=1 and daemon=1.

Result from p2pool:
...
Testing bitcoind RPC connection to 'http://127.0.0.1:44663/' with username 'xxxxx' ...
... Check failed! Make sure that you're connected to the right bitcoind with --bitcoind-rpc-port! ...

[mooncoindev]

No such thing as standardized in cryptocurrency there matey.
I'd assumed you'dve taken other standard diagnostic measures such as simply testing if the daemon is responding via RPC-JSON; but you havent.

Can I get you to run the following command on the host:
curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getinfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:44663

[coinflow]

No such thing as standardized in cryptocurrency there matey.

That's why I put it into quotation marks. :-) But it simplifies things. No big deal, to alter all relevant mooncoin to Mooncoin in the conf-dirs and -files, but would not have to be ...

curl gives the expected:

{"result":{"version":100500,"protocolversion":70002,"blocks":1101846,"timeoffset":0,"connections":25,"proxy":"","difficulty":4.66879760,"testnet":false,"relayfee":0.00100000,"errors":""},"error":null,"id":"curltext"}

So no problem with that.

[mooncoindev]

Ok, we've verified comms are fine, onto the next step:

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getwork","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:44663

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblocktemplate","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:44663

[coinflow]

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getwork","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:44663

{"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"curltext"}

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblocktemplate","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:44663

{"result":null,"error":{"code":-10,"message":"Mooncoin is downloading blocks..."},"id":"curltext"}

It throws the latter result every time.

[mooncoindev]

Have you tried restarting the daemon since? At the crossover to block 1,100,000 Aikapool forked off causing potential issues.

[coinflow]

Yes, several times; just now again and ~/mooncoin/src/Mooncoin-cli getinfo afterwards gives:

{
"version" : 100500,
"protocolversion" : 70002,
"blocks" : 1101846,
"timeoffset" : 0,
"connections" : 7,
"proxy" : "",
"difficulty" : 4.66879760,
"testnet" : false,
"relayfee" : 0.00100000,
"errors" : ""
}

curl:
{"result":null,"error":{"code":-10,"message":"Mooncoin is downloading blocks..."},"id":"curltext"}

Maybe interesting for you (if you don't know the thread already):
https://bitcointalk.org/index.php?topic=153232.0

Excerpt:

Latest tests show that the getblocktemplate latency doesn't influence efficiency much (at least up to 0.4s). Note that one possible side effect of high latency is that your CPU is used at 100% while bitcoind is processing the request and this could slow down P2Pool, indirectly lowering efficiency. You should not notice this effect on a multi-core CPU if it's not heavily used by other processes. If your getblocktemplate latency is really high (>0.3s) and your efficiency is <100% your low efficiency might be linked to your getblocktemplate latency, it's more likely to be linked to high bandwidth or CPU peak usage, so check that you don't have regular CPU/network peaks before trying to lower getblocktemplate latency needlessly.

Which could answer your above question about getwork ...?

[mooncoindev]

Something is wrong with your copy of the chain if its still doing that.
In regards to getwork; this has been dropped from Litecoin codebase for some time now, this is the underlying reason p2pool isnt working which I hinted at a few days ago.

[mooncoindev]

coinflow,
check out 109c27b (or just clone and recompile from master); will get rid of that pesky 'Mooncoin is downloading blocks...' issue.
baz.

[mooncoindev]

Ended up being resolved in 2688e58, please update your nodes.