From be86444b8826a6dcb44602e24ed1d1316204f2a6 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 24 Sep 2015 10:02:51 +0930
Subject: [PATCH 01/28] versionbits: the BIP.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-wuille-todd-maxwell-russell.mediawiki | 162 ++++++++++++++++++++++
 1 file changed, 162 insertions(+)
 create mode 100644 bip-wuille-todd-maxwell-russell.mediawiki

diff --git a/bip-wuille-todd-maxwell-russell.mediawiki b/bip-wuille-todd-maxwell-russell.mediawiki
new file mode 100644
index 00000000..d43157b8
--- /dev/null
+++ b/bip-wuille-todd-maxwell-russell.mediawiki
@@ -0,0 +1,162 @@
+  BIP: ??
+  Title: Version bits with timeout and delay
+  Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au>
+  Status: Draft
+  Type: Informational Track
+  Created: 2015-10-04
+</pre>
+
+==Abstract==
+
+This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
+
+==Motivation==
+
+BIP 34 introduced a mechanism for doing soft-forking changes without predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
+
+In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66, which further removed nVersion = 2 as valid option. As will be shown further, this is unnecessary. 
+
+==Specification==
+
+===Mechanism===
+
+'''Bit flags'''
+We are permitting several independent soft forks to be deployed in parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is not currently in use for any other ongoing soft fork. Miners signal intent to enforce the new rules associated with the proposed soft fork by setting bit 1<sup>B</sup> in nVersion to 1 in their blocks.
+
+'''High bits'''
+The highest 3 bits are set to 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP34 and BIP66. Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible.
+
+'''States'''
+With every softfork proposal we associate a state BState, which begins
+at ''defined'', and can be ''locked-in'', ''activated'',
+or ''failed''.  Transitions are considered after each
+retarget period.
+
+'''Soft Fork Support'''
+Software which supports the change should begin by setting B in all blocks
+mined until it is resolved.
+
+ <nowiki>if (BState == defined) {
+     SetBInBlock();
+ }
+
+'''Success: Lock-in Threshold'''
+If bit B is set in 1916 (1512 on testnet) or
+more of the 2016 blocks within a retarget period, it is considered
+''locked-in''.  Miners should stop setting bit B.
+
+ <nowiki>if (NextBlockHeight % 2016 == 0) {
+    if (BState == defined && Previous2016BlocksCountB() >= 1916) {
+        BState = locked-in;
+        BActiveHeight = NextBlockHeight + 2016;
+    }
+ }
+
+'''Success: Activation Delay'''
+The consensus rules related to ''locked-in'' soft fork will be enforced in
+the second retarget period; ie. there is a one retarget period in
+which the remaining 5% can upgrade.  At the that activation block and
+after, the bit B may be reused for a different soft fork.
+
+ <nowiki>if (BState == locked-in && NextBlockHeight == BActiveHeight) {
+    BState = activated;
+    ApplyRulesForBFromNextBlock();
+    /* B can be reused, immediately */
+ }
+
+'''Failure: Timeout'''
+A soft fork proposal should include a ''timeout''.  This is measured
+as the beginning of a calendar year as per this table (suggested
+three years from drafting the soft fork proposal):
+
+{|
+! Timeout Year
+! >= Seconds
+! Timeout Year
+! >= Seconds
+|-
+|2018
+|1514764800
+|2026
+|1767225600
+|-
+|2019
+|1546300800
+|2027
+|1798761600
+|-
+|2020
+|1577836800
+|2028
+|1830297600
+|-
+|2021
+|1609459200
+|2029
+|1861920000
+|-
+|2022
+|1640995200
+|2030
+|1893456000
+|-
+|2023
+|1672531200
+|2031
+|1924992000
+|-
+|2024
+|1704067200
+|2032
+|1956528000
+|-
+|2025
+|1735689600
+|2033
+|1988150400
+|}
+
+If the soft fork still not ''locked-in'' and the
+GetMedianTimePast() of a block following a retarget period is at or
+past this timeout, miners should cease setting this bit.
+
+ <nowiki>if (NextBlockHeight % 2016 == 0) {
+    if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
+         BState = failed;
+    }
+ }
+
+After another retarget period (to allow detection of buggy miners),
+the bit may be reused.
+
+'''Warning system'''
+To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion.  Whenever lock-in for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork.  It should warn even more loudly after the next retarget period.
+
+'''Forks'''
+It should be noted that the states are maintained along block chain
+branches, but may need recomputation when a reorganization happens.
+
+===Support for future changes===
+
+The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
+
+'''Modified thresholds'''
+The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
+
+'''Conflicting soft forks'''
+At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is a making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
+
+'''Multi-stage soft forks'''
+Soft forks right now are typically treated as booleans: they go from an inactive to an active state in blocks. Perhaps at some point there is demand for a change that has a larger number of stages, with additional validation rules that get enabled one by one. The above mechanism can be adapted to support this, by interpreting a combination of bits as an integer, rather than as isolated bits. The warning system is compatible with this, as (nVersion & ~nExpectedVersion) will always be non-zero for increasing integers.
+
+== Rationale ==
+
+The failure timeout allows eventual reuse of bits even if a soft fork was
+never activated, so it's clear that the new use of the bit refers to a
+new BIP.  It's deliberately very course grained, to take into account
+reasonable development and deployment delays.  There are unlikely to be
+enough failed proposals to cause a bit shortage.
+
+The fallow period at the conclusion of a soft fork attempt allows some
+detection of buggy clients, and allows time for warnings and software
+upgrades for successful soft forks.

From fecfe5bfac1d8a85b6ee9415201573f892b421e2 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 25 Sep 2015 10:57:56 +0930
Subject: [PATCH 02/28] Formatting feedback & copyright from btcdrak.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-wuille-todd-maxwell-russell.mediawiki | 39 +++++++++++++----------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/bip-wuille-todd-maxwell-russell.mediawiki b/bip-wuille-todd-maxwell-russell.mediawiki
index d43157b8..3bb2b9be 100644
--- a/bip-wuille-todd-maxwell-russell.mediawiki
+++ b/bip-wuille-todd-maxwell-russell.mediawiki
@@ -1,3 +1,4 @@
+<pre>
   BIP: ??
   Title: Version bits with timeout and delay
   Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au>
@@ -36,21 +37,21 @@ retarget period.
 Software which supports the change should begin by setting B in all blocks
 mined until it is resolved.
 
- <nowiki>if (BState == defined) {
-     SetBInBlock();
- }
+    if (BState == defined) {
+        SetBInBlock();
+    }
 
 '''Success: Lock-in Threshold'''
 If bit B is set in 1916 (1512 on testnet) or
 more of the 2016 blocks within a retarget period, it is considered
 ''locked-in''.  Miners should stop setting bit B.
 
- <nowiki>if (NextBlockHeight % 2016 == 0) {
-    if (BState == defined && Previous2016BlocksCountB() >= 1916) {
-        BState = locked-in;
-        BActiveHeight = NextBlockHeight + 2016;
+    if (NextBlockHeight % 2016 == 0) {
+        if (BState == defined && Previous2016BlocksCountB() >= 1916) {
+            BState = locked-in;
+            BActiveHeight = NextBlockHeight + 2016;
+        }
     }
- }
 
 '''Success: Activation Delay'''
 The consensus rules related to ''locked-in'' soft fork will be enforced in
@@ -58,11 +59,11 @@ the second retarget period; ie. there is a one retarget period in
 which the remaining 5% can upgrade.  At the that activation block and
 after, the bit B may be reused for a different soft fork.
 
- <nowiki>if (BState == locked-in && NextBlockHeight == BActiveHeight) {
-    BState = activated;
-    ApplyRulesForBFromNextBlock();
-    /* B can be reused, immediately */
- }
+    if (BState == locked-in && NextBlockHeight == BActiveHeight) {
+        BState = activated;
+        ApplyRulesForBFromNextBlock();
+        /* B can be reused, immediately */
+     }
 
 '''Failure: Timeout'''
 A soft fork proposal should include a ''timeout''.  This is measured
@@ -120,11 +121,11 @@ If the soft fork still not ''locked-in'' and the
 GetMedianTimePast() of a block following a retarget period is at or
 past this timeout, miners should cease setting this bit.
 
- <nowiki>if (NextBlockHeight % 2016 == 0) {
-    if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
-         BState = failed;
+    if (NextBlockHeight % 2016 == 0) {
+        if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
+             BState = failed;
+        }
     }
- }
 
 After another retarget period (to allow detection of buggy miners),
 the bit may be reused.
@@ -160,3 +161,7 @@ enough failed proposals to cause a bit shortage.
 The fallow period at the conclusion of a soft fork attempt allows some
 detection of buggy clients, and allows time for warnings and software
 upgrades for successful soft forks.
+
+==Copyright==
+
+This document is placed in the public domain.

From f278c02cbcc18b20d7eb1c68653e4368f3852f5c Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 25 Sep 2015 12:16:11 +0930
Subject: [PATCH 03/28] Bip number assigned: 9.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-wuille-todd-maxwell-russell.mediawiki => bip-0009.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename bip-wuille-todd-maxwell-russell.mediawiki => bip-0009.mediawiki (99%)

diff --git a/bip-wuille-todd-maxwell-russell.mediawiki b/bip-0009.mediawiki
similarity index 99%
rename from bip-wuille-todd-maxwell-russell.mediawiki
rename to bip-0009.mediawiki
index 3bb2b9be..abbcdafb 100644
--- a/bip-wuille-todd-maxwell-russell.mediawiki
+++ b/bip-0009.mediawiki
@@ -1,5 +1,5 @@
 <pre>
-  BIP: ??
+  BIP: 9
   Title: Version bits with timeout and delay
   Author: Pieter Wuille <pieter.wuille@gmail.com>, Peter Todd <pete@petertodd.org>, Greg Maxwell <greg@xiph.org>, Rusty Russell <rusty@rustcorp.com.au>
   Status: Draft

From 602e72125637ed90b75009e10fb5ba8a9cab3198 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sun, 27 Sep 2015 15:22:45 +0930
Subject: [PATCH 04/28] More btcdrak feedback.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-0009.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index abbcdafb..c17ca150 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -9,11 +9,11 @@
 
 ==Abstract==
 
-This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
+This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
 
 ==Motivation==
 
-BIP 34 introduced a mechanism for doing soft-forking changes without predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
+BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
 
 In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 2<sup>31</sup>+2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66, which further removed nVersion = 2 as valid option. As will be shown further, this is unnecessary. 
 
@@ -67,8 +67,8 @@ after, the bit B may be reused for a different soft fork.
 
 '''Failure: Timeout'''
 A soft fork proposal should include a ''timeout''.  This is measured
-as the beginning of a calendar year as per this table (suggested
-three years from drafting the soft fork proposal):
+as the beginning of a calendar year as per this table (suggest
+adding three to the current calendar year when drafting the soft fork proposal):
 
 {|
 ! Timeout Year
@@ -145,7 +145,7 @@ The mechanism described above is very generic, and variations are possible for f
 The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
 
 '''Conflicting soft forks'''
-At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is a making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
+At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
 
 '''Multi-stage soft forks'''
 Soft forks right now are typically treated as booleans: they go from an inactive to an active state in blocks. Perhaps at some point there is demand for a change that has a larger number of stages, with additional validation rules that get enabled one by one. The above mechanism can be adapted to support this, by interpreting a combination of bits as an integer, rather than as isolated bits. The warning system is compatible with this, as (nVersion & ~nExpectedVersion) will always be non-zero for increasing integers.

From 14a73adebf8c8dc832c321f090a6e0fddcbb3a77 Mon Sep 17 00:00:00 2001
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
Date: Tue, 29 Sep 2015 11:24:55 +0200
Subject: [PATCH 05/28] Add BIP0009 to index

---
 README.mediawiki | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 089d9b53..1243d20c 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -19,6 +19,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Active
 |-
+| [[bip-0009.mediawiki|9]]
+| Version bits with timeout and delay
+| Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
+| Informational
+| Draft
+|-
 | [[bip-0010.mediawiki|10]]
 | Multi-Sig Transaction Distribution
 | Alan Reiner

From fd189fdccd7e3c3caef01313df9c36f621af6d04 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 2 Oct 2015 10:50:18 +0930
Subject: [PATCH 06/28] BIP 009: Minor revision to extend bit into lockin
 period.

As discussed here:
	http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011275.html

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-0009.mediawiki | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index c17ca150..b160810f 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -37,14 +37,15 @@ retarget period.
 Software which supports the change should begin by setting B in all blocks
 mined until it is resolved.
 
-    if (BState == defined) {
+    if (BState != activated && BState != failed) {
         SetBInBlock();
     }
 
 '''Success: Lock-in Threshold'''
 If bit B is set in 1916 (1512 on testnet) or
 more of the 2016 blocks within a retarget period, it is considered
-''locked-in''.  Miners should stop setting bit B.
+''locked-in''.  Miners should continue setting bit B, so uptake is
+visible.
 
     if (NextBlockHeight % 2016 == 0) {
         if (BState == defined && Previous2016BlocksCountB() >= 1916) {
@@ -57,7 +58,7 @@ more of the 2016 blocks within a retarget period, it is considered
 The consensus rules related to ''locked-in'' soft fork will be enforced in
 the second retarget period; ie. there is a one retarget period in
 which the remaining 5% can upgrade.  At the that activation block and
-after, the bit B may be reused for a different soft fork.
+after, miners should stop setting bit B, which may be reused for a different soft fork.
 
     if (BState == locked-in && NextBlockHeight == BActiveHeight) {
         BState = activated;

From 5f2c0188be7b25f5c56e39aabd4cc83c5d8b33fc Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 2 Oct 2015 07:36:56 +0000
Subject: [PATCH 07/28] BIP0062: Add a warning about its undeployable status

---
 bip-0062.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index feb4d586..5d46b7c1 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -1,3 +1,5 @@
+'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.'''
+
 <pre>
   BIP: 62
   Title: Dealing with malleability

From b962c479b3276ccb00a6c71d66532c5bdf6bacf8 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sat, 26 Sep 2015 09:54:13 +0100
Subject: [PATCH 08/28] Amend BIP112 to fit BIP68 redefinition

---
 bip-0112.mediawiki | 107 +++++++++++++++++++++++----------------------
 1 file changed, 55 insertions(+), 52 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index c06caf50..ef791b2a 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -18,14 +18,9 @@ being spent.
 
 ==Summary==
 
-CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
-it compares the top item on the stack to the inverse of the nSequence
-field of the transaction input containing the scriptSig. If the
-inverse of nSequence is less than the sequence threshold (1 << 31),
-the transaction version is greater than or equal to 2, and the top
-item on the stack is less than or equal to the inverted nSequence,
-script evaluation continues as though a NOP was executed. Otherwise
-the script fails immediately.
+CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
+compares the top item on the stack to the nSequence field of the transaction
+input containing the scriptSig. **
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
 from being selected for inclusion in a block until the corresponding
@@ -58,13 +53,14 @@ Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
     
-    // Threshold for nLockTime: below this value it is interpreted as block number,
-    // otherwise as UNIX timestamp (already defined in Bitcoin Core).
-    static const unsigned int LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC
+    /* Threshold for nSequence: below this value it is interpreted
+     * as a relative lock-time, otherwise ignored. */
+    static const uint32_t SEQUENCE_LOCKTIME_THRESHOLD = (1 << 31);
     
-    // Threshold for inverted nSequence: below this value it is interpreted
-    // as a relative lock-time, otherwise ignored.
-    static const uint32_t SEQUENCE_THRESHOLD = (1 << 31);
+    /* Threshold for nSequence when interpreted as a relative
+     * lock-time: below this value it has units of blocks, otherwise
+     * seconds. */
+    static const uint32_t SEQUENCE_UNITS_THRESHOLD = (1 << 30);
     
     case OP_NOP3:
     {
@@ -79,75 +75,81 @@ semantics and detailed rationale for those semantics.
         if (stack.size() < 1)
             return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
         
-        // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
-        // accept 5-byte bignums since any value greater than or
-        // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
-        // anyway. This limitation just happens to coincide with
-        // CScriptNum's default 4-byte limit with an explicit sign
-        // bit.
+        // Note that elsewhere numeric opcodes are limited to
+        // operands in the range -2**31+1 to 2**31-1, however it is
+        // legal for opcodes to produce results exceeding that
+        // range. This limitation is implemented by CScriptNum's
+        // default 4-byte limit.
         //
-        // This means there is a maximum relative lock time of 52
-        // years, even though the nSequence field in transactions
-        // themselves is uint32_t and could allow a relative lock
-        // time of up to 120 years.
-        const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
+        // If we kept to that limit we'd have a year 2038 problem,
+        // even though the nLockTime field in transactions
+        // themselves is uint32 which only becomes meaningless
+        // after the year 2106.
+        //
+        // Thus as a special case we tell CScriptNum to accept up
+        // to 5-byte bignums, which are good until 2**39-1, well
+        // beyond the 2**32-1 limit of the nLockTime field itself.
+        const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
         
         // In the rare event that the argument may be < 0 due to
         // some arithmetic being done first, you can always use
         // 0 MAX CHECKSEQUENCEVERIFY.
-        if (nInvSequence < 0)
+        if (nSequence < 0)
             return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
         
-        // Actually compare the specified inverse sequence number
-        // with the input.
-        if (!CheckSequence(nInvSequence))
+        // To provide for future soft-fork extensibility, if the
+        // operand is too large to be treated as a relative lock-
+        // time, CHECKSEQUENCEVERIFY behaves as a NOP.
+        if (nSequence >= SEQUENCE_LOCKTIME_THRESHOLD)
+            break;
+        
+        // Actually compare the specified sequence number with the input.
+        if (!CheckSequence(nSequence))
             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
         
         break;
     }
     
-    bool CheckSequence(const CScriptNum& nInvSequence) const
+    bool CheckSequence(const CScriptNum& nSequence) const
     {
-        int64_t txToInvSequence;
+        // Relative lock times are supported by comparing the passed
+        // in operand to the sequence number of the input.
+        const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;
         
-        // Fail under all circumstances if the transaction's version
-        // number is not set high enough to enable enforced sequence
-        // number rules.
-        if (txTo->nVersion < 2)
+        // Fail if the transaction's version number is not set high
+        // enough to trigger BIP 68 rules.
+        if (static_cast<uint32_t>(txTo->nVersion) < 2)
             return false;
         
-        // Sequence number must be inverted to convert it into a
-        // relative lock-time.
-        txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
-        
-        // Sequence numbers under SEQUENCE_THRESHOLD are not consensus
-        // constrained.
-        if (txToInvSequence >= SEQUENCE_THRESHOLD)
+        // Sequence numbers above SEQUENCE_LOCKTIME_THRESHOLD
+        // are not consensus constrained. Testing that the transaction's
+        // sequence number is not above this threshold prevents
+        // using this property to get around a CHECKSEQUENCEVERIFY
+        // check.
+        if (txToSequence >= SEQUENCE_LOCKTIME_THRESHOLD)
             return false;
         
-        // There are two types of relative lock-time: lock-by-
-        // blockheight and lock-by-blocktime, distinguished by
-        // whether txToInvSequence < LOCKTIME_THRESHOLD.
+        // There are two kinds of nSequence: lock-by-blockheight
+        // and lock-by-blocktime, distinguished by whether
+        // nSequence < nThreshold (SEQUENCE_UNITS_THRESHOLD).
         //
         // We want to compare apples to apples, so fail the script
-        // unless the type of lock-time being tested is the same as
-        // the lock-time in the transaction input.
+        // unless the type of nSequence being tested is the same as
+        // the nSequence in the transaction.
         if (!(
-            (txToInvSequence <  LOCKTIME_THRESHOLD && nInvSequence <  LOCKTIME_THRESHOLD) ||
-            (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >= LOCKTIME_THRESHOLD)
+            (txToSequence <  nThreshold && nSequence <  nThreshold) ||
+            (txToSequence >= nThreshold && nSequence >= nThreshold)
         ))
             return false;
         
         // Now that we know we're comparing apples-to-apples, the
         // comparison is a simple numeric one.
-        if (nInvSequence > txToInvSequence)
+        if (nSequence > txToSequence)
             return false;
         
         return true;
     }
 
-https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
-
 
 ==Example: Escrow with Timeout==
 
@@ -244,3 +246,4 @@ http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
 ==Copyright==
 
 This document is placed in the public domain.
+

From 5273cdc3b902022da35b0e673a87efa820270cd1 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sat, 3 Oct 2015 23:14:20 +0100
Subject: [PATCH 09/28] Add more more example usecases and expand on summary

---
 bip-0112.mediawiki | 55 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index ef791b2a..ae569b68 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -20,7 +20,11 @@ being spent.
 
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
 compares the top item on the stack to the nSequence field of the transaction
-input containing the scriptSig. **
+input containing the scriptSig. If it is greater than or equal to (1 << 31),
+or if the transaction version is greater than or equal to 2, the transaction
+sequence is less than or equal to (1 << 31) and the top stack item is less than
+the transaction sequence, script exection continues as if a NOP was executed,
+otherwise the script fails.
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
 from being selected for inclusion in a block until the corresponding
@@ -131,14 +135,14 @@ semantics and detailed rationale for those semantics.
         
         // There are two kinds of nSequence: lock-by-blockheight
         // and lock-by-blocktime, distinguished by whether
-        // nSequence < nThreshold (SEQUENCE_UNITS_THRESHOLD).
+        // nSequence < SEQUENCE_UNITS_THRESHOLD.
         //
         // We want to compare apples to apples, so fail the script
         // unless the type of nSequence being tested is the same as
         // the nSequence in the transaction.
         if (!(
-            (txToSequence <  nThreshold && nSequence <  nThreshold) ||
-            (txToSequence >= nThreshold && nSequence >= nThreshold)
+            (txToSequence <  SEQUENCE_UNITS_THRESHOLD && nSequence <  SEQUENCE_UNITS_THRESHOLD) ||
+            (txToSequence >= SEQUENCE_UNITS_THRESHOLD && nSequence >= SEQUENCE_UNITS_THRESHOLD)
         ))
             return false;
         
@@ -151,7 +155,9 @@ semantics and detailed rationale for those semantics.
     }
 
 
-==Example: Escrow with Timeout==
+==Examples==
+
+===Escrow with Timeout===
 
 An escrow that times out automatically 30 days after being funded can be
 established in the following way. Alice, Bob and Escrow create a 2-of-3
@@ -173,6 +179,25 @@ The clock does not start ticking until the payment to the escrow address
 confirms. 
 
 
+===Payment Channel Revokation===
+
+Scriptable relative locktime provides a predictable amount of time to respond in
+the event a counterparty broadcasts a revoked transaction: Absolute locktime
+necessitates closing the channel and reopen it when getting close to the timeout,
+whereas with relative locktime, the clock starts ticking the moment the
+transactions confirms in a block. It also provides a means to know exactly how
+long to wait (in number of blocks) before funds can be pulled out of the channel
+in the event of a noncooperative counterparty.
+
+
+===Hash Time-Locked Contracts===
+
+Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
+is required for lightning network payment channels. The scheme requires both
+CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
+revokation.
+
+
 ==Reference Implementation==
 
 A reference implementation is provided in the following git repository:
@@ -224,24 +249,24 @@ BtcDrak authored this BIP document.
 
 ==References==
 
-BIP 68: Consensus-enforced transaction replacement signalled via
-sequence numbers
-https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
+[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68] Consensus-enforced transaction replacement signalled via sequence numbers
 
-BIP 65: OP_CHECKLOCKTIMEVERIFY
-https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
+[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65] OP_CHECKLOCKTIMEVERIFY
 
-BIP 113: Median past block time for time-lock constraints
-https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
+[https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113] Median past block time for time-lock constraints
 
-HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
-revocation hashes
-http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
+[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes]
+
+[http://lightning.network/lightning-network-paper.pdf Lightning Network]
+
+[http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]
 
 [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
 
 [https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
 
+[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
+
 
 ==Copyright==
 

From 4b0c6dc4ad23fce54b75182b43ec314fc8889ef3 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sat, 3 Oct 2015 23:24:17 +0100
Subject: [PATCH 10/28] Move examples under motivation section

---
 bip-0112.mediawiki | 85 +++++++++++++++++++++++-----------------------
 1 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index ae569b68..4773b173 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -50,6 +50,48 @@ minimum time after proof-of-publication. This enables a wide variety
 of applications in phased protocols such as escrow, payment channels,
 or bidirectional pegs.
 
+===Examples===
+
+====Escrow with Timeout====
+
+An escrow that times out automatically 30 days after being funded can be
+established in the following way. Alice, Bob and Escrow create a 2-of-3
+address with the following redeemscript.
+
+    IF
+        2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
+    ELSE
+        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
+        <Alice's pubkey> CHECKSIGVERIFY
+    ENDIF
+
+At any time funds can be spent using signatures from any two of Alice, 
+Bob or the Escrow.
+
+After 30 days Alice can sign alone.
+
+The clock does not start ticking until the payment to the escrow address
+confirms. 
+
+
+====Payment Channel Revokation====
+
+Scriptable relative locktime provides a predictable amount of time to respond in
+the event a counterparty broadcasts a revoked transaction: Absolute locktime
+necessitates closing the channel and reopen it when getting close to the timeout,
+whereas with relative locktime, the clock starts ticking the moment the
+transactions confirms in a block. It also provides a means to know exactly how
+long to wait (in number of blocks) before funds can be pulled out of the channel
+in the event of a noncooperative counterparty.
+
+
+====Hash Time-Locked Contracts====
+
+Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
+is required for lightning network payment channels. The scheme requires both
+CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
+revokation.
+
 
 ==Specification==
 
@@ -155,49 +197,6 @@ semantics and detailed rationale for those semantics.
     }
 
 
-==Examples==
-
-===Escrow with Timeout===
-
-An escrow that times out automatically 30 days after being funded can be
-established in the following way. Alice, Bob and Escrow create a 2-of-3
-address with the following redeemscript.
-
-    IF
-        2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
-    ELSE
-        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
-        <Alice's pubkey> CHECKSIGVERIFY
-    ENDIF
-
-At any time funds can be spent using signatures from any two of Alice, 
-Bob or the Escrow.
-
-After 30 days Alice can sign alone.
-
-The clock does not start ticking until the payment to the escrow address
-confirms. 
-
-
-===Payment Channel Revokation===
-
-Scriptable relative locktime provides a predictable amount of time to respond in
-the event a counterparty broadcasts a revoked transaction: Absolute locktime
-necessitates closing the channel and reopen it when getting close to the timeout,
-whereas with relative locktime, the clock starts ticking the moment the
-transactions confirms in a block. It also provides a means to know exactly how
-long to wait (in number of blocks) before funds can be pulled out of the channel
-in the event of a noncooperative counterparty.
-
-
-===Hash Time-Locked Contracts===
-
-Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
-is required for lightning network payment channels. The scheme requires both
-CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
-revokation.
-
-
 ==Reference Implementation==
 
 A reference implementation is provided in the following git repository:

From 315bd227d717cb57aa42abb14816671bd07bee8f Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sat, 3 Oct 2015 23:26:22 +0100
Subject: [PATCH 11/28] Change deployment to simple ISM

---
 bip-0112.mediawiki | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 4773b173..097a1361 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -207,21 +207,13 @@ https://github.com/maaku/bitcoin/tree/checksequenceverify
 ==Deployment==
 
 We reuse the double-threshold switchover mechanism from BIPs 34 and
-66, with the same thresholds, but for nVersion = 8. The new rules are
-in effect for every block (at height H) with nVersion = 8 and at least
+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 = 8. Furthermore, when 950 out of the 1000 blocks
-preceding a block do have nVersion = 8, nVersion = 3 blocks become
+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.
 
-When assessing the block version as mask of ~0x20000007 must be applied
-to work around the complications caused by
-[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use]
-of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal].
-
-By applying ~0x20000007 with nVersion = 8, the thresholds should be tested
-comparing block nVersion >= 4 as this will save a bit for future use.
-
 It is recommended that this soft-fork deployment trigger include other 
 related proposals for improving Bitcoin's lock-time capabilities, including:
 

From 9c0df8fd0d1b4e9ff94f6e3d8799c69d17473066 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sun, 4 Oct 2015 10:42:51 +0100
Subject: [PATCH 12/28] Add example usecase from Eric Lombrozo and quote from
 Anthony Towns

regarding lightning commitment transactions
---
 bip-0112.mediawiki | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 097a1361..8e0e9f11 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -2,7 +2,8 @@
   BIP: 112
   Title: CHECKSEQUENCEVERIFY
   Authors: BtcDrak <btcdrak@gmail.com>
-           Mark Friedenbach <mark@friedenbach.org>	
+           Mark Friedenbach <mark@friedenbach.org>
+           Eric Lombrozo <Eric Lombrozo>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
@@ -21,9 +22,9 @@ being spent.
 CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
 compares the top item on the stack to the nSequence field of the transaction
 input containing the scriptSig. If it is greater than or equal to (1 << 31),
-or if the transaction version is greater than or equal to 2, the transaction
+or if the transaction version is greater than or equal to 2, the transaction input
 sequence is less than or equal to (1 << 31) and the top stack item is less than
-the transaction sequence, script exection continues as if a NOP was executed,
+the transaction input sequence, script exection continues as if a NOP was executed,
 otherwise the script fails.
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
@@ -92,6 +93,30 @@ is required for lightning network payment channels. The scheme requires both
 CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
 revokation.
 
+In lightning commitment transactions, CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY
+enforce a delay between publishing the commitment transaction, and spending the
+output. The delay is needed so that the counterparty has time to prove the
+commitment was revoked and claim the outputs as a penalty.
+
+
+====Retroactive Invalidation====
+
+In many instances, we would like to create contracts that can be revoked in case
+of some future event. However, given the immutable nature of the blockchain, it
+is practically impossible to retroactively invalidate a previous commitment that
+has already confirmed. The only mechanism we really have for retroactive
+invalidation is blockchain reorganization which, for fundamental security
+reasons, is designed to be very hard and very expensive to deliberately pull off.
+
+Despite this limitation, we do have a way to provide something fairly similar
+using CHECKSEQUENCEVERIFY by constructing scripts with multiple branches of
+execution where one or more of the branches are delayed. That's to say, a
+delayed branch cannot execute until a certain amount of time has passed since
+the transaction containing the script (or a hash of it) confirmed. This provides
+a time window in which someone can supply an invalidation condition which spends
+the output, effectively invalidating the contract and potentially discouraging
+another party from broadcasting the transaction in the first place.
+
 
 ==Specification==
 
@@ -237,6 +262,8 @@ done by Peter Todd for the closely related BIP 65.
 
 BtcDrak authored this BIP document.
 
+Thanks to Eric Lombrozo help with example usecases.
+
 
 ==References==
 
@@ -259,6 +286,8 @@ BtcDrak authored this BIP document.
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
 
 
+
+
 ==Copyright==
 
 This document is placed in the public domain.

From e2d6ffbadd36db4395e29fea61804fd8fc945c16 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sun, 4 Oct 2015 03:51:17 -0700
Subject: [PATCH 13/28] Added "Contracts With Invalidation Deadline" and
 "Retroactive Invalidation" sections under examples.

---
 bip-0112.mediawiki | 54 +++++++++++++++++++++++++++++-----------------
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 8e0e9f11..0ecd77ca 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -3,7 +3,7 @@
   Title: CHECKSEQUENCEVERIFY
   Authors: BtcDrak <btcdrak@gmail.com>
            Mark Friedenbach <mark@friedenbach.org>
-           Eric Lombrozo <Eric Lombrozo>
+           Eric Lombrozo <elombrozo@gmail.com>
   Status: Draft
   Type: Standards Track
   Created: 2015-08-10
@@ -53,7 +53,10 @@ or bidirectional pegs.
 
 ===Examples===
 
-====Escrow with Timeout====
+
+====Contracts With Expiration Deadlines====
+
+=====Escrow with Timeout=====
 
 An escrow that times out automatically 30 days after being funded can be
 established in the following way. Alice, Bob and Escrow create a 2-of-3
@@ -75,7 +78,28 @@ The clock does not start ticking until the payment to the escrow address
 confirms. 
 
 
-====Payment Channel Revokation====
+====Retroactive Invalidation====
+
+In many instances, we would like to create contracts that can be revoked in case
+of some future event. However, given the immutable nature of the blockchain, it
+is practically impossible to retroactively invalidate a previous commitment that
+has already confirmed. The only mechanism we really have for retroactive
+invalidation is blockchain reorganization which, for fundamental security
+reasons, is designed to be very hard and very expensive to deliberately pull off.
+
+Despite this limitation, we do have a way to provide something functionally similar
+using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of
+execution where one or more of the branches are delayed we provide
+a time window in which someone can supply an invalidation condition that allows the
+output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging
+another party from broadcasting the transaction in the first place. If the invalidation
+condition does not occur before the timeout, the delayed branch becomes spendable,
+honoring the original contract.
+
+Some more specific applications of this  idea:
+
+
+=====Payment Channel Revokation=====
 
 Scriptable relative locktime provides a predictable amount of time to respond in
 the event a counterparty broadcasts a revoked transaction: Absolute locktime
@@ -86,7 +110,7 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-====Hash Time-Locked Contracts====
+=====Hash Time-Locked Contracts=====
 
 Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
 is required for lightning network payment channels. The scheme requires both
@@ -99,23 +123,13 @@ output. The delay is needed so that the counterparty has time to prove the
 commitment was revoked and claim the outputs as a penalty.
 
 
-====Retroactive Invalidation====
+=====2-Way Pegged Sidechains=====
 
-In many instances, we would like to create contracts that can be revoked in case
-of some future event. However, given the immutable nature of the blockchain, it
-is practically impossible to retroactively invalidate a previous commitment that
-has already confirmed. The only mechanism we really have for retroactive
-invalidation is blockchain reorganization which, for fundamental security
-reasons, is designed to be very hard and very expensive to deliberately pull off.
-
-Despite this limitation, we do have a way to provide something fairly similar
-using CHECKSEQUENCEVERIFY by constructing scripts with multiple branches of
-execution where one or more of the branches are delayed. That's to say, a
-delayed branch cannot execute until a certain amount of time has passed since
-the transaction containing the script (or a hash of it) confirmed. This provides
-a time window in which someone can supply an invalidation condition which spends
-the output, effectively invalidating the contract and potentially discouraging
-another party from broadcasting the transaction in the first place.
+    OP_IF
+        lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY
+    OP_ELSE
+        withdrawLockTime OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 p2shWithdrawDest OP_EQUAL
+    OP_ENDIF
 
 
 ==Specification==

From 39c269cb0de9fdf89e7959a3fde104a6268f114f Mon Sep 17 00:00:00 2001
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sun, 4 Oct 2015 04:43:25 -0700
Subject: [PATCH 14/28] Typo fix

---
 bip-0112.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 0ecd77ca..c92fbe02 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -99,7 +99,7 @@ honoring the original contract.
 Some more specific applications of this  idea:
 
 
-=====Payment Channel Revokation=====
+=====Payment Channel Revocation=====
 
 Scriptable relative locktime provides a predictable amount of time to respond in
 the event a counterparty broadcasts a revoked transaction: Absolute locktime

From bb6869a336e63d4720d59da833666e11447a3cef Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sun, 4 Oct 2015 15:21:03 +0100
Subject: [PATCH 15/28] Add section on lightning network examples written by
 Anthony Towns

---
 bip-0112.mediawiki | 118 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 105 insertions(+), 13 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index c92fbe02..dcd92373 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -96,7 +96,7 @@ another party from broadcasting the transaction in the first place. If the inval
 condition does not occur before the timeout, the delayed branch becomes spendable,
 honoring the original contract.
 
-Some more specific applications of this  idea:
+Some more specific applications of this idea:
 
 
 =====Payment Channel Revocation=====
@@ -110,17 +110,109 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-=====Hash Time-Locked Contracts=====
+=====Bidirectional Payment Channels=====
 
-Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
-is required for lightning network payment channels. The scheme requires both
-CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
-revokation.
+The lightning network proposes bidirectional two-party payment channels
+(between Alice and Bob) that would benefit from CHECKSEQUENCEVERIFY.
 
-In lightning commitment transactions, CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY
-enforce a delay between publishing the commitment transaction, and spending the
-output. The delay is needed so that the counterparty has time to prove the
-commitment was revoked and claim the outputs as a penalty.
+These channels are based on an anchor transaction that requires a 2-of-2
+multisig from Alice and Bob, and a series of revocable commitment
+transactions that spend the anchor transaction.  The commitment
+transaction splits the funds from the anchor between Alice and Bob and
+the latest commitment transaction may be published by either party at
+any time, finalising the channel.
+
+Ideally then, a revoked commitment transaction would never be able to
+be successfully spent; and the latest commitment transaction would be
+able to be spent very quickly.
+
+To allow a commitment transaction to be effectively revoked, Alice
+and Bob have slightly different versions of the latest commitment
+transaction. In Alice's version, any outputs in the commitment
+transaction that pay Alice also include a forced delay, and an
+alternative branch that allows Bob to spend the output if he knows that
+transaction's revocation code. In Bob's version, payments to Bob are
+similarly encumbered. When Alice and Bob negotiate new balances and
+new commitment transactions, they also reveal the old revocation code,
+thus committing to not relaying the old transaction.
+
+A simple output, paying to Alice might then look like:
+
+    OP_HASH160 <revokehash> OP_EQUAL
+    OP_IF
+        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        24h OP_CHECKSEQUENCEVERIFY
+        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+    OP_ENDIF
+
+This allows Alice to publish the latest commitment transaction at any
+time and spend the funds after 24 hours, but also ensures that if Alice
+relays a revoked transaction, that Bob has 24 hours to claim the funds.
+
+With CHECKLOCKTIMEVERIFY, this would look like:
+
+    OP_HASH160 <revokehash> OP_EQUAL
+    OP_IF
+        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        2015/12/15 OP_CHECKLOCKTIMEVERIFY
+        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+    OP_ENDIF
+
+This form of transaction would mean that if the anchor is unspent on
+2015/12/16, Alice can use this commitment even if it has been revoked,
+simply by spending it immediately, giving no time for Bob to claim it.
+
+Ths means that the channel has a deadline that cannot be pushed
+back without hitting the blockchain; and also that funds may not be
+available until the deadline is hit. CHECKSEQUENCEVERIFY allows you
+to avoid making that tradeoff.
+
+Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated,
+since in principle they may pay either Alice or Bob, depending on whether
+Alice discovers a secret R, or a timeout is reached, but the same principle
+applies -- the branch paying Alice in Alice's commitment transaction gets a
+delay, and the entire output can be claimed by the other party if the
+revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
+Alice might look like the following in Alice's commitment transaction:
+
+    OP_HASH160 OP_DUP <revokehash> OP_EQUAL
+    OP_IF
+        OP_DROP OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+    OP_ELSE
+        <R hash> OP_EQUAL
+        OP_IF
+            "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
+            OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+        OP_ELSE
+            "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
+            OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+        OP_ENDIF
+    OP_ENDIF
+
+and correspondingly in Bob's commitment transaction:
+
+   OP_HASH160 OP_DUP <revokehash> OP_EQUAL
+   OP_IF
+       OP_DROP OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+   OP_ELSE
+       <R hash> OP_EQUAL
+       OP_IF
+           OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
+       OP_ELSE
+           "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
+           "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
+           OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
+       OP_ENDIF
+   OP_ENDIF
+
+Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
+final branch of above to ensure Bob cannot spend the output until after both
+the timeout is complete and Alice has had time to reveal the revocation
+secret.
+
+See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper.
 
 
 =====2-Way Pegged Sidechains=====
@@ -276,7 +368,7 @@ done by Peter Todd for the closely related BIP 65.
 
 BtcDrak authored this BIP document.
 
-Thanks to Eric Lombrozo help with example usecases.
+Thanks to Eric Lombrozo and Anthony Towns for contributing example usecases.
 
 
 ==References==
@@ -291,6 +383,8 @@ Thanks to Eric Lombrozo help with example usecases.
 
 [http://lightning.network/lightning-network-paper.pdf Lightning Network]
 
+[https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning]
+
 [http://diyhpl.us/diyhpluswiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/ Scaling Bitcoin to Billions of Transactions Per Day]
 
 [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
@@ -300,8 +394,6 @@ Thanks to Eric Lombrozo help with example usecases.
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Jeremy Spilman Micropayment Channels]
 
 
-
-
 ==Copyright==
 
 This document is placed in the public domain.

From d80b70554399e1f5125773466bb276224bc0b295 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Sun, 4 Oct 2015 07:55:20 -0700
Subject: [PATCH 16/28] Split section

---
 bip-0112.mediawiki | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index dcd92373..eefd6273 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -98,8 +98,11 @@ honoring the original contract.
 
 Some more specific applications of this idea:
 
+=====Hash Time-Locked Contracts=====
 
-=====Payment Channel Revocation=====
+Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead.
+
+=====Bidirectional Payment Channels=====
 
 Scriptable relative locktime provides a predictable amount of time to respond in
 the event a counterparty broadcasts a revoked transaction: Absolute locktime
@@ -110,10 +113,9 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-=====Bidirectional Payment Channels=====
+=====Lightning Network=====
 
-The lightning network proposes bidirectional two-party payment channels
-(between Alice and Bob) that would benefit from CHECKSEQUENCEVERIFY.
+The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.
 
 These channels are based on an anchor transaction that requires a 2-of-2
 multisig from Alice and Bob, and a series of revocable commitment

From 748f33ccfb88f904287a076abffc6469bc097995 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sun, 4 Oct 2015 19:23:12 +0100
Subject: [PATCH 17/28] Better formatting

---
 bip-0112.mediawiki | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index eefd6273..425c966f 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -51,12 +51,10 @@ minimum time after proof-of-publication. This enables a wide variety
 of applications in phased protocols such as escrow, payment channels,
 or bidirectional pegs.
 
-===Examples===
 
+===Contracts With Expiration Deadlines===
 
-====Contracts With Expiration Deadlines====
-
-=====Escrow with Timeout=====
+====Escrow with Timeout====
 
 An escrow that times out automatically 30 days after being funded can be
 established in the following way. Alice, Bob and Escrow create a 2-of-3
@@ -78,7 +76,7 @@ The clock does not start ticking until the payment to the escrow address
 confirms. 
 
 
-====Retroactive Invalidation====
+===Retroactive Invalidation===
 
 In many instances, we would like to create contracts that can be revoked in case
 of some future event. However, given the immutable nature of the blockchain, it
@@ -98,11 +96,11 @@ honoring the original contract.
 
 Some more specific applications of this idea:
 
-=====Hash Time-Locked Contracts=====
+====Hash Time-Locked Contracts====
 
 Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead.
 
-=====Bidirectional Payment Channels=====
+====Bidirectional Payment Channels====
 
 Scriptable relative locktime provides a predictable amount of time to respond in
 the event a counterparty broadcasts a revoked transaction: Absolute locktime
@@ -113,7 +111,7 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-=====Lightning Network=====
+====Lightning Network====
 
 The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.
 
@@ -217,7 +215,7 @@ secret.
 See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper.
 
 
-=====2-Way Pegged Sidechains=====
+====2-Way Pegged Sidechains====
 
     OP_IF
         lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY

From ec540ce6ed00d6bb8a266474ba6d6099db5cbdba Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 15:30:35 -0700
Subject: [PATCH 18/28] Clarify specificaiton of change in consensus behavior,
 based on feedback received.

---
 bip-0068.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index e336765a..28df807b 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -13,15 +13,15 @@ This BIP describes a modification to the consensus-enforced semantics of the seq
 
 ==Motivation==
 
-Bitcoin has sequence number fields for each input of a transaction. 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" behavior, 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 behavior on the part of miners.
+Bitcoin has sequence number fields for each input of a transaction. 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 an 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" behavior, 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 behavior on the part of miners.
 
 ==Specification==
 
 For transactions with an nVersion of 2 or greater, if the most significant bit (1 << 31) of a sequence number is clear, the remaining 31 bits are interpreted as an encoded relative lock-time. A sequence number with the most significant bit set is given no consensus meaning and can be included in any block, like normal, under all circumstances.
 
-If the second most significant bit (1 << 30) is clear, the remaining bits reduced by 2^14 are interpreted as a minimum block-heigh constraint over the input's age. A sequence number of zero indicates a relative lock-time of zero blocks (bits 31 and 30 clear) and can be included in any block. A sequence number of 1 << 14 can be included in the next block after the input it is spending, or any block thereafter, rather than it being possible to be included in the same block. A sequence number of 2 << 14 can't be included until two blocks later, and so on.
+If the second most significant bit (1 << 30) is clear, the next 16 bits are interpreted as a minimum block-height constraint over the input's age. The remaining 14 bits have no consensus-enforced meaning. A sequence number of zero indicates a relative lock-time of zero blocks (bits 31 and 30 clear) and can be included in any block. A sequence number of 1 << 14 can be included in the next block after the input it is spending, or any block thereafter, but cannot be included in the same block as its parent. A sequence number of 2 << 14 can't be included until at least two blocks later, and so on.
 
-Alternatively, if the second most significant bit (1 << 30) is set, the remaining bits reduced by 2^5 are interpreted as a minimum block-time constraint over the input's age. A sequence number with just that second most significant bit set (0x40000000) is interpreted as a relative lock-time of 0, measured in seconds, and can be included in the same block as the output being spent. Advancing that sequence number by 2^5 (0x40000020) constrains the transaction to be included in blocks with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. Advancing the sequence number by an additional 2^5 (0x40000040) constrains the spend to be two seconds later, and so on.
+Alternatively, if the second most significant bit (1 << 30) is set, the next 25 bits are interpreted as a minimum block-time constraint over the input's age. The remaining 5 bits have no consensus-enforced meaning. A sequence number with just that second most significant bit set (0x40000000) is interpreted as a relative lock-time of 0, measured in seconds, and can be included in the same block as the output being spent. Advancing that sequence number by 2^5 (0x40000020) constrains the transaction to be included in blocks with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. Advancing the sequence number by an additional 2^5 (0x40000040) constrains the spend to be two seconds later, and so on.
 
 This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing consensus and non-consensus code functions that return true if a transaction's lock-time constraints are satisfied and false otherwise, with LockTime() and CheckLockTime(), new functions that return a non-zero value if a transaction's lock-time or sequence number constraints are not satisfied and zero otherwise:
 

From 1ed68dc60527fab374057039803a5f8f9a7648f3 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 15:37:23 -0700
Subject: [PATCH 19/28] Update code to match current pull request.

---
 bip-0068.mediawiki | 71 +++++++++++++++++++++++++++++++++-------------
 1 file changed, 52 insertions(+), 19 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 28df807b..89cb27aa 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -52,7 +52,7 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
     {
         CCoins coins;
     
-        bool fEnforceBIP68 = tx.nVersion >= 2
+        bool fEnforceBIP68 = static_cast<uint32_t>(tx.nVersion) >= 2
                           && flags & LOCKTIME_VERIFY_SEQUENCE;
     
         // Will be set to the equivalent height- and time-based nLockTime
@@ -72,8 +72,9 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
                 fFinalized = false;
     
             // Do not enforce sequence numbers as a relative lock time
-            // unless we have been instructed to.
-            if (!fEnforceBIP68)
+            // unless we have been instructed to, and a view has been
+            // provided.
+            if (!(fEnforceBIP68 && pCoinsView))
                 continue;
     
             // Sequence numbers equal to or above the locktime threshold
@@ -82,31 +83,62 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
             if (txin.nSequence >= CTxIn::SEQUENCE_LOCKTIME_THRESHOLD)
                 continue;
     
-            // Skip this input if it is not in the UTXO set. Aside from
-            // the coinbase input, this should only ever happen in non-
-            // consensus code.
-            if (!pCoinsView->GetCoins(txin.prevout.hash, coins))
-                continue;
+            // Fetch the UTXO corresponding to this input.
+            if (!pCoinsView->GetCoins(txin.prevout.hash, coins)) {
+                // It is fully expected that coinbases inputs are not
+                // found in the UTXO set. Proceed to the next intput...
+                if (txin.prevout.IsNull())
+                    continue;
+                // If a non-coinbase input cannot be found, we cannot
+                // be certain about whether lock-time constraints have
+                // been satisfied. Note that it should only ever be
+                // possible for this to happen with wallet transactions
+                // that have unknown inputs.
+                else
+                    return std::numeric_limits<int64_t>::max();
+            }
     
-            if (txin.nSequence < CTxIn::SEQUENCE_UNITS_THRESHOLD)
+            // coins.nHeight is MEMPOOL_HEIGHT (an absurdly high value)
+            // if the parent transaction was from the mempool. We can't
+            // know what height it will have once confirmed, but we
+            // assume it makes it in the same block.
+            int nCoinHeight = std::min(coins.nHeight, nBlockHeight);
+    
+            if (txin.nSequence < CTxIn::SEQUENCE_UNITS_THRESHOLD) {
                 // We subtract 1 from relative lock-times because a lock-
                 // time of 0 has the semantics of "same block," so a lock-
                 // time of 1 should mean "next block," but nLockTime has
                 // the semantics of "last invalid block height."
-                nMinHeight = std::max(nMinHeight,
-                      coins.nHeight
-                    + (int)(txin.nSequence >> CTxIn::SEQUENCE_BLOCKS_OFFSET)
-                    - 1);
-            else
+                nMinHeight = std::max(nMinHeight, nCoinHeight + (int)(
+                    txin.nSequence >> CTxIn::SEQUENCE_BLOCKS_OFFSET) - 1);
+            } else {
+                // In two locations that follow we make reference to
+                // chainActive.Tip(). To prevent a race condition, we
+                // store a reference to the current tip.
+                //
+                // Note that it is not guaranteed that indexBestBlock will
+                // be consistent with the passed in view. The proper thing
+                // to do is to have the view return time information about
+                // UTXOs.
+                const CBlockIndex& indexBestBlock = *chainActive.Tip();
+    
+                // The only time the negative branch of this conditional
+                // is executed is when the prior output was taken from the
+                // mempool, in which case we assume it makes it into the
+                // same block (see above).
+                int64_t nCoinTime = (nCoinHeight <= (indexBestBlock.nHeight+1))
+                                  ? indexBestBlock.GetAncestor(nCoinHeight-1)->GetMedianTimePast()
+                                  : nBlockTime;
+
                 // Time-based relative lock-times are measured from the
                 // smallest allowed timestamp of the block containing the
                 // txout being spent, which is the median time past of the
                 // block prior. We subtract one for the same reason as
                 // above.
-                nMinTime = std::max(nMinTime,
-                      pindexBestHeader->GetAncestor(coins.nHeight-1)->GetMedianTimePast()
-                    + (int64_t)((txin.nSequence ^ CTxIn::SEQUENCE_UNITS_THRESHOLD) >> CTxIn::SEQUENCE_SECONDS_OFFSET)
-                    - 1);
+                nMinTime = std::max(nMinTime, nCoinTime + (int64_t)((
+                    txin.nSequence - CTxIn::SEQUENCE_UNITS_THRESHOLD)
+                    >> CTxIn::SEQUENCE_SECONDS_OFFSET) - 1);
+            }
         }
     
         // If all sequence numbers are CTxIn::SEQUENCE_FINAL, the
@@ -137,7 +169,8 @@ This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(),
         flags = std::max(flags, 0);
     
         // pcoinsTip contains the UTXO set for chainActive.Tip()
-        const CCoinsView *pCoinsView = pcoinsTip;
+        CCoinsViewMemPool viewMemPool(pcoinsTip, mempool);
+        const CCoinsView *pCoinsView = &viewMemPool;
     
         // CheckLockTime() uses chainActive.Height()+1 to evaluate
         // nLockTime because when LockTime() is called within

From 9a7dafd2763211eaa195aab368710be701c1af68 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 15:38:06 -0700
Subject: [PATCH 20/28] Change git repo to the official pull request.

---
 bip-0068.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 89cb27aa..12b97c78 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -207,9 +207,9 @@ Alice and Bob continue to make payments to each other, decrementing the relative
 
 ==Implementation==
 
-A reference implementation is provided in the following git repository:
+A reference implementation is provided by the following pull request
 
-https://github.com/maaku/bitcoin/tree/sequencenumbers
+https://github.com/bitcoin/bitcoin/pull/6312
 
 ==Acknowledgments==
 

From 88507b49da209f886212e9237d0ec50e23216a71 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 16:37:54 -0700
Subject: [PATCH 21/28] Clarify some sections of text based on feedback, and
 convert to consistent styling for script examples.

---
 bip-0112.mediawiki | 127 ++++++++++++++++++++++-----------------------
 1 file changed, 63 insertions(+), 64 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 425c966f..f353019a 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -19,13 +19,15 @@ being spent.
 
 ==Summary==
 
-CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed it
-compares the top item on the stack to the nSequence field of the transaction
-input containing the scriptSig. If it is greater than or equal to (1 << 31),
-or if the transaction version is greater than or equal to 2, the transaction input
-sequence is less than or equal to (1 << 31) and the top stack item is less than
-the transaction input sequence, script exection continues as if a NOP was executed,
-otherwise the script fails.
+CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode.
+When executed, the script interpreter continues as if a NOP was executed
+so long as one of the following conditions is met:
+
+  * the transaction's nVersion field is 0 or 1;
+  * the top item on the stack is a value greater than or equal to (1 << 31); or
+  * the top item on the stack and the transaction input's sequence number are both relative lock-times of the same units, and the relative lock-time represented by the sequence number is greater than or equal to the relative lock-time represented by the top item on the stack.
+
+Otherwise, script execution terminates with an error.
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
 from being selected for inclusion in a block until the corresponding
@@ -63,7 +65,7 @@ address with the following redeemscript.
     IF
         2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
     ELSE
-        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
+        "30d" CHECKSEQUENCEVERIFY DROP
         <Alice's pubkey> CHECKSIGVERIFY
     ENDIF
 
@@ -98,7 +100,7 @@ Some more specific applications of this idea:
 
 ====Hash Time-Locked Contracts====
 
-Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead.
+Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway must be used instead.
 
 ====Bidirectional Payment Channels====
 
@@ -138,13 +140,13 @@ thus committing to not relaying the old transaction.
 
 A simple output, paying to Alice might then look like:
 
-    OP_HASH160 <revokehash> OP_EQUAL
-    OP_IF
-        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
-    OP_ELSE
-        24h OP_CHECKSEQUENCEVERIFY
-        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
-    OP_ENDIF
+    HASH160 <revokehash> EQUAL
+    IF
+        DUP HASH160 <Bob key hash> CHECKSIGVERIFY
+    ELSE
+        "24h" CHECKSEQUENCEVERIFY
+        DUP HASH160 <Alice key hash> CHECKSIGVERIFY
+    ENDIF
 
 This allows Alice to publish the latest commitment transaction at any
 time and spend the funds after 24 hours, but also ensures that if Alice
@@ -152,13 +154,13 @@ relays a revoked transaction, that Bob has 24 hours to claim the funds.
 
 With CHECKLOCKTIMEVERIFY, this would look like:
 
-    OP_HASH160 <revokehash> OP_EQUAL
-    OP_IF
-        OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
-    OP_ELSE
-        2015/12/15 OP_CHECKLOCKTIMEVERIFY
-        OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
-    OP_ENDIF
+    HASH160 <revokehash> EQUAL
+    IF
+        DUP HASH160 <Bob key hash> CHECKSIGVERIFY
+    ELSE
+        "2015/12/15" CHECKLOCKTIMEVERIFY
+        DUP HASH160 <Alice key hash> CHECKSIGVERIFY
+    ENDIF
 
 This form of transaction would mean that if the anchor is unspent on
 2015/12/16, Alice can use this commitment even if it has been revoked,
@@ -167,7 +169,7 @@ simply by spending it immediately, giving no time for Bob to claim it.
 Ths means that the channel has a deadline that cannot be pushed
 back without hitting the blockchain; and also that funds may not be
 available until the deadline is hit. CHECKSEQUENCEVERIFY allows you
-to avoid making that tradeoff.
+to avoid making such a tradeoff.
 
 Hashed Time-Lock Contracts (HTLCs) make this slightly more complicated,
 since in principle they may pay either Alice or Bob, depending on whether
@@ -177,35 +179,35 @@ delay, and the entire output can be claimed by the other party if the
 revocation secret is known. With CHECKSEQUENCEVERIFY, a HTLC payable to
 Alice might look like the following in Alice's commitment transaction:
 
-    OP_HASH160 OP_DUP <revokehash> OP_EQUAL
-    OP_IF
-        OP_DROP OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
-    OP_ELSE
-        <R hash> OP_EQUAL
-        OP_IF
-            "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
-            OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
-        OP_ELSE
-            "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
-            OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
-        OP_ENDIF
-    OP_ENDIF
+    HASH160 DUP <revokehash> EQUAL
+    IF
+        DROP DUP HASH160 <Bob key hash> CHECKSIGVERIFY
+    ELSE
+        <R hash> EQUAL
+        IF
+            "24h" CHECKSEQUENCEVERIFY DROP
+            DUP HASH160 <Alice key hash> CHECKSIGVERIFY
+        ELSE
+            "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
+            DUP HASH160 <Bob key hash> CHECKSIGVERIFY
+        ENDIF
+    ENDIF
 
 and correspondingly in Bob's commitment transaction:
 
-   OP_HASH160 OP_DUP <revokehash> OP_EQUAL
-   OP_IF
-       OP_DROP OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
-   OP_ELSE
-       <R hash> OP_EQUAL
-       OP_IF
-           OP_DUP OP_HASH160 <Alice key hash> OP_CHECKSIGVERIFY
-       OP_ELSE
-           "24h" OP_CHECKSEQUENCEVERIFY OP_DROP
-           "2015/10/20 10:33" OP_CHECKLOCKTIMEVERIFY OP_DROP
-           OP_DUP OP_HASH160 <Bob key hash> OP_CHECKSIGVERIFY
-       OP_ENDIF
-   OP_ENDIF
+   HASH160 DUP <revokehash> EQUAL
+   IF
+       DROP DUP HASH160 <Alice key hash> CHECKSIGVERIFY
+   ELSE
+       <R hash> EQUAL
+       IF
+           DUP HASH160 <Alice key hash> CHECKSIGVERIFY
+       ELSE
+           "24h" CHECKSEQUENCEVERIFY DROP
+           "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
+           DUP HASH160 <Bob key hash> CHECKSIGVERIFY
+       ENDIF
+   ENDIF
 
 Note that both CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY are used in the
 final branch of above to ensure Bob cannot spend the output until after both
@@ -217,11 +219,13 @@ See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable
 
 ====2-Way Pegged Sidechains====
 
-    OP_IF
-        lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY
-    OP_ELSE
-        withdrawLockTime OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 p2shWithdrawDest OP_EQUAL
-    OP_ENDIF
+The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics of which are outside the scope of this BIP. CHECKSEQUENCEVERIFY is used to make sure that sufficient time has passed since the return peg was posted to publish a reorg proof:
+
+    IF
+        lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> REORGPROOFVERIFY
+    ELSE
+        withdrawLockTime CHECKSEQUENCEVERIFY DROP HASH160 p2shWithdrawDest EQUAL
+    ENDIF
 
 
 ==Specification==
@@ -258,14 +262,9 @@ semantics and detailed rationale for those semantics.
         // range. This limitation is implemented by CScriptNum's
         // default 4-byte limit.
         //
-        // If we kept to that limit we'd have a year 2038 problem,
-        // even though the nLockTime field in transactions
-        // themselves is uint32 which only becomes meaningless
-        // after the year 2106.
-        //
         // Thus as a special case we tell CScriptNum to accept up
         // to 5-byte bignums, which are good until 2**39-1, well
-        // beyond the 2**32-1 limit of the nLockTime field itself.
+        // beyond the 2**32-1 limit of the nSequence field itself.
         const CScriptNum nSequence(stacktop(-1), fRequireMinimal, 5);
         
         // In the rare event that the argument may be < 0 due to
@@ -281,13 +280,13 @@ semantics and detailed rationale for those semantics.
             break;
         
         // Actually compare the specified sequence number with the input.
-        if (!CheckSequence(nSequence))
+        if (!checker.CheckSequence(nSequence))
             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
         
         break;
     }
     
-    bool CheckSequence(const CScriptNum& nSequence) const
+    bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
     {
         // Relative lock times are supported by comparing the passed
         // in operand to the sequence number of the input.
@@ -321,7 +320,7 @@ semantics and detailed rationale for those semantics.
         
         // Now that we know we're comparing apples-to-apples, the
         // comparison is a simple numeric one.
-        if (nSequence > txToSequence)
+        if (txTo->vin[nIn].nSequence > txToSequence)
             return false;
         
         return true;

From 2a685b018499606251e2711aa9b50221b660daea Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 16:39:01 -0700
Subject: [PATCH 22/28] Change git repo to pull request #6564.

---
 bip-0112.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index f353019a..e1a186fc 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -329,9 +329,9 @@ semantics and detailed rationale for those semantics.
 
 ==Reference Implementation==
 
-A reference implementation is provided in the following git repository:
+A reference implementation is provided by the following pull request:
 
-https://github.com/maaku/bitcoin/tree/checksequenceverify
+https://github.com/bitcoin/bitcoin/pull/6564
 
 
 ==Deployment==

From 87868a6dd60ab6f1316f4d7b4ee1fde188f98444 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 16:44:37 -0700
Subject: [PATCH 23/28] Add in-line description of BIP 68.

---
 bip-0113.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index b7313e30..5b3affdb 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -35,7 +35,7 @@ miners to claim more transaction fees by lying about the timestamps of
 their block.
 
 This proposal seeks to ensure reliable behaviour in locktime calculations as 
-required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68, and BIP112 (CHECKSEQUENCEVERIFY).
+required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68 (sequence numbers), and BIP112 (CHECKSEQUENCEVERIFY).
 
 
 ==Specification==

From b027b77ed969fe27e3a7808742173a77d105e991 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 16:53:44 -0700
Subject: [PATCH 24/28] Change reference git repo to the associated pull
 request.

---
 bip-0113.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index b7313e30..59bee847 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -64,10 +64,10 @@ parameter. This BIP proposes that after activation calls to
 IsFinalTx() or LockTime() within consensus code use the return value
 of `GetMedianTimePast(pindexPrev)` instead.
 
-A reference implementation of this proposal is provided in the
-following git repository:
+A reference implementation of this proposal is provided by the
+following pull request:
 
-https://github.com/maaku/bitcoin/tree/medianpasttimelock
+https://github.com/bitcoin/bitcoin/pull/6566
 
 
 ==Deployment==

From 31a5fdfb850e0d9eb31167253bb8b81f03974477 Mon Sep 17 00:00:00 2001
From: Zach Dexter <zach.dexter@gmail.com>
Date: Fri, 9 Oct 2015 15:35:04 -0400
Subject: [PATCH 25/28] Fix ambiguous reference to seed value in BIP32 test
 vectors

---
 bip-0032.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 902a5eb2..28541f54 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -209,7 +209,7 @@ It is also the reason for the existence of hardened keys, and why they are used
 
 ===Test vector 1===
 
-Master (hex): 000102030405060708090a0b0c0d0e0f
+Seed (hex): 000102030405060708090a0b0c0d0e0f
 * Chain m
 ** ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
 ** ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
@@ -231,7 +231,7 @@ Master (hex): 000102030405060708090a0b0c0d0e0f
 
 ===Test vector 2===
 
-Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
+Seed (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
 * Chain m
 ** ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
 ** ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U

From b930994728312cc4b6a5ea1bbe5ddb862b3ae3b4 Mon Sep 17 00:00:00 2001
From: Justus Ranvier <justusranvier@riseup.net>
Date: Mon, 12 Oct 2015 15:56:38 -0500
Subject: [PATCH 26/28] Improve ECDH and blinding factor calculations

The blinding factor used for notification transactions incorporates and outpoint being spent by the notification transaction.

This ensures that blinding factors will always be unique, even if a user sends a notification transaction to the same recipient multiple times while spending funds from the same address.

Since some common EC libraries have ECDH functions that only return the x value of the resulting point, only use the x value for calculating scalar shared secrets.
---
 bip-0047.mediawiki | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index c8397a7d..8247e001 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -99,11 +99,13 @@ Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform
 ## Alice selects the private key corresponding to the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>a</pre>
 ## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre>
 ## Alice calculates a secret point: <pre>S = aB</pre>
-## Alice expresses the secret point in compressed DER format, then calculates a scalar shared secret: <pre>s = SHA256(S)</pre>
+## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre>
+### "x" is the x value of the secret point
+### "o" is the outpoint being spent by the first pubkey-exposing input of the transaction.
 # Alice serializes her payment code in binary form.
-# Alice renders her payment code (P) unreadable to anyone except Bob by:
-## Replace the x value with x': <pre>x' = s XOR (x value)</pre>
-## Replace the chain code with c': <pre>c' = sha256(s) XOR (chain code)</pre>
+# Alice renders her payment code (P) unreadable to anyone except Bob:
+## Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre>
+## Replace the chain code with c': <pre>c' = c XOR (last 32 bytes of s)</pre>
 # Alice adds an OP_RETURN output to her transaction which consists of P.
 <img src="bip-0047/reusable_payment_codes-01.png" />
 
@@ -113,10 +115,12 @@ Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform
 ## Bob selects the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>A, where A = aG</pre>
 ## Bob selects the private key associated with his notification address: <pre>b</pre>
 ## Bob calculates a secret point: <pre>S = bA</pre>
-## Bob expresses the secret point in compressed DER format, then calculates a scalar shared secret: <pre>s = SHA256(S)</pre>
+## Bob calculates the binding factor: <pre>s = HMAC-SHA512(x, o)</pre>
+### "x" is the x value of the secret point
+### "o" is the outpoint being spent by the first pubkey-exposing input of the transaction.
 ## Bob interprets the 80 byte payload as a payment code, except:
-### Replace the x value with x': <pre>x' = s XOR (x value)</pre>
-### Replace the chain code with c': <pre>c' = sha256(s) XOR (chain code)</pre>
+### Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre>
+### Replace the chain code with c': <pre>c' = c XOR (last 32 bytes of s)</pre>
 ## If the updated x value is a member of the secp256k1 group, the payment code is valid.
 ## If the updated x value is not a member of the secp256k1 group, the payment code is ignored.
 
@@ -138,7 +142,7 @@ Bitcoins received via notification transactions require special handling in orde
 ## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre>
 ### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob
 ## Alice calculates a secret point: <pre>S = aB</pre>
-## Alice expresses the secret point in compressed DER format, then calculates a scalar shared secret: <pre>s = SHA256(S)</pre>
+## Alice calculates a scalar shared secret using the x value of S: <pre>s = SHA256(Sx)</pre>
 ### If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again.
 ## Alice uses the scalar shared secret to calculate the ephemeral public key used to generate the P2PKH address for this transaction: <pre>B' = B + sG</pre>
 <img src="bip-0047/reusable_payment_codes-04.png" />
@@ -248,6 +252,7 @@ In order to use Bitmessage notification, the recipient must have a Bitmessage cl
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
 * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
 * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[https://bitcoin.org/en/glossary/outpoint|Outpoint]]
 * [[https://github.com/petertodd/dust-b-gone|dust-b-gone]]
 * [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]]
 * [[https://bitmessage.org/bitmessage.pdf|Bitmessage]]

From 61b865e5241be45437ece5fe70ae6e6c2319cbb9 Mon Sep 17 00:00:00 2001
From: Jonathan Cross <jonathancross@users.noreply.github.com>
Date: Tue, 20 Oct 2015 15:38:14 +0200
Subject: [PATCH 27/28] Spelling fix.

"unneccesarily" => "unnecessarily"
---
 bip-0121.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0121.mediawiki b/bip-0121.mediawiki
index 76513dd0..de89f0cc 100644
--- a/bip-0121.mediawiki
+++ b/bip-0121.mediawiki
@@ -98,7 +98,7 @@ The <tt>p</tt> parameter value is the destination where to send the
 PoP to. This destination is typically a <tt>https:</tt> URL or a
 <tt>http:</tt> URL, but it could be any type of URI, for example
 <tt>mailto:</tt>. To keep <tt>btcpop:</tt> URIs short, users should
-not make their <tt>p</tt> parameter unneccesarily long.
+not make their <tt>p</tt> parameter unnecessarily long.
 
 ==== <tt>http:</tt> and <tt>https:</tt> URLs ====
 

From da1a3ff617504c2a7b0bcd723e4c6d4a8c730890 Mon Sep 17 00:00:00 2001
From: Jonathan Cross <jonathancross@users.noreply.github.com>
Date: Tue, 20 Oct 2015 16:04:46 +0200
Subject: [PATCH 28/28] Spelling fix and small clarification for BIP 120

Spelling:
  Line 42: "neccesarily" => "necessarily"
  Line 126: "scipts" => "scripts"

One small improvement for clarity:
  Line 138:  "another" => "a different"
---
 bip-0120.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki
index e099f5be..1602c655 100644
--- a/bip-0120.mediawiki
+++ b/bip-0120.mediawiki
@@ -39,7 +39,7 @@ Current methods of proving a payment:
 * In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5.
 * Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so.
 
-If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not neccesarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address.
+If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not necessarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address.
 
 == Specification ==
 
@@ -123,7 +123,7 @@ The server needs to validate the PoP and reply with "valid" or "invalid". That p
 # Check that there is exactly one output. This output must have value 0 and conform to the OP_RETURN output format outlined above.
 # Check that the nonce is the same as the one requested.
 # Check that the inputs of the PoP are exactly the same as in transaction T, except that the sequence numbers must all be 0. The ordering of the inputs must also be the same as in T.
-# Run the scripts of all the inputs. All scipts must return true.
+# Run the scripts of all the inputs. All scripts must return true.
 # Check that the txid in the PoP output is the transaction you actually want proof for. If you don’t know exactly what transaction you want proof for, check that the transaction actually pays for the product/service you deliver.
 # Return "valid".
 
@@ -135,7 +135,7 @@ The server needs to validate the PoP and reply with "valid" or "invalid". That p
 ** nonce - Your pop will not validate on server.
 * Someone can steal a PoP, for example by tampering with the PoP request, and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^48). The server should have a mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so.
 * Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied.
-* Transaction malleability may cause the server to have another transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions.
+* Transaction malleability may cause the server to have a different transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions.
 
 == Reference implementation ==