SatoshiDice, lack of remedies, and poor ISP options are pushing me toward "Lite"

[Meni Rosenfeld]

There _must_ be competition for block space to make fees a viable way to pay for security.  

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

[1714809821]

1714809821

[meowmeowbrowncow]

There _must_ be competition for block space to make fees a viable way to pay for security.  

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

Meni.  What is the degree of this TotC problem?  That is to say what percentage of self-interested miners (or I suppose successful blocks solves) would sufficiently degrade the position of a loose affiliation of miners enforcing a sustainable tx fee?

 

[nevafuse]

There _must_ be competition for block space to make fees a viable way to pay for security.  

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

The same argument could be applied to block size.  Competition creates an environment where tx fees = mining costs.  Right now tx fees + block reward = mining costs.  Block reward is high, so tx fees are low.  Once the block limit starts to become a problem, it will be increased or removed.  It's a win-win for everyone.  More transaction fees per block & faster confirmations.  The only downside is a larger blockchain, but I don't think we're even close to limiting transactions based on bandwidth and/or storage concerns.

Keeping the block size limit may increase tx fees in short term, but long term it will be more harmful than good to the miners.  People will be annoyed by the long confirmation times & high fees and start using a different cryptocurrency.  Now the miners have hurt themselves by transferring value out of the bitcoin economy.

[Meni Rosenfeld]

There _must_ be competition for block space to make fees a viable way to pay for security.  

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

Meni.  What is the degree of this TotC problem?  That is to say what percentage of self-interested miners (or I suppose successful blocks solves) would sufficiently degrade the position of a loose affiliation of miners enforcing a sustainable tx fee?

That's hard to quantify, especially without empirical data on how much users are willing to pay to get their transactions included faster. But about 40% is the hashrate a cartel needs to perform a profit-boosting attack, so I'd say it might be the overall ballpark for the hashrate needed by a group of miners with an unwritten agreement to reject low-fee txs in order to keep the pressure up. But that's assuming the immediate-profit-maximizers are individually small; if there are only 10 miners with 10% hashrate each, it's probable they will converge to rejecting low-fee txs even if they did not originally intend to.

[zebedee]

There _must_ be competition for block space to make fees a viable way to pay for security.  

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

Why do you believe this (that small self-interested miners will survive)?  Why must this be a tragedy of the commons?  What is special about bitcoin mining that makes block space the only scarce resource that cannot find a price?  Removing the limit doesn't make it a non-scarce resource, as precisely the fact it is a scarce resource is what is apparently scaring so many commenters.

My gut feeling is that the block size limit should be removed, and let the free market reign.  It works elsewhere, why not for transaction processing?

You're effectively claiming that some miner can survive and be profitable / just eat the cost by being selfish and adding all transactions no matter how small the fee.  Good for her!  She must be more efficient than everyone else.  If you can't stand the competition, stop trying to compete and get out of the race.  If mining is not profitable, miners will drop out until it is profitable, just like happens now.  Everyone will benefit from the competition towards more efficient mining setups and lower transaction fees. 

The argument that block size must be limited seems to me to ignore that:

- every node is free to not relay "spam" blocks, in the same way they are free to not relay spam transactions now, for whatever definition of spam that node sees as fit.
- hashing transactions into blocks has a cost, as does relaying large blocks.  If your block is "too big", for some technology and market-determined definition of big - then you will be beaten to the relaying race by a smaller, lighter, more network-acceptable block.
- a real feedback loop exists here to determine the right pricing and policies, "on average"
- every node is free to implement whatever policy on this stuff they want.
- if sufficient hashing power believes a certain miner or pool is an anti-social PITA, they can put "social pressure" on them by not relaying their stuff.

Remove the block size limit entirely I say.  Ultimately it is effectively just another indirect input to block difficulty, and we let all the other inputs such as CPU/GPU/ASIC technology advances float, and so we should do the same for block size.

[Meni Rosenfeld]

Why do you believe this (that small self-interested miners will survive)?  Why must this be a tragedy of the commons?  What is special about bitcoin mining that makes block space the only scarce resource that cannot find a price?  Removing the limit doesn't make it a non-scarce resource, as precisely the fact it is a scarce resource is what is apparently scaring so many commenters.

I will say again. Block data size is one cost (storing the data, downloading and uploading it, and it also correlates with number of signature verifications required). Hashing is a completely different cost which is independent of the block size. There is no way to reasonably discuss this without clearly understanding the distinction.

Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks).

This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it. This means epsilon will tend to 0 and total revenue from txs will be equal to the resource cost needed to handle them, leaving no revenue to sponsor the very expensive hashing.

My gut feeling is that the block size limit should be removed, and let the free market reign.  It works elsewhere, why not for transaction processing?

It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed.

For the marginal cost of handling transactions, the externality is network burden, and one solution is to limit network burden per block.
For the amortized cost of hashing, the externality is dissolving the bargaining power of hashers. One solution is to limit the bitcoins transferred per block. (So miners can still have bargaining power against big senders willing to pay a large fee to have their tx included).

You're effectively claiming that some miner can survive and be profitable / just eat the cost by being selfish and adding all transactions no matter how small the fee.  Good for her!  She must be more efficient than everyone else.  If you can't stand the competition, stop trying to compete and get out of the race.  If mining is not profitable, miners will drop out until it is profitable, just like happens now.  Everyone will benefit from the competition towards more efficient mining setups and lower transaction fees.

Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally.

The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate.

There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet.

[zebedee]

Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks).

This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it.

But I pointed out this isn't true.  Including the transaction increases block size and therefore storage costs, increases time to propagate, and increases the chance of some other relay not liking it.

I'm disagreeing with the fundamental assumption you're making that it's "pure profit".

Also, whatever the costs are to the network, the fact is they're being borne by the network.  If the network can't afford it, the network won't afford it.  I haven't seen a convincing (to me) refutation of these points.  If something isn't worthwhile people won't do it.  If it is, people will.

My gut feeling is that the block size limit should be removed, and let the free market reign.  It works elsewhere, why not for transaction processing?

It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed.

It's not clear to me, as I've tried to explain.  Just like producing widgets - if someone can't do it profitably, that isn't a reason to seek out a central authority (here the arbitrary block size limit) to "solve" the problem (by specifying a minimum price in the case of the widget, or maximum block size for a block).  They just go bust.

This is even the case now - clearly block size is not a constraint at the moment, it might as well be infinite, as most blocks are way below the limit, and not even at the point where the reference client makes it "more expensive" to take up more space.  And yet the network isn't suffering, and also not every transaction is getting accepted in the immediately next block.  Because there are costs, lags, and delays, and that is their way of being expressed.  Some people moan, but they're the ones who will stop trying to do it (including qt client users who aren't adding much to the network).  If the "market" wants those users to keep doing it, the market will pay a higher fee to ensure they find it worthwhile.

Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally.

By hashing, I was talking about the cost of rebuilding and rehashing the merkle tree, not the cost of hashing the block.  Sorry for any confusion; I feel that may have led you to misunderstand my argument.

The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate.

There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet.

I'm not certain an unconstrained block size can work.  But I think it's highly likely it can, and I've not read anything to persuade me otherwise.
If the market wants something (here, more hashing power) it will pay for it, like anything else.

So why not give it a go?  If it's a disaster, there will be no problem getting the 50% consensus to put one back, right?

[Jeweller]

A limit on the data size of a block isn't the only or even the most efficient way to keep demand for transactions high. The marginal cost of handling the tx size is expected to be much lower than the amortized cost of hashing to secure it, so artificial scarcity in the former to sponsor the latter creates perverse incentives.

I agree here: Limiting a block to 1MB feels strange and arbitrary.  More so given that 1MB is pretty much nothing for today's computers, and many times this transaction rate could be supported with no real problems other than removing the block size limit.

This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it. This means epsilon will tend to 0 and total revenue from txs will be equal to the resource cost needed to handle them, leaving no revenue to sponsor the very expensive hashing.

So if I understand what you're saying here, it's that any self-interested solo miner (not a cartel) will include transactions as long as it's profitable for him / her to do so.  Or rather, not unprofitable / loss making.  We see this now; miners include transactions with no fees, with no direct benefit to themselves.  Assuming no block size limit, the negative feedback loop would simply be processing cost to the miner vs. transaction fee, which would tend to make for very cheap transactions.

This is basically how it works now.  C+epsilon for each transaction included, with both C and epsilon equal to 0 in most transactions right now.  Right now what's determining effort into block publishing is the block reward, which overwhelms transaction fees, essentially subsidizing them.

The block reward will become negligible, but that's many years ahead of us.  Long before that, within a year or two, we're likely to start hitting block size limits somewhat regularly, and after that, perhaps constantly.

I'm not certain an unconstrained block size can work.  But I think it's highly likely it can, and I've not read anything to persuade me otherwise.
If the market wants something (here, more hashing power) it will pay for it, like anything else.

So why not give it a go?  If it's a disaster, there will be no problem getting the 50% consensus to put one back, right?

Yeah, why not!
Seriously though I'm inclined to agree here as well -- I bet removing the size limit wouldn't kill bitcoin.  But here's the thing-- while we're debating these issues on bitcointalk.org (and sorry if this is an old / tired debate -- it certainly isn't to me however) people are building new bitcoin businesses and investments and all sorts of stuff.  And the blockchain is growing, and miners are mining, and the average transactions / sec and block size are going up.  If we all came to a unanimous decision about a protocol change, it would still be a big pain to switch / fork.  But since we can't even agree, and developers are saying basically "we'll see what happens", to me that means the 1MB limit is going to be with us for quite a while, for good or bad.

So I'm still trying to figure out myself if "artificially" constrained block sizes is "good" or "bad" for bitcoin.  My feeling is that either with the 1MB limit, or without a hard limit, the system will work, but it will work for somewhat different purposes. 

But would you all agree that regardless of desirability, we will see blocks really hitting that limit hard, and stuff really affected by it, before any protocol change occurs? (If it ever does.)

[nevafuse]

If we all came to a unanimous decision about a protocol change, it would still be a big pain to switch / fork.  But since we can't even agree, and developers are saying basically "we'll see what happens", to me that means the 1MB limit is going to be with us for quite a while, for good or bad.

So I'm still trying to figure out myself if "artificially" constrained block sizes is "good" or "bad" for bitcoin.  My feeling is that either with the 1MB limit, or without a hard limit, the system will work, but it will work for somewhat different purposes. 

But would you all agree that regardless of desirability, we will see blocks really hitting that limit hard, and stuff really affected by it, before any protocol change occurs? (If it ever does.)

I'm not sure if you can really call it a "hard" fork.  Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet.  And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.

Regardless, it isn't really up to the core developers anymore.  The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.  The incentives are there, its just a matter of time.

No doubt in my mind that artificially limiting the block size to increase miner fees will bring great success to the next cryptocurrency that does away with the block size limit.

[gmaxwell]

The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit.

No, they can't. The rules of Bitcoin are not based on voting, only the ordering of transactions is. The only way they could do that is by becoming the effective developers of the Bitcoin software that all the users and merchants, etc use.  As someone who mines a bit myself I _fully_ welcome them to try though! In fact, I'll gladly write the patch for any big miner that wants it.

[jgarzik]

I'm not sure if you can really call it a "hard" fork.  Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet.  And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.

Regardless, it isn't really up to the core developers anymore.  The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.

Wrong.

All bitcoin clients will reject a block above 1MB, regardless of what any miner produces.

Thus, it would take a hard fork to change the maximum block size.

[Meni Rosenfeld]

Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks).

This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it.

But I pointed out this isn't true.  Including the transaction increases block size and therefore storage costs, increases time to propagate, and increases the chance of some other relay not liking it.

I'm disagreeing with the fundamental assumption you're making that it's "pure profit".

This is all supposed to be incorporated in C, the marginal cost per transaction. Some of what you mentioned is a bit abstract so there's room fo debate. But it is still the case that the costs you mentioned relate indirectly to the number of transactions; letting it influence the incentives to hash, which is independent, is neither robust nor efficient.

Also, whatever the costs are to the network, the fact is they're being borne by the network.  If the network can't afford it, the network won't afford it.  I haven't seen a convincing (to me) refutation of these points.  If something isn't worthwhile people won't do it.  If it is, people will.

My gut feeling is that the block size limit should be removed, and let the free market reign.  It works elsewhere, why not for transaction processing?

It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed.

It's not clear to me, as I've tried to explain.  Just like producing widgets - if someone can't do it profitably, that isn't a reason to seek out a central authority (here the arbitrary block size limit) to "solve" the problem (by specifying a minimum price in the case of the widget, or maximum block size for a block).  They just go bust.

Sometimes it works, sometimes not. When incentives are aligned the invisible hand works. But when there's an identifiable systemic reason why some business can't be profitable - and we want these businesses to exist - there is need for some intervention.

This is even the case now - clearly block size is not a constraint at the moment, it might as well be infinite, as most blocks are way below the limit, and not even at the point where the reference client makes it "more expensive" to take up more space.  And yet the network isn't suffering, and also not every transaction is getting accepted in the immediately next block.  Because there are costs, lags, and delays, and that is their way of being expressed.  Some people moan, but they're the ones who will stop trying to do it (including qt client users who aren't adding much to the network).  If the "market" wants those users to keep doing it, the market will pay a higher fee to ensure they find it worthwhile.

The problem of sponsoring hashing hasn't even begun to manifest itself because of the coinbase, which is still more than sufficient for it. And txs are still few enough that the crude anti-spam rules (required fee for low-priority txs) are enough to keep the nodes from overloading.

Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally.

By hashing, I was talking about the cost of rebuilding and rehashing the merkle tree, not the cost of hashing the block.  Sorry for any confusion; I feel that may have led you to misunderstand my argument.

I understood this is what you meant. AFAIK the cost of hashing into the Merkle tree is negligible in comparison to ECDSA verification; and even if not, it's part of what I call marginal cost, as opposed to the amortized cost of hashing block headers.

The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate.

There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet.

I'm not certain an unconstrained block size can work.  But I think it's highly likely it can, and I've not read anything to persuade me otherwise.
If the market wants something (here, more hashing power) it will pay for it, like anything else.

So why not give it a go?  If it's a disaster, there will be no problem getting the 50% consensus to put one back, right?

In most cases gradual changes are healthier. Switching instantly to no-limit and then back to some limit can be disruptive. I think you're too charitable towards the free market, in those situations where it works it works great, but there are situations where it doesn't - or at least, where the free market works only by deciding to constrain itself to be less free.

The study of game theory brings up some examples, especially wherever bargaining is involved.

[dree12]

I'm not sure if you can really call it a "hard" fork.  Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet.  And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.

Regardless, it isn't really up to the core developers anymore.  The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.

Wrong.

All bitcoin clients will reject a block above 1MB, regardless of what any miner produces.

Thus, it would take a hard fork to change the maximum block size.

This makes very little sense. Why not code the limit into miners only, and have the client simply prefer to relay smaller blocks over larger ones?

[gmaxwell]

This makes very little sense. Why not code the limit into miners only, and have the client simply prefer to relay smaller blocks over larger ones?

Because the purpose of Bitcoin is to build a currency that substantially eliminates trust.  If Bitcoin users are forced by technology have to trust miners to do the correct thing— to not inflate the currency, to not destroy its decentralization, etc— then they can be easily disenfranchised. Not only would they be forced to trust (which is against the goals of the system) but without the enforcement by a great many users miners would have reduced incentives to not cheat in the various ways that the enforcement prohibits absolutely. E.g. why not increase the subsidy to 26 BTC? Because it would undermine confidence? pfft. They'd justify it by some argument about lost coins, expanding economy, importance of security and such, just like the inflation producing governements and central banks do. Doing it would benefit all the miners, so why shouldn't they "vote" a raise for themselves? And a little bit of inflation at a time demonstrability doesn't undermine all confidence in a currency.

Of course, you do have the option to trust miners in exchange for a reduced validation cost to you by using a SPV node— but that option is only really viable because the miners are regulated by the many other participants who do verify.

Why have mining at all? Because we can't accomplish a decentralized currency without a way of providing for the ordering of transactions, and we don't know a way to provide ordering without some kind of vote or without centralization. So mining is just an attack resistant way of voting on the order of transactions. But we don't use mining for more than that because voting is not actually a good solution, it requires a kind of trust (though better than centralization)— and so for the non-ordering things that can be validated independently nodes do validate them independently. (Even SPV nodes should and do validate all that they can within the context of their permitted operating cost).

[dree12]

This makes very little sense. Why not code the limit into miners only, and have the client simply prefer to relay smaller blocks over larger ones?

Because the purpose of Bitcoin is to build a currency that substantially eliminates trust.  If Bitcoin users are forced by technology have to trust miners to do the correct thing— to not inflate the currency, to not destroy its decentralization, etc— then they can be easily disenfranchised. Not only would they be forced to trust (which is against the goals of the system) but without the enforcement by a great many users miners would have reduced incentives to not cheat in the various ways that the enforcement prohibits absolutely. E.g. why not increase the subsidy to 26 BTC? Because it would undermine confidence? pfft. They'd justify it by some argument about lost coins, expanding economy, importance of security and such, just like the inflation producing governements and central banks do. Doing it would benefit all the miners, so why shouldn't they "vote" a raise for themselves? And a little bit of inflation at a time demonstrability doesn't undermine all confidence in a currency.

Of course, you do have the option to trust miners in exchange for a reduced validation cost to you by using a SPV node— but that option is only really viable because the miners are regulated by the many other participants who do verify.

Why have mining at all? Because we can't accomplish a decentralized currency without a way of providing for the ordering of transactions, and we don't know a way to provide ordering without some kind of vote or without centralization. So mining is just an attack resistant way of voting on the order of transactions. But we don't use mining for more than that because voting is not actually a good solution, it requires a kind of trust (though better than centralization)— and so for the non-ordering things that can be validated independently nodes do validate them independently. (Even SPV nodes should and do validate all that they can within the context of their permitted operating cost).

I don't see how this applies to block size. Miners do not have a significant benefit in increasing the block size, the only extra power granted to them. And in the case that there is a significant benefit, that probably means blocks are so tightly packed increasing the block size would make sense anyways.

[gmaxwell]

I don't see how this applies to block size. Miners do not have a significant benefit in increasing the block size, the only extra power granted to them.

They would— it would allow them to accept more low fee transactions, thus increasing their fee income in that single block, by making the space non-scarce— though in the long run it will make miners less, at the time of forming a block it would make them more. There would be no rational reason to not gobble up the fees as as fast as you can unless there was cartel behavior to force lower sizes anyways. Maybe the cartel regulating miners would choose better limits, but it would mean that we'd have to trust the cartel to behave wisely rather than a set in stone rule which produces a market for fees by fixing the maximum size.

That is all in regard to why it should work the way it does— the reason it does work the way it does is just a result of the principle of the system. Miners are only depended on for ordering.

[nevafuse]

I'm not sure if you can really call it a "hard" fork.  Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet.  And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.

Regardless, it isn't really up to the core developers anymore.  The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.

Wrong.

All bitcoin clients will reject a block above 1MB, regardless of what any miner produces.

Thus, it would take a hard fork to change the maximum block size.

This makes very little sense. Why not code the limit into miners only, and have the client simply prefer to relay smaller blocks over larger ones?

Miners & clients are the same thing.  Even if you aren't necessarily trying to find the next block, if you are running the client, you are still voting on what blocks are valid & which ones aren't and propagating them appropriately.  The problem isn't that blocks over 1MB would be too large for miners/clients to propagate.  The problem is that they would see the larger blocks as INVALID.

Lets assume 50% of the miners/clients were running bitcoin instances that accepted blocks over 1MB.  It would look like the hashrate dropped in half to both sides.  Basically 2 different versions of bitcoin would exist.  Mtgox, blockchain, slush, deepbit, etc would all have to decide what side to take.  Or they could even fight on both sides.  Technically both could exist indefinitely.  The prices would probably even be different between the two.  Nothing is stopping that from happening...even today.  Same problem happens if advances in quantum computing make people want to use a different encryption method.

[gmaxwell]

Lets assume 50% of the miners/clients were running bitcoin instances that accepted blocks over 1MB.  It would look like the hashrate dropped in half to both sides.

Not quite, the accepting side would still see the mining of the non-accepting side. It's not mutually exclusive.

Basically 2 different versions of bitcoin would exist.  Mtgox, blockchain, slush, deepbit, etc would all have to decide what side to take.  Or they could even fight on both sides.  Technically both could exist indefinitely.

Of course, the value of bitcoin depends on it not biurficating. That would be a maximally bad outcome: basically everyone with funds before the split would double their funds. So thats obviously highly unstable.

Same problem happens if advances in quantum computing make people want to use a different encryption method.

We don't use encryption in bitcoin. Perhaps you meant signatures? We can actually upgrade signature algorithms without a hard fork.

[nevafuse]

Not quite, the accepting side would still see the mining of the non-accepting side. It's not mutually exclusive.

Depends which blockchain is longer, right?  Isn't that the whole point of requiring more than 51% of the hashrate?  If the blockchain with the >1MB blocks is longest, the clients on the accepting side will not see the mining of the non-accepting side because they will be working on a different blockchain.  But if the blockchain with the <=1MB blocks is longest, both clients will see the same thing & be working on the same blockchain.  Hints why it'd make sense to do it now because there aren't any blocks being generated anywhere near the 1MB limit.  So both clients could co-exist for the time being.  There wouldn't be any issue until a >1MB block is generated & accepting nodes own more than 50% of the hashrate.

[dree12]

Not quite, the accepting side would still see the mining of the non-accepting side. It's not mutually exclusive.

Depends which blockchain is longer, right?  Isn't that the whole point of requiring more than 51% of the hashrate?  If the blockchain with the >1MB blocks is longest, the clients on the accepting side will not see the mining of the non-accepting side because they will be working on a different blockchain.  But if the blockchain with the <=1MB blocks is longest, both clients will see the same thing & be working on the same blockchain.  Hints why it'd make sense to do it now because there aren't any blocks being generated anywhere near the 1MB limit.  So both clients could co-exist for the time being.  There wouldn't be any issue until a >1MB block is generated & accepting nodes own more than 50% of the hashrate.

The point is, at 50/50, the non-accepting side will eventually win over because the accepting side still accepts their blocks. At a certain point, their chain will be longer. At 51% or above, the accepting side should eventually carve their own blockchain—but it might take a while.