GoldCoin Talk
Main Category => Technical Discussion => Topic started by: MicroGuy on June 11, 2013, 06:43:39 AM
-
As many of you are probably aware, we are working to secure a talented developer for fixing the code.
Ultimately we must put into place a development team so that the future of the coin never rests in the hands of a single individual. Once we get the immediate technical issues resolved and the network stabilized I feel it is critical that we get to work putting into place a mechanism that will prevent a single person from bringing the coin to its knees.
According to my sources, we need to start making some very critical decisions this week regarding the code. So let's get to work.
-
Do we have a list of things that need to be decided? Is it going to be community orientated as to what the features are? Lets get to work :)
-
Do we have a list of things that need to be decided? Is it going to be community orientated as to what the features are? Lets get to work :)
Here's a quick list of off the top of my head:
1. How to notify users, pool operators, and exchanges.
2. What exact changes are needed in the code.
3. How to secure a secondary developer as backup?
I've been in touch with a developer, who has no time for this project, but did review the proposed changes made by Hyoshi and feels that the changes proposed are indeed sound.
-
What are the list of changes proposed though?
-
What are the list of changes proposed though?
Here are some proposed changes from the Nibble developer from a previous thread:
All, I am the dev of "Nibble" - my coin has been near the top of coinchoose.com on and off for the last few weeks. I can do whatever you want really with this coin. Some ideas I have are to change the fork to 20,950 - its currently set to fork at 21k. you guys will have to spread the word of the update, get cryptsy to install it and all that.
I would change the block time to 1 minute, make the difficulty retarget something like 250 blocks, make the max difficulty adjustment around 110% (makes attacks or spikes less effective or impacting), and change the coin maturity to 50 confirms - the current 100 for a coin with so few miners is insane. I would keep the block reward at 500 but have it 1/2 every x amount of blocks (way out in the future)
These are not things the dev did wrong - its just that no coin is ever intended to be mined with under 10 mH/s total.
I can make these changes immediately and have a build for you tonight - I have dealt with gldcoin (we swapped nodes to improve both networks) and he told me that he will let me take over his dev duties. He said that he just has no time at the moment, he's swamped at work, swamped at home or something.
-
The main thread at Bitcointalk needs regular amendment on the first page: and URGENTLY with the address of this forum !
gldcoin has that under his user control at bitcointalk.
-
The main thread at Bitcointalk needs regular amendment on the first page: and URGENTLY with the address of this forum !
gldcoin has that under his user control at bitcointalk.
Only gldcoin can do this, Microguy can you speak with him and get him to amended or lock the thread so a new one can be made with the correct information?
-
What are the list of changes proposed though?
Here are his proposed changes from the previous thread:
All, I am the dev of "Nibble" - my coin has been near the top of coinchoose.com on and off for the last few weeks. I can do whatever you want really with this coin. Some ideas I have are to change the fork to 20,950 - its currently set to fork at 21k. you guys will have to spread the word of the update, get cryptsy to install it and all that.
I would change the block time to 1 minute, make the difficulty retarget something like 250 blocks, make the max difficulty adjustment around 110% (makes attacks or spikes less effective or impacting), and change the coin maturity to 50 confirms - the current 100 for a coin with so few miners is insane. I would keep the block reward at 500 but have it 1/2 every x amount of blocks (way out in the future)
These are not things the dev did wrong - its just that no coin is ever intended to be mined with under 10 mH/s total.
I can make these changes immediately and have a build for you tonight - I have dealt with gldcoin (we swapped nodes to improve both networks) and he told me that he will let me take over his dev duties. He said that he just has no time at the moment, he's swamped at work, swamped at home or something.
I think these changes are a good idea, however will changing the folk to 20950 be advise seeing we are so close to this block currently?
-
The main thread at Bitcointalk needs regular amendment on the first page: and URGENTLY with the address of this forum !
gldcoin has that under his user control at bitcointalk.
Only gldcoin can do this, Microguy can you speak with him and get him to amended or lock the thread so a new one can be made with the correct information?
Ideally, the webmaster should just forward the entire domain to this forum. We also need to think about creating a new official thread on bitcointalk listing this website as the official forum.
-
Looks like good news! I will be making an announcement shortly. :)
-
I only have a minute, so I wanted to quickly demonstrate my stance on no more hard-forks. We are at 21938, and we have gotten 35 in the last 12 hours. At this rate, we should be done and at block 21k in a mere 24 hours. I believe rather than thinking about more hard-forks which would bring more hardship to the coin, we should instead just focus on building infrastructure and getting miners and such on the coin!
-
I only have a minute, so I wanted to quickly demonstrate my stance on no more hard-forks. We are at 21938, and we have gotten 35 in the last 12 hours. At this rate, we should be done and at block 21k in a mere 24 hours. I believe rather than thinking about more hard-forks which would bring more hardship to the coin, we should instead just focus on building infrastructure and getting miners and such on the coin!
You mean we are at 20938. ;)
-
I agree, at this point, lets just wait for the fork at 21k because that's only 58 blocks away
You must be also careful not to attract to much attention going into the form so a hash rate attack is not deployed to raise the difficulty.
I think after this hard fork, a decision should be make regarding another hard fork and whether to change the block speed, difficulty adjustments etc
There is no reason not to do a hard fork if it will help the coin, and there are many things you can do to make it a popular coin to mine. If its popular to mine, then investor's will want to buy gold which will raise the value, and open doors for the coin.
-
so im a little confused on what exactly happens at the hardfork. Is it just a diff change? Should we stop mining after hardfork? I think others out there don't know exactly what will happen and what miners should do. Should we restart our mining rigs immediately after 21000 block? Anyone with any insight?
-
so im a little confused on what exactly happens at the hardfork. Is it just a diff change? Should we stop mining after hardfork? I think others out there don't know exactly what will happen and what miners should do. Should we restart our mining rigs immediately after 21000 block? Anyone with any insight?
Mining becomes much much more profitable after hardfork, that's what happens.
-
I'm currently in communication with the original developer (GLD). Update to follow. Yes, It's good news! :)
-
so im a little confused on what exactly happens at the hardfork. Is it just a diff change? Should we stop mining after hardfork? I think others out there don't know exactly what will happen and what miners should do. Should we restart our mining rigs immediately after 21000 block? Anyone with any insight?
at block 21000 diff will adjust.
-
...here's my update.
There are now three developers (at least) willing to help us with our project.
In addition, we now have the full support of gldcoin. He has volunteered to edit his first post, remove the outdated links, and then close the previous GLD thread on bitcointalk. I have already made the new official thread. He has also offered his services to the community (but they will be limited due to time constraints) and has offered to sell me the domain GLDCOIN.COM which I will pay for and then donate to the community.
My background is in domaining and hosting so I can handle the transfer and hosting of the name. I suggest we use this domain as the official website of Goldcoin. Maybe a community member(s) will volunteer to build the website. I don't want to get too off track so we can discuss these plans in another thread. The good news is that we have universal cooperation which was and is essential.
Now back on topic.
Anytime you are building a team of talented individuals, you will be dealing with egos. It's important that all of us (including myself) remember that what we're doing here needs to be in the best of interest of Goldcoin. We will not always agree. Now I think what we should do is narrow down the options available to us in terms of dealing with the network problem. So I propose that we hear from ALL the experts, weigh their opinions, and then collectively reach a decision.
It is the community and the idea that is all powerful. I am simply contributing my time and energy like everyone else here. And I do understand that it's the "collective energy" that is the all powerful and unstoppable force.
So let's get to work.
-
Keep the fork a secret so we aren't attacked directly prior. When it kicks in, as long as the hashrate is around what it is now, we are golden. The difficulty should drop, mining will be very profitable. If the difficulty drops enough, it will be the most profitable coin easily at this price. the key is you DO NOT want a bunch of new miners to come in with their large hash-rates and take all hat profitable mining from you. They will figure that out for themselves in the coming days. The difficulty will never rise by more than 140% (so you will never see a move from 1.5 - 7.5 roughly like happened a few weeks back.
-
...here's my update.
There are now three developers (at least) willing to help us with our project.
In addition, we now have the full support of gldcoin. He has volunteered to edit his first post, remove the outdated links, and then close the previous GLD thread on bitcointalk. I have already made the new official thread. He has also offered his services to the community (but they will be limited due to time constraints) and has offered to sell me the domain GLDCOIN.COM which I will pay for and then donate to the community.
My background is in domaining and hosting so I can handle the transfer and hosting of the name. I suggest we use this domain as the official website of Goldcoin. Maybe a community member(s) will volunteer to build the website. I don't want to get too off track so we can discuss these plans in another thread. The good news is that we have universal cooperation which was and is essential.
Now back on topic.
Anytime you are building a team of talented individuals, you will be dealing with egos. It's important that all of us (including myself) remember that what we're doing here needs to be in the best of interest of Goldcoin. We will not always agree. Now I think what we should do is narrow down the options available to us in terms of dealing with the network problem. So I propose that we hear from ALL the experts, weigh their opinions, and then collectively reach a decision.
It is the community and the idea that is all powerful. I am simply contributing my time and energy like everyone else here. And I do understand that it's the "collective energy" that is the all powerful and unstoppable force.
So let's get to work.
Good, well done.
Collective energy, that's what cryptocurrency,P2P, is all about. I dont have any coding skills or experience, but I will continue to contribute my unseen 'nudges' in the right direction: I have owned and run 4 businesses (employed up to 8 people) over the last 30 years, so I think I can make the right sort of impression on all types of personality.
-
Another thing i was thinking about when difficulty drops in a few days the big miners will notice the profability and start mining Goldcoins by the tens of thousands and dump them on the exchange. I am just afraid it will hurt GLD more. Have the devs thought about the reward per block.
-
I don't think anything OFFICIAL about the fork should be posted on bitcointalk.org at all. Just keep all OFFICIAL talk on GLDCOIN.com forums or here. Only those who are acutally trying to progress the coin should benefit from keeping up to date with what is going on. All imo.
-
Keep the fork a secret so we aren't attacked directly prior. When it kicks in, as long as the hashrate is around what it is now, we are golden. The difficulty should drop, mining will be very profitable. If the difficulty drops enough, it will be the most profitable coin easily at this price. the key is you DO NOT want a bunch of new miners to come in with their large hash-rates and take all hat profitable mining from you. They will figure that out for themselves in the coming days. The difficulty will never rise by more than 140% (so you will never see a move from 1.5 - 7.5 roughly like happened a few weeks back.
This seems like good advice to me. What do we need to do in order to execute this option?
-
Another thing i was thinking about when difficulty drops in a few days the big miners will notice the profability and start mining Goldcoins by the tens of thousands and dump them on the exchange. I am just afraid it will hurt GLD more. Have the devs thought about the reward per block.
if you drop the rewards per block, the coin will die - you can change things just because miners will mine, and miners may trade it away. That's really the whole point. If no one mines a coin - the coin dies.
Rather the effort should be made to improve the coins image and usability (where can you use the coin) in order to drive up the price.
Big miners only looks towards BTC profitability, and hopefully this will stay off their radar for a while - but in no way shape or form do you want them not to mine it.
And if someone wants to be involved but has a low hashrate - the best thing for these individuals to do is to buy LTC or BTC and buy these sell orders of GLD, investing in the coin. If everyone just hoards their coins, that is fine, but if no one actually buys the sell orders, the price will surely fall.
-
Keep the fork a secret so we aren't attacked directly prior. When it kicks in, as long as the hashrate is around what it is now, we are golden. The difficulty should drop, mining will be very profitable. If the difficulty drops enough, it will be the most profitable coin easily at this price. the key is you DO NOT want a bunch of new miners to come in with their large hash-rates and take all hat profitable mining from you. They will figure that out for themselves in the coming days. The difficulty will never rise by more than 140% (so you will never see a move from 1.5 - 7.5 roughly like happened a few weeks back.
This seems like good advice to me. What do we need to do in order to execute this option?
Really at this point just wait and see what happens at 21k. i have examined the code and it will work. From there we see how it goes when the fork kicks in. I for some crazy reason its attacked prior to the release, we would need to make another emergency form immediately and without warning - only letting cryptsy, pool operator's and key people. Then when its forked and the key people/infrastructure is using the forked chain, you let the world know. That is a worst case scenario - I think GLD is off heir radar for now and FTC/LTC are on their immediate list to try and destroy.
-
Another thing i was thinking about when difficulty drops in a few days the big miners will notice the profability and start mining Goldcoins by the tens of thousands and dump them on the exchange. I am just afraid it will hurt GLD more. Have the devs thought about the reward per block.
if you drop the rewards per block, the coin will die - you can change things just because miners will mine, and miners may trade it away. That's really the whole point. If no one mines a coin - the coin dies.
Rather the effort should be made to improve the coins image and usability (where can you use the coin) in order to drive up the price.
Big miners only looks towards BTC profitability, and hopefully this will stay off their radar for a while - but in no way shape or form do you want them not to mine it.
And if someone wants to be involved but has a low hashrate - the best thing for these individuals to do is to buy LTC or BTC and buy these sell orders of GLD, investing in the coin. If everyone just hoards their coins, that is fine, but if no one actually buys the sell orders, the price will surely fall.
Ok Hyoshi. In your estimation what should we do? and when?
Edit: According to Hyoshi everyone needs to make sure they have the latest binaries as listed on the official page at bitcoin talk and here in the how-to forum. We need to get the word out to everyone to update to the latest binaries.
-
Here are some proposed changes from the Nibble developer from a previous thread:
All, I am the dev of "Nibble" - my coin has been near the top of coinchoose.com on and off for the last few weeks. I can do whatever you want really with this coin. Some ideas I have are to change the fork to 20,950 - its currently set to fork at 21k. you guys will have to spread the word of the update, get cryptsy to install it and all that.
I would change the block time to 1 minute, make the difficulty retarget something like 250 blocks, make the max difficulty adjustment around 110% (makes attacks or spikes less effective or impacting), and change the coin maturity to 50 confirms - the current 100 for a coin with so few miners is insane. I would keep the block reward at 500 but have it 1/2 every x amount of blocks (way out in the future)
These are not things the dev did wrong - its just that no coin is ever intended to be mined with under 10 mH/s total.
I can make these changes immediately and have a build for you tonight - I have dealt with gldcoin (we swapped nodes to improve both networks) and he told me that he will let me take over his dev duties. He said that he just has no time at the moment, he's swamped at work, swamped at home or something.
It is too late to change the fork to be earlier IMO. I don't think I agree with your other changes proposed. The protocol was never meant for short block times. You can get away with it on smaller networks but it will bite you if you grow later. Also, for what happens to a coin with shorter block times take a look at i0coin. Till better solutions to the issues caused are created I would hold off increasing block times. As for caping the increase at 110% all the does is extend the time that the coin can be mined at a rate exceeded the designed for parameters without it readjusting to compensate. The reduction in confirms due to the low mining power is just madness. The purpose of the confirms is to make sure that block is locked in. With low mining power and miners able to switch power easily, you actually need more confirms not less.
What the dev did wrong was already create a fork with the new client release. This probably is what caused a lot of the issues seen since then.
-
Here are some proposed changes from the Nibble developer from a previous thread:
All, I am the dev of "Nibble" - my coin has been near the top of coinchoose.com on and off for the last few weeks. I can do whatever you want really with this coin. Some ideas I have are to change the fork to 20,950 - its currently set to fork at 21k. you guys will have to spread the word of the update, get cryptsy to install it and all that.
I would change the block time to 1 minute, make the difficulty retarget something like 250 blocks, make the max difficulty adjustment around 110% (makes attacks or spikes less effective or impacting), and change the coin maturity to 50 confirms - the current 100 for a coin with so few miners is insane. I would keep the block reward at 500 but have it 1/2 every x amount of blocks (way out in the future)
These are not things the dev did wrong - its just that no coin is ever intended to be mined with under 10 mH/s total.
I can make these changes immediately and have a build for you tonight - I have dealt with gldcoin (we swapped nodes to improve both networks) and he told me that he will let me take over his dev duties. He said that he just has no time at the moment, he's swamped at work, swamped at home or something.
It is too late to change the fork to be earlier IMO. I don't think I agree with your other changes proposed. The protocol was never meant for short block times. You can get away with it on smaller networks but it will bite you if you grow later. Also, for what happens to a coin with shorter block times take a look at i0coin. Till better solutions to the issues caused are created I would hold off increasing block times. As for caping the increase at 110% all the does is extend the time that the coin can be mined at a rate exceeded the designed for parameters without it readjusting to compensate. The reduction in confirms due to the low mining power is just madness. The purpose of the confirms is to make sure that block is locked in. With low mining power and miners able to switch power easily, you actually need more confirms not less.
What the dev did wrong was already create a fork with the new client release. This probably is what caused a lot of the issues seen since then.
Thank you for these ideas.
In your view, what is the best move for us to make at this point and time?
-
Here are some proposed changes from the Nibble developer from a previous thread:
All, I am the dev of "Nibble" - my coin has been near the top of coinchoose.com on and off for the last few weeks. I can do whatever you want really with this coin. Some ideas I have are to change the fork to 20,950 - its currently set to fork at 21k. you guys will have to spread the word of the update, get cryptsy to install it and all that.
I would change the block time to 1 minute, make the difficulty retarget something like 250 blocks, make the max difficulty adjustment around 110% (makes attacks or spikes less effective or impacting), and change the coin maturity to 50 confirms - the current 100 for a coin with so few miners is insane. I would keep the block reward at 500 but have it 1/2 every x amount of blocks (way out in the future)
These are not things the dev did wrong - its just that no coin is ever intended to be mined with under 10 mH/s total.
I can make these changes immediately and have a build for you tonight - I have dealt with gldcoin (we swapped nodes to improve both networks) and he told me that he will let me take over his dev duties. He said that he just has no time at the moment, he's swamped at work, swamped at home or something.
It is too late to change the fork to be earlier IMO. I don't think I agree with your other changes proposed. The protocol was never meant for short block times. You can get away with it on smaller networks but it will bite you if you grow later. Also, for what happens to a coin with shorter block times take a look at i0coin. Till better solutions to the issues caused are created I would hold off increasing block times. As for caping the increase at 110% all the does is extend the time that the coin can be mined at a rate exceeded the designed for parameters without it readjusting to compensate. The reduction in confirms due to the low mining power is just madness. The purpose of the confirms is to make sure that block is locked in. With low mining power and miners able to switch power easily, you actually need more confirms not less.
What the dev did wrong was already create a fork with the new client release. This probably is what caused a lot of the issues seen since then.
You are probably right on the 1 minute blocks, I was just throwing its out there as it was mentioned before by a few other people.
The problem i think is that you are failing to see the past history of the coin. This coin was attacked last minute to push up the difficulty to the current 7.34. This coin was in the scopes of many people since the beginning, and will surely be the target of future attacks. The cap I was suggesting would prevent these attacks from causing any huge spikes in difficulty. It will not extend the period a coin can be mined at a faster rate - the block re-targets are 504.
Here is some simple math:
4 difficulty changes of 110 % (440%) are actually more than 1 difficulty change at a original max 400% every 2016 blocks (which is what this coin was set to originally).
As for the confirmations, these numbers were pulled out of thin air. 120 is no safer than 60 confirmations once a coin is over difficulty 1. Do you really think that 120 wasn't just an arbitrary number in Litecoin and/or Bitcoin? I have had blocks waiting to mature for 4 days now - at its worst last week, it took 1 entire week for a block to mature. Now thats madness.
-
What the dev did wrong was already create a fork with the new client release. This probably is what caused a lot of the issues seen since then.
What did he do? Not sure I follow what he did. I thought he created a new client that would fork at 21K, from the looks of it he did what FTC did. How else would you do a hard fork if everyone doesn't have the updated client?
-
The problem i think is that you are failing to see the past history of the coin. This coin was attacked last minute to push up the difficulty to the current 7.34. This coin was in the scopes of many people since the beginning, and will surely be the target of future attacks. The cap I was suggesting would prevent these attacks from causing any huge spikes in difficulty. It will not extend the period a coin can be mined at a faster rate - the block re-targets are 504.
Mining a coin is not attacking it. You also can not attack a coin at the last minute, unless it is using a non standard buggy difficulty calculation, as the whole time period is considered. Namecoin had worse issues back in 2011 with miners hoping on and off it then this coin has had.
4 difficulty changes of 110 % (440%) are actually more than 1 difficulty change at a original max 400% every 2016 blocks (which is what this coin was set to originally).
Yes, so it is less bad. Capping the difficulty either way is still probably not the right approach (and yes I know the original btc code does do this).
As for the confirmations, these numbers were pulled out of thin air. 120 is no safer than 60 confirmations once a coin is over difficulty 1. Do you really think that 120 wasn't just an arbitrary number in Litecoin and/or Bitcoin? I have had blocks waiting to mature for 4 days now - at its worst last week, it took 1 entire week for a block to mature. Now thats madness.
It is not in Bitcoin. It is meant to be about a day. Idea was that the community would detect an attack before it went back a day in the block chain. Now in reality, with the value of a block, I am sure people would react about the same losing blocks that are not fully confirmed but already have a decent number of confirmations on them. LTC, yeah, they just copied it over and did not adjust it, so it became more arbitrary. However, low hashing power is not a good reason to change this. This would better just be returned to the usual values when the difficulty adjustment is fixed. Basically, no need to tweek the wrong knobs.
-
What the dev did wrong was already create a fork with the new client release. This probably is what caused a lot of the issues seen since then.
What did he do? Not sure I follow what he did. I thought he created a new client that would fork at 21K, from the looks of it he did what FTC did. How else would you do a hard fork if everyone doesn't have the updated client?
He made it so the old and new clients do not talk to each other.
Edit: Actually I may hopefully be wrong about this. I was going off some diffs I generated from some code I was given that was claimed to be from the 0.6.3 release. Due to some other things I am seeing, I am not sure I trust this to be true.
As for how you do a fork without people getting the updated client, I was about to ask you the same thing:
http://www.gldtalk.org/index.php?topic=27.msg291#msg291
Not sure how you keep a fork a secret when you want people to update the client.
I have no idea why you are asking me the question, as I never said to keep new clients/forks a secret.
-
I don't think it should be kept secret...just not blab it all of bitcointalk.org
it will slowly get updated...the majority of people who mine it now have the updated client...so the fork will happen, the slower the news gets out about when the fork happened...the better for the longs in GLD rather than the pool hoppers.
-
Thank you for these ideas.
In your view, what is the best move for us to make at this point and time?
Wait and see how the changes go at 21k seems like the best coarse. You really don't want to put out forking updates without reasonable lead time or too soon after each other.
-
Thank you for these ideas.
In your view, what is the best move for us to make at this point and time?
Wait and see how the changes go at 21k seems like the best coarse. You really don't want to put out forking updates without reasonable lead time or too soon after each other.
This seems like a reasonable and measured approach. What do you think we're looking at in terms of a worst case / best case type comparison at the 21K fork? Any ideas on what we're looking at in terms of the most likely outcome?
-
Mining a coin is not attacking it. You also can not attack a coin at the last minute, unless it is using a non standard buggy difficulty calculation, as the whole time period is considered. Namecoin had worse issues back in 2011 with miners hoping on and off it then this coin has had.
Actually, when someone points 2 gHs at a coin to run a 51% attack, and at the same time bring the difficulty from 1 to 7 in a matter of hours, yes it is an attack. Again, you have not been around this coin and have no idea what was done to destroy the coin. As soon as the difficulty changed, the hashrate dropped to 100 mH/s, and within a day, down to 30 mH/s (because the real miners left) and eventually you have what is there today. It was down to 7 mH/s
Capping the difficulty either way is still probably not the right approach (and yes I know the original btc code does do this).
If the difficulty was capped in the first place this coin wouldn't be at difficulty 7.3. Capping the difficulty keeps the coin from being put to death as this coin was by an influx of mining that just drops off after the difficulty changes. If this coin is allowed to have unlimited difficulty changes, or even 400% Litecoin style adjustments, the coin will be right back here with 7 mH/s hashrates in a matter of weeks again.
So you propose what? Do nothing? Make it possible for difficulty to skyrocket by someone trying to raise difficulty to kill the coin or by simple coin hoppers following coinchoose?
I have my doubts that you are out to help this coin. I would bet the house on that.
-
Mining a coin is not attacking it. You also can not attack a coin at the last minute, unless it is using a non standard buggy difficulty calculation, as the whole time period is considered. Namecoin had worse issues back in 2011 with miners hoping on and off it then this coin has had.
Actually, when someone points 2 gHs at a coin to run a 51% attack, and at the same time bring the difficulty from 1 to 7 in a matter of hours, yes it is an attack. Again, you have not been around this coin and have no idea what was done to destroy the coin.
A 51% attack is not the same as just mining with an unmodified client. However a 51% attack is also going to be in control of things, so does not fit at all what you posted the first time. The time warp fix is in place though so at least it would have to be a real 51% attack.
As soon as the difficulty changed, the hashrate dropped to 100 mH/s, and within a day, down to 30 mH/s (because the real miners left) and eventually you have what is there today. It was down to 7 mH/s
You again have not described an attack, you have just described rational profit seeking mining behavior. Do you remember how that used to go with nmc?
If the difficulty was capped in the first place this coin wouldn't be at difficulty 7.3. Capping the difficulty keeps the coin from being put to death as this coin was by an influx of mining that just drops off after the difficulty changes. If this coin is allowed to have unlimited difficulty changes, or even 400% Litecoin style adjustments, the coin will be right back here with 7 mH/s hashrates in a matter of weeks again.
All capping the difficulty does is increase the time the coin runs at a lower difficulty then it should. It is not the growth in difficulty quickly that is the issue, it is the lack of a quick reset back down.
So you propose what? Do nothing? Make it possible for difficulty to skyrocket by someone trying to raise difficulty to kill the coin or by simple coin hoppers following coinchoose?
I have my doubts that you are out to help this coin. I would bet the house on that.
I proposed that we wait and see how the FTC/SunnyKing/PPC inspired code does. It would not have been my first choice I think, but it is what is in place, and it would cause more issues to try and do anything differently at this point.
I am not the one who proposed things that are I think are probably more harmful than helpful. You only seem to want to make sure that blocks are not generated too slowly. I am only pointing out that it should still be a concern that they don't get generated and mined out way ahead of schedule either. It seems you can not keep to a discussion on the merits of the ideas and had to resort to an ad hominem already.
-
This addressed to hyoshi .. as well as twobits
Capping the difficulty either way is still probably not the right approach (and yes I know the original btc code does do this).
If the difficulty was capped in the first place this coin wouldn't be at difficulty 7.3. Capping the difficulty keeps the coin from being put to death as this coin was by an influx of mining that just drops off after the difficulty changes. If this coin is allowed to have unlimited difficulty changes, or even 400% Litecoin style adjustments, the coin will be right back here with 7 mH/s hashrates in a matter of weeks again.
I have read what you both say with interest. I do not pretend to understand all the technical issues, but it seems to me that the positives and drawbacks are finely balanced for any proposed changes. There is a fair matter of opinion there as well .
As for the desired variables: Please correct me if I am wrong, but Capping amounts or reset times seem to be the contentious issues at this stage:
In the earlier stages of coin life, (and that applies to all coins atm apart from BTC and maybe LTC ) the most important aim is to maintain network hashrate, and have some measure of resistance to attack (I understand there a several types of attack). Therefore that should be the prime aim so......
It seems to me that a cap is desirable (if the coins runs at a lower difficulty for longer, that won't kill it), and a flexible readjustment down is also required. I cannot see the real disadvantages of maximum downward flexibility combined with a gently rising cap.
Please can you let me know if I have read this correctly ?
-
There are some great insights and views expressed in this thread.
In my estimation, this is the most critical discussion in the Goldcoin universe. It could very well be that this discussion goes down in the books as the most important discussion ever in the history of Goldcoin. So I "feel" we need to fully concentrate on this topic and prepare for each and every possible scenerio. The waters are stormy and filled with many obstacles. So we need to be diligent and guide the ship carefully and be sure to avoid the many icebergs ahead.
At some point we'll need to reach a consensus on which way to turn the rudder.
-
I have read quite a few things in this thread, some things I know to be "off". I have been around the block quite a few times in the BTC-Alt coin world. Written and modified more code than I can remember.Talked and worked with coin developers (Still do).
But I think with the level of "hostility" between developers and others in this thread, I am going to stay out of it.It would not surprise me if more people like myself are doing the same thing.
Only one piece of advice, I STRONGLY suggest the final difficulty algo be based on the PPC difficulty algo. PPC is almost a year old, and nobody has been able to pull a difficulty attack on it. You will find the coins that have survived a large difficulty gap or attack, ultimately at least adopted a partial PPC style targeting algo.If you need a scrypt model to work off of, look at the Novacoin daemon/client, it is basically a scrypt version of PPC.
Note: For those not elbows deep in the "tech" stuff :D I am talking about the difficulty targeting and not the POS/POW blocks feature of PPC and NVC.
-
I have read quite a few things in this thread, some things I know to be "off". I have been around the block quite a few times in the BTC-Alt coin world. Written and modified more code than I can remember.Talked and worked with coin developers (Still do).
But I think with the level of "hostility" between developers and others in this thread, I am going to stay out of it.It would not surprise me if more people like myself are doing the same thing.
Only one piece of advice, I STRONGLY suggest the final difficulty algo be based on the PPC difficulty algo. PPC is almost a year old, and nobody has been able to pull a difficulty attack on it. You will find the coins that have survived a large difficulty gap or attack, ultimately at least adopted a partial PPC style targeting algo.If you need a scrypt model to work off of, look at the Novacoin daemon/client, it is basically a scrypt version of PPC.
Note: For those not elbows deep in the "tech" stuff :D I am talking about the difficulty targeting and not the POS/POW blocks feature of PPC and NVC.
I like these ideas very much.
In your opinion, when should we release the client update/patch? Can you please layout a detailed step-by-step plan of action based on your current understanding of the network situation?
-
I have read quite a few things in this thread, some things I know to be "off". I have been around the block quite a few times in the BTC-Alt coin world. Written and modified more code than I can remember.Talked and worked with coin developers (Still do).
But I think with the level of "hostility" between developers and others in this thread, I am going to stay out of it.It would not surprise me if more people like myself are doing the same thing.
Only one piece of advice, I STRONGLY suggest the final difficulty algo be based on the PPC difficulty algo. PPC is almost a year old, and nobody has been able to pull a difficulty attack on it. You will find the coins that have survived a large difficulty gap or attack, ultimately at least adopted a partial PPC style targeting algo.If you need a scrypt model to work off of, look at the Novacoin daemon/client, it is basically a scrypt version of PPC.
Note: For those not elbows deep in the "tech" stuff :D I am talking about the difficulty targeting and not the POS/POW blocks feature of PPC and NVC.
You are right, PPC does have a pretty good algo for difficulty.
-
Do we have a list of things that need to be decided? Is it going to be community orientated as to what the features are? Lets get to work :)
Here's a quick list of off the top of my head:
1. How to notify users, pool operators, and exchanges.
2. What exact changes are needed in the code.
3. How to secure a secondary developer as backup?
I've been in touch with a developer, who has no time for this project, but did review the proposed changes made by Hyoshi and feels that the changes proposed are indeed sound.
#1: Buy an email list service like mailchimp or something which allows the first 500 people to sign up for free. You can then secure who signs up and only they will be on the email list and every time you need to send them something you can type one email and it will go to all their emails.
-
Difficulty adjustment worked like a charm... I am going to add checkpoints to the client and am looking into a way to automatically add them via a trusted checkpoint node like NVC