Tree: 05e96d2500

2015_12_bip1

20160201_status_updates_d2f

20170314-comments

master

patch-1

patch-2

staging

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '05e96d2500'

${ noResults }

Commit Graph

21 Commits (05e96d2500258724f4d2cb04b1d803aea045c6bf)

Author	SHA1	Message	Date
Justus Ranvier	283aa14f77	add version 2 section for bloom filter-based notifications	9 years ago
Justus Ranvier	37a35b5565	add recommended handling for notification tx change outputs	9 years ago
Justus Ranvier	8b11b61981	explain the usage of versions with regards to payment code behavior	9 years ago
Justus Ranvier	97dafa75b3	BIP-0047: Clarify usage and format of outpoints Introduce the terms 'designated input' and 'designated pubkey' for clarity Update reference link for outpoint to a more canonical source	9 years ago
Luke Dashjr	4edd6d2bad	Lots of formatting fixes	9 years ago
Justus Ranvier	2f566884f4	update recent changes	9 years ago
Justus Ranvier	27848f7d6b	Clarify the definition of identity and the relationship to BIP-44	9 years ago
Justus Ranvier	650fa601ad	enumerate the list of script forms which can convey a notification pubkey	9 years ago
Justus Ranvier	a6f4ae5b5d	clarify wallet recovery procedure	9 years ago
Justus Ranvier	07ab320513	clarify the various types of child keys derived from an identity	9 years ago
Justus Ranvier	876af7fa87	add missing change notification and minor corrections	9 years ago
T Dev D	8dcddf5267	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.	9 years ago
Michael Goldstein	565cc313a6	fix typo	9 years ago
Justus Ranvier	b930994728	Improve ECDH and blinding factor calculations 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.	9 years ago
Justus Ranvier	873827d796	BIP-47: correct base58check version byte 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	9 years ago
Justus Ranvier	c375301fa8	BIP-47: Clarify decoding of notification transactions Specify procedure for extracting payment codes from notification transactions. Add explicit check that payment code x values are valid for secp256k1	9 years ago
Justus Ranvier	e700392b15	improve Bitmessage key derivation	9 years ago
Justus Ranvier	2616c9abc3	add mailing list discussion reference	9 years ago
Justus Ranvier	114ed229d3	Correct serialization 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	9 years ago
Justus Ranvier	1612a0016a	BIP-0047: Reusable payment codes 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.	9 years ago