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. Nice to hear your opinion. So the staking will be based on the available balance instead of unspent (and unlocked) transactions? I'm sure more would like to hear about how staking will work when there is time to explain. |
|
|
|
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.pdfI 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. |
|
|
|
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. |
|
|
|
|
All masternodes nodes and peers down, let the remaining masternodes continue into a hundred forks of Darknet PoS Classic 1 to n.
Just do it, don't look at the balance and and transactions, erase those old blockchains.
Looking forward to PoS at 259200 again... maybe keeping the PoS and Masternode reward low for a month would help. For example 10 for proposals and 5 DNET divided between MN and PoS.
|
|
|
|
But I did learn a few things to do it quicker using scripts, clustershish etc. So yeah, new skill earned at least. Now I'm ready for next update.  Had to google ClusterSHISH.... thought it was a misspelling... good that there is something like clusterssh for Windows users. :-) |
|
|
|
The problems syncing could be due to problems with checking the proof of stake, or verifying blocks. I set up one node to sync using "connect=" from 5 masternodes that are on the same chain. I assume the masternode would all send the same block updates and there should be no differing headers) The syncing got stuck about 100 blocks from where the masternodes were. (stuck on block 261687... 9278bbfb89902faee60e0b1a44d6b53616915168aae893b7d8c2ef4e1268aa60 ) If one is not able to sync from 0 blocks (without downloading a blockfile), reliably, then something is seriously broken. It would be interesting to know if master nodes are paying on the chain that the are on only, or both chains. I haven't looked into how masternodes work in detail,I suppose they check, sign and send transactions based on the fork that they are on, and these are verified by other masternodes based on their version of the chain. Also, it's possible that a masternode can exist on one fork and not the other if it's transaction has been spent on one chain and not on the other or if the masternode transaction only exists on one fork (created after forking). So we end up with masternodes disagreeing. DarkCoin / Dash has had at least this fork: https://www.dash.org/forum/threads/issues-with-masternode-payments-fork.858/I noticed that these messages stop appearing in the logs when the syncing freezes: 2016-08-11 23:13:54 UpdateTip: new best=55e6a5b9629e9a8bb8c00e43079857d6db2f832b5fdcf0a69e060c4dadadf564 height=260824 log2_work=55.897618 tx=370493 date=2016-08-11 02:55:27 progress=0.978356 cache=108387 My guess is that at some point there are too many orphan blocks to sort out and it becomes impossible to proceed. 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!
Good to hear! I think a roll back to 259200 would be fair. (At least, it would prevent having to choose a chain and associated disappointments) I'll stop digging through git and sleep. |
|
|
|
I am processing blocks very slowly and for every new block I get a reward.
I am on 261655.
getblockhash 261655
b187c860bf073423914955ed4ef35fe42135547446ecfa73dbc1dd4944caf088
lol getblockhash 261655 c90edb6fc9b9b5379293aa98dab394a6437e5ef5a0fafb9d3e8213b59dca7927 not good ..... just assume we on the right one and hes on the wrong one  Maybe we just post transactions on the forum and vote on who has the biggest stake.  $ darknet-cli getblockhash 261655 4eb4f0301155f55a64842e01bc7b59772eed45d5ec332a7518d488fc824eb308 All my active masternodes are on the same chain. Backup up ones wallet (to USB or another computer) is probably a good idea... Also, some of my masternode transactions had staked and therefore could not be found... so had to make new ones... |
|
|
|
./darknet-cli getblockhash 261426
0cc10649438a2f8fc5344e451e99fee5b74f052af0c035335d4b95a7ec8d19e4
Maybe moving along more smoothly now... $ darknet-cli getblockhash 261426
0cc10649438a2f8fc5344e451e99fee5b74f052af0c035335d4b95a7ec8d19e4
darknet-cli getblockhash 261438
2e4b035e4dbac8fbe769f386fb62aaa3cf1a52f5449ef6524ce0b7ecfd12dd66
$ darknet-cli getblockhash 261439
61779e01a466d4c342c86ba4565d7ff19cf6122010a0f586ae129565e3edde48
$ darknet-cli getblockhash 261445
0cf0a08e1a3733bd049cde235ecca91b79b843c09fe0f8f50b19c56922ba315b
|
|
|
|
which is the correct block that its up to. i am i on 261357 so is masternode payments page but you lot are higher? whos right?
Yeah, seems my controller wallet is ahead. I'll resync and report back. My MN's are on the right chain I guess then? (below) (same as MN page) getblockhash 261357 a45b5debbef34dfdd92bd8b84b8570ffda24eba7d330ae76a6923307f62e7ff7 The masternode payments page can also be wrong, or different, depending on what it's peers send it. |
|
|
|
which is the correct block that its up to. i am i on 261357 so is masternode payments page but you lot are higher? whos right?
I'm here... $ darknet-cli getblockhash 261356
c2ab07ddf0bdcc1e838844eecc416ced18aa36ecc27f85af1ac03964b4fdb3cb
$ darknet-cli getblockhash 261357
a45b5debbef34dfdd92bd8b84b8570ffda24eba7d330ae76a6923307f62e7ff7
$ darknet-cli getblockchaininfo
{
"chain" : "main",
"blocks" : 261357,
"headers" : 261412,
"bestblockhash" : "a45b5debbef34dfdd92bd8b84b8570ffda24eba7d330ae76a6923307f62e7ff7",
"difficulty" : 5004.24322926,
"verificationprogress" : 0.99980615,
"chainwork" : "0000000000000000000000000000000000000000000000000159f9e5aef1fc77" I'm here.
11:59:36

{
"chain" : "main",
"blocks" : 261382,
"headers" : 261397,
"bestblockhash" : "8c9cb46a6cb1a19cca6749aeed073ecbc2e249133d2a95cde3c142b0eb805e0a",
"difficulty" : 27942.13510120,
"verificationprogress" : 0.99908329,
"chainwork" : "000000000000000000000000000000000000000000000000016f01d01e17ed64"
}
What do you get for these blocks? darknet-cli getblockhash 261356 darknet-cli getblockhash 261357 I'm now here: darknet-cli getblockhash 261359 ff33c560ea23a62180fdd470ebacf7b2e20ef5e11b9093314bdbd2e1b5d15310 |
|
|
|
which is the correct block that its up to. i am i on 261357 so is masternode payments page but you lot are higher? whos right?
I'm here... $ darknet-cli getblockhash 261356
c2ab07ddf0bdcc1e838844eecc416ced18aa36ecc27f85af1ac03964b4fdb3cb
$ darknet-cli getblockhash 261357
a45b5debbef34dfdd92bd8b84b8570ffda24eba7d330ae76a6923307f62e7ff7
$ darknet-cli getblockchaininfo
{
"chain" : "main",
"blocks" : 261357,
"headers" : 261412,
"bestblockhash" : "a45b5debbef34dfdd92bd8b84b8570ffda24eba7d330ae76a6923307f62e7ff7",
"difficulty" : 5004.24322926,
"verificationprogress" : 0.99980615,
"chainwork" : "0000000000000000000000000000000000000000000000000159f9e5aef1fc77" |
|
|
|
Hopefully getting there... In case someone wants to compare or tell me I am on the wrong chain... $ darknet-cli getblockhash 260200
c6e2324f5baf1b8dfcc5feee9d2eb6db3481136da78b287b1b2c44ff68932e12
$ darknet-cli getblockhash 260209
c1a37179151fd5f44d08d06805e4d4087341eacdf5aaaef2553c69fca29c21d4
$ darknet-cli getblockhash 260250
427e740be5d6db1820d8d525211a032995f489c5ddad9b8a330de5aae74b1018
$ darknet-cli getblockhash 260300
e7de292ba59b816dd22b47a075b9553161d9782fab1ac55a90f4a4f20f2ef023
$ darknet-cli getblockhash 260350
fbf52102b5212406acb7a03f96accf53309b4bb4c59e09eeab41d3f15c1a86da
$ darknet-cli getblockhash 260391
caeb312a35155ff60bc9751b402cb13180139d05676382282fc09da35fcdce50 All on the wrong one. Would just ignore it till they fix it with new exe that this time will hopefully work. They need enable the masternode lock as well to stop us connecting to all the ones not updated. Thanks! Will just note I compiled from the latest commit: 9c46858, deleted everything except conf files, and restored a blockchain from before 70200 version masternodes and used the recommended peers from an earlier post. If we have an official or authoritative chain, it would be nice if someone could post hashes of block ending in 00 and perhaps blocks where people are getting stuck. |
|
|
|
Hopefully getting there... In case someone wants to compare or tell me I am on the wrong chain... $ darknet-cli getblockhash 260200
c6e2324f5baf1b8dfcc5feee9d2eb6db3481136da78b287b1b2c44ff68932e12
$ darknet-cli getblockhash 260209
c1a37179151fd5f44d08d06805e4d4087341eacdf5aaaef2553c69fca29c21d4
$ darknet-cli getblockhash 260250
427e740be5d6db1820d8d525211a032995f489c5ddad9b8a330de5aae74b1018
$ darknet-cli getblockhash 260300
e7de292ba59b816dd22b47a075b9553161d9782fab1ac55a90f4a4f20f2ef023
$ darknet-cli getblockhash 260350
fbf52102b5212406acb7a03f96accf53309b4bb4c59e09eeab41d3f15c1a86da
$ darknet-cli getblockhash 260391
caeb312a35155ff60bc9751b402cb13180139d05676382282fc09da35fcdce50 |
|
|
|
This is a wonderful work in progress.... There is another commit for the self builders out there, expect more until we get this work as it should. I had Bittrex Turn off their wallet again. So we can address the issues. Please Hang in there..
Please clarify, this is what I see at https://github.com/Darknet-Crypto/Darknet/tree/master
Latest commit db34f50 10 hours ago
Or is there something else coming...Just saw this... Latest commit 9c46858 2 minutes ago ... so github changes do not show up instantly... I haven't had much luck with this, I can't admit to having tried everything but I am eager to be among the first to get my masternodes up and running. Happy to see more fixes ... 259200 ... until one of the new peers is willing to connect... |
|
|
|
I have the older one, looks like the changes are necessary as there are a lot of warnings and errors in the logs after the PoW blocks end. Compiling.... Done ... Let's see... $ darknet-cli getblockhash 259880
f6bf9eae07bbba776309c374ef73b83bf633853b7026ceeff17e20ccd0774098
Yay!!! I am up to this block now... does anyone want to confirm I am on the right chain? darknet-cli getblockhash 260209 c1a37179151fd5f44d08d06805e4d4087341eacdf5aaaef2553c69fca29c21d4 Thought scripting everything would be overkill for the small amount of masternodes I have ( < 10 ) , but now considering it... At least I have clusterssh set up now... Time to set up masternodes... |
|
|
|
|
Would also be good to which is the valid version of software to run...
Looking at github, there the latest tag v2.0.1.0 which is at 922f368
and master has some other changes and is at db34f50.
Updating 922f368..db34f50
Fast-forward
src/kernel.cpp | 12 ++++++++----
src/kernel.h | 2 +-
src/main.cpp | 2 +-
Which is correct? Should the changes in master be used "in production". Maybe a new tag should be made... and the version increased so we can be sure we are on the right version.
Anyway, it's nice to see that a decision has been made about which chain is valid and which peers we should use.
|
|
|
|
self compilers can go, binaries will be up shortly, and everyone needs to update, like yesterday. Also a note regarding the possibility of unforeseen bugs, but let's get this chain moving. If users have staked they need to roll back to an old, pre-PoS blockchain backup, or do a resync
Let's go!! Ok, my masternodes have stopped here... darknet-cli getblockchaininfo
{
"chain" : "main",
"blocks" : 259494,
"headers" : 259494,
"bestblockhash" : "50c102c52f44c4220724c82e7eed1580e9da0874e0d9ea91984e130f511d20ba",
"difficulty" : 14.66822643,
"verificationprogress" : 0.99941685,
"chainwork" : "00000000000000000000000000000000000000000000000000dbc7d6a49e17a8"
}
My wallet is up to here: darknet-cli getblockchaininfo
{
"chain" : "main",
"blocks" : 259544,
"headers" : 259544,
"bestblockhash" : "bb5f320345e1ebc6fc66164c8ccfe6ed72225ce49e779c4b34dd50cba90377ab",
"difficulty" : 25.49310285,
"verificationprogress" : 1.00000000,
"chainwork" : "00000000000000000000000000000000000000000000000000dbcbe95b5b96e8"
} |
|
|
|
There is no point in writing a guide for a script at that level. It is meant to be used on a scale and work 99% automatically without input and any "schischi" as we say around here.
Run this script on a Ubuntu 16.04 vultr VPS and replace the masternode keys in the config files. There is nothing complicated to it, just give it a shot.
Can you explain how it works with multiple ips? How many ips does vultr give you? What spec would you need for it to work on however many vps you have running? Not sure about vultr... but you can have multiple IP#s on the same interface. As long as traffic for them is being route there by your service provider. If your service provider uses ipv6, you can easily and cheaply get more IP numbers. On my masternode hosts, I put several IP#s on my local interface "lo" and connect TOR to those local addresse.. Each Darknet instance darknet.conf will need a different setting for bind and rpcbind... For example can use 127.0.0.1 for masternode 1 and 127.0.0.2 for masternode 2 ... 127.0.0.254 if you have enough memory, cores and disk in one machine for that many masternodes. I'll post a guide for putting setting up masternodes with TOR soonish... Yeah, thats almost exactly how i would it. As soon as that is implemented by me, vultr is optional. I still highly recommend them as masternodes cause quite some traffic now and with my script you can install up to 5 masternodes on a 5$ / month vultr instance. I have a couple old machines in the basement... now I split the instances across a few VMs. I think each instance need about 100meg RAM. So with 1 Gig, 7-8 masternode might be doable if the extra services are kept to a minimum. By the way, nice script that you posted, clearly trying to do things the right way... |
|
|
|
There is no point in writing a guide for a script at that level. It is meant to be used on a scale and work 99% automatically without input and any "schischi" as we say around here.
Run this script on a Ubuntu 16.04 vultr VPS and replace the masternode keys in the config files. There is nothing complicated to it, just give it a shot.
Can you explain how it works with multiple ips? How many ips does vultr give you? What spec would you need for it to work on however many vps you have running? Not sure about vultr... but you can have multiple IP#s on the same interface. As long as traffic for them is being route there by your service provider. If your service provider uses ipv6, you can easily and cheaply get more IP numbers. On my masternode hosts, I put several IP#s on my local interface "lo" and connect TOR to those local addresse.. Each Darknet instance darknet.conf will need a different setting for bind and rpcbind... For example can use 127.0.0.1 for masternode 1 and 127.0.0.2 for masternode 2 ... 127.0.0.254 if you have enough memory, cores and disk in one machine for that many masternodes. I'll post a guide for putting setting up masternodes with TOR soonish... |
|
|
|
Meanwhile on Bittrex, someone bought all the sell orders up to 800 sat. (Approx. 210K of DNET)
The current plan for the reduction in block rewards makes the next few months a good time to be running masternodes and staking. Let's hope there is the next few months adoption of DNET for than just for trading and speculation. So is it ok to use the master release from github? Are we there yet? :-) |
|
|
|
|
Show Posts
