Why Peter Rs Fee Market Wont Work

[danielW]

Hi many people like Peter Rs presentation about fee market. I disagree with him and wrote a blog post why.

http://danielwilczynski.com/2015/11/30/why-peter-rs-fee-market-wont-work

At the first Scaling Bitcoin conference Peter R presented his ideas on why a fee market would exist without a block size limit. You can see his presentation here: https://www.youtube.com/watch?v=ad0Pjj_ms2k.

He is wrong and I will explain why.

Peter says that a non-zero supply curve exists because increasing block size increases cost to miners due to higher orphan rate. I have also heard a variation of this argument with increasing block size being constrained by hardware resources, internet bandwidth etc.

Theoretically these arguments are correct, practically they are not.

The effect of block size on these costs is almost negligible.

The supply curve is not exactly flat but very close to it. It is practically (if not theoretically)  flat and at zero. In reality a fee market will not form.

As an example, we have a supply and demand curve for oxygen but there is no real market for it because its impractical for something so cheap with such a flat and low curve. Yes, Oxygen does have a supply curve because humans are capable of increasing its supply at an increasing cost.

When curves meet at extremes the market breaks down.

No block size limit would simply result in huge blocks and a much more centralised node network, that can be easier influenced by governments.

But lets ignore all of the above for a second.

Peter also says we need at least 2 mining pools, for a market to form based on the orphan rate cost. Of course you hardly have much of a market with 2 pools, or 5-10 pools. That is what we have now. You can not have a real efficient market for orphan rates with only a few participants at one end.

Furthermore, orphan rate is a result of block propagation and can be decreased by moving pools closer together geographically. That is obviously very negative if we are trying to prevent mining centralisation.

You might ask, why can a fee market form with fixed block-size supply then? After-all we still have only a small number of pools? The reason is, that in Peter’s model the cost variable is due to the differing orphan rate between pools. That is not true for fixed block size. There is no variable for the supply curve. Thats why the supply curve is a straight vertical line.

Finally Peter refers to the block size limit as some ‘artificial centrally controlled limit’.

He does raise a good and important point here. In the situation of a fee-market based on limited block size. What would be the mechanism for changing the block-size limit and who would have control? The solutions from Peter R or others did not satisfy me personally. It is a valid question though. Are we to have a hard-fork each time we decide the fees are getting too high or low?  Do we implement code to allow a semi-centralised authority to decide? These do not seem like good solutions.

To say it is a centrally controlled limit is wrong however. To change the limit needs the consensus of the network i.e. nodes. Core developers have some limited ability to influence people, but ultimately they can not force through any change by themselves, they need the networks tacit agreement. Nobody and everybody controls the limit. Its control is decentralised (and therefore hard to change).

Finally there is nothing exceptionally artificial about the limit. Bitcoin itself is artificial, the 21 million limit is also an arbitrary artificial limit. Humans set the parameters of Bitcoin, its supply and its block size limit. The problem and difference is the 21 million limit does not have to change. Block size limit might have to, how will that be decided?

[jonald_fyookball]

I have read and thought about what you are saying and
first of all, thank you for reading and peer reviewing
Peter's paper.

Let's discuss.

I would like to believe that Peter is correct but
I'm open minded enough to consider that he may not be.

I want to understand more clearly what you are saying and why.

Peter says that a non-zero supply curve exists because increasing block size increases cost to miners due to higher orphan rate. I have also heard a variation of this argument with increasing block size being constrained by hardware resources, internet bandwidth etc.

Theoretically these arguments are correct, practically they are not.

The effect of block size on these costs is almost negligible

I'm not sure why you say that. Can you support that point?

Would would they be negligible?

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.

What am I missing here?

[Undermood]

I have read and thought about what you are saying and
first of all, thank you for reading and peer reviewing
Peter's paper.

Let's discuss.

I would like to believe that Peter is correct but
I'm open minded enough to consider that he may not be.

I want to understand more clearly what you are saying and why.

Peter says that a non-zero supply curve exists because increasing block size increases cost to miners due to higher orphan rate. I have also heard a variation of this argument with increasing block size being constrained by hardware resources, internet bandwidth etc.

Theoretically these arguments are correct, practically they are not.

The effect of block size on these costs is almost negligible

I'm not sure why you say that. Can you support that point?

Would would they be negligible?

To me, it seems anything but negligible, and seems like common sense. 
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.

What am I missing here?

Even Peter's speech, his reasons were not convining as well. Never mind it seems his proposol was not applicable in reality. No one will accept it except himself.

[BlindMayorBitcorn]

I know I didn't get it.

[johnyj]

Hi many people like Peter Rs presentation about fee market. I disagree with him and wrote a blog post why.

Finally there is nothing exceptionally artificial about the limit. Bitcoin itself is artificial, the 21 million limit is also an arbitrary artificial limit. Humans set the parameters of Bitcoin, its supply and its block size limit. The problem and difference is the 21 million limit does not have to change. Block size limit might have to, how will that be decided?

Yes, in fact his model indicated that in order to accept large blocks to earn more fee income, miners should use centralized large data center and relay network to speed up their communication and reduce the orphan cost. That's exactly the worst result from decentralization point of view, and his model does not calculate the value of decentralization, thus is too simplified

It is also interesting that you mentioned that all the limit in bitcoin is artificial. So if you could find a good reason why block size should be limited then that limit is possible to be accepted by the majority of the participants, similar to 21 million coin supply

Currently all the arguments that "block should not be full" borrow the typical reasoning from production and service industry: A higher cost for consumer will slow adoption. However, a monetary system does not work the same way as goods or service production, since any businesses ultimately try to earn money. So when your product is the final target of all the business, then you don't need to make profit by selling service, because people will automatically come for your product

It is similar to that central banks worry that if the fee of USD transaction is too high, then no one is going to use USD

People do not come to bitcoin to do transaction every day, they are after something that they can not find in fiat money: anti-inflation and anti-censorship and international payment, they should be willing to pay a high fee for these since they could not find these features anywhere else

In my opinion, payment function is the least important for bitcoin, if technology allow, it does not hurt to have a little bit more room for more transactions, but it can grow exponentially so eventually the blocks will be full and micro transactions will move offline. But that does not hurt bitcoin's adoption, because most of the people coming to bitcoin not to do micro transactions, for that purpose they have fiat money

[Cconvert2G36]

-snip-
People do not come to bitcoin to do transaction every day, they are after something that they can not find in fiat money: anti-inflation and anti-censorship and international payment, they should be willing to pay a high fee for these since they could not find these features anywhere else

Bitcoin is expensive in price because it is currently useful. All the other things you mention would be better served by monero. As many here will be happy to explain. 

[johnyj]

-snip-
People do not come to bitcoin to do transaction every day, they are after something that they can not find in fiat money: anti-inflation and anti-censorship and international payment, they should be willing to pay a high fee for these since they could not find these features anywhere else

Bitcoin is expensive in price because it is currently useful. All the other things you mention would be better served by monero. As many here will be happy to explain.  

People come to bitcoin seeking protect from inflation, and Monero is inflation in cryptocurrency world thus no one cares seriously  

[Cconvert2G36]

-snip-
People do not come to bitcoin to do transaction every day, they are after something that they can not find in fiat money: anti-inflation and anti-censorship and international payment, they should be willing to pay a high fee for these since they could not find these features anywhere else

Bitcoin is expensive in price because it is currently useful. All the other things you mention would be better served by monero. As many here will be happy to explain. 

Monero is inflation in cryptocurrency world thus no one cares seriously 

Shhhh... it's cereal stuff.

[jonald_fyookball]

so far, no one responded my actual point here.

[jonald_fyookball]

I guess Daniel's argument is without merit?
Peter's fee market is accurate?

[QuestionAuthority]

I guess Daniel's argument is without merit?
Peter's fee market is accurate?

Both are wrong and both are right to a degree. Since the reference implementation as of version 0.10.0 fees are treated differently. Here are the default settings that can be changed by the miner (which we know are large profit seeking farms). 50,000 bytes in the block are set aside for the highest-priority transactions (priority = sum(input_value_in_base_units * input_age)/size_in_bytes), regardless of transaction fee. Transactions are added highest-priority-first to this section of the block. Then transactions that pay a fee of at least 0.00001 BTC/kb (can be changed by the miner) are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes. The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

Considering the fact that these values can be easily manipulated by the mining consortium, fees can and will be adjusted to maintain profitability for the miner. This is fine if a method of announcing the minimum required fee for timely processing is announced publicly.

[jonald_fyookball]

I guess Daniel's argument is without merit?
Peter's fee market is accurate?

Both are wrong and both are right to a degree. Since the reference implementation as of version 0.10.0 fees are treated differently. Here are the default settings that can be changed by the miner (which we know are large profit seeking farms). 50,000 bytes in the block are set aside for the highest-priority transactions (priority = sum(input_value_in_base_units * input_age)/size_in_bytes), regardless of transaction fee. Transactions are added highest-priority-first to this section of the block. Then transactions that pay a fee of at least 0.00001 BTC/kb (can be changed by the miner) are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes. The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

Considering the fact that these values can be easily manipulated by the mining consortium, fees can and will be adjusted to maintain profitability for the miner. This is fine if a method of announcing the minimum required fee for timely processing is announced publicly.

What does any of that have to do with my point, that "the bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning."? 

[QuestionAuthority]

I guess Daniel's argument is without merit?
Peter's fee market is accurate?

Both are wrong and both are right to a degree. Since the reference implementation as of version 0.10.0 fees are treated differently. Here are the default settings that can be changed by the miner (which we know are large profit seeking farms). 50,000 bytes in the block are set aside for the highest-priority transactions (priority = sum(input_value_in_base_units * input_age)/size_in_bytes), regardless of transaction fee. Transactions are added highest-priority-first to this section of the block. Then transactions that pay a fee of at least 0.00001 BTC/kb (can be changed by the miner) are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes. The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

Considering the fact that these values can be easily manipulated by the mining consortium, fees can and will be adjusted to maintain profitability for the miner. This is fine if a method of announcing the minimum required fee for timely processing is announced publicly.

What does any of that have to do with my point, that "the bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning."? 

Oh, sorry, I thought you were talking about the fee market. Orphaning is usually just when two miners find blocks at very similar times. Bigger blocks should still be found within the adjusted parameters of difficulty and then shouldn't be any more susceptible to orphaning than the existing size blocks. That's a good question for the dev & tech section though. I can't see how blocksize should have any effect.

[gmaxwell]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Alternatively, miners can just consolidate to larger and larger pools-- which don't suffer any of those delays between themselves. Historically, this is how miners have responded to higher orphaning.

Alternatively alternatively, pools can just implicitly trust each other's work-- this is functionally equivalent to becoming a single larger pool for the purpose of this discussion.

Even ignoring all this, in the absence of subsidy orphaning risk doesn't produce a non-negligible minimum fee (in other words, this can't be an argument for fees providing Bitcoin's security in the long run). Even ignoring that, whatever 'implied limit' that falls out has no reason to be a blocksize which is workable for keeping non-mining full nodes on the network, so no check on the miner's behavior.


Amusingly, all of these were pointed out in peer review on Peter_R's paper, and he agreed to revise it to at least make the assumptions explicit... but then did not do so.

[BlindMayorBitcorn]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All of the expensive operations can be done before a block is found, then they do not add any proportional time.

Alternatively, miners can just consolidate to larger and larger pools-- which don't suffer any of those delays between themselves. Historically, this is how miners have responded to higher orphaning.

Alternatively alternatively, pools can just implicitly trust each other's work-- this is functionally equivalent to becoming a single larger pool for the purpose of this discussion.

I hope all this hostility isn't getting to you, Gmax. Keep fighting the good fight.

[Peter R]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Correct. 

Miners could agree to only solve blocks that the other miners are already expecting.  This would mean that exactly zero information about the block contents would need to be transmitted at the time of block-solution announcement.  This would eliminate any block-size dependent propagation risk. 

[jonald_fyookball]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Correct.  

Miners could agree to only solve blocks that the other miners are already expecting.  This would mean that exactly zero information about the block contents would need to be transmitted at the time of block-solution announcement.  This would eliminate any block-size dependent propagation risk.  

1. By expensive operations, I assume you mean the validation of transactions.
The validation of transactions could be done by the miner solving the block,  before a block is found, but the propagation of a large block across the network is another story.
Assuming a 1 MB/second speed, this seems like it would certainly become a factor when blocks get large, say 100 MB.  100 seconds
is surely significant (a factor of 16.6~% on a 600 second block interval).

2. Nodes validating the new block need to make sure they have all the transactions in the block and then compute the merkle tree (not sure how operationally expensive that is).
So are you sure "all" of the expensive operations can be done.  Seems like this would contribute to delay and orphaning.

P.S. no hostility personally to gmax despite my opinions about the blocksize debate.
 

[Peter R]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Correct.  

Miners could agree to only solve blocks that the other miners are already expecting.  This would mean that exactly zero information about the block contents would need to be transmitted at the time of block-solution announcement.  This would eliminate any block-size dependent propagation risk.  

1. By expensive operations, I assume you mean the validation of transactions.
The validation of transactions could be done by the miner solving the block,  before a block is found, but the propagation of a large block across the network is another story.
Assuming a 1 MB/second speed, this seems like it would certainly become a factor when blocks get large, say 100 MB.  100 seconds
is surely significant (a factor of 16.6~% on a 600 second block interval).

2. Nodes validating the new block need to make sure they have all the transactions in the block and then compute the merkle tree (not sure how operationally expensive that is).
So are you sure "all" of the expensive operations can be done.  Seems like this would contribute to delay and orphaning.

P.S. no hostility personally to gmax despite my opinions about the blocksize debate.
 

A lot of things are possible.  

Block-size dependent propagation delays can be completely eliminated if all of the miners know with some certainty what the next block could be before it arrives.  In particular, if miners know that the next block will be 1 of N possible blocks, and if N does not depend on the block size, then communicating which of the N expected blocks is the "real" block requires only log₂N bits (plus of course communicating the PoW).

It is even possible to have N=1.  Imagine that the miners mine a "practice blockchain" first and then the "real blockchain" next such that the blocks in the real blockchain lag those in the practice blockchain by, for example, one hour.  All miners agree to make the real chain an exact copy of the practice chain.  Voila: the "real blocks" can be communicated by just transmitting the block headers.  The fee market thus appears to break down.  

[jonald_fyookball]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Correct.  

Miners could agree to only solve blocks that the other miners are already expecting.  This would mean that exactly zero information about the block contents would need to be transmitted at the time of block-solution announcement.  This would eliminate any block-size dependent propagation risk.  

1. By expensive operations, I assume you mean the validation of transactions.
The validation of transactions could be done by the miner solving the block,  before a block is found, but the propagation of a large block across the network is another story.
Assuming a 1 MB/second speed, this seems like it would certainly become a factor when blocks get large, say 100 MB.  100 seconds
is surely significant (a factor of 16.6~% on a 600 second block interval).

2. Nodes validating the new block need to make sure they have all the transactions in the block and then compute the merkle tree (not sure how operationally expensive that is).
So are you sure "all" of the expensive operations can be done.  Seems like this would contribute to delay and orphaning.

P.S. no hostility personally to gmax despite my opinions about the blocksize debate.
 

A lot of things are possible.  

Block-size dependent propagation delays can be completely eliminated if all of the miners know with some certainty what the next block could be before it arrives.  In particular, if miners know that the next block will be 1 of N possible blocks, and if N does not depend on the block size, then communicating which of the N expected blocks is the "real" block requires only log₂N bits (plus of course communicating the PoW).

It is even possible to make N one.  Imagine that the miners mine a "practice blockchain" first and that the "real blockchain" next such that the blocks in the real blockchain lag those in the practice blockchain by, for example, one hour.  All miners agree to make the real chain an exact copy of the practice chain.  Voila: the "real blocks" can be communicated by just transmitting the block headers.    

Assuming those possibilities, what would be the implication about the fee market? 
Wouldn't this support Daniel's point that a fee market would not develop?

[Peter R]

To me, it seems anything but negligible, and seems like common sense.  
The bigger block, the longer the time is required to process
it, and the greater the the risk of orphaning.
What am I missing here?

All the of expensive operations can be done before a block is found, then they do not add any proportional time.

Correct.  

Miners could agree to only solve blocks that the other miners are already expecting.  This would mean that exactly zero information about the block contents would need to be transmitted at the time of block-solution announcement.  This would eliminate any block-size dependent propagation risk.  

1. By expensive operations, I assume you mean the validation of transactions.
The validation of transactions could be done by the miner solving the block,  before a block is found, but the propagation of a large block across the network is another story.
Assuming a 1 MB/second speed, this seems like it would certainly become a factor when blocks get large, say 100 MB.  100 seconds
is surely significant (a factor of 16.6~% on a 600 second block interval).

2. Nodes validating the new block need to make sure they have all the transactions in the block and then compute the merkle tree (not sure how operationally expensive that is).
So are you sure "all" of the expensive operations can be done.  Seems like this would contribute to delay and orphaning.

P.S. no hostility personally to gmax despite my opinions about the blocksize debate.
 

A lot of things are possible.  

Block-size dependent propagation delays can be completely eliminated if all of the miners know with some certainty what the next block could be before it arrives.  In particular, if miners know that the next block will be 1 of N possible blocks, and if N does not depend on the block size, then communicating which of the N expected blocks is the "real" block requires only log₂N bits (plus of course communicating the PoW).

It is even possible to make N one.  Imagine that the miners mine a "practice blockchain" first and that the "real blockchain" next such that the blocks in the real blockchain lag those in the practice blockchain by, for example, one hour.  All miners agree to make the real chain an exact copy of the practice chain.  Voila: the "real blocks" can be communicated by just transmitting the block headers.    

Assuming those possibilities, what would be the implication about the fee market?  
Wouldn't this support Daniel's point that a fee market would not develop?

Right.  If miners all agreed to behave in this way (e.g., pre-consensus by mining a practice chain first), then the fee market based on orphaning risk would break down.  It would be equivalent to the propagation impedance in my fee-market paper falling to zero.