| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
