I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
Cheers! I know what you're talking about with the old dead code. CED even mentioned it in PM. I just left it as is, as almost every single DIGI code implementation I looked at still had it included. I didn't want to stray from the norm, but I'm glad you were able to clean it up! Kudos, mate. Can you post the code block here for reference? I'd love to see the cleaned up function. -Fuse Ah cool. Yes it took some time but I believe I have a pretty neat piece of code now  Link below Thats awesome! I haven't pushed the commits on guldencoin to the github repo yet, but here is the DIGI I have right now: https://gist.github.com/GeertJohan/0694cb20b5fa48f7820bHere are the comments I made in the commit that cleans up the Digi code, so you can see why I removed certain pieces of code: https://gist.github.com/GeertJohan/14fa6f23e5c0105972e4I think the problem you are mentioning on your lines 59-56 (negative timespan) are solved by the limiter at your lines 74-78. Right? Cheers! |
|
|
|
|
I've cleaned up the Digishield code.. there was a lot of dead and unused code from the time it was used to adjust every x blocks (we're adjusting every block).
To be honest, now that the code is clean and "simple to understand", I have quite good hopes for this!
|
|
|
|
What block will the hardfork start?
It will be aimed towards the end of january so everyone has time to update. |
|
|
|
No offence to the person that made that site, but i like Bram's site way more chat.guldencoin.com is just a webchat frontend to the #Guldencoin channel on the tweakers.net irc servers. The upside about this is that everyone is free to pick their own client to connect to the chat. See http://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clientsI will mail tweakers.net concerning the session limit.. this happened ofcourse because the chat.guldencoin.com servere opened too many connections to tweakers.net They can probably lift the restriction for our servers' IP. Cheers! |
|
|
|
Fuse, can you join the chat channel at http://chat.guldencoin.com ?  Would like your opinion on some algo related stuff. Ofcourse, everyone else is also very welcome in the chat! |
|
|
|
But please... " G-J, do not click on the link!!!!!!"  zzzzzZZZZZZzzzZZZZZ hmm what!?? zzzzzZZZZZZzzzZZZZZ So relaxing music! Let me counter that post with some DOWORK music: https://soundcloud.com/toofutureshop/too-future-guest-mix-014-snbrn(I'm working on Digi in the coin, fuse already provided new code, will post an update here today!) |
|
|
|
/GJ, you said the large-wave and DIGI functions of the simulator would be about a day's work. Have you been able complete it yet? Not rushing, just haven't seen an update. If not, my offer is still on the table- I'll contact the DIGI devs and ask them to write the custom DIGI code for NLG. Let me know if you want to go that route.
I made great progress on the sim, I have added export to csv (excel) and am working on the simulations (large wave, jump pool). Implementing Digi in NLG isn't even that much work, no need to ask the Digi dev's to do that for us. What IS a lot of work is proving that Digi will actually protect us from a jumping pool, that's why we need to run these simulations. We need prove that the algorithm adjusts properly, and we must be able to explain HOW and WHY the algorithm is adjusting properly. |
|
|
|
... bla bla bla block A block B blabla ....
How would such situation be resolved in non-digi algo's? No this isn't digi's fault. We simply shouldn't change ComputeMinWork's max adjustment from 400% to 25%. I don't think any coin ever did this, unless you have a very very extreme difficulty re-adjustment algorithm that actually could cause adjustments over 400%, in which case you want to change it upwards! |
|
|
|
TL;DR: the change to 25% doesn't do what was expected and will only introduce chain splits. That's an assumption or has been tested with the simulator? Neither, it's deducted by reading the sources. |
|
|
|
Hi all, Digi with 25% max adjustmentI have been reading the changes committed by ny2cafuse ( https://github.com/nlgcoin/guldencoin/pull/7) Sadly, the 25% filter was not actually changing the required difficulty. In fact: it would cause major and non-resolving chain-splits. The max 25% adjustment rule is in a function that is used to detect "ddos" blocks. This is a simple and quick check to see if a block can be taken seriously, before the full checks are done, which are using a lot more resources. This protects the network from ddos attacks. How changing the max adjustment to 25% would cause a chainsplit, step by step: Say two miners (A and B) would mine a block at the same time and broadcast it to the network. Half the network gets block from A first, other half gets block from B first. The group that got block A will now perform an anti ddos check on the block from B, because B was later and therefore is considered to be a split. Lets assume that the digishield changed the difficulty over 25%. This means group A will completely ignore block B. In the meanwhile, group B has more miners and mines blocks B2 and B3; they now have the larger chain: "B>B2>B3". But since group A won't accept block B, they will never get this chain and won't resolve the split. The miners in group A won't either, they'll continue mining as if nothing ever happened. The same applies for group B: group B will never accept block A because it has > 25% difficulty change, so IF group A gets the longer chain (which would normally resolve the split), it won't be accepted by group B because group B will never accept block A. The normal max adjustment is 400%, which will allow even the most extreme diff changes by digi or dgw3. TL;DR: the change to 25% doesn't do what was expected and will only introduce chain splits. What now?I will now continue with the simulator, doing the items listed in the previously posted TODO list. This will give us more insight in how the change to digi will affect the chain. It's important that we know what we are doing before we're making these changes. We are very close. But remember: it's done when we have a proven correct solution that won't mess up the chain and will solve our problems. If testing can be done with Digishield in the simulator so soon, there where also discussions on changing parameters in DGW3 2 months ago orso that could do a lot if I am correct. If the simulator can really simulate small and big waves that soon, then take some time for good testing different parameters and blocktimes. Just my thoughts. 1 or 2 weeks more Clever, I can live with that.
You're making an excellent point here: yes we can try DGW3 with alternative settings in the simulator. We can even change formula's (not just the settings/parameters for the formula's). "How can I help?"If you're a coder then you can help out with the code, please do! We're on github: https://github.com/nlgcoin/guldencoinhttps://github.com/GeertJohan/diffsimPlease contact me if you'd like to help with code. We do accept pull requests. "But I'm not a coder..."Thats okay.. You might not be able to help with the more technical aspects of Guldencoin but that is just a very small part of what we're doing here. For instance: contact merchants, introduce your friends to Guldencoin (remember: they can get 100 free NLG! Who doesn't like free stuff!?) Or write an article about Guldecoin. Comment on large news websites on topics related to Guldencoin. etc. etc. Better even: think out of the box. The things I've just listed have been listed before, and although they are very very important, it's also good to have new and innovative usage and promotion of Guldencoin.. Gulden New Year!Lets work together towards a future where Guldencoin is widely accepted in The Netherlands and beyond! Everything we're doing are small steps towards that goal, and as long as everyone keeps making these small steps: we'll reach that goal in 2015. Cheers! |
|
|
|
The larger waves is quite simple, will take me an hour or so to make a perfect job.
Digishield implementation will take a bit longer, maybe 5 or 6 hours..
More timeconsuming features are exporting a simulated chain to excel for further analysis.
Cheers!
Do you mean the simulator is almost ready for testing? Different algo's testing in GO with different parameters? I am a bit confused now what you mean. Oh maybe you missed the announcement, that's okay. Right now the simulator is working with small waves and DGW3 algo. You can pick up the sources at https://github.com/GeertJohan/diffsimSo whats on the TODO: - larger waves (5-15% change between blocks) - jump pool (CM) simulation - Digishield algorithm - export simulation to excel |
|
|
|
There was a tough discussion, then consensus and a desicion made by the team you are part of.
What is the message you giving us by making doubts about the decision you are part of?
I don't understand...
I never tested Digishield, but I did read the code during the switch from KGW to a new algo (which became DGW3). My impression was that Digishield is a lot similar to DGW3, but I thought DGW3 was slightly better. The reason there is somewhat consensus is based on the great testing job done by fuse, criptoe and others. So the community started voting for Digishield, and simply followed the wishes of the community. I know creating a custom algorithm will take longer than simply implementing the existing Digishield algorithm.. So thats why Digishield is the easy choice right now. If digishield doesn't work we expected, we can always change again later.. Hai GJ. How long do you think it will last for the simulator to get ready for testing the bigger waves as well? Can you give an indication?
If it is only 2 or 3 weeks or so, I agree with you to wait and implement the best solution at once. But most dedicated miners have enough of what Clever does. It is going on too long now and if all takes another month or 2 months, I think most want the Digishield now, me included. I understand their point of view.
That is why keep the community updated with updates and info on this project was/is that important, not only when things are finished. I understand it is difficult to say when it is ready though, but an indication would be good as well.
The larger waves is quite simple, will take me an hour or so to make a perfect job. Digishield implementation will take a bit longer, maybe 5 or 6 hours.. More timeconsuming features are exporting a simulated chain to excel for further analysis. Cheers! |
|
|
|
Community Alert!!! Digishield is not going to be a magic bullet against Clevermining. In fact, expect network difficulty to hit new record highs and be 'stuck' for long periods of time. If Clevermining hits the NLG network with 10x or 20x hash-rate of the base nethash, the difficulty will hit 10x or 20x in a blink. Digishield deals very aggressively with hash-rate spikes, and when Clevermining exits, taking the hash-rate with them, the network is going to be 'stuck' at a very high difficulty. This Digishield doing its job, reacting quick enough to make it unprofitable to attack the network with high hash-rate. No one knows how Clevermining or its profitability algo will react to this change. Terk may continue to test the network looking for a way to get coins at a discount. Depends on the tenacity of the Clevermining team as to how many cycles the network has to go through till Clevermining discovers how to best handle the changed diff algo. Do not expect Clevermining to go quietly, NLG has been their cash cow for many months. I am expecting new record highs of difficulty and some long, grinding sessions before the network achieves equilibrium. What I don't expect to see is false difficulty lows and Clevermining minting the majority of the blocks in a 24hr period by attacking. If Terk decides to park 20x hash-rate on the NLG network for a few days or weeks, Clevermining will own the NLG network by brute force, but not at a discount as they have been. The NLG dev team and community need to have realistic expectations of the upcoming difficulty algo change and the above is what I expect to happen. Understand that if it were up to me, we'd take more time to develop and test a better solution. But it seems the majority of the community wants to try Digishield.. |
|
|
|
A 25% modified Digishield diff algo is my recommendation.
How is the algo modified? I'd be very interested to see how it works! You change the max difficulty adjustment. Other than that it's standard DIGI. Okay.. And it is increased 25% then? No other changes are made? While I completely trust GJ, a simulator is a just that... a simulation.
A simulation is not "just a simulation".. it's a piece of code that executes the exact same maths as being done in the satoshi client, but does not require actual hashing power.. Thereby making it easier to see how an algo reacts.. This makes it a much more powerful tool to test algo changes. Can it simulate a fork caused by an isntant, massive hashrate increase? You also talk about luck with a 100MH miner... well the 600GH miner is going to have luck too. Computer simulations, while very accurate(when proven so) are only as good as the code. There's a reason why robot AI isn't to a point of consciousness yet. Forks aren't caused by the diff readjustment algorithm and so they're currently out of scope for the simulator, and are not part of the difficulty re-adjustment problem at all. The chances of a 1MH miner having three lucky blocks are a lot larger then the chances for a 600GH miner having three lucky blocks. 1. Look at network difficulty adjustment in increments instead of minutes or seconds -
The common fault is to look at a network as blocks per minute or blocks per 24 hours, such as presented by 'nlgblogger', instead a network needs to be looked at as the number of diff adjustments per 24 hours. With a 60sec block time, there is 1440 increments per 24 hours, with 150sec(NLG), there are only 576. So any diff algo designed for a 60sec block time needs to be looked at over 1440 blocks, not a 24 hour period, to see if it is working as desired if that diff algo is applied to any other block time. NLG has only about 1/3 of the diff increments in 24 hours when compared to a 60sec block time network. Both DigiShield and DGW3 were desired expressly for a 60 second block time, Digicoin in the former and DarkCoin in the latter. This is why neither Digi nor DGW3 are effective without tuning.
I don't really agree. The main variable that drives the DGW3 calculation is the average block time for the past n blocks. Hashing power can be added/removed instantaneous. It's not like hashing machines need to "warm up" and slowly increase their hashing speed over a few minutes or hours, so it doesn't make sense for any diff algo to take into account how many re-adjustments per hour are happening. I think you're missing the point here. The reason Kilo brings this up is VERY valid. If you have more iterations of retargeting in a specific period, the more change can happen. Lets say the NLG codebase was only allowed to be altered every 6 months. You would have to make a lot of major changes to account for everything that happened in that defined time period. Maybe something happened 5 months ago, but now you're waiting to catch up. If you say you can change the codebase every 3 months, now you're only 2 months behind instead of 5. Mind you, I know the blocks carry the changes with each block, but when they are targeted for a longer time, they reaction is more severe. I'll get back to this. I totally agree that having more adjustments (smaller block times) will give the diff re-adjustment more opportunities to re-adjust, and so in theory it will work better.. But this is not something the algorithm itself should be aware of. Also, let's not forget that smaller blocktimes introduces a new problem: more chance of chain splits. (network must converge within the blocktime, if it doesn't, a split might occur.. if the split isn't handled well by the network, it becomes permanent and we're stuck with a fork..) Digishield is a much simpler and more elegant diff algo that scales easily and effectively, while DGW3 is very complex and does not scale well.
I wouldn't say DGW3 is very complex.. It's not even complex relative to Digishield, because the two look a lot alike. Please tell me how you think Digi is more elegant and what you mean with "scaling".. Where in the maths does Digi scale better than DGW3? Averaging difficulties to calculate the newer difficulty is more complex in ways. It's allows more room for error and skewed calculations. It's pretty obvious DGW3 doesn't scale well. You can't argue that because the chain shows it. I think it has for a long time now. I'll take a stab at what Kilo meant by elegant. DIGI is simple. It's a 1 to 2 line addition to the base LTC difficulty algorithm. That's it. It's elegant in that it's simple and it works. Additionally, Kilo and I have witnessed DIGI implementations over the last year that scaled very well. When a chain's hashrate grows 5X it's size in a day and stays healthy, I would say it scales pretty darn good. I know DGW3 doesn't handle the current spikes very well.. But what is this "scaling" factor? And why would Digi handle it well? Is there an example of a coin with Digi that has x30 hashrate increases (e.g.: clevermining) at the same level as Guldencoin currently is? Also, Digishield is not really a 1 to 2 line addition to the base LTC algorithm. Please read https://github.com/digibyte/digibyte/blob/master/src/main.cpp#L1268-L1555And we don't have 5x hashrate in a day.. we have 30x hashrate in 3 seconds.. I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation.
Blockreward is nowhere near related to the difficulty algorithm.. It wouldn't have anything to do with Digishield... Completely related if you reduce the block time to accommodate for an algo that is meant for shorter block times. A 150 second block time works for LTC because LTC uses the standard algo with a shit ton of hashing power, think petahash, behind it consistently. NLG doesn't have that. Most other altcoins that have healthy chains use a block time closer to 60 seconds but not less. 90 seconds would be optimal, but Kilo's 75 seconds is probably a very safe number for NLG. Less than 60 seconds and you run the risk of timewarp attacks. Kilo has successfully done this to a few coins just to prove the maths. But that aside, shortening the block time is a solid idea. It reduces the magnification of the retarget changes and allows for faster reactions. If you shorten the block time, you have to reduce the reward, unless you want to mine out faster. Normally, I would be against reducing block rewards, but halving the block time and the block reward gives you the same coins mined daily, but with 100% more difficulty changes in that time. With the current network stability (which isn't very high) I wouldn't recommend lower blocktimes.. Furthermore, it simply doesn't work because although lower blocktimes means more blocks and thus more re-adjustments.. it's the same calculations being done... say we would half the block time to 75 seconds, that means the difficulty would also be halved so we would get twice the number of blocks within the same amount of time. The income/costs for dedicated miners wouldn't change, they would just get twice the blocks with each half the reward per block. This also applies for clever, they would have to spend the same amount of hashingpower to get twice the number of blocks at half the reward per block.. so in the end it's just the same thing.. The only thing that changes is that if the dgw3 or digi impact isn't halved too: it will cause twice the size in blocktime spikes (both up and down).. So you'd have to half the dgw3/digi impact.. which means that in the end, you're left with 0 effect (apart from a network that's more vulnerable to time warp attacks and chain splits). The faster reaction you're talking about would work if the hashrate changes over a number of blocks' time. But with a jump pool, it's instantanious. If I'm missing something, please explain. (....) This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions.
How did you figure out these numbers ? I would say the 50% stuck time is conservative with DIGI. I would guess you would reduce the amount of stuck time(blocks that take forever to mine) closer to 90-95%. The chain would function smoother, and not make wild swings into the stratosphere like it does now with DGW3. The 100% increase in difficulty adjustments is correct if you halve the block time. The reduction in the amount of blocks that clever could mint is about right. It's not hard to see in the charts I posted that if you threw 10X the network hashrate at the chain, based on profitability, you're profitability would be gone before you could grab 15 blocks in under a minute. There's no averaging, so DIGI doesn't need to take in to account the false lows that DGW3 produces. The reaction is instant instead of delayed because of a moving average. The numbers, while not statistically absolute, are sound. No need to dismiss them. The fact that digi doesn't take into account the false lows /does/ sound good.. As that is actually the largest part of the problem we're seeing. Please don't take these remarks personally.. I'm merely pointing out that with the hashrate/sec spikes we're experiencing; both DGW3 and Digishield won't handle it. I know I haven't been active the last week or so, I'm sorry for that. But please keep in mind that we want a permanent and solid solution. We actually need a more complex algo...
I don't take the remarks personally, at all. I think you are 100% incorrect about DIGI not handling the hashrate spikes though. We've proved it on a testnet. It's funny... we presented actual data, but there's still people that deny it, like it was all made up lol. DIGI works, the graphs back that up, and the solution will work until the entire altcoin environment makes it's next paradigm shift. You can't predict the future of mining, so you can't create an algo for it. You can however use what is effective in this era of mining. DIGI is the answer.You spent that entire post trying to debunk my team's findings, and shoot down the possibility of using DIGI. However, you didn't mention a single plan of action other than to state that a more complex algo needs to be created.
A plan that has been needed for months now. Give us direction. You're the rudder. Don't let us steer ourselves into the rocks.
So, I don't really believe in the halved blocktimes, but investigating more into digi seems to be worth the time.. Before christmas I had the idea to write 'GDR': "Guldencoin Difficulty Readjustment". Maybe it's a good approach to take what we've learned so far, including DGW3 and Digi approaches, and work out an algorithm that is better. After all that is how DGW3 and Digi were born too: by applying lessons learned and incremental development. I would be extremely happy to do this, but not alone. If anyone can provide me with a Digi ported to the simulator that would be great, it's pretty simple, but will take some time. If the community doesn't want a new algorithm and places it's bet on Digi, then I WILL help with that. I'd be happy to work together with youguys to apply and deploy the software patch. Just as before I will provide compiled binaries for all major platforms and update the seeds and send a network alert. I believe last time that went pretty well, and this time we don't have to do a chain fork. Please though, understand that we should not do this without being absolutely sure. There are always risks. Cheers! |
|
|
|
With respect to the testing, how is real world mining not actual maths? It is how the algorithm is going to behave on a chain, rather than how a simulator says it will behave. I would think if you wanted true test data you would truly test it, would you not? Like I said, I'm for testing against the simulator, but we need to know that the simulator(which simulates actual mining, not actually mining) is giving us substantiated results. We can't say the simulator is the key to testing algorithms without testing the simulator against an actual testnet first.
For example, you would need to mine on a testnet. You would simulate large wave, small wave, etc. and record all the data. Then you would need to replicate that chain with the simulator, and compare the results. If the simulator was off by a predetermined margin, you wouldn't be able to say the simulator was accurate. After all the testnet chain would be the definitive data... it's the actual mining.
So to say that testnet data is an educated guess is a little off base. It is the actual, substantiated data collected from mining.
-Fuse
Let me make an other statement, "a simulator is nothing more or less than a tool for testing situations that CAN'T be test otherwise"
Why do you think cars are crashed to a concrete wall? Why do you think they testflight a new plane? Just because all the simulations they do just give a pretty good insight but are no substitute for the real live situations. Simulators are the next best thing if you can't afford testing live!
This said a simulator for crypto an unnecesary toy. Real live testing is possible in the testnet environment, real software, real hashes from real miners.
The Criptoe team tested Digi in a modified form on testnet and the results are looking OK. What reason can any dev have for a cumbersome coin NOT to change the algo to something thats properly tested.
I should clarify a bit on the simulator. First of all, the comparison to car crashing simulations is not very accurate. We crash cars into walls because it's very very hard to simulate all the moving parts, the different materials, the impact and weight of all those materials.. the temperature and friction of all the parts.. etc. etc. etc.. So real live testing is the way to go.. A difficulty re-adjustment algorithm is ~100 lines of code performing some calculations.. When you give this the same input, it will output the same thing every time.. The only thing that makes the simulator different from a testnet is that no actual hashing is required and one can "fake" any amount of GH/s without having to purchase large machines.. I'm not saying testnet testing shouldn't happen, it's very important.. But unless you own a fortune and just bought a lot of new mining machines, it can't test against the same volumes of hashingpower.. Another argument for my simulator is that it makes testing easier and faster.. on a testnet testing a chain with 100 blocks should take 100*150 seconds.. The simulator can do this instantly because time is "simulated".. Again, that does not make the math being done any less reliable.. it's just fooling DGW3 by telling it more time has passed that did in the real world. And yes, fuse is correct that if you record the testnet results and input them in a simulator, somewhere near the same output should come out.. (only faster). There is one large difference between the testnet results and the simulator: the simulator calculates with 'perfect' hashrate chance. So if you have a dice roll 60 times, it will roll to each digit 10 times.. Wheras real mining has a chance of "having luck".. In the end this doesn't really matter for the diff algo testing, becuase "having luck" with a 100 MH miner isn't nowhere near as much impact as 600GH/s rolling through.. |
|
|
|
A 25% modified Digishield diff algo is my recommendation.
How is the algo modified? I'd be very interested to see how it works! While I completely trust GJ, a simulator is a just that... a simulation.
A simulation is not "just a simulation".. it's a piece of code that executes the exact same maths as being done in the satoshi client, but does not require actual hashing power.. Thereby making it easier to see how an algo reacts.. This makes it a much more powerful tool to test algo changes. 1. Look at network difficulty adjustment in increments instead of minutes or seconds -
The common fault is to look at a network as blocks per minute or blocks per 24 hours, such as presented by 'nlgblogger', instead a network needs to be looked at as the number of diff adjustments per 24 hours. With a 60sec block time, there is 1440 increments per 24 hours, with 150sec(NLG), there are only 576. So any diff algo designed for a 60sec block time needs to be looked at over 1440 blocks, not a 24 hour period, to see if it is working as desired if that diff algo is applied to any other block time. NLG has only about 1/3 of the diff increments in 24 hours when compared to a 60sec block time network. Both DigiShield and DGW3 were desired expressly for a 60 second block time, Digicoin in the former and DarkCoin in the latter. This is why neither Digi nor DGW3 are effective without tuning.
I don't really agree. The main variable that drives the DGW3 calculation is the average block time for the past n blocks. Hashing power can be added/removed instantaneous. It's not like hashing machines need to "warm up" and slowly increase their hashing speed over a few minutes or hours, so it doesn't make sense for any diff algo to take into account how many re-adjustments per hour are happening. Digishield is a much simpler and more elegant diff algo that scales easily and effectively, while DGW3 is very complex and does not scale well.
I wouldn't say DGW3 is very complex.. It's not even complex relative to Digishield, because the two look a lot alike. Please tell me how you think Digi is more elegant and what you mean with "scaling".. Where in the maths does Digi scale better than DGW3? I would fork NLG to a 75sec block target time with a 500NLG reward that retargets every block using a custom Digishield implemtation.
Blockreward is nowhere near related to the difficulty algorithm.. It wouldn't have anything to do with Digishield... (....) This would reduce any 'stuck network' time by 50%, increase the number of diff increments per 24hrs by 100%, reduce the number of blocks that Clever can mint per 24hrs by 80%, and make NLG a much better network for micro-transactions.
How did you figure out these numbers ? Please don't take these remarks personally.. I'm merely pointing out that with the hashrate/sec spikes we're experiencing; both DGW3 and Digishield won't handle it. I know I haven't been active the last week or so, I'm sorry for that. But please keep in mind that we want a permanent and solid solution. We actually need a more complex algo... |
|
|
|
Good Morning Guldencoin Community! I have some great news to share with you. The early release of the diffsim has just been pushed to GitHub. This version contains a simple hashrate wave simulation and the DGW3 algorithm. The first things on my TODO list are: larger waves simulation and jump pool simulation. A graphical user interface might be added later, especially having something to render graphs would be great. This version is not very user-friendly yet, so expect a bumpy ride. https://github.com/GeertJohan/diffsimI welcome contributions to this project very much! Feedback is welcome here, and in the thread on the official forums: https://forum.guldencoin.com/index.php?topic=707.0Good it is ready, GJ  When translated other algo's in Go, can this be implemented easy? The larger waves and jump pool simulation, takes it a lot of work further more or was this the most intensive work done. I have no idea, just asking what to expect, think most of us have no clue about the time needed to do such work. I cannot assist, not a programmer, hope others can. What needs to be done now will be easier. Initial work was the hardest part. I have released already so others might help |
|
|
|
Good Morning Guldencoin Community! I have some great news to share with you. The early release of the diffsim has just been pushed to GitHub. This version contains a simple hashrate wave simulation and the DGW3 algorithm. The first things on my TODO list are: larger waves simulation and jump pool simulation. A graphical user interface might be added later, especially having something to render graphs would be great. This version is not very user-friendly yet, so expect a bumpy ride. https://github.com/GeertJohan/diffsimI welcome contributions to this project very much! Feedback is welcome here, and in the thread on the official forums: https://forum.guldencoin.com/index.php?topic=707.0 |
|
|
|
Damnit, /GJ... making me learn GO. lol
Let me see if I can figure this out.
-Fuse
Awesome! Let me know if you need any help. |
|
|
|
|
Show Posts
