- Make Abstract more readable
- Update Sender definition and acronym descriptions
- Added comments to ReturnPaymentRequest definition
- Bold ECDH and AES Setup notes and added "(see below)" for reference
- Removed Requestor/Responder definitions
- Seperated ECDH secret point generation and AES-256 (CBC Mode) setup from individual steps (listed twice) and created it's own section
- Added InvoiceRequest Validation section
Results obtained upon implementing BIP47 for Samourai Wallet. Payment codes are calculated assuming v1 specification without use of BitMessage. Also assumes notification transaction from Alice to Bob has been sent.
Previously BIP-0001 listed in its header preamble that is was a "Standards Track"
type proposal. This conflicts with both its own definition of "Standards Track"
proposal as well as the type listed in PEP-0001 of which BIP-0001 is based on.
Defitions of each type of proposal:
A Standards Track BIP describes any change that affects most or all Bitcoin implementations.
An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature.
A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process.
Specifically: "Any meta-BIP is also considered a Process BIP."
Based on these definitions BIP-0001 should have always been labeled as a "Process" BIP and this patch corrects this.
From the text: "Some Informational and Process BIPs may also have a
status of "Active" if they are never meant to be completed. E.g. BIP 1
(this BIP)."
