I do, because for those ~17 years the owner of those coins would have received a benefit from the levied fee had he chosen to spend them.

Bit atrophy? A stray cosmic ray?

Yes, I'm aware of that and consider it a feature. I don't think that lost coins is an issue, except in the very long-term.

Though I am not a core developer by any means, let me say that this is a great suggestion and I am surprised this thread has languished.

Yeah, but my proposal also includes a new transaction type where fees can be claimed as a bounty each time an output halves in value, solving that problem.

If all you are trying to do is recover lost coins, that's fine. But that's really more of an added benefit to demurrage, whose primary purpose is much more expansive.

Because my proposal trades that inconvenience to the miners with a reward for the user: those demurrage fees are treated as transaction fees, so their transaction is processed quickly and at less cost. These may be heretical words on this forum, but I'd rather reward the consumers in the economy than the miners.


But we should move this debate elsewhere if you want to continue it.

Demurrage solves that problem definitively. Do a search for ‘freicoin’ on this forum.

This would be extraordinarily useful for high-value accounts, ones which store millions+ of USD worth of crypto-tokens. Something like that is simply too valuable to secure on any system connected to the internet.

My group is working on this for our own altchain client. In our application, the “master keys” to a bank or exchange's primary account will be printed off as QR codes, and stored in safety deposit boxes. Transactions to/from this account would use MULTISIG with 2-of-3 signatures required, and we'll have an offline machine in a secure location (safe requiring multiple keys to access) with attached scanner and printer. To do a transaction out, you need at least all the keys to the safe and two QR codes. The machine performs an offline transaction (using the scanner to input the keys), then prints that transaction as a QR code. Anyone can then take that QR code and use it on a machine connected to the internet to broadcast the transaction.

The master keys to the organization's accounts are never stored or processed on a computer connected to the internet, multiple people are required to be present making it harder for an insider job, and existing/familiar organizational security measures can be employed.

Demurrage would solve this...


Anyway, simply build into the client an automatic ‘transfer’ from one address to another in your wallet every year or so; the user need not even be notified. If an output goes stale for three years or more, that means the either the owner hasn't been seen in two years or the wallet is lost. The output is then up for grabs.

I'm implementing something similar to this in my demurrage-based test block chain. Demurrage fees are assessed as transaction fees when the coins are spent, but each time an output halves in value due to fees (takes about 20 years), those fees, rounded up, become up for grabs. Eventually lost coins are re-entered into circulation.

What a joke. They want to hire CEO, lead front-end, and lead back-end developers (all founder-level positions), for what one can only assume from the posting to be minimal/non-controlling equity? And no investor worth their salt recruits a position this high up off a job posting. You use people you know, and the people they know--everyone knows everyone here in the valley. Who are these jokers?

There are silicon valley startups working on bitcoin. There are even some working on new blockchains (I'm lead developer for one of them). But these guys come off as pretty amateurish.

I value price stability, just as you do. But you and I are working to create an alternative currency, so naturally we think about these long-term, macroeconomic issues. On the other hand, most people will be driven by short-term self-interest. Merchants will want higher prices, consumers will want lower prices. Miners will want more subsidy, investors/hoarders will want deflation. Yes, it will reach some sort of equilibrium--but there is no reason to presume that it'll be at stable spending power.

It won't balance out unless the miners and speculators just happen to have equal assets, which is unlikely.

How does that achieve price stability, however? People would vote with their self-interest in mind, probably with the miners voting for higher subsidies, and everyone else voting for lower.

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

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.

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.

There are some points there I would like to address, but I'm still waiting for my newbie status to be lifted



We're on the same page then. But for completeness sake, there are two trade-offs that I glossed over:

First, having automatic withdraws is more convenient for miners as it results in consistent and predictable yields. Using transaction fees as the method makes mining a bit like playing the lottery--some miners will be fortunate enough to generate blocks containing transactions with large fees, others will not. However pooled mining will greatly alleviate this, and the total/average yield will be approximately the same as in the automatic withdraw case. IMHO this makes it a non-issue in practice.

Second, automatic withdraws correctly handle lost coins in a way that transaction fees do not. In the automatic withdraw case, lost wallets continue to depreciate in value with the proceeds slowly returning to the economy over time. However with transaction fees, if a wallet is lost those coins will never be used in a transaction and so the demurrage fees will never be assessed. A reasonable compromise that I am considering is creating a special transaction type that allows miners to proactively claim fees from inactive accounts at certain thresholds (for example, each time the account has halved in value). In that way, we get the best of both solutions.



It occurs to me that we would also have to take into consideration population growth in the steady-state (or growth of the network in initial stages) as well as productivity growth of the overall economy...

(At this point I must say that I am a programmer by training and profession, though I read the Economist on weekends. I just spent a half hour trying to analyze all the contributing factors to price inflation, at which point the complexity of it caused me to believe that this might not be the right path. So please bear with me as I attempt to reason this out, and tell me if I'm getting any part of it wrong:)

What my company and I are seeking with a demurrage currency is all the economic benefits of low, positive inflation currency, with the added benefit of long-term price stability. So I'm trying to design a system in which price inflation is stable at zero, but with a demurrage rate set so as to have the same positive effects as the Fed's 1% price inflation target.

However in designing this system I have fallen victim to the incorrect thinking that demurrage is equivalent to a corresponding price inflation. It may look that way from the consumer's perspective, but I have run some numbers to verify what you said, and now I see that macro-economically it is exactly analogous to increasing the monetary supply (which all things being equal will cause inflation, but there are other factors at work as well).

Taking this as a chance to think about what it is that we (my company) are trying to accomplish, I realize now that what we want to achieve at the most basic level is an increase in the velocity of crypto-token money, by incentivising spending and discouraging hoarding. Worrying about price inflation/deflation was attacking a correlated symptom rather than the root cause.

That simplifies things considerably because demurrage of any non-zero amount will naturally increase the velocity of money. So the only questions then are: by how much, and with what consequences?

Which puts me back at square one, and I need to think about it some more. Is this something anyone here has looked into?

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.

I'm finally out of newbie status and able to post. Here's the discussion that's been going on over on the freicoin forums (I've just copied over my posts, I hope it's still readable):


Well, I believe this is the opportune time for me to announce that my startup is working on an alternative full* bitcoin client. We will support a block chain with demurrage from day one, and we would like very much to work with you to get your support in making this the “official” freicoin block chain on freicoin.org.

(*To clarify, it's a implementation of the bitcoin protocol, as defined in the original bitcoin whitepaper, on top of a different peer-to-peer overlay network. It is intended for new alternative block chains, and it's not bit-compatible with the mainline bitcoin block chain or network protocol.)

We will be implementing our own general currency for exchange, and we expect a general currency should incentivize spending, discourage hoarding, and maintain stable, fixed prices. Naturally your freicoin proposal fits the bill, and to my eyes at least it does so better than anything else (and in the past few weeks I think I've read every other alternative block chain proposal out there).

It will *not* be merge-mining capable, however. Merge mining requires inter-dependence between the associated block chains, which is simply unacceptable from a technical perspective and with regards to the long-term security of the network.

As a working schedule--keeping in mind that this *will* change--we'll probably have a version for internal testing by the end of September/early October, and a public beta in the November/December timeframe. If everything goes well, the beta will be become the freicoin testnet, and a new freicoin block chain generated for the official release in early 2012.

Here's the breakdown of how our demurrage block chain will differ from bitcoin:

1. 10 second blocks (EDIT: we've changed back to 10-minute blocks!)
2. 10bn freicoins (1e18 monetary units) total circulation
3. 2 hour difficulty retarget (every 720 blocks)
- Up to +10% adjustment up (EDIT: this is back to the standard 4x.. I shouldn't have lendt any credence to solidcoin)
- Up to -400% adjustment down
4. 1% demurrage per annum (but calculated per-block) (EDIT: this has been adjusted to 4%)
5. 32 freicoins issued per block

Some notes on why these numbers are chosen:

1) This may seem out of left field, but we also have to consider building a protocol that will survive humanities expansion into space, where the speed of light becomes a limiting concern. Round-trip to the moon is just under 3 seconds. Round-trip time to L4/L5 is on the order of about 17 minutes, and RTT to the orbit of Mars, Mars' moons, and NEOs is similar, albeit fluctuating. Anything further out would of course take longer. Current bitcoin network performance shows that round times on the order of a second could work. Choosing 10 seconds per block allows for a crypto-currency that comfortably includes all of cislunar space, provides a 60x improvement in verification time over bitcoin, and is within an order of magnitude of the best the current bitcoin network can do.

2) Comparisons were made with the per-capita size of the USD monetary pool, then extrapolated to an estimated 20bn residents of cislunar space in the mid 22nd century.

3) I'll simply point to solidcoin for this. I'd be curious to know if anyone has done some research on what the optimal numbers for this should be.

4) Roberto M. Billi & George A. Kahn, 2008. "What is the optimal inflation rate?," Economic Review, Federal Reserve Bank of Kansas City, issue Q II, pages 5-28.

The authors estimate that between 0.7% and 1.4% is ideal. 1% is comfortably in the middle and easy to work with. The demurrage will be paid as mandatory transaction fees (transactions will not be accepted unless the transaction fee meets or exceeds the required demurrage).

5) That this coincides with solidcoin's choice is pure coincidence. With 1% demurrage per annum, one can expect roughly 32 freicoins of demurrage per block in the steady-state. While freicoins are still being mined, the yield (new coins + demurrage + tx fees) will be between 32 and 64 freicoins, on average.