Someone else had problems with bgfminer and furys not connecting to p2p pools (saying the pool is hiding block contents from the user) and tried with Cryptopool mining but after 5 min my hashrate disappear from the dashboard (i can see it in my workers page). But everything seems to work fine on blazinghashes.com
Thanks for letting us know! The network is almost up to 6 GH! Lets get to 10 GH & get to the switch-over in a couple days! I have put what i can't toward the network, wished i could do more. I have 2 asics running specifically for DGB (hope to make it bigger soon). Awesome! Thank you for contributing! And thank you to everyone else who is helping out! We are almost at 7GH right now! Woohoo! |
|
|
|
Someone else had problems with bgfminer and furys not connecting to p2p pools (saying the pool is hiding block contents from the user) and tried with Cryptopool mining but after 5 min my hashrate disappear from the dashboard (i can see it in my workers page). But everything seems to work fine on blazinghashes.com
Thanks for letting us know! The network is almost up to 6 GH! Lets get to 10 GH & get to the switch-over in a couple days! |
|
|
|
I've been away on "summer vacation" and I've only had opportunity enough to check in once in a while to read and stay more or less up-to-date, and since I'm going to be extremely pressed for time in the coming weeks (paying for that vacation, LOL), the only thing I have time to say (and that is really worth saying) right now is: DigiByte's Community Is Awesome! You guys are tops! And you know I'm not just saying that. +1 The DigiByte community does rock! We are at 4700 MH & have pushed past block 143k! Thank you to everyone who is donating hash! May a plethora of DigiBytes rain upon your gracious souls!  Just spent an hour on the phone with the 1&1 support staff. They migrated the DigiByte servers to a new data-center. The site was supposed to be offline for no more than 30 minutes. 8 hours later it is finally back online. |
|
|
|
Side note for folks using Coinbase: Coinbase Names Aon as its Bitcoin Insurance Broker
Nermin Hajdarbegovic | Published on August 28, 2014 at 13:28 BST
UPDATE (28th August 15:00 BST): CoinDesk has reached out to Coinbase for clarification on whether the company’s policy excludes bitcoin held in cold storage (offline wallets).
Aon insurance headquarters
Coinbase has revealed that its users’ online wallets are being insured through top broker Aon.
The news came in a surprise blog post in which the company announced it has been insured against the theft or loss of bitcoin since November 2013, stressing that its users are not being charged for the cover.
The wallet and merchant services provider said it teamed up with Aon, one of the world’s largest insurance brokers, to further protect its users’ bitcoin funds.
Aon uses underwriters with high credit ratings, Coinbase explained, such as an Standard & Poor’s rating of ‘A+’ or AM Best rating of ‘A XV’ or higher.
Protected against theft and hacking
The company said its policy provides sufficient insurance to cover the company’s average online holdings at any time and protects against a variety of potential causes of loss:
“Coinbase is insured against theft and hacking in an amount that exceeds the average value of bitcoin we hold in online storage at any given time. The insurance covers losses due to breaches in physical or cyber security, accidental loss, and employee theft.”
There is one significant caveat, however:
“It doesn’t cover bitcoin lost or stolen as a result of an individual user’s negligence to maintain secure control over their login credentials.”
The policy comes with industry standard policy exclusions that apply to most policies around the world. Additional details are available on the Coinbase FAQ page.
Coinbase vs the competition
Coinbase went on to warn against claims made by some other companies in the bitcoin industry.
The company pointed out that some bitcoin wallets claim to be fully insured, but in reality are not working with accredited carriers or are self-insuring. Others claim to be fully insured currently, but only because they hold very few bitcoins which can be covered by a small policy. Once the operator grows, the cover would not be adequate, Coinbase said.
Although blog post did not specifically name the bitcoin companies in question, there are relatively few operators offering insured bitcoin services.
Elliptic Vault launched in January, with insurance underwritten by Lloyd’s of London. However, the company’s deal with Lloyd’s broke down and it was forced to look for a new insurance company shortly after it launched. It has since made a deal through broker CBC Insurance.
Xapo is another bitcoin company claiming to have insurance cover, stating that all bitcoins in its vaults are covered. However, the company is insured by Bermuda-based Meridian Global Insurance Limited, which is wholly owned by Xapo.
CoinDesk took a closer look at the issue of insurance in a recent feature which examined why insurance companies are reluctant to cover bitcoin operators. Source: http://www.coindesk.com/coinbase-names-aon-bitcoin-insurance-broker/YC, Thanks for posting! This is good to know! |
|
|
|
Website appears to be down.....
Our server hosting provider is migrating to a new data center. Could be offline for a couple hours. |
|
|
|
to my earlier issues with the current wallet. It seemed to be with the conf file. I changed the txindex to index and 1-4 hour behind message and reindexing issue is no longer a problem. That seemed to fix my issues. whether or not txindex was actually the problem, I don't know.
rpcallowip=*
rpcuser=yourusername
rpcpassword=yourpassword
server=1
daemon=1
txindex=1
debug=1
algo=scrypt
rpcport=14022
port=12024
addnode=216.250.125.121
addnode=74.208.230.160
addnode=69.164.206.169
addnode=
addnode=96.126.114.208
addnode=54.204.36.33
addnode=192.99.41.108
addnode=199.83.128.91
addnode=199.83.132.91
Glad to hear this fixed your issue! Net hash is still looking good. 5500 MH. Chain is moving good. Thank you to everyone who is mining! |
|
|
|
Looks like we have the chain moving along with 1014 MH. If we can keep about 1000 MH consistently we should be able to get things to stabilize.
This is not correct ... we still need 10GH ... the situation is complicated but I have worked through and back tested it against the stats and think I have the cause. Too complicated to type in full, but putting that aside for a moment ... 1. There is a multipool/individual(s) exacerbating the problem 2. Network hash rate: Something is wrong with that, when we were stuck for hours a few blocks ago it was showing 1000 MH ... since then the cryptominingpool alone has added nearly 1000 Mh, and other people have vouched support, and yet it has dropped to 900 odd. In fact currently that pool shows 1400 MH and using getmininginfo says it is 1000 MH 3. The block/minute time has only dropped to a block every 8mins, I know from experience that throwing 5,000 MH drops it to block/2 min ... in theory 10,000MH/10GH should return us to a block/minute and see block 145,000 in less than two days. For info: 10GH/s @ block/minute average would generate 16,000,000+ DGB at a market value of 6.5 BTC, at current rental it would only cost 6 BTC. Alternatively if people contributed a combined total of 10GH/s it would mean every one gets paid on average better than rental rates! NZ, Watching what is going down & the way the blockchain is reacting I think you might be right about an individual making the problem worse. It appears to begin acting normal as the hash rate increases. 10 GH looks like it would put us back to normal. |
|
|
|
STATS UPDATE:
Ok, so since this started the difficulty has stabilised and in the last six hours we have found ~50 blocks, thanks for everyone's support. All miners are getting a reasonable return, although this depends on pool luck a full list can be found in the OP.
However the target of 1 block/minute is still a way off, we still need to hit 10GH/s (Might only be 8GH/s still calculating on the fly) and maintain it for 1.5 days.
The good news: If we hit this all miners should still get an above average return
P.S. I have increased my network contribution to 1.2GH/s
This is awesome! It looks like we are currently almost 5 GH. The chain is moving along nicely! We totally do not understand why the difficult is going down. But if it gets us past block 145k we are all for it! Thanks again NZ. Current diff 187. |
|
|
|
|
Looks like we have the chain moving along with 1014 MH. If we can keep about 1000 MH consistently we should be able to get things to stabilize.
|
|
|
|
I have a version of the old wallet running on an old laptop ... this gives the current network hashrate accurately.
Current Network Hash Rate: 1055 MH/s
Lets get it up to 2000 ... starting in 15 mins?
I will put 500 MH/s in about 15 minutes30 minutes Awesome! Thank you Thrassos! |
|
|
|
This is awesome! Thank you for doing this! We are reading a current net hashrate of 968 MH. |
|
|
|
I am running the v3.0.1.0-g354c0f3-MultiAlgo (64-bit) which I downloaded from the main site. I tried deleting the "blockchain" & "chainstate" folders. Even with a fresh install (all traces of the digibtye data removed) it still will hang with the v3.0.1.0-g354c0f3-MultiAlgo (64-bit) version. I had no issue prior to this version wallet. If that helps any
I think what I will do for now since I currently only have one ATI 7850 (tiny 345Kh/s) is wait for block 145,000. Then I can add 38Gh/s with my USB miners.
Interesting. Can you provide a screenshot & debug.log info? We have 5 Windows 7 x64 bit machines running 3.0.1 in the office & at home with no issues. It started reindexing again =/ EDIT- shut it down and brought it back up and now it's at the 5 hour behind mark again. I tried adding the debug info and the forum won't allow me to post it. Is there a specific part you need to look at? Edit 2- I think I found the issue... maybe. I went to the main and downloaded the wallet for Windows 64bit. I noticed the file name was different than the version I had before. I may have install a previous wallet version. I installed the current wallet from the site. Hopefully this works. The 3.0.1b wallet only included language translation updates. No changes were made other than that. If your an English speaker you wont notice a difference. When we ported the code we had some pretty wild foreign translations for the word "DigiByte." |
|
|
|
I am running the v3.0.1.0-g354c0f3-MultiAlgo (64-bit) which I downloaded from the main site. I tried deleting the "blockchain" & "chainstate" folders. Even with a fresh install (all traces of the digibtye data removed) it still will hang with the v3.0.1.0-g354c0f3-MultiAlgo (64-bit) version. I had no issue prior to this version wallet. If that helps any
I think what I will do for now since I currently only have one ATI 7850 (tiny 345Kh/s) is wait for block 145,000. Then I can add 38Gh/s with my USB miners.
Interesting. Can you provide a screenshot & debug.log info? We have 5 Windows 7 x64 bit machines running 3.0.1 in the office & at home with no issues. |
|
|
|
|
Lets target 3GH net-hash at 6PM UTC tomorrow (2 PM Eastern, 11 AM Pacific.)
Current NetHash is: 1121 MH. (Taken from v2.9.1 wallet data)
In the past DigiByte had 2-3 GH routinely before the slow block-chain problem started. The key is to normalize the hash-rate & keep it consistent in order to let the difficulty stabilize.
|
|
|
|
I forgot to ask. Every time I close the v3.0.1.0 wallet and bring back up, it will hang for a good deal of time at 1 hour -4 hours behind. I've tried fresh installs and it keeps doing it. Should I go back to an older wallet for the time being?
What OS are you on? Windows 7 64 You downloaded the version 3.0.0 wallet correct? We had an issue on two of our PC's that we tested the 3.0.0 wallet on & then installed the 3.0.1 wallet. We had to delete the "blockchain" & "chainstate" folders and let the wallet re-download the block chain. 3.0.0 forked for a few hours so chances are your block-chain & database is corrupted in the Appdata folder. This would not be fixed by uninstalling/re-installing the wallet. Think we also deleted may have deleted the database file. Try deleting those files in AppDate/Romaing/DigiByte. |
|
|
|
@Digibyte
Thanks, that makes much more sense now.
Bit of a long shot, but I will drop josh a line and see if he is feeling generous ... failing that I think we should go with a coordinated push, do you have an idea for a start time/date so everyone can get involved?
How does 6 PM UTC time sound tomorrow? Thats 2 PM Eastern, 11 AM Pacific? Checking into the hash reporting issue with 3.0.1. According to the digi.morecoins pool (2.9.1 wallet) we are currently at 1121 MH net hash. http://digi.morecoins.org/index.php?page=dashboardWe had an issue with the 3.0.0 wallet where it would crash when you ran "getinfo" or "getmininginfo." This may be related. |
|
|
|
I forgot to ask. Every time I close the v3.0.1.0 wallet and bring back up, it will hang for a good deal of time at 1 hour -4 hours behind. I've tried fresh installs and it keeps doing it. Should I go back to an older wallet for the time being?
What OS are you on? |
|
|
|
This could be a problem ...
I pulled all my hash from the network around block 142,410 ... it then ran ok for the next 12+ hours until block 142,473 where the difficulty has now suddenly jumped to 1,000+ the highest digibyte has ever seen... could be stuck on this block for a long time.
I could probably clear it, but am getting a bit bored throwing away my own money to push the blockchain along ... especially as the Devs have not come forward and explained the cause of the problem. Happy to support them if they come up with a solution and need hashing power, but until then I have retreated to the side lines.
Also, does anyone know of a way to monitor the DGB network hashrate? All the usual sources no longer work since the introduction of the new wallet.
First off, thank you very much for putting your hash toward the network and trying to help us ll get over the hump. We dont expect anyone to mine for days on end with no return. As for the problem we have mentioned it several time over the past couple months. The problem is not with DigiShield alone as it worked fine until we combined it with the 0.9.1 protocol in April (you can see this on several charts.) DigiShield with the 0.6 Bitcoin protocol works great for several coins still and it still works for Dogecoin. We screwed up and did not do enough testing when we released the 0.9.1 wallet. We figured since no hard fork was required everything with the difficulty adjustment would stay the same. What basically happens with the 2.9.1 protocol is when a sudden hash spike occurs blocks are sometimes discovered only milliseconds apart. Combine this with a single block average (DigiShield only goes back to the previous block) and you get an astronomically high inflated difficulty. The next problem is when the hash rate drops and the difficulty eventually drops it drops too low and an oscillating effect occurs & the process repeats itself. The best way to overcome this is with a steady increase in hash, not a sudden spike. Also, a consistent hash base will be a huge improvement. Starting tomorrow we will begin adding hash to the network and we will publicly post the days target hash-rate. This will help speed things up considerably. We ask if you have some hash to contribute we could definitely use it. We dont expect people to do this for weeks on end but if we could get a rotation going that would be great. @Digibyte Thanks for the response, much appreciated. I admit I don't have all the answers but if it is the new protocol that is causing the problem then it is a concern that it will rear its head after the wallet passes block 145,000. The explanation you gave is plausible, but NOT the whole story and it doesn't explain what I have been observing, examples: A. Block 142,272 - 142,273 took over 5 hours to find the block at a difficulty of 1022 ... by your reckoning Digishield would then reduce the difficulty far to much ... but it actually increased to 1300+ B. Whilst pointing several GHs of hash at the network I was finding several groups of consecutive blocks, looking at these I often found two or more blocks in quick succession (seconds apart) but rather than increasing the difficulty as you suggest it actually reduced it for the next blocks. C. It is true the difficulty is oscillating, but it is also oscillating at far too high a range. It never reduces the difficulty to a point where you would find a block on average every minute (ie the correct difficulty) ... any idea why it fails to retarget to the correct level? Even when there has been very little hash pointing at the network it still oscillates roughly in the range 200-400. D. By increasing the network hash rate x6 I thought the difficulty may have gone up ... but it actually stayed the same and still oscillated in that same range. Do you have any idea why the hashrate has jumped to record levels over the last two blocks? I just want to make sure we don't replicate that and get it permanently stuck at an even higher difficulty. Interesting there are no problems with other coins using Digishield, Doge you might expect as it maintains a consistent very high hashrate ... but I would have thought some other coins may have had similar problems by now. Could it be unique to Digibyte and a stray line of code that is not included in other coins? Anyway, hopefully this will all be resolved and we can cruise to block 145k in no time. Happy to help with the hash power if you set a daily target. Is there somewhere we can check the Digibyte Network hashrate? Most of the original sources seem to have 'broken' since the wallet update. A) There is actually a delay with the code that offsets things. So if there is a sudden spike the difficulty will not respond to that until the 3rd or 4th block. We witnessed this wile testing the original DigiShield. Also, remember that block discoveries are random and not an exact process. Blocks can "accidentally" be discovered back to back even at a very high difficulty, low diff situation. B & C) This is an interesting observation we saw after the 2.9.1 codebase integration which we unfortunately did not test or recognize until after the fact. When we first tested Digishield (v2.0) over the course of a couple weeks we routinely saw the oscillation. In fact the oscillation is still present in Dogecoin. But it was a trade off for resistance against multi-pool attacks. I wish I could point you to an exact line of code in the 2.9.1 codebase but we are positive it was something we unintentionally integrated with the 0.9.1 Bitcoin core update that was meant for the Bitcoin difficulty adjustment scenario. 3.0.1 was built from the ground up from a completely different codebase. The difficulty issue will not be seen with the multi-algo update. Technically speaking the difficulty adjustment will work completely different. |
|
|
|
@Digibyte
An idea ...
If I have your permission I can ask Josh (CEO) of gawminers if he will donate the hash power to push us past 145,000.
He has been really supportive of the Altcoin community and I dread to think what scrypt hash power they now control, but it must run into THs. They sold Millions of $ of cloud scrypt power in the last week or so, and still have a large surplus under there control.
Presuming I make a case do we know what we require ... before the latest difficulty spike I calculated that 10GH/s for 1.5 days should do ... any idea if that is in the right area???
NZ, We are definitely all for it! Any help to get us past block 145,00 would be much appreciated. It would also be very interesting to see happen. 10 GH should do the trick. |
|
|
|
|
Show Posts
