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 Title: Blockchain scanning for inbound Stealth transactions
Authors: Christopher J. Sanborn Authors: Christopher J. Sanborn
Status: Draft 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. 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. 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 ## 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. 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 ## 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) * [bitshares-stealth-k](https://github.com/Agorise/bitshares-stealth-k) - A Kotlin library for Stealth support in BitShares (in _very_ early development stage)