NA - page 449. | Bitcointalksearch.org

Buerra

legendary

Activity: 980

Merit: 1000

Quote from: veertje on September 21, 2014, 03:18:28 AM

Quote from: Buerra on September 21, 2014, 03:10:17 AM

Quote from: bram_vnl on September 21, 2014, 02:28:54 AM

i don't get it why this topic is locked https://bitcointalk.org/index.php?board=147.0

Because PsychoticBoy = the Dutch moderator of that section and doesn't like NLG. Don't worry about it Bram Wink

You can always start a new topic with good and awesome NLG news.

Never thought about that it could be seen as negative, so I unlocked it again Wink

I locked it, because I thought it was just an announcement from me there, so no reactions needed anymore.
By the way, leave the discussion about "the other coin" there. Some are trying to be negative on NLG as well, don't give it attention that much. We post only positive things.

Apologies then

bram_vnl

legendary

Activity: 1148

Merit: 1000

Quote from: veertje on September 21, 2014, 03:18:28 AM

Quote from: Buerra on September 21, 2014, 03:10:17 AM

Quote from: bram_vnl on September 21, 2014, 02:28:54 AM

i don't get it why this topic is locked https://bitcointalk.org/index.php?board=147.0

Because PsychoticBoy = the Dutch moderator of that section and doesn't like NLG. Don't worry about it Bram Wink

You can always start a new topic with good and awesome NLG news.

I locked it, because I thought it was just an announcement from me there, so no reactions needed anymore. Never thought about that it could be seen as negative, so I unlocked it again Wink

By the way, leave the discussion about "the other coin" there. Some are trying to be negative on NLG as well, don't give it attention that much. We post only positive things.

I saw that, but I ignore it

veertje

legendary

Activity: 952

Merit: 1000

Quote from: Buerra on September 21, 2014, 03:10:17 AM

Quote from: bram_vnl on September 21, 2014, 02:28:54 AM

i don't get it why this topic is locked https://bitcointalk.org/index.php?board=147.0

Because PsychoticBoy = the Dutch moderator of that section and doesn't like NLG. Don't worry about it Bram Wink

You can always start a new topic with good and awesome NLG news.

Never thought about that it could be seen as negative, so I unlocked it again Wink

I locked it, because I thought it was just an announcement from me there, so no reactions needed anymore.
By the way, leave the discussion about "the other coin" there. Some are trying to be negative on NLG as well, don't give it attention that much. We post only positive things.

Buerra

legendary

Activity: 980

Merit: 1000

Quote from: bram_vnl on September 21, 2014, 02:28:54 AM

i don't get it why this topic is locked https://bitcointalk.org/index.php?board=147.0

Edit: Edited in light of new information Wink

WaterLooDown

legendary

Activity: 924

Merit: 1000

Timeline updated:

https://timeline.guldencoin.com/

bram_vnl

legendary

Activity: 1148

Merit: 1000

i don't get it why this topic is locked https://bitcointalk.org/index.php?board=147.0

CIG

newbie

Activity: 44

Merit: 0

Quote from: markanth on September 19, 2014, 02:02:13 AM

Quote from: CIG on September 18, 2014, 08:04:17 AM

Excellent work Mark! Do we get updates now and then?
I have set aside 20K NLG to support mining the 'hard blocks' for 10 days. I hope it's enough until the conformation time is more stable.
I'll donate 2000 NLG per day to anyone that close the longest gap.
Exceptions:
- The closed gap must be at least 60 minutes
- That address hasn't received a blockreward in previous 15 blocks where the time to find was less than a minute.

I presume pooladmins will distribute it after taking the normal pool fee. They may give it to the block finder or distribute it under the contributors or a combination of that.

Let's start with sept 16:
GgiTmq thank you for finding block 118414. You helped the Guldencoin network a lot. I donate 2000 NLG for that.
GLgBPz, GKaP57 and Gcpzph thank you for finding block 119148. You did a great job. Pro ratio I donate 42.69012692, 1957.30987306 and 0.00000002 NLG.

Very cool of you to reward the ones solving the hard blocks! Instead of posting the table you requested here it will be uploaded daily to http://nlgstats.iblogger.org (free webhost with ftp)

--Mark

It looks like the workaround measures have a positive effect on the longest confirmation time for now, although GfWGA still takes around 90% of generated new coins.
+--------------------------------------------------+---------------------------------+
| NLG blocks mined per day | longest block gap of the day |
+---------+---------+-------------+-------------+-----------+---------------------+
| date | total # | Gf7wGA # | Gf7wGA % | block | gap |
+---------+---------+-------------+-------------+-----------+---------------------+
| Sept 16 | 572 | 542 | 94.76% | 118414 | 278 minutes |
| Sept 17 | 543 | 505 | 93.00% | 119148 | 103 minutes |
| Sept 18 | 585 | 553 | 94.53% | 119477 | 110 minutes |
| Sept 19 | 580 | 543 | 93.62% | 120445 | 18 minutes |
| Sept 20 | 593 | 508 | 85.67% | 121096 | 24 minutes |

bram_vnl

legendary

Activity: 1148

Merit: 1000

good morning

ny2cafuse

legendary

Activity: 1582

Merit: 1002

HODL for life.

Quote from: /GeertJohan on September 20, 2014, 04:08:21 PM

We won't be the first Scrypt coin with DGW3, there are at least 3 others.
The fun thing about the diff re-adjustment algo (digi, DGW3) is that it does not have to know the hashing algorithm (scrypt, X11). It simply modifies the difficulty by a factor, the factor is calculated based on the target time for the past n blocks (nTargetTimespan), and the actual time for the past n blocks (nActualTimespan). The factor is applied to the average difficulty for the past n blocks (PastDifficultyAverage and bnNew).

I've made a gist to make it easy for you guys to read the code: https://gist.github.com/GeertJohan/b28da8105babf0553f21

So basically the parameters that can be changed are the max/min factor applied (lines 56 to 61 in the gist) and the number of blocks that are taken into the calculation (lines 12,13 in the gist).
I'm looking into that and have asked Evan (DGW author) for comments.

Damn, you read my mind. I was tempted to ask for a link to the DGW3 code, but I was like, "don't be lazy, Fuse... just go look for it". Then I got lazy, and forgot to look.

+1 for reading my mind. Grin

-Fuse

/GeertJohan

sr. member

Activity: 409

Merit: 250

Quote from: ny2cafuse on September 20, 2014, 02:44:17 PM

Quote from: Svener on September 20, 2014, 02:32:42 PM

Quote from: ny2cafuse on September 20, 2014, 02:03:45 PM

I had a conversation with Kilo after he posted the BTM post. In our discussion, he explained why BTM is a killer solution to the problems coins face with swings in hashrate and difficulty. I'll give it this much, it's a brilliant approach to solving the problem. However, it's an algorithm that is good from launch onward, not something you set midstream. DGW3, Digishield, etc. don't alter the base mechanics/dynamics of the coin. They only alter the process of accepting blocks into the chain. Additionally, they don't require a hardfork. The BTM solution needs a hardfork, and it changes major aspects of the coin. As stated above, you're looking at around a 24 hour confirmation time with it. That's a lot of time in which something could happen to the blockchain. Maybe I'm daft, but I just don't see the benefit of the BTM solution over something like DGW3 or Digishield.

It's all going to even out mining in the end. I say do whatever has the least amount of impact on the coin as a whole. IMO, DGW3 or Digishield does that.

-Fuse

I am also happy to see the devs are looking at DGW3, most scrypt coins just do digishield because it is the easier option. I don't see any normal scrypt coins with dgw3? So it might make NLG unique in some weird way.

Easy/effective. Pretty much why most coins go with it.

-Fuse

We won't be the first Scrypt coin with DGW3, there are at least 3 others.
The fun thing about the diff re-adjustment algo (digi, DGW3) is that it does not have to know the hashing algorithm (scrypt, X11). It simply modifies the difficulty by a factor, the factor is calculated based on the target time for the past n blocks (nTargetTimespan), and the actual time for the past n blocks (nActualTimespan). The factor is applied to the average difficulty for the past n blocks (PastDifficultyAverage and bnNew).

I've made a gist to make it easy for you guys to read the code: https://gist.github.com/GeertJohan/b28da8105babf0553f21

So basically the parameters that can be changed are the max/min factor applied (lines 56 to 61 in the gist) and the number of blocks that are taken into the calculation (lines 12,13 in the gist).
I'm looking into that and have asked Evan (DGW author) for comments.

ny2cafuse

legendary

Activity: 1582

Merit: 1002

HODL for life.

Quote from: Svener on September 20, 2014, 02:32:42 PM

Quote from: ny2cafuse on September 20, 2014, 02:03:45 PM

I had a conversation with Kilo after he posted the BTM post. In our discussion, he explained why BTM is a killer solution to the problems coins face with swings in hashrate and difficulty. I'll give it this much, it's a brilliant approach to solving the problem. However, it's an algorithm that is good from launch onward, not something you set midstream. DGW3, Digishield, etc. don't alter the base mechanics/dynamics of the coin. They only alter the process of accepting blocks into the chain. Additionally, they don't require a hardfork. The BTM solution needs a hardfork, and it changes major aspects of the coin. As stated above, you're looking at around a 24 hour confirmation time with it. That's a lot of time in which something could happen to the blockchain. Maybe I'm daft, but I just don't see the benefit of the BTM solution over something like DGW3 or Digishield.

It's all going to even out mining in the end. I say do whatever has the least amount of impact on the coin as a whole. IMO, DGW3 or Digishield does that.

-Fuse

I am also happy to see the devs are looking at DGW3, most scrypt coins just do digishield because it is the easier option. I don't see any normal scrypt coins with dgw3? So it might make NLG unique in some weird way.

Easy/effective. Pretty much why most coins go with it.

-Fuse

Svener

hero member

Activity: 502

Merit: 500

Quote from: ny2cafuse on September 20, 2014, 02:03:45 PM

I had a conversation with Kilo after he posted the BTM post. In our discussion, he explained why BTM is a killer solution to the problems coins face with swings in hashrate and difficulty. I'll give it this much, it's a brilliant approach to solving the problem. However, it's an algorithm that is good from launch onward, not something you set midstream. DGW3, Digishield, etc. don't alter the base mechanics/dynamics of the coin. They only alter the process of accepting blocks into the chain. Additionally, they don't require a hardfork. The BTM solution needs a hardfork, and it changes major aspects of the coin. As stated above, you're looking at around a 24 hour confirmation time with it. That's a lot of time in which something could happen to the blockchain. Maybe I'm daft, but I just don't see the benefit of the BTM solution over something like DGW3 or Digishield.

It's all going to even out mining in the end. I say do whatever has the least amount of impact on the coin as a whole. IMO, DGW3 or Digishield does that.

-Fuse

I am also happy to see the devs are looking at DGW3, most scrypt coins just do digishield because it is the easier option. I don't see any normal scrypt coins with dgw3? So it might make NLG unique in some weird way.

ny2cafuse

legendary

Activity: 1582

Merit: 1002

HODL for life.

I had a conversation with Kilo after he posted the BTM post. In our discussion, he explained why BTM is a killer solution to the problems coins face with swings in hashrate and difficulty. I'll give it this much, it's a brilliant approach to solving the problem. However, it's an algorithm that is good from launch onward, not something you set midstream. DGW3, Digishield, etc. don't alter the base mechanics/dynamics of the coin. They only alter the process of accepting blocks into the chain. Additionally, they don't require a hardfork. The BTM solution needs a hardfork, and it changes major aspects of the coin. As stated above, you're looking at around a 24 hour confirmation time with it. That's a lot of time in which something could happen to the blockchain. Maybe I'm daft, but I just don't see the benefit of the BTM solution over something like DGW3 or Digishield.

It's all going to even out mining in the end. I say do whatever has the least amount of impact on the coin as a whole. IMO, DGW3 or Digishield does that.

-Fuse

thsminer

sr. member

Activity: 332

Merit: 250

Quote from: BioMike on September 20, 2014, 12:53:59 PM

Quote from: thsminer on September 20, 2014, 12:50:09 PM

Quote from: BioMike on September 20, 2014, 11:46:50 AM

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

This would induce a problem when the diff rises organically. The confirmations would lower and lower over time.

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.

True. And to answer your initial question the answer is yes. In the BTM code its fixed to 720 initialy but nothing prevents manipulating that value.

BioMike

legendary

Activity: 1658

Merit: 1001

Quote from: thsminer on September 20, 2014, 12:50:09 PM

Quote from: BioMike on September 20, 2014, 11:46:50 AM

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

This would induce a problem when the diff rises organically. The confirmations would lower and lower over time.

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.

thsminer

sr. member

Activity: 332

Merit: 250

Quote from: BioMike on September 20, 2014, 11:46:50 AM

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

This would induce a problem when the diff rises organically. The confirmations would lower and lower over time.

Bluestreet

legendary

Activity: 988

Merit: 1000

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!

BioMike

legendary

Activity: 1658

Merit: 1001

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

thsminer

sr. member

Activity: 332

Merit: 250

Quote from: BioMike on September 20, 2014, 11:31:44 AM

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.

thsminer

sr. member

Activity: 332

Merit: 250

Quote from: /GeertJohan on September 20, 2014, 11:14:08 AM

I have also thought about that yes: rejecting blocks that are mined too soon. However, a miner could then mine the block in advance and broadcast it when the time is right.
So lets say the algorithm denies blocks with a timestamp within 20 seconds of the previous block. A jump pool operator could easily write some software to work arround this. The pool would generate 20 blocks in advance, each with a timestamp that is 20 seconds in the future relative to the previous block. Then the pool op would simply broadcast each block at exactly the right times. The pool's chain would automatically win as the normal miners simply can't generate blocks that fast. (edit: and they aren't coordinated to mine blocks in advance)
Please correct me if I'm wrong or if I'm overlooking something.

Yep, that could be done. However, asume some pool writes software to do this, they better use that technique to do some sort of spend attack.
Also this would be highly theoretical because if he mined 20 blocks his chain would only win if it has the most work done and I doubt if this is the case. On the other hand he has this oportunity right now also (mining blocks in advance and send them in at good times to keep the diff within limits). So not using something because it possibly can be manipulated is an awkward logic.

Topic: NA - page 449. (Read 893616 times)