Funding network security
What Bitcoin provides is a means to determine what is the consensus version of the transaction history, with the consensus determined by what a majority of hashing power applied to the proof of work problem by miners accepts as the true history. Since those who own Bitcoins, and who have access to hashing power, are not necessarily the same group there needs to be a mechanism for the former to fund the latter. The risk is that mechanism failing, and the majority of hashing power acting in a way that is against the wishes of the majority of economic interests.
An attacker with a majority of hashing power can either publish blocks they mine as they mine them, or withhold them. The former simply makes it impossible to get transactions confirmed that the attacker does not wish to be confirmed. The latter however can be used to rewrite the blockchain after the fact, causing transactions that appeared to be confirmed to become unconfirmed and vulnerable to reversal. In addition the attacker can exploit Transaction Malleability to make it impossible for those transactions to ever be included in the blockchain again.
The hashing power majority does not need to constitute a single individual or coherent group. For instance the economic majority may see fungibility as important, and thus want to ensure transaction outputs can not be blacklisted to prevent transactions spending them from being confirmed, even if those outputs are known to be involved with illegal activity such as theft or fraud. However the actions of mining pools are usually public knowledge; which blocks they mine is usually published on the pool website. If mining a transaction output known to be involved in illegal activity is made illegal, mining pools may independently seek out sources of information on transaction outputs known to be involved in illegal activity, and prohibit transactions spending those outputs from the blocks they mine, as well as delibrately trying to mine blocks that would orphan blocks with such transactions.
Similarly it could be made illegal to mine a transaction if the identity of the person making the transaction is not known, in conjunction with ways for transactions to make that identity public. Again, even if the economic majority would prefer to be able to make anonymous transactions, the hashing power majority may not want to take that risk.
Conversely the opposite may be true in either example; what "security" is may not always be obvious or easily agreed upon.
Currently each block creates 25 BTC as the block reward; as of April 2013 that inflates the currency supply by about 11% per year, in effect transferring 11% of the value of all the Bitcoins in existence to miners to pay for the security they provide. However, every four years the block reward is decreased by half, thus halving the overall inflation subsidy that pays miners.
The inflation subsidy pays miners directly from Bitcoin as a whole; in effect everyone holding Bitcoins is paying for security directly. However at some point it will become small enough that Bitcoin could be attacked by someone with very little resources. In addition a miner can still collect the inflation subsidy without including any transactions at all in the blocks they mine, an activity that can be seen as an attack.
It is predicted that the inflation subsidy will reach less than 1% of the Bitcoin nominal market cap sometime in 2033. However that figure is subject to the amount of lost coins from the early days of Bitcoin; it is unknown what the market cap of coins with owners able to spend them actually is.
Transactions may include fees which are given to the miner who included the transaction in a block. These fees can range from 0% to 100% of the transaction inputs technically speaking, although what is economically practical is a subset of that.
Fees can align the economic interests of Bitcoin users with the interests of miners. For instance in the above example of anonymous transactions fees can encourage miners to mine anonymous transactions regardless of the legal risk, or to take (possibly expensive) measures to reduce that risk.
The Blocksize Limit
Currently blocks are limited to 1MB in size, and further limited by "gentlemans agreement" in the form of a 500KB default maximum. While miners can choose to mine blocks exceeding the 500KB limit, the 1MB limit is fixed and any block larger than it is invalid; block space is a scarce resource. Provided that the demand for transactions is greater than about seven per second we can expect transaction fees to be greater than the marginal costs required to accept a transaction, thus creating a profit that can be used to fund the operation of hashing power.
If making a transaction becomes too expensive it can become worthwhile to use an off-chain payment system to move the funds instead, either one denominated in Bitcoins, or in a different currency entirely; the availability of off-chain transactions limits the maximum fees that miners can charge, in turn limiting the value of transactions as a way to fund security.
If transaction fees and the inflation subsidy do not pay for adequate security alternatives exist. In particular users who own Bitcoins, yet do not perform transactions, possibly because they are holding onto their Bitcoins as an investment and/or use off-chain transactions, only pay for security through the inflation subsidy.
In addition one approach to the scalability problem posed by the current 1MB blocksize limit is to remove or increase that limit. Without the blocksize limit it is expected that transaction fees will fall to the marginal costs of a transaction, which means that fees will not pay for any security at all.
As individuals Bitcoin owners can fund network security in a variety of ways, including artifical fee-paying transactions, paying abnormally high fees, donating directly to known miners, and operating their own mining equipment. The latter two methods have the advantage that the donator has control over the policy followed by the miner being funded.
However mining is a public good: any individual can also simply hope that others will fund security for them, also known as the free rider problem.
An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.
The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. In Bitcoin the problem is that mining is costly and benefits everyone who owns Bitcoins and/or performs transactions. A mining assurance contract needs to be constructed in such a way that participants agree that if some large amount of funds are commited, those funds will go to mining in some way, with the amount set to be large enough for a sufficiently high percentage of the economic activity of Bitcoin must have participated to avoid the free rider problem.
Bitcoin already supports assurance contracts as a transaction type - for a mining assurance contract the transaction output would be set to either an anyone can spend output, or an address owned by a specific miner. However as-is they have a serious problem: a miner can always collect the funds pledged to date by simply adding a sufficient amount of their own funds to the outstanding contract, and mining that transaction themselves, thus turning the contract into a simple donation. (modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.
With nLockTime a transaction can be created where the miner who will actually collect it is unknown in advance. As the deadline approaches, if the contract is not fully funded, participants double-spend their pledged transaction outputs to invalidate the contract. However this mechanism has the problem that anyone can make the contract fail, even if it is fully funded. That problem can be solved if Bitcoin's scripting language is extended to allow for transaction outputs that can only be spent by transactions following certain forms - the outputs would be locked to the contract until some time after the contract expires.