From c51a358a2d52755e98ba111a37b328d50f7db2dd Mon Sep 17 00:00:00 2001 From: Christopher Sanborn <23085117+christophersanborn@users.noreply.github.com> Date: Mon, 24 Sep 2018 11:48:50 -0400 Subject: [PATCH] Added clarification of key roles in Motivation section of 1203. Fixed incorrect bsip numbers in header blocks of 1203, 1204, and 1205. --- bsip-1203.md | 9 +++++++-- bsip-1204.md | 2 +- bsip-1205.md | 2 +- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/bsip-1203.md b/bsip-1203.md index dadad4e..0de96e2 100644 --- a/bsip-1203.md +++ b/bsip-1203.md @@ -1,4 +1,4 @@ - BSIP: 1204 (unassigned) + BSIP: 1203 (unassigned) Title: Blockchain scanning for inbound Stealth transactions Authors: Christopher J. Sanborn Status: Draft @@ -13,7 +13,12 @@ The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sen ## Motivation -A confidential transaction (cTX) does not identify the recipient. As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions. In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance. Transaction reciepts are encrypted data structures that embed the Pedersen commitment of the transaction output (TXO) and a one-time-use key-offset which the recipient uses to derive the private key needed to spend the incoming coin. The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts. +A confidential transaction (cTX) does not identify the recipient. As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions. In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance. Transaction receipts are encrypted data structures that embed the Pedersen commitment of the transaction output and the value and blinding factor that the recipient needs to "open" the commitment. Additionally, the receipt records the one-time public key which the recipient uses to derive the private key offset needed to spend the incoming coin, via a shared-secret procedure between the one-time key and the recipient's address key. The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts. + +_Keys involved in a cTX output (cTXO):_ +* **One-time PubKey (OTK)** — The sender generates this key (public and private) from randomness and uses it to generate a shared-secret between the OTK and the recipient's Address PubKey. The OTK PubKey will be clear-text encoded in the Tx receipt and optionally also recorded in the transaction output. +* **Address PubKey (APK)** — This is a public key encoded in the recipient's stealth address. The goal of a stealth address scheme is to _not_ identify this public key in a transaction output. The APK serves as a base point from which individual Tx output AuthKeys are computed. +* **Tx Output Auth Key (AuthKey)** — This public key will be recorded in the confidential transaction output (cTXO) as the key which is authorized to spend the commitment. This key is offset from the APK by a secret offset that only the sender and recipient can calculate (from the shared secret between OTK and APK). The sender knows only the offset between APK and AuthKey, but not the full secret key to the AuthKey. The recipient, knowing the private key behind the APK, can compute the private key to AuthKey and therefore can spend the commitment. Automated discovery could be enabled if the receipt were embedded within the transaction data structure and if an aspect of that data structure supported a challenge condition which the recipient could recognize. (As one simple option, the ability to decrypt the receipt could be viewed as the challenge condition, although it may not be the most performant.) diff --git a/bsip-1204.md b/bsip-1204.md index 9a0e82a..0bc17dd 100644 --- a/bsip-1204.md +++ b/bsip-1204.md @@ -1,4 +1,4 @@ - BSIP: 1205 (unassigned) + BSIP: 1204 (unassigned) Title: Deterministic addresses for Stealth wallets Authors: Christopher J. Sanborn Status: Draft diff --git a/bsip-1205.md b/bsip-1205.md index a7cac09..3c065a5 100644 --- a/bsip-1205.md +++ b/bsip-1205.md @@ -1,4 +1,4 @@ - BSIP: 1206 (unassigned) + BSIP: 1205 (unassigned) Title: Metadata hiding via Garlic Routing and other means Authors: Christopher J. Sanborn Status: Draft