This is only true if the per transaction fee is not zero.
In absence of a block size limit, there is no incentive to pay fee. Any positive fee would have to be enforced by a cartel of miner.

Unfortunately behaviour that is wrong for the community as a whole can make sense individually and can wreck the entire ecosystem.
Economist call this the "Tragedy of the commons" http://en.wikipedia.org/wiki/Tragedy_of_the_commons

In absence of block size limit individual miner are rational to include every transaction with any greater than zero fee. This however
disables pricing power of miner to the extent that they become unprofitable and go out of business, in effect reducing utility and security for all.


I am not trolling.

You are not neccesarily stupid, but uninformed if you think miner set the rules.

A miner who violates a rule that is enforced by the majority of miner locks himself into an alternate reality (a fork) that no one else cares of.

The majority of miner can enforce new stricter rules than currently in existence, this is called a soft fork. Enforcing a minimal fee by a cartel would be in effect a soft fork.

Not even the majority of miner can introduce a rule that is not a subset of those already in existence, without getting most of ordinary user upgraded.
An increased block size is not subset but extension of the current rule, therefore it falls into this cathegory, also called hard fork.

Bitcoin's value rests on the consensus of its user of the rules. The rules are practically constant as it is very hard to convience all user to upgrade.

In case of block size interest of ordinary user and miner are not aligned. Ordinary user just want lower best zero fee. Miner have to protect pricing power.

You know much less about Bitcoin that you think. I hope you have better things to do.

Miner do not make the rules. They have to obey the rules if in minority or can narrow existing rules if organizing a majority cartel.
The later would be needed to impose a non-zero fee in absence of a size limit in the protocol.

Because majority of miner nowdays use the bitoin core as published by the devs and that compiles blocks following a mix of commercial and alturistic rules.

Majority of miner do not care about this since inflation provides three-four magnitudes higher income than fees at the moment. They will. And this discussion is about the future and the limits.

let me be more precise:
There is a marginal cost implied by block propagation speed being proportional to size and propagation being proportional to orphan rate. There is also a computation cost of updating the merkle tree and updating miner with it. These marginal costs are today however magnitudes below the lowest non-zero fees paid.

He neglects that there is no reason to pay fees, if there is no limit on supply.


Since there is no marginal cost in including a transaction to the current block, a rational miner will always include a transaction with a non zero fee,
before it is included by any of its competitors.

Therefore a lower bound on fee will not work without a cartel or without a competition for space.

I prefer algorithms over cartels.

Microsoft's way to adapt a new technology is to create an incompatible fork of it, with bold promises on top of the existing one.
The tactic proved suitable to make their customer wait for them to catch-up.

Their fork fades out just like memory of their customer, so they can repeat.

You assume that miner can effectively control supply. This in absence of a block size limit is only the case if they are building cartels, that artificially limit the supply.

Is that you really prefer instead of an algorithmic decision?
Remember Bitcoin's promise is to operate without the need of cartels and authorities.

The OP gives a valid technical argument for raising block size limit, but is neglecting a financial argument against it.

The miners' income has to be greater than the cost of their work. Miners' income is inflation now, but is expected to be replaced by fees,
since inflation halves every four years. Purchasing power of new coins might be sustained for a while but must converge to zero in the limit.

Transaction fees exist only because there is a competition for block space. Eliminating that competition eliminates the fees and with that mining.

Therefore block space has to become and remain a scarce asset.

And that is exactly the back end does for you. Please contact SatoshiLabs with the rest.

You might have seen that CoinTerra did not work out as expected. It filed for bankrupcy a few days ago.
CoinTerra's default does not affect Bits of Proof as their option to buy the assets expired unused.

If mining would have provided stable income and growth, as it looked like as I joined them,
then I would have open sourced the plattform to create a standard on a longer run.

I live from Bitcoin software development about two years now.

Without alternate revenue or significant funding, I have to act selfish and short sigthed and protect
my competitive advantage, that enabled me to create products like the Bullion Bitcoin exchange or
myTREZOR back end and undisclosed others.

I am currently working on a side chain with huge business potential. Should the new plan work out,
then I will revisit the idea of open sourcing the stack.

I was remembered to https://bitcointalk.org/index.php?topic=6430.0 where sipa points to a paper desribing how to extract public key from the signature and the signed digest.

Satoshi eliminated every redundant byte in transactions and blocks, think of the compressed encoding of difficulty or the 32 bit date.

Why did he miss this significant opportunity of transaction size reduction?
Was it not known by 2009 or was it not known to him or is there more in this decision ?

I waited some time to be able to claim increased stability too.
There was not a single minute of disruption in service for nearly two weeks now and counting.

The Bits of Proof back end is serving thousands of users, lots simultanously and is retrieveing hundreds of transactions
out of tens of millions in matter of seconds or less with a criteria that is not a simple query but
a scan depending on previous hits.

This is not a negligible accomplishment, best illustrated by the fact that it is not yet matched by any other
implementation, not even for single user use.

I aopologize for any disruption, but have to emphasize that this software had uptimes north of 95%
in its worst weeks and is still improving.

You likely noticed significant improvement of performce while myTREZOR retrieves balances.
The reason is an upgrade of the back end. Have fun.

Depends on your time scale if it's old, it was unfortunatelly true before 0.8.0.  This was the fix for it:

https://github.com/bitcoin/bitcoin/commit/ac7b8ea0864e925b0f5cf487be9acdf4a5d0c487

An implementation forking from the majority view is not an issue for the majority or for the network at a whole.

BUT you personally would not want to be in the minority for any exploitable time period, because that could mean that you accept coins for your goods that are already spent in the majority view.

Your financial loss would be realized and final once you fix your software and return to majority consensus.

Let me guess, they said: Fork off!

Your work there is appretiated, but lets admit further benefits:

1. It is cheaper to learn from mistakes others make
2. Dangers uncovered elsewhere keep the herd together

Those who control the github keys of the most popular fork (bitcoin/bitcoin) determine the code run by the majority, this however is just common sense. Those who achive and maintain consensus and trust of people have power.

Those who know the beast called "Nakamoto consensus" are quick to point out the dangers, that are very real.

You are still free to fork or rewrite for your own benefit or loss. There are safer ways to play that too, keep asking and listening.

Maybe satoshi wanted to exclude the chance that there is a SHA256 ASIC in some drawer. The probability for the existence of a single chip piping through two SHA256s was less likely, so the "one CPU one vote" was more likely at the bootstrap of the currency.