From 219b17a8aaa1b9418c1829c129fc1c2de1bfd189 Mon Sep 17 00:00:00 2001 From: Christopher Sanborn <23085117+christophersanborn@users.noreply.github.com> Date: Wed, 17 Oct 2018 12:58:47 -0400 Subject: [PATCH] Updated numbering in bsip-1203 to match assigned numbering. --- bsip-1203.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bsip-1203.md b/bsip-1203.md index 29736fd..44ef1ec 100644 --- a/bsip-1203.md +++ b/bsip-1203.md @@ -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)