From 8b11b6198144e499590d0f70b4f5681b5ded03ee Mon Sep 17 00:00:00 2001 From: Justus Ranvier Date: Tue, 19 Apr 2016 13:01:55 -0500 Subject: [PATCH] explain the usage of versions with regards to payment code behavior --- bip-0047.mediawiki | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki index 0720eb40..248fabca 100644 --- a/bip-0047.mediawiki +++ b/bip-0047.mediawiki @@ -84,7 +84,19 @@ 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)== +==Versions== + +Payment codes contain a version byte which identifies a specific set of behavior. + +Unless otherwise specified, payment codes of different versions are interoperable. If Alice uses a version x payment code, and Bob uses a version y payment code, they can still send and receive transactions between each other. + +Currently specified versions: + +* Version 1 +** Address type: P2PKH +** Notification type: address + +==Version 1== ===Representation=== @@ -127,6 +139,8 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure: +Note: this procedure is used if Bob uses a version 1 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification. + # 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: