How would you want to handle the problem of rounding?

Not that I think it will have a lot of financial significance, but it is possible to get into situations where multiple txouts could yield slightly different total value depending how they are spent.

There is also the problem of agreeing on time, and even the time between when a transaction is issued and when it is included in the block chain could make a transaction over-spend its (now shrunken) inputs, or create other sorts of "slightly off" errors.  It might make sense to define the demurrage time in terms of the block chain and not in terms of 'wall clock' time.

An alternative is to have the underlying implementation store non-shrinking coins as they are now, with no demurrage, and to change the user interface to map a nominal demur-coin to the underlying non-shrinking coin according to a formula.  Then the underlying implementation would be represented in terms of coins-at-a-particular-point-in-time which are converted to present nominal demur-coins by a pre-determined time-dependent ratio.  There is still the problem of 'slightly off' errors if someone is asking 1 DMC in payment and you make the 1 DMC payment but by the time they receive it they get only 0.99999999 DMC.  If this is a human recipient it makes no difference but an automated payment processor could reject it.

I came up with a solution for the "exact payment problem" that I think is more elegant. It doesn't need new fields but constants for the fields address and value/amount of the output.

1) A constant destination address TO_MINER (= 0 ?) which allows you to specify the transaction fee explicitly within an ordinary output.

Now the unclaimed coins don't go for the miner but to take the potential losses of demurrage during the transaction.

2) A constant amount of the output (= 0) to specify the address where the not claimed but not destroyed by demurrage coins must go. 

If no "demurrage change output" is specified, the unclaimed change goes to the miner. This way you can encourage miners to include it fast.
If various are specified, the coins are distributed proportionally. This way you can share the tx demurrage losses with the recipient in any proportion you want.

When the unclaimed coins are all "spent", the transaction becomes invalid and can not get into the chain anymore. This way you're effectively putting an upper limit on how long can (in blocks) take the transaction to be put in the chain without adding an expiry field.

Still we don't have to touch any structure from bitcoin, only how balances are interpreted.

Thank you!

As you say, if it doesn't work on a global scale, each town can run its own freicoin chain.
If you or the people from the local clubs are interested, we're discussing some of the details of the implementation (the demurrage rate, the generation curve, etc) here:

http://www.freicoin.org/

Maybe we should wait for an alternative full bitcoin client to modify it instead of the current code, or we could wait for the lib to be developed.
https://gitorious.org/libbitcoin

If we chose to fork bitcoin directly, for the demurrage, we should do the following:

1) Encapsulate CTxOut properly, making nValue private and creating get/set methods
This change will make errors appear in every place where we need to change the code.

2) CTxOut should have a block_number field or a way to access it.

3) We change int64 CTxOut::getValue() for
int64 CTxOut::getValue(int nHeight) {
   return this.nValue - (this.nValue * DEMURRAGE_RATE * (nHeight - this.blockNumber));
}

I think that (and changing GetBlockValue) should be enough.
No one willing to take the bounty ?

On 10 second rounds:

In the past two months there have been 15 reorgs of the blockexplorer.com data-collection node. Assuming that a fork of the block chain resulted in only two branches, and that blockexplorer.com had just a 50% chance of selecting the “correct” branch, that means there has been 30 forks of the block chain in the last two months. That's 30 out of 8928 blocks for July and August, or about 0.336% chance for a given block. Now assuming that the network was not subject to malicious action during this time*, that means that in those 30 instances two blocks were generated close enough in time to be within the network latency. Or put differently, we can calculate the network latency of the current, existing bitcoin network to be: 10min/0.336% = 2.02 seconds.

*If it was, that would only lower the resulting latency.

Extrapolating into the future, we can expect this number to go down, not up. That may be somewhat counter-intuitive, but what we are seeing now is the worst-case possibility. The bitcoin peer-to-peer overlay is not optimized, at all. It is also conceivable that when a crypto-currency goes mainstream, we may see the emergence of fiber-optically connected payment processing nodes that can relay blocks and transactions to disparate parts of the network very quickly.

Further, it's not very clear that an increase in the number of forks would even been an issue. Bitcoin has defenses built into the protocol for resolving such conflicts. It is only when the probability of a split exceeds 50% that the block chain becomes divergent. On the current bitcoin network, that means round times must be no shorter than 4 seconds.

10 seconds is more than twice that lower limit, and as I said that limit will only get *smaller* as the network gets smarter.
On demurrage rates:

Ultimately inflation vs. deflation will probably depend more on supply and demand on the exchanges. But short of falling back to a fiat currency, I don't know how that can be credibly regulated.

However there has been considerable research into the effects of inflation on the economy, and what an “ideal” inflation rate would be. The paper I linked to is from the Federal Reserve Bank of Kansas City, and is the best and most recent report on an ideal interest rate. It is the source of the 1% number.

Demurrage doesn't need to fully compensate against other market effects to discourage hoarding, it simply needs to be enough to make other forms of wealth building (investment, loans, etc.) more desirable. This is the exact analogue to inflation in fiat currencies, and the Fed says 1% has been good enough for them.


On tx fee vs automatic withdraws:

I'm not sure I understand you; withdraws have to be made somehow. Are you suggesting that every block assay demurrage fees for every account? That would unnecessarily grow the block chain but a ridiculous amount. Or maybe it's just done on specific intervals, every X number of blocks? That would lead to other problems as people attempt to unload their coins before a drop, then buy back in afterwards.

Or maybe it's hardcoded into the client and not explicit in the block chain, that usable account balances decrease by a small amount every time a new block is generated? I'll argue that is both more complicated to implement, and less desirable.

If, on the other hand, your point is that the user should see a number that reflects their spendable balance, then I agree. But that is a UI issue divorced from the technical implementation.

If demurrage is assessed as mandatory transaction fees, then the user still retains some benefit: transactions from their accounts are seen as more valuable, and will be processed quickly. It is also technically very simple to implement, and if the context demands it can be hidden from the user by the UI.

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.

It amounts to the same thing--in either case the client would have to add a little extra transaction fee on top of the demurrage--if the transaction doesn't make it into the next block, some of that fee will convert into demurrage. If time goes by and that transaction still isn't confirmed, eventually the fee will run out and the transaction will be marked as invalid (not enough demurrage).

So far, that's the same for either my or your implementation. Where we differ is what we do with that demurrage fee. I say give it to the miners along with the transaction fee. You say destroy those coins, and give the miners a fixed amount per block which amortizes lost coins over time. My solution has the benefit of faster processing for the user (as the demurrage fees are treated as transaction fees), whereas your solution results in more consistent block rewards for miners. In the end, that is the only difference between my suggested approach and yours.

I didn't mean computationally faster. If demurrage fees are counted as transaction fees, the transaction is more likely to be accepted for the next block, and therefore the transaction will be confirmed more quickly, on average.


The core functionality is in Python, with block-chain specific hooks written in a Python-interpreted Lisp variant. The peer-to-peer overlay network is in C++. We follow the original bitcoin whitepaper rather strictly, but it is not compatible with the bitcoin wire protocol. The block and transaction formats are modified quite heavily, the scripting language is new, and the peer-to-peer overlay network and message protocol is entirely different from bitcoin.

EDIT: And I would like to think that it is cleaner and more readable, but I suppose that is in the eye of the beholder

I have recently seen this thread as well as the freicoin page and ripple page.

I understand that planning is a must but when will implementation and testing begin?

You can only discuss something so much before it becomes a circled discussion.

So is Freicoin dead now?