Output upkeep costs

[Meni Rosenfeld]

Transaction fees serve two purposes. They pay for the marginal cost of verifying, propagating and storing the transaction, and they pay for the amortized cost of hashing to secure it and all the other transactions. In this post I will focus on the former purpose.

Normally, a transaction's fee is paid once, but its cost in the requirement of every network node to download it and store it accrues forever, or at least until it is pruned. If it's of low value, it could stay unpruned forever, causing blockchain bloat. (It's also true that transaction fees are paid only to miners, while the cost is carried by all nodes; this can probably be solved by propagation incentivization schemes as in the Red Balloons paper, and will not be addressed here).

I'm of the opinion that bandwidth and storage are commodities, and there is no problem with "blockchain bloat" as long as the person who wishes his transaction to be recorded pays for the resources consumed. However, the resources required depend on the amount of time the transaction remains unpruned, and the current fee model does not take account of that.

There is a simple way to change this. I'll assume for simplicity that transaction A has a single output, and the transaction can be pruned some time after the output is spent. When spending the output as the input of a future transaction B, it does not add its entire value to the the amount that can be sent in the outputs of B; rather, a "storage fee" is deducted, determined by the storage size of transaction A and the time that has elapsed since transaction A, and added to a long-term fee pool (similar to the one discussed here, but with a much more gradual decay) which will be paid to future miners.

If the transaction is so low-value and old that the deduction is more than the value, it can be pruned and its value be added to the long-term fee pool. This prevents worthless transactions from being a burden forever.

There is some awkwardness in that the fee for storage is paid out not to those who stored it but rather future miners, but this is not as important as the fact that whoever consumed the storage resources pays for them for the benefit on the Bitcoin network at large.

Note that this is different from other proposals that depreciate or invalidate outputs, such as demurrage and coin recycling. The amount deducted is not proportional to the value of the output. Those who have a sizable life savings are not going to have it taken away from them - they can get it whenever they want, minus the appropriate storage fee. On the other hand, those who insist on keeping almost worthless outputs floating around will eventually see them discarded due to lack of interest. Because of this, I do not consider this an economic change of the kind that must never be done in Bitcoin. But if others disagree, this idea can still be used in an alt.

The actual fee paid will probably not be very large, since the commodities involved are fairly cheap. The exact proportionality constant can be either hardcoded (and changed once every few years to account for hardware advances and Bitcoin price appreciation), or adjusted with a dynamic system. There can also be a "grace period" of a year or so in which the fee doesn't accrue, so only exceptional cases of persistent outputs will be affected.

[Sergio_Demian_Lerner]

Very good idea. I had thought about which is the better way to solve the problem before, but your idea is the simplest and best.

Since (as I was told before in other thread)  there is no problem with destroying money (it makes everybody a bit richer) then you shouldn't bother to give the coins back to the miners. Just destroy them.

Nevertheless you will receive many opposing views such as: "there is no problem right now" or "it breaks compatibility" or "don't mess with my money".


Best regards, Sergio.

[Meni Rosenfeld]

Since (as I was told before in other thread)  there is no problem with destroying money (it makes everybody a bit richer) then you shouldn't bother to give the coins back to the miners. Just destroy them.

Well, there's nothing wrong with destroying bitcoins, but I still think it should be avoided if at all possible. And I think that overall, given the challenges we'll face in the future with regards to incentivizing miners to secure the network, increasing the mining subsidy for future generations is a bigger boost to network health than diminishing the supply thus appreciating everyone's holdings.

Nevertheless you will receive many opposing views such as: "there is no problem right now" or "it breaks compatibility" or "don't mess with my money".

Maybe. I'm open to any argument as long as it is done in a civil way. I hope this will be implemented one day, but I don't expect it to be any time soon.

[FreeMoney]

I'm not sure of anything, my understanding is shameful given how long I've been here, but here's a thought.

As mining becomes more memory intensive the job can be split up. There may be unions of miners who each hold part and make payments to each other based on the balance of queries vs answers. This would result in the user having to pay the miners cost. Maybe instead of 'unions' it'll just be supernodes that you can buy a subscription from.

It is the future tx issuer who wants that info available, not the past user. And if it becomes arduous to have that available he'll have to pay to have someone pull it out of the archives to make his tx confirm.

[runeks]

Interesting concept. I had the same thought some time ago. If you own gold and want someone to store it for you, you pay a fee. This makes perfect sense. I do think it's important that we correctly identify what needs to be incentivized. Non-miners who just hold a copy of the block chain and pass it on to peers are essentially just as much eligible for receiving the storage fee as miners. Miners add security, but don't aid in storage of the coins more than non-mining clients who also hold the block chain.

The grand question is how much should we value the securing of the network that only the miners perform vs the simple block chain storage and propagation that all non-thin clients (including miners) perform. An adaptive algorithm that finds out where there is a deficiency (in either network security or block chain availability) would be optimal. I still haven't figured out how to reward storage and propagation of the block chain though. Mining uses proof-of-work, can we do proof-of-propagation?

If we don't properly reward block chain storage and propagation, I suspect we might end up with a network with too many thin clients and not enough "thick" clients.

[Meni Rosenfeld]

Interesting concept. I had the same thought some time ago. If you own gold and want someone to store it for you, you pay a fee. This makes perfect sense. I do think it's important that we correctly identify what needs to be incentivized. Non-miners who just hold a copy of the block chain and pass it on to peers are essentially just as much eligible for receiving the storage fee as miners. Miners add security, but don't aid in storage of the coins more than non-mining clients who also hold the block chain.

The grand question is how much should we value the securing of the network that only the miners perform vs the simple block chain storage and propagation that all non-thin clients (including miners) perform. An adaptive algorithm that finds out where there is a deficiency (in either network security or block chain availability) would be optimal. I still haven't figured out how to reward storage and propagation of the block chain though. Mining uses proof-of-work, can we do proof-of-propagation?

If we don't properly reward block chain storage and propagation, I suspect we might end up with a network with too many thin clients and not enough "thick" clients.

As I mentioned, the Red Balloons paper goes some way into rewarding propagating nodes. Also, I expect that in the future full network nodes will offer a set of for-pay services to lightweight clients and pooled miners. So if we can incentivize miners, this should seep into nodes.

[Pieter Wuille]

I suggested something similar before: https://bitcointalk.org/index.php?topic=7942.0

[gmaxwell]

As I mentioned, the Red Balloons paper goes some way into rewarding propagating nodes. Also, I expect that in the future full network nodes will offer a set of for-pay services to lightweight clients and pooled miners. So if we can incentivize miners, this should seep into nodes.

It doesn't really.    The proposal it makes comes only at an enormous computational complexity and storage cost increase for transactions.  You can be forgiven for missing this because they don't speak clearly about the implementation.   In order to implement their proposal you must gather a public key from every peer. Then when you real to N peers you produce N copies of the transaction, each with the key of the peer you're handing it to embedded in the signed part.  Each of those peers makes N messages for each of N peers, appending that peers public key and signing with their own, and so on.  Eventually the miner ends up mining this enormous blob with all these signatures.   The signatures can not be stripped or otherwise miners will always strip them to avoid paying fees to anyone else.

It's hardly reasonable to attempt to incentivize forwarding transactions by first making it significantly more expensive to do so, especially when the ease of sharing information can solve that particular problem more easily by forwarding promiscuously (and, in particular, the author of a txn can give it to many miners directly).

(It's also the case that their fairness proof that discourages nodes from adding N copies of themselves only works on networks that form directed graphs, it doesn't appear to hold on randomly wired graphs like ours)

So much for the tangent—  in general I think you're mistaking the current purpose of fees,  right now they largely don't _pay for_ anything. They're used as a reusable proof of work to make certain kinds of denial of service attack costly.

[Meni Rosenfeld]

As I mentioned, the Red Balloons paper goes some way into rewarding propagating nodes. Also, I expect that in the future full network nodes will offer a set of for-pay services to lightweight clients and pooled miners. So if we can incentivize miners, this should seep into nodes.

It doesn't really.    The proposal it makes comes only at an enormous computational complexity and storage cost increase for transactions.  You can be forgiven for missing this because they don't speak clearly about the implementation.   In order to implement their proposal you must gather a public key from every peer. Then when you real to N peers you produce N copies of the transaction, each with the key of the peer you're handing it to embedded in the signed part.  Each of those peers makes N messages for each of N peers, appending that peers public key and signing with their own, and so on.  Eventually the miner ends up mining this enormous blob with all these signatures.   The signatures can not be stripped or otherwise miners will always strip them to avoid paying fees to anyone else.

I didn't say it solves the problem completely. Anyway, as far as I understand the miner eventually ends up with just the parts relevant to the path through which the transaction got to him, he doesn't need to know what was sent to the other peers.

It's hardly reasonable to attempt to incentivize forwarding transactions by first making it significantly more expensive to do so, especially when the ease of sharing information can solve that particular problem more easily by forwarding promiscuously (and, in particular, the author of a txn can give it to many miners directly).

Depends. In this case I'd say a resource consumption increase of about x10 is justified by a clear incentive structure for those providing it.

(It's also the case that their fairness proof that discourages nodes from adding N copies of themselves only works on networks that form directed graphs, it doesn't appear to hold on randomly wired graphs like ours)

I've spoken to the authors and they seem confident that the proof can be extended to other graph structures.

So much for the tangent—  in general I think you're mistaking the current purpose of fees,  right now they largely don't _pay for_ anything. They're used as a reusable proof of work to make certain kinds of denial of service attack costly.

This is a special case. If the resources to verify, broadcast and store transactions were in infinite abundance, we wouldn't have to worry about denial of service. But they're not, and DoS attacks work by consuming the limited resources. Hence, tx fees exist to make sure the demand for these resources (whether for a legitimate purpose or an attack) doesn't exceed supply, meaning, to pay for the resources.

Anyway, I am much less concerned about what tx fees are used for now, than about what they will be used for in the future.

[gmaxwell]

Depends. In this case I'd say a resource consumption increase of about x10 is justified by a clear incentive structure for those providing it.

Except it doesn't.  As a miner I would refuse to accept those bloat transactions and I would just widely publicize my addresses and encourage users to send their transactions directly to me.  As a user I would prefer to use software that knows about the addresses for many miners in order to enjoy the lowest required fees.

The resources required to process and forward transactions at the absolute maximum rate supported by the Bitcoin system can easily be supported by a high end desktop system on low end broadband, though this would be far less true if you made it >10x more expensive.   As it is it's vanishingly close to free.  Combined with the easy of spreading information widely, I don't think there is need for any more incentive beyond the inherit advantage of the Bitcoin system being well distributed and widely trusted.

Moreover, rewarding relaying doesn't align the incentives with validation— which is the more expensive thing.  I could happily add the redballoons rewards to transactions without validating them.  And the redballoons rewards makes the storage and validation costs to nodes actually providing validation much more expensive.   I could think of a lot better things to do with Bitcoin if we were to make TXN much larger.

I've spoken to the authors and they seem confident that the proof can be extended to other graph structures.

This seems really surprising to me.  If I can choose my peers, I will identify the miners, preferentially peer with them, and always forward to them with maximum-1 hops prepended.

[Meni Rosenfeld]

The resources required to process and forward transactions at the absolute maximum rate supported by the Bitcoin system can easily be supported by a high end desktop system on low end broadband, though this would be far less true if you made it >10x more expensive.

What are you referring to as "the absolute maximum rate supported by the Bitcoin system"? If it's 1MB per block then obviously this limit will be relaxed in the future. The maximum rate is determined by the resources put in it, so we want to incentivize putting in resources.

As it is it's vanishingly close to free.  Combined with the easy of spreading information widely, I don't think there is need for any more incentive beyond the inherit advantage of the Bitcoin system being well distributed and widely trusted.

It's a low cost per transaction, but with the current architecture, you either operate a full node or you don't. Operating a node that handles all transactions will be expensive, and without incentivization it won't be done.

Moreover, rewarding relaying doesn't align the incentives with validation— which is the more expensive thing.  I could happily add the redballoons rewards to transactions without validating them.

That's a good point, but maybe validation costs can be reduced with something like MAVEPAY.

I've spoken to the authors and they seem confident that the proof can be extended to other graph structures.

This seems really surprising to me.  If I can choose my peers, I will identify the miners, preferentially peer with them, and always forward to them with maximum-1 hops prepended.

I can't speak for the authors but to me it seems this doesn't break the system. You can take your peer's hashrate into consideration when deciding how much of the chain length to consume - if the hashrate is low or none, you'll consume as little as possible in hopes he will propagate it further, if it is high, you'll consume more to maximize your profits if he mines it itself.

I don't think that conceptually, everyone should know everyone in a p2p network. I don't agree with a system that relies on being able to identify your targets and communicate with them directly. If there are so few miners (more generally, block-constructing agents) that you can send to them all directly, we have a problem.

[gmaxwell]

The resources required to process and forward transactions at the absolute maximum rate supported by the Bitcoin system can easily be supported by a high end desktop system on low end broadband, though this would be far less true if you made it >10x more expensive.

What are you referring to as "the absolute maximum rate supported by the Bitcoin system"? If it's 1MB per block then obviously this limit will be relaxed in the future. The maximum rate is determined by the resources put in it, so we want to incentivize putting in resources.

There is no mechanism to relax the maximum block size without a hard chain fork. It's as technically difficult to raise the total number of Bitcoins.  And there is plenty of reason for the entire Bitcoin using community to strongly oppose an increase: Because any increase that raises the size to the point where keeping up requires a modest amount of resources would result in only a few wealthy and powerful entities running full nodes, completely destroying the value that Bitcoin provides: Decentralization.

It's a low cost per transaction, but with the current architecture, you either operate a full node or you don't. Operating a node that handles all transactions will be expensive, and without incentivization it won't be done.

You're presuming speculative changes to the system which would destroy its decentralization, and then you hope to buy it back by offering miniscule tidbits to a few parties.  Bad assumptions.  It's better to just assume the bitcoin using community will not accept changes which remove the decenteralization of the system.

That's a good point, but maybe validation costs can be reduced with something like MAVEPAY.

I'm pretty sure that no one wants to abandon all the strong security properties of the system to replace it with a soft majority consensus over everything.

I don't think that conceptually, everyone should know everyone in a p2p network. I don't agree with a system that relies on being able to identify your targets and communicate with them directly. If there are so few miners (more generally, block-constructing agents) that you can send to them all directly, we have a problem.

It's _very inexpensive_ to relay a transaction ... they're only a few hundred bytes and nodes ask if the far end has them already.  It's very difficult to hide 'apparent miners', the nodes that initially relay blocks for whomever is mining them— and if they're willing to relay the blocks it's a reasonable assumption that they're also willing to relay the transactions. If that isn't enough you could very easily send your transactions to a few dozen clearing houses which anyone who likes to can connect to.  This would have no validation overhead.

[Meni Rosenfeld]

The resources required to process and forward transactions at the absolute maximum rate supported by the Bitcoin system can easily be supported by a high end desktop system on low end broadband, though this would be far less true if you made it >10x more expensive.

What are you referring to as "the absolute maximum rate supported by the Bitcoin system"? If it's 1MB per block then obviously this limit will be relaxed in the future. The maximum rate is determined by the resources put in it, so we want to incentivize putting in resources.

There is no mechanism to relax the maximum block size without a hard chain fork. It's as technically difficult to raise the total number of Bitcoins.  And there is plenty of reason for the entire Bitcoin using community to strongly oppose an increase: Because any increase that raises the size to the point where keeping up requires a modest amount of resources would result in only a few wealthy and powerful entities running full nodes, completely destroying the value that Bitcoin provides: Decentralization.

It's as technically difficult but not as economically/socially difficult. People signed up to Bitcoin knowing the limit is 21M and changing this would destroy the Schelling point. The same cannot be said about the block size limit.

CC and PayPal and stuff process thousands of transactions per second; do you really want to limit Bitcoin to 3 transactions per second so people will have to resort to centralized services like CC and PayPal if they want to pay with their bitcoins? That would be destroying decentralization.

You can have thousands of transactions per second, and keep the hardware requirements low enough that it will be done by thousands of interested parties around the world - if they are properly incentivized.

Anyway, this is all not my opinion, it is my understanding that this is established consensus; arguing it is going to be a long and off-topic discussion.

Also, it is exactly my point that instead of placing arbitrary limits to make it easy to operate a node, you monetize it and let people sending transactions pay for the resources - which will encourage people to operate nodes. If the fee is high enough (and correspondingly, network traffic not excessive), it's possible that even at-home users will buy a dedicated high-end machine to run as a node for added income.

It's _very inexpensive_ to relay a transaction ... they're only a few hundred bytes and nodes ask if the far end has them already.  It's very difficult to hide 'apparent miners', the nodes that initially relay blocks for whomever is mining them— and if they're willing to relay the blocks it's a reasonable assumption that they're also willing to relay the transactions. If that isn't enough you could very easily send your transactions to a few dozen clearing houses which anyone who likes to can connect to.  This would have no validation overhead.

I don't understand. I didn't talk about hiding miners, I talked about difficulty in being connected to every computer in the world. If it's easy to connect to all miners / all clearinghouses then the system isn't decentralized enough.

[gmaxwell]

It's as technically difficult but not as economically/socially difficult. People signed up to Bitcoin knowing the limit is 21M and changing this would destroy the Schelling point. The same cannot be said about the block size limit.

Sure it can be. The selling point is ultimately decentralization: Even the 21 million limit is only a possibility because the decentralization makes changing it infesable.  "A few thousand parties" is nowhere near adequate to provide for the security and autonomy of Bitcoin— the groups that allow the current mess with government fiat currencies and central banks is larger than that and they permit it just fine.

Moreover, decapping the size removes the economic incentive to provide fees in the first place absent a conspiracy by the mining entities to fix prices, because it would remove any pressure to increase fees paid above epsilon— as you'll always make more in an instant by taking every single with-fee transaction no matter how small the fee is.  And, of course, if the mining parties conspire then none of the other security assumptions hold either.

CC and PayPal and stuff process thousands of transactions per second; do you really want to limit Bitcoin to 3 transactions per second so people will have to resort to centralized services like CC and PayPal if they want to pay with their bitcoins? That would be destroying decentralization.

Of course not, you build decentralized payment systems denominated in Bitcoin, like ripple pay or via open transactions.   These systems which don't require worldwide visibility for all information are _technically_ suitable for enormous transaction volumes while Bitcoin— a broadcast, everything known by everyone, medium is not technically suitable for the complete worldwide transaction volume.  Yes, under some assumptions (which almost completely abandon decentralization) you can make it work— but its hideous and costly, and just generally a bad idea— and it still leaves the users with slow transaction processing, and risk of reversal if they don't wait.

Anyway, this is all not my opinion, it is my understanding that this is established consensus; arguing it is going to be a long and off-topic discussion.

Your understanding is incorrect.   The only unarguable "established consensus" is the Bitcoin software itself— it is what defines Bitcoin and all of its properties.   And there is nothing in it about raising the hard blocksize limit. It _could_ have mechanism in it to facilitate that, but it doesn't.

I suppose it may be reasonable to assume some blocksize increase at some point in the future with the consent of effectively all the users, but if the users accept one which either makes it costly to run a fully validating node then they are fools who will consign Bitcoin to eventual centralization, or one which removes significant pressure for space in blocks— which will make mining economically nonviable and remove Bitcoin's security  against reversals.  ... but please don't mistake the overzealous defense of Bitcoin's potential scalability offered by a few users who haven't thought carefully about the implied loss of centralization and developers of centralized clients to be an official plan for the future.

[Meni Rosenfeld]

Moreover, decapping the size removes the economic incentive to provide fees in the first place absent a conspiracy by the mining entities to fix prices, because it would remove any pressure to increase fees paid above epsilon— as you'll always make more in an instant by taking every single with-fee transaction no matter how small the fee is.  And, of course, if the mining parties conspire then none of the other security assumptions hold either.

I agree. The fact that how to solve this problem is a hotly discussed topic suggests that people expect the limit to be relaxed. And the fact that there are proposed solutions suggests that this does not prohibit relaxing the limit.

Your understanding is incorrect.   The only unarguable "established consensus" is the Bitcoin software itself— it is what defines Bitcoin and all of its properties.   And there is nothing in it about raising the hard blocksize limit. It _could_ have mechanism in it to facilitate that, but it doesn't.

The Bitcoin software is just that, software. It changes to adapt to the problem it is set out to solve.

I didn't say it's unarguable, I said the argument is off-topic for this thread.

I suppose it may be reasonable to assume some blocksize increase at some point in the future with the consent of effectively all the users, but if the users accept one which either makes it costly to run a fully validating node then they are fools who will consign Bitcoin to eventual centralization, or one which removes significant pressure for space in blocks— which will make mining economically nonviable and remove Bitcoin's security  against reversals.  ... but please don't mistake the overzealous defense of Bitcoin's potential scalability offered by a few users who haven't thought carefully about the implied loss of centralization and developers of centralized clients to be an official plan for the future.

If you look at this thread you'll see many people, including Gavin, not even talking about whether the block size limit should be relaxed, but taking it for granted and figuring out how to do this dynamically. Mike Hearn is known for having analyzed how can Bitcoin be scaled to thousands of tps, and theymos has recently made a comment favorable towards a limit change. Apparently Satoshi was in favor too, but I can't find a source.

I didn't find any comment saying that 1MB should be the limit forever, so it seems that in fact you are of a minority opinion. Anyway, again, whatever we want the tradeoff between scalability and ease of running a node to be, the proper way to achieve it isn't a block size limit, it's a transaction fee structure.

[lophie]

I really like this idea.... adding incentive for full nodes that do not want to mine.

Necromancer regrets....

[misterbigg]

Necromancer regrets....

It's good that this was brought up again because it might provide a solution to the transaction spam originating from SatoshiDICE.