Add BIP 68: Consensus-enforced transaction replacement signalled via sequence numbers #158

   0 | @@ -0,0 +1,199 @@
   1 | +<pre>
   2 | +  BIP: 68
   3 | +  Title: Consensus-enforced transaction replacement signalled via sequence numbers
   4 | +  Author: Mark Friedenbach <mark@friedenbach.org>
   5 | +  Status: Draft
   6 | +  Type: Standards Track
   7 | +  Created: 28-05-2015

harding commented at 7:10 PM on June 20, 2015:

I think we switched all dates in the BIPs repository to ISO8601 in d83755efa4207, so 2015-05-28 would probably be better.

  11 | +
  12 | +This BIP describes a modification to the consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding output, for the purpose of supporting consensus-enforced transaction replacement features.
  13 | +
  14 | +==Motivation==
  15 | +
  16 | +Bitcoin has sequence number fields for each coin a transaction is spending. The original idea appears to have been that the highest sequence number should dominate and miners should prefer it over lower sequence numbers. This was never really implemented, and the half implemented code seemed to be making this assumption that miners would honestly prefer the higher sequence numbers, even if the lower ones were much much more profitable. That turns out to be a dangerous assumption, and so most technical people have assumed that kind of sequence number mediated replacement was useless, because there was no way to enforce "honest" behaviour, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behaviour on the part of miners.

harding commented at 7:17 PM on June 20, 2015:

for each coin a transaction is spending.

suggest "for each input" (more common terminology among non-core devs, and you use it in the Specification section)

half implemented

probably should be: "half-implemented"

was useless, because

Suggest removing the comma.

  15 | +
  16 | +Bitcoin has sequence number fields for each coin a transaction is spending. The original idea appears to have been that the highest sequence number should dominate and miners should prefer it over lower sequence numbers. This was never really implemented, and the half implemented code seemed to be making this assumption that miners would honestly prefer the higher sequence numbers, even if the lower ones were much much more profitable. That turns out to be a dangerous assumption, and so most technical people have assumed that kind of sequence number mediated replacement was useless, because there was no way to enforce "honest" behaviour, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behaviour on the part of miners.
  17 | +
  18 | +==Specification==
  19 | +
  20 | +The maximum sequence number can be included in any block, like normal. For transactions with an nVersion of 2 or greater, a sequence number of one less than the maximum can only be included in the next block after the input it is spending, rather than it being possible to be included in the same block. A sequence number one less than that can only be included two blocks later, and so on. Alternatively, a sequence number LOCKTIME_THRESHOLD (500,000,000) less than the maximum (0xffffffff - 500,000,000 = 0xe2329aff can only be included in a block with an nTime timestamp at least one second greater than the median time past of the block of the input it is spending. A sequence number one less than that can only be included two seconds later, and so on. This behaviour is only enforced if the most significant bit of the sequence number field is set.

harding commented at 7:39 PM on June 20, 2015:

(0xffffffff - 500,000,000 = 0xe2329aff

Unclosed parens

one second greater than the median time past of the block of the input it is spending.

"median time past" looks like a normal adjective phrase, but it makes no sense in context unless you know that's the name of a Bitcoin Core function. I suggest either placing it in italics to indicate foreign phrasing, using GetMedianTimePast(), or expanding it to describe what GetMedianTimePast() does.

 160 | +
 161 | +==Deployment==
 162 | +
 163 | +We reuse the double-threshold switchover mechanism from BIPs 34 and 66, with the same thresholds, but for nVersion = 4. The new rules are in effect for every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 4, nVersion = 3 blocks become invalid, and all further blocks enforce the new rules.
 164 | +
 165 | +It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, such as BIP 65: OP_CHECKLOCKTIMEVERIFY.

harding commented at 7:55 PM on June 20, 2015:

BIP 65: OP_CHECKLOCKTIMEVERIFY

If you don't mind, could you make this a link? [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki): OP_CHECKLOCKTIMEVERIFY