| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Finalize BIP-47
|
|
BIP47: Missing word
|
|
|
|
The original implementation of BIP-47 in Samourai Wallet reversed
the parameters in the calculation of the HMAC-SHA512 step of
notification transaction blinding.
This change adjusts the text to match the as-implementend behavior
in deployed BIP-47 wallets and the test vectors.
|
|
|
|
|
|
|
|
|
|
|
|
Affects: BIPs 38, 39, 42, 44, 47, 60, 61, 74, 75, 90, 150, 151, 152
|
|
- 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
|
|
|
|
|
|
|
|
|
|
Introduce the terms 'designated input' and 'designated pubkey' for clarity
Update reference link for outpoint to a more canonical source
|
|
Add link to BIP47 test vectors
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Specify procedure for extracting payment codes from notification transactions.
Add explicit check that payment code x values are valid for secp256k1
|
|
|
|
|
|
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.
|
