From 876af7fa87945870eaf4ec5bf4b4ec5a01f1f715 Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 10:14:13 -0600 Subject: [PATCH 1/6] add missing change notification and minor corrections --- bip-0047.mediawiki | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index e460a12d..31190403 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,5 +1,7 @@ RECENT CHANGES: +* (12 Oct 2015) Revise blinding method for notification transactions + * (21 Sep 2015) Correct base58check version byte * (18 Sep 2015) Clarify decoding of notification transactions @@ -57,11 +59,15 @@ Hardened derivation is used at this level. Except where noted, all keys derived from a payment code use the public derivation method. +==Standard Payment Codes (v1)== + +===Representation=== + ====Binary Serialization==== A payment code contains the following elements: -* Byte 0: type. required value: 0x01 +* Byte 0: version. required value: 0x01 * Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification ** Bit 0: Bitmessage notification ** Bits 1-7: reserved @@ -233,7 +239,7 @@ A recipient prefers to receive notifications via Bitmessage indiates this prefer * Setting bit 0 of the features byte to 1 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version -* Setting byte 67 of the serialized payment code to the desired Bitmessage stream number +* Setting byte 68 of the serialized payment code to the desired Bitmessage stream number The sender uses this information to construct a valid notification Bitmessage address: From 07ab320513843bf75b55def318d60ced47434548 Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 10:47:44 -0600 Subject: [PATCH 2/6] clarify the various types of child keys derived from an identity --- bip-0047.mediawiki | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 31190403..650c0959 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -31,9 +31,29 @@ Payment codes add identity information to transactions which is useful in a merc We define the following 3 levels in BIP32 path: -
+
 m / purpose' / coin_type' / identity'
-
+ + +The child keys derived from an identity are used in different ways: + + +m / purpose' / coin_type' / identity' / 0 + + +The 0th (non-hardened) child is the notification key. + + +m / purpose' / coin_type' / identity' / 0 through 2147483647 + + +These (non-hardened) keypairs are used for ECDH to generate deposit addresses. + + +m / purpose' / coin_type' / identity' / 0' through 2147483647' + + +These (hardened) keypairs are ephemeral payment codes. Apostrophe in the path indicates that BIP32 hardened derivation is used. From a6f4ae5b5d3a247b6a8f2a8baec7e5b8ed165051 Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 10:28:27 -0600 Subject: [PATCH 3/6] clarify wallet recovery procedure --- bip-0047.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 650c0959..066878bb 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -220,7 +220,9 @@ When querying a public blockchain explorer, wallets SHOULD connect to the explor Previously-spendable funds will generally not be lost or become inaccessible after a recovery from a seed, but all information regarding previous outgoing payments will be lost. -The metadata which a wallet must store regarding the state an identity consists of: +In order to recover received funds from a seed, the wallet must obtain every notification it has ever received to its notification address, including all spent transactions. It then re-establishes its lookahead window for each subchain by scanning every derived address sequentially until it locates a contiguous block of unused addresses of a user-specified length. + +The metadata which a wallet must store to properly process outgoing transactions consists of: # A list of every payment code to which the identity has sent a notification transaction. ## This list is lost if a wallet must be recovered from a seed. From 650fa601ad0fb7b928dbc7c34fb4abe3388e2e5d Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 10:37:43 -0600 Subject: [PATCH 4/6] enumerate the list of script forms which can convey a notification pubkey --- bip-0047.mediawiki | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 066878bb..99b0be21 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -161,6 +161,17 @@ Bitcoins received via notification transactions require special handling in orde # Outputs received to notification addresses MAY be passed through a mixing service before being added to the user's spendable balance. # Outputs received to notification addresses MAY be donated to miners using dust-b-gone or an equivalent procedure. +=====Standard Notification Transaction Scripts===== + +Alice SHOULD use an input script in one of the following standard forms to expose a public key, and compliant applications SHOULD recognize all of these forms. + +* P2PK (pay to pubkey) +* P2PKH (pay to pubkey hash) +* Multisig (bare multisig, without P2SH) +* a script which spends any of the above script forms via P2SH (pay to script hash) + +Compatible wallets MAY provide a method for a user to manually specify the public key associated with a notification transaction in order to recover payment codes sent via non-standard notification transactions. + ====Sending==== # Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows: From 27848f7d6bfa1152c80fb16e8c235a38644e0680 Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 13:40:54 -0600 Subject: [PATCH 5/6] Clarify the definition of identity and the relationship to BIP-44 --- bip-0047.mediawiki | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 99b0be21..50baaac6 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -71,9 +71,17 @@ Hardened derivation is used at this level. ===Identity=== -Identity is a particular extended public/private key pair. The extended public key is a payment code. +The identity derivation level produces an extended public key and its associated extended private key. -Identities SHOULD have 1:1 correspondence with a BIP44 account, as in each BIP44 account in an HD wallet should be assigned exactly one payment code which shares the same index value. +When the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a "payment code." + +This derivation level is equivalent to the Account level in BIP-44. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs. + +For example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0'). + +The second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths. + +Incoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction. Hardened derivation is used at this level. @@ -111,7 +119,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met ====Definitions==== -* Payment code: an extended public key which is associated with a particular identity +* Payment code: an extended public key and associated metadata which is associated with a particular identity/account * Notification address: the P2PKH address associated with the 0th public key derived from a payment code * Notification transaction: a transaction which sends an output to a notification address which includes an embedded payment code From 2f566884f488056c666bdd52805422517254401f Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Fri, 18 Dec 2015 13:48:13 -0600 Subject: [PATCH 6/6] update recent changes --- bip-0047.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 50baaac6..c3c50586 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -1,11 +1,11 @@ RECENT CHANGES: +* (18 Dec 2015) Update explanations to resolve FAQs + * (12 Oct 2015) Revise blinding method for notification transactions * (21 Sep 2015) Correct base58check version byte -* (18 Sep 2015) Clarify decoding of notification transactions - 
   BIP:     47
   Title:   Reusable Payment Codes for Hierarchical Deterministic Wallets