133 - feefilter message
BIP: 133 Layer: Peer Services Title: feefilter message Author: Alex Morcos Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133 Status: Draft Type: Standards Track Created: 2016-02-13 License: PD ==Abstract== Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. ==Motivation== The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. However, there are limitations to the effectiveness of these approaches. The reject filter is reset after every block which means transactions that ...
90 - Buried Deployments
BIP: 90 Title: Buried Deployments Author: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD ==Abstract== Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. ==Motivation== BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the following conditions: # 75% rule: If 750 o...