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

Work in API Requirements subsection of Specifications

Browse source
This commit is contained in:
Christopher Sanborn 2018-10-10 14:51:35 -04:00
parent 4772b5a736
commit 792c524b2a
1 changed files with 17 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
bsip-1203.md
View file

@ -114,9 +114,10 @@ _secret = Shared(otk, ViewKey)_
The sender must be careful to leak neither the shared shared secret nor the private _otk_ key.
</li>
<li> Compute the OffsetKey as a child of the ViewKey, indexed by the shared secret:
<li> Compute the OffsetKey as a child of the ViewKey, using a SHA256 hash of the shared secret as a child index:
_offset = ChildOffset(ViewKey,secret)_<br>
_childindex = SHA256(secret)_<br>
_offset = ChildOffset(ViewKey,childindex)_<br>
_OffsetKey = offset*G_
</li>
<li> Compute the AuthKey by summing SpendKey and OffsetKey:
@ -134,9 +135,10 @@ The receiver, having acquired a list of cTXO metadata that includes _OTK_ and _A
_secret = Shared(OTK, viewpriv)_
</li>
<li> Compute the OffsetKey as a child of the ViewKey, indexed by the shared secret:
<li> Compute the OffsetKey as a child of the ViewKey, using a SHA256 hash of the shared secret as a child index:
_offset = ChildOffset(ViewKey,secret)_<br>
_childindex = SHA256(secret)_<br>
_offset = ChildOffset(ViewKey,childindex)_<br>
_OffsetKey = offset*G_
</li>
<li> Recover the public SpendKey by subtracting OffsetKey from AuthKey:
@ -184,11 +186,19 @@ _(TODO: How is this serialized? Do omitted fields "take up space"? Can fields b
### API Requirements to Allow Detection of Inbound Commitments
(Discuss here a proposed API call for retrieving commitments by block height range)
To monitor for incoming transactions to a particular wallet, a wallet need only download sets of `stealth_memo` structures to test for recognition. The full cTXO (including Pedersen commitment, owner structure, range proof, etc.) need not be downloaded. Because the encrypted data inside the memo indicates the Pedersen commitment, the wallet will know which cTXO it has recognized. (Witness nodes index cTXO's by Pedersen commitment.)
(Note: the data returned by this call should also include (or, perhaps this should be a separate call) a list of all commitments that were SPENT in the same block height range. In the case of RingCT this would be a list of key-images used, since with RingCT the network doesn't know which commitments are spent or not.)
(Discuss here a proposed API call for retrieving stealth_memos by block height range)
(Discuss also possible optimizations such as batching historical commitment and spend data into ranges of fixed size (say intervals of 2^17 blocks, representing a little over four days) so that these data-balls can be cached and returned efficiently without the node needing to satisfy a unique query every time.)
To know whether a cTXO is still unspent (e.g. by another instance of the wallet), a wallet could attempt to retrieve the corresponding commitment object from an API node. An empty result indicates the commitment has been spent. However, this procedure indicates our interest in a specific set of commitments, and the network traffic generated runs the risk of revealing that those commitments are "linked".
To prevent this, we propose instead that, in like manner to the downloading of bulk `stealth_memo` structures, that an API call for downloading bulk lists of consumed commitments be implemented, with the download again being over specified block height ranges. A wallet then needs only to test that its own commitments are not on the list of spent commitments.
In the event that ring signatures are implemented for transaction inputs (see [BSIP-1202](bsip-1202.md)), then instead of downloading a list of consumed commitments, we would instead download a list of used key images, which would serve the same purpose.
Because a wallet downloads `stealth_memo` structures in bulk over block height ranges, the wallet never reveals to the network its interest in any specific cTXOs. Thus network interaction for monitoring purposes does not undermine privacy.
NOTE: It is currently possible to retrieve all needed info to support recognition of incoming transactions via Elastic Search queries. This implies: (1) functional wallet behavior can be implemented right away, even if new API calls take longer to implement, and (2) it may be possible to avoid adding new API calls altogether, if the Elastic Search infrastructure is deemed performant enough to support queries from Stealth wallets. (Although intuitively it seems to me an API method would result in a better user experience).
## Discussion