Merge pull request bitcoin#712 from mytwocentimes/patch-1

[Trivial]Typos & links fix BIP 151

Author: luke-jr

bip-0151.mediawiki

@@ -18,29 +18,29 @@ This BIP describes an alternative way that a peer can encrypt their communicatio
 == Motivation ==
 
 
-The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer.
+The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoin's trust model, however, for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer.
 
 Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. Today it's trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys (and link with his Google profile, etc.). Just created and broadcasted transactions will reveal the amount and the payee to the network provider.
 
 This BIP also describes a way that data manipulation (blocking commands by a intercepting TCP/IP node) would be identifiable by the communicating peers.
 
 Analyzing the type of p2p communication would still be possible because of the characteristics (size, sending-interval, etc.) of the encrypted messages.
 
-Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanism are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel.
+Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanisms are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel.
 
 == Specification ==
 
 A peer that supports encryption must accept encryption requests from all peers.
 
-A independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction).
+An independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction).
 
 Both peers must only send encrypted messages after a successful ECDH negotiation in ''both directions''.
 
 Encryption initialization must happen before sending any other messages to the responding peer (<code>encinit</code> message after a <code>version</code> message must be ignored).
 
 === Symmetric Encryption Cipher Keys ===
 
-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:
+The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of an 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="bitcoinecdh", ikm=ecdh_secret|cipher-type)</code>.
@@ -59,7 +59,7 @@ Both sides must also calculate the 256bit session-id using <code>SID = HKDF_EXPA
 
 === The <code>encinit</code> message type ===
 
-To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for a <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> interaction for the opposite communication direction.
+To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for an <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> interaction for the opposite communication direction.
 
 {|class="wikitable"
 ! Field Size !! Description !! Data type !! Comments
@@ -90,11 +90,11 @@ The [email protected] specified and defined by openssh [5] combines
 
 <code>K_2</code> must be used in conjunction with poly1305 to build an AEAD.
 
-Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304.
+Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per byte then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304.
 
 === The <code>encack</code> message type ===
 
-The responding peer accepts the encryption request by sending a <code>encack</code> message.
+The responding peer accepts the encryption request by sending an <code>encack</code> message.
 
 {|class="wikitable"
 ! Field Size !! Description !! Data type !! Comments
@@ -150,7 +150,7 @@ If more data is present, another message must be deserialized. There is no expli
 
 === Re-Keying ===
 
-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''.
+A responding peer can inform the requesting peer over a re-keying with an <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(session_id || old_symmetric_cipher_key))</code>.
 
@@ -172,12 +172,12 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code
 
 == References ==
 
-* [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
+* [1] https://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
 * [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869
-* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
-* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
+* [3] ChaCha20 https://cr.yp.to/chacha/chacha-20080128.pdf
+* [4] Poly1305 https://cr.yp.to/mac/poly1305-20050329.pdf
 * [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
-* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
+* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
 
 == Acknowledgements ==
 * Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.