Topic: [ANN][PIVX] - PRIVATE INSTANT VERIFIED TRANSACTION - PROOF OF STAKE - ZEROCOIN - page 370. (Read 782375 times)

What if all the masternodes are causing the fork? Especially people with bunches. What about everyone running normal wallets for a bit then slowly bringing the masternodes on after we are somewhat stable. It seems to me like we're good then someone fires up a bunch of Masternodes at once and it forks us in several directions. Worth a try I don't know, just a thought. Almost like hitting a low difficulty coin with 30 gigs of hash, it's bound to fork.

You need to follow the instructions carefully guys. All my masternodes and wallet are at 261474 and the status page is current, too.

This is what i did:

Wallet owners:
* stop the wallet
* delete all files except the darknet config, masternode config and wallet.dat (+backups)
* remove all addnode and connect instructions, except those (the following nodes worked reliable for me):
* put the current chainfiles from dropbox in your data folder
* start the 2.0.3 wallet
* unlock the wallet

Masternodes owners:
* stop all nodes
* update the darknetd binary to 2.0.3
* delete all files except the darknet config containing your masternode private key
* put the current chainfiles from dropbox in your data folder
* start all nodes, one by one

I also drop all packages by specific masternodes that were especially unreliable in the past with

My main wallet is still in sync with the MN info page's block & hash which I believe is still correct.
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

I think a certain group of trusted members with many nodes needs to be let in first to establish a good strong network before letting everyone else jump in.
If someone is intentionally generating bad nodes to create a bad chain, hopefully that would make it much harder for the chain to split up like this.

Anyways, unless the devs voice it out beforehand, I'll provide new update from the devs as soon as I have something to post.

Here's my getpeerinfo of my main wallet. Maybe you could try connecting to only those peer IP's.
I will also try to do the same with my MN's to see if I can build up a stronger chain.

23:57:51
?
getpeerinfo


23:57:51
?
[
    {
        "id" : 1,
        "addr" : "72.49.184.206",
        "addrlocal" : "60.240.49.38:59674",
        "services" : "0000000000000001",
        "lastsend" : 1471010271,
        "lastrecv" : 1471010271,
        "bytessent" : 291610,
        "bytesrecv" : 533933,
        "conntime" : 1470994048,
        "pingtime" : 0.26162600,
        "version" : 70500,
        "subver" : "/DarkNet Core:2.0.3/",
        "inbound" : false,
        "startingheight" : 261199,
        "banscore" : 0,
        "synced_headers" : 261466,
        "synced_blocks" : 261466,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 2,
        "addr" : "68.227.30.210",
        "addrlocal" : "60.240.49.38:59676",
        "services" : "0000000000000001",
        "lastsend" : 1471010271,
        "lastrecv" : 1471010271,
        "bytessent" : 14662698,
        "bytesrecv" : 1738611,
        "conntime" : 1470994054,
        "pingtime" : 17.42019800,
        "version" : 70500,
        "subver" : "/DarkNet Core:2.0.3/",
        "inbound" : false,
        "startingheight" : 145635,
        "banscore" : 0,
        "synced_headers" : 147393,
        "synced_blocks" : -1,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 4,
        "addr" : "173.245.158.8",
        "addrlocal" : "60.240.49.38:59690",
        "services" : "0000000000000001",
        "lastsend" : 1471010271,
        "lastrecv" : 1471010271,
        "bytessent" : 375459,
        "bytesrecv" : 562009,
        "conntime" : 1470994069,
        "pingtime" : 0.25908700,
        "version" : 70500,
        "subver" : "/DarkNet Core:2.0.3/",
        "inbound" : false,
        "startingheight" : 261200,
        "banscore" : 0,
        "synced_headers" : 261466,
        "synced_blocks" : 261466,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 5,
        "addr" : "coin-server.com",
        "addrlocal" : "60.240.49.38:59693",
        "services" : "0000000000000001",
        "lastsend" : 1471010271,
        "lastrecv" : 1471010271,
        "bytessent" : 284962,
        "bytesrecv" : 537113,
        "conntime" : 1470994075,
        "pingtime" : 0.25945500,
        "version" : 70500,
        "subver" : "/DarkNet Core:2.0.3/",
        "inbound" : false,
        "startingheight" : 261200,
        "banscore" : 0,
        "synced_headers" : 261466,
        "synced_blocks" : 261466,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 134,
        "addr" : "104.218.120.209",
        "addrlocal" : "60.240.49.38:61621",
        "services" : "0000000000000001",
        "lastsend" : 1471010271,
        "lastrecv" : 1471010271,
        "bytessent" : 233146,
        "bytesrecv" : 432073,
        "conntime" : 1470999944,
        "pingtime" : 0.31801500,
        "version" : 70500,
        "subver" : "/DarkNet Core:2.0.3/",
        "inbound" : false,
        "startingheight" : 261289,
        "banscore" : 0,
        "synced_headers" : 261466,
        "synced_blocks" : 261466,
        "inflight" : [
        ],
        "whitelisted" : false
    }
]

Yeah, I'm having issues also with my MNs. Back to the drawing board is needed I would say.

trust me mine too, it would be negative to the health of this crypto development in general to keep it, its like finding gold chain on the street that is too small fit for a neck

one idea is to use testnet , test heck out of fork. premine test net with some POW (pre-fork), fork, POW again, then rollback , (dont need to be many wallets participating) then the trigger POS and probe the situation

maybe

Yeah. Apparently the MN info page is on the wrong chain also as the devs. So it's still a mess right now.

Devs are looking at ways to ensure the next new wallet will only connect and/or download from a certain chain via hash verification.
Anyways, after the last 3 updates, last thing we want is for another round of multi-forks. So we'll just have to wait more this time.

oh boy, switching to pos seems to have caused a shit show. As i am on the correct chain but my MN is getting mad rewards. would be a shame if the roll back killed them... good job on stopping trex deposits/withdraws

DEV TEAM UPDATE

Basically, new v2.0.2.0 network was going strong for first 5 hours before a bad chain got pulled in by someone and ruined it all.
So the devs are currently working to end this fiasco of forks once and for all. If you know you can help, please PM s3v3nh4cks.

As expected, all the Masternode & Stake payments post-PoS block 259200 may be rolled back to ensure it's fair to all.
We are treading on uncharted waters here as DarkNet is first crypto to have PoS on Bitcoin Core 0.10.x. So hang tight!

Have you checked you masternode transactions?  Some of mine had staked to I needed to make a new address and and change the masternode.conf and the private key in the masternode's darknet.conf.

Yeah, I'm having issues also with my MNs. Back to the drawing board is needed I would say.

one node i have done is stuck there as well. meh!!

Seeing some nodes getting stuck at:

./darknet-cli getblockhash 261107
7fd290de5cade33ef240c77b0237f4cca6e13fbd876fb0d41f8f19b41104e3db

so this update hasnt worked and no point updating nodes?

aaaaaaaaaaaaand we have a 51%+ fork that needs another fork here.

Hardcoded good nodes, blacklisting old clients, a valid checkpoint and a forced sync from scratch should do the trick over the next update.

Patience or dump in my low orders pls.