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

bsip1203 minor phrasing fixes

Browse source
This commit is contained in:
Christopher Sanborn 2018-10-05 11:38:11 -04:00
parent 4383ef74a7
commit b0b0be9592
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
bsip-1203.md
View file

@ -13,20 +13,20 @@ The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sen
## Motivation
"Stealth addresses" are a method of providing _unlinkability_ to blockchain transactions. Unlinkability is a major component of the "Privacy Triad": _unlinkability_, _confidentiality_, and _untraceability_. Using a stealth address, a sending wallet is able to compute a "child" public key that derives from the public key specified in the address, but which cannot be correlated, or "linked", to the address public key except by the sender and the receiver. This child key is what is used for the transaction outputs (TXOs). As such, third party observers cannot link TXOs to addresses, nor even link together TXOs which are "controlled" by the same address.
"Stealth addresses" are a method of providing _unlinkability_ to blockchain transactions. Unlinkability is a major component of the Privacy Triad: _unlinkability_, _confidentiality_, and _untraceability_. Using a stealth address, a sending wallet is able to compute a child public key that derives from a public key encoded in the address, but which cannot be correlated, or "linked", to the address public key, unless you are either the sender or the receiver. This child key becomes the authorization key for transaction outputs (TXOs) intended for the receiver. As such, third party observers cannot link TXOs to addresses, nor even link together independent TXOs which are "controlled" by the same address.
Although this is a great benefit to privacy, it complicates the matter of detecting inbound transactions, since a wallet cannot simply scan for transactions which explicitly identify the destination address.
Existing [Stealth Phase I](bsip-0008.md) functionality already includes the use of stealth addresses, but does not include a solution for detection of inbound transactions. As a result of which, user adoption of the Stealth feature has been very minimal. We propose below a solution to inbound transaction detection as well as some additional enhancements to the stealth addressing scheme.
Existing [Stealth Phase I](bsip-0008.md) functionality already includes the use of stealth addresses, but does not include a solution for detection of inbound transactions. As a result of which, user adoption of the Stealth feature has been very minimal. We propose below a solution to inbound transaction detection as well as some additional enhancements to the stealth addressing scheme, including a proposed new address format that allows for watch-only wallets.
## Rationale
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.
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 must use 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.
* **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 to enable automated discovery.
* **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.
* **Tx Output Authorization 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.