NA

[strataghyst]

So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.

Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.

I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.

If I am understanding the proposal properly, it seems a good alternative not because big pools won't be able to find a lot of blocks, because most probably they will be mining most of them, but because it makes the mining not profitable enough and as such they go to the next coin. Once that happens, the block findings will return to the finders who are always mining because big pools have left the building.

Is my interpretation correct?

Yep, thats the idea. But even if those pools stay they are put in a position where the impact on the network is much less. But my assumption is they leave the coin alone because it's not profitable anymore.

I'm also big fan of BTM 's solution its simple and effective at least on paper. But I still don't comprehend why DWG doesn't work for Guldencoin as it does work for other's.

[1715004357]

1715004357

[1715004357]

1715004357

[1715004357]

1715004357

[1715004357]

1715004357

[BioMike]

Hash rate dropped since yesterday... did something change?
http://www.guldencointrader.nl/hashrate.php

I've also rented about 220MH and pointed them to guldenpool. The pool has been getting some blocks since then. Not much, but still.
Looking at how much was generated, and how much it costed me... I would have to sell them at about 1250 sat to break even. That is not as bad as I would expect, someone with mining gear would do better.

[c_e_d]

BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.

DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)

BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?

DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.

[strataghyst]

BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.

DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)

BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?

DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.

As I understand the long maturity time is only for newly mined blocks so it wouldn't affect daily use that much?

[thsminer]

BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.

DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)

BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?

DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.

You do not mention the maturity part and thats were the little trick lies. BTM has a maturity of 720 blocks... So a jumppool has to wait an awful long time before he she can sell the coins. If they screw the blocktime of a coin they have to wait even longer and thus shoot their own foot. As Geert-Johan mentioned they can build a buffer and sell from there, but every fence you raise makes a coin less attractive for those kind of pools and I doubt if they are willing to put up such buffer.

[ny2cafuse]

BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.

DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)

BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?

DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.

As I understand the long maturity time is only for newly mined blocks so it wouldn't affect daily use that much?

Correct, it's only on newly found blocks.  Otherwise it's the standard 6 confirms on transactions.

I very much like thsminer's block rejection idea.  It would stop these damn 20 blocks in 10 seconds scenarios.  I'm also in the boat with c_e_d in that I believe DGW3 just needs to be tweaked.  I've been saying that since my first post about the change.  DGW3 is allowing too many blocks before spiking up in difficulty, and it's spiking to high.  The second we went from 300 to 700 in difficulty I knew.

I haven't done enough research on BTM, but couldn't we just extend the confirmation times to emulate it, and tweak DGW3 to mitigate large swings of hashrate?  In my mind it seems like we could do both.

-Fuse

[thsminer]

BTM is using an old diff algo version, allowing spikes and drops by a max factor of 4 while calculating the diff from the last 24 hrs hashrate once every interval (=24 hrs for standard block times), and using an extrem maturity time (3 days?) to scare steady switching miners away.

DGW2 changed that to a max factor of 3 and a time interval of 140 blocks with retargeting every block.
DGW3 changed that again to an intervall of 24 blocks while keeping the max factor at 3.
(That's roughly it without too many details)

BTM solution:
What happens if a switching pool can live with that?
It takes the 720 blocks with low diff and than leaves the normal miners with high diff until it is recalculated another 720 later.
Their argument is (from how I read it), the market price will jump up during this high diff times to compensate it.
Nice for day traders but for a daily use coin?

DGW3 works as long as the jumps in hashrate aren't as extrem as we see them currently. (My hopes in DGW3 were higher too)
So I am thinking along the same lines like thsminer and do it by modding the DGW3 we have.
Set a min and max time for blocks and during a block try to look ahead how the diff has to change for the next block, so you are not stuck with a high diff block while the hashrate already has fallen far down. The current algo first needs a block with lower hashrate before the diff for the next block gets calculated lower. Maybe a little more fine tuning and we should be good, having an algo that is able to work with todays challenges.

As I understand the long maturity time is only for newly mined blocks so it wouldn't affect daily use that much?

Correct, it's only on newly found blocks.  Otherwise it's the standard 6 confirms on transactions.

I very much like thsminer's block rejection idea.  It would stop these damn 20 blocks in 10 seconds scenarios.  I'm also in the boat with c_e_d in that I believe DGW3 just needs to be tweaked.  I've been saying that since my first post about the change.  DGW3 is allowing too many blocks before spiking up in difficulty, and it's spiking to high.  The second we went from 300 to 700 in difficulty I knew.

I haven't done enough research on BTM, but couldn't we just extend the confirmation times to emulate it, and tweak DGW3 to mitigate large swings of hashrate?  In my mind it seems like we could do both.

-Fuse

Did you read your PMs...

[c_e_d]

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.

[Buerra]

Hi All,

With all the mining talk that has been going on we most likely overlooked that we have had 3 new websites accepting Guldencoin and a new
Guldencoin Faucet and Links website added by the community.

The 3 online shops are:

https://www.101munten.nl/
https://www.zeusminershop.com/
https://www.fotoboxxl.nl/

The Timeline has also been updated by Waterloo.

[strataghyst]

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.

You are right it would be very scary but we are not talking about the diff recalculating that BTM uses only about the longer maturity time for newly mined coins.

[thsminer]

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.

At first your right about the possible high diff after 720 blocks but if someone would induce such spike they have to wait for several days before they get their money because it also takes 720 blocks to mature. This will make jumppools think twice.

There is no way in the current setup to calculate the hashrate of the current block because this is done outside the network in the machines of the miners. Sure you can write some software added to the coins core to periodicaly send some status but if I was a pool I would tweak that info an tell the ouside world the hashing is very low.

You are amongst many people who say "rejecting blocks seems a bad idea" At first I got a little tired but thats not in the interest of the coin so I will explain why its not so strange...
I will refer to pooled mining. When you join a pool and start hashing on the current block, you get a diff from the pool that's less as the network diff. So you start hashing and find a matching block. You submit it to the pool and because it's hashed at a lower diff, good chance it does not comply with the network diff. And then comes the fun... your block gets rejected by the pool!
So your machine starts again and again and again, until you or another pooled miner finds a block that matches the network diff. At that moment the block is send onto the network and is accepted by the network.
So when you enter a pool you are hashing for John Doe most of the time and you get reject on reject. Your work however is recorded because the pool has to calculate how much effort you put in finding the block. The latter is the reason pools work this way otherwise they don't know how much effort you put in hashing.

[xtrix]

I love to see the wonderful discussion at the sideline. 

Although I'm not an expert in the crypto algorithms, I really start feeling a lot for the strategy of rejecting calculated blocks.

[veertje]

It looks like DGW3 handles it better atm with not that very deep lows in diff anymore. Blocktime also relative better atm.

Maybe DGW3 still needs time to settle from a cold start a few days ago and 2.5 minute blocktime? It was designed for 1 minuteblocktime I believe and needed time maybe to adjust with multiple GH/s swings at the cold start. Still adjusting is my opinion.

http://www.guldencointrader.nl/

[BioMike]

It looks like DGW3 handles it better atm with not that very deep lows in diff anymore. Blocktime also relative better atm.

Maybe DGW3 still needs time to settle from a cold start a few days ago and 2.5 minute blocktime? It was designed for 1 minuteblocktime I believe and needed time maybe to adjust with multiple GH/s swings at the cold start. Still adjusting is my opinion.

http://www.guldencointrader.nl/

Does it do corrections over longer time frames?

[veertje]

It looks like DGW3 handles it better atm with not that very deep lows in diff anymore. Blocktime also relative better atm.

Maybe DGW3 still needs time to settle from a cold start a few days ago and 2.5 minute blocktime? It was designed for 1 minuteblocktime I believe and needed time maybe to adjust with multiple GH/s swings at the cold start. Still adjusting is my opinion.

http://www.guldencointrader.nl/

Does it do corrections over longer time frames?

I think it couldn't handle the spike in hashrate (from 0 to 9 GH/s) at the start and swings short thereafter. But maybe I am totally wrong on this, but it seems like the lows in diff. swings are getting higher and the spike less high, but it is still far from stable ofcourse atm. But maybe it can adjust more and more in time?

[ShopemNL]

Sneakpeak

[shrekster]

I think we could hit 700 today

[c_e_d]

You are amongst many people who say "rejecting blocks seems a bad idea" At first I got a little tired but thats not in the interest of the coin so I will explain why its not so strange...
I will refer to pooled mining. When you join a pool and start hashing on the current block, you get a diff from the pool that's less as the network diff. So you start hashing and find a matching block. You submit it to the pool and because it's hashed at a lower diff, good chance it does not comply with the network diff. And then comes the fun... your block gets rejected by the pool!
So your machine starts again and again and again, until you or another pooled miner finds a block that matches the network diff. At that moment the block is send onto the network and is accepted by the network.
So when you enter a pool you are hashing for John Doe most of the time and you get reject on reject. Your work however is recorded because the pool has to calculate how much effort you put in finding the block. The latter is the reason pools work this way otherwise they don't know how much effort you put in hashing.

I said it sounds bad
Your reference to pooled mining did help a lot so I am now able to hopefully describe better what I ment with my vague words of "resending blocks with a corrected diff sounds far better".
Acting like a pool saying 'try it again with this higher diff' if block times are too short.
A bit more complicated on the other side, when block times are getting to long. 'Try it gain with this lower diff" doesn't work here. But with an intelligent algo we should be able to keep the upper block times limited too.

DGW3 still adjusting? We are at 1760 new blocks now, 1760 calculations to adjust. I can't see any reason in the code why it could take that long.

On the bride site: Looks like the heavy dump of ~900k coins this morning cleared the way to a nice price improvement during the last hours. Monday still coming, so there is something to look forward to during the coming week.

[andresm]

Anyone know how far is the process with apple accepting the ios wallet?

[24Kilo]

I have to run the numbers, but retargeting difficulty with a time component will create vulnerability to a TW(Time Warp) attack. Just doing a quick simulation here tells me that a TW attack would be successful with less than 10% of the total nethash.

I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.

As I see it, you would need very little nethash for a successful TW attack.