diff options
Diffstat (limited to 'bip-0047.mediawiki')
| -rw-r--r-- | bip-0047.mediawiki | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index e16dd7f..af801f9 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -8,7 +8,7 @@ RECENT CHANGES: Layer: Applications Title: Reusable Payment Codes for Hierarchical Deterministic Wallets Author: Justus Ranvier <justus@openbitcoinprivacyproject.org> - Comments-Summary: No comments yet. + Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047 Status: Draft Type: Informational @@ -174,7 +174,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of ## Bob selects the designated pubkey: <pre>A, where A = aG</pre> ## Bob selects the private key associated with his notification address: <pre>b</pre> ## Bob calculates a secret point: <pre>S = bA</pre> -## Bob calculates the binding factor: <pre>s = HMAC-SHA512(x, o)</pre> +## Bob calculates the blinding factor: <pre>s = HMAC-SHA512(x, o)</pre> ### "x" is the x value of the secret point ### "o" is the outpoint being spent by the designated input. ## Bob interprets the 80 byte payload as a payment code, except: @@ -218,7 +218,7 @@ The following actions are recommended to reduce this risk: ====Sending==== -# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH follows: +# Each time Alice wants to initiate a transaction to Bob, Alice derives a unique P2PKH address for the transaction using ECDH as follows: ## Alice selects the 0th private key derived from her payment code: <pre>a</pre> ## Alice selects the next unused public key derived from Bob's payment code, starting from zero: <pre>B, where B = bG</pre> ### The "next unused" public key is based on an index specific to the Alice-Bob context, not global to either Alice or Bob @@ -312,7 +312,7 @@ A recipient specifies their preference for alternate notification by setting the ===Bitmessage Notification=== -A recipient prefers to receive notifications via Bitmessage indiates this preference by: +A recipient which prefers to receive notifications via Bitmessage indicates this preference by: * Setting bit 0 of the features byte to 1 * Setting byte 67 of the serialized payment code to the desired Bitmessage address version |