|
|
| Line 1: |
Line 1: |
| What Bitcoin provides is a means to determine what is the consensus version
| | If you have followed a link to this page from reddit or elsewhere, please see for the original document. |
| 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
| | https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332 |
| 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<ref>[https://bitcointalk.org/index.php?topic=157130.0 Decentralised crime fighting using private set intersection protocols]</ref> 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 Block|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.
| |
| | |
| == Inflation Subsidy ==
| |
| | |
| Currently each block [[Controlled_Currency_Supply|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.<ref>[https://bitcointalk.org/index.php?topic=69423.0 Miners that refuse to include transactions are becoming a problem]</ref>
| |
| | |
| 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 or will be.
| |
| | |
| == Transaction Fees ==
| |
| | |
| Transactions may include [[transaction_fees|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 [[Maximum transaction rate|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.
| |
| | |
| === Off-chain Transactions ===
| |
| | |
| 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.
| |
| | |
| == Alternatives ==
| |
| | |
| 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|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.
| |
| | |
| === Individual ===
| |
| | |
| 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
| |
| [http://en.wikipedia.org/wiki/Free_rider_problem free rider problem].
| |
| | |
| === Assurance Contracts ===
| |
| | |
| 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.<ref>http://en.wikipedia.org/wiki/Assurance_contract</ref>
| |
| | |
| 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<ref>[[Contracts#Example_3:_Assurance_contracts]]</ref> - for a
| |
| mining assurance contract the transaction output would be set to either an
| |
| [[Script#Anyone-Can-Spend_Outputs|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.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770]</ref>
| |
| (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.<ref>[https://bitcointalk.org/index.php?topic=157141.msg1822138#msg1822138]</ref>
| |
| | |
| == References ==
| |
| <references/>
| |
| * [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]
| |
| [[Category:Technical]]
| |