Gregory: Please assign a BIP # https://github.com/petertodd/bips/blob/bip-full-rbf-deadline/bip-full-rbf-deadline.mediawiki 
  BIP: ??
  Title: Full Replace-by-Fee Deployment Schedule
  Author: Peter Todd 
  Status: Draft
  Type: Standards Track
  Created: 2015-06-29
==Summary== This BIP proposes a deployment schedule for full replace-by-fee (full-RBF) functionality, with an automatic activation of Tuesday April 5th, 2016, at 3pm UTC upon which supporting relay nodes and miners will enable full-RBF mempool behavior on mainnet. Prior to the activation deadline supporting nodes and miners will support first-seen-safe(1) replace-by-fee (FSS-RBF) mempool behavior. ==Motivation== Full-RBF has significant efficiency advantages(2) over alternatives such as FSS-RBF and Child-Pays-For-Parent for a wide variety of common transaction patterns such as fee-bumping and multiple sequential payments, as well as smart contract protocols such as payment channels and auctions. Miner support would let the wider Bitcoin community use the blockchain more efficiently, supporting more transactions per second in less blockchain space. While full-RBF does allow users to "undo" transactions after they have been sent, the ability of decentralized wallets to protect users from double-spends has proven to be near-zero.(3) Centralized services have had some success in doing so, albeit at the cost of having to sybil attack the network, a strategy that cannot scale to more than a small handful of payment processing companies.(3) Even then success is not assured. Worryingly large payment providers have shown willingness(4) to consider extreme measures such as entering into legal contracts directly with large miners to ensure their transactions get mined. This is a significant centralization risk and it is not practical or even possible for small miners to enter into these contracts, leading to a situation where moving your hashing power to a larger pool will result in higher profits from hashing power contracts; if these payment providers secure a majority of hashing power with these contracts inevitably there will be a temptation to kick non-compliant miners off the network entirely with a 51% attack. It does not make sense for the whole Bitcoin community to incur higher transaction costs, sybil attacks, and centralization risk for the sake of a small handful of companies. However an orderly, planned, upgrade is still desirable. ==Implementation== As full-RBF usage patterns, unlike first-seen-dependent zeroconf, does not depend on mempool syncronization this BIP won't specify detailed relay node behavior. However the following implementation is reasonable and well-tested with considerations such as DoS attacks taken into account: https://github.com/bitcoin/bitcoin/pull/6352 To maximize engineer availability the deadline date was chosen to be towards, but not at, the start of the week, and away from any public holidays. 3pm UTC was chosen as a compromise between Pacific West Coast and European timezones; miners in the Asian timezones may choose to manually set their exact switchover date a few hours ahead with little risk to themselves. Nine months into the future was chosen on the basis of allowing time for affected companies to plan for the upgrade, without pushing the upgrade unnecessarily far into the future. ==Credits== Thanks goes to Jeff Garzik for suggesting the idea of a full-RBF deployment deadline. ==References== 1) "First-Seen-Safe Replace-by-Fee", Peter Todd, Bitcoin-development mailing list, May 25th 2015, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html 2) "Cost savings by using replace-by-fee, 30-90%", Peter Todd, Bitcoin-development mailing list, May 25th 2015, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07813.html 3) "F2Pool has enabled full replace-by-fee", Peter Todd, Bitcoin-development mailing list, June 19th 2015, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08422.html 4) "F2Pool has enabled full replace-by-fee", Adrian Macneil, Director of Engineering, Coinbase, Bitcoin-development mailing list, June 19th 2015, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08443.html ==Copyright== This document is placed in the public domain. -- 'peter'[:-1]@petertodd.org 000000000000000002b9facd4d17c9e3f1f494f9336f7dc5dae35d8918852890