Merge remote-tracking branch 'bitcoin/master'

Conflicts:
	README.mediawiki

9 files changed, 402 insertions, 34 deletions

diff --git a/README.mediawiki b/README.mediawiki
index 56c8bd1..1f8ef4d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -254,9 +254,15 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+<<<<<<< HEAD
 | [[bip-0069.mediawiki|69]]
 | Lexicographical Indexing of Transaction Inputs and Outputs
 | Kristov Atlas
+=======
+| [[bip-0068.mediawiki|68]]
+| Consensus-enforced transaction replacement signalled via sequence numbers
+| Mark Friedenbach
+>>>>>>> bitcoin/master
 | Standard
 | Draft
 |-
@@ -283,6 +289,12 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Stephen Pair
 | Standard
 | Draft
+|-
+| [[bip-0101.mediawiki|101]]
+| Increase maximum block size
+| Gavin Andresen
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0001.mediawiki b/bip-0001.mediawiki
index 5c8a544..c18ebd3 100644
--- a/bip-0001.mediawiki
+++ b/bip-0001.mediawiki
@@ -27,11 +27,11 @@ The BIP editors assign BIP numbers and change their status. Please send all BIP-
 
 The BIP process begins with a new idea for Bitcoin. It is highly recommended that a single BIP contain a single key proposal or new idea. Small enhancements or patches often don't need a BIP and can be injected into the Bitcoin development work flow with a patch submission to the Bitcoin issue tracker. The more focused the BIP, the more successful it tends to be. The BIP editor reserves the right to reject BIP proposals if they appear too unfocused or too broad. If in doubt, split your BIP into several well-focused ones.
 
-Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this.
+Each BIP must have a champion -- someone who writes the BIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The BIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is BIP-able. Posting to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev] mailing list (and maybe the [https://bitcointalk.org/index.php?board=6.0 Development&Technical Discussion] forum) is the best way to go about this.
 
 Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time. Many ideas have been brought forward for changing Bitcoin that have been rejected for various reasons. Asking the Bitcoin community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Bitcoin is used.
 
-Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development bitcoin-development@lists.sourceforge.net]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
+Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org]. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
 
 Following a discussion, the proposal should be sent to the Bitcoin-dev list and the BIP editor with the draft BIP. This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed.
 
diff --git a/bip-0045.mediawiki b/bip-0045.mediawiki
index 3710ce8..f93319d 100644
--- a/bip-0045.mediawiki
+++ b/bip-0045.mediawiki
@@ -49,7 +49,7 @@ Purpose is a constant set to 45, following the BIP43 recommendation.
 It indicates that the subtree of this node is used according to this specification.
 
 <code>
-m / purpose' / *
+m / 45' / *
 </code>
 
 Hardened derivation is used at this level.
@@ -76,11 +76,11 @@ purpose public keys:
 03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13
 </pre>
 
-it should use `m / purpose ' / 0 / *` for 
+it should use `m / 45 ' / 0 / *` for 
 `039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`, 
-`m / purpose ' / 1 / *` for
+`m / 45 ' / 1 / *` for
 `03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`,
-and `m / purpose ' / 2 / *` for
+and `m / 45 ' / 2 / *` for
 `03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`,
 as dictated by their lexicographical order.
 
@@ -99,7 +99,7 @@ chain is used for addresses which are not meant to be visible outside of the
 wallet and is used for return transaction change.
 
 For example, if cosigner 2 wants to generate a change address, he would use
-`m / purpose ' / 2 / 1 / *`, and `m / purpose ' / 2 / 0 / *` for a receive
+`m / 45 ' / 2 / 1 / *`, and `m / 45 ' / 2 / 0 / *` for a receive
 address.
 
 Non-hardened derivation is used at this level.
@@ -134,7 +134,7 @@ others using the next index, and calculate the needed script for the address.
 
 Example: Cosigner #2 wants to receive a payment to the shared wallet. His last
 used index on his own branch is 4. Then, the path for the next receive
-address is `m/$purpose/2/1/5`. He uses this same path in all of the cosigners
+address is `m/45'/2/0/5`. He uses this same path in all of the cosigners
 trees to generate a public key for each one, and from that he gets the new
 p2sh address.
 ====Change address case====
@@ -145,7 +145,7 @@ using a separate index to track the used change addresses.
 
 Example: Cosigner #5 wants to send a payment from the shared wallet, for which
 he'll need a change address. His last used change index on his own branch is
-11. Then, the path for the next change address is `m/$purpose/5/0/12`. He uses
+11. Then, the path for the next change address is `m/45'/5/1/12`. He uses
 this same path in all of the cosigners trees to generate a public key for each
 one, and from that he gets the new p2sh address.
 
@@ -165,27 +165,23 @@ protocol to accept or reject it, belong to another BIP, in my opinion.
 ===Address discovery===
 
 When the master seed is imported from an external source the software should
-start to discover the accounts in the following manner:
+start to discover the addresses in the following manner:
 
-# derive the first account's node (index = 0)
-# derive the external chain node of this account
-# scan addresses of the external chain; respect the gap limit described below
-# if no transactions are found on the external chain stop discovery
-# if there are some transactions, increase the account index and go to step 1
+# for each cosigner:
+# derive the cosigner's node (`m / 45' / cosigner_index`)
+# for both the external and internal chains on this node (`m / 45' / cosigner_index / 0` and `m / 45' / cosigner_index / 1`):
+# scan addresses of the chain; respect the gap limit described below
 
-This algorithm is correct, because software should disallow creation of new
-accounts if previous one has no transaction history as described in chapter
-"Account" above.
-
-Please note that the algorithm works with the transaction history, not account
-balances, so you can have account with total 0 coins and the algorithm will
-still continue with discovery.
+Please note that the algorithm uses the transaction history, not address
+balances, so even if the address has 0 coins, the program should continue with discovery.
+Opposite to BIP44, each cosigner branch needs to be checked,
+even if the earlier ones don't have transactions
 
 ===Address gap limit===
 
-Address gap limit is currently set to 20. If the software hits 20 unused
-addresses in a row, it expects there are no used addresses beyond this point
-and stops searching the address chain.
+Address gap limit is currently set to 20. If the software hits 20 unused 
+addresses (no transactions associated with that address) in a row, it expects
+there are no used addresses beyond this point and stops searching the address chain.
 
 Wallet software should warn when user is trying to exceed the gap limit on
 an external chain by generating a new address.
diff --git a/bip-0061.mediawiki b/bip-0061.mediawiki
index a18a4e6..aca329a 100644
--- a/bip-0061.mediawiki
+++ b/bip-0061.mediawiki
@@ -107,6 +107,8 @@ The following codes are used:
 |-
 | 0x10 || Transaction is invalid for some reason (invalid signature, output value greater than input, etc.)
 |-
+| 0x12 || An input is already spent
+|-
 | 0x40 || Not mined/relayed because it is "non-standard" (type or version unknown by the server)
 |-
 | 0x41 || One or more output amounts are below the 'dust' threshold
diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki
index 4846abf..7bd88a6 100644
--- a/bip-0062.mediawiki
+++ b/bip-0062.mediawiki
@@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but
 ===New rules===
 
 Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above:
-# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to delibrately create an invalid signature for with OP_CHECKSIG and OP_CHECKMULTISIG the empty byte array (the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
+# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. To provide a compact way to deliberately create an invalid signature for with OP_CHECKSIG and OP_CHECKMULTISIG the empty byte array (the result of OP_0) is also allowed. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]].
 # '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]].
 # '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]].
diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index 5549182..02de20b 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -40,7 +40,7 @@ An example where this technique is used is in micro-payment channels, where the
 nLockTime field proves that should the receiver vanish the sender is guaranteed
 to get all their escrowed funds back when the nLockTime is reached.
 
-However the nLockTime field is insufficient if you wish to prove that
+However, the nLockTime field is insufficient if you wish to prove that a
 transaction output ''cannot'' be spent until some time in the future, as there
 is no way to prove that the secret keys corresponding to the pubkeys controlling
 the funds have not been used to create a valid signature.
@@ -60,7 +60,7 @@ either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
 not to have immediate access to the funds to discourage bad actors from
 attempting to get the secret keys from him by force.
 
-However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
+However, with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
 the form:
 
     IF
@@ -74,24 +74,24 @@ the form:
 
 At any time the funds can be spent with the following scriptSig:
 
-    <Alice's signature> <Bob's signature> 0
+    0 <Alice's signature> <Bob's signature> 0
 
 After 3 months have passed Lenny and one of either Alice or Bob can spend the
 funds with the following scriptSig:
 
-    <Alice/Bob's signature> <Lenny's signature> 1
+    0 <Alice/Bob's signature> <Lenny's signature> 1
 
 
 ===Non-interactive time-locked refunds===
 
 There exist a number of protocols where a transaction output is created that
 requires the co-operation of both parties to spend the output. To ensure the
-failure of one party does not result in the funds becoming lost refund
+failure of one party does not result in the funds becoming lost, refund
 transactions are setup in advance using nLockTime. These refund transactions
 need to be created interactively, and additionaly, are currently vulnerable to
 transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols,
 replacing the interactive setup with a non-interactive setup, and additionally,
-making transaction mutability a non-issue.
+making transaction mutability (aka malleability) a non-issue.
 
 
 ====Two-factor wallets====
@@ -172,6 +172,17 @@ sufficiently far into the future that large miners profitably can't sell the
 sacrifices at a discount.
 
 
+===Freezing Funds===
+
+In addition to using cold storage, hardware wallets, and P2SH multisig outputs
+to control funds, now funds can be frozen in UTXOs directly on the blockchain.
+With the following scriptPubKey, nobody will be able to spend the encumbered
+output until the provided expiry time. This ability to freeze funds reliably may
+be useful in scenarios where reducing duress or confiscation risk is desired.
+
+    <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
+
+
 ===Replacing the nLockTime field entirely===
 
 As an aside, note how if the SignatureHash() algorithm could optionally cover
@@ -276,9 +287,21 @@ time.
 
 PayPub - https://github.com/unsystem/paypub
 
-Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
+Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
+
+
+==Implementations==
+
+Python / python-bitcoinlib
+
+- https://github.com/petertodd/checklocktimeverify-demos
+
+JavaScript / Node.js / bitcore
+
+- https://github.com/mruddy/bip65-demos
 
 
 ==Copyright==
 
 This document is placed in the public domain.
+
diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki
index 3fd1b85..41cbd8f 100644
--- a/bip-0066.mediawiki
+++ b/bip-0066.mediawiki
@@ -23,7 +23,7 @@ This document proposes to restrict valid signatures to exactly what is mandated
 
 Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, must be encoded using strict DER encoding (see further).
 
-These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verifcation, if the signature does not pass the <code>IsValidSignatureEncoding</code> check below, the entire script evaluates to false immediately. If the signature is valid DER, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to <code>IsValidSignatureEncoding</code>).
+These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the <code>IsValidSignatureEncoding</code> check below, the entire script evaluates to false immediately. If the signature is valid DER, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to <code>IsValidSignatureEncoding</code>).
 
 ===DER encoding reference===
 
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
new file mode 100644
index 0000000..8da92b8
--- /dev/null
+++ b/bip-0068.mediawiki
@@ -0,0 +1,209 @@
+<pre>
+  BIP: 68
+  Title: Consensus-enforced transaction replacement signalled via sequence numbers
+  Author: Mark Friedenbach <mark@friedenbach.org>
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-05-28
+</pre>
+
+==Abstract==
+
+This BIP describes a modification to the consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding output, for the purpose of supporting consensus-enforced transaction replacement features.
+
+==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" behaviour, as even a few rational (profit maximizing) miners would break that completely. The change described by this BIP provides the missing piece that makes sequence numbers do something significant with respect to enforcing transaction replacement without assuming anything other than profit-maximizing behaviour on the part of miners.
+
+==Specification==
+
+The maximum sequence number can be included in any block, like normal. For transactions with an nVersion of 2 or greater, a sequence number of one less than the maximum can only be included in the next block after the input it is spending, rather than it being possible to be included in the same block. A sequence number one less than that can only be included two blocks later, and so on. Alternatively, a sequence number LOCKTIME_THRESHOLD (500,000,000) less than the maximum (0xffffffff - 500,000,000 = 0xe2329aff) can only be included in a block with an nTime timestamp at least one second greater than the median time stamp of the 11 blocks prior to the block containing the coin being spent. A sequence number one less than that can only be included two seconds later, and so on. This behaviour is only enforced if the most significant bit of the sequence number field is set.
+
+This is proposed to be accomplished by replacing IsFinalTx() and CheckFinalTx(), existing 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:
+
+<pre>
+    enum {
+        /* Interpret sequence numbers as relative lock-time constraints. */
+        LOCKTIME_VERIFY_SEQUENCE = (1 << 0),
+    };
+    
+    const uint32_t SEQUENCE_THRESHOLD = (1 << 31);
+    
+    int64_t LockTime(const CTransaction &tx,
+                     int flags, const CCoinsView* pCoinsView,
+                     int nBlockHeight, int64_t nBlockTime)
+    {
+        CCoins coins;
+        uint32_t nLockTime;
+    
+        bool fEnforceBIP68 = tx.nVersion >= 2
+                          && flags & LOCKTIME_VERIFY_SEQUENCE;
+    
+        // Will be set to the equivalent height- and time-based nLockTime
+        // values that would be necessary to satisfy all relative lock-
+        // time constraints given our view of block chain history.
+        int nMinHeight = 0;
+        int64_t nMinTime = 0;
+        // Will remain equal to true if all inputs are finalized (MAX_INT).
+        bool fFinalized = true;
+    
+        BOOST_FOREACH(const CTxIn& txin, tx.vin) {
+            // The relative lock-time is the inverted sequence number so
+            // as to preserve the semantics MAX_INT means an input is
+            // finalized (0 relative lock-time).
+            nLockTime = ~txin.nSequence;
+    
+            // ~MAX_INT is zero/false, meaning the input is final.
+            if (!nLockTime)
+                continue;
+            else
+                fFinalized = false;
+    
+            // Sequence numbers equal to or above the SEQUENCE_THRESHOLD
+            // are not treated as relative lock-times, nor are they given
+            // any consensus-enforced meaning at this point.
+            if (nLockTime >= SEQUENCE_THRESHOLD)
+                continue;
+    
+            // Do not enforce sequence numbers as a relative lock time
+            // unless we have been instructed to.
+            if (!fEnforceBIP68)
+                continue;
+    
+            // Skip this input if it is not in the UTXO set. This should
+            // only ever happen in non-consensus code.
+            if (!pCoinsView->GetCoins(txin.prevout.hash, coins))
+                continue;
+    
+            if (nLockTime < LOCKTIME_THRESHOLD)
+                // We subtract 1 from relative lock-times because of 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)nLockTime - 1);
+            else
+                // 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.
+                nMinTime = std::max(nMinTime,
+                      pindexBestHeader->GetAncestor(coins.nHeight-1)->GetMedianTimePast()
+                    - LOCKTIME_THRESHOLD + (int64_t)nLockTime);
+        }
+    
+        // If sequence numbers are MAX_INT / zero relative lock-time, the
+        // transaction is considered final and nLockTime constraints are
+        // not enforced.
+        if (fFinalized)
+            return 0;
+    
+        if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD)
+            nMinHeight = std::max(nMinHeight, (int)tx.nLockTime);
+        else
+            nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime);
+    
+        if (nMinHeight >= nBlockHeight)
+            return nMinHeight;
+        if (nMinTime >= nBlockTime)
+            return nMinTime;
+    
+        return 0;
+    }
+    
+    int64_t CheckLockTime(const CTransaction &tx, int flags)
+    {
+        AssertLockHeld(cs_main);
+    
+        // By convention a negative value for flags indicates that the
+        // current network-enforced consensus rules should be used.
+        flags = std::max(flags, 0);
+    
+        // pcoinsTip contains the UTXO set for chainActive.Tip()
+        const CCoinsView *pCoinsView = pcoinsTip;
+    
+        // CheckLockTime() uses chainActive.Height()+1 to evaluate
+        // nLockTime because when LockTime() is called within
+        // CBlock::AcceptBlock(), the height of the block *being*
+        // evaluated is what is used. Thus if we want to know if a
+        // transaction can be part of the *next* block, we need to call
+        // LockTime() with one more than chainActive.Height().
+        const int nBlockHeight = chainActive.Height() + 1;
+    
+        // Timestamps on the other hand don't get any special treatment,
+        // because we can't know what timestamp the next block will have,
+        // and there aren't timestamp applications where it matters.
+        const int64_t nBlockTime = GetAdjustedTime();
+    
+        return LockTime(tx, flags, pCoinsView, nBlockHeight, nBlockTime);
+    }
+</pre>
+
+Code conditional on the return value of IsFinalTx() / CheckLockTime() has to be updated as well, since the semantics of the return value has been inverted.
+
+==Rationale==
+
+Counting down from the maximum makes sense, since nothing can be higher than the maximum and no transaction can be in a block before its parent transactions. This means that a higher sequence number can always be included earlier than a lower one (even if the time the original coins being spent was unknown when the transaction was authored). Because of this, even rational miners should go along with the scheme: Take the higher sequence number and collect the fees, or skip over it in the hopes that no one else takes a higher number before the next available lower number becomes spendable. And, of course, users are not constrained to make their sequence numbers go down only one at a time. So it's "take the most updated version, now, or gamble that no one in the next dozen blocks takes the most updated and that you manage to include the next to most when it finally becomes mineable." This is similar to how lock-time works. In fact, this scheme is precisely a per-input relative lock-time.
+
+==Example: Bidirectional payment channel==
+
+A bidirectional payment channel can be established by two parties funding a single output in the following way: Alice funds a 1btc output which is the 2-of-2 multisig of Alice AND Bob, or Alice's key only after a sufficiently long timeout, e.g. 30 days or 4320 blocks. The channel-generating transaction is signed by Alice and broadcast to the network.
+
+Alice desires to send Bob a payment of 0.1btc. She does so by constructing a transaction spending the 1btc output and sending 0.1btc to Bob and 0.9btc back to herself. She provides her signature for the 2-of-2 multisig constraint, and sets a relative lock-time using the sequence number field such that the transaction will become valid 24-hours or 144 blocks before the refund timeout. Two more times Alice sends Bob a payment of 0.1btc, each time generating and signing her half of a transaction spending the 1btc output and sending 0.2btc, then 0.3btc to Bob with a relative lock-time of 29 days from creation of the channel.
+
+Bob now desires to send Alice a refund of 0.25btc. He does so by constructing a transaction spending the 1btc output and sending 0.95btc (= 0.7btc + 0.25btc) to Alice and 0.05btc to himself. Since Bob will still have in his logs the transaction giving him 0.7btc 29 days after the creation of the channel, Alice demands that this new transaction have a relative lock-time of 28 days so she has a full day to broadcast it before the next transaction matures.
+
+Alice and Bob continue to make payments to each other, decrementing the relative lock-time by one day each time the channel switches direction, until the present time is reached or either party desires to close out the channel. A close-out is performed by setting the relative lock-time to zero (nSequence = MAX_INT) and both parties signing.
+
+==Implementation==
+
+A reference implementation is provided in the following git repository:
+
+https://github.com/maaku/bitcoin/tree/sequencenumbers
+
+==Acknowledgements==
+
+Credit goes to Gregory Maxwell for providing a succinct and clear description of the behaviour of this change, which became the basis of this BIP text.
+
+==Deployment==
+
+We reuse the double-threshold switchover mechanism from BIPs 34 and 66, with the same thresholds, but for nVersion = 4. The new rules are in effect for every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 4. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 4, nVersion = 3 blocks become invalid, and all further blocks enforce the new rules.
+
+It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, such as [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: OP_CHECKLOCKTIMEVERIFY.
+
+==Compatibility==
+
+The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP without requiring any special-case handling.
+
+There may be other uses for the sequence number field that are not commonplace or yet to be discoverd. To allow for other uses of the sequence number field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is set. This allows up to 31 bits of the sequence number field to be used for other purposes in applicaitons which don't simultaneously need a per-input relative lock-time.
+
+The most efficient way to calculate sequence number from relative lock-time is with bit-inversion:
+
+<pre>
+    // 0 <= nHeight < 500,000,000 blocks
+    nSequence = ~(nHeight);
+    nHeight = ~(nSequence);
+    
+    // 1 <= nTime < 1,647,483,648 seconds (52.2 years)
+    nSequence = ~(nTime - 1 + LOCKTIME_THRESHOLD);
+    nTime = ~(nSequence) - LOCKTIME_THRESHOLD + 1;
+</pre>
+
+In languages which do not support bit inversion, the calculation can be accomplished with integer arithmetic instead:
+
+<pre>
+    nSequence = 0xffffffff - nHeight;
+    nHeight = 0xffffffff - nSequence;
+    
+    nSequence = 0xffffffff - nTime + 1 - LOCKTIME_THRESHOLD;
+    nTime = 0xffffffff - nSequence + 1 - LOCKTIME_THRESHOLD;
+</pre>
+
+==References==
+
+Bitcoin mailing list discussion: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07864.html
+
+BIP 34: Block v2, Height in Coinbase, https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
+
+BIP 65: OP_CHECKLOCKTIMEVERIFY, https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
+
+BIP 66: Strict DER signatures, https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki
new file mode 100644
index 0000000..9a78255
--- /dev/null
+++ b/bip-0101.mediawiki
@@ -0,0 +1,126 @@
+<pre>
+  BIP: 101
+  Title: Increase maximum block size
+  Author: Gavin Andresen <gavinandresen@gmail.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-06-22
+</pre>
+
+==Abstract==
+
+This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate.
+
+==Motivation==
+
+Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth.
+
+==Specification==
+
+After deployment (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header.
+
+The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
+
+Expressed in pseudo-code, using integer math, assuming that block_timestamp is after the activation time (as described in the Deployment section below):
+
+    function max_block_size(block_timestamp):
+
+        time_start = 1452470400
+        time_double = 60*60*24*365*2
+        size_start = 8000000
+        if block_timestamp >= time_start+time_double*10
+            return size_start * 2^10
+
+        // Piecewise-linear-between-doublings growth:
+        time_delta = block_timestamp - time_start
+        doublings = time_delta / time_double
+        remainder = time_delta % time_double
+        interpolate = (size_start * 2^doublings * remainder) / time_double
+        max_size = size_start * 2^doublings + interpolate
+
+        return max_size
+
+==Deployment==
+
+Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC.
+
+Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.
+
+Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block.
+
+==Test network==
+
+Test network parameters are the same as the main network, except starting earlier with easier supermajority conditions and a shorter grace period:
+
+    starting time: 1 Aug 2015 (timestamp 1438387200)
+    activation condition: 75 of 100 blocks
+    grace period: 24 hours
+
+==Rationale==
+
+The initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners on bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China).
+
+The doubling interval was chosen based on long-term growth trends for CPU power, storage, and Internet bandwidth. The 20-year limit was chosen because exponential growth cannot continue forever. If long-term trends do not continue, maximum block sizes can be reduced by miner consensus (a soft-fork).
+
+Calculations are based on timestamps and not blockchain height because a timestamp is part of every block's header. This allows implementations to know a block's maximum size after they have downloaded it's header, but before downloading any transactions.
+
+The deployment plan is taken from Jeff Garzik's proposed BIP100 block size increase, and is designed to give miners, merchants, and full-node-running-end-users sufficient time to upgrade to software that supports bigger blocks. A 75% supermajority was chosen so that one large mining pool does not have effective veto power over a blocksize increase. The version number scheme is designed to be compatible with Pieter's Wuille's proposed "Version bits" BIP, and to not interfere with any other consensus rule changes in the process of being rolled out.
+
+==Objections to this proposal==
+
+Raising the 1MB block size has been [https://www.google.com/webhp?#q=1mb+limit+site%3Abitcointalk.org discussed and debated for years].
+
+===Centralization of full nodes===
+
+The number of fully-validating nodes reachable on the network has been steadily declining. Increasing the capacity of the network to handle transactions by increasing the maximum block size may accelerate that decline, meaning a less distributed network that is more vulnerable to disruption. The size of this effect is debatable; the author of this BIP believes that the decline in fully validating nodes on the network is largely due to the availability of convenient, attractive, secure, lightweight wallet software and the general trend away from computing on desktop computers to mobile phones and tablets.
+
+Increasing the capacity of the network to handle transactions should enable increased adoption by users and businesses, especially in areas of the world where existing financial infrastructure is weak. That could lead to a more robust network with nodes running in more political jurisdictions.
+
+===Centralization of mining: costs===
+
+Miners benefit from low-latency, high-bandwidth connections because they increase their chances of winning a "block race" (two or more blocks found at approximately the same time). With the current peer-to-peer networking protocol, announcing larger blocks requires more bandwidth. If the costs grow high enough, the result will be a very small number of very large miners.
+
+The limits proposed by this BIP are designed so that running a fully validating node has very modest costs, which, if current trends in the cost of technology continue, will become even less expensive over time.
+
+===Centralization of mining: big-block attacks===
+
+[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html Simulations show] that with the current peer-to-peer protocol, miners behind high-latency or low-bandwidth links are at a disadvantage compared to miners connected to a majority of hashpower via low-latency, high-bandwidth links. Larger blocks increase the advantage of miners with high-bandwidth connections, although that advantage can be minimized with changes to the way new blocks are announced (e.g. http://bitcoinrelaynetwork.org/ ).
+
+If latency and bandwidth to other miners were the only variable that affected the profitability of mining, and miners were driven purely by profit, the end result would be one miner running on one machine, where latency was zero and bandwidth was essentially infinite.
+
+However, many other factors influence miner profitability, including cost of electricity and labor and real estate, ability to use waste heat productively, access to capital to invest in mining equipment, etc. Increasing the influence of bandwidth in the mining profitability equation will not necessarily lead to more centralization.
+
+===Unspent Transaction Output Growth===
+
+This BIP makes no attempt to restrict the approximately 100% per-year growth in unspent transaction outputs (see http://gavinandresen.ninja/utxo-uhoh for details), because the author believe that problem should be solved by a further restriction on blocks described in a separate BIP (perhaps an additional limit on how much the transactions in any block may increase the UTXO set size).
+
+==Long-term fee incentives==
+
+http://gavinandresen.ninja/block-size-and-miner-fees-again
+
+==Other solutions considered==
+
+There have been dozens of proposals for increasing the block size over the years. Some notable ideas:
+
+===One-time increase===
+
+A small, quick one-time increase to, for example, 2MB blocks, would be the most conservative option.
+
+However, a one-time increase requires just as much care in testing and deployment as a longer-term fix. And the entire debate over how large or small a limit is appropriate would be repeated as soon as the new limit was reached.
+
+===Dynamic limit proposals===
+
+BIP 100 proposes a dynamic limit determined by miner preferences expressed in coinbase transactions, with limits on the rate of growth. It gives miners more direct control over the maximum block size, which some people see as an advantage over this proposal and some see as a disadvantage. It is more complex to implement, because the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched out-of-order in a 'headers-first' mode).
+
+[https://bitcointalk.org/index.php?topic=1078521.0 Meni Rosenfeld has proposed] that miners sacrifice mining reward to "pay for" bigger blocks, so there is an incentive to create bigger blocks only if transaction fees cover the cost of creating a larger block. This proposal is significantly more complex to implement, and it is not clear if a set of parameters for setting the cost of making a block bigger can be found that is not equivalent to a centrally-controlled network-wide minimum transaction fee.
+
+==Compatibility==
+
+This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks.
+
+Simplified Payment Verification software is not affected, unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/6341
+