Updated numbering in bsip-1203 to match assigned numbering.

Added rudimentary summary in Summary section.

README.md

@@ -45,3 +45,9 @@ Number             | Title                                                    |
 [35](bsip-0035.md) | Mitigate Rounding Issue On Order Matching                                   | Abit More | Protocol | Accepted
 [36](bsip-0036.md) | Remove expired price feeds on maintenance interval                          | oxarbitrage | Protocol | Accepted
 [37](bsip-0037.md) | Allow new asset name to end with a number                                   | oxarbitrage | Protocol | Accepted
+[1200](bsip-1200.md) | Stealth development, Phase II                              | Chris Sanborn | Informational | Draft
+[1201](bsip-1201.md) | New operations for Confidential Asset (CA) transactions    | Chris Sanborn | Protocol      | Draft
+[1202](bsip-1202.md) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol      | Draft
+[1203](bsip-1203.md) | Blockchain scanning for inbound Stealth transactions       | Chris Sanborn | Protocol      | Draft
+[1204](bsip-1204.md) | Deterministic addresses for Stealth wallets                | Chris Sanborn | Informational | Draft
+[1205](bsip-1205.md) | Metadata hiding via Garlic Routing and other means         | Chris Sanborn | Informational | Draft

bsip-1200.md

@@ -0,0 +1,89 @@
+    BSIP: 1200 (unassigned)
+    Title: Stealth development, Phase II
+    Authors: Christopher J. Sanborn <...>
+             Agorise, Ltd. <Agorise@protonmail.ch>
+    Status: Draft
+    Type: Informational
+    Created: 2018-01-29
+    Discussion: <https://t.me/Agorise>
+
+
+## Abstract
+
+To discuss the continued development of Stealth functionality and provide an overview of the following BSIPs which define components of that development.
+
+Component BSIPs: _(Works in progress!!)_
+
+Number             | Title                                                        | Type          | Status
+:-----------------:|--------------------------------------------------------------|---------------|--------
+[1200](bsip-1200.md) | Stealth development, Phase II — _(this document)_          | Informational | Draft
+[1201](bsip-1201.md) | New operations for Confidential Asset (CA) transactions    | Protocol      | Draft
+[1202](bsip-1202.md) | Ring signatures for untraceability of Stealth transactions | Protocol      | Draft
+[1203](bsip-1203.md) | Blockchain scanning for inbound Stealth transactions       | Protocol      | Draft
+[1204](bsip-1204.md) | Deterministic addresses for Stealth wallets                | Informational | Draft
+[1205](bsip-1205.md) | Metadata hiding via Garlic Routing and other means         | Informational | Draft
+
+## Motivation
+
+The initial phase of Stealth development was proposed and implemented in [BSIP-0008](bsip-0008.md), and is live on the BitShares network.  Support for this first round of confidentiality features has been implemented in the CLI wallet, and has also been demonstrated in the UI wallet by Agorise, Ltd., in a code fork not yet integrated into the mainline UI-Wallet code.  Utilization of the privacy features remains low, for two reasons: (1) the difficulty of using the CLI wallet for day-to-day activities, and (2) the Stealth feature set thus far, while valuable, does not yet provide a comprehensive privacy solution.
+
+Phase One of Stealth development consisted of the implementation of Confidential Transactions (CT) [[1]](#see-also), which was initially proposed for the Bitcoin network in a paper by Greg Maxwell.  CT provides two key features: **value-blinding**, and **stealth addresses**.  Value-blinding means that the value amounts of transactions are unknowable except to the parties of the transaction (provided the transaction is sufficiently removed from the operation that initially converted a public balance to a blind balance).  Stealth addresses are an address format that the sender can use to derive a "shared secret" public key for which only the recipient can derive a private key, without revealing publicly that the stealth address and the public key used to transmit the funds are related.  The use of stealth addresses helps to anonymize transactions, however it creates a burden of communication between the sender and the recipient, who must be made aware of the existence of an inbound transaction.
+
+Stealth addresses also provide partial **unlinkability**, or the inability to "link" balance elements (we'll call them UTXOs for Unspent Transaction Outputs) together to see that they are controlled by the same party. However, wallet implementations may, in order to facilitate discovery by the receiving party, publicly embed the stealth address of the receiving party into the transaction, thus breaking unlinkability and threatening anonymity.  Heretofore, no privacy-preserving method has been proposed on this network to enable discovery, other than the sender and receiver being in direct communication off of the blockchain (e.g. sending **transaction receipts**).  Furthermore, CT transactions are **traceable**, meaning that a transaction reveals which UTXOs are consumed in the creation of new UTXOs.  This has two implications: (1) a transaction history can be constructed, and it may be possible to establish a vary narrow set of originating users who initally "blinded" a previously public balance, thus potentially establishing to a high degree of probability *who* is involved and *how much* value is involved in a particular sequence of transactions, and (2) a user spending a balance consisting of more than one UTXO will of necessity reveal that those UTXOs are controlled by the same party, or "linked," thus again breaking unlinkability.
+  
+In what follows we propose methods of enhancing the confidential abilities offered by the BitShares network by integrating specific solutions to achieve unlinkability, untraceability, and automated transaction discovery by the receiving party.  Additionally, since BitShares is a multi-asset blockchain, we propse to adopt Confidential Assets (CA).  CA is an extension to CT that hides not just the values of a transaction, but also the assets involved.  Further, we propose various convenience and user-experience enhancements to ease the backup burden placed on users and reduce the chances of lost funds.  Lastly, we propose an ongoing effort to harden wallets and p2p nodes against metadata leaks. 
+  
+## Rationale
+
+We view "Stealth" as a constellation of features providing robust privacy and "grandma-friendly" usability and reliability.  A user of Stealth transactions should be reasonably assured that their privacy is complete, and not underminable by easy-to-make procedural mistakes.
+
+### "Blinded" vs. "Stealth"
+
+To facilitate an orderly, confusion-free upgrade, and to differentiate between Phase One and Phase Two functionality, we have adopted the convention of referring to the existing CT transactions that only blind transaction amounts as **Blind Transfers**, and the proposed more fully-private transaction features as **Stealth Transfers**.  The names convey that Stealth Transfers will be more private than Blind Transfers (although some user education will be needed on this).  Upon maturity of the Stealth feature set, the utilization of Blind transfers should be retired.
+
+### Specific features and enhancements
+
+Specific features and enhancments proposed by this and associated BSIPs are as follows:
+
+#### Asset Hiding
+
+Confidential Assets (CA) [[2]](#see-also) extends Confidential Transactions (CT) to include asset hiding.  Existing CT functionality can hide the value amount of a transaction, but the asset being transfered is publically visible in the transaction format.  Since BitShares is a multi-asset blockchain, it would be of value to hide not just the value but also the identity of the asset involved.  CA provides a method to do this.  The proposal to implement CA on the BitShares network is in [BSIP-1201](bsip-1201.md).
+
+#### Unlinkability and Untraceability
+
+While BitShares is an account-based blockchain, similar e.g. to Ethereum and others, Stealth operations on the BitShares network follow a UTXO model, similar to BitCoin and related blockchains.  UTXOs (Unspent Transaction Outputs) are discrete balances held in the "outputs" of transactions.  A user's total balance is composed of the sum total of all UTXOs that fall under their control.  A Stealth transaction consists of the destruction of one or more existing UTXOs and the creation of one or more new UTXOs.  CT guarantees that the values of the outputs are unknowable (except for deductions that can be made if one happens to know, precisely or approximately, the values of the inputs).  However, the current implementation of CT provides no privacy regarding *which* UTXOs are used as inputs to the transaction.  Because of this, current CT transactions are fundamentally *traceable* and *linkable*.  **Traceable** means that a history of prior inputs can be constructed, "tracing" where an output came from, and if the history is short enough (refering to how many prior UTXOs one must traverse before finding an operation where a public balance was converted to a blind balance) then it may be possible to reveal involved parties and estimate transaction values.  **Linkability** refers to the ability to show that a set of UTXOs are controlled by the same party, or that a set of disparate transactions were conducted by the same party.  Although the latter is well protected due to non-reuse of public keys, the former is implicated by CT.  A CT transaction consuming multiple inputs necessarily reveals that all inputs are controlled by the same party, and if anonymity has been compromised for one input UTXO, then it is effectively compromised for all of them.
+
+To solve the problems of linkability and traceability, we propose to take a page from the Monero project.  The Monero network uses a system of **ring signatures** to create a high degree of plausible-deniability as regards who exectuted any particular transaction [[3]](#see-also).  A ring signature is an *n* of *m* signature scheme wherein the set of inputs to a transaction is much larger than the set of inputs actually consumed by the transaction, and the signature provided guarantees that the correct party signed the transaction, but makes it impossible to know *which* party is the signer.  With a Monero-like ring signature scheme, it is no longer possible to determine *which* UTXOs are "spent" vs. "unspent" (a mechanism to prevent double-spends does exist, of course).  This means that it is no longer possible to construct an exclusive directed graph if inputs to outputs, thus providing untraceability and unlinkability.  (More specifically, the set of inputs that *might* be in the history of a particular output rapidly becomes so large that it is no longer possible to say with significant probability that any particular party was involved.)
+
+We propose and discuss the implementation of ring signatures for Stealth transactions in [BSIP-1202](bsip-1202.md).
+
+#### Scanning for Inbound Stealth Transactions
+
+The current implementation of CT requires that a sender must communicate to the recipient a "transaction receipt" that contains, in encrypted form, data that the recipient needs in order to take possession of a transaction output.  This is burdensome, and implies a high risk of lost funds as a result of lost or uncommunicated receipts.
+
+We propose automated, privacy-preserving methods of scanning for inbound transactions in [BSIP-1203](bsip-1203.md).
+
+#### Backups of Stealth Balances
+
+In [BSIP-1204](bsip-1204.md) we propose standardized derivation of Stealth addresses to enable backup seeds or brainkeys to be used to securely back up a Stealth account prior to first use, enabling recovery in the event of a lost or corrupted hot wallet.
+
+#### Metadata Hiding
+
+Lastly, in [BSIP-1205](bsip-1205.md), we propose methods of hardening wallets against eavesdropping and timing attacks, so that usage patterns and the method used to communicate with the peer-to-peer network do not compromise user privacy.  (As an example, a naive wallet might check a users balance by querying the status of a set UTXOs under the user's control, revealing immediately to the network that a given set of UTXOs are "of interest" to a single party.)
+
+## Specifications
+## Discussion
+## Summary for Shareholders
+## Copyright
+
+  This document is placed in the public domain.
+  
+## See Also
+
+* Phase One of Stealth development: [BSIP-0008](bsip-0008.md)
+
+[1] Confidential Transactions (Greg Maxwell) - https://people.xiph.org/~greg/confidential_values.txt
+
+[2] Confidential Assets (Poelstra, et. al.) - https://blockstream.com/bitcoin17-final41.pdf 
+
+[3] Ring Confidential Transactions (Shen Noether) - https://eprint.iacr.org/2015/1098

bsip-1201.md

@@ -0,0 +1,106 @@
+    BSIP: 1201 (unassigned)
+    Title: New operations for Confidential Asset (CA) transactions
+    Authors: Christopher J. Sanborn
+    Status: Draft
+    Type: Protocol
+    Created: 2018-01-29
+    Discussion: <url>
+
+
+## Abstract
+
+Confidential Assets (CA) [[2]](#see-also) extends Confidential Transactions (CT) [[1]](#see-also) to include asset hiding.  The BitShares network already understands and validates CT transactions, but is not yet capable of validating CA transactions.  The transaction format will need minor to moderate updating and the validation routines will likewise need updating. We propose to either (a) update op-code 39, 49, and 41 to be CA capable, or (b) define new opcodes for CA stealth operations.  The latter option probably affords a cleaner upgrade path.  The old opcodes should then be disfavored for user wallet use.
+
+Confidential Assets is a new, but not un-tested, technology.  The Elements Project [[3]](#see-also) maintains an experimental implementation [[4]](#see-also) of CA as a Bitcoin side chain.  The code for that project is MIT-licensed and can help guide the implementation  of CA in the BitShares ecosystem.
+
+_This BSIP is one of several describing_ [Stealth development, Phase II](bsip-1200.md).
+
+## Motivation
+
+A user maintains value-blinded balances on the BitShares blockchain as a collection of Pedersen commitments, which are EC curve points that obscure their committed values by adding a secret blinding factor times a generator point.  By keeping the blinding factor secret, the user keeps their balance secret.  Meanwhile, balances can be transferred, subdivided, or combined, provided the sum of blinding factors for all inputs to a transaction are equal to the sum of blinding factors of all outputs of a transaction.  A user wishing to un-blind and "claim" a balance contained in a Pedersen commitment may do so by revealing the blinding factor for that commitment, which then allows the network to verify the committed amount and credit it to a public balance.
+
+A commitment C is given mathematically by _C = value * H + blinding_factor * G_, where H and G are separate curve point generators with no known divisor between them.  Because there is no known multiple _m_ solving _H = m*G_, the _value_ and _blinding_factor_ quantities are effectively independent, which makes _C_ a firm commitment to _value_.
+
+BitShares is a multi-asset chain.  The Pedersen commitments implemented in _Stealth Phase I_ commit only to a value amount, and nothing more.  For the network to understand *which* asset is represented by a commitment, a plaintext metadata field is associated with the Graphene object for the commitment, containing the asset ID of the blinded asset.  This means that the asset type of an individual blinded balance is publicly knowable.
+
+Confidential Assets (CA) introduces a method for using a commitment to a hash of the asset description as a confounding factor similar to the blinding factor, such that, unless one already knows the asset represented by a particular Pedersen commitment, one cannot determine the asset from inspection alone.  Furthermore, amounts of differing assets can be combined in a single transaction, so that the asset IDs of the outputs are not individually knowable.  Thus, even by tracing the history of a given commitment, one cannot simply divine the asset type by back-tracing to the point where a public asset was blinded, as the history may implicate multiple asset types.  When a user wishes to un-blind an asset, he may do so by providing both the value blinding factors and the asset blinding factors for the commitment, so that the network can confirm the contents thereof.
+
+By allowing commitments of differing assets to be mixed together, we achieve two points for privacy: (1) we increase the available mix-in set for diffusion of transaction history, and (2) we make it more difficult for blockchain analysis to determine which assets are being operated on in any given transaction (the more assets involved in the history of a particular commitment, the greater the uncertainty of what the commitment contains).
+
+## Rationale
+
+### _Asset Tags_ and _Asset Commitments_
+
+The existing value-blinded CT transaction capability includes an explicit **asset ID** in the transaction format, and unspent commitments are associated with an explicit clear-text asset ID in the database.  For example, querying the blockchain for commitment "024449...8073" returns a structure containing three defining fields:
+
+Field:      | Data (Meaning)
+:----------:|----------
+commitment: | "0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073" |
+asset_id:   | "1.3.0"  (Core asset, BTS)
+owner:      | (Authority struct specifying public key that must sign)
+
+Under CA, the `asset_id` field would be replaced by `asset_commit` which is a commitment to an **asset tag**.  The asset tag, denoted *H<sub>A</sub>*, is a curve point produced by a hashing procedure of some defining description of the asset (for example the `asset_id`, "1.3.0", etc.).  The asset commitment, denoted *H*, is the sum of *H<sub>A</sub>* and a blind point, e.g., _H = H<sub>A</sub> + r*G_.  Under this scheme, a CA commitment in the database would look similar to:
+
+Field:        | Data (Meaning)
+:------------:|----------
+commitment:   | "0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073"
+asset_commit: | "022b607af588386028a97d6bc4be5caddb432340329bc808ba587c0b92ffb1087c"
+owner:        | (Authority struct specifying public key that must sign)
+
+As can be seen, casual inspection of the blockchain does not reveal the underlying asset, nor even asset tag, since it is commingled with a blinding factor.  The only way to know the asset id would be if the commitment were a direct descendent of an asset-issuance transaction (where a public balance was blinded into a value-asset blind CA commitment).  However, once a commitment is involved in a transaction involving inputs of multiple asset types, then uncertainty is introduced in the descendent commitments: the asset type will be _one_ of the parent asset types, but which one is unknowable except to parties that know the blinding factors.
+
+_(TODO: QUESTION: How is it ensured that H<sub>A</sub> is a valid curve point? There must be some kind of nonce increment in the hash procedure to reject non-curve points.  Find out.)_
+
+### _Range Proofs_ and _Surjection Proofs_
+
+Since the committed values in the Pedersen commitments are unknowable to parties not privy to the blinding factors, there exists the possibility for a transaction resulting in two or more outputs to encode a negative value in one output and an excess positive value in the others, resulting in inflated (i.e., counterfeit) asset supply.  To prevent this, transactions with more than a single output are required to provide a **range proof** for each output, which is a zero-knowledge proof that the committed value is in a finite range between zero and an upper bound that won't risk overflow into negative values.  (Values are encoded as 256-bit unsigned integers such that very-large integers "wrap around" and behave as negatives. Range proofs typically prove that a committed amount can be represented in 64-bits or less, affording no risk of overflow.)  Under CA, the requirement to provide a range proof remains the same as under CT.
+
+A new requirement in CA is the **asset surjection proof**.  Similar to range proofs, ASPs prove that a validity contstraint is met on the blinded asset commitments of the transaction outputs.  Specifically, it proves that the asset tags of the outputs match the asset tags of the inputs, without revealing what those tags are or which outputs correspond to which inputs.  (TODO: preceding is imprecise.)
+
+(TODO: discuss space requirments of ASPs, since they do add to transaction size. Compared to range proofs already included in CT transactions, however, they are comparatively small, except perhaps in the case of a large number of inputs and outputs in a single transaction.)
+
+## Specifications
+
+We propose to add the following three CA operations to the set of valid operations declared in graphene::chain::operation (chain/protocol/operations.hpp). The new CA operations are shown here side by side with their CT equivalents:
+
+Op-Code | Description                   | Op-Code          | Description
+:------:|-------------------------------|------------------|----------------------------------
+39      | transfer_to_blind_operation   | 49 (placeholder) | transfer_to_ca_blind_operation
+40      | blind_transfer_operation      | 50 (placeholder) | ca_blind_transfer_operation
+41      | transfer_from_blind_operation | 51 (placeholder) | transfer_from_ca_blind_operation
+|       |                               | 52 (placeholder) | ct_to_ca_blind_transfer_operation
+
+On the left are CT operations, whose outputs are value-blinded commitments. On the right are the corresponding CA operations, whose outputs are value-and-asset-blinded commitments. Of special note is op 52, which takes value-blinded CT inputs and outputs value-and-asset-blinded outputs. (As an alternative, op 50 could be made flexible enough to accept either CT or CA inputs, if this proves feasible.)  As CA is seen as an upgrade to CT, no op-code is here proposed for transferring from CA back to CT, however in the event of market demand such an operation could be coded.
+
+#### Proposed operation: transfer_to_ca_blind_operation (Public to Blind)
+
+#### Proposed operation: ca_blind_transfer_operation (Blinded to Blind)
+
+#### Proposed operation: transfer_from_ca_blind_operation (Blind to Public)
+
+## Discussion
+
+### Compatibility with ring-signature scheme
+
+The Op-Code additions and specifications provided in this document do not conflict with or depend on the details of the ring-signature proposals in [BSIP-1202](bsip-1202.md), as they effect different substructures of the Transaction structure, and therefore both proposals can be implemented independently. This document specifies structures within the Operations vector within a Transaction structure, whereas the ring signature scheme would change the Signatures vector.
+
+(TODO: Check whether preceding is true, i.e. that the operation structure is independent of signature method.  If it is not true, include here a discussion of what else might need to be included in the structure, so that a decision can be made as to whether the two features would be best developed in parallel, or whether ring-sigs could be implemented subsequently as an "upgrade" to CA.)
+
+#### Asset surjection and compatibility
+
+TODO: Question: Are Asset-Surjection Proofs compatible with a Ring-Sig scheme?  I.e., can a prover who is "accusing" unrelated inputs produce the proof even not knowing the blind factors and asset tags of the unrelated inputs?
+
+## Summary for Shareholders
+## Copyright
+
+This document is placed in the public domain.
+
+## See Also
+
+[1] Confidential Transactions (Greg Maxwell) - https://people.xiph.org/~greg/confidential_values.txt
+
+[2] Confidential Assets (Poelstra, et. al.) - https://blockstream.com/bitcoin17-final41.pdf 
+
+[3] Elements Project - https://elementsproject.org
+
+[4] Elements Project on GitHub - https://github.com/ElementsProject/elements

bsip-1202.md

@@ -0,0 +1,103 @@
+    BSIP: 1202 (unassigned)
+    Title: Ring signatures for untraceability of Stealth transactions
+    Authors: Christopher J. Sanborn
+    Status: Draft
+    Type: Protocol
+    Created: 2018-01-29
+    Discussion: <url>
+
+
+## Abstract
+
+Confidential Transactions (CT) [[1]](#see-also), (as implemented by [Phase I](bsip-0008.md) of Stealth development), solves the linkability and value-hiding problems, but not the traceability problem.  CT transfers are traceable on the blockchain, meaning that for any given transaction, a history of prior transactions can be determined.  If the set of antecedents is large, then there is a great degree of plausible-deniability regarding the origins of the hidden assets.  However, if the set is small, it is possible to determine with increasing probability where the assets originated from.  A solution to this is to “mix” transaction inputs with unrelated users so as to increase the traceability set.  Some privacy blockchains rely on a mechanical mixing or “tumbling” process to increase the traceability set, however this approach has drawbacks.  Monero has a very clever scheme of using ring signatures to automatically and randomly mix in unrelated inputs on every transaction, guaranteeing that even newly blinded funds are mixed with with inputs having a rich history.  It is proposed, as a component of [Stealth development Phase II](bsip-1200.md), to implement a similar mechanism for BitShares.
+
+## Motivation
+
+Stealth can be thought of as a constellation of privacy-preserving features implemented on (or planned for) the BitShares blockchain.  "Privacy" here is a set of specific goals:
+
+* Untraceability
+* Unlinkability
+* Value/Asset hiding
+* Anonymity
+
+Although Confidential Transactions (CT) provides good solutions to unlinkability and value hiding, (which together help but do not fully solve anonymity), the transactions currently supported on the network are fully traceable.  This means it is possible generate a history all prior transactions leading up to a particular transaction output, including a set of originating transactions wherein public balances were blinded.  For outputs which are "close" to their originating transactions, it may be possible possible to identify a small set of non-anonymous originating actors, and to make estimates of the possible maximum value amount of an output (by assuming it can be no larger than the sum of all originating transactions in its history).
+
+What we seek is a method to make it unknowable *which* prior transaction outputs were consumed in the generation of a new transaction output.  Although it seems a tall order (how can a node validate that a sum of inputs balances a set of outputs when it is unknown which inputs are involved?), a solution actually comes in the form of a ring signature protocol developed for the Monero project. <!-- TODO: check specific heritage of this protocol -->
+
+The ring signature strategy in Monero has gone through two major developmental stages.  In the first stage, transaction amounts were not blinded (although pseudo-blinding was achieved by composing value transfers from an aggregate of round-number individual transactions).  In the second stage, the ring signature authorization protocol was combined with Confidential Transactions to form the RingCT protocol [[2]](#see-also), in which transfers are both value-blinded and untraceable.  Since BitShares already implements CT, the adoption of RingCT into BitShares Stealth operations can be seen as an improvement upon an existing feature.
+
+## Rationale
+
+Although BitShares is an account-based blockchain, in which value-transfer operations are a simple transfer of balance from one account to another, Stealth operations on the BitShares blockchain instead follow a **UTXO model**.  Stealth transactions produce "**transaction outputs**" (TXOs) which represent individual balance amounts under the control of someone possessing the appropriate secret key.  These TXOs are "unspent" (UTXOs) until they are involved in a downstream transaction, at which point they are considered destroyed and no longer spendable. (To partially spend a UTXO, a transaction consuming it would need to produce two outputs: one to the intended recipient, and one back to the sender as "change.")
+
+A transaction in a UTXO-based blockchain is simply a list of inputs (UTXOs which will be destroyed) and a list of outputs (newly-generated UTXOs).  Validating such a transaction involves confirming that the value sum of inputs equals the value sum of outputs plus fees, and that appropriate authorization is provided for all inputs.
+
+Because the list of inputs is part of the transaction, all UTXOs have a traceable history.
+
+Ring signatures are a signature scheme in which, for a given set of credentials, a signature is provided proving that at least *one* of the credentials authorized the transaction, but it cannot be determined by a third party *which* credential it was that signed it.  Thus ring signatures provide **plausible deniability**.  All involved credentialed parties can mutually point fingers at each other, saying, "it wasn't me."  <!-- CITE -->
+
+Ring signatures can provide untraceability in Stealth transactions in the following way:  For a given transaction, a set of inputs is collected which is *larger* than the set needed to cover the the intended transaction outputs.  The additional inputs should include inputs for which the spender does not have authorizaton to spend.  A signature is provided proving that at minimum *enough* inputs are authorized to cover the outputs, however an external observer cannot determine which inputs are thereby consumed.  Double-spending of inputs is prevented by the provision of a "**key image**" for each actually-spent input.  A key image is a piece of data that uniquly derives from the consumed input, but which cannot be matched to it.  A subsequent spend of the same input would produce the same key image, alerting the network to the attempt at a double spend.  Now, the set of inputs to any transaction includes not only the actually-consumed inputs, but also a large set of "red herring" inputs, which achieve two important aims for untraceability:
+
+1. A degree of plausible-deniability for the authorizer of any individual transaction, and
+2. An enormously larger set of prior transactions that form the "history" of the transaction, implicating a *much* larger set of originating transactions than is actually involved in the true history of the transaction.
+
+It should be noted that one drowback of this scheme is that it is no longer possible to determine which UTXOs are spent vs. unspent, and this has implications for database pruning.  However, the Monero chain has been functioning with this limitation for several years now without hitting a performance bottleneck.  Additionally, the Monero team has projected that performance growth will keep pace with database size, even absent pruning of spent TXOs.  (CITE).  (A review of this projection and discussion of its implication for the BitShares chain is in the Discussion section.)
+
+## Specifications
+
+(Detailed description of RingCT with annotations for how it would be adapted to BitShares Stealth transactions.) [[2]](#see-also)
+
+## Discussion
+
+### Overview of alternative untraceability solutions
+
+(Compare/contrast with other schemes for providing untraceability, including ZeroCoin accumulators, master-node facilitated tumbling, MimbleWimble, etc.)
+
+#### Mimblewimble
+
+* PRO: Supports a sort of automated, non-interactive aggregate signature scheme (end result similar to CoinJoin), facilitating untraceability at the blockchain level (although not necessarily at the network-snooping level).
+* CON: Requires communication between sender and recipient.
+* [[Jed2016]](#see-also), [[PoelMW]](#see-also)
+
+#### CoinJoin, CoinSwap, etc.
+
+* In [1], Maxwell states "[CT is] compatible with CoinJoin and CoinSwap, allowing for transaction graph privacy as well while simultaneously fixing the most severe limitation of these approaches to privacy (that transaction amounts compromise their privacy)."
+  * ((This still needs to be researched by this author but I believe these protocols involve mixing with contemporaneous participants, many of whom may be nefarious actors.  RingCT allows mixing with historical transactions, and reuse of historical transactions, greatly broadening the set of available mix-in transactions.  TODO: confirm this disadvantage.))
+
+* Dash (http://dash.org) uses a system of "master nodes" to coordinate an opt-in mechanism of "pre-washing" coins via several rounds of mixing with other participants where each round of washing is a CoinJoin-like process. (https://dashpay.atlassian.net/wiki/spaces/DOC/pages/1146924/PrivateSend)
+
+#### Accumulator Schemes, e.g. ZeroCoin
+
+* Spending a coin into the accumulator produces receipt that can be used to withdraw a coin from the accumulator later.  The withdraw operation cannot be linked to the orignal deposit operation.  Untraceability os provided by the fact that the "plausible deniability set" of users who might be responsible for the coin is the set of all users who have deposited coins into the accumulators.  This can be a very large set.
+  * Pros:
+    * Large deniability set
+    * Conceptully simple mechanism
+    * Possible to audit supply
+  * Cons:
+    * Depends on a **trusted setup**, which, if compromised, could allow theft or counterfeit of coins
+      * (NOTE: Announcement by ZCoin team of an upgrade that eliminates need for trusted setup) (CITE)
+      * [[Yap2017]](#see-also), [[GrothSigma]](#see-also)
+    * Mechanism to transfer coins between users while the coins are *inside* the accumulator is unclear/unknown (to this author) or impossible.  Thus an accumulator may be a good way to wash or hide your own funds, but is not a good solution for creating a balance that one easily use in cash-like user-to-user transactions.
+
+### Scaling challenges in a Ring-Sig scheme
+
+(Discussion of the implications of not pruning spent TXOs.)
+
+## Summary for Shareholders
+## Copyright
+
+This document is placed in the public domain.
+
+## See Also
+
+[1] Confidential Transactions (Greg Maxwell) - https://people.xiph.org/~greg/confidential_values.txt
+
+[2] Ring Confidential Transactions (Shen Noether) - https://eprint.iacr.org/2015/1098
+
+[Jed2016] Mimblewimble (Tom Elvis Jedusor) - https://scalingbitcoin.org/papers/mimblewimble.txt
+
+[Poel2016MW] Mimblewimble (Andrew Poelstra) - https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf
+
+[Yap2017] Zcoin moving beyond trusted setup in Zerocoin (Reuben Yap) - https://zcoin.io/zcoin-moving-beyond-trusted-setup-in-zerocoin/
+
+[GrothSigma] - One-out-of-Many Proofs: Or How to Leak a Secret and Spend a Coin (Jens Groth and Markulf Kohlweiss) - https://eprint.iacr.org/2014/764.pdf

bsip-1203.md

@@ -0,0 +1,264 @@
+    BSIP: 0053
+    Title: Blockchain scanning for inbound Stealth transactions
+    Authors: Christopher J. Sanborn
+    Status: Draft
+    Type: Protocol
+    Created: 2018-01-29
+    Discussion: https://github.com/bitshares/bsips/issues/91
+
+
+## Abstract
+
+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
+
+"Stealth addresses" are a method of providing _unlinkability_ to blockchain transactions.  Unlinkability is a major component of the Privacy Triad: _unlinkability_, _confidentiality_, and _untraceability_.  Using a stealth address, a sending wallet is able to compute a child public key that derives from a public key encoded in the address, but which cannot be correlated, or "linked", to the address public key, unless you are either the sender or the receiver.  This child key becomes the authorization key for transaction outputs (TXOs) intended for the receiver.  As such, third party observers cannot link TXOs to addresses, nor even link together independent TXOs which are destined to the same address.
+
+Although this is a great benefit to privacy, it complicates the matter of detecting inbound transactions, since a wallet cannot simply scan for transactions which explicitly identify the destination address.
+
+Existing [Stealth Phase I](bsip-0008.md) functionality already includes the use of stealth addresses, but does not include a solution for detection of inbound transactions.  As a result of which, user adoption of the Stealth feature has been very minimal.  We propose below a solution to inbound transaction detection as well as some additional enhancements to the stealth addressing scheme, including a proposed new address format that allows for watch-only wallets.
+
+## Rationale
+
+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 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 must use 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 Key (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 ViewKey.  The OTK PubKey will be clear-text encoded in the Tx receipt, and optionally also recorded in the transaction output to enable automated discovery.
+* **Address Keys (ViewKey and SpendKey)** — These are public keys encoded in the recipient's stealth address.  The goal of a stealth address scheme is to _not_ identify these public keys in any transaction output.  A long-form address encodes _two_ public keys, referred to as ViewKey and SpendKey. The SpendKey serves as a base point from which individual Tx output AuthKeys are computed as an offset, and the ViewKey is used with the OTK to compute that offset.  A short-form address encodes only a single public key, which serves as both the ViewKey and SpendKey.
+* **Tx Output Authorization 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 address SpendKey by a secret offset that only the sender and recipient can calculate (from the shared secret between OTK and ViewKey).  The sender can only know the offset, but not the full secret key to the AuthKey.  The recipient, knowing the private key behind the SpendKey, 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.
+
+Current network rules allow for a receipt to be embedded in each Tx output via a `stealth_memo` field which is formatted in a similar way as the encrypted memos that may accompany regular (non-Stealth) transfer operations. These memos are composed of a header specifying the OTK PubKey and the "message PubKey" for which the recipient holds the corresponding private key, followed by cipher text which is AES encrypted with a shared-secret key between the OTK and the message PubKey.  For this `stealth_memo` field, the current behavior of the CLI reference wallet is to use the recipient's Address PubKey as the message PubKey.  Although this is a reasonable choice for encrypting message text generally, it has the severe downside of identifying the recipient's Address PubKey in the memo header, and therefore breaks anonymity and negates the unlinkability provided by using a stealth address scheme.  For this reason, the CLI reference wallet currently does _NOT_ actually embed the memo in the Tx ouput but instead Base58 encodes it and prints it to the screen, calling it a "transaction receipt." The sender must manually, and secretly, transmit this to the recipient via a side channel.
+
+**Stealth Memo structure: (Stealth I)**
+
+<span></span> | <span></span>
+-----: | :---
+**One-time PubKey:** | Chosen from randomness by sender &nbsp; **_(33 bytes)_**
+**Message PubKey:** |  Public key controlled by recipient. &nbsp; **_(33 bytes)_**<br>
+**Cipher Text:** | AES encrypted message, using _key &leftarrow; Shared(OTK,MPK)_
+
+_Current Stealth I behavior is to use the Address PubKey as the message PubKey, which reveals intended recipient!!_
+
+A very simple solution would be to change the behavior of embedding the Address PubKey in the message PubKey field, and to instead record the Tx output AuthKey in this slot.  Because the recipient is also able to derive this AuthKey through knowledge of her own address private keys (in combination with the OTK recorded in the header), the recipient would simply need to test the OTK against each of their own Address Keys to see if the resulting AuthKey matches the one in the header.  If it does, then the output is recognized as destined to the recipient, even though the recipient's Address PubKeys are not identified in the memo header.  The computational cost of this is one Diffie Hellman round, a hash operation, and a child key derivation.  It should be noted that the AES encryption key should still be computed from the shared secret between the OTK and the address ViewKey, however, as this will allow view-only wallets which cannot compute the private key behind the AuthKey to decrypt the memo and tally the incoming transaction.
+
+**Stealth Memo structure: (Proposed: Stealth II)**
+
+<span></span> | <span></span>
+-----: | :---
+**One-time PubKey:** | Chosen from randomness by sender &nbsp; **_(33 bytes)_**
+**cTXO AuthKey:** |  Child public key of the stealth address and the OTK. &nbsp; **_(33 bytes)_**<br>
+**Cipher Text:** | AES encrypted message, using _key &leftarrow; Shared(OTK,ViewKey)_
+
+_Proposed Stealth II behavior is to embed the AuthKey in the second slot, while still encrypting the message data with a shared key between the OTK and the Address key (specifically, the ViewKey so that watch-only wallets can read the commitment data)._
+
+To support this strategy, a wallet will need to inspect all cTX activity on the network and test the challenge conditions on each transaction.  This could be achieved if API nodes are extended to provide an API call to retrieve `stealth_memo` fields from all cTXOs appearing in a specified block range.  The wallet could simply download the memos, test the challenge on each one, and identify and decrypt the ones that are destined to the wallet.  No need would remain to manually transmit transaction receipts.  The receipts would be embedded, compactly and unlinkably, in the Tx outputs.
+
+## Specifications
+
+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
+
+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.  If the wallet is a watch-only wallet for a particular address, then it is assumed to have the private and public ViewKey, but only the public SpendKey.
+2. Wallet can query an API node for commitments occurring between specified block heights, to obtain sets of embedded receipts to scan for owned commitments. ([See below](#api-requirements-to-allow-detection-of-inbound-commitments) for this process.)
+
+We detail procedures for stealth address formats which encode either a single public key, or two distinct public keys in which one key is the ViewKey and the other the SpendKey. The single-key format is already in use on the BitShares network and is borrowed from the original Confidential Transactions specification. The dual-key format allows for additional wallet features and is borrowed from CryptoNote-based coins such as Monero.  No changes to the network nodes are required for wallets to support dual-key address formats.  In fact, the single-key format can be thought of as a special case of the dual-key format in which the same key is used as the ViewKey and the SpendKey.
+
+**Address Formats:**
+
+&nbsp; | 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`
+**Invoice Nonce:** | This one encodes a single PubKey serving both the viewing and spending role, but also includes a 64-bit "nonce" or "tag" that the spending wallet is to include in the encrypted memo part of the cTXO, allowing the receiver to interpret payment as being applied to a specific invoice. <br><br> Format: `BTSaaaaaaaaaaaaaaaaaaaannnnnnnncccc`
+
+_(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)
+
+Recognizability depends on there being a deterministic relationship between the AuthKey that authorizes expenditure of a particular cTXO, the one-time key (OTK) that the sender generated randomly for the cTXO, and the recipient's Address key (or keys).
+
+We assume that the stealth address encodes public keys corresponding to two purposes: discovery, and expenditure.  When an address encodes only one public key, that key is used for both purposes. We refer to the key for discovery as the "view" key, and denote the private, public pair as _(v, ViewKey)_.  For spending, we denote the key pair as _(s, SpendKey)_.
+
+The AuthKey for a cTXO is an EC point summation of the address's SpendKey and an EC point "offset," which, for present purposes we will denote by the private, public pair _(o, Offset)_, with _Offset = o*G_, where _G_ is the generator point for the curve.
+
+&nbsp; _AuthKey &nbsp;=&nbsp; SpendKey &nbsp;+&nbsp; Offset_
+
+Anonymity is preserved so long as only the sender and the receiver are able to compute _o_ and _Offset_.  The algorithm for computing _Offset_ is a deterministic function of the OTK and ViewKey only, (and not the SpendKey).  This allows the the recipient to recover the SpendKey by simple subtraction of _Offset_ from the AuthKey.  The recipient's wallet then compares the computed SpendKey against the address SpendKey.  The wallet may even compare against a whole list of SpendKeys that the wallet may have used to generate an address family with a common ViewKey, allowing for differentiable invoices, without sacrificing efficiency of scanning. (See _[address-per-invoice](#utility-of-dual-key-addresses)_ below.)
+
+Algorithm | Description / Specification
+:---:|:---------------------------
+_Shared(a,B)&nbsp;&rarr;&nbsp;secret <br> Shared(A,b) &rarr; secret_ | This yields a "shared secret" between public keys _A_ and _B_ computable only by parties possessing at least one of the private keys _a_ and _b_.<br><br>&nbsp; _secret = SHA512(P<sub>X</sub>)_; &nbsp; &nbsp; _P = aB = Ab_<br><br>For BitShares Stealth, the secret is a byte buffer (64 bytes) computed from the SHA512 hash of the encoded _X_ coordinate (32 bytes) of EC point _P_. (c.f. [EC Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman).)
+_ChildOffset(B,index)&nbsp;&rarr;&nbsp;offset_ | This yields an integer-valued private key _offset_ that generates the keypair _(offset, Offset = offset*G)_.  The offset is considered to be a "child" of key _B_, and the parameter _index_ is a byte buffer.<br><br>&nbsp; _child = BigInteger(SHA256(Compressed(B)_ &vert;&vert; _index))_<br><br>_Compressed(B)_ refers to the SEC1 "compressed" representation of public key _B_.  The &vert;&vert; symbol refers to concatenation.
+
+**Sending:**
+
+The sender's procedure for computing the offset and generating the AuthKey for the cTXO is detailed as follows:
+
+<ol>
+<li> Compute a "shared secret" between between the sender and receiver:
+
+_secret = Shared(otk, ViewKey)_
+
+The sender must be careful to leak neither the shared shared secret nor the private _otk_ key.
+</li>
+<li> Compute the OffsetKey as a child of the ViewKey, using a SHA256 hash of the shared secret as a child index:
+
+_childindex = SHA256(secret)_<br>
+_offset = ChildOffset(ViewKey,childindex)_<br>
+_OffsetKey = offset*G_
+</li>
+<li> Compute the AuthKey by summing SpendKey and OffsetKey:
+
+_AuthKey = SpendKey + OffsetKey_
+</li>
+</ol>
+
+**Receiving:**
+
+The receiver, having acquired a list of cTXO metadata that includes _OTK_ and _AuthKey_, goes through the following process to test for ownership:
+
+<ol>
+<li> Compute a "shared secret" between between the sender and receiver:
+
+_secret = Shared(OTK, viewpriv)_
+</li>
+<li> Compute the OffsetKey as a child of the ViewKey, using a SHA256 hash of the shared secret as a child index:
+
+_childindex = SHA256(secret)_<br>
+_offset = ChildOffset(ViewKey,childindex)_<br>
+_OffsetKey = offset*G_
+</li>
+<li> Recover the public SpendKey by subtracting OffsetKey from AuthKey:
+
+_SpendKey = AuthKey - OffsetKey_
+
+</li>
+<li> Compare the recovered SpendKey against all wallet SpendKeys that may have been used with the ViewKey to generate an address.  If one matches, then the cTXO is "recognized."  To later spend the cTXO, the wallet computes the private authorization key as:
+
+_authpriv = spendpriv + offset_
+</li>
+</ol>
+
+Thus, a wallet may undertake to periodically download and scan the metadata for Stealth transactions and test for outputs that can recover a wallet's public SpendKey from knowledge of the private ViewKey.
+
+##### Embedding recognizability data in the transaction
+
+For the recipient to have the practical ability to recognize a cTXO as their own, the cTXO, as recorded on the blockchain, must include the following two items: 1.) The one-time PubKey (OTK) that the sender generated for shared-secret generation, and, 2.) the authorization PubKey (AuthKey) of the cTXO.  Because the AuthKey is computed deterministically from _Shared(OTK,AddrKey)_, it stands that if the recipient can generate the same AuthKey, then the cTXO belongs to them.
+
+The structure of a cTXO is as follows:
+
+_Field_ | _Purpose_
+-------:|:-------
+**`commitment`:** | Blinded value commitment &nbsp; _(EC curve point, 33 bytes)_
+**`range_proof`:** | Proof data supporting transaction validity &nbsp; _(0 to ~5 KiB)_
+**`owner`:** | BitShares owner structure specifying weighted list of keys or accounts that may spend this commitment. (Typically lists just one public key, the "AuthKey" for the cTXO.)
+**`stealth_memo`:** | Also known as the "transaction receipt" when transmitted off-chain.<br><br> **`one_time_key`:** &nbsp; _(EC curve point, 33 bytes)_<br> **`to`:** &nbsp; Use the AuthKey here! _(EC curve point, 33 bytes)_<br> **`encrypted_memo`:** &nbsp; Data that recipient needs to "open" the commitment.<br><br> _The stealth memo is optional as far as the network is concerned, but essential if you want the recipient to be able to detect the incoming transaction without sending a "receipt."_
+
+_(An example transaction showing all these fields can be seen in [block 22157273](https://cryptofresh.com/tx/8182e9d78cbce7df281bc252a9e6d87566ca0622). In this Tx, the stealth_memo '`to`' field unwisely names the recipient's address key, rather than the cTXO Auth key, and thus breaks unlinkability.)_
+
+Since the `stealth_memo` field can be used to record both the OTK and the AuthKey, all the wallet needs to do to scan for incoming transactions is to download batches of stealth memos and, for each one, test whether the combination of the OTK and the wallet's Address key yields the AuthKey.  If it does, then derive the AES decryption key from _Shared(OTK,ViewKey)_ and use that to read the additional data in `encrypted_memo`. 
+
+Structure of `encrypted_memo`:
+
+_Field_ | _Purpose_
+-------:|:-------
+**`from_key`:** | Original use:<br><br><ul>Identifies address key of sender **(optional)**. &nbsp; _(EC curve point, 33 bytes)_</ul>Alternate possible uses:<br><br> <ul><li>Instead of ID'ing the 'from' address, could use this field to embed an _invoice nonce_ to allow receiver to correlate payment to an invoice.</li></ul>
+**`amount`:** | Value of commitment. &nbsp; _(Integer, 32 bytes)_
+**`blinding_factor`:** | Blinding factor. &nbsp; _(Integer, 32 bytes)_<br><br>_Note: Except when a blind_sum is needed, the blinding factor is deterministic from a hash of the shared secret, meaning this field can potentially be repurposed or omitted. To guarantee that the blinding factor can always be deterministic, transactions can be padded with a commitment to zero to absorb the blind_sum._
+**`commitment`:** | The Pedersen commitment. &nbsp; _(EC curve point, 33 bytes)_<br><br> _Note: This field is redundant, since the commitment is determined by_ C = amnt * H + blind * G, _and could potentially be omitted._
+**`check`:** | Checksum to confirm correct decryption. &nbsp; _(4 bytes)_
+
+_(TODO: How is this serialized? Do omitted fields "take up space"?  Can fields be chosen a la carte? How hard will it be to extend this memo format, for, say, multiple assets in the case of CA? See fc::raw::pack.)_
+
+ 
+### API Requirements to Allow Detection of Inbound Commitments
+
+To monitor for incoming transactions to a particular wallet, a wallet need only download sets of `stealth_memo` structures to test for recognition.  The full cTXO (including Pedersen commitment, owner structure, range proof, etc.) need not be downloaded.  Because the encrypted data inside the memo indicates the Pedersen commitment, the wallet will know which cTXO it has recognized.  (Witness nodes index cTXO's by Pedersen commitment.) 
+
+(Discuss here a proposed API call for retrieving stealth_memos by block height range)
+
+To know whether a cTXO is still unspent (e.g. by another instance of the wallet), a wallet could attempt to retrieve the corresponding commitment object from an API node.  An empty result indicates the commitment has been spent.  However, this procedure indicates our interest in a specific set of commitments, and the network traffic generated runs the risk of revealing that those commitments are "linked".
+
+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-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.
+
+NOTE: It is currently possible to retrieve all needed info to support recognition of incoming transactions via Elastic Search queries.  This implies: (1) functional wallet behavior can be implemented right away, even if new API calls take longer to implement, and (2) it may be possible to avoid adding new API calls altogether, if the Elastic Search infrastructure is deemed performant enough to support queries from Stealth wallets.  (Although intuitively it seems to me an API method would result in a better user experience). 
+
+## Discussion
+
+### Utility of dual-key addresses
+
+Utilization of the dual-key address format has numerous interesting use cases, including:
+
+* The ability to maintain **watch-only wallets**. By entrusting only the View Key to a view-only node, it is possible for this node to monitor for activity to an address without granting spending access to the same node.  This allows for such things as: opt-in transparency; cash register monitoring; organizational internal auditing, etc.
+
+* The ability to use **address-per-invoice** without introducing substantial additional scanning overhead.  To use this, one keeps the same viewing PubKey and iterates the Spending PubKey part of the address, generating a distinct address per invoice.  When scanning the blockchain, the _Child Offset_ is a function of the shared-secret between OTK and ViewKey, such that _AuthKey = SpendKey + Offset_.  To obtain the public SpendKey, a watching wallet can subtract the Offset from the AuthKey to obtain the SpendKey, and simply compare against a list of per-invoice SpendKeys that were used to generate addresses.  Adding additional SpendKeys to scan for does not incur any additional EC group operations, merely additional byte-wise comparisons, which are trivial. _(Note that while the invoice addresses generated in this manner are distinct, they are not unlinkably distinct, since they share the viewing component.  If a business wants individual invoices to be mutually unlinkable, then this scheme will not be sufficient.  However, this is a consideration for a business's off-chain security practices, as the addresses themselves never appear on-chain or in a transaction.  An alternate solution which allows even the ViewKey to vary, while still allowing for efficient scanning, is presented in [MRL-0006](https://lab.getmonero.org/pubs/MRL-0006.pdf), however this introduces a change in how the deterministic offsets are generated, which would need to be signaled by a flag in the address format and supported by wallets.)_
+
+### 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.  This strategy would be similar to the "Integrated addresses" that can be used on the Monero platform.  Note, however, that this scheme is largely obsoleted by the simple ability to iterate the SpendKey through a HD address family while keeping the same ViewKey in a dual-key address format.)
+
+### Pitfalls and Cautions
+
+#### Specific risks and remedies
+
+##### Sender leaks private _otk_ or private _shared secret_:
+
+TODO: analyze
+
+#### An attack on address key from leak of a transaction private key
+
+A confidential output will have associated with it an "Output PubKey," or AuthKey.  He who can provide a signature from the AuthKey is authorized to spend the commitment.  Automated detection of inbound commitments depends on the deterministic computation of an offset between the One-time PubKey (OTK) and the Address SpendKey, 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 AuthKey.  Only the receiver can do this (by knowing both the offset and the address's private spending key).
+
+Because AuthKeys are only used once, wallet software designers may be led to believe that the security of the AuthKey private keys 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 private AuthKey to reveal the address's private spending key.  Although the general public is not expected to be privy to that offset, the _sender_ of the output is in possession of the offset (and the ability to compute it due to knowing the random _k_ behind the One-time PubKey).  This means the sender would be enabled to compute the address's private key, in the event that the recipient leaks the private AuthKey.
+
+Thus, wallet designers should be advised to treat the private TXO AuthKeys handled by their wallets with at least as much care as the address private keys, 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.) 
+
+## Summary for Shareholders
+
+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.
+
+Most of the work needed to implement this BSIP is in the wallet, namely the correct production of recognizable cTXOs and the process of scanning for owned cTXOs.  The only network-level change is the addition of two API calls: one to return batches of `stealth_memo` fields included in a block range, and one to return batches of consumed commitments (in the case of CT transactions) or used key-images (in the case of RingCT transactions).  These API calls would need to be available on wallet-serving API nodes, but would not be needed on block-producing witness nodes.  There are no consensus changes proposed in this document.
+
+## Copyright
+
+This document is placed in the public domain.
+
+## References
+
+[vS13] - Nicolas van Saberhagen, _Cryptonote v 2.0_, 2013 - https://cryptonote.org/whitepaper.pdf
+
+[NG17] - Sarang Noether and Brandon Goodell, _An efficient implementation of Monero subaddresses_, 2017 - https://lab.getmonero.org/pubs/MRL-0006.pdf
+
+## See Also
+
+* 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)

bsip-1204.md

@@ -0,0 +1,34 @@
+    BSIP: 1204 (unassigned)
+    Title: Deterministic addresses for Stealth wallets
+    Authors: Christopher J. Sanborn
+    Status: Draft
+    Type: Informational
+    Created: 2018-01-29
+    Discussion: <url>
+
+
+## Abstract
+
+To simplify a wallet owner's backup burden by documenting and standardizing key derivation for Stealth balances from the same backup seeds used to generate the user's regular account keys.
+
+## Motivation
+
+Current wallet implementations (e.g. the CLI wallet and Agorise's extensions to the UI wallet) generate a new Brain Key for each Stealth "account" (defined as a confidential balance under the control of a single private key).  Since creating a confidential account is a purely client-side activity, (in contrast with a regular account which is registered on the blockchain), there is no automatic association between a confidential balance and a regular account that ostensibly "owns" it, and a backup burden is created for each new confidential balance.
+
+It would be desireable to give the user the ability to maintain all of her accounts and balances under the control of a single backup key seed or brain key, so that the backup burden can be satisfied just once, at the creation of the user's first regular account.  The derivation schemes defined under Bitcoin's BIP-44 provide a natural mechanism for this, and Satoshi Lab's SLIP-48 already define derivation paths for owner, active, and memo keys on BitShares and similar networks.
+
+We propose here:
+
+(1) To define additional derivation paths for Stealth accounts, and,
+
+(2) For backwards compatibility with existing accounts secured by Brain Key, to standardise and document a distinct procedure for deriving Stealth keys from Brain Keys so that the same Brain Key that secures a user's regular account can also be used to secure their confidential balances, if the user desires.
+
+## Rationale
+## Specifications
+## Discussion
+## Summary for Shareholders
+## Copyright
+
+This document is placed in the public domain.
+
+## See Also

bsip-1205.md

@@ -0,0 +1,30 @@
+    BSIP: 1205 (unassigned)
+    Title: Metadata hiding via Garlic Routing and other means
+    Authors: Christopher J. Sanborn
+    Status: Draft
+    Type: Informational
+    Created: 2018-01-29
+    Discussion: <url>
+
+
+## Abstract
+
+To provide an overview of strategies that can be used by wallets to prevent leaking of sensitive metadata, e.g. your interest in particular balances on the blockchain, to third parties that may be monitoring network traffic, or to potentially compromised nodes on the BitShares p2p network.
+
+## Motivation
+
+Querying a p2p node to check your confidential balances reveals your interest in particular commitments and threatens anonymity by establishing a link between an IP address and a commitment set.  New anonymity technologies such as Garlic routing and i2p can be used to ensure that neither network monitoring nor a compromised p2p node can determine the origin of a request regarding a particular set of commitments, thus protecting anonymity.
+
+Additionally, querying a discrete set of commitments undermines confidential unlinkability.  Unlinkability is the inability to determine that multiple independent commitments are controlled by the same party.  Although not perfect, a partial solution to this is to use Bloom filters to query a superset of commitments, so that the p2p node will return a mix of linked commitments as well as random commitments, making it difficult for an external observer to establish which commitments are actually of interest to the querying party and which are included by the filter serendipitously.
+
+There may also exist other strategies of merit to protect unlinkability and privacy generally.
+
+## Rationale
+## Specifications
+## Discussion
+## Summary for Shareholders
+## Copyright
+
+This document is placed in the public domain.
+
+## See Also