Merge remote-tracking branch 'upstream/master'

Added:

- Versioning
- Cancellation
- Add UNKNOWN_TYPE to ProtocolMessageType enum in paymentrequest.proto
  and BIP75 text (based on suggestions from
  http://androiddevblog.com/protocol-buffers-pitfall-adding-enum-values/)

  Updated:

  - Additional pki_type values
  - Updated status_code values
  - Update BIP75 Motivation and use cases to provide more color around
    reasoning and use of BIP75

    NOTE: The BIP75 language no longer contains a description of the KYC
    compliance use case, as it is a single, very specific use-case that
    does not have any bearing on the technical specifications herein.
    BIP75 extends the original BIP70 Payment Protocol to become a
    two-way, encrypted messaging process, which can be used for a
    variety of reasons one of which is regulatory compliance.

1 files changed, 2 insertions, 2 deletions

diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki
index a4c8b8e..cf221f2 100644
--- a/bip-0151.mediawiki
+++ b/bip-0151.mediawiki
@@ -39,7 +39,7 @@ Encryption initialization must happen before sending any other messages to the r
 The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification:
 
 1. HKDF extraction
-<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinechd", ikm=ecdh_secret|cipher-type)</code>.
+<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type)</code>.
 
 2. Derive Key1
 <code>K_1 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK1", L=32)</code>
@@ -148,7 +148,7 @@ If more data is present, another message must be deserialized. There is no expli
 
 A responding peer can inform the requesting peer over a re-keying with a <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''.
 
-The new symmetric cipher key will be calculated by <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
+The new symmetric cipher key will be calculated by <code>SHA256(SHA256(session_id || old_symmetric_cipher_key))</code>.
 
 Re-Keying interval is a peer policy with a minimum timespan of 10 seconds.