agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Rephrasing in the Specifications section. Discussion of some future address extensions in the Discussion section.

Browse source
This commit is contained in:
Christopher Sanborn 2018-09-30 14:13:58 -04:00
parent 7ebd6ac361
commit f3ee7999f7
1 changed files with 30 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
bsip-1203.md
View file

@ -41,7 +41,11 @@ To support this strategy, a wallet will need to inspect all cTX activity on the
## 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.
We specify two protocols. In the first subsection, [_Wallet procedure..._](#wallet-procedure-for-recognizing-own-commitments), we specify the recognition protocol by detailing wallet behaviors for:
* Creating transaction outputs that can be recognized by their recipients, and,
* Recognizing transaction outputs that are destined to the wallet.
And in the second subsection, [_API requirements..._](#api-requirements-to-allow-detection-of-inbound-commitments), we propose a new API call for querying nodes for transaction outputs to be scanned for recognizable markers. This is an added feature for API nodes and does not involve any consensus changes.
### Wallet procedure for recognizing own commitments
@ -50,18 +54,22 @@ Assumptions:
1. 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.
2. Wallet can query an API node for commitments occurring between specified block heights, to obtain a set to scan for owned commitment. ([See below](#api-requirements-to-allow-detection-of-inbound-commitments) 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.
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 borrowed from CryptoNote-based coins such as Monero.
**Address Formats:**
  | Format:
:------:|--------
**CT-style:** | Single public key and checksum. Public key _A_ serves both viewing and spending roles.<br><br> Format: `BTSaaaaaaaaaaaaaaaaaaaacccc`
**CryptoNote-style:** | Two public keys plus a checksum. Public key _A_ serves the viewing role and public key _B_ serves the spending role.<br><br> Format: `BTSaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbcccc`
_(In the address formats above we consider the part following the "BTS" identifier to be Base58 encodings of the concatenated byte buffer representations of public keys and checksum bytes. C.f. [Base58Check](https://en.bitcoin.it/wiki/Base58Check_encoding) encoding.)_
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]](#references) 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](https://en.bitcoin.it/wiki/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
@ -98,6 +106,20 @@ XXXXX
(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.)
## Discussion
### Possible future extensions
#### Additional address formats
The two stealth address formats described above provide for single key and dual key addresses, where the latter allows for separation of transaction monitoring from the ability to spend, allowing for view-only wallets.
There may be use cases for additional address formats allowing for more complex situations.
One would be a multi-sig situation in which the address format encodes multiple spending keys and a weighting requirement. Although, this would make the resulting address very lengthy, it would also add an interesting use-case. And, since BitShares authority structures already allow for a vector of authorizing keys and weights, it should be possible to implement the feature on the wallet side, without needing any changes to consensus or API. This idea is not explored further here but merely suggested for future exploration if there is a desire for the feature.
Another use case for an extended address format would be... (TODO: Discuss including an "invoice nonce" in the address format for correlating incoming transactions to a particular invoice. C.f. Bitcoin where using an address-per-transaction serves both unlinkability as well as invoicing. With Stealth addresses, there is no need to increment addresses for unlinkability, and doing so to facilitate invoicing only increases the scanning overhead by introducing the need to test against additional private keys. But by including an invoice nonce in the address format, which the spending wallet would carry over into the encrypted part of the `stealth_memo`, the recipient can correlate payments to invoices while using only a single address key (or a single pair of spending/viewing keys in the dual-key case).)
### Pitfalls and Cautions
#### An attack on address key from leak of a transaction private key
@ -110,7 +132,6 @@ Thus, wallet designers should be advised to treat the Output PrivKeys handled by
(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
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.