[ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund)

[jtimon]

I have read that thread previously, but I don't remember an explanation of why such a system would be better, except that arithmetic progression would supposedly be easier to implement. But both methods are trivially easy (just a few changed lines in the calculation of nSubsidy), and the Bitcoin geometric distribution method has already been proven to work and be a relatively fair compromise. If it ain't broke, why fix it?

Bitcoin distribution hasn't proved to work. The 4 years haven't passed yet. What if the security suddenly halves when the reward drops to 25 BTC?
I'm not saying that's what will happen, but no one really knows.

Why do you dislike the resulting curves of the Bitcoin method? Sorry if I'm asking you to repeat yourself, but it's not very clear from the thread you linked to.

Because...

1) miners reward always go down until it stabilizes (instead of rising and dropping).
2) Both the reward curve and the total base curve are more "continuous".

But, yes. It is easy to implement and there's many alternatives.
The max bases and final rewards may have more to do with aesthetics...
But I like that 100 fcn per block (final reward) and 50000 blocks per year that converges at 1B max base with 4.something% demurrage I think I remember. We were looking for round numbers there, that's not really important, but easy to summarize for new people.

What I dislike are steps (in the curves) and complex signals to miners and prices.
What I want is smooth and derivates that converge at zero but don't cross it several times.

[galambo]

What I dislike are steps (in the curves) and complex signals to miners and prices.
What I want is smooth and derivates that converge at zero but don't cross it several times.

I don't think you have carefully considered the problem of synchronizing a system like you propose.

For instance, it would be possible to make a system where the difficulty of mining is constantly adjusted to global network hashing power, but a system like this would be very difficult to synchronize. The nodes couldn't agree on what blocks to accept or reject. Piecewise definitions of difficulty and generation function are unfortunately a consequence of the peer to peer network.

[galambo]

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

That wouldn't have the effect you think it would...  

You need this formula

Compound amount (single payment)  

return this.nValue *= (1 - i)^(nHeight-this.blocknumber);   // i is demurrage rate

annualized demurrage rate = 4.4/100=.044

i=(.044 interest per year)/(365.24 days per year*24 hours per day*6 ten minute blocks per hour)= 8.37e-7 interest per 10 minutes block

let me know if you see any mistakes

You can play with the effect here...

http://www.ajdesigner.com/phpdiscountfactors/single_payment_compound_amount_equation.php

put I in as "-.00000083713850837138508371385083713851" and period as number of blocks to see how much your currency multiplier would work through time )


maaku choose 4.4% because he likes irrational numbers...  Using the generally accepted "rule of 72 " (we don't use the rule of 69 because that is a naughty number) we see it will take 16.363636363636363636363636363636363636363636363636363636363636363636363636363. .. years to halve your money

[maaku]

Actually, we chose 4.4% because, it appears, I screwed up a calculation at some point (perhaps rounding error?). The goal was to pick a simple value that when compounded put us within the 4-5% range (I was advocating 4% at the time, jtimon 5%; I was hoping to split the difference). At some point I tried 8e-7 = (1/1250000), and calculated 4.4%. Of course I just did the calculation again and realized it's closer to 4.1%. I'm not sure how I made the error earlier, or if I was operating under different assumptions, or if I just copied down the result incorrectly. Ultimately it's an arbitrary choice.

I also got an email from someone who pointed out that there might be potential for speeding up demurrage calculations if the demurrage rate per block were an exact power of two. 2**-20 results in about 4.9% annually. Of course maybe we should forget about future minor optimizations and simply fix it at 4.5%.

[galambo]

Actually, we chose 4.4% because, it appears, I screwed up a calculation at some point (perhaps rounding error?). The goal was to pick a simple value that when compounded put us within the 4-5% range (I was advocating 4% at the time, jtimon 5%; I was hoping to split the difference). At some point I tried 8e-7 = (1/1250000), and calculated 4.4%. Of course I just did the calculation again and realized it's closer to 4.1%. I'm not sure how I made the error earlier, or if I was operating under different assumptions.

I also got an email from someone who pointed out that there might be potential for speeding up demurrage calculations if the demurrage rate per block were an exact power of two. 2**-20 results in about 4.9% annually. Of course maybe we should forget about future minor optimizations and simply fix it at 4.5%.

You're probably right... That  long string of numbers was me typing approximations (365.25) into calc.exe. only the best tools here

[doublec]

If you enable merge mining on Freicoin, how will you prevent large miners from taking over the chain as happened when coiledcoin was released? In that case a pool used merge mining to have >51% of mining power and refused to accept any blocks from anyone else. As a result they got all the coins and the chain was effectively dead.

Not enabling merge mining has the issue of large miners from doing similar but they don't get the attack for free - they won't earn bitcoins while doing it. This attack pretty much stopped development of new alt coins from what I can tell.

[maaku]

Which pool carried out that attack?

[doublec]

Which pool carried out that attack?

See this post and related thread. It's a contentious issue so rather than concentrating on the who, concentrate on the fact that it happened. Any large pool or miner can do it, so any new merge-mineable coin would need to be able to handle it.

[mokahless]

Interesting.

[maaku]

Well, I'd rather just speak with the people involved and get their consent, as it is, to proceed unmolested.

We'll see...

[smoothie]

Which pool carried out that attack?

See this post and related thread. It's a contentious issue so rather than concentrating on the who, concentrate on the fact that it happened. Any large pool or miner can do it, so any new merge-mineable coin would need to be able to handle it.

We may as well merge-mine beer coins so at least people can get drunk if they lose all their money  

[markm]

The attack done on Coiledcoin almost certainly violated laws, and it didn't actually last long, for a long time since then coiledcoin seems to have been operating normally, with the attacker simply doing normal merged mining using his pool's users' hashing power without the users seeming to care.

SO sure the attacker is still racking up coins, but others are still able to use the coins. The chap just happens to have a lot of suckers willing to freely give him hashes to do as he pleases with.

-MarkM-

[jtimon]

I don't think you have carefully considered the problem of synchronizing a system like you propose.

For instance, it would be possible to make a system where the difficulty of mining is constantly adjusted to global network hashing power, but a system like this would be very difficult to synchronize. The nodes couldn't agree on what blocks to accept or reject. Piecewise definitions of difficulty and generation function are unfortunately a consequence of the peer to peer network.

You seem to be talking about a system different than bitcoin's. Although there were some improvement proposal on the freicoin forums I wanted to keep things simple and only change what really needed to be changed.
Although probably we should consider some easy changes from here:
https://en.bitcoin.it/wiki/Hardfork_Wishlist

That wouldn't have the effect you think it would...  

You need this formula

Compound amount (single payment)  

return this.nValue *= (1 - i)^(nHeight-this.blocknumber);   // i is demurrage rate

Yes, DEMURRAGE_RATE would be your (1-i). Probably the name is not appropriate.

annualized demurrage rate = 4.4/100=.044

i=(.044 interest per year)/(365.24 days per year*24 hours per day*6 ten minute blocks per hour)= 8.37e-7 interest per 10 minutes block

let me know if you see any mistakes

Actually we could also adjust the "10 min per block" constant to get beaty numbers. For example 50000 block per year (11.something minutes per block).

You can play with the effect here...

http://www.ajdesigner.com/phpdiscountfactors/single_payment_compound_amount_equation.php

Thank you, I'll play with it later.

Actually, we chose 4.4% because...

Something around 4-5%, great. We consider something like 4.8% in one of our calculations in the post I refer to above.

[jtimon]

Hey, MarkM remembered me that we're forgetting the "exact payment problem".
My proposal was:
https://bitcointalk.org/index.php?topic=36190.msg453112#msg453112

Edit: Another consideration. I think that at the very least the pruning technology should be separated from the campaign. It would actually benefit bitcoin too, so pure austrians could contribute with that one even if they think that the whole idea of freicoin is stupid.

[LoupGaroux]

@jtimon, as it stands now we have enough to finish the minimal Freicoin client (based on Bitcoin-Qt, not Armory) and release it without any fan-fare or associated services. And we will, even if donations stop today.

The goal of the Indiegogo campaign is to take it far enough that enough of an ecosystem exists for merchants to start accepting freicoins as-is, and to create marketing materials for people on the ground to use to explain and promote the currency. About 5-10% will be spent on the basic core, another 25-35% on services and features that are necessary for use, and about 40% on the website, video, and promotional material. The rest, unfortunately, goes to Indiegogo fees and taxes :\

Interesting that $825 of your needed $28,000 (less than 3%!) is enough to begin implementation. Your estimation of fees, publicity and hosting costs is absurd. Unless of course, a lion's share of that amount is "fees" for the developers (who are basically just tweaking an existing code base). Nice. That kind of thinking is just a swell way to introduce the concept of diminishing net worth currency to the world. A currency that arbitrarily loses value run by folks that look to control and make a killing off if your use of it.

Thanks for playing, I'll pass. And continue to poke fun at this dramatically bad idea.

And really swell citation on the moonbat selling shamanism and money theory. It's called a clue, you need to get one.

[maaku]

Hey, MarkM remembered me that we're forgetting the "exact payment problem".
My proposal was:
https://bitcointalk.org/index.php?topic=36190.msg453112#msg453112

It's not a problem, at least not in that context. It will require implementation of receiver-fees, however, so that the receiver can make an transaction claiming the funds with extra fees in case the input value decays below the output value.

The exact payment solution would work too, and it's a toss-up as to which one is easier to implement.

[SgtSpike]

1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j
Total Received   0.20115289 BTC   
Final Balance   0.20115289 BTC

I lol'd.

[jtimon]

Hey, MarkM remembered me that we're forgetting the "exact payment problem".
My proposal was:
https://bitcointalk.org/index.php?topic=36190.msg453112#msg453112

It's not a problem, at least not in that context. It will require implementation of receiver-fees, however, so that the receiver can make an transaction claiming the funds with extra fees in case the input value decays below the output value.

The exact payment solution would work too, and it's a toss-up as to which one is easier to implement.

Sure there's more possible solutions. All I'm saying is that it is a problem that is better to solve (although not a particularly hard one).

Will you consider separating the campaign in different parts?

[galambo]

Edit: Another consideration. I think that at the very least the pruning technology should be separated from the campaign. It would actually benefit bitcoin too, so pure austrians could contribute with that one even if they think that the whole idea of freicoin is stupid.

If the aim was to create a simple clone of bitcoin with demurrage, sure. Don't you think that's aiming pretty low?

I would hope this currency becomes valuable because it is better than bitcoin (because it builds on it), not because it only copies it.

[galambo]

1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j
Total Received   0.20115289 BTC   
Final Balance   0.20115289 BTC

I lol'd.

I don't think the cross section of people that would be interested in this proposal, and the people interested in bitcoin would be very large. I certainly don't have any bitcoin. My only real interest in either is completely technological (i look at them as tools). However, if this project does everything they say they want to do I think many more people in the community will find this worthwhile.