3.3 KiB
BSIP: 1204 (unassigned)
Title: Blockchain scanning for inbound Stealth transactions
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>
Abstract
The existing Stealth implementation (BSIP-0008) 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), 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
Summary for Shareholders
Copyright
This document is placed in the public domain.