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

mxnsch

sr. member

Activity: 474

Merit: 252

Quote from: presstab on August 13, 2016, 02:30:50 AM

My opinion is that the "light" syncing that new core version of bitcoin and others have, which are centered around headers, is the root of the cause. You cannot check proof of stake with the information supplied in the current headers, so many wallets are essentially blindly accepting headers and supposing that they are valid. Every once in a while invalid headers slip in, and this creates a problem when trying to sync up.

I have created a blocks-only wallet, and I believe it is the solution for now. It suspends the "light" headers syncing functionality. I have had success testing the blocks-only wallet internally on my machines. It needs to be put to the test by everyone else though.

I think you are up to something here, i am ready to setup a couple of nodes to test it as soon as the code is available for build.

Thanks for taking care!

djselery

legendary

Activity: 1386

Merit: 1001

Quote from: tylerderden on August 13, 2016, 02:34:43 AM

Nice. Well we certainly have the right community to test it out. This has been the most chill crypto thread I think I've seen.

no shit, actually the best

tylerderden

copper member

Activity: 1162

Merit: 1025

Nice. Well we certainly have the right community to test it out. This has been the most chill crypto thread I think I've seen.

presstab

legendary

Activity: 1330

Merit: 1000

Blockchain Developer

Quote from: mikegi on August 13, 2016, 02:02:22 AM

I suppose there can still something else wrong with verifying the blocks other than the multiple chains. I tried to sync a node (using "connect=") from some of my masternodes that were on the same chain and it still gets stuck...

Maybe the devs could describe a bit about what they see as the problem and how to approach fixing it and get some fresh eyes on the code in github. The new software versions forks have put the DNET network into a weak and unstable state, this is something that could be addressed.

My opinion is that the "light" syncing that new core version of bitcoin and others have, which are centered around headers, is the root of the cause. You cannot check proof of stake with the information supplied in the current headers, so many wallets are essentially blindly accepting headers and supposing that they are valid. Every once in a while invalid headers slip in, and this creates a problem when trying to sync up.

I have created a blocks-only wallet, and I believe it is the solution for now. It suspends the "light" headers syncing functionality. I have had success testing the blocks-only wallet internally on my machines. It needs to be put to the test by everyone else though.

mikegi

full member

Activity: 165

Merit: 100

Quote from: jakiman on August 12, 2016, 06:38:15 PM

BTW, what is causing the fork?

Will another week or two of PoW (low reward) with the new wallet before switching to PoS help?

Basically the are to two tiers of p2p.

Miners (in this case now PoS staking) who generate new blocks and headers.

Masternodes, that provides services like voting, anonymous transactions, etc. and are able to reject blocks that they consider to be invalid.

With different chains, Masternodes aren't in agreement about new blocks

The Dash Whitepaper has a description of the differences from bitcoin and what masternodes do and how they work...

https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf

I suppose there can still something else wrong with verifying the blocks other than the multiple chains. I tried to sync a node (using "connect=") from some of my masternodes that were on the same chain and it still gets stuck...

Maybe the devs could describe a bit about what they see as the problem and how to approach fixing it and get some fresh eyes on the code in github. The new software versions forks have put the DNET network into a weak and unstable state, this is something that could be addressed.

NotMyFarm

full member

Activity: 236

Merit: 100

Quote from: B1tUnl0ck3r on August 12, 2016, 03:32:17 PM

Quote from: 4x13 on August 12, 2016, 03:19:51 PM

Who has a wallet/masternode that is stuck on block 261683 I need you to send me your debug.log file please. from before that block up to getting stuck

Hello s3v3nh4cks,

Sadly I never went farther than the 261107... sorry not to be able to help you.

May the code be with you.

Courage!

same here
followed instructions twice
stuck on Mac Wallet 261107 and not getting anywhere

jakiman

legendary

Activity: 1638

Merit: 1011

jakiman is back!

BTW, what is causing the fork?

Will another week or two of PoW (low reward) with the new wallet before switching to PoS help?

jakiman

legendary

Activity: 1638

Merit: 1011

jakiman is back!

I guess the MN info page is stuck also now. While all my MN's are stopped. I just retried just 1 but still gets stuck at 261107. I'll stop for now.
I have plenty of MNs. So if the devs want me to start them up prior to next public release to build a bigger initial network, let me know. Wink

BTW, this is the script I've been using. Let me know if this isn't correct or can be improved.

Quote

#!/bin/bash
echo "Stopping darknet"
./darknet-cli stop
echo "Removing old Version"
rm darknetd
rm darknet-cli
sleep 30
echo " Removing old blockchain data "
cd
cd .darknet
rm -R blocks chainstate db.log fee_estimates.dat mncache.dat peers.dat mnpayments.dat debug.log budget.dat backups
sed -i.bak '/listen/d' ~/.darknet/darknet.conf
echo 'listen=0' >> ~/.darknet/darknet.conf
sed -i.bak '/addnode/d' ~/.darknet/darknet.conf
echo 'connect=72.49.184.206' >> ~/.darknet/darknet.conf
echo 'connect=68.227.30.210' >> ~/.darknet/darknet.conf
echo 'connect=173.245.158.8' >> ~/.darknet/darknet.conf
echo 'connect=coin-server.com' >> ~/.darknet/darknet.conf
echo 'connect=173.245.157.244' >> ~/.darknet/darknet.conf
echo 'connect=178.254.23.111' >> ~/.darknet/darknet.conf
wget https://www.dropbox.com/s/njdjxmsvhwh6njf/.darknet.zip?dl=0
unzip .darknet.zip?dl=0 -d ~/.darknet
rm -rv .darknet.zip?dl=0
cd
echo "Downloading new version"
wget https://github.com/Darknet-Crypto/Darknet/releases/download/v2.0.3.0/darknet-cli
wget https://github.com/Darknet-Crypto/Darknet/releases/download/v2.0.3.0/darknetd
echo "setting permissions"
chmod +x darknet*
echo "Starting Darket damon"
./darknetd
sleep 120
echo "Starting Masternode"
./darknet-cli getinfo
echo "all done "

werwortmann

member

Activity: 80

Merit: 10

Quote from: 4x13 on August 12, 2016, 03:19:51 PM

Who has a wallet/masternode that is stuck on block 261683 I need you to send me your debug.log file please. from before that block up to getting stuck

I have masternode that is stuck on 261686, 3 blocks later.
Usefull?

B1tUnl0ck3r

sr. member

Activity: 854

Merit: 277

liife threw a tempest at you? be a coconut !

Quote from: 4x13 on August 12, 2016, 03:19:51 PM

Who has a wallet/masternode that is stuck on block 261683 I need you to send me your debug.log file please. from before that block up to getting stuck

Hello s3v3nh4cks,

Sadly I never went farther than the 261107... sorry not to be able to help you.

May the code be with you.

Courage!

4x13

legendary

Activity: 1078

Merit: 1011

Who has a wallet/masternode that is stuck on block 261683 I need you to send me your debug.log file please. from before that block up to getting stuck

borris123

hero member

Activity: 728

Merit: 500

Quote from: tylerderden on August 12, 2016, 12:31:44 PM

Yep tried both of the above same result stuck on that same block. Shutting her down so if you guys fix it while I'm out I'm not dragging the network towards fork age, good luck boys.

same just tried it on a few. nvm. will keep checking back till there a fix.

tylerderden

copper member

Activity: 1162

Merit: 1025

Yep tried both of the above same result stuck on that same block. Shutting her down so if you guys fix it while I'm out I'm not dragging the network towards fork age, good luck boys.

B1tUnl0ck3r

sr. member

Activity: 854

Merit: 277

liife threw a tempest at you? be a coconut !

Quote from: jakiman on August 12, 2016, 09:16:32 AM

Quote from: mxnsch on August 12, 2016, 09:08:50 AM

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

thank you for the suggestion... I tried it. However the dreaded block 261107 was insurmountable for my node. In a sense 2.0.2 was working "better"...

I read good ideas here... maybe increasing the number of trusted node for the release could be a nice option until the network stabilize. I wouldn't exclude nefarious actors trying to undermine this project...

patience...

muchoman

sr. member

Activity: 465

Merit: 250

Quote from: tylerderden on August 12, 2016, 12:00:37 PM

Sounds like an idea because yeah no matter what I do my nodes are all over the place. At one point I had them all on 2.0.3 but then stuck on a block. Everything else has resulted in nodes running 1.0.1 and 2.0.1 I'm sure that while implementing pos while having masternodes is not helping any lol. Upgrade your shit people! Or its just some dick playing games, like they do...

Right now I have 3 on 2.0.3, 2 stuck on block 261107 and node 173.245.158.2 on block 261137 height 261653 and counting (only on the height though)

Not sure what's up

Wallet is 8 hours behind and not moving past 261107

This is using mxnsch directions exactly

This worked for me, seems to be correct chain.
getblockhash 263095
1d3ceaefc613004219292f50f5f25f3afb17bb66ea90d67fec85fde942240872

https://bitcointalksearch.org/topic/m.15896582

tylerderden

copper member

Activity: 1162

Merit: 1025

Sounds like an idea because yeah no matter what I do my nodes are all over the place. At one point I had them all on 2.0.3 but then stuck on a block. Everything else has resulted in nodes running 1.0.1 and 2.0.1 I'm sure that while implementing pos while having masternodes is not helping any lol. Upgrade your shit people! Or its just some dick playing games, like they do...

Right now I have 3 on 2.0.3, 2 stuck on block 261107 and node 173.245.158.2 on block 261137 height 261653 and counting (only on the height though)

Not sure what's up

Wallet is 8 hours behind and not moving past 261107

This is using mxnsch directions exactly

EcoChavCrypto

sr. member

Activity: 448

Merit: 250

Quote from: tylerderden on August 12, 2016, 10:56:39 AM

Quote from: jk9694 on August 12, 2016, 10:44:20 AM

Quote from: tylerderden on August 12, 2016, 09:53:44 AM

Quote from: jakiman on August 12, 2016, 09:47:20 AM

Quote from: tylerderden on August 12, 2016, 09:35:22 AM

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.

Maybe the hosting companies could rebuild nodes with the correct addnodes and include IP tables blocking the ones that are causing the fork. There might be enough nodes between the hosting companies to stabilise the network. Do a stealth wallet release to the hosts and their clients and make it public when there are enough stable nodes for it not to fork. That could work right?

tylerderden

copper member

Activity: 1162

Merit: 1025

Quote from: jk9694 on August 12, 2016, 10:44:20 AM

Quote from: tylerderden on August 12, 2016, 09:53:44 AM

Quote from: jakiman on August 12, 2016, 09:47:20 AM

Quote from: tylerderden on August 12, 2016, 09:35:22 AM

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.

jk9694

full member

Activity: 274

Merit: 122

Quote from: tylerderden on August 12, 2016, 09:53:44 AM

Quote from: jakiman on August 12, 2016, 09:47:20 AM

Quote from: tylerderden on August 12, 2016, 09:35:22 AM

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

copper member

Activity: 1162

Merit: 1025

Quote from: jakiman on August 12, 2016, 09:47:20 AM

Quote from: tylerderden on August 12, 2016, 09:35:22 AM

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

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