My wallet node was up to block 259390... on whatever chain...
My masternodes seem to be happily waiting at 259200 with "status" : "Masternode successfully started".
Any suggestions from the devs about what to do with currently running masternodes or what will be likely necessary steps one should take when the fix is ready?
Anyway, it is nice to see some action in github indicating a solution is in the works.
|
|
|
I looked at half of my masternodes, which I haven't restarted since upgrading to the latest version... they aren't really stuck, but are behind. Running getinfo shows 259200 on all of the masternodes while my controller / wallet / staking node :-) is at 259279. I'll let the masternodes chug along... Hopefully, the only problem is what is being displayed, while the blockchain marches on. What is interesting is that the peers, mostly show that they are on 259200 also. Controller: darknet-cli getpeerinfo |grep synced_headers "synced_headers" : 258773, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, A masternode: darknet-cli getpeerinfo |grep synced_headers "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259250, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : 259265, "synced_headers" : 259200, "synced_headers" : 259200, "synced_headers" : -1, Definitely, there are some issues to be addressed. I am optimistic that it is problem is mostly with what the cli reports. Looking at the PoS reward schedule and current Masternode reward, I think investing in a few more masternodes is not a bad ides.
|
|
|
I have noticed some weird behavior with the new wallet. It says it is up to date, but it get stuck on a certain block.
I am seeing this on my controller wallet and masternodes. "chain" : "main", "blocks" : 254640, "headers" : 257855, "bestblockhash" : "000000000037bce3960f9bc044c2ce8f2840d046b86699b21dc47f019e048508", "difficulty" : 110.31885163, "verificationprogress" : 0.98450540, "chainwork" : "00000000000000000000000000000000000000000000000000d7309beadd7bfd" }
The headers stays up to date, but the blocks stays stuck at whatever block the chain was on when I started the daemon/wallet. I noticed this because when I receive transactions, they would never show as confirmed. I have to force my wallet to rescan the blockchain to get it up to the latest block.
My masternode controller / wallet was stuck too... (peers connected but transactions not updating). For me it was enough to restart the daemon. Not sure if it is stuck again. I am now at block 258951. I haven't looked at the masternodes yet. Ok, restarted and up to 259127. Happy PoS everyone!
|
|
|
Wow.. You don't like my OP heh.. Haha. I accidently deleted my conf files and need to copy the node list from the OP. I couldn't copy as it's not in text format. So it was a pain typing them up myself. So did I, twice... fortunately, I still had .darknet/darknet.conf~
|
|
|
I just updated my masternodes... given that this one is a bit more complicated because the the blockchain needs to be resynced and some database files need to be deleted I made some notes to speed up the process for myself, the someone here surely will find them helpful. Read through everything before starting to copy paste... this works for me, your setup may differ. Build the latest version ... I assume you already have an old version in git Your configuration options or paths may differ. Probably also a good time to and and so I haven't mentioned stopping your currently running masternode daemons. $ cd git/Darknet/ $ ./autogen.sh $ ./configure $ make clean $ make -j4 $ cd src/ $ tar zcvf ~/dnet.tar.gz darknet-tx darknet-cli darknetd
Copy the to the machine(s) running your masternode(s) and unpack it over your current executables Preparation... on a working node running the latest dnet (you need to at least delete some files in the .darknet dir ... and start a dnet nodes with the latest version) Stop the node before tarring!! $ darknet-cli stop $ tar zcvf dnet_base70200.tar.gz .darknet/blocks/ .darknet/peers.dat .darknet/chainstate/ .darknet/budget.dat .darknet/mncache.dat
copy this file to each machine that has masternodes to be updated: Updating a masternode: $ cd .darknet $ rm -r fee_estimates.dat mncache.dat mnpayments.dat budget.dat chainstate blocks peers.dat $ cd .. $ tar zxvf /tmp/dnet_base70200.tar.gz $ darknetd $ watch darknet-cli masternode status
When your masternode is waiting for activation run the following on the masternode controller... $ darknet-cli masternode start-alias abc123 Check that your masternode is "status" : "Masternode successfully started" and move on to the next one... If you found this helpful and you are so inclined, a small gift to this address will go towards my next masternode or beer (in which case it will be traded to BTC which will be used to pay for beer.) D8zVCiBSRehy2xR4tfaapjz75BYAyg2tAH
|
|
|
Seems that there are a lot of orphan blocks. Generating load on the CPU... Here's my daemon version. "version" : "v3.6.0.0-UT-ZAH-HA-DEZ-BIN", "protocolversion" : 61400, "walletversion" : 60000,
2016-08-02 18:31:41 ProcessBlock: ORPHAN BLOCK 6148, prev=8f9b3f86c7191f4d6cb01531c661b499f404c95aded1188796c7d8ae7f9fe831 2016-08-02 18:31:47 ProcessBlock: ORPHAN BLOCK 6149, prev=5f671dd3048f17192b2f0303ed167326429cd98ac1d3f80714d6bd6359739be5 2016-08-02 18:31:55 ERROR: CheckProofOfStake() : INFO: read txPrev failed 2016-08-02 18:31:55 ERROR: AcceptBlock() : check proof-of-stake failed for block 5098b23c92fc9eec6a8fa4a1036aadc8d5d22f9ac3251576f26365213f88c40b 2016-08-02 18:31:55 ERROR: ProcessBlock() : AcceptBlock FAILED 2016-08-02 18:31:55 ERROR: CheckProofOfStake() : INFO: read txPrev failed 2016-08-02 18:31:55 ERROR: AcceptBlock() : check proof-of-stake failed for block 5098b23c92fc9eec6a8fa4a1036aadc8d5d22f9ac3251576f26365213f88c40b 2016-08-02 18:31:55 ERROR: ProcessBlock() : AcceptBlock FAILED 2016-08-02 18:31:55 ERROR: CheckProofOfStake() : INFO: read txPrev failed 2016-08-02 18:31:55 ERROR: AcceptBlock() : check proof-of-stake failed for block 5098b23c92fc9eec6a8fa4a1036aadc8d5d22f9ac3251576f26365213f88c40b 2016-08-02 18:31:55 ERROR: ProcessBlock() : AcceptBlock FAILED 2016-08-02 18:31:55 ERROR: CheckProofOfStake() : INFO: read txPrev failed 2016-08-02 18:31:55 ERROR: AcceptBlock() : check proof-of-stake failed for block 5098b23c92fc9eec6a8fa4a1036aadc8d5d22f9ac3251576f26365213f88c40b 2016-08-02 18:31:55 ERROR: ProcessBlock() : AcceptBlock FAILED 2016-08-02 18:31:55 ERROR: CheckProofOfStake() : INFO: read txPrev failed 2016-08-02 18:31:55 ERROR: AcceptBlock() : check proof-of-stake failed for block 5098b23c92fc9eec6a8fa4a1036aadc8d5d22f9ac3251576f26365213f88c40b 2016-08-02 18:31:55 ERROR: ProcessBlock() : AcceptBlock FAILED 2016-08-02 18:31:57 ProcessBlock: ORPHAN BLOCK 6150, prev=47ad059bb122b0b9131e7bbebb30ca5daa64296a110ef4b66570eb6040bac924 2016-08-02 18:32:02 connect() to 191.134.83.91:44440 failed after select(): Connection refused 2016-08-02 18:32:02 keypool reserve 46 2016-08-02 18:32:02 keypool return 46 2016-08-02 18:32:10 ProcessBlock: ORPHAN BLOCK 6151, prev=970ce4fb315fb2a53650f940e3825fe272640200762f2568544efece396ab7b2 2016-08-02 18:32:12 ProcessBlock: ORPHAN BLOCK 6152, prev=2eff24e3984afbfa4098d9c3946b94cc0e3a7d04d39f4f5ad42553b562b20c98 2016-08-02 18:32:12 ProcessBlock: ORPHAN BLOCK 6153, prev=1154c004230465123d3cd33882452b9d1fa12be31e957e2aff28e95d2746c09c 2016-08-02 18:32:12 ProcessBlock: ORPHAN BLOCK 6154, prev=e26a295d2ece6c51fb4f51f29aa0291cfbaf54015550982a68486cb010a606a0 2016-08-02 18:32:12 ProcessBlock: ORPHAN BLOCK 6155, prev=d54dc78e10576b1184984d47f68bc1e86ce4f1300e3c4bacc59bac3ed5fa8485 2016-08-02 18:32:16 ProcessBlock: ORPHAN BLOCK 6156, prev=e4821d1c167e59b84ec10981e9694c22aab9d07d1b20448ad781f2b381f29b1b
|
|
|
It's closing so if you have anything there, time to login and cash out!
I had received an email from the ticket system (in Chinese but with at least two words in English, one of them being closing). Do check the withdrawal limits. I needed to deposit a small amount of BTC to meet the 0.01 Withdrawal limit. After that I had no problems moving my various coins out.
I signed up a few months ago when I saw a small arbitrage opportunity. The there were many things that didn't work initially but my tickets we answered typically within a day and things started working. Unfortunatly, there was rarely enough volume or reasonable orders or bids for most coins to make the the exchange interesting.
|
|
|
It's closing so if you have anything there, time to login and cash out!
I had received an email from the ticket system (in Chinese but with at least two words in English, one of them being closing). Do check the withdrawal limits. I needed to deposit a small amount of BTC to meet the 0.01 Withdrawal limit. After that I had no problems moving my various coins out.
I signed up a few months ago when I saw a small arbitrage opportunity. The there were many things that didn't work initially but my tickets we answered typically within a day and things started working. Unfortunatly, there was rarely enough volume or reasonable orders or bids for most coins to make the the exchange interesting.
|
|
|
Since yesterday my shift wallet don't want to sync. How to fix it? Thanks in advance
Here are a couple commands to add nodes manually. Sometimes, problems with NAT or Firewall can cause connectivity problems. Try pasting each line, separately into the gshift command line. admin.addPeer("enode://4c8635f108dae8a997697d9c22ddca36969e7f9bc57d9fc01102d7e7d9633231331ae7f7307aceb1aa19130b5bdd4afe397db616c76e7ffc1c69302ba0d09a39@45.32.182.61:53900")
admin.addPeer("enode://f019da062a635a4e9e89ec93edc7ca11c06fdfec0574f1cb001126a82dc6ffa6ca05f924a683934ff5d01fc5d4b0ac9507349a945c97121b2a355d39b1781cd7@104.238.157.156:53900") thanks, but i can't write in gshift. What else i can try How do you start gshift? You can start it with the command at the end of the line.... or in another terminal run . If your computers clock is too fast or too slow, this can also cause problems with finding peers. If you are running Linux I suggest installing ntp. For windows. http://windows.microsoft.com/en-us/windows/set-clock#1TC=windows-7Please confirm if you had trouble with the clock and also if that solved the problem.
|
|
|
Since yesterday my shift wallet don't want to sync. How to fix it? Thanks in advance
Here are a couple commands to add nodes manually. Sometimes, problems with NAT or Firewall can cause connectivity problems. Try pasting each line, separately into the gshift command line. admin.addPeer("enode://4c8635f108dae8a997697d9c22ddca36969e7f9bc57d9fc01102d7e7d9633231331ae7f7307aceb1aa19130b5bdd4afe397db616c76e7ffc1c69302ba0d09a39@45.32.182.61:53900")
admin.addPeer("enode://f019da062a635a4e9e89ec93edc7ca11c06fdfec0574f1cb001126a82dc6ffa6ca05f924a683934ff5d01fc5d4b0ac9507349a945c97121b2a355d39b1781cd7@104.238.157.156:53900")
|
|
|
Hi guys. I have money in change addresses I want to move it all to a single address in the wallet do I just sweep the keys? Have had a look but read some conflicting info on this process to thought better best to ask.
thanks
This might be handy if you need to send between your own wallets from the command line. eth.sendTransaction({from:eth.accounts[2], to:eth.accounts[3], value: web3.toWei(1, "ether")}) Check the account address with: And balance with: web3.fromWei(eth.getBalance(eth.accounts[0]), "ether") List all accounts
|
|
|
developer, there is a problem ether core work through the same port 41303 and turns the conflict with purses and GETH. simultaneous operation of 2 wallets impossible
I think Ethereum uses 30303. Anyway, the server could be bound to a different IP# (or run on a different host if there is a port conflict, though I think running p2p on a "non-standard" port should be ok). RPC for the wallet should be possible on any port >=1024... Or lower if you like to run geth as root. :-) right, Ethereum's Geth uses port 30303 as Uther's uses 41303, so the Geths should run at the same time without conflict. Etherwallet uses IPC(internal process connection) . If they have conflict ,maybe they share the same setting, i will have a look at it. I wouldn't recommend it, especially not for productin but I suppose the same executable could be used for both Ethereum and Uther assuming separate data directories, correct genesis blocks and non conflicting ports are configured on the command line.
|
|
|
What you do with BTC?Buy/Sell Altcoins on Exchanges Accept payment (have worked for bitcoin) Used to Mine a little Where you spend?Restaurants, Bars Online shops ( Typically Vape, Computer Hardware ) Where you sell BTC ?For cash: LocalBitcoins.com Where you buy BTC ?With cash or bank LocalBitcoins.com , Gatecoin , ATM, In person
|
|
|
developer, there is a problem ether core work through the same port 41303 and turns the conflict with purses and GETH. simultaneous operation of 2 wallets impossible
I think Ethereum uses 30303. Anyway, the server could be bound to a different IP# (or run on a different host if there is a port conflict, though I think running p2p on a "non-standard" port should be ok). RPC for the wallet should be possible on any port >=1024... Or lower if you like to run geth as root. :-) Listening on [::]:41303 I0530 19:16:42.753877 github.com/uther/go-uther/core/blockchain.go:565] Chain manager stopped I0530 19:16:42.759378 github.com/uther/go-uther/eth/handler.go:200] Stopping ethereum protocol handler... I0530 19:16:42.763379 github.com/uther/go-uther/eth/handler.go:221] Ethereum protocol handler stopped I0530 19:16:42.766879 github.com/uther/go-uther/core/tx_pool.go:163] Transaction pool stopped I0530 19:16:42.769879 github.com/uther/go-uther/eth/backend.go:496] Automatic pregeneration of ethash DAG OFF (ethash dir: C:\Users\MiningRIG_1\AppData\Ethash) I0530 19:16:42.775380 github.com/uther/go-uther/p2p/nat/nat.go:111] mapped network port tcp:41303 -> 41303 (ethereum p2p) using NAT-PMP if it launched ether wallet, if the air switch on and run it, he sees uther coins)) I'm not sure about the latest release but in the first release the Genesis block needs to be set when starting for the first time. ./geth --genesis uther-genesis.json console It's mentioned in the first post. (I'm still running Geth/v1.3.6 so can't say if it works on the right chain from a fresh install with 1.4.4) Also the enode mentioned in the thread should speed up syncing... Looks like the only one mentioned in this thread is from ocminer which is also Geth/v1.3.6. Would be nice if the dev published an enode... admin.addPeer("enode://96af71904742ab9cf73af953968aafe16852d2586f399165c0d4e82e6a751182901f0a3ba9be8aa64a0b51247b4ba98ef2b7bf4c98be5ab8b497288e6ef3e857@37.59.24.15:41303")
|
|
|
developer, there is a problem ether core work through the same port 41303 and turns the conflict with purses and GETH. simultaneous operation of 2 wallets impossible
I think Ethereum uses 30303. Anyway, the server could be bound to a different IP# (or run on a different host if there is a port conflict, though I think running p2p on a "non-standard" port should be ok). RPC for the wallet should be possible on any port >=1024... Or lower if you like to run geth as root. :-)
|
|
|
just be strong shift holders, this project has big potential and the dev team is working hard from what i know. at 8 million coins shift will go full pos and from those 8 million there are 2 million coins for development and community fund. its amazingly rare and the price is really cheap in my opinion. but thats crypto and for that i love it:)
The recent Lisk release and uncertainty about the effects of the upcoming block reward halving for BTC have put a lot of pressure on the price of many of the other coins. It's also good to think about prices in terms of fiat. BTC/USD is about 23% up in a week (440 to 540 USD). Shift is at 0.00004062 now and was 0.00005240 a week ago. It's about 35% down in terms of BTC, but in terms of USD only about 5% down.
|
|
|
Here's my current status $ TZ=GMT date ; date +%s ;darknet-cli getblockchaininfo Sat May 28 15:27:57 GMT 2016 1464449277 { "chain" : "main", "blocks" : 161842, "headers" : 161842, "bestblockhash" : "0000000006cf86ada52c3a0016d2d1d870567ef39bd387b1a510d5a63f721f19", "difficulty" : 10.85730668, "verificationprogress" : 0.99999162, "chainwork" : "00000000000000000000000000000000000000000000000000b1084236467415" }
|
|
|
I wonder who is watching the situation in the market, how much is bought and sold coins 2 Weeks had repurchased approximately 4m coins back into the market, they did not come back up for sale. as it is known that at present all the coins 7,25m. purses Developer 3m coins on the market now 750-800k. And now the most interesting - the 4th of coins were purchased, if someone watched a very interesting, but it appeared on the stock exchange volume dramatically and he bathed at than before in a glass of this volume did not exist. What kind of coins are traded on the market Insightful analysis, currently I see 739772.914 SHIFT up for sale, The top 6 balances (all > 100k each) total about 2123 kSHIFT. There was a site with archives of the top wallets for various coin on bittrex. I'll post the link when I find it unless someone beats me to it.
|
|
|
If the guy's that are pumping and dumping stops that only means price is to low to mine it. But as for myself still hold more than 180,000 shift waiting for the price to get back up past 10,000 again. And I stoped mining shit a few days ago Due to issues with Windows 10 and my AMD r390x's crashing every 30 second's
No problems with other coins? I asked some questions a couple days ago in this post and would like to know if your problems are specific to shift. https://bitcointalk.org/index.php?topic=1155284.msg14898274#msg14898274-Mike No it was due to Drivers and issues with Windows 10 working with my AMD r390x's .Seems to be issues with AMD 390x's running on windows 10 .I have four Rigs mining Three of my rigs Have four PowerColor Devil 390x in each of them my other rig is running 4 R390's and it's working fine .It's only my rig's with the 390x's in them that are having issues fixed it by going back to window's 7. All is fine now Great that you have found the problem! Happy mining!
|
|
|
|