summaryrefslogtreecommitdiff
path: root/bip-0047.mediawiki
AgeCommit message (Collapse)Author
2016-04-19add version 2 section for bloom filter-based notificationsJustus Ranvier
2016-04-19add recommended handling for notification tx change outputsJustus Ranvier
2016-04-19explain the usage of versions with regards to payment code behaviorJustus Ranvier
2016-04-17BIP-0047: Clarify usage and format of outpointsJustus Ranvier
Introduce the terms 'designated input' and 'designated pubkey' for clarity Update reference link for outpoint to a more canonical source
2016-02-24Merge pull request #257 from SamouraiDev/SamouraiDev-patch-1Luke-Jr
Add link to BIP47 test vectors
2016-02-03Lots of formatting fixesLuke Dashjr
2015-12-18update recent changesJustus Ranvier
2015-12-18Clarify the definition of identity and the relationship to BIP-44Justus Ranvier
2015-12-18enumerate the list of script forms which can convey a notification pubkeyJustus Ranvier
2015-12-18clarify wallet recovery procedureJustus Ranvier
2015-12-18clarify the various types of child keys derived from an identityJustus Ranvier
2015-12-18add missing change notification and minor correctionsJustus Ranvier
2015-12-04Add link to BIP47 test vectorsT Dev D
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.
2015-11-23fix typoMichael Goldstein
2015-10-12Improve ECDH and blinding factor calculationsJustus Ranvier
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.
2015-09-21BIP-47: correct base58check version byteJustus Ranvier
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
2015-09-18BIP-47: Clarify decoding of notification transactionsJustus Ranvier
Specify procedure for extracting payment codes from notification transactions. Add explicit check that payment code x values are valid for secp256k1
2015-07-10improve Bitmessage key derivationJustus Ranvier
2015-07-10add mailing list discussion referenceJustus Ranvier
2015-07-10Correct serializationJustus Ranvier
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
2015-07-10BIP-0047: Reusable payment codesJustus Ranvier
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.