Ahh yes, I of course mean 2.5 minutes and 1.5 minutes, not paying close attention my mind is elsewhere on more important matters so apologies for that Anyway all other points remain, you should be far more concerned about the difficulty than by the block spacing being slightly off.

The only thing that is obvious is that you are (1) quite confused (2) like to make things up.
Here we have the original block spacing target from April 4 2014 - https://github.com/nlgcoin/guldencoin/blob/2de5c37654417bbdecccbde170b865ebf3820b93/src/main.cpp#L1081
Here we have the current block spacing target in current build - https://github.com/nlgcoin/guldencoin/blob/master/src/main.cpp#L1081

You will notice that they are identical, I hope this clears any confusion up.

Further to the above, yes blocks are still coming in slightly slow - the latest version has drastically improved things here and the next one will do so even further - but this is because the coin experiences hash rate swings between 2 and 8 gh/s - this is a problem faced by any coin that faces some level of success - and therefore has lots of pools etc. wanting to mine it - but is not yet as big in terms of hashrate as litecoin or bitcoin that hashrate never drops downwards.

If EFL is not experiencing this problem then perhaps it is because the EFL hashrate is so low (difficulty seems to hover in the 30's) that there are not wild swings or large mining pools to worry about - basically to be quite blunt, nobody actually wants to mine it - this is not a good thing it means that EFL basically fails at the single most important thing a currency needs to do which is being secure. With a hash rate that low anyone can 50% attack the network with pocket change

It seems to me that 'blocks averaging 3 1/2 - 4 minutes instead of 2 1/2 minutes' is a far better problem to have than 'Anyone who can scrap together 0.2 BTC can 50% the coin at will'
i.e. Get your own house in order instead of going around pointing fingers, you will get much further by working on improving what you have than by bad mouthing others.

The Guldencoin block target is 250 seconds not 150 seconds, maybe you should double check your facts before you post.

Edit - never mind the above - I was not paying close attention due to all the other nonsense in the post distracting me, 150 seconds is of course 2 1/2 minutes which is what the Guldencoin target is.

Two things:
1) The multi algo we are looking at implementing is our own, it is going to contain fixes for several issues that we have picked up which the other coins who implemented multi algo did not. If we are not happy that we can fix these we will not launch it, we are not going to launch a broken multi algo. This is proper development with proper testing not some copy and paste job and that is why it will take some time.
2) Groestl is not currently in our list of algos that will be chosen, we are at this point only considering algos  that already have widespread use on larger coins.

'There's an old saying that goes: "if it ain't broke, don't fix it"'

The problem is that if you look below the surface, for all but the very largest coins (bitcoin) the security model of pow (as it currently stands for guldencoin and other similar sized coins) is very much broken.
It may appear 'not broken' to 'regular folk', as nobody has chosen to do any large scale attacks yet, but that doesn't mean that every single pow coin is not a disaster waiting to happen, the more and more mainstream crypto becomes the more likely this is, and when it does happen it will likely not be just one small coin that gets attacked but all of them.

It would be reckless to wait until after a major attack happens to do something about it, at that point it is already much too late, the damage will be done and irreparable.
It is absolutely essential that security issues are sorted out now already, whether the solution be PoS, multi algo, a combination of the two or something else entirely.

Also keep in mind that delta is still in a 'transition' phase for the first 576 blocks, while it should work well in the transition phase we can only see its full final behaviour in action after that.

Just another reminder, if you haven't already done so please update all your wallets to 1.4.0 to help avoid issues with the changeover.
If you have upgraded and usually keep your wallet closed, it would be helpful if you could try leave your wallet open just to help us have more 1.4.0 nodes for the transition.

Anything is possible, however resources are limited so it's a matter of concentrating resources where they are most needed first.
To save on development time, initially we would probably go for a simple update screen just to alert people properly that there is an update and allow them to update easily, it may eventually evolve into something fancier.
However it is not something we have discussed much yet, we will probably discuss this more as we head toward the next release, so who knows how it will eventually turn out, especially if e.g. more developers over their time in future.

It is hard to say with the fluctuating block times, but our current best guess is some time on Sunday for first delta block. For the first 576 blocks delta will operate in a 'transition mode' before it takes full effect, we are hoping this will take a day or two maximum.

Just a reminder/note that it is really important that at least 50% of the network upgrade before the switchover block, preferably more or else we will have a problem on our hands
So if you have not yet upgraded please do so.

Does your firefox have noscript enabled or something like that perhaps?

It is not possible for a difficulty algorithm alone to fix all the problems the coin currently faces, it can go a long way to helping with the really long block times which is of course a major issue but it cannot solve everything the long block times are just the symptom of a larger issue, it is almost inevitable that we will still have to go ahead with multi algo as well although if in some unlikely event we don't we would have to do something else.

A difficulty algorithm tries to predict the future, so there is no such thing as a perfect difficulty algorithm especially if it has to deal with giant hash swings. (Though obviously something better than the current one can be achieved)

There are two old bans from before the channel was handed over to me by freenode staff - I've just cleared them now, try again and see if it helps

Haha, as it grows we can probably clamp down and implement some rules to keep things under control, channel is in its infancy so not being closely watched for now.

Always silent just before a storm :p

It is sort of hard to give such a list as there are different types of end users, e.g. those who use the RPC console and those who don't for example.

A few of the larger more noticeable changes (in my opinion):
Header first synchronization allowing for faster synchronisation.
A new bandwidth dialog where you can see a graph of bandwidth usage over time.
A new peers dialog where you can see a visual representation of the peers you are connected to and various peer information.
Lots of new RPC commands for better wallet control, a complete overhaul of the RPC console to make it much easier to use all commands now have detailed help information and usage examples etc. and the help  is much more readable.
Much clearer error messages in most cases - e.g. The error LTex encountered above would be quite a bit better explained.
Improvements to how inputs are selected for payments - which would make a problem like what LTex encountered (with dust) much less frequent)
Watch only addresses.
Enables multi signature stuff.
A REST API which developers may find handy.


There are then additionally 100s of little performance improvements, stability fixes and security fixes plus lots of other things that I didn't include above.
To get a more comprehensive idea you can look at all bitcoin release notes since 2013-05-29 (0.8.2) - most of these changes apply.

At a guess it is probably pulling in too many small change addresses making the overall size of the transaction (in Kb not money) too large, what you can do as a temporary fix is turn on coin control in the options dialog and select only a few larger change addresses to pay from in the coin control dialog.

(This is one of the many things that will be handled far better after the wallet update)

As much as I would like to believe that, I have to ask why it is then that you are already coming up with conspiracy theories about my work.

e.g. That I am supposedly having problems with scrypt, the only reason the possibility of dropping scrypt when multi-algo kicks in has come up at all is because some community members asked (on both this and the other forum) whether it is possible.
This has absolutely nothing whatsoever to do with technical limitations in either frank or mines code - in fact the scrypt code is already working, it would need to be in order for the port to be testable and for the current block chain to remain usable.
Dropping scrypt saves me exactly 0 work, if it is going to be dropped it will be based on a proper discussion about the merits of various algorithms and which ones we want to keep, a discussion we have already stated multiple times we want to have very soon on the community forums.


While I certainly don't expect people to accept the work I do without question - on the contrary I would find it quite unsettling if there was no input on various things, and have very little patience for yes men; suck-ups or fanboys - I certainly find it somewhat distasteful to have people already spreading rumours after such a short period of time and with no facts to back them up.

While I personally am not phased by such things, you may want to at least wait until I miss the first deadline or the first bug is found before you start casting stones or you may find it harder to attract developer talent in future, not all developers have a thick skin and most of us have 100s of projects begging us to join them, generally we want to get on with actual work and not be dragged into political battles (or whatever it is going on here).

Know that I am on probation, as you the Guldencoin community are with me, if the community doesn't like my work, or me, once I have actually delivered it, they are welcome to tell me to take a hike, likewise if I as a developer don't feel the community is one I see a future in I will be equally quick to move on elsewhere.
I'm not getting any further involved in this fight except to say that in the end it is the community that is getting harmed when things like this happen, perhaps this should be considered before turning every little discussion into a fight over the same thing and using bystanders as ammunition in that fight.

Nobody has given anybody anything, Rijk started a thread saying he would *like* to do that in future when the work is completed and asking the communities opinion. The discussion is ongoing no decision has been reached.
You should really not post things if you don't bother to properly check your facts first.