Bitcoin Forum
December 06, 2016, 08:26:00 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »  All
  Print  
Author Topic: [ANN] Freicoin: demurrage crypto-currency from the Occupy movement (crowdfund)  (Read 56326 times)
maaku
Legendary
*
Offline Offline

Activity: 905


View Profile
July 02, 2012, 08:30:20 PM
 #121

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?

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

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481012760
Hero Member
*
Offline Offline

Posts: 1481012760

View Profile Personal Message (Offline)

Ignore
1481012760
Reply with quote  #2

1481012760
Report to moderator
1481012760
Hero Member
*
Offline Offline

Posts: 1481012760

View Profile Personal Message (Offline)

Ignore
1481012760
Reply with quote  #2

1481012760
Report to moderator
1481012760
Hero Member
*
Offline Offline

Posts: 1481012760

View Profile Personal Message (Offline)

Ignore
1481012760
Reply with quote  #2

1481012760
Report to moderator
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
July 02, 2012, 08:53:52 PM
 #122

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?

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.

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

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.

Perfect.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
maaku
Legendary
*
Offline Offline

Activity: 905


View Profile
July 02, 2012, 09:23:22 PM
 #123

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
July 02, 2012, 10:11:40 PM
 #124

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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
galambo
Sr. Member
****
Offline Offline

Activity: 390



View Profile
July 02, 2012, 10:17:34 PM
 #125


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
Sr. Member
****
Offline Offline

Activity: 390



View Profile
July 02, 2012, 10:37:53 PM
 #126


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...   Lips sealed

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 Smiley)


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 Wink
maaku
Legendary
*
Offline Offline

Activity: 905


View Profile
July 02, 2012, 11:17:24 PM
 #127

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

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
galambo
Sr. Member
****
Offline Offline

Activity: 390



View Profile
July 02, 2012, 11:26:20 PM
 #128

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 Wink
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
July 03, 2012, 12:09:43 AM
 #129

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
Legendary
*
Offline Offline

Activity: 905


View Profile
July 03, 2012, 12:13:13 AM
 #130

Which pool carried out that attack?

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
July 03, 2012, 12:44:32 AM
 #131

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
Sr. Member
****
Offline Offline

Activity: 464



View Profile
July 03, 2012, 12:47:23 AM
 #132

Interesting.

maaku
Legendary
*
Offline Offline

Activity: 905


View Profile
July 03, 2012, 12:47:45 AM
 #133

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

We'll see...

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
smoothie
Legendary
*
Offline Offline

Activity: 1834


LEALANA Monero Physical Silver Coins


View Profile
July 03, 2012, 12:48:03 AM
 #134

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  Grin

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
markm
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
July 03, 2012, 05:42:41 AM
 #135

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
July 03, 2012, 06:35:29 AM
 #136

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...   Lips sealed

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


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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
July 03, 2012, 04:08:48 PM
 #137

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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
LoupGaroux
Sr. Member
****
Offline Offline

Activity: 420



View Profile
July 03, 2012, 05:02:00 PM
 #138

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

54Gh/s bASIC Bitcoin Mining Devices
Pre-Order Yours Today!     
Only $1069.99 ! @ http://www.BitcoinASIC.com


Look^^ I'm selling my soul too!
maaku
Legendary
*
Offline Offline

Activity: 905


View Profile
July 03, 2012, 05:30:07 PM
 #139

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.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 03, 2012, 05:37:52 PM
 #140

1HzH4YtFwBQXyF2NCCwyY2qFCCsBsmdN3j
Total Received   0.20115289 BTC   
Final Balance   0.20115289 BTC

I lol'd.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!