importprivkey ofc.

Nah that would probably work fine, but something more guldencoin related artwise. So I don't have to guess which paperwallet is which.
(btw I did the banksycoin paperwallet; https://dl.dropboxusercontent.com/u/27041159/Bansky-25.html )

To be honest, it's not hard. in every xxcoin-qt you got the console. and if you type importprivkey "YOURPRIVATEKEY" "label", it will just show up in your wallet . (some qt's are a bit annoying, and you need to do it twice to make it pop up)

Hello all,

I haven't posted a message on here over the past few weeks because I've been very busy with the difficulty problem.
Once it was discovered that the jump pool might be CleverMining I got in contact with Terk to discuss the problem.
He reduced the amount of hashrate for NLG a few times so it won't cause multiple hour blocktimes anymore.
Fuse also contacted Terk, and as you all know by now the hashrate used by CleverMining for NLG is now 1/12th of the normal hashrate they would use.

I want to thank Terk and CleverMining again for their cooperation and help.

However, CleverMining and other jump mining pools won't hold back forever, especially not when the prices rise.
So we need a solution.

I dug into the code.. I read the digishield and DGW1,2,3 algorithms and looked at some others.
Digishield looks a lot like the original diff adjustment algorithm. But it readjusts per block and rises diff slower, while it lowers diff faster.
This makes it possible for a jump pool to mine a lot of blocks, and afterwards the diff drops faster again.
DGW1 and 2 look a lot like DGW3. DGW3 simply has some improvements over the first two.
DGW also adjusts the difficulty per block. But it rises the diff just as fast as it lowers it.
But it calculates the new diff based on the average diffs for the past x blocks. This means the diff can rise fast when a lot of blocks are mined in a short amount of time, but it also levels back pretty quick afterwards.
I believe that DGW3 is our best option. We are now making plans for a mandatory update including this new algorithm. We will have more information available before the end of tomorrow (sun 21th).

Thanks,
Geert-Johan

Yes we are still thinking about the BTM solution of making the required confirmations for generated coins higher.
However, I think it can be bypassed by any jump pool fairly easy. The pool simply creates a buffer of say 100K NLG and places this at the exchange. When the pool decides to mine blocks, the buffer is being sold. So if the pool gets 14 blocks, then 14K NLG is sold at the exchange. When the 14K mined coins are completely confirmed (which will take longer than normal), the coins are moved to the buffer at the exchange, so the buffer is back at 100K NLG again.
I think this technique might actually be used already, it makes the calculations by a jump pool very accurate because mined coins can immediately be sold. The buffer itself is a one time investment that can eventually be sold again.

So when the generated coins maturity confirmations is changed from 120 to 240, that would simply mean that the jump pool requires a buffer of twice the size to accommodate for the confirmation time..
So like BTM, it would require a huge confirmation time (maturity), like 480 (20 hours), 720 (30 hours), 960 (40 hours) or maybe even 1152(48 hours)... Each one requiring a larger buffer to effectively calculate the profitability for mining and selling coins right away.. And even with a small buffer it would work, it would just mean that the miner can't come back every hour and has to wait for the buffer to fill for a day or two..
The downside is that our dedicated miners also have to wait longer before their coins are matured. So I would very much like to hear how everyone thinks about this. Especially if you are a miner (dedicated or jump), please let us know how you feel about a higher maturity confirmation count.

I don't mind/care the dumping of the coins on exchanges (or the financials of the big jumping pools), what matters is how the pool reacts to this change in respect of difficulty adjustments. If we have a big pool jumping in and out less frequently, this means more blocks for our dedicated miners (and maybe longer stretches of lower difficulty).

I've got difficulties trying to visualize the effect of this change on the network difficulty (and your bypass method doesn't make it easier).

Personally, I think rejecting otherwise valid blocks is a no-go area. That is not in the benefit of anybody.

Thats how you look at the problem. Orphan blocks are also valid blocks... and the only ones with very low submissions are pools with guerilla techniques.

Edit: The current diff system punishes you also when you are mining fast... In fact there are two problems to fix; hopping very high hashrate and concentration of hashrate.   

I am highly impressed with the discussion taking place here. The dev definitely has looked at all angles and the miners are coming back with more suggestions. Really I feel Guldencoin is in great hands here!

Not if you take the average diff of x blocks and use the deviation from that to calculate a difference from a base maturation time.