could someone sum up the features of this fork?
1) Dangerously  fast blocks 2) Escrow implemented 3) nonstandard tx enabled 4) Upcoming (hopefully soon) message signing 5) general intent to be experimental and feature-rich [I really hope some coderfolk would hop in so more awesome tweaks and tricks can be rolled out. I especially want some more robust anti-time-trickery tweaks towards which I have been pointed and the "hidden transfer" script implementation) |
|
|
|
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. Someone just create 20,000 blocks in less than an hour. The first 20,000 took over 48 hours. Difficulty is 0.06. Exploit has not been fixed. At this rate the chain may as well restart because if an exchange opens 1 person will have 95% of the coins which makes no sense. Given that the upper limit on maximum number of Geists is above hundred billions, and that I pre-mined meself quite a bunch (primarily due to my desire to start a laundry with "squeaky clean coins" should GG persevere) I am reluctant to do a restart. Investigation is in progress, I am standing by for feedback as to possible causes from upstanding members  (I am reasonably certain that the limit on accept window is 10 in the latest release, but if someone has 51% of the net he can set whatever accept he wishes - and whatever anything else for that matter) I would be very grateful if BitcoinEXpress commented on current state of affairs in a constructive manner. |
|
|
|
I have a... lingering suspicion that we have a case of "51 attack" here. BitcoinEXpress is that so ? |
|
|
|
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. Someone just create 20,000 blocks in less than an hour. The first 20,000 took over 48 hours. Difficulty is 0.06. Exploit has not been fixed. At this rate the chain may as well restart because if an exchange opens 1 person will have 95% of the coins which makes no sense.
That would be me ! Hey dude, are you using creative timestampting or some thing like that ? |
|
|
|
|
BTW, Geist Geld site will be soon upon us.
It will have bounties and stuff, like every fork (I tried adding blackjack and hookers but did not succeed)
|
|
|
|
LOLCUST: Bitcoin Express has enough GH/s to be a pool himself. Problem solved!
I am more concerned about pools in terms of how will the "share" distribution mechanisms handle the speeds necessary to effectively mine 15/s blocks, not just how network adjusts to high GH/s. The best way to find out, and that is to get pools into the fray and see how it goes. |
|
|
|
Actually, a pool would be vastly more needed now than an exchange.
Geist Geld, by virtue of fast blocks, favors significant centralization, and pools naturally provide a way to arrange a limited, competitive form of centralization.
Also, it would be interesting to see whether such fast blocks cause "quirkiness" in pool software operation.
P.S.:
Geist Geld isn't limited to experiments with block rate.
It has enabled nonstandard transactions, already supports Escrow (multisign transactions) and is likely to support message signing pretty soon.
If you want people to mine it, there needs to be an exchange also.Point.
Proposal:
Launch pool first, get ETA of +3 (or whatever DoubleC is comfortable with) days on exchange opening. |
|
|
|
I would say you nailed this one bullseye with one shot. I think your real concern isn't our "safety" it's yours. Sooner or later one of these alt-chains are going to replace Bitcoin if Bitcoin doesn't do some seriously needed updating and improvements.
You know it, I know it and so does everyone else.
Sometimes the truth isn't all warm and fuzzy, sometimes it's just plain brutal.
I'd like to point out that there is no particular reason why several chains with different properties can't coexist. For instance, there could be one well-established, reliable chain with only the most needed, most tested and most secure features, and a [pimp] fast-blocked, permanently experimental (sorta like TOR is always experimental forever ) feature-rich one [/pimp] , as well as dedicated-purpose chains like Namecoin and such. Also, coins with different degrees of "necessary centralization" might exist, with userbase preference being driven by how comfortable they are with a given net's distribution of "powers that be" Bitcoin, due to its prominence, has become "serious business". That necessitates a very conservative approach to development. [pimp]That's why I started a fork with a more lighthearted approach to ... pretty much everything [/pimp] |
|
|
|
|
Actually, a pool would be vastly more needed now than an exchange.
Geist Geld, by virtue of fast blocks, favors significant centralization, and pools naturally provide a way to arrange a limited, competitive form of centralization.
Also, it would be interesting to see whether such fast blocks cause "quirkiness" in pool software operation.
P.S.:
Geist Geld isn't limited to experiments with block rate.
It has enabled nonstandard transactions, already supports Escrow (multisign transactions) and is likely to support message signing pretty soon.
|
|
|
|
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. |
|
|
|
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 ?
|
|
|
|
Hello! As some of you might know, I have started a humble little fork, with the explicit purposes of 1) seeing how a "very" fast block rate fares (so far it's been doing relatively nice) 2) otherwise experimenting with various interesting features that aren't currently ripe for wide-scale use in general bitcoin 3) adopting a different block rate / decentralization tradoff stance, one that favors faster blocks 4) providing an environment where those interested can test out various optimizations before they can go into bitcoin proper and generally provide a less "serious business" coin for programmers to play with 5) assuming the alt cryptocurrency in question survives and reaches the point of transitioning to block rate of 7 secs per block (which is one of the "goals"), see how a currency with fixed, non-changing production rate behaves economically Thread here.As some of you might know, I am not a programmer (I would hardly qualify for a code monkey), and thus the project so far is somewhat lacking in talented code contributions (message signing would be interesting thing to test out on GG, for one). Thus, people with coding skills, free time, and desire to contribute their expertise to an experimental "fast" blockchain, or just provide constructive advice, are hereby kindly invited. Thank you for your attention |
|
|
|
Namecoin [pr_mode=1] and of course the coin I have started, GeistGeld [pr_mode=0] |
|
|
|
|
So, if I just keep money in this coin, they burn up?
Why not just keep them in dollars then ? :p
|
|
|
|
I bet he will go for 7 sec/blocks just to top my fork |
|
|
|
|
If it wasn't for the risk of person who insisted on GeistGeld name for my fork going amok on me, I would have totally rebranded the project ;-)
|
|
|
|
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 ? |
|
|
|
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 |
|
|
|
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 ? |
|
|
|
|
Show Posts
