Disincentive to confirm transactions when burning (destroying) transaction fees?

[DeathAndTaxes]

The economics of orphans as it relates to transactions has become more understood in the last year.  I started thinking about how it would affect a currency like Peercoin (PPC) which doesn't compensate miners with transaction fees and instead burns them.   Will this create an economic disincentive for miners to include transactions in the next block?

Peercoin has a low level of persistent inflation.  PoS will increase the coin supply by 1% annually.  Peercoin is a hybrid coin with both PoW and PoS.  The PoW component contributed to the majority of the inflation in its early history but it will decay to a negligible level over time.  For the purpose of this question the PoW component can be ignored.   PPC offsets this new minting by destroying the transaction fees instead of paying them to miners as with Bitcoin et al.   Monetary inflation will approach at rate of:  m = 1% - (tx fees / money supply).  Unlike some inflation zealots I have no issue with this.  Inflation is capped at 1% and in reality will be lower, it is even possible the coin will be slightly deflationary.   In the long run a monetary system with <1% inflation or <1% deflation is not a material change to a money supply which is static.  Burning the tx fees is an interesting way to provide a counterbalance to the continual minting of new coins.  This structure however creates an economic disincentive to miners in the form of uncompensated orphan costs.  This shouldn't be viewed as judgement on the developers.  Peercoin launched almost two years ago and there was less discussion on the economics of transaction selection at that time.

For those unfamiliar with the term, orphan costs refer to the economic cost of including one more transaction in the next block.  All blockchain based currencies have orphaned blocks.  Orphaned blocks are due to a second competing block being found after a miner has found a block but before the block has propagated the entire network (specifically to all miners).  The larger the latency between when a block is found and when it has finished propagating the higher the probability that a competing block will be found.  Although it isn't the only factor the size of the block contributes to the latency.  All other factors being the same a block which is twice as large, will take twice as long to propagate and thus has twice the chance of being orphaned.   The cost can be expressed as Bitcoins (or uBTC) per kB.  If the orphan cost is higher than the fee paid then the miner has no direct economic incentive to include the transaction.  Including the transaction will in the long run reduce the net revenue paid to the miner.  To date most miners have been forward looking and include transactions even if they do marginally reduce net revenue however a system based on direct economic benefit is stronger than one based on charity or working for the common good.  

There are some optimizations that are possible and with Bitcoin the declining subsidy and rising number of paying transactions will reduce the orphan cost over time.  The burning of fees on the Peercoin network means that all transactions are essentially unpaid from the view of the miner.  Peercoin can use the same optimizations proposed for Bitcoin to reduce the orphan cost but the gross revenue for all transactions will always be zero.  This means that all transactions will have a negative effect on net revenue and there is no economic incentive to include the transaction in the next block.  The maximum net revenue is already available by mining an empty block and including any additional transactions only serves to lower the miners net revenue.  The more transactions the miner includes the less net revenue he receives.  Some miners may work for the common good and there is an indirect mutual benefit by supporting the network, however arrangements which lack a direct benefit can lead to a tragedy of the commons.

Do you see this as an issue for Peercoin or more widely for any system where the fees are burned?  How can the disincentive be reduced or eliminated?  I have a couple ideas (but they all involve hard forks).  I will post them later but I would like to see other viewpoints first.

[1714780075]

1714780075

[1714780075]

1714780075

[1714780075]

1714780075

[1714780075]

1714780075

[telepatheic]

The first thing to note is that assuming miners are rational is a rather poor assumption. As Peter Todd likes to point out, if a miner has to spend several hours modifying code to increase their revenue by a tiny amount, they will likely not do it, even if over a long period of time they will easily recover any costs.

Most miners simply use software which is available to them and which they feel is ethically right. If miners were fully profit maximising they would DOS other miners, deliberately put large transactions onto the network to slow down other miners but not themselves, offer transaction double spend services and form conglomerates to mine selfishly.

Peercoin miners don't optimise their earnings by doing many more malicious things like forming mining pools that make sure that they create blocks which guarantee that only pool members will be able to mine blocks in future via proof of stake (this attack is extremely complex to analyse because of the trade off between using coin age now vs in the future and the use of checkpoints, but I believe it is still possible with far less than 50% of the stake)

In terms of bitcoin, sending blocks "headers first" seems to solve the orphan block problem as propagation becomes more or less independent of block size.

[DeathAndTaxes]

The first thing to note is that assuming miners are rational is a rather poor assumption. As Peter Todd likes to point out, if a miner has to spend several hours modifying code to increase their revenue by a tiny amount, they will likely not do it, even if over a long period of time they will easily recover any costs.

Not sure what is much of a barrier.  Open source and the trivial nature of the change means a few minutes of work and it can be replicated at no cost.   Hell the development could even be done and promoted by an outsider party (i.e. large bitcoin stakeholder who sees PPC as a competitive threat).   As block sizes rise the incentive to "cheat" will grow.   If all miners produce blocks of the same size the effective orphan rate approaches zero.   However as the nominal orphan rate rises the benefit from cheating also rises (and a larger reduction is possible).  

Most miners simply use software which is available to them and which they feel is ethically right. If miners were fully profit maximising they would DOS other miners, deliberately put large transactions onto the network to slow down other miners but not themselves, offer transaction double spend services and form conglomerates to mine selfishly.

Agreed although I would think it is a smaller ethical leap for a miner to let other miners pick up the transactions because his margins are really low than it is to engage in direct attacks on the network.   I guess my point was more about as disincentive influencing otherwise honest but pragmatic miners.

In terms of bitcoin, sending blocks "headers first" seems to solve the orphan block problem as propagation becomes more or less independent of block size.

Until they receive the merkle tree, miners can only mine an empty block.  The block message size can be optimized significantly (>90% is possible) but it will still be space dependent.  With Bitcoin I see this as less of an issue because the falling subsidy combined with more efficient propagation means the orphan cost can be made very low (possibly <100 sat / KB after two subsidy cuts).  For transactions above that threshold there is no reason not to include them.  It becomes the path of least resistance.

[coinft]

Miners could agree not to build on purposefully empty or too small blocks. If the majority complies, the risk of getting an empty block ignored by the network costs too much.

This could be done informally just by each node looking at its own memory pool, and not forwarding new blocks which do not contain enough TXs, and miners not building on them. Or a more elaborate scheme could involve some cryptographic proof of neglected TXs.

Probably just the threat of such a scheme is enough to keep miners in line.

[telepatheic]

Agreed although I would think it is a smaller ethical leap for a miner to let other miners pick up the transactions because his margins are really low than it is to engage in direct attacks on the network.   I guess my point was more about as disincentive influencing otherwise honest but pragmatic miners.

It depends on pre-conceived ideas of what an honest miner is. I guess most people would think a miner not including any transactions is more honest than a miner offering a double spend service but I would argue that a network with no transactions is worse than a network with a constant risk of 1 or 0-confirmation double spending.

Until they receive the merkle tree, miners can only mine an empty block.

I hadn't really thought about that too much, it does improve the situation though. Empty blocks are only sent out if they are found relatively quickly which has less impact on the end users.

Bitcoin users must realise that bitcoin is not fundamentally proving that decentralised consensus is possible. It is simply a clever trade-off of consensus  security vs expended work under the assumptions that the majority of the work is being done by machines which are honest (ie obey a set of rules even against opposing short term economic incentives) and we have a reliable network infrastructure.

In certain cases those assumptions are unrealistic. Imagine if satoshi (or indeed anyone massing up large amounts of bitcoin) were to make a transaction today sending a million coins to a transaction fee but with an nLockTime a week in the future. Everyone will want to mine that block. Miners will likely go to great lengths to be in the biggest pool, pool owners will try to screw over their miners and start DOS attacks. And even once the block is mined there will be weeks or even months of uncertainty that there might be a massive reorganisation.

[Peter R]

Miners could agree not to build on purposefully empty or too small blocks. If the majority complies, the risk of getting an empty block ignored by the network costs too much.  This could be done informally...

I wonder if it could also be done formally (as in enforced by the protocol).  

I proposed an idea like yours on another thread about establishing informal "best-practices" for filling each block (however, I never suggested that miners ignore blocks from those who break the guidelines).  It could be informally agreed upon, for example, to use a proportional feedback controller to determine the block_size for the current block you're working on

   block_size = avg_blocksize_last_diff_period  +  
                           K1 x (unconfirmed_transactions_kB - target_unconfirmed_transactions_kB)

where K1 is a gain parameter.  

But I've always wondered if you could actually enforce this at the protocol level (not that I think it would necessarily be a good thing if you could) by using "block_size > … " rather than an "block_size = ...".  The parameter "avg_blocksize_last_diff_period" is deterministic (full nodes and miners will be in 100% agreement) and K1 is static.  If we also set
 
   target_unconfirmed_transactions_kB = K2 x avg_blocksize_last_diff_period

this parameter becomes deterministic too.  The only thing the network will not agree on is the precise value of unconfirmed_transacations_kB.  However, well-connected nodes should all be in loose agreement here.  In order for a miner to have his block accepted, he will be motivated to add a bit more transactions than are strictly necessary to ensure that his peers accept it (because their value of "unconfirmed_transactions_kB" may be slightly larger) but not too much more TXs in order to minimize his chance of having his block orphaned.    


The question is whether this algorithm would be stable and byzantine robust for certain values of K1 and K2.  

[jonald_fyookball]

I can imagine that the tragedy of the commons would be easily avoided because there are stakeholder rewards.  Thus, many stakeholders would also be do-gooder miners.

Mining empty blocks (or selectively ignoring transactions)
is btw also an issue of concern for bitcoin in the 51% attack scenario.

I would like to explore possible solutions to this. 

Not to take this thread on too much of a tangent,
but some food for thought seems to be found here:

http://bitslog.wordpress.com/2014/05/02/decor/

[Cryddit]

The DECOR idea is good, for several reasons. 

First because the hashing power spent on a fork is hashing power which can be counted as having been spent on the main chain, when comparing the main chain to any *other* fork. 

This is also useful because it makes "preparing an attack chain ahead of time in secret" less plausible; the root of the attack chain failing to appear in the "orphaned blocks" of the following block on the main chain would make the falsehood of the attack chain much more obvious. 

It would be advantageous, IMO, to generalize it; instead of just recording siblings of blocks in the main chain, you could record siblings, their children, their grandchildren, etc - for as long as the attack chain was within, say, 3 blocks' worth of hashing work of the main chain.  This would make it possible to track the progress of a threatening "fork" from the main chain, at least if the "fork" consists of blocks that have actually been announced.   And unannounced blocks suddenly appearing on a chain more than three blocks behind the main chain should be regarded with suspicion, at the very least. 

It might be reasonable to require a 4-to-1 work difference before switching to a fork whose root isn't recorded in the chain you're switching from, simply because such a fork is much more likely to be an attack chain. 

The important thing here is that someone could make a conclusion about the status of the blockchain's security by looking at a block.  If there's no announced fork running, you can be sure that a fork prepared in secret will have to contain four times as much work to displace the chain you're paying on, and if there is an announced fork, you can wait until the main chain is seven blocks ahead of it before you make any major transactions.

[gmaxwell]

Fee burning is usually ill advised for an unrelated reason—  usually they're burned as some way of escaping some bad motivation (e.g. miners might be incentive to bloat up blocks if they could collect fees!),  but forced fee burning is actually impossible because you can pay any non-forced feed out of band rather than as a fee (and forced fees have a problem of fixing the economic scale).  E.g. I can just make my transaction pay the miner as an output instead of as a fee. I can even helpfully author N versions, each paying a different miner, and the miners can choose whichever version they like.

For a long time eligius ran code that considered payment to the pools donation address as fees, I'm not sure if it still does— but it's a trivial change.

Not really an answer to your question directly, but perhaps it is one indirectly: the disincentive in those systems can be overcome by exactly that dodge to the intended incentive system there... pay the miners out of band and they're rewarded for including the transactions.