|
|
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]]
| |