- Update all Accepted status to Proposed (renamed status)
- The BIP Comments preamble headers added to every BIP
- The License preamble headers have been added to all BIPs with a Copyright 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.
The blinding factor used for notification transactions incorporates and outpoint being spent by the notification transaction.
This ensures that blinding factors will always be unique, even if a user sends a notification transaction to the same recipient multiple times while spending funds from the same address.
Since some common EC libraries have ECDH functions that only return the x value of the resulting point, only use the x value for calculating scalar shared secrets.
Previously specified version byte only produced the desired leading character if the check bytes were omitted
Thanks to TD from Samourai Wallet for pointing this out
Since the length of the data encoded by base58check affects the version
byte needed to produce a desired leading character, fix the length of
the payment code at 80 bytes, and correct the version byte to 0x23
Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses which provide useful features such as positively identifying
senders to recipients and automatically providing for transaction refunds.
Payment codes can be publicly advertised and associated with a real-life
identity without causing a loss of financial privacy.
Compared to stealth addresses, payment codes require less blockchain data
storage.
Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair,
while stealth addresses require 40 bytes per transaction.
