ArtForz
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2011, 07:21:56 PM |
|
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")
|
bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2011, 07:25:28 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 ?
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
MaGNeT
Legendary
Offline
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 09:18:58 AM |
|
Any progress yet? ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
CosicMiner
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 01:28:51 PM |
|
Any updates Lolcust? Maybe he didn't notice the forum is back up again ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
MaGNeT
Legendary
Offline
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 02:12:49 PM |
|
Any updates Lolcust? Maybe he didn't notice the forum is back up again ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) Maybe he's starting a Cosby Coin Chain.
|
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 02:13:04 PM |
|
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
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 02:37:42 PM |
|
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
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
ArtForz
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 02:56:06 PM |
|
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).
|
bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
|
|
|
MaGNeT
Legendary
Offline
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 02:56:50 PM |
|
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/?lk7q928f2lrduagNow testing ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 03:05:01 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 03:23:27 PM |
|
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.
|
bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 03:38:45 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ? What's your nick on Github ?
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
smoothie
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 04:39:30 PM |
|
Once again can you explain how diff. adjusts?
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 04:46:19 PM Last edit: September 11, 2011, 04:56:27 PM by 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 ?
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
smoothie
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 04:50:54 PM |
|
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?
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
Lolcust (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 11
Hillariously voracious
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 04:57:45 PM |
|
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.
|
Geist Geld, the experimental cryptocurrency, is ready for yet another SolidCoin collapse ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Feed the Lolcust! NMC: N6YQFkH9Gn9CTm4mpGwuLB5zLzqWTWFw67 BTC: 15F8xbgRBA1XZ4hmtdFDUasroa2A5rYg8M GEG: gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 09:21:34 PM Last edit: September 11, 2011, 09:32:02 PM by 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. $ 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
Legendary
Offline
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 09:31:13 PM |
|
How big is the chance "GeistGeld" is going to an exchange? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I like the idea of fast blocks and quick confirmations.
|
|
|
|
johnj
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 09:41:04 PM |
|
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)
|
1AeW7QK59HvEJwiyMztFH1ubWPSLLKx5ym TradeHill Referral TH-R120549
|
|
|
MaGNeT
Legendary
Offline
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 11, 2011, 09:44:48 PM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) But with low difficulty, it's normal I think.
|
|
|
|
|