12 KiB
BSIP: 1203 (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 receipts are encrypted data structures that embed the Pedersen commitment of the transaction output and the value and blinding factor that the recipient needs to "open" the commitment. Additionally, the receipt records the one-time public key which the recipient uses to derive the private key offset needed to spend the incoming coin, via a shared-secret procedure between the one-time key and the recipient's address key. The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts.
Keys involved in a cTX output (cTXO):
- One-time PubKey (OTK) — The sender generates this key (public and private) from randomness and uses it to generate a shared-secret between the OTK and the recipient's Address PubKey. The OTK PubKey will be clear-text encoded in the Tx receipt and optionally also recorded in the transaction output.
- Address PubKey (APK) — This is a public key encoded in the recipient's stealth address. The goal of a stealth address scheme is to not identify this public key in a transaction output. The APK serves as a base point from which individual Tx output AuthKeys are computed.
- Tx Output Auth Key (AuthKey) — This public key will be recorded in the confidential transaction output (cTXO) as the key which is authorized to spend the commitment. This key is offset from the APK by a secret offset that only the sender and recipient can calculate (from the shared secret between OTK and APK). The sender knows only the offset between APK and AuthKey, but not the full secret key to the AuthKey. The recipient, knowing the private key behind the APK, can compute the private key to AuthKey and therefore can spend the commitment.
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
We specify two protocols. In the first subsection we will specify wallet behaviors for (1) creating transaction outputs that can be recognized by their recipients, and (2) recognizing transaction outputs that are destined to the wallet. In the second subsection we propose a new API call for querying nodes for transaction outputs to be scanned for recognizable markers.
Wallet procedure for recognizing own commitments
Assumptions:
- Wallet has access to a set of private keys corresponding to stealth addresses which may own commitments on the blockchain. These private keys are needed to "recognize" incoming transactions.
- Wallet can query an API node for commitments occurring between specified block heights, to obtain a set to scan for owned commitment. (See below for this process.)
In what follows, we detail procedures for two different stealth address formats: one which encodes a single public key, and one which encodes two public keys. The two formats serve a similar purpose of allowing for unlinkable transactions, but the dual-key format allows for watch-only wallets, whereas the single-key format does not. The single key format is borrowed from Confidential Transactions, whereas the dual-key format is standard in CryptoNote-based coins such as Monero.
The dual-key format separates the duties of spending a commitment from those of reading the commitment, such that a person in possession of only the "viewing key" (the private key corresponding to the additional pubkey in the address) can discover, interpret, and tally incoming transactions, but cannot spend them. The "spending key" (private key corresponding to the primary pubkey in the address) is needed to authorize the spending of a commitment. The dual-key address format and signing procedures are described in detail in [vS13] and reviewed below.
Procedure for single-key stealth addresses (CT-style)
A short, single-key stealth address (of the type used in Confidential Transactions) has format:
BTSaaaaaaaaaaaaaaaaaaaacccc
where BTS is a format identifier specifying a BitShares PubKey address format, and aaaa...cccc is the base58check encoding of a public key A concatenated with four checksum bytes. (C.f. Base58Check encoding, but note that we omit the version byte used in Bitcoin addresses.)
We assume the address encodes public key A, and that the wallet owner is in posession of (A, a), where a is the corresponding private key.
Embedding recognizability data in the transaction
Embedding recognizability data in the transaction is an optional, though highly recommended, wallet behavior, so that the receiving wallet can recognize incoming commitments. The network will not reject a transaction which is missing this data, because the Stealth Phase I (BSIP 0007) specification called for the receiver to be notified via an out-of-band communication of a "transaction receipt". Nevertheless, the implemented transaction output format contains a field called stealth_memo into which this data may be embedded, although the structure of this data has not been formally standardized. (We propose a standard below.)
Because of the free-form nature of this extra recognizability data, some wallets engage in the very poor behavior of directly identifying the receiving stealth address in the transaction. This, of course, completely negates the unlinkability property provided by stealth addresses, and this behavior should be highly discouraged.
Here is a brief overview of the structure of an individual commitment on the blockchain with associated recognizability data:
[TABLE]
As alluded to above, the existing (bad) practice is to either leave the recognizability data blank (relying on transaction receipts), or to populate the XXXX field with the receiving address public key (negates unlinkability).
We propose the following alternative:
XXXXX
Detecting inbound transaction (single-key)
Procedure for dual-key stealth addresses (CryptoNote-style)
Embedding recognizability data in the transaction
Detecting inbound transaction (single-key)
API Requirements to Allow Detection of Inbound Commitments
(Discuss here a proposed API call for retrieving commitments by block height range)
(Note: the data returned by this call should also include (or, perhaps this should be a separate call) a list of all commitments that were SPENT in the same block height range. In the case of RingCT this would be a list of key-images used, since with RingCT the network doesn't know which commitments are spent or not.)
(Discuss also possible optimizations such as batching historical commitment and spend data into ranges of fixed size (say intervals of 2^17 blocks, representing a little over four days) so that these data-balls can be cached and returned efficiently without the node needing to satisfy a unique query every time.)
Pitfalls and Cautions
An attack on address key from leak of a transaction private key
A confidential output will have associated with it an "Output PubKey." He who can provide a signature from that PubKey is authorized to spend the commitment. Automated detection of inbound commitments depends on the deterministic computation of an offset between the One-time PubKey and the Address PubKey, which is computed from the shared secret between the sender and receiver. Because only the offset is deterministic, the sender cannot compute the private key to the Output PubKey. Only the receiver can do this (by knowing both the offset and the Address private key).
Because Output PubKeys are only used once, wallet software designers may be led to believe that the security of the Output PrivKeys are only important up until the commitment is spent. (What would it matter, to leak that private key, when the commitment it authorizes is no longer spendable?) This would be a mistake, however, because anyone who can compute the additive offset can subtract it from the Output PrivKey to reveal the Address PrivKey. Although the general public is not expected to be privy to that offset, the sender of the output is in posession of the offset (and the ability to compute it due to knowing the random k behind the One-time PubKey). This means the sender can compute the Address PrivKey, in the event that the recipient leaks the Output PrivKey.
Thus, wallet designers should be advised to treat the Output PrivKeys handled by their wallets with at least as much care as the Address PrivKeys, even long after the commitments they authorize have been spent. A leak of a single commitment's PrivKey is tantamount to a leak of the PrivKey for the entire wallet.
(A similar risk of revealing a parent PrivKey from leak of a child PrivKey and parent XPUB when using non-hardened derivation is noted in the Bitcoin BIP-32 protocol for Hierarchical Deterministic Wallets.)
Discussion
Summary for Shareholders
Copyright
This document is placed in the public domain.
References
[vS13] - Nicolas van Saberhagen, Cryptonote v 2.0, 2013 - https://cryptonote.org/whitepaper.pdf