Demurrage, transaction fees, storage fees & comparison to commodity money.

[MoonShadow]

Can someone define "hoarding" in a way that is incompatible with "saving"? In my opinion, the two are one in the same. Hoarding is just what one person calls another's saving "too much".

Doesn't a demurrage charge upon spending actually discourage the consolidation of multiple outputs into a single one?

No, because demurrage would have to scale depending upon the number of existing transactions.  It's the avoidance of demurrage, with the inclusion of a 'grace' period, that encourages major savers to consolidate their holdings.

[1714112284]

1714112284

[1714112284]

1714112284

[goatpig]

Because as the network grows, the resources required to store those many old transactions grow at least as much.  New clients must download and verify each of those transactions for as long as they persist.  A single transaction with 400,000 BTC costs exactly the same amount to store as the same transaction with 50 BTC; but one person with holdings totaling 400,000 BTC spread across 8000 transactions imposes 8000 times as much burden of resources upon the network.  The idea is to encourage that person to consolidate his holdings into fewer transactions, without forcing him to do so, as he can still choose to leave them where they are if he is okay with 8000 times as much storage fees as is necessary.  It also has the effect of partially compensating the miners for the resources that those many transactions consume; not just 8000 times as much disk space, but 8000 times as much bandwidth for every new client that connects to that node to download the existing blockchain.  Currently, it still doesn't matter; because the miners are more than compensated for these things with the block reward and blockchain pruning is not yet implemented anyway.  I'm just thinking ahead.

You say you want to prune the chain? How would you deal with lost coins then? Do you intent to simply replicate old transactions in newer blocks? Wouldn't that hinder the demurrage fee calculation? The light weight client will eventually see the day so I don't think the whole block chain download will remain a problem in the mid term. The only reason a person with 50 BTC imposes less on the network than someone with 400k BTC is the flat fee. Reflecting volume on the fee would help against that in a better fashion imo.

From my understanding, spread out long term holdings will still have a small impact compared to live, broken down transactions constantly creating new coins to pay for odds amounts. I agree that "traders" are already paying for that service, but so have hoarders. Technologically, the spot these people have "purchased" in the block chain doesn't require further maintenance. The idea of demurrage has been brought up as an alternative to lacking fees, but I think the very concept of "simulated maintenance fee " vs actual maintenance costs needs a thread on its own before we can really figure out where to go with demurrage.

At any rate, we can't establish now that fees won't be reward enough to maintain adequate security in a few decades from today. Miners already have control over transaction inclusion, I think it is wiser to first wait for a tangible hint of whether or not the market can maintain high security naturally before we talk of modding the source.

[caveden]

Considering the proposition of demurrage itself, I don't like it very much, for the following reasons:

• All it does it does is that it forces people to move money around, so that transaction fees are collected and the chain is pruned. If the transaction fees remain near a satoshi, that doesn't add much to miners. It would be better to make sure transaction fees won't go that low.
• It introduces a completely new and big feature/constraint to a system that doesn't necessarily need it. (transaction fees and maximum block size are already there)
• I can't see a way to make it automatically adjustable or "market-adaptive"... and hard-coded, arbitrary rules are not good.
  

I still prefer an adaptive maximum limit to the block size, that creates some artificial block space scarcity on peak hours of the day or peak days of the week/month/year. It is not a major new feature, and although the formula to be defined is arbitrary, there are no arbitrary constant values. And it may guarantee a minimum incentive to miners.

[caveden]

Concerning the whole chain size, I don't think that will be a major problem, compared to the bandwidth required.

And if it ever becomes annoying for some miners, they can try offering bounties to the owners of the oldest coins to move them to a new address. It can be done without the owner of the coins having to identify himself.

There is one major barrier though: some private keys are lost. These coins won't ever be moved again, and there isn't anyway to verify that the coins are really lost or someone is just lying about it. Considering that people probably lost private keys from the early days of bitcoin, when the coins were mostly worthless, I'd say there isn't much room for pruning the chain.

[MoonShadow]

Because as the network grows, the resources required to store those many old transactions grow at least as much.  New clients must download and verify each of those transactions for as long as they persist.  A single transaction with 400,000 BTC costs exactly the same amount to store as the same transaction with 50 BTC; but one person with holdings totaling 400,000 BTC spread across 8000 transactions imposes 8000 times as much burden of resources upon the network.  The idea is to encourage that person to consolidate his holdings into fewer transactions, without forcing him to do so, as he can still choose to leave them where they are if he is okay with 8000 times as much storage fees as is necessary.  It also has the effect of partially compensating the miners for the resources that those many transactions consume; not just 8000 times as much disk space, but 8000 times as much bandwidth for every new client that connects to that node to download the existing blockchain.  Currently, it still doesn't matter; because the miners are more than compensated for these things with the block reward and blockchain pruning is not yet implemented anyway.  I'm just thinking ahead.

You say you want to prune the chain? How would you deal with lost coins then? Do you intent to simply replicate old transactions in newer blocks? Wouldn't that hinder the demurrage fee calculation? The light weight client will eventually see the day so I don't think the whole block chain download will remain a problem in the mid term. The only reason a person with 50 BTC imposes less on the network than someone with 400k BTC is the flat fee. Reflecting volume on the fee would help against that in a better fashion imo.

I don't know how to deal with lost coins, or even if it's possible.

From my understanding, spread out long term holdings will still have a small impact compared to live, broken down transactions constantly creating new coins to pay for odds amounts. I agree that "traders" are already paying for that service, but so have hoarders. Technologically, the spot these people have "purchased" in the block chain doesn't require further maintenance.

Yes, it does.  That's my point.  It may not require much, but it does require some resources.

The idea of demurrage has been brought up as an alternative to lacking fees, but I think the very concept of "simulated maintenance fee " vs actual maintenance costs needs a thread on its own before we can really figure out where to go with demurrage.

That's why I started this thread, to have that conversation.

At any rate, we can't establish now that fees won't be reward enough to maintain adequate security in a few decades from today. Miners already have control over transaction inclusion, I think it is wiser to first wait for a tangible hint of whether or not the market can maintain high security naturally before we talk of modding the source.

Miners don't have as much control as you think.  There is a market that they have to respond to, so there needs to be published expectations.  This is not an unpredictable issue, it's a very definable economic issue.

[MoonShadow]

Considering the proposition of demurrage itself, I don't like it very much, for the following reasons:

• All it does it does is that it forces people to move money around, so that transaction fees are collected and the chain is pruned. If the transaction fees remain near a satoshi, that doesn't add much to miners. It would be better to make sure transaction fees won't go that low.

This is how we can keep it from "going that low"

• It introduces a completely new and big feature/constraint to a system that doesn't necessarily need it. (transaction fees and maximum block size are already there)

It necessarily needs it, in some form or fashion.  And the max block size is going to go away.  Too many people are opposed to the artificial scarcity that it imposes, and want to remove it and let it become a true free market.

• I can't see a way to make it automatically adjustable or "market-adaptive"... and hard-coded, arbitrary rules are not good.
  

I still prefer an adaptive maximum limit to the block size, that creates some artificial block space scarcity on peak hours of the day or peak days of the week/month/year. It is not a major new feature, and although the formula to be defined is arbitrary, there are no arbitrary constant values. And it may guarantee a minimum incentive to miners.

An adaptive max block size is fine for it's own reasons, if a system can be agreed upon, and that really would have to be code enforced.  But that would not solve the problem.  There is little evidence that such compensation will be appropriate to overcome the 'free storage' problem, and much economic theory that suggests that over the long term free storage of old transactions will distort the market.

[da2ce7]

This whole thread is based upon a false premise: there is a global storage cost for old transactions.  This is untrue.

The miners only need to keep the root hash of every block to verify transactions.  However the owner of the old coins needs to keep an complete copy of the old block.

To spend the old coins. The owner announces both the transaction, and provides the old coin's block for upload.  The miners (who wish to) will see this transaction an 're-download' the old block. (and compare the root Merkle hashes)

The miner only need to keep the more recent blocks, old blocks can be downloaded when needed.  Only some of the miners will bother to download the old block, others will just focus on bitcoins in recent blocks.

This extra work of checking old blocks can adequately and naturally attract higher transaction fees. (but not demurrage, as there was no 'storage costs')

The whole concept of demurrage doesn't isn't economically logical.  Just like always issuing new coins always isn't economically logical.  The COST involved isn't to secure old coins - but to secure NEW TRANSACTIONS.  When all the Bitcoin's are mined, securing transactions moves to a user-pays model.  (as it should be, the user pays for the cost)

There is no cost in 'not using' Bitcoin.

[smooth]

This whole thread is based upon a false premise: there is a global storage cost for old transactions.  This is untrue.

The cost is requiring that the block chain continue to grow to stay ahead of attackers.  Otherwise eventually an attacker can reverse the entire chain, including the old transactions.

[MoonShadow]

This whole thread is based upon a false premise: there is a global storage cost for old transactions.  This is untrue.

It's provably true that there is a cost to maintaining old transactions, however small that it is.

The miners only need to keep the root hash of every block to verify transactions.  However the owner of the old coins needs to keep an complete copy of the old block.

To spend the old coins. The owner announces both the transaction, and provides the old coin's block for upload.  The miners (who wish to) will see this transaction an 're-download' the old block. (and compare the root Merkle hashes)

If this were universally true, where would the miners download the old blocks from?  The miners is where those blocks are most likely to be kept.

Only some of the miners will bother to download the old block, others will just focus on bitcoins in recent blocks.

I see this as an unintended consequence of the network providing for free storage indefinitely, and I don't agree that it would be a workable solution, or even generally a positive consequence.

This extra work of checking old blocks can adequately and naturally attract higher transaction fees. (but not demurrage, as there was no 'storage costs')

Once again, there is a provable degree of storage costs suffered by the network.  If you don't believe that is true, then just consider what you think would happen if transactions stopped.

The whole concept of demurrage doesn't isn't economically logical.  Just like always issuing new coins always isn't economically logical.  The COST involved isn't to secure old coins - but to secure NEW TRANSACTIONS.  When all the Bitcoin's are mined, securing transactions moves to a user-pays model.  (as it should be, the user pays for the cost)

There is no cost in 'not using' Bitcoin.

Old transactions are indeed 'using' Bitcoin.  The only way to not be using bitcoin is to sell out all that you have so that someone else is using what you once had.  If you have a positive balance in bitcoin, you're using the system by defintion.

[jtimon]

I've changed your proposal to this:

1) Miners would receive the demurrage fees relative to their hashing contributions, like the block reward is now.

2) Demurrage fees should be very small, but should be assessed with each block.

3) The block reward by demurrage would be proportional to the number of "out of date" (and not empty) addresses.
  
4) Only transactions older than, say 6 months, should be affected by demurrage fees.

5) The demurrage would be discounted from the payer's address when he makes a transaction (but it is effectively charged when the miner receives it).

This, by the way, also solves "the problem of the lost wallets" since lost wallets will eventually be completely spent on demurrage fees. Actually I didn't though it was a technical problem until now. I wasn't very concern with the economic impact of lost wallets neither.

Again, I think a demurrage fee that depends on the money quantity too and not only on time would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders.
Lending would still be more interesting than storing while the liquidity premium were positive, or even zero because most goods aren't as time resistant as a safe loan.
More investing (another way of saving) would be more interesting than today in this "saving market" and in general.
Note that you can invest with borrowed money so investing is not always saving.    
But the reason why malinvestments are done before crises is because of an "unexpected" increase in the monetary supply (note that this had happened with gold being money too), not because need to charge the liquidity premium in order to lend wisely.
My proposal would remove the point 4 and change the 5:

5) The block reward by demurrage would be constant. To accomplish this, the reward would be equal to the demurrage percentage charged on each account but applied to the total targeted supply.

If you want a reasonable demurrage rate with this proposal you need to change either the 21 M or the 50 btc. I think the issuing curve would be different too, so it cannot be applied to bitcoin.
I think we should focus on the proposal for bitcoin and discuss the supposedly evil financial effects of demurrage and freicoin in another thread.

Another thing that creighto's proposal accomplish is preventing other applications from "burning bitcoins" to have storage forever (like a dns address in the destination field).
The applications that introduce information for free (or for fee) but without burning bitcoins could still be used with this proposal, but when a block dosn't contain active transactions it doesn't have to be stored and sent (right?). So the service bitcoin provides can be timestamping, but not storage if we apply demurrage.
You just need to burn bitcoins to get "everlasting storage" right now.

[BitterTea]

Again, I think a demurrage fee that depends on the money quantity too and not only on time would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders.

Unless you can define "hoarding" in a way that does not also include "saving", please stop using this bullshit term.

[jtimon]

Again, I think a demurrage fee that depends on the money quantity too and not only on time would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders.

Unless you can define "hoarding" in a way that does not also include "saving", please stop using this bullshit term.

"Hoarding" is just shorter than "holding money". I still don't know what you don't like about my definition of hoarding: is a way to save. But it doesn't mean that I should always use save instead of hoard, because sometimes I mean save in a more general way, not necessarily hoarding, without specifying the way to save.

I think we should focus on the proposal for bitcoin and discuss the supposedly evil financial effects of demurrage and freicoin in another thread.

[BitterTea]

"Hoarding" is just shorter than "holding money". I still don't know what you don't like about my definition of hoarding: is a way to save. But it doesn't mean that I should always use save instead of hoard, because sometimes I mean save in a more general way, not necessarily hoarding, without specifying the way to save.

Ok, so we agree that hoarding and saving are exactly the same thing? Then why use the word hoarding, which has a distinctly negative connotation?

This is specifically the part of your post with which I take issue:

would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders

You imply that hoarders are a subset of savers, and that it is less detrimental to punish them compared to the savers. I don't understand this view at all.

I think we should focus on the proposal for bitcoin and discuss the supposedly evil financial effects of demurrage and and freicoin in another thread.

I'm merely taking issue with your biased terminology, which seems to be at the core of your argument for the use of demurrage in the first place.

[MoonShadow]

I've changed your proposal to this:

5) The demurrage would be discounted from the payer's address when he makes a transaction (but it is effectively charged when the miner receives it).

This, by the way, also solves "the problem of the lost wallets" since lost wallets will eventually be completely spent on demurrage fees. Actually I didn't though it was a technical problem until now. I wasn't very concern with the economic impact of lost wallets neither.

How do you propose to do this?  My understanding of the system doesn't allow for discounting of transactions (or accounts, if you prefer) without significant changes to the technical aspects.

Again, I think a demurrage fee that depends on the money quantity too and not only on time would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders.

This would likely introduce other perverse incentives than what I was trying to prevent, and I would have to oppose that on principle and on economic grounds.  Any demurrage system must scale relative to the real costs to the network scale, and that means per transaction and not per transaction value setting.

Lending would still be more interesting than storing while the liquidity premium were positive, or even zero because most goods aren't as time resistant as a safe loan.
More investing (another way of saving) would be more interesting than today in this "saving market" and in general.
Note that you can invest with borrowed money so investing is not always saving.  

This is neither economicly sound, nor relevant to Bitcoin.  It's not remotely relevant to the problem I'm trying to avoid.

 
But the reason why malinvestments are done before crises is because of an "unexpected" increase in the monetary supply (note that this had happened with gold being money too), not because need to charge the liquidity premium in order to lend wisely.
My proposal would remove the point 4 and change the 5:

5) The block reward by demurrage would be constant. To accomplish this, the reward would be equal to the demurrage percentage charged on each account but applied to the total targeted supply.

I don't even think that this is possible.

If you want a reasonable demurrage rate with this proposal you need to change either the 21 M or the 50 btc. I think the issuing curve would be different too, so it cannot be applied to bitcoin.
I think we should focus on the proposal for bitcoin and discuss the supposedly evil financial effects of demurrage and freicoin in another thread.

No.  Absolutely not.  I would much prefer to leave the potential problem unaddressed than proceed in this manner.

[Vandroiy]

I'd like this demurrage on very stale coins, as in lost coins. If you don't move coins for 8 years, they start disappearing slowly.

It is totally reasonable for BTC holders to refresh once in 8 years. This gives a small fee to miners, and with what I learned about nodes not accepting blocks that split the block chain too far back... with little change to the protocol, we might not need many miners to keep things going.

I find the idea of having exactly 21M coins much nicer than the risk of "suddenly, surprise market crash caused by ancient million bitcoin deposit". Also, you can pretty much rely on coins getting lost somewhere, so this will always secure a minimum amount of mining.

Nice part: nobody complains, since everybody can prevent demurrage by just doing a single transfer to himself every 8 years. The client could remind people, too.

[MoonShadow]

I think that it's totally reasonable for users to refresh once a year.

[MoonShadow]

I'm still waiting for any of the developers to chime in and tell me how demurrage could be done, or if it's even possible, beyond the early idea of an alternate minimum fee upon eventual transfer.  I still can't grasp how lost coins could even  be 'rotted'.

[jtimon]

Ok, so we agree that hoarding and saving are exactly the same thing? Then why use the word hoarding, which has a distinctly negative connotation?

Is there a single word that means "money holder"/hoarder without negative connotations (that I don't need) and other than "saver"?

would be financially beneficial for the money users and won't punish all the savers. Just hoarders and lenders

You imply that hoarders are a subset of savers, and that it is less detrimental to punish them compared to the savers. I don't understand this view at all.

With demurrage some savings would move from "money holding" to lending, storage of goods or direct investment
Some savings could also move from lending to direct investment. Before direct investment becomes "too risky", savers would prefer storing to lend.
Some of the investments are not done not because they're not economically feasible due to a lack of real resources, but because the saver can demand the liquidity premium or just hold their money at zero cost for them.
This forces all investments to be at least as profitable as the liquidity premium.
The risk premium is an "insurance" from the lender to the borrower, that's why it gets smaller with collateral.
If the capital was only the investments, nothing would prevent the yields of capital to tend to zero as the different investments compete between them for profits. But while the capital is investments plus money, there's an artificial (yes, money being time resistant is an agreement between the money users) low limit for the capital yields. When investments yields are below the liquidity premium (instead of when they're below zero), the capital price of the investments is recalculated and investment "stops" until the cost of production of the real capital at least match (through comparison with the yield of money on liquidity premium) the rent that can be earned in the market with that real capital.
While lenders and other capital owners take the extra profit from the liquidity premium, the more saving is made by holding instead of lending, the more investments won't be done to "compete with the rest of the capital for profits".
The money holders don't benefit from all this, nor they are the ones to blame for anything. We should not blame no one for this. It's just the result of the agreement of letting money be time resistant. The players just follow the rules of the game. But as we can create new moneys we can change those rules. If people find more interesting that money is not everlasting, they can agree with each other in trading with that money. Actually there's people doing it right now.
I think is not a semantic issue, but an economic one.
Since I'm pretty sure no one is going to agree on the financial gains of demurrage, I think we should move to another thread. For example this one:

http://forum.bitcoin.org/index.php?topic=6549.0

I would like to know any flaws on my reasoning, but I don't want to keep on discussing it here because it goes beyond the topic of the thread.

[jtimon]

I've changed your proposal to this:

5) The demurrage would be discounted from the payer's address when he makes a transaction (but it is effectively charged when the miner receives it).

This, by the way, also solves "the problem of the lost wallets" since lost wallets will eventually be completely spent on demurrage fees. Actually I didn't though it was a technical problem until now. I wasn't very concern with the economic impact of lost wallets neither.

How do you propose to do this?  My understanding of the system doesn't allow for discounting of transactions (or accounts, if you prefer) without significant changes to the technical aspects.

The creation of bitcoins to pay the miners would be as simple as the creation of the current reward and equal to:

flat_demurrage_fee * number of old transactions

All nodes would have to know that it is allowed to "create" bitcoins this way accept those blocks.

The later destruction of the already payed fees could be implemented through a third field (apart from payment and transaction fee) for registering the amount "destroyed" in the transaction. That field isn't even necessary since the content of that field can be calculated like this:

 ((previous_tx_block_num + expiration_time) - current_tx_block_num) * flat_demurrage_fee

All nodes would have to know that the "old" accounts contain less money than they say to reject transactions from accounts with not enough funds.
The lost wallets are just ignored like empty accounts when they've spent all they content in demurrage fees.

My proposal would remove the point 4 and change the 5:

5) The block reward by demurrage would be constant. To accomplish this, the reward would be equal to the demurrage percentage charged on each account but applied to the total targeted supply.

I don't even think that this is possible.

The "creation" is constant and not related to the number of old transactions

For the "destruction":

 (previous_tx_block_num - current_tx_block_num) * demurrage_rate * amount_in_account

[MoonShadow]

I suppose that would work, if we were starting over or starting a new fork of code, but this problem doesn't justify a breaking change.