summaryrefslogtreecommitdiff
path: root/bip-0047.mediawiki
diff options
context:
space:
mode:
authorJustus Ranvier <justusranvier@riseup.net>2016-04-17 09:20:46 -0500
committerJustus Ranvier <justusranvier@riseup.net>2016-04-17 09:52:53 -0500
commit97dafa75b32249adce8c6d02fdb56b3f28f0e24d (patch)
tree9c0747d4338d4816718a8bb124f2da8195c74a6b /bip-0047.mediawiki
parent3ff0772bb2ca4260d0cb8aadcd3c078a4c8972f8 (diff)
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
Diffstat (limited to 'bip-0047.mediawiki')
-rw-r--r--bip-0047.mediawiki15
1 files changed, 9 insertions, 6 deletions
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index bdac681..0720eb4 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,7 +1,7 @@
RECENT CHANGES:
+* (17 Apr 2016) Clarify usage of outpoints in notification transactions
* (18 Dec 2015) Update explanations to resolve FAQs
* (12 Oct 2015) Revise blinding method for notification transactions
-* (21 Sep 2015) Correct base58check version byte
<pre>
BIP: 47
@@ -119,6 +119,9 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met
* 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 0<sup>th</sup> 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
+* Designated input: the first input in the notification transaction which exposes an secp256k1 pubkey in either its signature script, or in the redeem script or pubkey script of the output being spent
+* Designated pubkey: the first secp256k1 pubkey pushed to the stack during script execution for the designated input
+* Outpoint: the specific output of a previous transaction which is being spent. See the Reference section for the binary serialization
====Notification Transaction====
@@ -127,12 +130,12 @@ Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform
# Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction)
## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address
# Alice derives a unique shared secret using ECDH:
-## Alice selects the private key corresponding to the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>a</pre>
+## Alice selects the private key corresponding to the designated pubkey: <pre>a</pre>
## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre>
## Alice calculates a secret point: <pre>S = aB</pre>
## Alice calculates a 64 byte 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 first pubkey-exposing input of the transaction.
+### "o" is the outpoint being spent by the designated input
# Alice serializes her payment code in binary form.
# Alice renders her payment code (P) unreadable to anyone except Bob:
## Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre>
@@ -143,12 +146,12 @@ Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform
# Bob watches for any transactions which create an output at his notification address.
# When a transaction is received, the client examines it to determine if it contains a standard OP_RETURN output with an 80 byte payload (notification transactions).
# If the first byte of the payload in a notification transaction is 0x01:
-## Bob selects the first exposed public key, of the first pubkey-exposing input, of the transaction: <pre>A, where A = aG</pre>
+## 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>
### "x" is the x value of the secret point
-### "o" is the outpoint being spent by the first pubkey-exposing input of the transaction.
+### "o" is the outpoint being spent by the designated input.
## Bob interprets the 80 byte payload as a payment code, except:
### Replace the x value with x': <pre>x' = x XOR (first 32 bytes of s)</pre>
### Replace the chain code with c': <pre>c' = c XOR (last 32 bytes of s)</pre>
@@ -300,7 +303,7 @@ In order to use Bitmessage notification, the recipient must have a Bitmessage cl
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
-* [[https://bitcoin.org/en/glossary/outpoint|Outpoint]]
+* [[https://bitcoin.org/en/developer-reference#outpoint|Outpoint]]
* [[https://github.com/petertodd/dust-b-gone|dust-b-gone]]
* [[https://en.bitcoin.it/wiki/Base58Check_encoding|Base58Check encoding]]
* [[https://bitmessage.org/bitmessage.pdf|Bitmessage]]