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

Updated numbering in bsip-1203 to match assigned numbering.

Browse source
This commit is contained in:
Christopher Sanborn 2018-10-17 12:58:47 -04:00
parent 792c524b2a
commit 219b17a8aa
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
bsip-1203.md
View file

@ -1,4 +1,4 @@
BSIP: 1203 (unassigned)
BSIP: 0053
Title: Blockchain scanning for inbound Stealth transactions
Authors: Christopher J. Sanborn
Status: Draft
@ -194,7 +194,7 @@ To know whether a cTXO is still unspent (e.g. by another instance of the wallet)
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.
In the event that ring signatures are implemented for transaction inputs (see [BSIP-0052](bsip-0052.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.
@ -242,7 +242,7 @@ Thus, wallet designers should be advised to treat the private TXO AuthKeys handl
## Summary for Shareholders
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.
Although the goal of this BSIP is to support the long-range vision of [Stealth Phase II](bsip-0050.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.
@ -260,5 +260,5 @@ This document is placed in the public domain.
## See Also
* Overview of _Stealth Phase II_ - [BSIP-1200](bsip-1200.md)
* Overview of _Stealth Phase II_ - [BSIP-0052](bsip-0052.md)
* [bitshares-stealth-k](https://github.com/Agorise/bitshares-stealth-k) - A Kotlin library for Stealth support in BitShares (in _very_ early development stage)