slackcoder/bips - Bitcoin Improvement Proposals

Age	Commit message (Collapse)	Author
2016-04-19	add version 2 section for bloom filter-based notifications	Justus Ranvier

2016-04-19	add recommended handling for notification tx change outputs	Justus Ranvier

2016-04-19	explain the usage of versions with regards to payment code behavior	Justus Ranvier

2016-04-17	BIP-0047: Clarify usage and format of outpoints	Justus Ranvier
	Introduce the terms 'designated input' and 'designated pubkey' for clarity Update reference link for outpoint to a more canonical source
2016-02-24	Merge pull request #257 from SamouraiDev/SamouraiDev-patch-1	Luke-Jr
	Add link to BIP47 test vectors
2016-02-03	Lots of formatting fixes	Luke Dashjr

2015-12-18	update recent changes	Justus Ranvier

2015-12-18	Clarify the definition of identity and the relationship to BIP-44	Justus Ranvier

2015-12-18	enumerate the list of script forms which can convey a notification pubkey	Justus Ranvier

2015-12-18	clarify wallet recovery procedure	Justus Ranvier

2015-12-18	clarify the various types of child keys derived from an identity	Justus Ranvier

2015-12-18	add missing change notification and minor corrections	Justus Ranvier

2015-12-04	Add link to BIP47 test vectors	T 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-23	fix typo	Michael Goldstein

2015-10-12	Improve ECDH and blinding factor calculations	Justus 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-21	BIP-47: correct base58check version byte	Justus 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-18	BIP-47: Clarify decoding of notification transactions	Justus Ranvier
	Specify procedure for extracting payment codes from notification transactions. Add explicit check that payment code x values are valid for secp256k1
2015-07-10	improve Bitmessage key derivation	Justus Ranvier

2015-07-10	add mailing list discussion reference	Justus Ranvier

2015-07-10	Correct serialization	Justus 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-10	BIP-0047: Reusable payment codes	Justus 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.