BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.
DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)
BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?
DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.
As I understand the long maturity time is only for newly mined blocks so it wouldn't affect daily use that much? |
|
|
|
So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.
Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.
I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.
If I am understanding the proposal properly, it seems a good alternative not because big pools won't be able to find a lot of blocks, because most probably they will be mining most of them, but because it makes the mining not profitable enough and as such they go to the next coin. Once that happens, the block findings will return to the finders who are always mining because big pools have left the building. Is my interpretation correct? Yep, thats the idea. But even if those pools stay they are put in a position where the impact on the network is much less. But my assumption is they leave the coin alone because it's not profitable anymore. I'm also big fan of BTM 's solution its simple and effective at least on paper. But I still don't comprehend why DWG doesn't work for Guldencoin as it does work for other's. |
|
|
|
Let the price drop another 200 sat and we can see if clevermining still has major impact.
Really, this is not a solution in any way. I agree! but i do think a price drop will occur. |
|
|
|
Don't cry every little thing is gonna be alright.  Did the dev team contact the developers of DGW3 as I read somewhere a while ago that they helped implement with other coins. Maybe they can help fine tuning it to 2.5 min blocks as it is designed for 1min blocks. The solution that Geertjohan gives also works, does it require another hard fork? If so maybe a longer maturity time like casinocoin can also be included? I personally like that solution. I would never ban IP's that just doesn't feel right. You cannot really blame clevermining as they only use a little flaw in our algorithm. |
|
|
|
Hi,
BTW great coin, but before I buy some NLG up I just want to make sure on something. I gather the below addresses is for your spacedrop to the dutch people. I notice all 150 million is still in those addresses? Has no one claimed or...
Cold Storage 1: GYhkHEHFSwjVaq7Bt9Akm9EHDMamiWkPZb
Cold Storage 2: GLjU6est4NXFri3Rmx2SnA9PzFdYsm1Tcb
Cold Storage 3: GK3g74iYY5cCHF8AscMgPUBSRV7kicwRR4
I can't answer your questions but welcome and join the Guldencoin forum it has an English section you can ask over there https://forum.guldencoin.com/index.php |
|
|
|
Dear Guldencoin community, SWISSCEX updated the wallet to v1.3.0 and the market is open again. Happy tradding Best regards, Lukas / SWISSCEX Thank you Lukas  and bittrex? Trading works but wallets still offline. |
|
|
|
Big applause for the Dev team and ofcours to all people related to Guldencoin! Be proud of yourselfs cause I know for sure the community is! |
|
|
|
Looks good. Lots of quality info . Donated some coins. Much appreciated, thank you. Still no confirmations yet. |
|
|
|
Looks good. Lots of quality info . Donated some coins. |
|
|
|
Terk has gotten back to me. He had originally limited the hashrate that was mining on NLG to a 4th of the total hashrate of the pool. He has decreased that to an 8th of the total hashrate. He asked that we monitor the chain and let him know how it looks.
While he hasn't agreed to stop mining NLG, he did agree to work with us to get things running smoothly.
-Fuse
Just to correct things. We put less than 8th of our pool hashrate to NLG. CleverMining always had an algorithm to limit amount of hashrate pointed at any coin depending on coin difficulty, to don't pump the coin difficulty too much. It works great with DigiShield coins and works well with most KGW coins. I'm not sure why NLG is different here. Maybe KGW doesn't work well with longer times between blocks (most coins these days have 60-second blocks)? What I did is limited amount of hashpower pointed to NLG to 1/8th of what we point at any other coin with the same difficulty. This isn't related to our total pool hashrate, it's related only to coin difficulty and expected time to find a block. We adjust our maximum allowed hashrate to coin difficulty to don't find blocks too fast. NLG has 8x handicap here from now on. This means we allow 8x less hashpower pointed to NLG than to other coins at the same difficulty. NLG difficulty already dropped after this change and remains steady. Times between blocks started being more regular. I hope this will help regular pools to also find good blocks and will prevent high difficulty jumps and long times between blocks. We don't want to withdraw away completely from NLG as we have responsibilities to our users. We promised them to maximize their profits and to mine coins which are profitable. But we also don't want to harm coins and this is why I wanted to find some middle ground between CleverMining users interests and Guldencoin community interests. I hope I found the right balance. I will keep this 8x handicap until Sep 26th when I heard you plan to launch the new difficulty readjustment algorithm. Thanks for stepping up and making the change, it helps us all in the long run! Thank you! Just Amazing ! |
|
|
|
Cool stuff! Interesting times ahead. |
|
|
|
Nice! |
|
|
|
|
Can you scan private keys with the Android wallet?
|
|
|
|
Crosspost from this Guldencoin forum topicGuldencoin Explorer betaThe Guldencoin team is continuously working to improve the fundamental tools that power the coin and serve this great community. It's only a day ago that we migrated the forums to a more ddos-proof location, and now it's time to release our next project: the Guldencoin Explorer beta. This is a block explorer that I've been working on for the past few weeks. It's a new explorer, written from scratch. At this time the explorer supports basic functionality, more features will be added as development progresses. Because this is new software, there is some precaution advised. Don't use this explorer as a definite source of information yet, as data could be missing. For instance, support for non-standard transaction scripts is not available yet. As this is a beta, the explorer might not have 24/7 uptime. It might crash and needs to restart for updates now and then. If you notice a bug or mistake, please report this! We cannot fix what we don't notice. Have fun! https://explorer.guldencoin.comMy compliments with the result GJ! it's working like a charm. You even made some nice gadgets with it, great. If I can help out on hosting this, send me a PM. Yes really nice work GeertJohan! There's a little typo on the about page in the change log section. View transactino details with list of vin/vout's. |
|
|
|
Crosspost from this Guldencoin forum topicGuldencoin Explorer betaThe Guldencoin team is continuously working to improve the fundamental tools that power the coin and serve this great community. It's only a day ago that we migrated the forums to a more ddos-proof location, and now it's time to release our next project: the Guldencoin Explorer beta. This is a block explorer that I've been working on for the past few weeks. It's a new explorer, written from scratch. At this time the explorer supports basic functionality, more features will be added as development progresses. Because this is new software, there is some precaution advised. Don't use this explorer as a definite source of information yet, as data could be missing. For instance, support for non-standard transaction scripts is not available yet. As this is a beta, the explorer might not have 24/7 uptime. It might crash and needs to restart for updates now and then. If you notice a bug or mistake, please report this! We cannot fix what we don't notice. Have fun! https://explorer.guldencoin.comMy compliments with the result GJ! it's working like a charm. You even made some nice gadgets with it, great. If I can help out on hosting this, send me a PM. Yes really nice work GeertJohan! |
|
|
|
Just a quick question for Geertjohan when I generated a vanityaddres and don't import the private key in to the Guldencoin client but instead load it in the paperwallet generator to create a cold storage does this work? Edit: I'm at home now and tried it and it works |
|
|
|
@geertjohan when I using your vanitygen tut I get an error when I type ./vanitygen -X 38 Greg It says that bitcoin starts with a 1. And when I type ./vanitygen -X 39 Greg it generates an adres an privkey but when I try to import it the console says invalid privkey error -5. Am I missing something You must use -X 38, to get the correct address version for a Guldencoin addresses. Not -X 39 The problem you're having is that the prefix sequence is not valid for Base58Check encoding (aparently). Try `./vanitygen -X 38 GReg` for instance, that will work. More info aboute Base58Check: https://en.bitcoin.it/wiki/Base58Check_encodingOk generating worked but now I get error adding key to wallet code -4 Is your wallet password protected? If so, unlock it first with `walletpassphrase <password> <timeout>` A timeout value of 30 is fine, so you have 30 seconds to add the privkey. When you have added the privkey the guldencoin-qt application, or even the whole computer, might seem to freeze. This is because the application is working very hard to scan all old blocks for transactions to the key. If you are sure that no transaction to the key happened in the past (because you've only just generated the address and not sent anything to it yet) you can disable the rescan for a fast import: `importprivkey <key> "my new address" false` Yes my bad, I think that's the solution but now I'm not at my computer I'll try when I'm at home. Thanks for the help! |
|
|
|
@geertjohan when I using your vanitygen tut I get an error when I type ./vanitygen -X 38 Greg It says that bitcoin starts with a 1. And when I type ./vanitygen -X 39 Greg it generates an adres an privkey but when I try to import it the console says invalid privkey error -5. Am I missing something You must use -X 38, to get the correct address version for a Guldencoin addresses. Not -X 39 The problem you're having is that the prefix sequence is not valid for Base58Check encoding (aparently). Try `./vanitygen -X 38 GReg` for instance, that will work. More info aboute Base58Check: https://en.bitcoin.it/wiki/Base58Check_encodingOk generating worked but now I get error adding key to wallet code -4 |
|
|
|
|
Show Posts
