BIPs bitcoin improvement proposals

102 - Block size increase to 2MB

<pre> BIP: 102 Layer: Consensus (hard fork) Title: Block size increase to 2MB Author: Jeff Garzik <jgarzik@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102 Status: Rejected Type: Standards Track Created: 2015-06-23 </pre> ==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 sho...

35 - mempool message

<pre> BIP: 35 Layer: Peer Services Title: mempool message Author: Jeff Garzik <jgarzik@exmulti.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035 Status: Final Type: Standards Track Created: 2012-08-16 </pre> ==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 desireable 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 containin...

100 - Dynamic maximum block size by miner vote

<pre> BIP: 100 Layer: Consensus (hard fork) Title: Dynamic maximum block size by miner vote Author: Jeff Garzik <jgarzik@gmail.com> Tom Harding <tomh@thinlink.com> Dagur Valberg Johannsson <dagurval@pvv.ntnu.no> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 Status: Rejected Type: Standards Track Created: 2015-06-11 License: BSD-2-Clause </pre> ==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 the blocks they creat...

106 - Dynamically Controlled Bitcoin Block Size Max Cap

<pre> BIP: 106 Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty <bitcoin@upalc.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 </pre> ==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 fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth...

101 - Increase maximum block size

<pre> BIP: 101 Layer: Consensus (hard fork) Title: Increase maximum block size Author: Gavin Andresen <gavinandresen@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0101 Status: Withdrawn Type: Standards Track Created: 2015-06-22 </pre> ==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 Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header. The maximum size shall be 8,000,000 bytes at a timestam...

123 - BIP Classification

<pre> BIP: 123 Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive </pre> ==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 GNU 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 implementors a choice of whether to support them. ...