Goldcoin (GLD) Core Development Thread

[twobits]

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.

[twobits]

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.

[bobbix]

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.

[twobits]

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.

[MicroGuy]

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?

[hyoshi]

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.

[twobits]

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.

[Majormax]

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 ?

[MicroGuy]

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.

[dreamwatcher]

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    I am talking about the difficulty targeting and not the POS/POW blocks feature of PPC and NVC.

[MicroGuy]

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    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?

[hyoshi]

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    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.

[bitshirehashaway]

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.

[hyoshi]

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