Topic: [ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund) - page 19. (Read 68048 times)

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-

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

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

We'll see...

Interesting.

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.

Which pool carried out that attack?

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.

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

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%.

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

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.

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.


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.

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?

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.

Yes, I agree. But I'm not sure how your current proposal would work.
You say "So the reward for each block in the first 4 years is 50 freicoins + the per-block demurrage rate applied to the existing monetary base"
I guess you then reduce to 25 + ...
But I kind of dislike the resulting curve (mainly for rewards, but neither for the base).
Instead of the simplest "always constant" issuance that takes so long, we thought about beginning fast and then annealing it each year, or each block...
Here's one possibility (that a linked to before):

int64 static GetBlockValue(int nHeight, int64 nFees)
{
 int64 nSubsidy;
 if (nHeight > EQUILIBRIUM_BLOCK) {
 nSubsidy = EQUILIBRIUM_REWARD;
 } else {
 nSubsidy = INTIAL_REWARD + ((nHeight - 1) * DECAY);
 }
 return nSubsidy + nFees;
}

The constants would be defined like this:

#define EQUILIBRIUM_REWARD 1000 * COIN //this can be changed
#define MAX_BASE 1000000000 * COIN //1 Billion, this can be changed
#define EQUILIBRIUM_BLOCK 250000 // 5 years, this can be changed
#define DEMURRAGE_RATE 0.0001 // 1 - 0.0001, ~5% annual, this can be changed
#define DECAY 0.008 // can be changed// MAX_BASE = (EQUILIBRIUM_BLOCK/2) * ((2*INTIAL_REWARD) + ((EQUILIBRIUM_BLOCK - 1) * DECAY)) - DEMURRAGE_CHARGED_UNTIL_EQUILIBRIUM
#define INTIAL_REWARD ((((MAX_BASE + DEMURRAGE_CHARGED_UNTIL_EQUILIBRIUM) * 2) / EQUILIBRIUM_BLOCK) - ((EQUILIBRIUM_BLOCK - 1) * DECAY)) / 2

We discussed extensively about this (and the max supply and final reward, all of them interrelated) in the freicoin forum thread:
http://www.freicoin.org/gesell-currency-t8.html

I think we kind of agreed on using arithmetic progression. But there's lots of possibilities (I know, infinite, I mean appealing possibilities).
Please, take a look at that thread.


Perfect.

Yes, the 5-10% “Freicoin-core” consists of demurrage + merged mining patches applied to Bitcoin-Qt (plus, of course, build servers for doing cross-platform testing and deployment). The 25-35% “Freicoin-extra” is stuff like Armory support, blockchain pruning, mining pools, exchanges, etc.

The prototype overlays demurrage on top of the usual Bitcoin subsidies. So the reward for each block in the first 4 years is 50 freicoins + the per-block demurrage rate applied to the existing monetary base. An alternative I'm considering is what your propose: eliminate the stepped Bitcoin subsidy algorithm and instead issue subsidy to miners equal to the demurrage rate applied to the eventual total steady-state monetary base, i.e. constant rewards forever.

The downside of this later approach is how long it would take to generate the total monetary base. It would take 15 years to generate half of all freicoins, 30 years for 0.75M, etc. It would take 75 years to generate 96% of the eventual total monetary base. The problem being that it would take decades until the inflation due to the expanding monetary base isn't the dominating factor, and therefore wouldn't be an effective test of a demurrage currency in the wild.

I think it's better for everyone's interests to fill the monetary base as quickly as possible, although not so quick as to have large concentrations of wealth among early adopters. Do you agree?


It'll be pre-announced, code and binaries available, only the genesis block mined, etc. etc. Just like the litecoin release.

Testnet binaries will be available sooner, so we can make sure the final release goes flawlessly.

That's great!  Make sure to at least post an update here once you code it up so people can start testing it out.

Thank you for explaining that. Does the 5-10% include merged mining with bitcoin and namecoin or that goes in the services part?

Is the reward for miners constant or there's complicated calculations at the time of the transaction?
I know you think your way is easier to implement, but I still disagree. A constant reward for miners and the following formula to check the balance of an output is much easier.

What I thought was necessary for libbitcoin (didn't test anything)

1)
We replace int64 CTxOut::getValue() for

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

2) replace

int64 static GetBlockValue(int nHeight, int64 nFees)
{
 int64 nSubsidy = 50 * COIN;

 // Subsidy is cut in half every 4 years
 nSubsidy >>= (nHeight / 210000);

 return nSubsidy + nFees;
}

for

int64 static GetBlockValue(int nHeight, int64 nFees)
{
 int64 nSubsidy = 50 * COIN; //or another constant
 return nSubsidy + nFees;
}

or something like this if you want the max base to be issued faster. I find my solution simpler and cleaner than yours. Also better for miners and the security of the network. Please, reconsider that decision too.

I don't want to seem distrustful, but I've already spent many hours promoting the concept and if I promote your campaign and then it ends up in nothing...that would be very harmful for all my previous efforts, adding "scam" connotations to the name of the currency itself.
I would prefer to code freicoin instead of the shit I code at work, but I don't care if you get pay to do it.
It's not about the credit neither. I don't like articles like this one in which "Freicoin, created by NASA engineers...", but seriously, is not about the credit.

For me It's all about the success of Freicoin.

When I see it working I will be happy to give up the domain freicoin.org, give you the small bounty I store and thank you a lot.
But until now I've only seen posts from you. I don't even know if you're a NASA scientist or a Silicon Valley entrepreneur.

I hope you can understand my worries.

@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 :\

@maaku

I'm kind of worry that you're asking for that much money. I'm not saying that you're going to runaway with the money, but the very basic (implementing demurrage and adding the merged mining that is already coded for namecoin) is much cheaper than that. I mean the pruning algorithm sounds great, but I don't think that's necessary for freicoin, just a cool thing for both bitcoin, freicoin and all the other cryptocurrencies: it could be placed in another campaign. The film, the pool, the exchange...all great and necessary things. I just don't need they're necessary for the first step.
Anyway, I hope you have more luck than I had with my old bounty.

For some of the common criticisms that have been repeated here (I didn't read the full thread)...
Some of them discussed here (but I've improved my English and knowledge in economics since then, thank you bitcoiners).

Freicoin is equivalent to expocoin (proportionally constant inflatacoin/timecoin)
If you're only thinking about miners reward, yes. But price deflation would be expected through growth instead of exponential price inflation (which is clearly an inconvenience).
And the most important thing: expocoin doesn't do anything against the basic interest. An inflation premium will be just added to the gross interest, but the basic interest won't disappear.
A more detailed explanation can be found here: https://bitcointalksearch.org/topic/m.469848

Demurrage leads to consumerism
No. If fact demurrage make us think in the long term by rducing the time preference.
A higher interest rate means a "higher short-term thinking".

Tree Metaphor
http://www.wuala.com/jtimon/temp/what%20do%20we%20invest%20in.png

Imagine you plant a tree. In ten years, that tree can give you $100 in lamber and in 100 years, $ 1000.
Now from the financial perspective.

With a currency that yields 5% interest, $100 in ten years are equivalent to $ 61.39 today. And $1000 in 100 years are equivalent to $ 7.60 today.

If the currency has 5% demurrage, $100 in ten years are equivalent to $ 167.02 today. And $1000 in 100 years are equivalent to $ 168,903.82 today.

With interest, the same stuff in the future is valued less than today. With demurrage, the same stuff in the future is valued more than today.

This proves that the structure of money has an impact in our way to value things over time.

With demurrage we have more incentive for conservation AND therefore to save.

How can you say that?, demurrage is a direct attack against savers

No. Hoarding is not the only way to save, you can store real goods instead of blocking the medium of exchange. You can also lend your money.
Gesell explains that the average saver will be able to save much more from the interests that he's saving on all its purchases (most savers pay more interest than they receive, it's just that they don't see it) here: http://www.community-exchange.org/docs/Gesell/en/neo/part4/5g.htm
There's an open discussion on the deflation thread on whether hoarders create wealth or not. I think only lenders/investors create growth, not money hoarders.

It doesn't matter, it won't be competitive. People will always prefer to hold bitcoins and therefore no merchant will accept it.

It's strange that chiemgauers can compete with euros then, since they're backed by euros and also have demurrage, anyway...
Then you don't have to fight against this, you can just wait for us fool idealists to fail on our own. No government will force you to accept it by decree.

That wasn't forgotten--that was explicitly mentioned in the article and by myself in the proposal and this thread. Freicoin is a medium-of-exchange currency only. If you have excess freicoins and you convert those freicoins into bitcoins, fiat, commercial paper, or whatever, that is both expected and inconsequential. Remember that the counter-party to that transaction now has freicoins that they want to get rid of, keeping the money in circulation.