Pretty cool on the Reddit page: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FKyR8Wx9.png&t=663&c=cpIk9IctY6BObQ) Very cool indeed! Thank you!
|
|
|
Any chance of some instructions on how to update P2Pools, thanks.
We will double check this! Thanks! I just updated my P2Pool node. I didn't even stop P2pool, I just stopped the DigiByte client, replaced it with the newer version, and relaunched it. My node kept on running all the time and picked up new work as soon as the client was relaunched. I didn't touch the P2Pool config yet. @All P2Pool Owners: The P2Pool Config also needs to be updated. I have requested Rav3npl (at Github) to check it out. And I'll let you guys know when the networks.py files are updated. https://github.com/Rav3nPL/p2pool-rav/issues/57So Heres how P2Pools can update both digibyte and p2pool config files using the terminal: How to Update digibyte or DigiByteProject:change directory to digibyte or digibyteproject OR if youve renamed it as suggested in my guide You should what changes were made (Deletions and additions in the code) -- Make sure that these changes were made! And now you can run digibyted again, and as stated by the p2pool owners above, you dont have to stop the client... How to Update P2Pool Config:Again, this can ONLY be done after Rav3n or someone from the DigiByteTeam (@xploited) gives us the networks.py files. So, wait until that happens. Change directory to p2pool OR if you havent renamed it to p2pool Again, You should see that Additions and Deletions were made in the code -- Make sure that these changes were made! Doon't worry, when you pull to p2pool.. There are no changes made to the web-static folder.. so you frontend will stay the same ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) I would recommend killing the p2pool and restarting it just to be safe ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) We dont want any surprise forks! ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Thank you for posting! We ourselves are not sure exactly what needs updated as we have never operated a P2P pool.
|
|
|
Update is mandatory by block 67,200 which should be found sometime on Friday 2/28/2014!
Starting tomorrow pools that have not updated will be de-listed from the website and will be crossed out in red here on BitcoinTalk until they have updated.
Thanks for your cooperation!
|
|
|
Great idea, "DigiShield" added to thread title!
|
|
|
Europe Node: p2-pool.eu:9022 Updated 2min ago. Can you please add me to the list, thanks. Added, thank you! Mac OSX & Ubunutu wallets being uploaded as we speak!
|
|
|
Very cool! Thank you, will update you on the list!
|
|
|
Any chance of some instructions on how to update P2Pools, thanks.
We will double check this! Thanks!
|
|
|
i've been with this coin since launch and i've seen it get lower and lower wondering why as this is one of the few coins that deserves to go really well. all the hard work thats been put into it by the devs. it's always my go to mining coin. i think now it's only up from here
+1 We are ready to start the trip to the moon!! 1st pool to update is: http://digi.morecoins.org/Thank you for updating! They have been a solid pool since the beginning!
|
|
|
ok i'm running the new wallet. downloaded from the digibyte website
What do you think? Is everything working for you?
|
|
|
We are now in the process of uploading the DigiShield update for release! Will post links as soon as it is ready!
|
|
|
This looks reasonable now and will work under normal conditions, although an asymmetric algorithm is not recommended, it opens up some unfair mining practices. If you look at the recent history of the Luckycoin and what the wafflepool.com did to it, you should realize that your 99% finished algorithm will not protect you from a similar event. https://coinplorer.com/Charts/Difficulty/LKYIt doesn't matter how you choose these parameters, they will provide no effective protection. Do some simulation what happens when a pool sustains 10GH/s+ for some hours on your coin. Thank you for the feedback and the link! We will look into that for sure!
|
|
|
Any ETA when the update will drop?
We will drop it around 7 PM UTC time tomorrow (2pm Eastern) as it is late here (2 AM). It has been another long day for us. We are happy with the tests so far. We will mine the testnet over night and get an average over several hours to double check that we are where we want to be. We are now making sure the wallet syncs with the main net etc. Thanks again for your patience!
|
|
|
Our delay right now is deciding exactly how much we should allow the difficulty to adjust with each block. The performance from our tests indicates the equivalent of 200x allows for the fastest adjustments up and down within a reasonable amount of time. // Maximum 400% adjustment... bnResult *= 200; Is there something we are over looking here? With a much higher (actual) hash load will this adjustment act differently? What are the dangers of allowing very large diff swings like this? Also, with a higher difficulty # like the 10-20 range we currently see, will we see any other phenomena that we can't test in the low hash test-net environment? Are we on the right path? I am getting the impression you don't really understand the retargeting code. The only thing you achieve by changing the number in the quoted code is to open up a big security hole. In case you also change some other parts of the code to match the above change, the resulting retargeting factor of 200 is insane. You are just asking someone with an ASIC to send your coin from diff 10 to diff 10,000 and then you are stuck mining even a single block. We are leaving this code like this, as we see how it is used with checkpoints. It took us several runs to understand exactly what all was going on there. // Maximum 400% adjustment... bnResult *= 4; We discovered the optimum combination was to set a different limit for difficulty increases vs decreases. By doing this we are able to recover or adjust to a 8-10x increase or decrease in net hash within just a few blocks. By having the limits high for both increases and decreases we were able to adjust rapidly to hash swings, but an annoying "oscillation" of block timings emerged. Two fast, then two slow. To fix this we discovered by having lower limits on increases and higher limits on difficulty decreases the oscillation was mitigated and overall performance and re-targeting improved dramatically. if (nActualTimespan < (retargetTimespan - (retargetTimespan/3)) ) nActualTimespan = (retargetTimespan - (retargetTimespan/3)); if (nActualTimespan > (retargetTimespan + (retargetTimespan/2)) ) nActualTimespan = (retargetTimespan + (retargetTimespan/2));
We are now running tests on the network for a few hours to get a running block average and we will also simulate a few more hash swings. We are 99% finished though! With DigiShield we are offering a solution to the re-target problem never seen before in a coin!
|
|
|
Great news! We appear to have found the winning combination for the re-target in the DigiShield update!
We discovered the optimum combination was to set a different limit for difficulty increases vs decreases. By doing this we are able to recover or adjust to a 8-10x increase or decrease in net hash within just a few blocks. By having the limits high for both increases and decreases we were able to adjust rapidly to hash swings, but an annoying "oscillation" of block timings emerged. Two fast, then two slow. To fix this we discovered by having lower limits on increases and higher limits on difficulty decreases the oscillation was mitigated and overall performance and re-targeting improved dramatically.
We are now running tests on the network for a few hours to get a running block average and we will also simulate a few more hash swings. We are 99% finished though! Thank you for your support and patience! The extra time we have spent testing over the last 5 days will most definitely pay off for everyone in the long run! With DigiShield we are offering a solution to the re-target problem never seen before in a coin!
|
|
|
+1 Funny, we decided on this name yesterday. It appears all the great minds in the DigiByte community think alike! Glad to see it was arrived at independently of the dev team!
Happy that I proposed that name for my first post ever on bitcointalk ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Welcome to the community! Whats your DGB address?
|
|
|
|