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

BSIP-1203: More work in Specification section. Some addition to Shareholder Summary section.

master
Christopher Sanborn 2018-09-30 19:14:48 -04:00
parent fb068e7e1c
commit d489b494bd
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
bsip-1203.md
View File

@ -81,28 +81,24 @@ We assume the address encodes public key _A_, and that the wallet owner is in po
##### Embedding recognizability data in the transaction
Embedding recognizability data in the transaction is an optional, though highly recommended, wallet behavior, so that the receiving wallet can recognize incoming commitments. The network will not reject a transaction which is missing this data, because the [Stealth Phase I (BSIP 0007)](bsip-0007.md) specification called for the receiver to be notified via an out-of-band communication of a "transaction receipt". Nevertheless, the implemented transaction output format contains a field called `stealth_memo` into which this data may be embedded, although the structure of this data has not been formally standardized. (We propose a standard below.)
For the recipient to recognize a cTXO as their own, the cTXO need only to encode two items: 1.) The one-time PubKey (OTK) that the sender generated for shared-secret generation, and, 2.) the authorization PubKey (AuthKey) of the cTXO. Because the AuthKey is computed deterministically from _Shared(OTK,AddrKey)_, it stands that if the recipient can generate the same AuthKey, then the cTXO belongs to them.
Because of the free-form nature of this extra recognizability data, some wallets engage in the very poor behavior of directly identifying the receiving stealth address in the transaction. This, of course, completely negates the unlinkability property provided by stealth addresses, and this behavior should be highly discouraged.
The structure of a cTXO is as follows:
Here is a brief overview of the structure of an individual commitment on the blockchain with associated recognizability data:
[TABLE]
As alluded to above, the existing (bad) practice is to either leave the recognizability data blank (relying on transaction receipts), or to populate the XXXX field with the receiving address public key (negates unlinkability).
We propose the following alternative:
XXXXX
##### Detecting inbound transaction (single-key)
_Field_ | _Purpose_
-------:|:-------
**`commitment`:** | Blinded value commitment   _(EC curve point, 33 bytes)_
**`range_proof`:** | Proof data supporting transaction validity   _(0 to ~5 KiB)_
**`owner`:** | BitShares owner structure specifying weighted list of keys or accounts that may spend this commitment. (Typically lists just one public key, the "AuthKey" for the cTXO.)
**`stealth_memo`:** | Also known as the "transaction receipt" when transmitted off-chain.<br><br> **`one_time_key`:** &nbsp; _(EC curve point, 33 bytes)_<br> **`to`:** &nbsp; Use the AuthKey here! _(EC curve point, 33 bytes)_<br> **`encrypted_memo`:** &nbsp; Data that recipient needs to "open" the commitment.<br><br> _The stealth memo is optional as far as the network is concerned, but essential if you want the recipient to be able to detect the incoming transaction without sending a "receipt."_
Since the `stealth_memo` field can be used to record both the OTK and the AuthKey, all the wallet needs to do to scan for incoming transactions is to download batches of stealth memos and, for each one, test whether the combination of the OTK and the wallet's Address key yields the AuthKey. If it does, then use then derive the AES decryption key from _Shared(OTK,AuthKey)_ and use that to read the additional data in `encrypted_memo`.
#### Procedure for dual-key stealth addresses (CryptoNote-style)
##### Embedding recognizability data in the transaction
##### Detecting inbound transaction (single-key)
##### Detecting inbound transaction (dual-key)
### API Requirements to Allow Detection of Inbound Commitments
@ -143,6 +139,10 @@ Thus, wallet designers should be advised to treat the Output PrivKeys handled by
Although the goal of this BSIP is to support the long-range vision of [Stealth Phase II](bsip-1200.md), the implementation of this BSIP would provide value _right now_, as it would enable the utilization of even the Phase I _Confidential Transactions_ operations without the reliance on burdensome transaction receipts, which are the primary end-user stumbling block to routine Stealth use.
We have detailed in this document procedures for producing recipient-recognizable transaction outputs from stealth addresses. Specifically, we have detailed the procedure for _two_ distinct stealth address formats: a single-key address format which is identical to that which is already in use, and a new dual-key address format which separates the duties of monitoring from spending, and thus allows for watch-only Stealth wallets. Support for the dual-key address format would require no network or consensus changes. It requires only wallet support.
Most of the work needed to implement this BSIP is in the wallet, namely the correct production of recognizable cTXOs and the process of scanning for owned cTXOs. The only network-level change is the addition of two API calls: one to return batches of `stealth_memo` fields included in a block range, and one to return batches of consumed commitments (in the case of CT transactions) or used key-images (in the case of RingCT transactions). These API calls would need to be available on wallet-serving API nodes, but would not be needed on block-producing witness nodes. There are no consensus changes proposed in this document.
## Copyright
This document is placed in the public domain.