[ANN][PIVX] - PRIVATE INSTANT VERIFIED TRANSACTION - PROOF OF STAKE - ZEROCOIN

[B1tUnl0ck3r]

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!

I just wanted to note the quality of your announcement jakiman. Very good public relation manager... I would even say crisis manager .

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

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.

Effectively it happened to me too. Specially on wrong fork. My 0.00000001 Dnet advice would be to touch nothing and restart to sync. most of the time mine rebuild themselves because the stake is invalid.

good luck & patience.

[q327K091]

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

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

[q327K091]

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!

cool , np at all, solid update.. suspending all master nodes even though they by a miracle  are staking, although I can't send em back to the mother ship

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.

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

[B1tUnl0ck3r]

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

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

I agree the POS is one of the major improvement of this particular coin. I hope that in the long term the situation will be stabilized. I am sure the devs are working hard on it. I see those minor inconveniences as a necessary part toward innovation.

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!

cool , np at all, solid update.. suspending all master nodes even though they by a miracle  are staking, although I can't send em back to the mother ship

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.

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

I volunteer gladly a node to the test if useful for the devs. keep us informed of your needs.

[DRPD]

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

some of my mn's also stuck on 261107
others and windows wallet are on 261311 atm.

i guess no point in updating the rest of my nodes ....

[Rageee]

My wallet is still happily staking away.

getblockhash 261334

be073cebc6247bf57a59fe8a4ede62cfc06413b70e97c2cf90005fd615d98c45

[boy2k]

wallet is stuck like the above guys
some nodes are up to date, some stuck.
sigh...

[NotMyFarm]

stuck wallet on
261118
+ Masternode Sync stuck too

[kopykat]

all nodes stuck @ block 261107.

[cryptomaxsun]

The network is still not running. purse need to update?
What happened?

[jakiman]

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 these peer IP's which definitely seem to be good.
I will also try to do the same with my MN's to see if I can build up a stronger chain.

connect=72.49.184.206
connect=68.227.30.210
connect=173.245.158.8
connect=coin-server.com
connect=104.218.120.209

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
    }
]

[mxnsch]

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):

Code:

connect=72.49.184.206
connect=74.118.192.18
connect=138.68.50.249
connect=173.245.157.244
connect=173.245.158.8
connect=coin-server.com
connect=24.119.187.242
connect=178.254.23.111

* 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

Code:

iptables -A INPUT -s 68.227.30.210 -j DROP
iptables -A INPUT -s 173.245.157.244 -j DROP
iptables -A INPUT -s 173.245.158.8 -j DROP

[DRPD]

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.

my controller wallet ist also in sync with http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html an moving forward fine
but i guess i receive to much staking rewards ... and a lot of my masternodes are stuck on some blocks ....

[jakiman]

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):

Code:

connect=72.49.184.206
connect=74.118.192.18
connect=138.68.50.249
connect=173.245.157.244
connect=173.245.158.8
connect=coin-server.com
connect=24.119.187.242
connect=178.254.23.111

* 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

Code:

iptables -A INPUT -s 68.227.30.210 -j DROP
iptables -A INPUT -s 173.245.157.244 -j DROP
iptables -A INPUT -s 173.245.158.8 -j DROP

I'm currently re-trying my first 10 MN's with only the nodes below (which I know for sure are good) & with listen=0. I'll update on how it goes shortly.

connect=72.49.184.206
connect=68.227.30.210
connect=173.245.158.8
connect=coin-server.com
connect=104.218.120.209

[tylerderden]

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.

[bathrobehero]

I forked on the previous wallet again and was at block 230025 but getpeerinfo showed that I was connected to peers with different block heights and headers.

I don't think wallets should connect to peers that are both synced and on different heights.


With the newest wallet I'm stuck at 261107 (7fd290de5cade33ef240c77b0237f4cca6e13fbd876fb0d41f8f19b41104e3db).

[jakiman]

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.

I also agree that it's the MN's that's causing the fork.

Everyone on wrong blockhash or are stuck on block compared to MN info page should stop their wallets & MNs right now. (I did)
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

Going to bed now....

[tylerderden]

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.

I also agree that it's the MN's that's causing the fork.

Everyone on wrong blockhash or are stuck on block compared to MN info page should stop the MNs right now. (I did)
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

I just figure this has never been done, trial and error, rule out every possible cause one by one and go from there, that's all we can do. It seems that whoever is hosting a bunch of Masternodes for a fee, sorry brother can't remember right now and anyone else with more than a few should bring them on slowly over time one at a time. SUCKS if that is the case, especially after that one dude made the sweet ass script but after pondering a bit, this seems like a good Avenue to pursue

[jk9694]

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.

I also agree that it's the MN's that's causing the fork.

Everyone on wrong blockhash or are stuck on block compared to MN info page should stop the MNs right now. (I did)
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

I just figure this has never been done, trial and error, rule out every possible cause one by one and go from there, that's all we can do. It seems that whoever is hosting a bunch of Masternodes for a fee, sorry brother can't remember right now and anyone else with more than a few should bring them on slowly over time one at a time. SUCKS if that is the case, especially after that one dude made the sweet ass script but after pondering a bit, this seems like a good Avenue to pursue

While  I host a considerable amount, they are brought on in just that manner.  The process is automated, but the nodes will only update when I tell them to.  It is a fully managed service after all.  On the same note, I am heavily involved with the developers and the testing.  Many many late nights so far.

[tylerderden]

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.

I also agree that it's the MN's that's causing the fork.

Everyone on wrong blockhash or are stuck on block compared to MN info page should stop the MNs right now. (I did)
http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

I just figure this has never been done, trial and error, rule out every possible cause one by one and go from there, that's all we can do. It seems that whoever is hosting a bunch of Masternodes for a fee, sorry brother can't remember right now and anyone else with more than a few should bring them on slowly over time one at a time. SUCKS if that is the case, especially after that one dude made the sweet ass script but after pondering a bit, this seems like a good Avenue to pursue

While  I host a considerable amount, they are brought on in just that manner.  The process is automated, but the nodes will only update when I tell them to.  It is a fully managed service after all.  On the same note, I am heavily involved with the developers and the testing.  Many many late nights so far.

The late nights thing sucks man, but thanks for putting in the time! I'm just spit balling, have you guys tried just getting pos going on regular wallets no masternodes? If that worked, and your system brings them on slowly maybe it's the rush of some people with you know 40 or 50 MN hitting the network all at once? Just seems like the one factor that could fork us, similar to mining pools with big hash (dedicated ahem..dick lol) hitting new coins. I could be completely wrong I'm out of the loop just been observing and thinking about cause and effect. If you guys want some help testing or just talking shit through I know my stuff so hit me up.


Edit: not sure about this either but what if pos and masternodes are pulling in different directions?  Maybe this requires 2 chains or one with alternating slots in code like line 1 pos chain line 2 masternode 3 pos 4 Mn... hell I don't know.