[ANNOUNCE] New alternate cryptocurrency - Geist Geld - page 28.

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

Quote from: ArtForz on September 11, 2011, 09:56:06 AM

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 ?

ArtForz

sr. member

Activity: 406

Merit: 257

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.

2112

legendary

Activity: 2128

Merit: 1073

Quote from: ArtForz on September 11, 2011, 09:56:06 AM

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?

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Quote from: Lolcust on September 11, 2011, 09:37:42 AM

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

ArtForz

sr. member

Activity: 406

Merit: 257

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).

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

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

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

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

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Quote from: CosicMiner on September 11, 2011, 08:28:51 AM

Any updates Lolcust?

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

Maybe he's starting a Cosby Coin Chain.

CosicMiner

full member

Activity: 135

Merit: 100

Any updates Lolcust?

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

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Any progress yet? Grin

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

Quote from: JohnDoe on September 09, 2011, 02:18:06 PM

Quote from: Lolcust on September 09, 2011, 01:59:04 PM

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 ?

ArtForz

sr. member

Activity: 406

Merit: 257

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")

JohnDoe

sr. member

Activity: 392

Merit: 251

Quote from: Lolcust on September 09, 2011, 01:59:04 PM

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.

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

Okay guys, I've pushed the version that 1) opens up the whole accept window to .conf manipulation Multicoin-style 2) sets it to 30 secs to git

Could someone give it a quick look to see if I fucked up big time anywhere, and if not, I shall concoct win builds for this beast ASAP

P.S.:

Having update kick in at block x is somewhat above my humble abilities Sad

Lolcust

member

Activity: 112

Merit: 11

Hillariously voracious

Quote from: ArtForz on September 09, 2011, 01:41:17 PM

edit: 10 seconds or so *should* work for geist. guess miners will simply have to make sure they have a accurate clock on their boxes *g*

Let's try 30 seconds ( Due to sacarlson's kind help I have code for tweaking that stuff via config almost done) and see how bad that fares.

Quote from: ArtForz on September 09, 2011, 01:41:17 PM

edit2: I have some finished-but-needs-more-testing NTP code around here somewhere that I indended for zombie-i0 v1.2, if anyone is interested...

That's super cool, but integrating NTP into GG is way over my limited ability

P.S.:

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 ?

ArtForz

sr. member

Activity: 406

Merit: 257

Only way I see to fix the "someone produces blocks in the future to fuck with diff" problem is... to narrow the accept window a lot. When moving zombie-i0 to 90 sec/block and retarget every 3h I lowered the window to only allow blocks up to 5 minutes in the future (could've done 15 seconds as well, one benefit of the [somewhat half-assed] NTP support).

edit: 10 seconds or so *should* work for geist. guess miners will simply have to make sure they have a accurate clock on their boxes *g*
edit2: I have some finished-but-needs-more-testing NTP code around here somewhere that I indended for zombie-i0 v1.2, if anyone is interested...

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: ArtForz on September 09, 2011, 01:29:56 PM

A bit over 3400, around 4 blocks/sec average (= around 13% effective hashrate). bitcoind still starts lagging like hell beyond 3 blocks/sec or so Lips sealed

Cool. Least we got some benchmarking done.

Good test chain.

Doubt an exchange or pool will jump on this though.

No worries =)

CosicMiner

full member

Activity: 135

Merit: 100

Quote from: ArtForz on September 09, 2011, 01:25:33 PM

Quote from: CosicMiner on September 09, 2011, 01:20:16 PM

Quote from: ArtForz on September 09, 2011, 01:07:15 PM

Trying something, hold on to your hats.

Mining on full throttle this time?

Nope, but before I was always mining @ effective diff 1 due to H==0 checks in my miners and poold.
Also gave me an opportunity to test some of my bitcoind/pool performance improvements on a "live" network.

It was so fast I couldnt read the log output on geistd.

ArtForz

sr. member

Activity: 406

Merit: 257

A bit over 3400, around 4 blocks/sec average (= around 13% effective hashrate). bitcoind still starts lagging like hell beyond 3 blocks/sec or so Lips sealed

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

Quote from: ArtForz on September 09, 2011, 01:20:36 PM

Ok, done.
In case anyone is wondering what on earth that storm of blocks was, a slightly optimized bitcoind with 9Gh of miners @ diff 0.0625.

How many blocks u get in that shot?

Topic: [ANNOUNCE] New alternate cryptocurrency - Geist Geld - page 28. (Read 74190 times)