Update bip-0070.mediawiki

Slightly re-worded description of the signature field in PaymentRequest

The previous phrasing confused me and I had to check the Bitcoin Core source code to see what it was expecting for a signature.
Update bip-0038.mediawiki

Fix some erroneous statements in the description of the math used for encryption/decryption of EC-Multiplied keys/addresses
Add test case for UTF8 NFC normalization
Add normalization note on test case
Attempt to put the actual characters in the source file
Replaced example domain name with example.com.
Added file size limits for Payment and PaymentACK messages.
Added note about handling multiple copies of a Payment message, to ensure resend is safe
in case of a transport layer failure.
Added reference to RFC 2616 to BIP0072.
Added note about handling HTTP statuses which are neither error nor success.
Expanded and clarified wording on recovering from error states when sending payment to the merchant's server.
Update bip-0070.mediawiki

Change "zero-byte placeholder" to "empty string"
Loosened URL validity period on payment requests.
Update bip-0070.mediawiki

Revised final sentence of signature field description.
Small typo
Validate a payment request is still valid prior to payment

Currently there exists the potential for a user to load a payment request into
their wallet which is valid at that time but its expiration lapses prior to
the user authorizing the payment. This could lead to an unnecessary customer
service interaction.
Disambiguate Which Key Is Compromised When Ext. PubKey + PrivKey Are Leaked

I mistakenly inferred from the following clause that a parent extended
public key plus a child private key would be equivalent to knowing the
extended *child* private key---meaning that the *parent* private key was
still secure:

> knowledge of the extended public key + any non-hardened private key
> descending from it is equivalent to knowing the extended private key

This patch's addition of the word "parent" (twice) removes the ambiguity
and may help other readers draw the correct inference that the parent
private key is no longer secure in this case.

I also changed "+" to "plus" to avoid confusion with the actual
mathematical operations used in this BIP.
Merge pull request #41 from harding/master

Clarification of how to construct the PaymentRequest signature
Merge pull request #54 from rnicoll/bip0070-limits

BIP0070 limits and error handling
Merge pull request #60 from aalness/aalness_bip70

Validate a payment request is still valid prior to payment