|
|
(4人の利用者による、間の6版が非表示) |
1行目: |
1行目: |
| + | このページではBIP(Bitcoin Improvement Proposal)について説明します。 |
| + | BIPの詳細と作成方法については、[https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki BIP 2]を参照してください。<br> |
| + | wikiページを作成するだけではありません。 |
| <pre> | | <pre> |
− | BIP: 105 | + | BIP:105 |
− | Title: Consensus based block size retargeting algorithm | + | タイトル:コンサスベースのブログサイズリッターゲットアルゴリム |
− | Author: BtcDrak <btcdrak@gmail.com> | + | 著者:BtcDrak <btcdrak@gmail.com> |
− | Status: Draft | + | ステスタス:下書き |
− | Type: Standards Track | + | タイプ:標準トラック |
− | Created: 2015-08-21 | + | 作成日:2015-08-21 |
| </pre> | | </pre> |
| | | |
− | ==Abstract==
| |
| | | |
− | A method of altering the maximum allowed block size of the Bitcoin protocol
| + | このBIPの全文は[[bip-0105.mediawiki]]で読むことができます。 |
− | using a consensus based approach.
| |
− | | |
− | ==Motivation==
| |
− | | |
− | There is a belief that Bitcoin cannot easily respond to raising the
| |
− | blocksize limit if popularity was to suddenly increase due to a mass adoption
| |
− | curve, because co-ordinating a hard fork takes considerable time, and being
| |
− | unable to respond in a timely manner would irreparably harm the credibility of
| |
− | bitcoin.
| |
− | | |
− | Additionally, predetermined block size increases are problematic because they
| |
− | attempt to predict the future, and if too large could have unintended
| |
− | consequences like damaging the possibility for a fee market to develop
| |
− | as block subsidy decreases substantially over the next 9 years; introducing
| |
− | or exacerbating mining attack vectors; or somehow affect the network in unknown
| |
− | or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
| |
− | extensive.
| |
− | | |
− | Dynamic block size adjustments also suffer from the potential to be gamed by the
| |
− | larger hash power.
| |
− | | |
− | Free voting as suggested by BIP100 allows miners to sell their votes out of band
| |
− | at no risk, and enable the sponsor the ability to manipulate the blocksize.
| |
− | It also provides a cost free method or the larger pools to vote in ways to
| |
− | manipulate the blocksize such to disadvantage or attack smaller pools.
| |
− | | |
− | | |
− | ==Rationale==
| |
− | | |
− | By introducing a cost to increase the block size ensures the mining community
| |
− | will collude to increase it only when there is a clear necessity, and reduce it
| |
− | when it is unnecessary. Larger miners cannot force their wishes so easily
| |
− | because not only will they have to pay extra a difficulty target, then can be
| |
− | downvoted at no cost by the objecting hash power.
| |
− | | |
− | Using difficulty as a penalty is better than a fixed cost in bitcoins because it
| |
− | is less predictable.
| |
− | | |
− | In order to prevent miners having complete control over blocksize, an upper
| |
− | limit is required at protocol level. This feature ensures full nodes retain
| |
− | control over consensus, remembering full nodes are the mechanism to keep miners
| |
− | honest.
| |
− | | |
− | | |
− | ==Specification==
| |
− | | |
− | The initial block size limit shall be 1MB.
| |
− | | |
− | Each time a miner creates a block, they may vote to increase or decrease the
| |
− | blocksize by a maximum of 10% of the current block size limit. These votes will
| |
− | be used to recalculate the new block size limit every 2016 blocks.
| |
− | | |
− | Votes are cast using the block's coinbase transaction scriptSig.
| |
− | | |
− | As per BIP34, the coinbase transaction scriptSig starts with a push of the block
| |
− | height. The next push is a little-endian number representing the preferred block
| |
− | size in bytes. For example, 0x4c(OP_PUSHDATA1) 0x03(size of constant) 0x80 0x84 0x1e(2MB)
| |
− | or 0x4c(OP_PUSHDATA1) 0x04(size of constant) 0x80 0x96 0x98 0x00(10MB).
| |
− | | |
− | If a miner votes for an increase, the block hash must meet a difficulty target
| |
− | which is proportionally larger than the standard difficulty target based on the
| |
− | percentage increase they voted for.
| |
− | | |
− | Votes proposing decreasing the block size limit do not need to meet a higher
| |
− | difficulty target.
| |
− | | |
− | Miners can vote for no change by voting for the current block size.
| |
− | | |
− | For blocks to be valid the blockhash must meet the required difficulty target
| |
− | for the vote otherwise the block is invalid and will be rejected.
| |
− | | |
− | Every 2016 blocks, the block size limit will be recalculated by the median of
| |
− | all votes in the last 2016 blocks. This will redefine the block size limit for
| |
− | the next 2016 blocks.
| |
− | | |
− | Blocks that are larger than the calculated base block size limit are invalid and
| |
− | will be rejected.
| |
− | | |
− | The base block size limit may not reduce below 1MB or increase above 8MB.
| |
− | | |
− | | |
− | ==Acknowledgements==
| |
− | | |
− | This proposal is based on ideas and concepts derived from the writings of
| |
− | Meni Rosenfeld and Gregory Maxwell.
| |
− | | |
− | | |
− | ==References==
| |
− | | |
− | [[BIP 0034|BIP34]] | |
− | | |
− | ==Copyright==
| |
− | | |
− | This work is placed in the public domain.
| |
− | | |
− | [[Category:Developer]]
| |
− | [[Category:Technical]]
| |
− | [[Category:BIP|D]]
| |