Considering the conversation has been taken to the Dutch section of the Gulden forum, I'm going to take it that my input isn't welcome anymore. Either way, if Google translate is halfway correct and I'm reading it right, Rijk and the team will look at ready to pull Git code. So I updated the git-pull, correcting the errors that /GJ noted. https://github.com/nlgcoin/guldencoin/pull/8Stop making excuses, stop dragging your feet, and just fix the damn algorithm already. -Fuse |
|
|
|
no config file.... do i just create one and put it in the AppData/roaming/tagcoin folder...
Yes. That will get it going with the proper addnode, and get you synced to the same chain the pool is on(if their is another chain in the wild somewhere). Heading out for the night. I'll check back in come morning. -Fuse |
|
|
|
Well I replaced the .dat on windows and it shows the correct wallet addy.... now if I can get it to sync I will be in business  Now we're talking! Let me know how it goes. Cheers! -Fuse |
|
|
|
I added the conf. file but it crashes the app now...must need to add more to it....
is it possible to move the wallet.dat file from a mac to a PC wallet.... i would open a PC wallet but still need to get all those coins....
I would guess that it would be, however, I would still make a backup of the file to make sure that you have a good copy. Or you could export the private key and import it on the windows computer. Does the wallet give you any errors when it opens? That would help pinpoint the problem. My conf file has the following in it, although some of the addnodes aren't relevant anymore: rpcuser=**********
rpcpassword=**********
addnode=tagmining.com
addnode=tag.hashfaster.com
addnode=tag.botpool.net
addnode=tagcash.com
server=1 Mind you, I've only ever ran the wallets on a windows and linux, but that's what I've run with since day one. You may need to add a user and password. It's worth a shot for that much coin. -Fuse |
|
|
|
|
According to another thread I found in on this forum for "mac wallet config file", the config file will need to be created in the ~/Library/Application Support/Tagcoin folder. That's where you will find your wallet.dat file as well. Just create the file with the name tagcoin.conf, add the "addnode=tagmining.com" line to it, and restart the miner.
6000TAG isn't something you want to just walk away from, mate. We'll get it figured out.
-Fuse
|
|
|
|
Looks good, Bram!
-Fuse
Thanks fuse! I'm sorry I can not join the conversation it's too difficult for me No worries, mate... google translate only goes so far  I'm trying daily to keep up with the Gulden forum posts in Dutch... I know how you feel! -Fuse |
|
|
|
hcf27, within the context of all you've highlighted here, what are the ramifications for continued performance of POT's blockchain? If it's so unprofitable to mine, will the corresponding reduction in difficulty be commensurate with improving returns to see enough miners maintain the network? Or is there are real possibility the network could start failing because there's just not enough miners?
I'm a long term holder of POT and believe the dev team has been honest and reasonably committed, however I take all your points seriously versperwillow and see you're highlighting the major stumbling block of this thing being relevant, let alone successful.
The market will find a new balance. At first less people will mine, you can already see this on the total hashrate of the coin that has descended to around 3ghs... however the cut on supply should bring the price up and those people who mine will get less coins but at a higher price, bringing miners back. Difficulty will also decrease at first and will play its part, but all in all the markets should stabilize after a while, it will be interested to see how it plays out this next few days. It is important to state tho that this is in THEORY what should happen, but there are other factors to take into account that are unpredictable: Investors selling their coins, confidence in the dev team, marketing efforts, etc... [/quote] The problem though is that this is the theory that put POT in the position it is in now. Halving the coin didn't increase the price then and it won't now. Halving the coin won't drive up demand. As long as there is POT for sale on exchanges, and little to no use for it's intended purpose, there won't be a demand. At one point people could make money mining POT, so they mined it. After the first halving, the price needed to double, instead it stayed the same and even went down a bit. So it was effectively half as profitable to mine. Then it went down in price again, to around half of what it was after the first halving, and it halved again. That's yet another decrease in per-block profitability. Demand can't be increased by halving. That's the logic that doomed this coin. Check any coin that radically changed it's block halving/values mid-mining to "increase demand", and see where they are now. You may find 1 or 2 that are still around, but the rest are dead. Demand can only be increased by adoption. Unfortunately, without any legitimate adoption in the markets this coin was conceived for, then this coin will continue to flounder. And yes, CCN may only have 1 shop that accepts it for MJ sales, but last I checked that was an infinity percent greater adoption rate for MJ purchases than POT. -Fuse |
|
|
|
Fuse makes VALID points. From reading how things have been posted lately, I feel he's been shunned and targetted for trying to help, and he's the only one from the outside trying to help!!! So what gives?
I'm not going to deny that the way the errors were presented weren't a little upsetting to me and my team. When /GJ and I were discussing the issues in IRC, he asked if we should make a post about not moving forward with the change yet. I suggested that we state that the code still needed to be worked on, improved and tested, and that my team would provide full support with testnets, hashrate, etc. What the community got was a little different from that. My team wasn't exactly happy about it. We worked to provide support when support was lacking, and we made a single line code mistake that ended up causing this delay. That being said, I don't see it as a shunning so much as another excuse to delay a change. /GJ said himself the only reason he's going forward with it is because the community demanded it: 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 better solution. Not DIGI. A better solution. I understand that things take time. I understand that things need to be tested, including the validity of the simulator. But you aren't going to find a more effective method of dealing with CM any time soon that doesn't involve a massive overhaul of the entire codebase, or an extremely long period of testing. If you want to test DIGI against the simulator, so be it. I'm all for seeing if it can accurately simulate real mining. But don't delay what has already been delayed for 4 months while we wait for a tool that won't fix the issue. And let me be clear- I wholeheartedly want the simulator to succeed. But it's a long term project that doesn't need to be mutually exclusive of the algo change. Fix the mistake that was made when DGW3 was implemented, and work on whatever you want to work on for the future of the coin. In the meantime, without a code change, we're dealing with this still:  While the code we uploaded had a small error, the algorithm was in fact providing results. If the devs don't trust the results, I suggest they start up a testnet and test it themselves. Or the community. Or anyone for that matter. Real mining data that can be quantified and examined in real-time by anyone. Just don't sit around playing it ultra-conservative because you want to wow the community with some new innovative idea or tool. Push forward, make the changes that need to be made and refocus on the your future goals. This change doesn't need to be the last change this coin ever makes. If we have to push out another update at a later time, so be it, but at least we didn't sit around while 45 million more NLG get mined by CM. 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.
Two things I take from this post, and I could be extremely wrong, but I'm going to take a stab at it anyway. First, DIGI isn't hard for /GJ to implement. So he could have it done now if he really wanted to. Second, there is already live blockchain data out there, and my "erroneous" testnet data, that proves DIGI works to mitigate jumping pools like CM. Why delay if you have both parts of the equation? Just solve for X already. -Fuse |
|
|
|
I've had time to reflect on the changes I posted, the things /GJ noted, and I've come to some conclusions. People are not going to like what I'm about to say, but I'm going to say it anyway to get it off my chest. 6. Responsibility You are responsible and the rest of the community. If you say that we have to implement something, we will. That is what’s happening with DIGI, but Geert-Johan looks at the code before he implements something. And in this case he saw that some things didn’t add up, things that could’ve caused bigger problems. Bigger than we’re facing now. But Geert-Johan can’t just say that something isn’t right. He needs to present proof and discuss this with the person that delivered the code, in this case Fuse. After this conversation it was decided not to implement this code, but further development was chosen. It's the exact reason I asked Rijk to double-check the code on his end(/GJ). I knew the code was alpha. It wasn't catastrophically incorrect though. The problems Rijk mentions is that the line in the code we used to adjust the difficulty(albeit incorrectly) would have caused the past blocks on chain to not sync properly if you resynced. That portion of code had nothing to do with algorithm, as noted by /GJ in IRC chat. So the answer to this is to not change it from it's original version. DIGI would have reacted the same way with modified values in this block of code(the correct difficulty adjustment code): if (nActualTimespan < (retargetTimespan - (retargetTimespan/4)) ) nActualTimespan = (retargetTimespan - (retargetTimespan/4));
if (nActualTimespan > (retargetTimespan + (retargetTimespan/2)) ) nActualTimespan = (retargetTimespan + (retargetTimespan/2)); My error wasn't catastrophic, and it could have been easily corrected. DIGI would still react similar to the graphs I provided. We can move past this "it's done when it's done, so stop asking us about when it will be done" mantra that we've heard for 4 months now. /GJ could go back to working on the simulator, and proving it's results against a testnet's results. This is still paramount to it's credibility in my mind. Yes, math is math and it will never be wrong... unless it is wrong or there are variables not introduced. Relying strictly on an unproven simulator is as blind-sighted as implementing a community member's code without looking over it first. 7. Decentral If Geert-Johan didn’t look at the code, or hadn’t discovered that the code wasn’t good, we would’ve implemented it. Because the community asked for it, it is decentral, so the majority decides. Very simple. Realize that this comes with huge responsibility. Everyone has that responsibility, you help decide Guldencoin’s future. No, you wouldn't have. You would have always had him look at it. That's what a smart dev would do. Additionally, if the code was in question, and a solution was needed to stem the effects of CM, the DIGI devs could be contacted to help with the custom changes. They openly announce their willingness to help coins implement DIGI. It's not because they get paid for it, it's because they know it's the algorithm that best mitigates multipool influence. But this was rejected by /GJ on a few separate occasions because "the change is not difficult". If it's not difficult, why not make it happen? Additionally, people are correct in that no difficulty algo right now will do that completely. No difficulty algo will do that in the foreseeable future of crypto. Yes, you could move to CPU/GPU based mining or POS, but you lose a considerable amount of community in making those changes. DIGI buys us time, and aligns us with the current era of MP mitigation. I feel like we're sitting around waiting for someone, maybe /GJ, to develop the next best algo ever. But how long is that going to take, and is NLG going to be the guinea pig for the implementation? But the real question here is this- if /GJ is checking community submitted work, who is checking him? This presents us with a single point of failure and acceptance. Who checked /GJ's DGW3 code results when the decision was made to implement it? I'm going to guess it was /GJ. There needs to be a second set of eyes in the code team. My code errors prove that. There always needs to be someone to check the other person's work. Who is the backup in the dev team? 8. What now? Geert-Johan is continuing work on the simulator and will test DIGI too, if the outcome says that DIGI is the solution, that will be implemented. If DIGI is not the solution, Geert-Johan will continue the development of the custom algorithm. This is the path that we are following and is, according to us, the only solution. Note, according to us. Other developers can look for a different solution, in the end the community decides. Unfortunately, it's not that simple. For anything to be taken seriously now, it will have to be proven by the simulator. The simulator that hasn't been proven against testnet data yet. But the problem lies in that the simulator is in GO. Sure it's a hop, skip, and a jump away from C++, but how many people honestly know GO in this community besides the person who wrote the simulator? So where does that leave us? Again... with a single point of failure and acceptance. We can't just drop some code in to the simulator and test things. We need to port it to GO ourselves, or present it to /GJ to port it. There's no community involvement when the community isn't able to be involved. Yes, /GJ is a great coder... we know that. But aligning the code so he is the only coder is not the way to go. So yes, learn GO, outsource a dev, etc etc etc. Fact of the matter is that /GJ had 4 months to focus on algo development. Instead of the algo change, he coded a simulator, still unproven, with an algo we've already proved doesn't work. Wouldn't it have been more productive to start with something that you would want to test, rather than something you want to move away from? DGW3 doesn't work. We don't need to know why after 4 months of dealing with it's failure. Move on to something else that does. 9. Communication There are a lot of questions about this, with most frequently: When is it done? I can understand that, but unfortunately the answer is short: when it’s done. That’s the way it is. I have asked Geert-Johan to just focus on development and not on updates. He can’t say when it’ll be done, but he will solve it. Maybe other developers can give this information and present a specific roadmap. Actions will always speak louder than words. It took my team 1-2 weeks to change the code(yes, slightly incorrect), set up 2 pools, confirming nodes around the world, a block explorer, and test mining on a testnet. 24Kilo's 14yo son wrote a pearl script to pull data from the debug.log files to parse block data before we had a block explorer, giving us early block difficulty change data. In two weeks we were able to provided more direct effort towards making a change than we've seen in 4 months of CM rape. We got tired of waiting and we acted. I'm glad we did, regardless of the final outcome. If my team lost face with our inability to provide 100% correct code, I'm ok with that. So take my post as being overly critical, or angry, or short-minded, or whatever you want to take it as. To me, it's just me being honest to myself and saying what I'm thinking. Some people may not like that, but like I said, I'm in it for the long haul. Like me or hate me, my pool will continue to run, my physical coins will continue to sell, and the Criptoe team will continue to try to provide additional support to NLG in any way possible. Just don't expect us to accept inaction... we've been waiting for 4 months too long now for this change. -Fuse |
|
|
|
I think its the peers.dat file that needs replacing with updated IP's but not sure...
What block number are you on? The pool is currently on 153792, as of 7:40am PST. Here is a transaction in the last 10 transactions on the server wallet:  If your block height doesn't match the pool, you're on another fork. This is why you need to add the line "addnode=tagmining.com" to your tagcoin.conf file. Remove all the other addnodes for now. Delete everything, directories included, EXCEPT the wallet.dat file. Make a copy of wallet.dat before you delete anything. If you delete wallet.dat, your money is gone. Then restart the client. It will connect to the pool, and we can make sure that the issue isn't a syncing issue. Do that and let me know what happens. Past that, I'm not sure how to help you, as the wallet address you use to mine coins is being sent coins according to the blockchain. -Fuse |
|
|
|
I tried the following from the Terminal--- its syncing, so we will see
open /Applications/TagCoin-Qt.app --args -addnode=tagmining.com
Sounds good, mate. Heading to bed now, will check in when I wake up to make sure it all went ok. Cheers, Fuse |
|
|
|
i think this is it for a Mac
open /Applications/TagCoin-Qt.app --args -rescan
Rescan will do just that, rescan the blockchain to make sure it's updated. However, if your nodes are forked, you're just going to get the forked chain. Adding tagmining.com as an addnode line to your config will keep you synced to the pool, which should always be on the latest block. -Fuse |
|
|
|
I was mining on Tagmining.com from "Total Blocks" 241-252 using my Cryptsy wallet address until the post stated they did not update their wallet. At that time I switched to my wallet-
My question is that I should be seeing payouts now to my wallet since the blocks being confirmed are in the "total blocks" 265 range---and I am not seeing anything...
Keith
You should be seeing payouts to your address. No funds are held on the server, so make sure that your address is correct. That being said, PM me your address, and I'll look at the transactions. -Fuse Edit: @Tagbond, can you resync the block explorer please? Cheers |
|
|
|
I just can't seem to manage to get the QR so small to fit, office, paint and others won't let me srink it enough  , anyone any tips? I used Adobe Illustrator when I created the QR code wallets. I was able to scale the image down without much loss of quality. -Fuse |
|
|
|
/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. Sounds good. I just want to note though, that while the code I provided wasn't 100% correct, the graphs I provided were 100% typical of a DIGI implementation. You will always return to a "baseline" difficulty, rather than a false low caused by the averaging equation. The removal of the false lows are enough to mitigate around 70-80% of CM's influence. How DIGI works isn't difficult to understand. If nActualTimespan(actual block time) goes over nTargetTimespan(150 seconds in our case), the difficulty goes down proportionately. If nActualTimespan is less than nTargetTimespan, difficulty goes up proportionately. The key difference between DIGI and DGW3, besides the removal of false lows caused by a moving average, is the the immediate retarget instead of a delayed retarget caused by the averaging. I'm sure you know why and how it adjusts properly though... you had it a better understanding of the code in the 20 minutes we chatted than I will probably ever have. How much data are you looking to collect before you move forward? Also, when will the DIGI port and large-wave code be posted to github for community testing? -Fuse |
|
|
|
Would be nice to see a how-to video as Fuse suggested a few days ago. Also good for later buyers of the coin and info in the shop.
I know, mate... I've been slacking on this. I'm sorry. The whole family has been sick for the last few days, so I haven't had a chance to put aside some time to do it. I'll try today, though. -Fuse |
|
|
|
Clever is hitting us hard again Have they ever stopped? CM is a cancer. Take a look at the last month or so of their forum thread( https://bitcointalk.org/index.php?topic=448649.0). Even the miners there are questioning what is happening with CM. Missing payouts, Terk being absent, etc. I don't understand how anyone could run a pool like that and continue to gain miners. /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. -Fuse |
|
|
|
Wanneer komt guldencoin op Cryptsy?
Hoe later hoe beter... Kan je uitleggen wat je daar mee bedoelt en op welke wijze dit slecht zou kunnen zijn voor de guldencoin? Having Gulden listed on Cryptsy allows multipools that use Cryptsy's APIs to determine profitability to include Guldencoin in their mining schema. Essentially it would open the door to additional multipools at a time when we can't handle one. Cryptsy might be an option when an algo change is completed, but at this time it's just not needed. Additionally, most coins that go to Cryptsy are subject to bot auto-trading and pump and dump group activities. It's not a place for coins that value stability and longevity. I hope the explanation doesn't get lost in translation -Fuse |
|
|
|
It's ironic that you mention noobs considering the people from the Guldencoin community that have posted here have all been here longer than you. And that's the disturbing fact, being still noobs that believe in shitcoins after having been here for so long. I'd like to know if you consider anything other than LTC or BTC a viable coin. Hell, people used to call LTC a shitcoin. It's obtuse to think that alternative systems of payments can't be used in niche markets. NLG fills a niche market that yearned for a return of the currency that was replaced by the euro. It's a brilliant business plan that has been proven successful by the people using it on a daily basis. A considerable amount of people, by the way. The adoption rate of NLG is faster than that of any coin I've ever been involved with, including LTC. To top it off, it's all community driven. You keep arguing this whole "it's just a shitcoin" thing, but you're talking to someone who tried to lead a charge against them before you were even registered: https://bitcointalk.org/index.php?topic=222015.0. I hate the pump and dump coins that flood these forums with a passion. I've been following coins long enough to know that NLG is not one of these coins. I still want to hear from Terk though... the ever-absent pool op. Is clever just around to "rape shitcoins"? Your miners seem to think so. -Fuse |
|
|
|
|
Show Posts
