Where is this digibyte.conf file in windows located? C:/users/YourUser/AppData/Roaming/DigiByte I am amazed as to how fast the Digibyte block chain syncs, is there anything special about how DGB does things or is it based on the number of transactions in the blockchain?
The DigiByte block chain is much smaller so there is less to download. But we have also set up some high speed dns seed servers. We are in the process of setting up two more so there will be 4 total. |
|
|
|
|
,./,./,
Thanks for the feedback. Does the wallet sync with the net?
We are working on the icon issue. Will also get on the wallet language translation issues later. If you could supply what the translation should be in a list that would be great.
Example:
Bitcoinadres= DigiByteadres?
Bitcoinnetwerk=DigiBytenetwerk?
|
|
|
|
Hmmm... was hoping it was a one off, but I've now encountered this 3x post upgrade to 3.0.1. Windows 32bit. Had no issues previously with upgrades, including the previous 3.0.0. Each time I choose OK, and it rebuilds and loads my wallet... but then if I close it down and launch again it repeats....  1) Backup your wallet.dat 2) Go to YourUser/AppData/Roaming/DigiByte 3) Delete the "blocks" & "chainstate" folders The error with the 3.0.0 release will cause this issue. Once you delete those folders it will re-sync correctly. |
|
|
|
is it right that the multi algo already started about 2.9 days?
It will start in 2.9 days? Or do you mean has it already started? It should take 1-2 weeks based up the current speed of the block chain for it to start. we are now at block #141764 multi algo start at #145000 145000-141764=3236 blocks 1 block = 1 minute 3236 minutes / 60 = 54 hours 52 / 24 = 2,1 days I'm crazy? or day I made a mistake? If the chain was working as expected you would be absolutely correct. But since there have been big delays (stuck chain) we used the average over the last couple months to time the change. If we waited 10,000 blocks it could take a month for the change to occur. |
|
|
|
is it right that the multi algo already started about 2.9 days?
It will start in 2.9 days? Or do you mean has it already started? It should take 1-2 weeks based up the current speed of the block chain for it to start. |
|
|
|
If anyone has any other suggestions before we make this the official update release, we have a few hours to make an adjustment. But at this point we do not see any better options?
You can adjust diff using profitability. But if you are sure that there will be no instamine, I don't care. If I right understand, no one can mine 300 blocks with some shitty SHA ASIC in a 5 minutes, right? This is correct, the diff will catch up very quickly. Plus the other algos need to produce blocks to allow for more of the sha blocks to be created. |
|
|
|
Starting difficulty is:
"difficulty_sha256d" : 0.00024414,
"difficulty_scrypt" : whatever scrypt diff is at switch over
"difficulty_groestl" : 0.00024414,
"difficulty_skein" : 0.00024414,
"difficulty_qubit" : 0.00024414,
Sorry, but WTF you are doing? There will be such instamine. There may be a few extra blocks, but no where near what there has been in the past with coin launches. The difficulty will adapt very, very quickly. Within a few minutes it will catch up. Think of it as an incentive to mine at the start of multi-algo. We have tested this on tesnet, it will be nothing like what people have seen in the past. DigiShield will jack up the difficulty very quickly, but this time it will average itself out over the previous 10 blocks. Plus a few other adjustments for better performance (no more stuck chain.) We thought about changing the starting diff to something much higher, but then the problem is if we artificially raise the initial floor for the difficulty it will not be able to go lower if needed. This can cause other problems. Since each algo is weighted differently, there is no reliable # to set things to. We really have no idea what the "right" difficulty should be as there is no reliable way of figuring out what it should be. It is much better to let it find its natural equilibrium. Once again, there will be a few minutes of bonus blocks for initial miners, but their is no reliable way to avoid this. Think of it as make up for the last few months of mining. We are way behind where we should be as far as coin production. This does not fit in well with our next step in progressing toward a micro payment currency (more of this will be released in the coming weeks.) If anyone has any other suggestions before we make this the official update release, we have a few hours to make an adjustment. But at this point we do not see any better options? |
|
|
|
Introducing DigiByte v3.0.1 MultiAlgo Mandatory Update before block 145,000 Awesome. What is starting difficulty at these algos? Starting difficulty is: "difficulty_sha256d" : 0.00024414, "difficulty_scrypt" : whatever scrypt diff is at switch over "difficulty_groestl" : 0.00024414, "difficulty_skein" : 0.00024414, "difficulty_qubit" : 0.00024414, Since we have a modified DigiShield the algo diffs will catch up rapidly to prevent an instamine (like what we saw at launch back in Jan.) Each algo will have its own difficulty. you are the best dev of the world!
is there a mac os x wallet available?
We are working on it as we speak. I would like to try some SHA256 hash first, what pools are ready for this?
No pools are available yet, we just wanted a few more people to test the wallet before we pushed it out to the underlying infrastructure (pools, exchanges, block explorers). Only scrypt mining is available until the switchover at block 145,000. About 1-2 weeks depending on chain speed. |
|
|
|
chinese version have some issues.  translate "比特币" to "极特币" and change the bitcoin address to digibyte address.  Good catch appbox. Thank you! |
|
|
|
|
Ok, we have the fix implemented and we are in the process of double checking everything and testing it. Thank you for your patience everyone!
|
|
|
|
Latest pull from git does not compile for me
miner.cpp: In function 'CBlockTemplate* CreateNewBlock(const CScript&, int)':
miner.cpp:137:9: error: 'pindexBest' was not declared in this scope
miner.cpp:138:101: error: expected ')' before 'PRI64d'
main.cpp: In function 'unsigned int GetNextWorkRequiredV1(const CBlockIndex*, const CBlockHeader*, int)':
main.cpp:1298:13: warning: variable 'retargetSpacing' set but not used [-Wunused-but-set-variable]
CXX noui.o
Yes, we put that in there for the time being to keep people from pulling 3.0.0 code. We can't make the repo private so that is the next best option. We are still working on getting 3.0.1 out there. |
|
|
|
Anyone solo mining care to share their digibyte.conf file? I had this working previously but now can't seem to get it going....
We will release all the .conf info once we get this issue resolved. Thanks again for all your patience. This is a very complicated update. All will be normal again soon! |
|
|
|
Anyone solo mining care to share their digibyte.conf file? I had this working previously but now can't seem to get it going....
Don't try solo mining with the 3.0.0 wallet as even "scrypt" blocks will be invalidated on that chain. We are working on getting 3.0.1 out as fast as we can. |
|
|
|
@ Digibyte... trying to solo mine Scrypt... why does your digibyte.conf as listed on the first post contain an rpcport=14022 AND a port=12024? Also... are the nodes as listed still correct?
The nodes listed need to be updated. The ports are correct. |
|
|
|
As I understand it, its not a p2pool in the link. It's a centralized pool using local database to store shares mined by each miner, which get then payed out. P2pool is a de-centralized network of p2pool nodes, which are interconnected, with peer to peer communication so miners can connect to any p2pool node, even hop between the nodes in the p2pool network, without loosing their shares. And p2pool is using PPLNS payout system. So if i run a p2pool it would be only for one algo ? Or people would be able to mine any algo with the p2pool ? It is possible to mine 5 different alogs on one pool. But you will need 5 instances of the wallet running, each set to a different algo with a different rpc port to mine on. NOMP is essentially a p2p pool that can handle this out of the box. https://github.com/zone117x/node-open-mining-portal/ |
|
|
|
Can someone clear things up for me? Are people obtaining coins from mining on SHA 256 when they're not supposed to?
Essentially a couple people were able to mine a few block on the SHA algo. However since these coins are on a separate chain the existing network is rejecting them. The few people who did download 3.0.0 can see these blocks, but we are recompiling the wallet with a fix as we speak to v 3.0.1 We are implementing a checkpoint on the old chain that will invalidate all the SHA blocks. Stay tuned, and who ever is mining the SHA blocks please note they will be rejected by the old chain and will be invalid if you try and send them anywhere. |
|
|
|
Just got a reply from Cryptsy. I sent 1675449.00 DGB, but so far the deposit has not shown up and the address for the transaction is not listed. Going to wait for all the verifying to finish and then uninstall the wallet. Re-install fresh
It does appear that a fork has already emerged between new 3.0.0 wallets & the old chain. We pulled the 3.0.0 downloads until we get a lid on exactly what is going on. It appears Sha256 is still active while the other algos are not * should not be mine-able until block 145,000. But since it is default backbone of the multi-algo code we are going to re-check our switch over code. Please hold off on mining the sha256 code until we get a lid on it. We can implement a checkpoint on the old chain if need be. Gotcha, Just did a fresh install >.< lol Ok. Yeah we are going over the code again real quick. It does appear the normal chain is on block 141,663 while the 3.0.0 wallet is on block 141,988. We will re-compile and release 3.0.1. Just keep your existing coins (pre-update) in your wallet and don't move them just yet. |
|
|
|
|
Show Posts
