[ANNOUNCE] New alternate cryptocurrency - Geist Geld

[ArtForz]

from my sims, asymmetric diff adjustment of any kind is "bad". makes it possible for a cartel to put more blocks per timespan and still end up with the correct sum-of-difficulty (for SC-and-clones *1.1 /4 that nets you the ~x3.5 "attack")

[1713271591]

1713271591

[1713271591]

1713271591

[1713271591]

1713271591

[1713271591]

1713271591

[1713271591]

1713271591

[1713271591]

1713271591

[Lolcust]

Meanwhile....

Guys, here's a question that crossed my mind - would changing the "adjustment step  limit" from "/4" to some other value benefit a fork with fast blocks, and if so, which approximate value should that be ?

I've always felt that there's no reason to have a limit when adjusting downwards. If the current hashing rate is less than the required to adjust exactly by /4 then you'll need 2 long retargets to get back to normal speed, but if it can adjust freely then only 1 is needed. Namecoin is currently on this predicament. The next adjustment will be by /4 to 23,500 but the "instant" difficulty (average of the last 120 blocks) is 7,000 so after this very long adjustment cycle there will be yet another long cycle, if the current hash rate remains constant.

I'm of opinion that this is primarily of concern to nets with large retarget periods (thousands of blocks, bitcoin has 2016 IIRC ) and relatively "slow" blocks.

Am I wrong ?

[MaGNeT]

Any progress yet? 

[CosicMiner]

Any updates Lolcust?

Maybe he didn't notice the forum is back up again 

[MaGNeT]

Any updates Lolcust?

Maybe he didn't notice the forum is back up again 

Maybe he's starting a Cosby Coin Chain.

[Lolcust]

Okay guys, good news are:

• Altering acceptance window seems to proceed without trouble, so I've narrowed it to 10 secs. Should be somewhat sufficient to reduce vulnerability to the timestamp thingie
• Twobits pointed me to NTP code in i0coin that was straightforward enough for me to introduce into GG without much issues. Geist thus now has NTP capability (ensuring proper time synch). Kudos twobits and kr105rlz
• Introduced checkpoints, everything seems fine
• Escrow fixed (works now)
• Nonstandard transactions now allowed (done primarily to fix  Escrow behavior, but I'm sure that the talented and creative folks here will find many more tweaks possible now that the "floodgates" are "open"

Thus, Linux users update from Github (don't forget to update the bitcoin.conf), Windows users stand by for binaries.

Bad news are:

• Updating nTargetTimespan to a  higher value (as suggested by ArtForz to further reduce the capacity for diff manipulation) in a "graceful" manner ( that is, in a manner that does not ruin stuff ) seems to be beyond my *cough* limited programming *cough* prowess.
• message signing requires both more skills and some design decisions to implement "right" (I' for one, would rather prefer the more userfriendly approach with compact signatures, as proposed by Pieter)

Those things  will have to wait until I convince a decent programmer or several to contribute...

Also (in the future), some interesting tweaking regarding Bitcoin's  behavior of ignoring a block per retarget period in order to further increase resistance to time-based manipulations, assuming programming skills are made available

[Lolcust]

New windows binary, with "crutches" (Crutches also updated with new escrow syntax, also, a naugty bug in a batch file which prevented from passing multi-parameter queries in the "control" tab is now fixed)

http://www.mediafire.com/?lk7q928f2lrduag

"Raw" .exe with most recent "raw" config

http://www.mediafire.com/?bsuhpshz12p56iz

[ArtForz]

10sec in the future should be plenty narrow enough. The simple version of my attack for a 240s retarget period needs at least a 960 sec "in the future" window for maximum effectiveness.
Have to check the ntp code you used, if it's my 'fixed' version of kr105s original code it's not very nice to pool.ntp.org (queries the same NTP server every 5 min).
I swear I have a way better one around here somewhere (runs NTP in seperate thread, takes round trip time into account, only queries ntp once per hour after initial sync, compares local, ntp and median of peer times and warns user if theres a large difference).

[MaGNeT]

New windows binary, with "crutches" (Crutches also updated with new escrow syntax, also, a naugty bug in a batch file which prevented from passing multi-parameter queries in the "control" tab is now fixed)

http://www.mediafire.com/?lk7q928f2lrduag

Now testing

[2112]

I swear I have a way better one around here somewhere (runs NTP in seperate thread, takes round trip time into account, only queries ntp once per hour after initial sync, compares local, ntp and median of peer times and warns user if theres a large difference).

I don't understand one thing: why would one incorporate NTP into *coind? In any other software that I know NTP is handled by split ntpd-daemon & in-kernel-timeadj in a closed feedback loop. The net effect is that gettimeofday() (or an equivalent) returns very accurate time (fraction of millisecond when stratum > 0). Any other software can just use gettimeofday() and rely on it being very accurate and monotonic.

What so special about *coind that it would require a built-in implementation of NTP?

[ArtForz]

1. we need a clock accurate to at least "block in future window"/2, better doesn't hurt. Bitcoin just uses the median of peer times as thanks to the large diff period and block-in-future window it can tolerate up to an hour or so of offset.
2. It's not a full NTP impl, just stupid SNTP w/ RTT correction (usually +-1ms on a box with properly working ntp)(and i0s original code doesn't even do RTT correction...).
3. Got a cross-platform way to determine if the system we're running on has a running and working ntpd? Does windows even have real NTP support? iirc even W7 only has a SNTP daemon to periodically sync ala ntpdate-from-cronjob.

[Lolcust]

10sec in the future should be plenty narrow enough. The simple version of my attack for a 240s retarget period needs at least a 960 sec "in the future" window for maximum effectiveness.
Have to check the ntp code you used, if it's my 'fixed' version of kr105s original code it's not very nice to pool.ntp.org (queries the same NTP server every 5 min).
I swear I have a way better one around here somewhere (runs NTP in seperate thread, takes round trip time into account, only queries ntp once per hour after initial sync, compares local, ntp and median of peer times and warns user if theres a large difference).

Well, yes, I suspect that it's that very code (I didn't know the fix was yours, and just credited the guy who committed. If you want, I can update the credits in the code comments).

I'm  sure your code is good, but I reasonably doubt that I will be able to implement it by myself (my skills are only a notch above copy/paste as far as programming goes, I'm a design/arts dude by trade)

ArtForz , perhaps you could become a GG contributor ? What's your nick on Github ?

[smoothie]

Once again can you explain how diff. adjusts?

[Lolcust]

Once again can you explain how diff. adjusts?

Diff adjusts as with bitcoin, but re-targeting  happens every 16 blocks.

It has been brought to my attention by ArtForz that it is too little and so an increase in this value is to be expected in the future


By the way, this brings me to several  things regarding which  I would like to receive opinions and constructive arguments:

• What would be optimal retarget period for a chain with 15 second blocks (in the future might be even 7 second  blocks ) and why ?
• would changing the "adjustment step  limit" from "/4" to some other value benefit a fork with fast blocks, and if so, which approximate value should that be ?

[smoothie]

Once again can you explain how diff. adjusts?

Diff adjusts as with bitcoin, but re-targeting  happens every 16 blocks.

It has been brought to my attention by ArtForz that it is too little and so an increase in this value is to be expected in the future


By the way, this brings me to several  things that I would like to receive opinions and constructive arguments:

• What would be optimal retarget period for a chain with 15 second blocks (in the future might be even 7 second  blocks ) and why ?
• would changing the "adjustment step  limit" from "/4" to some other value benefit a fork with fast blocks, and if so, which approximate value should that be ?

So as with bitcoin 2016 blocks turns out to be 14 days. What is the period for this? 15 seconds multiplied by 16?

[Lolcust]

So as with bitcoin 2016 blocks turns out to be 14 days. What is the period for this? 15 seconds multiplied by 16?

240 seconds.

[2112]

2. It's not a full NTP impl, just stupid SNTP w/ RTT correction (usually +-1ms on a box with properly working ntp)(and i0s original code doesn't even do RTT correction...).
3. Got a cross-platform way to determine if the system we're running on has a running and working ntpd? Does windows even have real NTP support? iirc even W7 only has a SNTP daemon to periodically sync ala ntpdate-from-cronjob.

In Re:2. I believe you are at least order of magnitude optimistic with +/-1ms standard deviation. To be safe I would assume 100ms standatd deviation with just properly working ntpd (and not openntpd). So two orders of magnitude, if you take your time over the net. It is easy to get much better time over the air thanks to Uncle Sam's (or Uncle Bill Clinton's) GPS with no SA (Selective Availability) and cheap GPS mousey receivers.
In Re:3. I normally do the equivalent of "ntpq -c readvar" and "ntpdc -c loopinfo" agains localhost. I check the status bits in ntpq's output and the offset in ntpdc's output. It has been serving me well over the years.

Code:

$ ntpdc -c loopinfo
offset:               -0.000442 s
frequency:            -6.781 ppm
poll adjust:          30
watchdog timer:       28 s
$ ntpq -c readvar
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.1.1c-rc1@1.836 Thu Feb 13 12:17:19 EST 2003 (1)",
processor="i686", system="Linux2.4.20-6", leap=00, stratum=3,
precision=-15, rootdelay=14.035, rootdispersion=22.854, peer=43382,
refid=ntp.example.com
reftime=d217a3e7.a71fcd24  Sun, Sep 11 2011 14:17:27.652, poll=6,
clock=d217a40b.dd65b20b  Sun, Sep 11 2011 14:18:03.864, state=4,
offset=-0.442, frequency=-6.781, jitter=0.756, stability=0.015

In Re: Windows. MSFT has a decent NTP implementation if nobody is tampering with it, expecially in case of domain membership. But there are so many programs that tamper with the timekeeping on Windows that it is almost impossible to trust it by default.  Additionally, MSFT made some "embrace and extend" extension to NTP, they are documented on the site for European Windows developers.
In Re: pool.ntp.org. Due to rampant abuse, the members of pool.ntp.org deploy various countermeasures. One very popular is to deliver time that is obviously off by months or years. You really have to be carefull with polling pool.ntp.org more often than the default 1024 seconds.

[MaGNeT]

How big is the chance "GeistGeld" is going to an exchange?

I like the idea of fast blocks and quick confirmations.

[johnj]

I dunno.  With the average block shorter than 225mh/s can get any work in, it's going to exclude a lot of smaller machines.

I have another card on the way, even then i think I'll stll be at 50/50 reject.


(unless my experience was just a bug)

[MaGNeT]

I dunno.  With the average block shorter than 225mh/s can get any work in, it's going to exclude a lot of smaller machines.

I have another card on the way, even then i think I'll stll be at 50/50 reject.


(unless my experience was just a bug)

I did a test run with 2950Mhahs/s and I had 5 accepted / 80 rejected on average, even with CGMiner
But with low difficulty, it's normal I think.