Author

Topic: Implementing demurrage: how many functions to change? (Read 1714 times)

legendary
Activity: 1050
Merit: 1003
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.

You could do this, but it is hard to get 51% to join a cartel.

That applies to using a vhanged code too.
How is that? Changed code allows an arbitrarily small minority to vote with their feet.

Mining power requires majority consensus AND the will to impose that consensus on any deviant minority.
hero member
Activity: 836
Merit: 1030
bits of proof
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.

You could do this, but it is hard to get 51% to join a cartel.

That applies to using a vhanged code too.
legendary
Activity: 1050
Merit: 1003
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.

You could do this, but it is hard to get 51% to join a cartel. The idea of rejecting blocks from independent-minded miners would be very controversial.
You may see something like this in the future, however. As mining gets more centralized, it will be easier to form cartels. The decrease in block reward will also make cartels more profitable.
hero member
Activity: 836
Merit: 1030
bits of proof
regarding demurrage: miner could impose floor to transaction fee based on coin age. No code change needed for that just, their majority will to do so.
newbie
Activity: 56
Merit: 0
Try as I might... I still don't understand why anyone would voluntarily choose a currency with built-in savings devaluation over a currency that does not exhibit this trait.
legendary
Activity: 1050
Merit: 1003
My immediate concern is that it undoes demurrage for participating actors, thereby eliminating the positive economic effects which come from universal demurrage, making me wonder what the purpose would be at all.

What you devised seems to be a mechanism for punishing people who don't participate in proof-of-stake. If that's your goal it's fine (although I don't agree with it), but the consequences are antithetical to what we're trying to do with demurrage and Freicoin specifically.


As I see it everyone is subject to demurrage. People are paid for participating by having their demurrage forgiven. That is, this is money for services rendered, not money for doing nothing.

Anyways, good luck with Freicoin then.
legendary
Activity: 905
Merit: 1012
My immediate concern is that it undoes demurrage for participating actors, thereby eliminating the positive economic effects which come from universal demurrage, making me wonder what the purpose would be at all.

What you devised seems to be a mechanism for punishing people who don't participate in proof-of-stake. If that's your goal it's fine (although I don't agree with it), but the consequences are antithetical to what we're trying to do with demurrage and Freicoin specifically.

By the way, that's not to say that there aren't interesting consequences from integrating proof-of-stake with demurrage currency. As I've talked about on the Freicoin forums, it could lead to a sort of decentralized republican (small-r) parliamentary government:

http://www.freicoin.org/demurrage-should-it-all-go-to-miners-t20.html
legendary
Activity: 1050
Merit: 1003
Maybe I'm being thick-headed and just not getting it, but could you explain what problem(s) that solves? It's hard to have an opinion without some context.


PS: If anyone came to this resurrected thread based on the title, we've since gotten demurrage fully implemented and worked out the various best practices for handling accounting with a rotting money supply. Code is on github here. Discussion about Freicoin is happening on its forums and the #freicoin IRC channel (freenode).

What problem are you looking for?

One problem is double-spend attacks using 51% of hashing power. Impossible with the above system. Moreover threshold can be made arbitrarily strong. e.g. double spend attacks with 99.999% of hashing power can easily be made impossible.
legendary
Activity: 905
Merit: 1012
Maybe I'm being thick-headed and just not getting it, but could you explain what problem(s) that solves? It's hard to have an opinion without some context.


PS: If anyone came to this resurrected thread based on the title, we've since gotten demurrage fully implemented and worked out the various best practices for handling accounting with a rotting money supply. Code is on github here. Discussion about Freicoin is happening on its forums and the #freicoin IRC channel (freenode).
legendary
Activity: 1050
Merit: 1003
Jtmon, I had an idea for a demurrage-based reward system and would like to hear your thoughts.

The core principles are as follows:
a) Demurrage is charged as a mandatory txn fee based on coin-age (basically it is like your coins are constantly earning negative interest)
b) There is a mixed PoW and PoS system. Miners and stakeholders are paid via demurrage.
c) The money supply is constant (neglecting losses).
d) PoW cannot be used to mine secretly [either effectively or at all depending on implementation parameters]. This prevents double-spends which are based on secret mining.

There are other details, but the following is enough for now. The mining process is as follows:
1) Tentative PoW block is mined. Hash of work submission determines random lottery draw.
2) Random lottery draw determines stakeholder. Winning probability is proportional to stake holdings. [there are modifications of this to harden further against PoW attacks]
3) Tentative PoW block is broadcast. Winning stakeholder is invited to sign block.
Note: Rewards from come from demurrage charged on txns in block. They are divided between PoW miner and stakeholder. This can be a special txn in the block.
The stakeholders coins are refreshed in the process of signing a block. Meaning that his demurrage is reset to zero. This together with txn fee earnings provides the stakeholders participation incentive.
4) If block gets signed, then it enters the main chain upon signing. Otherwise block is orphaned and we return to step 1.
5) Once the block is signed, the chain can be extended via step 1.
6) There is also space after each block for an optional stake signature. This stake signature can be provided any time between when a block is mined and 6 blocks afterwards. This signature is not directly rewarded. However, these optional stake signatures serve as heartbeats. Keys that fail to provide heartbeats forfeit their right to participate in the lottery draw until they move their coins to a new public key. Such inactive keys cannot avoid demurrage penalties. Accordingly you want to provide a heartbeat if possible.

Notes:
a) If stakeholders leave their clients up and ready to sign blocks, they avoid demurrage charges and may earn some profit via txn-fees.
b) Mining a secret sequence of blocks is almost impossible. You would need to select yourself as the lottery winner. For example, if you have 1% of active mining coins then you have to provide 100 times as much work to generate a block as a public miner. This ratio can be increased arbitrarily via modification to step 2. Just ask for a sequence of random signatures instead of just 1. e.g. If you ask for 5 sigs, than the secret work requirement will be 10 billion times the public work requirement.
c) People who are not actively signing blocks face demurrage.
d) Security here is primarily provided by forcing miners to broadcast blocks. People who aren't present to sign are weakening security. Thus the rationale for charging them demurrage.
e) Since signers are given some fees, the incentive to provide signatures increases if other people are keeping their clients offline.
legendary
Activity: 1372
Merit: 1002
isent demurrage just making the value smaller?
then you could just continue giving a block reward of 50.

it *should* do it.

I think you're talking about timecoin (constant generation). Some people claim that expocoin (exponential monetary base growth) would have the same economics effects, but I think the effect on interest is different. Expocoin would rise nominal rates by adding an inflation premium but would keep real interest untouched. On the other hand, frecoin (constant monetary base through constant generation and demurrage) would lower real interest.

So I think I need to reduce the nominal value of "accounts" proportionally each block. This also puts lost wallets "back into circulation".
I just need to change the way balance for each address is interpreted like this:

amount - (demurrage_rate ^ (current_block_number - tx_block_number))
legendary
Activity: 1050
Merit: 1000
You are WRONG!
Hi, I've been reading the bitcoin code lately looking for the functions to modify to implement demurrage.
With demurrage, when the client wants to know the balance of an address, it has to take into account how many blocks ago.
The only change that is needed is there, how to interpret the balance of accounts.
I think I only have to change three methods for that:

CWalletTx::GetAvailableCredit()
CWalletTx::GetAccountAmounts(strAccount, nGenerated, nReceived, nSent, nFee);
CWalletTx::GetAmounts(allGeneratedImmature, allGeneratedMature, listReceived, listSent, allFee, strSentAccount);

Am I right?

isent demurrage just making the value smaller?
then you could just continue giving a block reward of 50.

it *should* do it.
legendary
Activity: 1372
Merit: 1002
Hi, I've been reading the bitcoin code lately looking for the functions that have to be modified to implement demurrage.
With demurrage, when the client wants to know the balance of an address, it has to take into account how many blocks ago was each transaction made.
The only change that is needed is there, how to interpret the balance of accounts.
I think I only have to change three methods for that:

CWalletTx::GetAvailableCredit()
CWalletTx::GetAccountAmounts(strAccount, nGenerated, nReceived, nSent, nFee);
CWalletTx::GetAmounts(allGeneratedImmature, allGeneratedMature, listReceived, listSent, allFee, strSentAccount);

Am I right?

EDIT: new forum at http://www.freicoin.org/
Jump to: