On Monday I introduced drafts of six new BSIPs (BitShares Improvement Proposals) to the BSIP issue tracker detailing the continued development of Stealth technology on the BitShares platform. They are issue numbers 88, 89, 90, 91, 92, and 93. The six BSIPs discuss various distinct improvements and upgrades to the existing Stealth technology. Stealth is not new to BitShares, but the existing Stealth features are underutilized, in part because of the incomplete privacy that they currently offer. (The features are available in the CLI wallet, however the UI developers have been wisely conservative in not offering features which may impart an exaggerated sense of security.)
“Stealth” here refers the ability of users to conduct certain activities privately. Primarily, this includes the maintenance of private, inscrutable balances of any asset type, and the ability to transfer balances to other users without revealing value amounts or the identities of the parties involved.
Privacy, and therefore “Stealth,” is not a single technology or protocol, but rather several, that address specific mechanisms by which information about a user’s activities may be leaked. An initial round of Stealth development succeeded in implementing Confidential Transactions (CT) in March of 2016 following BSIP-0008. CT provides two major features: value-blinding and stealth addresses. These features, while important, are still very susceptible to chain analysis. This is because inputs and outputs to a transaction are explicitly listed, meaning that for any particular output, a detailed history can be constructed, back to the originating transactions where a public balance was blinded. Unless a user transacts with a large number of other users utilizing the Stealth features, the set of originating transactions in an output’s history may be small and highly likely to identify the user (or a small number of users) and suggest plausible value amounts. In fact, casual users of Stealth may be receiving little to no privacy benefit from the features as currently implemented.
Thus, additional features and measures are still required to provide acceptable levels of privacy to the users of the Stealth feature.
Towards that end, I have written rough drafts of six BSIPs addressing specific components of continuing Stealth development, which, taken together, will result in an enormous increase in privacy afforded to the users of Stealth features on the BitShares platform. These are still very early drafts, and in some cases only partially complete, if not mere stub articles. In some cases, there are more than one available solution to a particular problem, and involvement and discussion from the developer community is needed to ensure the best path forward is chosen. Further research and documentation is still needed to complete the BSIPs to the level where a decision on whether to implement can be made.
Active editing of the BSIP drafts is currently happening in Agorise’s fork of the BSIPs repository. The text of each BSIP will be periodically merged into the corresponding issues in the core BSIP repository, which will be the preferred location for technical discussion on each document. @Agorise and @kenCode have been constant believers in the future of Stealth on BitShares and a tremendous support in the initial research and writing of these BSIPs, and cannot be thanked enough.
The six BSIPs subdivide the work into logically distinct components. The first BSIP serves as an entry point and summary of the remaining BSIPs. The very latest version will always be located here:
https://github.com/Agorise/bsips/blob/master/bsip-1200.md
A table of all six BSIPs describing the specific components is located in the above link, and is also replicated below: (Numbers are mere placeholders until officially accepted into the core BSIP repository.)
Note that these BSIPs are NOT done yet! I am introducing them now so that community involvement and discussion can guide the development. If I propose a bad idea, I want you all to call me out on it!
| Number | Title | Type |
|---|---|---|
| 1200 | Stealth development, Phase II | Informational |
| 1201 | New operations for Confidential Asset (CA) transactions | Protocol |
| 1202 | Ring signatures for untraceability of Stealth transactions | Protocol |
| 1203 | Blockchain scanning for inbound Stealth transactions | Protocol |
| 1204 | Deterministic addresses for Stealth wallets | Informational |
| 1205 | Metadata hiding via Garlic Routing and other means | Informational |
In addition to the introductory BSIP (latest draft here, GitHub issue here), very brief summaries of each Stealth Phase II component are given as follows:
Confidential Assets (CA) extends Confidential Transactions (CT) by hiding not just the value amounts of a transaction, but also the asset type. For a multi-asset platform such as BitShares, this extension has obvious value. (Latest draft here, Issue here)
Here several options are considered to provide untraceability. At the moment I favor adapting RingCT (which combines ring signatures with Confidential Transactions) to incorporate Confidential Assets, forming RingCA. RingCT is already used by privacy-centric coins such as Monero, thus it is a tested technology. However other options are also worthy of consideration, including MimbleWimble and Sigma protocols combined with ZeroCoin. (Original ZeroCoin required a trusted setup, which is not desirable, however with Sigma protocols the trusted setup is no longer needed [Yap2017, Groth2014].) (Latest draft here, Issue here)
Existing Stealth functionality on BitShares does not provide a mechanism for automated discovery of inbound Stealth transactions. Instead, a transaction "receipt" needs to be communicated from sender to receiver. This is a consequence of stealth addresses — even the recipient doesn't know a balance belongs to them if they don't possess a "shared secret" between sender and receiver! Of course, it is possible to embed this data in the blockchain in a way that only the receiver can find and decrypt it. This BSIP is to propose mechanisms for this process and API extensions (if needed) to support it. (Latest draft here, Issue here)
This one is simple. It proposes to document a standard process for deriving stealth addresses from a wallet seed, to facilitate easy wallet backup. Nothing technologically new here — UTXO-based coins have been using this feature for years — it just needs to be documented so that various wallet vendors can keep to the same standard. (Latest draft here, Issue here)
This one is more open ended. It has to do with eavesdroppers listening in on your wallet's communication with the network. Let's say your Stealth balance is composed of ten different balance elements (called commitments) on the blockchain. Nobody would know that all ten of them belong to the same person (this is called unlinkability)... until your wallet querries all ten of them in one communication to check your balance! In this BSIP we propose wallet behaviors that avoid compromising the privacy measures that underpin Stealth. (Latest draft here, Issue here)
You may have noticed that sometimes I capitalize Stealth, and sometimes I don't. And you may have also seen all-caps STEALTH if you are a follower of the long story arc of this BitShares feature.
When I capitalize "Stealth," I am referring to the Stealth technology as implemented (or planned) on the BitShares network. It refers to the aggregate of specific technologies that are mobilized when a user uses the Stealth features.
You may have also noticed lowercase, as in the phrase "stealth addresses." Stealth addresses are one specific technological component of the Stealth feature set.
Lastly, although I've made no mention of it above, you may have seen STEALTH. STEALTH refers to a tradeable asset on the BitShares platform that users can buy and sell. Users do NOT need to hold STEALTH tokens in order to use the Stealth features! The STEALTH tokens are a "Fee-Backed Asset" (FBA) which are bought-and-burned with the transaction fees used to make Stealth transactions. The FBA is intended to support the development of Stealth features, as described by BSIP-0007
I personally intend to take the lead on the completion of the Stealth BSIP drafts, and thereafter on the implementation of the features.
The BSIPs above all include at least an abstract and motivation section, nevertheless much remains to be done. Broad description of the proposed solutions are included, but the detailed specifications are still to be drafted. I intend over the coming weeks to do the necessary research to articulate solutions to the level of detail needed to allow committee assessment and implementation, should the community wish to implement.
For cases where more than one good solution may exist, I will research and draft concise summaries of available options to allow comparative evaluation and involved discussion from the community, to result in the best possible solutions.
I have been passionate about crypto since 2014 and have worked within the BitShares ecosystem for just over a year. My primary interest is in making existing systems more private through applied cryptography. I am a believer in individual liberty, and that privacy is essential to preserving freedom. I have over two decades of software development experience. Like many in this field, cryptography and crypto economics are more recent passions. I come from a background of scientific computing.
Thank you for reading along, and allowing me to make this introduction and to articulate my plans. I welcome all commentary and feedback!
Images: 1 Beach Chairs in Bichromatic Infrared; 2 Beer Pong Bugs; 3 Bugz!
Christopher Sanborn is passionate about cryptocurrencies, individual liberty, agorism, photography, peaceful parenting, and making the world a better place through cryptography. He has a Ph.D. in Physics and over a decade of experience in scientific computing and software development. Follow him at 
