Search results

Keep in mind we're dealing with a network cache. Masternode 'start'ing is nothing more than a signed (by the masternodeprivkey associated with a particular masternode) packet with a particular protocol number, ip, port, vin, and index (all the stuff in masternode.conf) bouncing around the...

I'm not using start-many on testnet. All my testnet nodes are hot nodes. I'm pretty sure the command returns successful if it is able to connect and send data to the ip:port of the masternode. I don't think (could be wrong, haven't read code) it uses any response from the remote side.

sent -- hope it's illuminating.

yes, same block 75799. eduffield , should we a) fix it ourselves, or b) assume this could be a mainnet issue and send you logs or something else?

same. on win qt 64. (linux 64 picked up from its stuck block no problem)

fixed itself I guess. I've been afk. Am still running .18. -- will update to .19 shortly.

69 votes (times 4) cast!

just found all my (linux 64) nodes stuck on block 84451 000000069e4c361acc087ca7fef2d3b2fde3646db560a55503353d56e7c3b39b they think they're started: 'masternode successfully started' my desktop qt is on block 84613 000000f46dac98807c23817f06937fdb68d28ca68f99adfffd535180a2008acb and shows...

69 yeas cast for all! :)

I'm sure there's some better documentation out there, but here's a primer. The type of keys used for signing and addresses come in pairs. A public and a private key. Signing a message requires a private key. Verifying a message requires a public key. (In the case of cryptocurrencies, the...

69 votes cast! ubuntu@node-master:~/testnet$ for node in `seq -w 001 069` ; do echo $node ; (knssh $node 'cd testnet ; ./dash-cli -datadir=. mnbudget vote 73409160b4e97ed712e67757ea6ff9cc6b32fc8087aeb41b355c3b2a635b8ffe yes') & done ubuntu@node-master:~/testnet$ for node in `seq -w 001 069` ...

updated my testnet nodes. :) ubuntu@node-master:~/testnet$ seq -w 001 069 | p 'cd testnet ; ./dash-cli -datadir=. getinfo | egrep "(\"version|protocolversion)" | tr "\n" " " ; CURRENT=`./dash-cli -datadir=. getblockcount` ; echo -n "$CURRENT "; ./dash-cli -datadir=. getblockhash `./dash-cli...

do getblockhash 76356 you should get 00000006a36c1108a4a604eceec6b028253f72057fd76a6ebbca6ad48cdeefc5 then you'll know you're on the right chain.

I rent. Hundreds now. Is cheaper than managing hardware all over the place.

It's a cloud instance. They're mostly single cores. Which is plenty considering dashd (v11) uses < 5% of it.

all my nodes show ubuntu@node-master:~/testnet$ knssh 001 'cd testnet ; CURRENT=`./dash-cli -datadir=. getblockcount` ; echo -n "$CURRENT "; ./dash-cli -datadir=. getblockhash `./dash-cli -datadir=. getblockcount`' 76322 00000001d0b484d973ec5b6c9946613f3edd80debc23522e140a0958d6e9ed1e

No. That would put it at 100%. (It's a single core.)

Just a heads up. All versions of v12 are using a much larger amount of cpu. Below shows last 30 days. First part is v11 running alone. Last part is v12 running along side it.

I wonder if some 'luck' comes into play. As in which peer(s) your wallet decides to listen to. Two out of three of my desktop (win) wallets were out of sync. Doing above got them happy. Yet all of my linux masternodes were already on the longest chain. So there also may be a platform difference...

tools -> wallet repair -> rebuild index if that doesn't do the trick, shutdown wallet, delete peers.dat in %appdata%/your[testnet]dashfolder/testnet3/peers.dat and rebuild again.