Topic: [7.3 btc bounty] Implement demurrage in an alternative chain with merged mining (Read 4887 times)

I should have probably closed this thread long ago saying what I'm saying now, but better late than never...

Although merged mining is not ready yet (the original bounty asked for that, but much more has been done, like a minning pool and more freicoin specific changes), this bounty was merged with the later campaign days before the official launch..

Since this bounty was basically me and nodemaster, I didn't thought it would be a problem, but let me know if you're not satisfied.

Some links:

main page: http://freico.in/
forum: http://www.freicoin.org/
code: https://github.com/freicoin/freicoin
more on github: https://github.com/freicoin

Exactly.


Not sure I understand this part.


Yes, but again, not sure what you mean in the bold part.


Yes.

If ALL the money is decreasing ALL the time, then ALL you should need is for ALL displays of actual AMOUNTS of the money to include a time-factor, so that the SAME value in the blockchain will display as a DIFFERENT amount every nanosecond or millisencond or second or minute or hour or day or whatever.

Thus the demurrage would exist purely cosmetically in the clients, needing no representation in the blockchain whatsoever.

Done this way, the number of new coins minted per block would ALSO be perceived as being less over time UNLESS the actual number minted in the actual blockchain anticipates this and compensates for it so that on average if the blocks take the average amount of time they are supposed to then the average number of DISPLAY-COINS (as distinct from the actual number the blockchain records) comes out to whatever number it is that you are aiming for it to come out as.

Basically "the unwashed masses" need not ever concern themselves with the mysterious fact that the numbers in the blockchain do not change yet the number of DISPLAY-COINS, which is the actual number used in real life, being the actual number taking into account that moment in time's demurrage of the entire all coins ever to be minted including those not minted yet, changes constantly.

Basically even block explorers would display the display-amount based on the moment the block is explored, only highly technical machine-code-types needing to know the obscure fact that the blockchain uses constants to express amounts that in reality are changing moment by moment.

-MarkM-

Yes, the point is offering the possibility of some refund from the "buffer for demurrage" instead of givving it always to miners.

You'd still need transaction fees, wouldn't you? Otherwise if it didn't make it in the next block the inputs will have decayed to be less than the outputs.

That only means that if you don't include any transaction fee, you risk your transaction to become invalid before getting included in a block. I suggested another possibility that doesn't imply transaction fees here.


We don't want the unit to decrease in value over time. Why would we want that? Besides, I have no experience at manipulating markets or pegging currencies.
We only want to push interest rates down by discouraging the hoarding of money.

Until you know which block a transaction gets into, you cannot know how much to subtract from it, and even if you do think you know, a re-org could happen later, changing which block it goes into.

Maybe it would be simpler to create a currency that you keep lowering the buy-back price of, that is, keep lowering the number of bitcoins you are willing to buy it back for, so that it effectively keeps going down in value over time.

-MarkM-

About the 2 btc nodemaster gave.


No, freicoin forums are still open. And this bounty two. But the other campaign have been started without asking me.
Probably they're well intended but I cannot avoid to think that they may take the money and run away, leaving freicoin with a bad name.
Maybe I worry too much...

2BTC? What are you talking about? I just heard about freicoin recently and it interested me. With all the other coins that have been created since bitcoin, I thought maybe the forums had been abandoned and work had gone ahead. So I figured I'd ask.

No, it is still only a concept.
There's another campaign to try to implement it (and more things, like a web and a video).
nodemaster if you want your 2 btc back just PM. I will maintain the rest of the bounty for the minimal things I ask for here, just in case.
If they code it they will take this too. If they don't, I will eventually do it myself when I have the time. Not for the bounty (well, nodemaster's 2 BTC), but because I really have faith in the currency.

So is Freicoin dead now?

Well it seems that maaku is already implementing it. I'm trying to change some of their design decisions.
I would prefer to directly fork bitcoin to take advantage of its code updates when it's possible. I won't code anything until I finish my college final project, until the algorithm learns how to play Reversi/Otello on its own (neural networks + genetic algorithms + GPGPU).

But even if I could, I think some issues have to be addressed first. For example, the formula for the coins to generate. Since the freicoin community is still tiny, I'm not really in a hurry, but if someone wants to take the bounty, the sooner we have the code to test it the better. I also wanted to see merged mining in production before launching freicoin, but now it seems that maybe that won't happen soon (because of ArtForz/btcExpress attack).

About Ripple, I don't know if Ryan is currently improving ripplepay or already implementing distributed ripple. I think he's improving ripplepay while editing the protocol draft. I would want to have more general conditions (an scripting language like in bitcoin) instead of only registries. But since most people don't like the registries idea, Ryan has taken it out of the base protocol.
I've also proposed to fellow traveler a way to implement ripple inside OT, but I'm still waiting an answer about its feasibility.

I really want to have the code for both freicoin and distributed ripple right now, but I still think there's some design issues to be solved.

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.

Yes, transactions from "old accounts" will be processed faster even with no transaction fees. But I don't see how that's desirable.
With my proposal, the user will add more funds than needed to the transaction to pay the demurrage charged from the creation of the transaction to its inclusion in the chain. With the change if this extra coins he can do:

1) Keep it to himself
2) Give it to the miner
3) Give it to the recipient
4) A combination of the three

He can also specify a transaction fee to the miner. My proposal (apart from maintaining demurrage revenues for miners constant), gives more freedom to the users to decide what is better for them.

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

Actually I had another idea: https://bitcointalksearch.org/topic/m.453112
This way you could specify the exact fee to the miner.


I don't understand why your solution results in faster processing for the user. My CTxOut::getValue(int nHeight) method seems very fast to me.
You need to make a very similar method for calculating the fee. Actually users still need my method to check their current balance (or the balance of any given address). You cannot explicitly represent the real balances in the block chain because they change with each new block.

I'm curious about your project. Is it also written in C++ ? Is it very different from bitcoin or is just a cleaner and more readable implementation?

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 think this is the simplest way to implement it. Why is it less desirable?


Having it demurrage charged explicitly in the block chain only leads to complications.
For example, How do you warranty that the total demurrage charged with each block is equal to the reward?

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?