So any ETA on your fork maaku?
Hi, I was at a conference all week. I got plenty of code written, but didn't have time to check the forum
It's coming along, although I will refrain from making any further public announcements regarding schedule until we are close to a public beta.
I've finalized our block header and transaction formats. It *will* be merge-mine capable, but only with future currencies based on our crypto-token system. It will *not* be merge-mine compatible with bitcoin, namecoin, or any of its derivatives. I'm sorry, but the system we've come up with is simply too clean, elegant, and future-proof to give up.
We've substituted s-expressions (Lisp) for bitcoin's Forth-like scripting language. This is in part for simplicity of implementation and testing, but also because we expanded the use of the scripting language to definition of how the currency works. In effect, the behavior of the crypto-token system is governed by programmable and pluggable hooks written in the scripting language.
That's perhaps delving too deep into implementation than is necessary. Here's some updates to the user-level features of the currency:
1. Back to 10 minutes blocks
2. 1 week difficulty retargets (+/- 4x up/down)
3. 4% demurrage per annum
4. Coin generation rate... TBD
On my contentious 10-sec blocks:
I maintain that it would work, and in fact would provide more security (because the work of the network is manifested more regularly, there is a compounding effect wherein the number of confirmations matters--so 60 confirmations at 10s intervals *is* more secure than one confirmation at 10min intervals). However my project manager made me realize that the benefits are marginal, there is associated risk, some downsides (larger block-chains), and it doesn't gain us anything that we couldn't get through other means. So we're back to a conservative 10-minute round.
Difficulty retargets:
I maintain that bitcoin's two weeks is simply too long--especially if there is a drop in hashrate like we saw with namecoin. For the security of the network, it would be best if difficulty retargets occurred more quickly than a distributed, uncoordinated mining network could respond. I felt 2 hours was the right compromise in this regard--if miners collectively but individually decided to pull out, it might take a full day (given differences in timezones and reaction time). That would be enough time for one or two retargets, so hopefully the utility of the network would not be compromised.
Unfortunately, one also needs to account for statistical variance. Bitcoin is effectively using an inherently random Poisson process (the proof of work) as a clock. Only if the sample size is large enough can this be a reliable timekeeping measure. If the target interval is 10 minutes, 2 hours would be only 12 samples, which is definitely too small. 2 weeks is 2016 samples, which is certainly very conservative. 1 week would be 1008 samples, which is probably enough. 1 day would be better IMHO, but at 144 samples I need to do some math/run some simulations to see if that would still work.
The demurrage rate:
I assume there are some simplifying assumptions in the equation that you gave me, as it doesn't match the first derivative of the equation on Wikipedia. But assuming that's correct, I would target 1% price inflation for the reasons given before, and 3% GDP growth, which is also a number the Fed has consistently targeted. By your form of the exchange equation that would mean a 4% increase in the monetary supply/4% demurrage.
On coin generation:
The previous rate would have been comparable, albeit in addition to the 4% target. However it would have taken over a century to generate all the coinage! Actually, there's nothing inherently wrong with that, but it is different from bitcoin. And it indirectly raises the issue of reward for early adopters.
EVERY alt-chain so far, except namecoin, has proven to be a scammy get-rich-quick scheme. Right or wrong, the community will perceive freicoin as more of the same unless steps are taken to eliminate or compensate for unfair distribution to early adopters.
This I don't have a solution for yet, but I'm open to suggestions and interested the opinion of others here.