Pages:
Author

Topic: Why I support Jeff's BIP100 (Read 10526 times)

legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
December 06, 2015, 07:58:03 AM
#92
By thinking of bitcoin as a currency, everyone will day no to this. Currencies are meant to be stable, and be used like a ruler to measure the price of a good. If the scale of the ruler is changing each day, what's the point of that?

Bitcoin's stability doesn't stem primarily from the blocksize limit, though.  There are a multitude of factors affecting that, like the block reward and supply cap which won't be altered.  A variable blocksize only makes the system unstable if it's too large and we lose nodes or miners as a result.   The tricky part is determining how large is too large. 
legendary
Activity: 1232
Merit: 1029
give me your cryptos
December 06, 2015, 06:55:25 AM
#91
By thinking of bitcoin as a currency, everyone will day no to this. Currencies are meant to be stable, and be used like a ruler to measure the price of a good. If the scale of the ruler is changing each day, what's the point of that?
legendary
Activity: 1806
Merit: 1164
November 09, 2015, 04:29:03 PM
#90
Pools are voting for BIP100:

member
Activity: 129
Merit: 13
November 09, 2015, 04:18:23 PM
#89
I have been thinking about BIP100 carefully.  I think the voting process in BIP100  is not consistent with the existing power structure so could be undermined. This is with respect to a vote for a decreases in the blocksize limit, with an 80% majority being required. In some circumstances (but not all) 50% of the miners can impose a lower limit anyway, if they collaborate and orphan all blocks above a certain size. (Please note the opposite is not true, as all full nodes, and not just miners, are required to implement an increase in the limit)  This fact needs to be reflected in the voting mechanism, otherwise the voting can be considered to ignore reality.

For example, if 79% vote for a decrease and 21% vote for an increase, then under BIP100 the limit is unchanged.  This "defeat" for the 79% could serve as a catalyst for collusion to impose the lower limit anyway and undermine the voting process.  I think BIP100 should be constructed in such a way to avoid this disconnect from the actual power in the mining industry.

In conclusion, these voting systems need to be constructed such that 50% of votes or less, should be required for a reduction in the limit and 50% of votes or more, should be required for an increase in the limit. Therefore, to avoid the perception of small block bias, I think a simple 50th percentile rule is best.

BIP100 should be modified to a simple 50th percentile voting system.
legendary
Activity: 1316
Merit: 1004
October 01, 2015, 11:46:21 PM
#88
BIP 100 always has reminded me of what a Union represents in the US. Workers (in this case miners) will have a say so in the minimal wage for their job that they need to perform to get paid. If the "boss" doesn't comply (in this case, everyone who transacts in bitcoins), then the workers will go on strike. 

This could be very devastating for bitcoin in general. No workers means no security in transactions... Unions in the beginning meant to give people optimal working conditions and not promote a slave type of labor; since in this case we're talking about miners who use computers to do their work, this isn't necessarily valid.  I understand that miners are coming to the brink of whether they make a profit or not, but obviously something needs to be done to create a less costly way to mine coins.  If that were to happen then everything will be perfectly fine.
newbie
Activity: 52
Merit: 0
September 30, 2015, 10:45:26 AM
#87
the uncertainty with BIP100 too large.
legendary
Activity: 1246
Merit: 1004
September 29, 2015, 08:17:13 PM
#86
The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.

Fortunately, both BIP100 and BIP101 are very smooth already; not even close to suddenly doubling or halving.

I reject the whole "if needed" approach.  If demand were high and supply were low then we'd effectively have to choose between small blocks (hundreds of competing payment processors) and large blocks (one payment processor, the majority miner).  Even with 1MB blocks it's possible to cheaply process many more transactions than would be required for the hundreds of competing payment processors scenario.

This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.

I don't see how "fairness" enters into the debate.  I'm much more interested in finding something which works and is robust.
sr. member
Activity: 448
Merit: 250
September 29, 2015, 03:00:28 PM
#85
Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.

I was looking at some sort of hybrid between BIP100 and BIP106, so that the increase or decrease would take both the miner vote and the network traffic into account.  The change would only go ahead if the two were in alignment.  Also, the doubling/halving part might prove excessive, so felt that needed curtailing:

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%,
    lower blocksize limit by 12.5%,
    or remain at current blocksize limit. 

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5%

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
September 28, 2015, 04:56:57 PM
#84
Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.

I was looking at some sort of hybrid between BIP100 and BIP106, so that the increase or decrease would take both the miner vote and the network traffic into account.  The change would only go ahead if the two were in alignment.  Also, the doubling/halving part might prove excessive, so felt that needed curtailing:

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%,
    lower blocksize limit by 12.5%,
    or remain at current blocksize limit. 

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5%

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
member
Activity: 129
Merit: 13
September 28, 2015, 04:41:36 PM
#83
Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.
legendary
Activity: 1246
Merit: 1004
September 07, 2015, 07:05:09 AM
#82
Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.

Ah yes, that might do the trick.
member
Activity: 129
Merit: 13
September 07, 2015, 06:47:17 AM
#81
Possibly, but there may be a trade-off here.  Miners would also have less power to track changing demand (seasonal surges and declines) and so the voting mechanic will be less effective in increasing network security.

I do not think BIP100 or economic policy should be used to cater to seasonal demand variations.  Although I guess its imposible to draw a clear line between short term and long term demand variations.

Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.
legendary
Activity: 1246
Merit: 1004
September 06, 2015, 11:16:15 PM
#80
One possibly silly idea: Could BIP100 come along with a protocol rule making coinbase outputs unspendable for 4 years?  I'd be a bit more comfortable were votes undivorcably attached to long-term investments in Bitcoin.

It would be good to get your thoughts on this.  Could it work?  Is there something obvious I've overlooked?

Edit:
Transaction creators could channel their fees to miners using an OP_TRUE output, avoiding the coinbase lock described above.
legendary
Activity: 1246
Merit: 1004
September 06, 2015, 08:21:26 PM
#79
Given (7), I see no way for Alice to lose a game of chicken with a payment processing entity responsible for about 5% of all transactions.

In a game of chicken, Alice could have zero revenue whilst playing the game, all the payment processing entity has to bear is 10x lower fees and confirmations 5% slower.  Users may have a "loss" of at least 9 satoshis of benefit per transaction, but Alice losses everything.  Alice could lose the game.

Perhaps there is a resistance here.  My intuition still tells me that Alice would win but I'll admit it's not clear cut.

For example, there are some cases when some miners could actually benefit from a lower bitcoin price.  Please consider the following example:
1. A large proportion of the active network hashrate is earning bitcoin at a cost very marginally below the current market spot price of bitcoin.  Please see the below image for this hypothetical industry cost curve:
...

2. Miners with lower costs could cynically vote for a smaller size limit, in the hope the bitcoin price/mining revenue falls.  Lets say the bitcoin price falls to $900 in the above chart
3. The miners with higher costs start to lose the money and become inactive
4. The network difficulty falls, and therefore mining costs fall
5. The profit margins of the remaining lower cost miners increase, despite the lower bitcoin price/mining revenue.  Therefore these miners benefit in the short term

Interesting idea.  As you note, such an exotic situation is unlikely to occur and probably couldn't be sustained.  I'd imagine the costs of mining capital would change to reflect the risks of this potential attack (more efficient miners would become slightly more valuable and less efficient miners slightly less).  Still, I agree with you that it would be better to robustly block these niggling attack possibilities for a more predictable and efficient system overall.

As a defense against this and other similar voting based attack vectors, in the long term I think the voting period should significantly increase.  This could make it more likely more miners vote for the long term strength of the system, as short term attack based voting is likely to have less of an impact.

Possibly, but there may be a trade-off here.  Miners would also have less power to track changing demand (seasonal surges and declines) and so the voting mechanic will be less effective in increasing network security.

Maybe there are other ways the proposal could be made robust against such attacks.  Maybe an annual voting scheme could be combined with a new protocol mechanism to smooth out miner income across the year.  Maybe it can be shown that these medium-term surges and declines are no big deal.
legendary
Activity: 1246
Merit: 1004
September 06, 2015, 08:54:39 AM
#78
Thanks for taking a look at this.  I'm aware that my posts are getting lengthy.

In the above example Alice has 5% of the hashing power, therefore if she refuses to include transactions with a fee of less than 10 satoshis, users have a choice to pay 10x more in fees to be confirmed on average c5.3% faster.  Whether users choose to do this depends on their preferences, maybe c5.3% is enough and maybe it is not, clearly the higher the percentage the more compelling this is for users.  However, you need to also consider the game theory at play here, if users are willing to pay 10x the price for 5.3% faster confirmations, in the long term the best strategy could be to only create 1 satoshi fee transactions and wait it out, for Alice to go out of business or back down.  Therefore the dynamic is more complicated, a kind of game of chicken between Alice and the users.

True, but this would require actual co-ordination between the bulk of the transaction creators to achieve (the co-ordination in (12) is technically unnecessary and was assumed for simplicity).  The spirit of the situation is to assume that the miners do not collude; I consider it only natural to assume the same of the transaction creators.

Given (7), I see no way for Alice to lose a game of chicken with a payment processing entity responsible for about 5% of all transactions.

It is clear that if Alice has a high enough proportion of the hashpower, she can win and drive fees up.  We cannot say what this level is.  Another possibility is that Alice forms a "cartel" of other miners and they all demand 10 satoshi fees.  The key point is that it is in the interests of users and coin holders, for many reasons other than fee market dynamics, for the mining industry not to consolidate and to have a wide distribution of hashing power.  A distributed mining industry is a necessary but not sufficient condition for Bitcoin to succeed, otherwise it will lack enough distinguishing characteristics from more traditional forms of money. Therefore, for the purposes of discussing these fee dynamics many years away, we should assume the mining industry is decentralized, otherwise this discussion is not relevant as Bitcoin would have failed.  Therefore, its likely that Alice will not have enough hashing power, or will be unable to form a cartel to drive up prices in the way you suggest.

Agreed.  I'll note that I consider the existence a single mining entity that acquires about 5% of all blocks to be well in line with "a wide distribution of hashing power" (Pareto distribution and all that).  I'd be interested to hear if you see "wide distribution of hashing power" differently.

BIP100 may therefore be necessary to allow miners to restrict supply, but at the same time remain decentralized and avoid forming an actual cartel.

Certainly, BIP100 creates a framework for miner coordination, setting cartel-like prices but not creating an actual cartel.  I also believe that in some situations, BIP100 will actually function to prevent miner centralisation.  However, I think there are other natural situations where BIP100 without limits will be powerless to stop miner centralisation (situations where there is a lot of demand for block space).
member
Activity: 129
Merit: 13
September 06, 2015, 07:18:24 AM
#77
In the above example Alice has 5% of the hashing power, therefore if she refuses to include transactions with a fee of less than 10 satoshis, users have a choice to pay 10x more in fees to be confirmed on average c5.3% faster.  Whether users choose to do this depends on their preferences, maybe c5.3% is enough and maybe it is not, clearly the higher the percentage the more compelling this is for users.  However, you need to also consider the game theory at play here, if users are willing to pay 10x the price for 5.3% faster confirmations, in the long term the best strategy could be to only create 1 satoshi fee transactions and wait it out, for Alice to go out of business or back down.  Therefore the dynamic is more complicated, a kind of game of chicken between Alice and the users.

It is clear that if Alice has a high enough proportion of the hashpower, she can win and drive fees up.  We cannot say what this level is.  Another possibility is that Alice forms a "cartel" of other miners and they all demand 10 satoshi fees.  The key point is that it is in the interests of users and coin holders, for many reasons other than fee market dynamics, for the mining industry not to consolidate and to have a wide distribution of hashing power.  A distributed mining industry is a necessary but not sufficient condition for Bitcoin to succeed, otherwise it will lack enough distinguishing characteristics from more traditional forms of money. Therefore, for the purposes of discussing these fee dynamics many years away, we should assume the mining industry is decentralized, otherwise this discussion is not relevant as Bitcoin would have failed.  Therefore, its likely that Alice will not have enough hashing power, or will be unable to form a cartel to drive up prices in the way you suggest.

BIP100 may therefore be necessary to allow miners to restrict supply, but at the same time remain decentralized and avoid forming an actual cartel.
legendary
Activity: 1246
Merit: 1004
September 05, 2015, 08:49:45 PM
#76
(1), (4), (5) and (6) imply that all miners are withholding all hash power until the total fee in mempool hits a desired threshold. I don't think that equilibrium can exists. Indeed any miner has the opportunity to orphan the last top to "steal" the transaction in that block while the network is waiting for the mempool to fill. Consequently any miner has to "defend" their block after finding a solution by mining on top of it, and will naturally add all fee paying transactions they can get on the way, forcing every other miner to commit at least some hashing power as soon as a new block is propagated.

I'd not considered the strategy of attempting to orphan existing blocks.  Good point.  I'll need to think about this.

Is this not a general problem with (4) and (5)?  Ignoring Alice, is sweeping the mempool always economically unwise absent a block subsidy?

You could rework your example with the assumption that miners are throttling their hash rate based on total fees in the mempool but even that may not stand in view of this previous counter argument.

Quote
13. Suppose that these 10-satoshi-fee transactions are distributed uniformly with time.

(13) coupled with (6) will reduce the average time it takes for every miner to start committing hash power, not just Alice. Generally, it means (7) is true with or without Alice. It also means that Alice may never hit her expected fee density.

I imagine the global stock of mining hardware will remain fairly heterogeneous.  I expect that some hardware will be more efficient than other hardware and so will be put to work sooner.  Alice, being a very large miner, would likely have some very efficient miners as well as some more aged hardware which can only earn its electricity consumption as the mempool grows large.

I certainly don't expect a situation where all miners have equally efficient hardware worldwide and all this hardware is put to work in unison at some special threshold.

(13) coupled with (6) will indeed reduce the average time the moment (13) comes into play.  By (1) I intend at each step to allow difficult to adjust appropriately to look for long-term stabilities.

In the Bitcoin network, block space suppliers compete for market share only by lowering prices, since the notion of quality does not apply to block bytes.

This is the simplification I'm challenging with my example.

You are speculating that Alice can exist in this market at a higher sell price only by waiting for demand to periodically outweigh supply.  However (5) contradicts that strategy, as it suggest supply is infinite for intents and purposes.

Yes, I'm assuming infinite supply in this sense.  However, while transaction creators demand the space, they also care about the time they must wait for the space.  Alice can do nothing about the first but she can have a small effect on the second.  For the lowest possible expected time to first confirmation of 10 minutes, a transaction creator needs every last miner willing to process their transactions.

As stated previously, other miners will not sit at this equilibrium.

I honestly haven't thought much about what other miners will do in this situation.  I guess that the most they could do to undermine Alice's strategy is to simply continue with their own, sweeping up every transaction they can find.

Assume my counter argument does not stand and Alice can still build "fat" blocks periodically regardless of the implications of (5). If she chooses to stick to this strategy despite the current equilibrium, the rest of the network will have a double incentive to orphan her:

1) Because of the first counter argument, as other miners know she is withholding all hash power until the mempool is attractive enough (according to (12), tx emitters know of her strategy, so there is no reason to believe other miners won't)
2) Because her blocks have higher than average fee density.

Given (5), I wouldn't expect miners to care only about fee mass and pay no attention to fee density.

I admit it seems rational that miners would try to orphan Alice's blocks in this scenario.  I'll need to think a bit harder about what might happen.  However, at this point I expect that another miner, Bob say, would experience an even greater burden.  Breaking one of Bob's blocks would give another miner access to all the transactions of the previous round, not just the 10-satoshi transactions.  When trying to break one of Alice's blocks, a miner is forgoing the opportunity to try and grab the 1-satoshi transactions she left on the table.
legendary
Activity: 3640
Merit: 1345
Armory Developer
September 05, 2015, 11:37:35 AM
#75
(1), (4), (5) and (6) imply that all miners are withholding all hash power until the total fee in mempool hits a desired threshold. I don't think that equilibrium can exists. Indeed any miner has the opportunity to orphan the last top to "steal" the transaction in that block while the network is waiting for the mempool to fill. Consequently any miner has to "defend" their block after finding a solution by mining on top of it, and will naturally add all fee paying transactions they can get on the way, forcing every other miner to commit at least some hashing power as soon as a new block is propagated.

You could rework your example with the assumption that miners are throttling their hash rate based on total fees in the mempool but even that may not stand in view of this previous counter argument.

Quote
13. Suppose that these 10-satoshi-fee transactions are distributed uniformly with time.

(13) coupled with (6) will reduce the average time it takes for every miner to start committing hash power, not just Alice. Generally, it means (7) is true with or without Alice. It also means that Alice may never hit her expected fee density.

In the Bitcoin network, block space suppliers compete for market share only by lowering prices, since the notion of quality does not apply to block bytes. You are speculating that Alice can exist in this market at a higher sell price only by waiting for demand to periodically outweigh supply. However (5) contradicts that strategy, as it suggest supply is infinite for intents and purposes. As stated previously, other miners will not sit at this equilibrium.

Assume my counter argument does not stand and Alice can still build "fat" blocks periodically regardless of the implications of (5). If she chooses to stick to this strategy despite the current equilibrium, the rest of the network will have a double incentive to orphan her:

1) Because of the first counter argument, as other miners know she is withholding all hash power until the mempool is attractive enough (according to (12), tx emitters know of her strategy, so there is no reason to believe other miners won't)
2) Because her blocks have higher than average fee density.
legendary
Activity: 1246
Merit: 1004
September 03, 2015, 07:49:32 PM
#74
Draft example:
    1. Assume that at all points in time, difficulty is such that blocks are found once every 10 minutes on average.
    2. Suppose all transactions pay a fee of 1 satoshi (ignore free transactions and fee per kB for simplicity).
    3. Suppose these transactions are produced at a constant rate.
    4. Suppose there is no block subsidy (so all miner revenue comes from transaction fees).
    5. Suppose each miner has the resources to completely empty the mempool with each block.  Suppose that this is the strategy currently employed by each miner.
    6. Suppose each miner only hashes when it is economically beneficial to do so (miners wait for a suitably plump mempool).
    7. Suppose at least 50% of all transactions are such that, to the creator, a reduction of the time to first confirmation by 10 seconds is worth more than 9 satoshis.

At this point we have a Nash equilibrium.

    8. Let Alice be a miner.
    9. Suppose that under the current scheme, Alice finds 5% of all blocks.
    10. Suppose Alice employs a new strategy: she only accepts transactions paying 10 satoshis.
    11. Suppose no transaction creators or other miners change their strategies.

At this point, Alice is doing worse than she was before (definition of Nash equilibrium).  From (6) we can see that Alice will in fact mine no blocks.

    12. Suppose transaction creators learn of Alice's strategy and co-ordinate a new strategy for themselves: the 50% of all transactions which would most benefit from a reduced time to first confirmation are broadcast with a 10 satoshi fee instead.
    13. Suppose that these 10-satoshi-fee transactions are distributed uniformly with time.

At this point, we can reasonably assume that Alice will find it profitable to hash at certain times.  She will be at a disadvantage relative to other miners, both for claiming smaller rewards and for having to wait for a larger mempool before she can begin mining.

    14. Suppose Alice finds 4% of all blocks.

At this point, Alice is earning much more than she was before (10) (Her revenue has increased dramatically.  Her costs also increase (1) but so do her profits (3), (13), (6)).  From (1), (5), (10), and (14) we can calculate that 1-satoshi-fee transactions must, on average, wait 25 seconds longer than 10-satoshi-fee transactions for their first confirmation (and suffer a higher waiting time variance).  By (7) and (12) we see that each of the 10-satoshi-fee transaction creators are better off than they were paying 1-satoshi fees.

Transaction creators continue to pay 10-satoshi fees frequently because, in this new scenario, the higher fee yields them utility.  Alice will be tempted to revert to her old strategy for even greater short-term profits but this will cause transaction creators to stop creating 10-satoshi-fee transactions, leaving Alice worse off in the long term.  Alice maintains her new strategy simply in caring about her long-term profitability.
legendary
Activity: 1246
Merit: 1004
September 03, 2015, 07:21:10 PM
#73
Even with no block subsidy and assuming all other miners always sweep the mempool I expect F will be greater than zero.  I think Alice from the example above could still find a viable mining strategy in only accepting 10-satoshi transactions and waiting for the mempool to grow sufficiently "plump" before beginning to hash.

That's assuming block size demand is superior to block size supply. Otherwise the mempool would essentially be empty after every block.

No, I was assuming that the mempool would be completely emptied with each block.

Clearly there is a debate on the projected supply vs demand, but in the absence of a block size limit, I'm expecting the technological gain from fast relay networks will keep the supply way ahead of the demand for pretty much ever.

Fair enough.  I expect that demand will catch up with and put pressure on supply myself.

My expectation is that as long as there is a realistic block size limit in place, the Nash equilibrium will put upward pressure on fees. With the absence of a realistic limit, the Nash equilibrium will induce the opposite effect and fees will be not be sufficiently high to support proper difficulty.

Just to be clear, I don't argue that with no block size limit that fees could support "proper difficulty".  I just don't see why each miner clearing the mempool with each of their blocks as the only stable, competitive outcome.

So my response to this:

Quote
It may be profitable for a miner to increase the minimum fee they will accept

would be "only if the Nash equilibrium supports it". Which is the same as saying that demand will outgrow supply, which implies there is not enough block space to wipe the mempool of fee paying transactions.

The corollary to this statement would be that if a miner can wipe the mempool, then competing miners cannot afford to do any less.

As far as this Nash equilibrium is concerned, I'm not sure exactly what the game is.  I suspect that by taking into account long-term thinking and the utility of faster confirmations that there could be more than one Nash equilibrium.

I'll post a draft example to better explain what I'm thinking.  Perhaps you'd be kind enough to pick a hole in it for me.
Pages:
Jump to: