Merging BSIP 1203 content into BSIP 1204, in preparation to remove 1203.

bsip-1203.md

@@ -7,6 +7,10 @@
     Discussion: <url>
 
 
+## Deprecation
+
+The proposal of this BSIP is now merged into the BSIP titled "Blockchain scanning for inbound Stealth transactions".   This file will soon be removed.
+
 ## Abstract
 
 To extend the WebSocket API to include a method to retrieve Confidential (blind or stealth) UTXO sets by block-height range.

bsip-1204.md

@@ -9,9 +9,22 @@
 
 ## Abstract
 
-A confidential (blind or stealth) transaction (CTXO) does not identify the recipient.  As such, there is no direct way for a wallet to query the p2p network for inbound transactions.  Instead, a wallet must either (a) inspect all CTXOs and test a challenge condition on each one, or (b) transmit to the p2p node some kernel of the challenge so that the p2p node can select an inclusive CTXO set. The latter option likely undermines unlinkability.  At present, the WS API offers no mechanism for retrieving whole sets of CTXOs between certain block-height ranges, thus a wallet must know the Pedersen commitment of CTXO that they are interested in. This is the reason for transaction receipts.  Lost or untransmitted receipts can result in lost funds.  It is proposed that the Witness Node component be updated to (a) index not just the Pedersen commitments, but also the stealth memo and/or range proof fields of CTXOs, and (b) afford an API method to retrieve CTXOs in a specified block range, so that wallets can scan and identify inbound transactions.  This will obviate the need for both receipt transmission and receipt storage by sender and recipient. The stealth memo format may also need updating to support challenge tests.
+The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sender to manually communicate *transaction receipts* to the recipients of each transaction to alert them to the presence of an inbound balance transfer, creating a danger of lost funds due to miscommunicated or lost receipts. This BSIP explores options for automated discovery of inbound transactions while still preserving fundamental privacy features of unlinkability and anonymity.
 
 ## Motivation
+
+A confidential transaction (cTX) does not identify the recipient.  As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions.  In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance.  Transaction reciepts are encrypted data structures that embed the Pedersen commitment of the transaction output (TXO) and a one-time-use key-offset which the recipient uses to derive the private key needed to spend the incoming coin.  The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts.
+
+Automated discovery could be enabled if the receipt were embedded within the transaction data structure and if an aspect of that data structure supported a challenge condition which the recipient could recognize.  (As one simple option, the ability to decrypt the receipt could be viewed as the challenge condition, although it may not be the most performant.)
+
+The current implementation already allows, but does not require, receipts to be embedded in the transactions.  Additionally, an existing cleartext field allows (but does not require) the recipient to be identified via their blind address, which could serve to alert the recipient, but at the steep expense of sacrificing unlinkability and anonymity.
+
+It is proposed to repurpose and perhaps extend the cleartext fields to contain a challenge condition, rather than cleartext address, which recipients can efficiently use to flag inbound transactions while still maintaining unlinkability and anonymity.
+
+To support this, a wallet will need to either (a) inspect all cTX activity on the network and test the challenge conditions on each transaction, or (b) transmit to the API node some kernel of the challenge so that the API node can select an inclusive cTXO set on behalf of the wallet. (The latter option likely undermines unlinkability, although it would lessen the burden on the receiving wallet.)
+
+Additionally, the WS/RPC API offered by network nodes will need to be extended to support returning ranges of cTXOs occuring within specified block ranges, so that wallets can scan them.  (Currently, cTXOs can *only* be looked up by Pedersen commitment, which for a new inbound transaction, would not yet be known to the wallet.)
+
 ## Rationale
 ## Specifications
 ## Discussion