Topic: Demurrage, transaction fees, storage fees & comparison to commodity money. - page 2. (Read 16781 times)

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.

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.

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.

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?

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"?)

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.

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-

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

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.

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.

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.

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.

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.

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.

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

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.

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


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


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.

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


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.


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.