Merge remote-tracking branch 'origin/master' into segwit_gbt_updates_20160330

5 files changed, 99 insertions, 27 deletions

diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index 0720eb4..b1145b3 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,7 +1,7 @@
 RECENT CHANGES:
+* (19 Apr 2016) Define version 2 payment codes
 * (17 Apr 2016) Clarify usage of outpoints in notification transactions
 * (18 Dec 2015) Update explanations to resolve FAQs
-* (12 Oct 2015) Revise blinding method for notification transactions
 
 <pre>
   BIP: 47
@@ -84,7 +84,27 @@ Hardened derivation is used at this level.
 
 Except where noted, all keys derived from a payment code use the public derivation method.
 
-==Standard Payment Codes (v1)==
+==Versions==
+
+Payment codes contain a version byte which identifies a specific set of behavior.
+
+Unless otherwise specified, payment codes of different versions are interoperable. If Alice uses a version x payment code, and Bob uses a version y payment code, they can still send and receive transactions between each other.
+
+Currently specified versions:
+
+* Version 1
+** Address type: P2PKH
+** Notification type: address
+* Version 2
+** Address type: P2PKH
+** Notification type: bloom-multisig
+
+===Recommended Versions===
+
+* Wallets which have bloom filtering capabilities SHOULD create version 2 payment codes instead of version 1 payment codes.
+* Version 1 payment codes are only recommended for wallets which lack access to bloom filtering capability.
+
+==Version 1==
 
 ===Representation===
 
@@ -127,6 +147,8 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met
 
 Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure:
 
+Note: this procedure is used if Bob uses a version 1 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification.
+
 # Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction)
 ## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address
 # Alice derives a unique shared secret using ECDH:
@@ -180,6 +202,17 @@ Alice SHOULD use an input script in one of the following standard forms to expos
 
 Compatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions.
 
+=====Post-Notification Privacy Considerations=====
+
+Incautious handling of change outputs from notification transactions may cause unintended loss of privacy.
+
+The recipient of a transaction which spends a change output from a prior notification transaction will learn about the potential connection between the sender and the recipient of the notification transaction.
+
+The following actions are recommended to reduce this risk:
+
+* Wallets which support mixing SHOULD mix change outputs from notification transactions prior to spending them
+* Wallets which do not support mixing MAY simulate mixing by creating a transaction which spends the change output to the next external BIP44 address
+
 ====Sending====
 
 # Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows:
@@ -294,6 +327,41 @@ The sender transmits their payment code in base58 form to the calculated Bitmess
 
 In order to use Bitmessage notification, the recipient must have a Bitmessage client which listens at the address which the senders will derive and is capable of relaying received payment codes to the Bitcoin wallet.
 
+==Version 2==
+
+Version 2 payment codes behave identifically to version 1 payment codes, except as modified below.
+
+===Representation===
+
+====Binary Serialization====
+
+* Byte 0: version. required value: 0x02
+
+===Protocol===
+
+====Definitions====
+
+* Notification change output: the change output from a notification transaction which which resides in the sender's wallet, but can be automatically located by the intended recipient
+* Payment code identifier: a 33 byte representation of a payment code constructed by prepending 0x02 to the SHA256 hash of the binary serialization of the payment code
+
+====Notification Transaction====
+
+Note: this procedure is used if Bob uses a version 2 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 2, see the appropriate section in this specification.
+
+# Construct a notification transaction as per the version 1 instructions, except do not create the output to Bob's notification address
+# Create a notification change address as follows:
+## Obtain the pubkey corresponding to the next change address
+## Construct a multisig output in the form:
+<pre>OP_1 <Bob's payment code identifier> <change address pubkey> OP_2 OP_CHECKMULTISIG</pre>
+
+The relative ordering of the payment code identifier and change address pubkey in the above script MAY be randomized
+
+Bob detects notification transactions by adding his payment code identifier to his bloom filter.
+
+# When the filter returns a notification transaction, the sender's payment code is unblinded using the same procedure as for version 1 notification transactions.
+
+Alice's wallet should spend the notification change output at the next appropriate opportunity.
+
 ==Test Vectors==
 
 * [[https://gist.github.com/SamouraiDev/6aad669604c5930864bd|BIP47 Reusable Payment Codes Test Vectors]]
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index ab66e12..0082db3 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -43,7 +43,7 @@ This specification only interprets 16 bits of the sequence number as relative lo
 For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block-based or time-based, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.
 
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
-The mining date of the output is equals to the median-time-past of the previous block which mined it.
+The mining date of the output is equal to the median-time-past of the previous block which mined it.
 
 The block produced time is equal to the median-time-past of its previous block.
 
diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index 9d8228c..19f74b6 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -185,7 +185,7 @@ Alice might look like the following in Alice's commitment transaction:
     ELSE
         <Commit-Revocation-Hash> EQUAL
         NOTIF
-            "24h" CHECKLOCKTIMEVERIFY DROP
+            "2015/10/20 10:33" CHECKLOCKTIMEVERIFY DROP
         ENDIF
         <Bob key hash>
     ENDIF
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index e3ffa9b..b8f686c 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -60,30 +60,30 @@ A non-witness program (defined hereinafter) txin MUST be associated with an empt
 
 A new block rule is added which requires a commitment to the <code>wtxid</code>. The <code>wtxid</code> of coinbase transaction is assumed to be <code>0x0000....0000</code>.
 
-A witness root hash is calculated with all those <code>wtxid</code> as leaves, in a way similar to the hashMerkleRoot in the block header.
+A <code>witness root hash</code> is calculated with all those <code>wtxid</code> as leaves, in a way similar to the <code>hashMerkleRoot</code> in the block header.
 
-The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is:
+The commitment is recorded in a <code>scriptPubKey</code> of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of <code>0x6a24aa21a9ed</code>, that is:
   
    1-byte - OP_RETURN (0x6a)
    1-byte - Push the following 36 bytes (0x24)
    4-byte - Commitment header (0xaa21a9ed)
-  32-byte - Commitment hash: Double-SHA256(witness root hash|witness nonce)
+  32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)
   
   39th byte onwards: Optional data with no consensus meaning
   
-and the coinbase's input's witness must consist of a single 32-byte array for the witness nonce.
+and the coinbase's input's witness must consist of a single 32-byte array for the <code>witness reserved value</code>.
 
-If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment.
+If there are more than one <code>scriptPubKey</code> matching the pattern, the one with highest output index is assumed to be the commitment.
 
 If all transactions in a block do not have witness data, the commitment is optional.
 
 === Witness program ===
 
-A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
+A <code>scriptPubKey</code> (or <code>redeemScript</code> as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
 
 There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig:
-# Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'')
-# Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. (''"P2SH witness program"'')
+# Triggered by a <code>scriptPubKey</code> that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. (''"native witness program"'')
+# Triggered when a <code>scriptPubKey</code> is a P2SH script, and the BIP16 <code>redeemScript</code> pushed in the <code>scriptSig</code> is exactly a push of a version byte plus a push of a witness program. The <code>scriptSig</code> must be exactly a push of the BIP16 <code>redeemScript</code> or validation fails. (''"P2SH witness program"'')
 
 If the version byte is 0, and the witness program is 20 bytes:
 * It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
@@ -93,9 +93,9 @@ If the version byte is 0, and the witness program is 20 bytes:
 
 If the version byte is 0, and the witness program is 32 bytes:
 * It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
-* The witness must consist of an input stack to feed to the script, followed by a serialized script ("witnessScript").
-* The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.
-* The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
+* The witness must consist of an input stack to feed to the script, followed by a serialized script (<code>witnessScript</code>).
+* The <code>witnessScript</code> (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the <code>witnessScript</code> must match the 32-byte witness program.
+* The <code>witnessScript</code> is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
 * The script must not fail, and result in exactly a single TRUE on the stack.
 
 If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.
@@ -108,7 +108,7 @@ If the version byte is 1 to 16, no further interpretation of the witness program
 
 Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:
 
-''Block cost'' is defined as ''Base size'' * 3 + ''Total size''.
+''Block cost'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>)
 
 ''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.
 
@@ -204,14 +204,13 @@ Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with
 
 === Extensible commitment structure ===
 
-The new commitment in coinbase transaction is a hash of the witness root hash and a witness nonce. The nonce currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in
-coinbase becomes:
+The new commitment in coinbase transaction is a hash of the <code>witness root hash</code> and a <code>witness reserved value</code>. The <code>witness reserved value</code> currently has no consensus meaning, but in the future allows new commitment values for future softforks. For example, if a new consensus-critical commitment is required in the future, the commitment in coinbase becomes:
 
-  Double-SHA256(Witness root hash|Hash(new commitment|witness nonce))
+  Double-SHA256(Witness root hash|Hash(new commitment|witness reserved value))
 
-For backward compatibility, the Hash(new commitment|witness nonce) will go to the coinbase witness, and the witness nonce will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
+For backward compatibility, the <code>Hash(new commitment|witness reserved value)</code> will go to the coinbase witness, and the <code>witness reserved value</code> will be recorded in another location specified by the future softfork. Any number of new commitment could be added in this way.
 
-Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the witness nonce to preserve the ability to do upgrades of the Bitcoin consensus protocol.
+Any commitments that are not consensus-critical to Bitcoin, such as merge-mining, MUST NOT use the <code>witness reserved value</code> to preserve the ability to do upgrades of the Bitcoin consensus protocol.
 
 The optional data space following the commitment also leaves room for metadata of future softforks, and MUST NOT be used for other purpose.
 
@@ -275,19 +274,23 @@ As a soft fork, older software will continue to operate without modification.  N
 
 == Deployment ==
 
-This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit TBD.
+This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1.
 
 For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
 
-For Bitcoin testnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
+For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
 
 == Credits ==
 
 Special thanks to Gregory Maxwell for originating many of the ideas in this BIP and Luke-Jr for figuring out how to deploy this as a soft fork.
 
+== Footnotes ==
+
+<references />
+
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit
+https://github.com/bitcoin/bitcoin/pull/7910
 
 == References ==
 
diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki
index 2da222c..f2c8857 100644
--- a/bip-0144.mediawiki
+++ b/bip-0144.mediawiki
@@ -86,9 +86,10 @@ Currently, the only witness objects type supported are script witnesses which co
 * '''Rationale for the 0x01 flag byte in between''': this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.
 
 === Handshake ===
-A new message 'havewitness' is sent after receiving 'verack' to
-indicate that a node can provide witness if requested (similar to
-'sendheaders') (Note: it might be better to signal this with a services bit in the version message)
+A node will signal that it can provide witnesses using the following service bit
+
+    NODE_WITNESS = (1 << 3)
+	
 
 === Hashes ===
 Transaction hashes used in the transaction merkle tree and txin outpoints are always computed using the old non-witness