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

[jtimon]

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.

Why would the "winner miner" apply that fee reduction?
He can get the whole fee while enjoying the saving in storage caused by the transaction.

[1715052581]

1715052581

[1715052581]

1715052581

[1715052581]

1715052581

[theymos]

Why would the "winner miner" apply that fee reduction?
He can get the whole fee while enjoying the saving in storage caused by the transaction.

Promoting smaller transactions is good for the miner unless he plans to quit mining soon.

[markm]

No-one mentioned the checkpoints, blocks that the client code knows enough about to realise the blockchain it is downloading is corrupt if any of those checkpoint blocks fail to match the values hard-coded into the client.

An attacker with >50% of the processing power cannot automagically convince the lesser percent of the network's processing power that those hardcoded checkpoints are wrong, so the attacked network will know for sure that any node trying to tell it a checkpoint block that does not match its own hard-coded checkpoint values is to be regarded as an attacker.

Thus, ancient (as in pre-existing the latest hard-coded checkpoint) coins are protected by those checkpoints. Do they still need constant adding of new blocks? Surely not? The entire network could simply stop completely and only transactions after the last hard-coded checkpoint will be at risk.

It seems to me to make a lot of sense that if "hoarders" (long term savers saving in actual unspent bitcoins rather than by investing or whatever) and "traders" (people making new transactions) have even slightly divergent goals that is an excellent reason for having at least two complementary blockchain-based currencies in use at any given time: one for saving and one for spending.

This whole thread seems kind of "moot" in an ecosystem of more than one blockchain-based currency. Get over the whole "there can be no blockchain but bitcoin's original blockchain" hangup and this whole problem can go away naturally.

From time to time a new blockchain can be started, with an explicit understanding/announcement that processing power is going to start moving toward the new chain, leaving the old chain to be secured primarily by means of the hard-coded checkpoints.

Eventually everyone interested in making new transactions and having them verified relatively fast will move to the new blockchain. People leaving their coins to their great great grandchildren will probably not worry too much that the Smithsonian, archive.org and other long term historical-storage facilities might take more than ten minutes to eventually release those coins come the century that their heirs finally choose to prepare to use them.

Announcements could even be made of at which block of both the old and the new chains the old chain will receive it's "final" checkpoint, after which no attempt to process a block every ten minutes will be made with the old blockchain. How to work out any later transactions on the old chain with the historical archive institutions need not even be detailed if this whole changeover is allowed a lot of time to happen, maybe even telling people that if they do want to leave their stash to their great great grandchildren they should in fact exchange it over to the new blockchain rather than depend on anyone being interested in buying ancient coins from ancient blockchains at some far future date.

Maybe we could simply add a -savingsnet flag like the -testnet flag for those wanting coins to save instead of (the default?) coins to spend...

-MarkM-

[jtimon]

Why would the "winner miner" apply that fee reduction?
He can get the whole fee while enjoying the saving in storage caused by the transaction.

Promoting smaller transactions is good for the miner unless he plans to quit mining soon.

So why would miners promote (by reduced fees) transaction that save storage space instead of smaller transactions?
I feel I'm missing something in your point.

[markm]

In fact if miners tend to be major investors in hardware as compared to non-miners, wouldn't at least some miners figure the vaster the blockchain the better, since they can better afford "vast" storage space (due to "economies of scale") than smaller players can?

-MarkM- (Isn't it typical in many or most industries to actually *want* {|such} "barriers to entry"?)

[jtimon]

In fact if miners tend to be major investors in hardware as compared to non-miners, wouldn't at least some miners figure the vaster the blockchain the better, since they can better afford "vast" storage space (due to "economies of scale") than smaller players can?

-MarkM- (Isn't it typical in many or most industries to actually *want* {|such} "barriers to entry"?)

Basically you're saying that miners would want maintaining the block chain to be more expensive to prevent others to compete with them.
Isn't it bad for the network users?

[elewton]

It's an interesting point.  Maybe some miners will restrict themselves to coins which they consider "hot" e.g. younger than X blocks and expect lower fees or (maybe?) expect that they can optimise their hasher for upcoming transactions, while archivers may charge higher fees or experience less pressure in the processor department while profiting from providing access to a longer history of the block chain.

I think this might be a form of miner speciation, separating the quick agile aggressive piranha-miner fighting for the most recent tranactions from the slow long-memoried whale-miner filter feeding through the older or lower priority transactions.

This of course requires a sufficient increase in the profitability of mining to begin the whole competitive and co-operative industry.

[MoonShadow]

• 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?

This is doable even in the current state of affairs.  A blockchain that doesn't mine, and has many connections to miners.  But that same blockchain server has to be compensated somehow, and this functionally means that those who use the blockchain server are going to have to pay that service directly.  In fact, I've been thinking about doing this exact business model, and charging a small monthly access fee for users.  The primary users, in my view, would be thin clients that use a redacted blockchain as a matter of course.

[MoonShadow]

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.

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

It's difficult to know the ratio, but the point is valid.  The standard behavior of the client is to total up as many inputs as necessary to pay the intended his due, and then the change returns to the sender.  Since the default behavior of the client is not to consolidate vast holdings into fewer transactions (the very behavior I'm trying to address) it's reasonable to assume that any transaction with more than one input is sending the larger of the two outputs.  So an average can be derived from the transaction records.

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

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

I'm suggesting an alternative minimum fee rule, for which any fee offered less than that the miners simply regard that transaction as among the 'free' class.  Either they pay the minimum fee expected for that transaction, based on this rule or any other minimum fee rule that is larger, or the transaction receives no priority bump compared to a free transaction and is not valid for the fee paying sections of the block.  By 'that low' I'm simply saying that I'm trying to establish a standard price floor that (profit minded) miners are likely to honor in general, so that users in general know to pay it.

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.

Because I'm trying to address the (admittedly very small) costs to the network for very old transactions.  The blocksize limits might pay for it fine, but that still wouldn't have a direct relationship to the costs of old transactions, but for the new transactions competing for space.  It wouldn't have any effect of encouraging the desired behavior from capital savers, namely the active reduction of resource usage.

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.

It's not much of an issue.  I've already admitted this.  The costs to the network required by any one old transaction are tiny, indeed.  But they do exist, and are cumulative in nature.  This cost isn't directly addressed in the current fee structure directly.  I'm proposing, and asking for better proposals, that directly address this long term cost.  The fees need not be large, and certainly shouldn't be large, to have the intended effect on user behavior overall.  I suggested an alternative minimum fee that would have expected only .00000026 BTC per year per input.  That's damn tiny, and it will be decades before this is either a value of any significance or even before the other minimums in effect are smaller than this.

[MoonShadow]

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.

This will happen anyway, so that lightweight clients can communicate with other lightweight clients offline.

[MoonShadow]

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 don't disagree.  I'm trying to create a standard for this that miners can turn to, and in this way also allow capital accumulators to plan out their best course of action before this point arises.  If my proposal, or something similar, is generally accepted by the miners as workable now, then current users will already begin to alter their behavior in a manner that limits their own costs in the future.

[jtimon]

It's an interesting point.  Maybe some miners will restrict themselves to coins which they consider "hot" e.g. younger than X blocks and expect lower fees or (maybe?) expect that they can optimise their hasher for upcoming transactions, while archivers may charge higher fees or experience less pressure in the processor department while profiting from providing access to a longer history of the block chain.

I think this might be a form of miner speciation, separating the quick agile aggressive piranha-miner fighting for the most recent tranactions from the slow long-memoried whale-miner filter feeding through the older or lower priority transactions.

This of course requires a sufficient increase in the profitability of mining to begin the whole competitive and co-operative industry.

Now I get what Gavin said.
The archivers would have an incentive to also ignore lost wallets and burned coins, although the first may be sometimes hard to know.
I still find the demurrage rule for the miners interesting.

[theymos]

So why would miners promote (by reduced fees) transaction that save storage space instead of smaller transactions?
I feel I'm missing something in your point.

Say that there are three transactions of 200 bytes with one spent output and one unspent output each. If someone spends all three of those unspent outputs in inputs in a 300 byte transaction, then the network has saved 300 bytes. I think miners will like this behavior enough to give a small fee reduction. Size-based fee rules would also promote this behavior somewhat.

[jtimon]

So why would miners promote (by reduced fees) transaction that save storage space instead of smaller transactions?
I feel I'm missing something in your point.

Say that there are three transactions of 200 bytes with one spent output and one unspent output each. If someone spends all three of those unspent outputs in inputs in a 300 byte transaction, then the network has saved 300 bytes. I think miners will like this behavior enough to give a small fee reduction. Size-based fee rules would also promote this behavior somewhat.

Oh, I see. Blocks that don't follow size-based fee rules would be rejected by other miners.
I guess the fee reduction would be a function of the space save to the network.
But aren't then you punishing the archivers mentioned before? The old transactions would be "forgotten" faster.
Also you're not restricting the user from paying a higher fee (that compensate the enforced reduction) to persuade the archiver to "remember" his previous transaction.

By the way, as accounts can be forgotten by the network I guess the lost wallets and burned bitcoins aren't a technical problem that demurrage fees solve anymore. Is not a problem because miners can prune old transactions without introducing more rules to the network.
The demurrage fees would in effect "force" every miner to become an archiver while putting a rule to "forget" collectively.
"Force" with an incentive and "forget" after exhausting the account.
Also renewing transactions would require a transaction fee, or miners would just prefer to keep earning demurrage fees for the old transaction. In this sense, demurrage subsidizes indirectly (and artificially?) transaction fees like the max block size.
One through a limit in the "bandwidth" of transactions and the other through a limit on the store time of transactions.

[rezin777]

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 don't disagree.  I'm trying to create a standard for this that miners can turn to, and in this way also allow capital accumulators to plan out their best course of action before this point arises.  If my proposal, or something similar, is generally accepted by the miners as workable now, then current users will already begin to alter their behavior in a manner that limits their own costs in the future.

I think you are trying to fix something that isn't broken and have no way of knowing if it is going to be broken or not. A lot of assumption. There is a danger here. Unintended consequences. This is why we have the saying, "If it ain't broke, don't fix it". You might end up doing more harm than good.

[smooth]

There is a danger here. Unintended consequences. This is why we have the saying, "If it ain't broke, don't fix it". You might end up doing more harm than good.

You could say that about inaction too.  In fact you could say that about having a bias in favor of inaction.

There is hardly any track record at all to say that bitcoin as it exists today "works" on a large scale over a long period of time.  It might, but there is no emperical reason to prefer the current implementation or policies in that problem space over anything else that also might work in that problem space.  The only real reason to prefer the status quo is that it costs nothing to implement, but that's a fairly small factor usually.

Any reasonable argument about long term success has to be based on some sort of analysis methodology (a simulation model for example) that is applied BOTH to status quo policies as well as some proposed alternative on more or less equal footing.

[rezin777]

It might, but there is no emperical reason to prefer the current implementation or policies in that problem space over anything else that also might work in that problem space. 

The empirical reason to prefer the current implementation is that it's working. It seems to be working quite well.

[stillfire]

It might, but there is no emperical reason to prefer the current implementation or policies in that problem space over anything else that also might work in that problem space. 

The empirical reason to prefer the current implementation is that it's working. It seems to be working quite well.

We haven't tested the current implementation without inflation driven mining which was the point smooth was making. We just don't have empirical evidence. We have nothing. There is no more reason to think this will work than something else without analysis.

We shouldn't change anything unless we have good reason to, but neither should we blindly cling to what we have without reason.

[theymos]

Oh, I see. Blocks that don't follow size-based fee rules would be rejected by other miners.

That could be done, but I'm not in favor of rejecting blocks based on fee rules (and that's not what I meant in my reply). Both fee reduction based on "old transaction deletability" and fee increase based on new transaction size can be optional.

I am speculating on what miners will do later as a free-market response to problems. I'm not proposing that any changes like these be made now, and certainly not in a way that would become permanent.