From 87525f24965b7f2e0e9ee05e19f3f585f9bed9f3 Mon Sep 17 00:00:00 2001
From: Christopher Sanborn
<23085117+christophersanborn@users.noreply.github.com>
Date: Tue, 2 Oct 2018 01:04:47 -0400
Subject: [PATCH] BSIP-1203: Explanation of address-per-invoice.
---
bsip-1203.md | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/bsip-1203.md b/bsip-1203.md
index f8b8ec4..56f6430 100644
--- a/bsip-1203.md
+++ b/bsip-1203.md
@@ -69,6 +69,7 @@ In what follows, we detail procedures for two different stealth address formats:
:------:|--------
**CT-style:** | Single public key and checksum. Public key _A_ serves both viewing and spending roles.
Format: `BTSaaaaaaaaaaaaaaaaaaaacccc`
**CryptoNote-style:** | Two public keys plus a checksum. Public key _A_ serves the viewing role and public key _B_ serves the spending role.
Format: `BTSaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbcccc`
+**Invoice Nonce:** | This one encodes a single PubKey serving both the viewing and spending role, but also includes a 64-bit "nonce" or "tag" that the spending wallet is to include in the encrypted memo part of the cTXO, allowing the receiver to interpret payment as being applied to a specific invoice.
Format: `BTSaaaaaaaaaaaaaaaaaaaannnnnnnncccc`
_(In the address formats above we consider the part following the "BTS" identifier to be Base58 encodings of the concatenated byte buffer representations of public keys and checksum bytes. C.f. [Base58Check](https://en.bitcoin.it/wiki/Base58Check_encoding) encoding.)_
@@ -125,6 +126,14 @@ _(TODO: How is this serialized? Do omitted fields "take up space"? Can fields b
## Discussion
+### Utility of dual-key addresses
+
+Utilization of the dual-key address format has numerous interesting use cases, including:
+
+* The ability to maintain **watch-only wallets**. By entrusting only the View Key to a view-only node, it is possible for this node to monitor for activity to an address without granting spending access to the same node. This allows for such things as: opt-in transparency; cash register monitoring; organizational internal auditing, etc.
+
+* The ability to use **address-per-invoice** without introducing substantial additional scanning overhead. To use this, one keeps the same viewing PubKey and iterates the Spending PubKey part of the address, generating a distinct address per invoice. When scanning the blockchain, the _Child Offset_ is a function of the shared-secret between OTK and ViewKey, such that _AuthKey = SpendKey + Offset_. To obtain the public SpendKey, a watching wallet can subtract the Offset from the AuthKey to obtain the SpendKey, and simply compare against a list of per-invoice SpendKeys that were used to generate addresses. Adding additional SpendKeys to scan for does not incur any additional EC group operations, merely additional byte-wise comparisons, which are trivial. _(Note that while the invoice addresses generated in this manner are distinct, they are not unlinkably distinct, since they share the viewing component. If a business wants individual invoices to be mutually unlinkable, then this scheme will not be sufficient. However, this is a consideration for a business's off-chain security practices, as the addresses themselves never appear on-chain or in a transaction.)_
+
### Possible future extensions
#### Additional address formats