102 - Block size increase to 2MB
BIP: 102 source Layer: Consensus (hard fork) Title: Block size increase to 2MB Authors: Jeff Garzik Status: Closed Type: Specification Assigned: 2015-06-23 Table of ContentsAbstractMotivationSpecificationBackward compatibilityDiscussionImplementation Abstract Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB. Motivation Continue current economic policy.Exercise hard fork network upgrade. Specification MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.Increase maximum block sigops by similar factor, preserving SIZE/50 formula.Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support. Backward compatibility Fully validating older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network. Discussion In the short term, an increase is needed to continue to current economic policies...
35 - mempool message
BIP: 35 source Layer: Peer Services Title: mempool message Authors: Jeff Garzik Status: Deployed Type: Specification Assigned: 2012-08-16 Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementation Abstract Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. Motivation Several use cases make it desirable to expose a network node's transaction memory pool: SPV clients, wishing to obtain zero-confirmation transactions sent or received.Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart.Remote network diagnostics. Specification The mempool message is defined as an empty message where pchCommand == "mempool"Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memo...
100 - Dynamic maximum block size by miner vote
BIP: 100 source Layer: Consensus (hard fork) Title: Dynamic maximum block size by miner vote Authors: Jeff Garzik Tom Harding Dagur Valberg Johannsson Status: Closed Type: Specification Assigned: 2015-06-11 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationDynamic Maximum Block SizeSignature Hashing Operations LimitsRecommendationsPublication of hardLimitDeploymentBackward compatibilityImplementationsCopyright Abstract Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting. Motivation Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers. Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide. Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for th...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Authors: Upal Chakraborty Status: Closed Type: Specification Assigned: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fe...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Authors: Eric Lombrozo Status: Deployed Type: Process Assigned: 2015-08-26 License: CC0-1.0 OR FSFAP Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs Abstract This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. Copyright This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and FSF All Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to su...
101 - Increase maximum block size
BIP: 101 source Layer: Consensus (hard fork) Title: Increase maximum block size Authors: Gavin Andresen Status: Closed Type: Specification Assigned: 2015-06-22 Table of ContentsAbstractMotivationSpecificationDeploymentTest networkRationaleObjections to this proposalCentralization of full nodesCentralization of mining: costsCentralization of mining: big-block attacksUnspent Transaction Output GrowthLong-term fee incentivesOther solutions consideredOne-time increaseDynamic limit proposalsCompatibilityImplementation Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. Motivation Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth. Specification After deployment (see the Deploymen...