Topic: [7.3 btc bounty] Implement demurrage in an alternative chain with merged mining - page 2. (Read 4919 times)

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.

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 ?

http://www.freicoin.org/implementations-details-and-bounty-t13.html#p129

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/

I don't know if Freicoin ever will work on a large scale. But in fact no one knows since it has not been done before. In Germany I know about a few local clubs who have some sort of Gesells Freigeld and it seems people like it on a local scale. Furthermore I belong to the few people who are not interested in cryptocurrencies for making quick money. And I feel like we need to get this implemented just in order to see if it works. If it don't work on a global scale I guess there will be plenty of local adopters. Because as soon as freicoin is implemented we might see local clubs adopt this to get their Freigeld system online.

Added 2 BTC to the Bounty 

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.

I have to admit that I haven't though much about problems related with rounding errors. Can you give an example of a problem that could raise?


Like I said here I was thinking in account the demurrage by blocks instead of years. This way we take advantage of the "internal clock" of the network.


Yes, the idea is to not touch the blocks once they're hashed and just interpret the balance of each output taking demurrage into account.
All the inputs less their demurrage have to be greater or equal than all the outputs for a given transaction to be valid.

I didn't saw the problem of specifying an exact amount. Even if the change (the one that goes back to the sender) takes the losses from demurrage, you have to specify what is the "change" output. You also have to specify either the block count when the transaction was created or the transaction fee explicitly if you want to ensure you pay a transaction fee.
If we consider the later option, it could be an example:
Output 1: 50 (to the recipient)
Output 2: 49.98 (your change back to you)
Output 3: 0.01 [tx fee] (to the miner)
Output 4: 0.005 [losses from demurrage] (back to you if is not all spent)
Output 5: 0.005 [tx fee] [losses from demurrage] (to the miner if is not all spent)

Probably output 5 can be removed and any input freicoins not redeemed in an output are considered a transaction fee if they're not consumed before starting to charge output 4.
If both output 4 and 5 (or frc not claimed by any output) are spent, the transaction becomes invalid and will no longer be able to appear in the chain.
The unclaimed coins are the first that are going to perish by demurrage, so if you want to ensure you add a transaction fee the indicator is needed for a special type of output (maybe just sending the coins to a null address known by the network).
To indicate what is going to be the losing output, the convention could be that it is the last output. If you want to limit the minimum change you're going to receive you can add two outputs to the same address.

This demurrage is only to be applied if the inputs are less than the outputs and until the transaction is in the chain. After that all outputs suffer from demurrage in the same proportion.

Thank you for pointing out the problem.

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.

After many discussions in the forum about Silvio Gesell I have decided to take a little step fordward for freicoin.

I think the task is not hard and that (even if I'm the only one to contribute to the bounty) the reward can get sufficiently encouraging with time and bitcoin rises in prices. I just don't have the time right now.
It would be interesting to integrate it on multicoin.

The winner will be the first to implement a bitcoin-like currency with built in demurrage and that can be merged mined like namecoin will be.

I hold the coins now, but if a moderator of the forum or just someone with more reputation does me the favor of holding them, probably more people will be willing to put their coins for the bounty.

You can donate by sending you contribution here:

1N9u8az3nkztXP3xUcYFhoFsNAvARxBowq

http://www.freicoin.org/