Search results

Use "dash-cli getinfo" and check if you node is on the same block as https://explorer.dash.org or https://chainz.cryptoid.info/dash/ If it's not, find the next block (block in getinfo output + 1) in either one of explorers, grab its hash and use these commands: dash-cli mnsync reset dash-cli...

Great report and awesome job! In defense of iOS wallet: it's Apple who requires your app to support new versions only and stops accepting submissions to older version when they release new iOS, there is nothing you can do to push the app that supports old versions AFAIK. And at the same time...

Note to mining pools: As more and more MNs upgrade to 12.2 (80%+ already), winners list on 12.1 becomes less and less consistent. You can check this by running "dash-cli masternode winners 500", note old blocks with "Unknown" winner. This means that by keeping mining on 12.1 your pool will...

I noticed a bunch of masternodes that report 0.12.2.0 or 0.12.2.1 version in p2p messages yet they are running on 70206 protocol according to masternode list. Make sure you see 70208 and not 70206 next to your node in "masternode list protocol" (or in "masternode list full"). If you upgraded...

Ok, now run following commands in console, one by one: mnsync reset reconsiderblock 00000000000000219eb0ff02c8ac196eeaceee1ce7453d228a1af77e129b607f clearbanned

- try "getchaintips 3" in debug console to see if there are any invalid branches - check debug.log for "invalid header" or "invalid block" messages

If you were running testnet MN and don't want to do this anymore - please don't just shutdown the node, move the collateral to de-list your MN.

The more connections you allow the higher the load (you can/will sync to more peers simultaneously). Can't recommend a specific number, it depends on your machine specs. I know that my machine feels a bit toasty with 64 connections, but hey, why just sit there doing nothing if I pay the same $$...

So the difference is that "genkey" gives you an old-style uncompressed privkey (starts with '7') but I don't see why a compressed one (starts with 'X') would fail... that's weird. Anyway... Glad that it worked :)

https://www.dashninja.pl/blocks.html If block is "green" then that's a dip0001 block, both mn and miner are upgraded. If only masternode is "green" (0.12.2.0+) but block is not, then miner is not upgraded. If masternode is "yellow" (0.12.1.0+), then no idea if miner is upgraded or not.

Received. But I found nothing weird there... Let's try it the other way, let's follow the guide: do "dash-cli masternode genkey" and copy its output to dash.conf masternodeprivkey= settings and DMT. Make sure to restart the node to let it read this new config, give it some time to finish sync...

It's not exactly the way it's described in the guide but this should work too. Weird that it doesn't... Can you send me debug.log from the remote node? [email protected] (zip it first pls)

I see some MN that has invalid signature for its ping - make sure mn privkey in DMT settings matches the one in dash.conf on this specific remote node

WATCHDOG_EXPIRED is not an issue if you updated sentinel and have crontab enabled, should fix itself. NEW_START_REQUIRED + "Not capable masternode: Masternode not in masternode list" is indeed an issue. Let your node to sync, wait for at least 10 minutes after you see MASTERNODE_SYNC_FINISHED...

@TanteStefana @qwizzie https://github.com/dashpay/dash/blob/v0.12.2.0/doc/release-notes.md#experimental-hd-wallet

Can you clarify what are the issues exactly? What's the status of your MNs? Are they switching to NEW_START_REQUIRED all the time or ..?

Lot's of nodes come up and down during migration and they have to sync additional data (mnlist, winners, governance) from scratch first time after upgrade due to changes in cache data structure, so I guess this is also a temporary issue and should go away eventually. We'll see :) Traffic from...

Agree with both of you :) (though dual core cpu is probably still an overkill today). High CPU usage was a combination of a bug and a super extreme load due to migration process, there shouldn't be such issue during normal operation time.

Fixed, thanks!

No, it doesn't require any kind of network-wide consensus, so it doesn't need spork.