flicking through using the ipv6 on vultr option i think i have it sorted just wondering how you do ./darknet-cli getinfo for all of them? I found the exe in cd /var/lib/ but it does not accept commands and gives error You must set rpcpassword=<password> in the configuration file: /root/.darknet/darknet.conf If the file does not exist, create it with owner-readable-only file permissions. i have done that for the 5 that are on there any help appreciated You could run ./darknet-cli -rpcconnect=IPNUMPER -rpcuser=masternodeusername -rpcpassword=yoursecurepassword getinfo I assume you are running this from within your masternode's server... You might need to set "rpcallowip=" to allow you to connect from wherever you are trying to connect to. It's prudent to set rpcallowip to only allow internal connections. (best to firewall all unnecessary ports). RPC could be used over ssl, but I suppose this could be used to generate extra load on the server if left open, and worse is possible if you use easily guessable usernames and passwords. |
|
|
|
guys, please leave this fucker alone - just ignore him.
Let's concentrate on how to defend SHF against such fuckers in the future.
SHF has a great true-blue dev team, growing community that truly consolidated after this shitty event, and the real product itself that is really awesome. So... what we can do for rock'n'roll now? How to bring back SHF to the right rails?
First time using "Ignore"   |
|
|
|
We just burned the 60k at block 279917.
If you look at the Total Coins in the previous block, you will see that this block is 60k less. The coins were sent as a network fee which are destroyed.
But why network fee was destroyed and not given to miner? Yes, at the change to PoS, network fees are now destroyed. Though it is fractional, it does help overtime with inflation, and now we can remove coins from the total coin cap if needed...  instead of having them just sit there at an address somewhere. Thats how burning coins should work.. I guess the "any 60k" was burned even though a significant number of forum members voted for the original. Original 60k  20 (31.3%) Any 60k  44 (68.8%) Total Voters: 64 I suppose no one here is interested in having any more forks.  Not entirely sure what you are implying, but there was a vote, and we did what the vote said. I am happy that 60k coins were burnt. I understand that finding transactions containing the initial 60k premine for the masternodes would be more work and would need a more complex transaction to burn them than what was carried out. Whatever decisions are made, or whatever is done, not everyone will be happy. While proposals might be described and discussed in bitcointalk. I think the decision to stray from the original plan should have been formalized with a proposal and vote. In the case of a crisis, security incident, etc. it could be acceptable for the developers make changes that need to be done quickly. There is no way for the poll to reflect the share of masternode voters. I think that this is why we have this masternode based proposal and voting system. Seeing that the system is not being used reduces its credibility. In my understanding it was an informal poll (unless I missed a message explaining it), which indicated that for 20 out of 64 who participated, It mattered which coins were burnt. Votes are not always decided based on 50% majority. Enough, that it could be discussed further... and a decision to stray from the initial plan, it could be formalized by a proposal and vote. As for the comment about the fork, this is definitely a small issue. There is not much at stake and no change in the intended supply of DNET. The Ethereum hard fork and Ethereum classic is a good example of what can happen when there is a lot at stake and when differences in principles. |
|
|
|
We just burned the 60k at block 279917.
If you look at the Total Coins in the previous block, you will see that this block is 60k less. The coins were sent as a network fee which are destroyed.
But why network fee was destroyed and not given to miner? Yes, at the change to PoS, network fees are now destroyed. Though it is fractional, it does help overtime with inflation, and now we can remove coins from the total coin cap if needed... instead of having them just sit there at an address somewhere. Thats how burning coins should work.. I guess the "any 60k" was burned even though a significant number of forum members voted for the original. Original 60k  20 (31.3%) Any 60k  44 (68.8%) Total Voters: 64 I suppose no one here is interested in having any more forks. |
|
|
|
|
First payment for my newest masternode just came.
Less than 41 hours after starting it.
|
|
|
|
Cool. I used your option 4 to get the CLI working but got this message. darknet-cli -rpcport=4441 -rpcuser=xxxxxx -rpcpassword=xxxxxx -conf=etc/masternodes/darknet_n1.conf masternode status
error: couldn't connect to server So I checked debug log and found this: (I masked the IP) 2016-09-01 00:01:04 Unable to bind to [2001:xxxx:xxxx:1a7::1]:9999 on this computer (bind returned error Cannot assign requested address (99))
2016-09-01 00:01:04 Error: Failed to listen on any port. Use -listen=0 if you want this.
2016-09-01 00:01:04 PrepareShutdown: In progress...
That's the IP that was pre-filled by your script to /etc/masternodes/darknet_n1.conf Any ideas? (I did tick the IPv6 option when I deployed this Ubu 16.04 server on Vultr) Haven't played with ipv6 much myself, but the first thing to check would be running "ifconfig" (if you use debian it is not in the path if you are not root so then you need to run "/sbin/ifconfig". Check that the range of ipv6 addresses you are using exists and is bound to an external interface for your host. Your service probider hopefully has some documentation. If not, I think Digital Ocean might have some documentation that you could adapt. |
|
|
|
|
I set up another masternode recently, and the transaction shows "walletconflicts".
The masternode is up, ENABLED and Successfully started, so I guess things are ok.
Could this affect staking? Should I resync my wallet? Would the txid information and logs
be of interest to the developers?
|
|
|
|
I have just set up a DNET MN and it's been running for around 36 hours and no payments yet. What's the best way to monitor the MN and make sure it's running correctly? Is there a site like for DASH where you can monitor masternodes?
Probably running " darknet-cli masternode status" on the masternode is best. Should show "status" : "Masternode successfully started" And seeing that the masternode is up to the latest block and has peer connections: run " darknet-cli getinfo" and check blocks and connections. I have noticed that my peers are often a bit ahead of the monitor here: http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.htmlI've also noticed, sometimes a masternode gets a bit behind for a few minutes, but usually it resolves itself. Checking the peers and adding a couple more can help. |
|
|
|
If the dev isn't around, maybe it's time for the community to discuss developing this further. Vote for TRBO on cryptofolio so you can monitor your millions! http://cryptofolio.info/welcome/vote |
|
|
|
I also see a lot of people who are still running the old wallets/masternodes, might want to update soon..
Any tips for restarting current masternodes with the latest version so that one doesn't need to restart them from the controller. With things being stable with my masternodes I'd rather wait for the next mandatory update or significant drop in reward than have my masternodes wait for a 1-2 days for the next payments. the timeout period is approx 60 minutes, so as long as you have you masternode restarted and running from the masternode side you should be fine. Good to know... I guess, I had relied a bit too much on the information the controller shows, and perhaps run .... masternode start-alias prematurely. Will try... |
|
|
|
What is going on? The 'maintenance' of 24 hours on Bittrex is turning into 2 days now?? This is not looking good. I also had 100 Shift mined from a pool sent to Bittrex...they aren't in the pool, and they aren't in Bittrex....but it shows they were sent somewhere...wonder where?? I think if the team doesn't get this under way, selling will start...also, I'm wondering if this is not just an issue with Shift, but with Bittrex..as Krypton has been down too for the same amount of time...I have 'lost coins' in no man's land supposed to be in Bittrex from a pool there too...nothing..nowhere...not on the pool, or Bittrex...thank goodness, not many.
the coins aren't missing, when Bittrex is done their maintenance the coins will show up in your Bittrex wallet until then it'll show your old balance, which seems to be pretty standard, but then again you never know, I haven't got a clue what the hang up is usually it's a few hours, but Krypton too? odd. but they did tweet that it would be up to 24h. If you follow Shift's github repo ( https://github.com/shiftcurrency/shift), it clear that the developers are making an effort to keep up to date with relevant patches in the Ethereum code. The state of other coins is possible to determine if you check their source repositories... For coins that follow Ethereum's version numbers scheme, comparing that to Ethereum's recent stable version could be a good gauge of efforts to maintain the code. (for example the output of admin.nodeInfo ) |
|
|
|
I also see a lot of people who are still running the old wallets/masternodes, might want to update soon..
Any tips for restarting current masternodes with the latest version so that one doesn't need to restart them from the controller. With things being stable with my masternodes I'd rather wait for the next mandatory update or significant drop in reward than have my masternodes wait for a 1-2 days for the next payments. |
|
|
|
Have been on miners-zone since the beginning when not mining solo. :-) |
|
|
|
|
Ok... running DarkNet Core:2.1.2 ...
A couple masternodes ended up being out of sync for a while... behind 100+ blocks and
showed up from the controllers point of view as missing / expired.
I suppose leaving them, things would have fixed themselves. I connected a couple of
working masternodes to the "stuck" peers with addnode ..... onetry... and the nodes
came back into sync in a few minutes. (and show up as ENABLED from the controller.
|
|
|
|
Fun fact: Didnt upgrade yet, but no crashes anymore on either side Me neither. Don't plan to unless necessary. |
|
|
|
We are trying to research the issue with corrupting and crashing wallets.
Is anyone having issues with Wallets crashing, that is NOT using that wallet to run a masternode (either local or remote masternodes). Just staking??
My wallet is running great, it only crashed on that wallet version that was corrupting wallet.dats. but I'm not running any masternodes and I haven't staked once but that's probly because my stake weight is in the negative, I have managed to get back 431 coins though lol! I just spent several hours trying to recover my coins, pretty sure they got orphaned during one of the forks. Since the wallet is defaulted to back itself up alot I had probly 40 back ups, I checked the dates on Bittrex then found all of the back ups from the day before, the day of, and the day after the transactions went out, imported a shit ton of .dats in hopes that one of them would have the private key for one of the address that I was using to withdraw but no deal, how that one address is the only one I don't have the key to and all of my small test transactions came through on another address but none of the big transfers is puzzling. So I have issues with 2 addresses, one that shows up on the block explorer but the private keys are mia and another that the big transfers aren't on the Explorer, only record is on my Bittrex account. So anyhow got the wallet completely rebuilt, all of the labels sorted out and sent a few coins from Bittrex, finally at least everything's working, but I'm not going to get too comfortable because it was all working before and confirmed in my wallet then poof got all forked up 08/10/2016 DNET 4732.27123882 Completed . Address: DPAeb34bEZ9FfBh8Qt391UmHNhZWdzL27q TxId: b1a48c0214460ab94b5e46d2ef1e411a35213eab9277ee090d20841a4f9ab8c0 That's the one that only the small txs stuck, if someone has an urge to do some Scooby-Doo business there you go If anybody has any ideas I'm open for suggestions, ive literally tried everything I'm pretty sure. For now I gotta chill for a bit, that was exhausting These might be a good start... ( it may be a bit of work to find the right numbers to modify this for DNET, and could depend on the format of the wallet but when you do you can extract all the keys, from wallet, used and unused). Could someone who knows more comment please? https://gist.github.com/msm595/7595164https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-MappingsOh sure...lemme just open this can of worms real quick hahaa, thanks for the links though seriously. Im not even that concerned about it working now, I think digging into all of that will be cool regardless of the end result. I did try salvage wallet also, unfortunately it didn't work. Wallet had a salvaged title or some thing. It will be educational at least... I had some old wallet backups that I thought might have a a fraction of a peercoin that didn't work. No peercoins left there but did manage to restore my transaction history. There were two numbers to tweak in order to get valid addresses and keys. |
|
|
|
We are trying to research the issue with corrupting and crashing wallets.
Is anyone having issues with Wallets crashing, that is NOT using that wallet to run a masternode (either local or remote masternodes). Just staking??
My wallet is running great, it only crashed on that wallet version that was corrupting wallet.dats. but I'm not running any masternodes and I haven't staked once but that's probly because my stake weight is in the negative, I have managed to get back 431 coins though lol! I just spent several hours trying to recover my coins, pretty sure they got orphaned during one of the forks. Since the wallet is defaulted to back itself up alot I had probly 40 back ups, I checked the dates on Bittrex then found all of the back ups from the day before, the day of, and the day after the transactions went out, imported a shit ton of .dats in hopes that one of them would have the private key for one of the address that I was using to withdraw but no deal, how that one address is the only one I don't have the key to and all of my small test transactions came through on another address but none of the big transfers is puzzling. So I have issues with 2 addresses, one that shows up on the block explorer but the private keys are mia and another that the big transfers aren't on the Explorer, only record is on my Bittrex account. So anyhow got the wallet completely rebuilt, all of the labels sorted out and sent a few coins from Bittrex, finally at least everything's working, but I'm not going to get too comfortable because it was all working before and confirmed in my wallet then poof got all forked up 08/10/2016 DNET 4732.27123882 Completed . Address: DPAeb34bEZ9FfBh8Qt391UmHNhZWdzL27q TxId: b1a48c0214460ab94b5e46d2ef1e411a35213eab9277ee090d20841a4f9ab8c0 That's the one that only the small txs stuck, if someone has an urge to do some Scooby-Doo business there you go If anybody has any ideas I'm open for suggestions, ive literally tried everything I'm pretty sure. For now I gotta chill for a bit, that was exhausting These might be a good start... ( it may be a bit of work to find the right numbers to modify this for DNET, and could depend on the format of the wallet but when you do you can extract all the keys, from wallet, used and unused). Could someone who knows more comment please? https://gist.github.com/msm595/7595164https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings |
|
|
|
|
I haven't had problems with the exception of the chain being stuck... once. (Same block
as everyone else...) My masternodes didn't need to be restarted for this. I started my
controller with a pre-PoS wallet.dat backup and masternodes with new wallet files. I can't say for
sure, but I don't I have had to restart masternodes with this version.
(Darknet Core Daemon version v2.1.2.0-ef94980). The wallet, I have restarted... usually due to
rebooting.
With all the restarting due to new versions, being stuck on forks, it's likely all the remaining
wallets in the backup dir could all be corrupted... cause problems... since the default
number of backups to keep is 10.
$ darknetd -? |grep backup
-createwalletbackups=<n> Number of automatic wallet backups (default: 10)
Corrupted is proably not be the best word, as it's likely that all the keys can be extracted, but
anyway, having something that causes problem for the dnet software or berkeley database
library.
Backing up the backup wallet directory every now and then would be prudent.
(As well as keeping track of the versions of Berkeley DB used... if you don't use version 4.8 )
Note, that the Berkeley DB version, should not be a concern to most. To use a different version
one would need to compile darknetd oneself and specify that you are not using 4.8 with
./configure --with-incompatible-bdb.
I am far from being an expert in wallet.dat files and databases, but when I have run into syncing
trouble or wallet database problems in the past with other coins. It has often been something
to do with a mismatched DB library version or with a the database not being shut down cleanly
(software crash, system crash, ungraceful shutdown).
I suspect there will not be any new fix for those who are still having problems in the next darknet version.
Out of curiosity, has anyone tried "-salvagewallet" (please back up first).
|
|
|
|
|
Show Posts
