agorise
/
bsips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added clarification of key roles in Motivation section of 1203. Fixed incorrect bsip numbers in header blocks of 1203, 1204, and 1205.

master
Christopher Sanborn 2018-09-24 11:48:50 -04:00
parent 00e3c38ebf
commit c51a358a2d
3 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
bsip-1203.md
View File

@ -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.)

2
bsip-1204.md
View File

@ -1,4 +1,4 @@
BSIP: 1205 (unassigned)
BSIP: 1204 (unassigned)
Title: Deterministic addresses for Stealth wallets
Authors: Christopher J. Sanborn
Status: Draft

2
bsip-1205.md
View File

@ -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