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)