To ilustrate the behaviour we experience look at the blocks below. At 137136 we had a diff of 412 and because the block preceding this took two hours the diff dropped to 118. But the max drop is 1/3 so it should have dropped to 138 and not 118. The dif lowers and despite blocktimes of tens of seconds it lowers and lowers. Till 137159 then the calculation says hoooo fellas this is too fast and it raises the diff from 29.8 to 162.1 not exactly the max three times that was in the DGW design... So why does is diff adjusted more than the DGW design? And second it can behave much better if it is a weighted average instead of a plain one.

 
137184 2014-10-20 19:37:56 1 1000 227.657 307183000 64.5077 4675.82 61.0856%
137183 2014-10-20 19:37:43 1 1000 188.93 307182000 64.5077 4675.82 61.0856%
137182 2014-10-20 19:37:14 6 45685.2034 431.768 307181000 64.5076 4675.82 61.0858%
137181 2014-10-20 19:01:13 1 1000 374.057 307180000 64.4828 4675.79 61.095%
137180 2014-10-20 19:00:42 2 1422.978 332.835 307179000 64.4827 4675.79 61.0951%
137179 2014-10-20 18:53:02 1 1000 302.237 307178000 64.4776 4675.79 61.097%
137178 2014-10-20 18:52:47 1 1000 276.263 307177000 64.4776 4675.79 61.0971%
137177 2014-10-20 18:52:02 1 1000 256.457 307176000 64.4773 4675.79 61.0973%
137176 2014-10-20 18:50:03 1 1000 240.951 307175000 64.4761 4675.78 61.0978%
137175 2014-10-20 18:49:57 3 1975.29793541 228.569 307174000 64.4763 4675.78 61.0978%
137174 2014-10-20 18:47:50 1 1000 218.365 307173000 64.475 4675.78 61.0984%
137173 2014-10-20 18:47:41 1 1000 210.006 307172000 64.4751 4675.78 61.0984%
137172 2014-10-20 18:47:39 1 1000 203.035 307171000 64.4753 4675.78 61.0984%
137171 2014-10-20 18:47:24 1 1000 197.242 307170000 64.4753 4675.78 61.0985%
137170 2014-10-20 18:47:19 1 1000 192.377 307169000 64.4755 4675.78 61.0985%
137169 2014-10-20 18:46:52 1 1000 188.239 307168000 64.4754 4675.78 61.0986%
137168 2014-10-20 18:46:48 1 1000 184.775 307167000 64.4756 4675.78 61.0986%
137167 2014-10-20 18:46:44 1 1000 181.831 307166000 64.4757 4675.78 61.0987%
137166 2014-10-20 18:46:41 1 1000 179.32 307165000 64.4759 4675.78 61.0987%
137165 2014-10-20 18:46:29 1 1000 177.128 307164000 64.476 4675.78 61.0987%
137164 2014-10-20 18:45:32 1 1000 175.297 307163000 64.4755 4675.78 61.099%
137163 2014-10-20 18:45:08 1 1000 173.454 307162000 64.4755 4675.78 61.0991%
137162 2014-10-20 18:43:29 2 6641.46782322 171.971 307161000 64.4745 4675.78 61.0995%
137161 2014-10-20 18:42:48 1 1000 170.843 307160000 64.4744 4675.78 61.0996%
137160 2014-10-20 18:42:27 1 1000 162.133 307159000 64.4744 4675.78 61.0997%
137159 2014-10-20 18:42:16 1 1000 29.857 307158000 64.4744 4675.78 61.0997%
137158 2014-10-20 18:41:59 1 1000 32.026 307157000 64.4744 4675.78 61.0998%
137157 2014-10-20 18:41:53 1 1000 34.314 307156000 64.4746 4675.78 61.0998%
137156 2014-10-20 18:41:40 1 1000 36.323 307155000 64.4746 4675.78 61.0999%
137155 2014-10-20 18:41:37 1 1000 38.742 307154000 64.4748 4675.78 61.0999%
137154 2014-10-20 18:41:34 1 1000 37.496 307153000 64.475 4675.78 61.0999%
137153 2014-10-20 18:41:18 1 1000 40.622 307152000 64.475 4675.78 61.1%
137152 2014-10-20 18:40:59 1 1000 43.965 307151000 64.475 4675.78 61.1001%
137151 2014-10-20 18:40:52 1 1000 47.547 307150000 64.4751 4675.78 61.1001%
137150 2014-10-20 18:40:48 1 1000 50.685 307149000 64.4753 4675.78 61.1001%
137149 2014-10-20 18:40:47 1 1000 54.738 307148000 64.4755 4675.78 61.1001%
137148 2014-10-20 18:40:43 1 1000 58.675 307147000 64.4757 4675.78 61.1001%
137147 2014-10-20 18:40:31 1 1000 63.313 307146000 64.4757 4675.78 61.1002%
137146 2014-10-20 18:40:03 1 1000 68.027 307145000 64.4756 4675.78 61.1003%
137145 2014-10-20 18:39:48 1 1000 72.557 307144000 64.4757 4675.78 61.1004%
137144 2014-10-20 18:39:44 1 1000 78.178 307143000 64.4758 4675.78 61.1004%
137143 2014-10-20 18:39:00 1 1000 83.37 307142000 64.4755 4675.78 61.1006%
137142 2014-10-20 18:38:55 1 1000 88.63 307141000 64.4757 4675.78 61.1006%
137141 2014-10-20 18:38:54 1 1000 92.904 307140000 64.4759 4675.78 61.1006%
137140 2014-10-20 18:38:49 1 1000 99.356 307139000 64.476 4675.78 61.1006%
137139 2014-10-20 18:38:33 1 1000 97.431 307138000 64.476 4675.78 61.1007%
137138 2014-10-20 18:37:44 1 1000 105.188 307137000 64.4757 4675.78 61.1009%
137137 2014-10-20 18:37:00 8 92544.22974057 118.799 307136000 64.4754 4675.78 61.1011%
137136 2014-10-20 18:36:42 3 8363.86928814 412.358 307135000 64.4763 4675.78 61.1006%
 

I would never recommend a 1-2 block focus.  That would be crazypants thinking.

I seriously think 6 is a nice even number, and it falls in line with about the average number of blocks that Clever rapes at any given time.  You put more focus on those 6 blocks, instead of 24 evenly, and you'll see a big change in Clever's ability to own 90% of the network.

Of course, GJ has some code on the table right now.  I guess we'll all just need to wait to see what it looks like before we try to push one way or another.

-Fuse

Time to put our Guldens where our mouth is 

A lot of good coins are in the process of going POS, even Noble because of the same problems they have. Is this a possible solution for the team? I know the miners will most likely not support the coin anymore because it hurts there own pockets but POS should be a backup plan if there isn't going to be a solution on the mining front.

I know this might sound like a crazy idea but why don't we let the price fall to around 300 and then the ratio between dedicated miners and multipools will decrease. Then after it's fixed we can start buying again? This would require a lot of collaboration I know but if everyone just removes there buy orders and let the price drop, the multipools will sell out at any price.

I am reading a lot about nite's gravity well and think it's idea is first born here.

https://bitcointalk.org/index.php?topic=552895.0

Maybe we should contact nite himself te help us think out a solution.

Just to continue with what Geert has said, we will have to come up with our own solution catered towards the guldencoin blockchain. DGW works for darkcoin and Digishield works for digibyte but it doesn't mean there solution works for every other coin perfectly. Also when changing things it's not just about sorting out the block times , securtiy, stability, vulnerabilities, abuse options all need to be looked into with a fine comb.
We will have more updates this week about the plan moving forward but please continue with the discussion, we appreciate the constructive criticism because it means people care about Guldencoin being as close to perfect as humanly possible.

The good news is we have capable developers who are 100% focussed on this and a month isn't long as this is a longterm project and the crypto landscape is always changing and we will have to continually review our processes and development strategy to cater for major changes that could effect the coins network in a positive or negative way.

Please keep the ideas and suggestions coming so we can look at all possible solutions. Together we can get this right!

I just sent a message to Terk asking if he can take a look at the amount of hashrate thrown at NLG.

DGW3 does better re-adjustment than KGW, but as we can see it's not good enough.
DGW3 calculates diff based on the 24 last blocks.
When there's a long blocktime, and then someone mines 1 block, then clevermining takes 23 blocks, the long blocktime block is not taken into the calculation anymore, and the diff spikes.
Now I hear you say: "why don't we increase the number of blocks taken into the DGW3 calculation". Well, I did some simulations and I believe in the end that will only affect the number of blocks clevermining gets before the diff spikes.

So we need something clever (no pun intended).

There are two methods:
- create a re-adjustment algorithm that is actually pretty smart, detecting patterns, applying penalties if a lot of blocks were mined in short time.
- work out how a block reward based on block time. e.g.: `reward = 1000 * (secsSinceLastBlock/150)` with a max of, say, 3000 (after 3x the target blocktime).

Best would be: both.

Please let me know what you think about this!
I'll work out more details this evening (CEST).

Is there anything wrong with Nite's Gravity Well? Seen it in action for a coin I once played with, worked pretty good.

cool link!  website is on my site! 

i lost the url of 1 Merchants i now the website its starts whit K  


http://www.guldencoinfaucet.nl offline

Nice!

The next 24 hours look like they going to be fun on the markets

Ok, here is a preliminary design for business cards I plan to print for distribution among dutch supporters.

The plan is to get enthousiasts to go to local shops they regularly visit anyway and let them ask the store owners if it's possible to pay in Gulden. Then they can explain in their own terms and comfort why they want this and leave the card behind for the store owner to look at once he is not busy running the store anymore.

This takes away the sale pressure and gives room for a friendly approach.

Please shoot at the design and context

Card-Front:

Card-Back:

BTM is recalculating the diff every 720 blocks, with an steady hashrate that translates to 1 day.
Imaging clever jumping in for exactly 1 interval of 720 blocks and than leave normal miners with the skyrocketed hashrate for the next interval for the following 720 blocks. Scary to me. It could take many days to solve those 720 high diff blocks.
That although opens the gates to malicious hashrate attacks.

DGW3 is adjusting every new block based on the last 24 blocks with a max increase to 3 times of the previous or max decrease to 1/3 of the previous. Reducing the interval of 24 blocks can make it adapt quicker (less smoother change), but on a jump you are still left with 1 block calculated based on the hashrate before the jump (called 'bad block' by me).
If we have a chance to see a bigger hashrate chance already during a block, we could take that into the calculation and the 'bad block' is gone. We should still set bounds of min and max block times and with some thinking we should even be able to translate that into a diff based on the actual hashrate.
Rejecting blocks sounds bad, resending blocks with a corrected diff sounds far better if possible. This could help at the beginning of a spike but sadly not at the end.