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

[Frozenlock]

Ultimately you are paying for the security of the present transaction.

Even if a million BTC were to sleep in an account for a hundred years, it is only when they are spent that the security is important (and paid for).

If I keep 10 BTC for 10 years, but one day before I spend them the blockchain is tempered with (in a way as to render the network worthless), I don't see why I should have paid the miners all this time.

I repeat: the security is only useful when you use your BTC. I would even add that the current transaction need the transaction history to validate itself.
Everything in-between transactions is irrelevant. 

Please don't destroy a key characteristic of Bitcoin (and ANY money); for now it is durable - as durable as the network. Doing so would undermine the entire project.

[1713483081]

1713483081

[1713483081]

1713483081

[1713483081]

1713483081

[1713483081]

1713483081

[da2ce7]

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.

This is not correct.  The cost is nothing more than what would need to be kept anyway even with culling. Please see: Merkle hash trees

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.

The person who owns the old coins needs to maintain a archive of the blocks that contain those coins... Again moving to a 'user-pay' system.  When the owner of the old coins wants to spend the coins that owner must provide a copy of the full old block.

The owner makes a transaction and provides the old block for download.  (if the miners who offer this service don't already choose to keep the old blocks)

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.

There is no global cost, (aka a user-pays system), then there is no 'unintended consequence' - the few miners who wants to secure old blocks (by downloading old blocks or keeping a archive), can charge a premium for the service.  This is why it is a 'transaction fee' for 'processing the transaction.'  If it requites more work to process old transaction, then those transactions will attract higher fees.  (again a user-pays system).

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.

Again, yes there is, See: Merkle hash trees: negligible cost for verifying old blocks without long-term storage.  (other than the owner of the coins providing the block for upload)

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.

This, again, is incorrect.  Nobody is compelling any miner to process old transaction... The miners can choose to reject old transactions for whatever reason they want.  Including their age.

[BitterTea]

Ultimately you are paying for the security of the present transaction.

Actually, this made something click for me.

Isn't it he recipient, not the sender, the one to gain the most from the protection of the block chain? Past six confirmations (or however many before the recipient provides the good or service), the sender couldn't care whether or not the transaction is reversed.

Is there some way to take this into account without breaking Bitcoin?

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

This is not correct.  The cost is nothing more than what would need to be kept anyway even with culling. Please see: Merkle hash trees

Yes.  You should read that link you posted.  Again, an unspent transaction does impose an ongoing resource cost upon the greater, collective network, however small that cost may be.  It's right there.  The merkle hash tree is intended to permit the block to be pruned of spent transactions but unspent transactions cannot be pruned.  Hence the cost.  I'm beginning to get annoyed.  I started this thread to have an educated conversation with intelligent peers, and I find myself spending too much time pointing out the basic errors of understanding of others instead.

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.

The person who owns the old coins needs to maintain a archive of the blocks that contain those coins... Again moving to a 'user-pay' system.  When the owner of the old coins wants to spend the coins that owner must provide a copy of the full old block.

If the (only|most available) copy of an old block is the one that the spender has, this introduces an attack vector not present in Bitcoin now.  The obvious one that I can think of is that Bitcoin depends on the independently verifiable blocks that are provided by multiple sources not connected to the parties involved in the trade, or at least enough sources that it's extremely unlikely that all those peers are connected to either party in the trade.  If the only copy available to the miner of the input block is the one provided by the sender himself, a spoofed block is then possible.  How hard do you think it would be to fake a block and transaction set that could hash to match the merkle root of one block too old for miners to keep?  It might take a malicious node a few days to find the right combo of extra-nonce and false transactions to match the merkle root, but time is of little concern in such an attack.

Spending coins in this way is the only way to have a decent risk assessment while using two lightweight clients while offline, but this can never be the norm.

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.

There is no global cost, (aka a user-pays system), then there is no 'unintended consequence'

Your core premise is false.  Easily proven as such, and you even use some of that evidence to support your false premise.  I find that amazing.

[da2ce7]

The merkle hash tree is intended to permit the block to be pruned of spent transactions but unspent transactions cannot be pruned.  Hence the cost.  I'm beginning to get annoyed.  I started this thread to have an educated conversation with intelligent peers, and I find myself spending too much time pointing out the basic errors of understanding of others instead.

You can safely prune both spent and unspent transactions, in fact you can prune entire blocks with spent transactions (for everyone except those those who own the coins in the given old blocks).

• Each miner keeps a list the root hashes of all the previous block, from the genesis block. (e.g. 256bit per block)
• A hash of all the past hashes is included in every block. (a slight modification to the block chain, but trivial) e.g. a Merkle hash tree root
• When an old transaction is announced, the miner downloads the block that contains these old coins.
• The miner compares the hash of the block downloaded to the known good hash of the block
• The miner then can check if the transaction is valid or not.
• When a block is announced with containing a very old block, the network will re-download that block and check if the transaction is correct
• (most) of the network forgets the old block once the new block is verified

See with one small change to the block-chain, (to contain a 2nd root of the hashes of all the past blocks), you can have secure on-demand downloading of old blocks.

So I believe your premise is incorrect.

[amincd]

Even if we somehow collectively solve this problem, there is another one. Contrary to what Satoshi wrote at the beginning, Bitcoin is a quite expensive system to maintain. At the current difficulty and BTC price, miners are paid 25-30 million USD a year (by block inflation) to protect 40-45 million USD Bitcoin market value. The current BTC price/difficulty may be abnormally high but the electricity alone costs a cool 1-1.5 million USD a year and equipment depreciation is 2-3 times of that and it will rise when BTC price/difficulty drops. And Bitcoin is barely safe to an attack because Bictoin need to maintain this capacity constantly and attackers can just use short bursts. I'm not sure that the mainstream banking costs for transaction system and money supply are so high percentwise for the same amount of money supply and trading that Bitcoin offers. The bailouts (which were indeed expensive) went for fixing the lending hole which Bitcoin is not doing.

It's not only the market value of the bitcoins that is being protected, it's the integrity of the transaction record, and therefore market value of the transactions that occurred that year.

Today for example, 7.4% of bitcoins were transferred. That means $3.3 million worth of BTC. In one year, assuming similar ratios as today (which I've looked through the data and it doesn't seem atypical), that comes to $1.215 billion worth of transactions. Keep in mind a lot these are international transfers which are typically much more costly in classical banking. The amount paid to miners comes to 2% of that, which replaces the cost of all the security that classic banks have to spend on when transferring money, and all of the other transaction costs as well.

Also, a successful >50% attack would not lead to a complete security breach where all bitcoins can be stolen. It would only open the possibility of double spends by an attacker, so the value of such an attack does not equal the market value of bitcoins. This suggests the risks of lower difficulty/market-cap could be low.

Furthermore, operating profit margins right now are quite high for miners. It will decrease significantly once bitcoin inflation slows and the market stabilizes, approaching close to the cost of electricity, which I've seen that you've noted at the moment is $0.75 million a year. This is only about 0.06% of the market value of transactions. There will need to be some profit, so even if we triple that, to 0.2%, that's still very low cost.

[BitterTea]

• When an old transaction is announced, the miner downloads the block that contains these old coins.

From whom? The assumption has been that miners will be the ones storing the full blocks.

Perhaps it is feasible for a division of labor, where block chain storage could be a separate business?

[da2ce7]

• When an old transaction is announced, the miner downloads the block that contains these old coins.

From whom? The assumption has been that miners will be the ones storing the full blocks.

Perhaps it is feasible for a division of labor, where block chain storage could be a separate business?

Well either the owner of the old transactions keeps the old blocks himself, or he pays another company to keep the old block for him.
The owner of the old coins understands that his old coins will be un-spendable if the old blocks are completely forgotten.

This is a user-pays system.  That is a good thing.

[Raulo]

Today for example, 7.4% of bitcoins were transferred. That means $3.3 million worth of BTC. In one year, assuming similar ratios as today (which I've looked through the data and it doesn't seem atypical), that comes to $1.215 billion worth of transactions. Keep in mind a lot these are international transfers which are typically much more costly in classical banking. The amount paid to miners comes to 2% of that, which replaces the cost of all the security that classic banks have to spend on when transferring money, and all of the other transaction costs as well.

Two points. The amount displayed in, e.g., bitcoinwatch is completely bogus. A transaction contains a change. If you transfer $10 to a third party from an account that has $100000, the banking system transfers $10, not $10 + $99990, while Bitcoin does the latter. Wouldn't you be rather pissed off if Paypal charged you 2.9% on $100000 when you moved $10? So the percentage of the cost in Bitcoin is way higher than what you calculated. Secondly, there are so many transactions because they are mostly free. When the fees become a norm, the transaction volume will slow down.

Also, a successful >50% attack would not lead to a complete security breach where all bitcoins can be stolen. It would only open the possibility of double spends by an attacker, so the value of such an attack does not equal the market value of bitcoins. This suggests the risks of lower difficulty/market-cap could be low.

I know that but a lot of people here downplay the consequences of the >50% attack. It is true that there is rather little to gain for the attacker compared to being honest. Therefore, I think we may never see a ">50% attack for profit". But for attackers that only want to make damage (for example a competition to Bitcoin), it can really make havoc. It's the mother of all DoS attacks. A >50% attacker can:

1. Completely halt all confirmations.
2. Reverse all transactions (so halt retroactively) and put them on hold.
3. Annihilate recently mined coins and all transactions where the coins were used (if the chain fork is longer than 120 blocks).
4. Double spend his coins.

And the point that is frequently missed:

5. Allow anybody to double spend. When the chain is forked, all transactions go into a memory pool of the miners. The attacker can be "nice" enough to remove them from his memory pool and allow anybody to connect, submit a new double spend transaction and confirm it. It can allow some non-fraudulent transaction and you will not know what is right and what is wrong.

If you think that it won't crash the BTC value, you are very optimistic. It would create such a mess that it will be very hard to untangle.  And do it a few times and nobody will trust the Bitcoin blockchain for anything larger that a few dollar transactions and Bitcoin returns to its amateur status.

Furthermore, operating profit margins right now are quite high for miners. It will decrease significantly once bitcoin inflation slows and the market stabilizes, approaching close to the cost of electricity, which I've seen that you've noted at the moment is $0.75 million a year. This is only about 0.06% of the market value of transactions. There will need to be some profit, so even if we triple that, to 0.2%, that's still very low cost.

As I wrote above, the value of transactions is bogus. The only think non-bogus is the total BTC value (money supply). Relatively to money supply, Bitcoin is expensive.

[jtimon]

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.

I don't think is a breaking change.
For the miners to receive the fees, they should just agree that these fees are legit: just as hard as changing the block reward.
For the holders to pay the fees, the miners should just reject transactions from accounts that are not enough funded (due to demurrage fees payments): just as hard as requiring a minimum fee for accepting transactions or removing the maximum block size.

[jtimon]

• When an old transaction is announced, the miner downloads the block that contains these old coins.

From whom? The assumption has been that miners will be the ones storing the full blocks.

Perhaps it is feasible for a division of labor, where block chain storage could be a separate business?

Well either the owner of the old transactions keeps the old blocks himself, or he pays another company to keep the old block for him.
The owner of the old coins understands that his old coins will be un-spendable if the old blocks are completely forgotten.

This is a user-pays system.  That is a good thing.

If miners prune not empty accounts, when a payment from that account is made, they would:

A) Ask for the missing blocks and verify they are correct.
B) Simply reject those transactions.

The miners have an incentive to just ignore old accounts to save storing (or computing power and bandwidth) so this whole thing is a more dangerous situation than I first thought.

[amincd]

Two points. The amount displayed in, e.g., bitcoinwatch is completely bogus. A transaction contains a change. If you transfer $10 to a third party from an account that has $100000, the banking system transfers $10, not $10 + $99990, while Bitcoin does the latter.

I didn't know that. I wonder how much of the transaction volume is change. This definitely changes the ratio, but it's difficult to know to what.

Secondly, there are so many transactions because they are mostly free. When the fees become a norm, the transaction volume will slow down.

I agree with this.

Quote
Also, a successful >50% attack would not lead to a complete security breach where all bitcoins can be stolen. It would only open the possibility of double spends by an attacker, so the value of such an attack does not equal the market value of bitcoins. This suggests the risks of lower difficulty/market-cap could be low.


I know that but a lot of people here downplay the consequences of the >50% attack. It is true that there is rather little to gain for the attacker compared to being honest. Therefore, I think we may never see a ">50% attack for profit". But for attackers that only want to make damage (for example a competition to Bitcoin), it can really make havoc. It's the mother of all DoS attacks. A >50% attacker can:

1. Completely halt all confirmations.
2. Reverse all transactions (so halt retroactively) and put them on hold.
3. Annihilate recently mined coins and all transactions where the coins were used (if the chain fork is longer than 120 blocks).
4. Double spend his coins.

And the point that is frequently missed:

5. Allow anybody to double spend. When the chain is forked, all transactions go into a memory pool of the miners. The attacker can be "nice" enough to remove them from his memory pool and allow anybody to connect, submit a new double spend transaction and confirm it. It can allow some non-fraudulent transaction and you will not know what is right and what is wrong.

Yes, the attacker can disrupt transactions, but cannot steal other people's bitcoins, so the monetary gain from such an attack is relatively small. As for an attack for competitive reasons, there is good reason to assume this would also not be perceived as being profitable by a potential attacker, because a disruption to bitcoin would benefit all competing currencies, not just the attacker's, so the attacker would be paying a large expense, to help not just himself, but his competitors as well, thus minimizing the benefit to himself.

As I wrote above, the value of transactions is bogus. The only think non-bogus is the total BTC value (money supply). Relatively to money supply, Bitcoin is expensive.

I agree that given I assumed the transaction volume reflected transfers between parties, my calculations are not applicable.

I'll add though that the difficulty does not need to scale with total BTC value. There will come a point where an attack will simply not be feasible by any party due to the level of difficulty, and after that point difficulty does not need to increase much with further increases in market capitalization.

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

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

No, not really. If you have "infinite" block space, it doesn't matter that you're forcing people to move around their coins once in a while, the transaction fees to do so will probably be only 0,01µBTC each transaction. They would remain "that low".

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. 

Why not? With limited space, transactions would compete for it, and the only way to do so is by offering higher fees.

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.

I'm not sure that's such an issue... comparing with bandwidth and processing power efficiency, storage space will probably not be such a problem.

[caveden]

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

That's a better idea. People implementing light-weight clients should take that in consideration, and store at least the blocks from which they have money on their wallets. People providing offline bitcoins like bitbill should also either encode the entire block on the bill, or at least allow the block to be downloaded from a server of them.

[caveden]

If the (only|most available) copy of an old block is the one that the spender has, this introduces an attack vector not present in Bitcoin now.  The obvious one that I can think of is that Bitcoin depends on the independently verifiable blocks that are provided by multiple sources not connected to the parties involved in the trade, or at least enough sources that it's extremely unlikely that all those peers are connected to either party in the trade.  If the only copy available to the miner of the input block is the one provided by the sender himself, a spoofed block is then possible.  How hard do you think it would be to fake a block and transaction set that could hash to match the merkle root of one block too old for miners to keep?  It might take a malicious node a few days to find the right combo of extra-nonce and false transactions to match the merkle root, but time is of little concern in such an attack.

Is this really feasible? One thing is to produce a hash that has a certain number of zeros in its beginning, another thing is to produce an exact hash from something else. To me it sounds as likely as brute forcing against cryptography, but well, I don't really understand all these cryptography stuff so I'm asking....

[Gavin Andresen]

If processing old transactions becomes expensive, then miners will start charging transaction fees to include them in their blocks.

Speculating about exactly HOW the miners will charge (will they subscribe to an 'old transaction service' or somehow contact the old-transaction-spender for the merkle branch of the old transaction?) is a waste of time, in my humble opinion.

[da2ce7]

If processing old transactions becomes expensive, then miners will start charging transaction fees to include them in their blocks.

Speculating about exactly HOW the miners will charge (will they subscribe to an 'old transaction service' or somehow contact the old-transaction-spender for the merkle branch of the old transaction?) is a waste of time, in my humble opinion.

Gavin, what do you think about including a second root-hash in the block hash tree.  This hash is the merkle root of a tree containing the root hashes every block before it?

This will be a useful feature for thin clients; once the clients have downloaded all the root hashes of the previous blocks, any new block can be used to check if the downloaded root hashes are correct.

This will enable secure arbitrary block download.

It is a miner modification to a block... I don't see it containing a large overhead,  it involves a extra sha256 of 3.2 MB / 100,000 blocks. It adds ~256bit to the block size.  I think that it's benefits out weigh the costs.

[Andris]

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.

Main concern about this would be giving it all to the person who found such a block. If at all possible, it should track unspent blocks and start returning them at the eight-year span.

[theymos]

You actually could do true demurrage as a backward-compatible change. At least 50% of the mining power would need to agree to follow the same rules, but all other clients would have their transactions restricted by these rules regardless of whether they update. The miners could, for example, agree that all outputs must have their spendable value reduced by x BTC per retarget. Any transaction that violates this rule would never be accepted, just as if it was invalid. Furthermore, an output reduced to a sub-zero value could be safely forgotten by the network, since any spend using it would be invalid.

If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.

I don't think fee-based demurrage will happen. Why would miners disincentivize people from allowing old transactions to be forgotten? Maybe spending old transactions will actually give you a fee reduction. More likely, you'll be charged an extra fee for turning a small transaction into a large transaction. You'll get a fee reduction for spending the last output of a transaction and turning a large transaction into a smaller one.

The strict demurrage I described at the beginning of this reply could happen if old transactions become a large burden, though I wouldn't like it. Hopefully other methods will be found.

[jtimon]

If processing old transactions becomes expensive, then miners will start charging transaction fees to include them in their blocks.

Speculating about exactly HOW the miners will charge (will they subscribe to an 'old transaction service' or somehow contact the old-transaction-spender for the merkle branch of the old transaction?) is a waste of time, in my humble opinion.

I see.
So miners would just ignore old transaction unless a high enough fee is paid for renewing it.
This would also solve the storage problems from burned transactions and lost wallets.
Although feasible, creighto's proposal is not necessary to solve potential storage problems.

But...what happens if no one stores a block with not empty accounts?
Will some accounts become invalid because of time?
This could be an additional source of monetary base shrinking.