Introducing Stealth II on Bitshares Talk

This past Saturday morning (September 1st) I had the opportunity to talk about the BSIP drafts I have introduced for "Phase II" of Stealth development on BitShares (see introductory article here) on the BitsharesTalk weekly hangout/podcast.

The hangout was recorded and is available on YouTube here, thanks to user @steempowerpics. (For my segment, skip to about 42 minutes and 30 seconds.)

For those who can't easily watch or listen, I have included the script I wrote up for it below. Note: this is the script of what I intended to say, so it's not an exact transcript of the show. (In particular, it omits questions and their replies.) But this should give a good overview if you just want to skim or can't listen right now.

---

Hi, I am Christopher Sanborn, and I’m planning on bringing the next level of Stealth to the BitShares platform.

First, a quick overview of who I am and my background. I come from a mathematical/scientific, academic background. I have a Ph.D. in Physics, a life-long passion for computer science, and like many in the crypto space, a much more recent passion for Cryptocurrencies after discovering Bitcoin at the end of 2013. I’ve been in the BitShares ecosphere ever since @kenCode of @Agorise brought me in a little over a year ago. Prior to that I really didn’t know much at all about the Graphene platform, or the advantages it offered over Bitcoin.

Now, with Ken, I’ve worked on developing UI-wallet support for the already existing Stealth features on BitShares, which are currently absent from the UI wallet (you must use the CLI wallet). With Ken I developed a prototype javascript library to support the needed crypto primitives for a Stealth wallet. This library is functional but is limited mainly by performance issues with computing the range-proofs in-browser. Currently, these just take too long to compute, even on newer hardware, because the code is running in-browser. However we are currently working on a Kotlin implementation to use in smart phone wallets, which should be much more performant.

Now, as for Stealth on BitShares generally: I’m going to talk about: (1) what features are implemented and functional RIGHT NOW on the network, and (2) what features I think we need before the privacy features that BitShares offers are worthy of the name “Stealth” and are providing the level of privacy that users should rightly expect.

So what do we have RIGHT NOW:

The privacy strategy that BitShares currently employs is called Confidential Transactions. Confidential Transactions is a strategy of using blinded Pedersen commitments, which are a mathematical construct, to encode value commitments in a way that is inscrutable to parties not in possession of a secret number called the “blinding factor,” and yet which must remain validateable by the network, meaning that the network can confirm that transactions which input old commitments and output new commitments, do not create or destroy money in the process. The network confirms that the transactions balance, but it does so without knowing the value amounts.

OK, now here’s where I talk about what “privacy” means, and I’m going to divide it into three specific properties, and argue that Confidential Transactions only reliably provides ONE of those properties.

So what is privacy? The three properties I’m going to describe are:

1.) Confidentiality,
2.) Un-traceability, and
3.) Un-linkability

These three properties are pretty-well summed up by the phrase:

“Unknown, sent Unknown, to Unknown”

The middle Unknown represents Confidentiality. It represent the question: What was sent in the transaction? It’s unknown. That’s confidentiality: the contents of a message, or, in this case, the value of a transfer, are unknown.

The first unknown in the phrase, “unknown sent unknown to unknown,” represents the property of untraceability — that is the question: Who initiated this transaction? And in fact it’s actually broader than that. Tracing is about discovering not just WHO is the instigator of a particular transaction, but potentially uncovering a whole history of instigators going all the way back to some originating event. This is tracing.

And finally the last unknown in the phrase. That one is unlinkability, and this has to do with who is on the receiving end of the transactions. Although actually I am somewhat abusing the term — because “linkabilty” isn’t technically about linking a particular transaction to a particular person, but really is about the ability to determine whether transaction outputs from multiple different, unrelated transactions are destined to the SAME individual (whether the real person is known or not.) So it’s basically whether disparate activity can be pinned on the same person, where the pattern might risk identifying the real-life identity.

So these are the three properties of privacy. They cover the protection of the message, or value amount, and the protection of the identities of the people involved.

Now the main feature of Confidential Transaction is — right in the name — Confidentiality. The primary achievement of Confidential Transactions is to blind the value amount of a transaction. But Confidential Transaction DOES NOT provide untraceabilty. (And I’ll comment in a moment about how well it provides unlinkability).

The reason for this is because Confidential Transactions follows the same UTXO model as Bitcoin does. (This is in contrast to BitShares and coins like ethereum which use an account-based model to represent user balances.) In the UTXO model, individual transaction outputs are consumed and replaced with new outputs when a transaction occurs. Your “balance” is actually the aggregate set of all Unspent Transaction Outputs, (abbreviated UTXOs), which are under your control.

And the reason this makes our transactions traceable is because the transaction format explicitly names the UTXOs which are to be consumed as inputs. Thus for any particular Pedersen commitment on the chain, a complete history of prior transactions can be constructed, going all the way back to some set (whether it’s a big set or small set) of public users who initially blinded the coins involved in that output’s history.

Thus, for users of Confidential Transactions, especially casual users who may wish to blind only a small amount and send it to a friend, the traceability of this sequence of events represents an almost complete negation of the privacy strategy employed. Think about it: If I blind 100 BTS into a stealth address, send 80 BTS to a friend’s stealth address, then that friend unblinds the 80 BTS and uses it to buy some forbidden literature, such as maybe Henry Hazlitt’s Economics in One Lesson, then the traceability of that sequence of events makes it completely obvious who actually paid for that book, even though there was a transaction in the middle of the sequence that was, in isolation, completely inscrutable.

Now, the unlinkability properties of Confidential Transactions are somewhat less compromised. CT actually provides a reasonably good unlinkability solution in the form of what are called stealth addresses. But the unlinkability is with regards to chain analysis alone. Somebody who can monitor network activity can break the unlinkability if a user’s wallet naively queries a public API node to confirm that all of their unspent commitments still remain un-spent. And so a discussion of appropriate wallet behavior needs to be had. A user may need to run a full node, but this has a convenience impact for casual users.

And so given these shortcomings of Confidential Transactions, I think it’s actually quite fortunate that there has been this delay, this feet-dragging, between the implementation of network support for CT and, and user support in the graphical UI wallet. Despite the importance of privacy, we actually DON’T want people using this feature under the impression that they are getting more privacy than they actually are. Although I do want to be careful as I say this, to acknowledge the substantial accomplishment of the BitShares community in having implemented Confidential Transactions in the first place. The feature has been online for two whole years now, and to my knowledge BitShare was the first mainline chain (not counting proof-of-concept chains) to implement Confidential Transactions. (Monero has since implemented a variation of it, but only about one year ago, I believe). That is a significant accomplishment and accolade to the BitShares community. And the only thing I want to emphasize here is that it’s not ENOUGH. Something more is still needed.

And so here I come to the BSIPs which I have introduced, which are a beginning of the process of speccing out in detail the changes and improvements to be made. And I want to emphasize beginning — because the BSIPs are not completely written yet — I am still writing them. They provide an overview and structure, but I will be continuing to write them to make them definite.

There are six distinct documents, of which one of them is an introduction, covering the reason WHY. It’s pretty much what you’ve heard me say right here just now. And then there are five more documents addressing specific solutions to specific privacy needs of Stealth on BitShares.

In very quick overview, they are:

BSIP 1200 — (the numbering here is just temporary placeholder numbers, until they get assigned numbers in the normal sequence) — BSIP 1200 is the Introductory BSIP.

The first one after that is BSIP 1201 — and it’s for the adoption of Confidential Assets. Confidential Assets is a stepwise improvement to the confidentiality of Confidential Transactions. Specifically, CT blinds ONLY the value amount of a commitment, not the asset type. But BitShares is a multi-asset chain. Keeping blind balances of assets other than the core BTS token is doable in the current implementation, but for it to work, the transaction output must explicitly name the asset type. Confidential Assets uses hashes of a formalized asset-description as a generator element in constructing the blinded Pedersen commitment, allowing for the hiding of both value and asset type in the transaction outputs.

Next is BSIP 1202 — and this covers Ring Signatures. This is the biggest and most important one, in my opinion. Because this is the untraceability solution. The scheme here is borrowed from Monero, which has used ring signatures to provide untraceability since the very beginning of the coin. Now interestingly, Monero has NOT had “confidentiality” until recently. JUST untraceability and unlinkability. Confidentiality was added only recently when they combined ring signatures with Confidential Transactions to form RingCT, which is what I propose we adopt into BitShares.

Now how it works is this: A ring signature scheme allows transactions to be built with a SUPERSET of transaction inputs. This means that the inputs to your transaction are not merely your OWN inputs, but you also throw in a smattering of OTHER PEOPLE’s inputs. The ring signature that you provide proves ONLY that the necessary inputs needed to cover the outputs are authorized, but does not allow you to determine WHICH inputs those are. This means that if you trace the history of an output, that history will include not only the involved parties, but also numerous other parties who are merely “accused”, if you will, of being an involved party. And there’s no way to tell them apart. THIS is the golden property that allows even casual use of Stealth to be very, very secure. Because the history of any transaction is broadened to include numerous parties who had nothing to do with your transaction.

Lastly, the remaining three BSIPs primarily get into more and more minutia. BSIP 1203 is a discussion of identifying inbound transactions without the sending and receiving parties needing to be in direct contact with one another, which is fairly important on the usability and convenience front. BSIP 1204 proposes using hierarchical deterministic stealth address determination to make wallet backup a one-time event on wallet creation, rather than something that needs to be repeated to secure each new inbound transaction, and BSIP 1205 seeks to be a best-practices reference for wallet behaviors to ensure that wallets don’t inadvertently and unwittingly compromise privacy protections through their interactions with the network and/or public API nodes.

The biggest proposed improvement here is, in my opinion, the ring signatures, and how by essentially taking a page out of Monero’s book, we can have top-notch privacy, using tested, proven methods, and without having to get into the interesting though esoteric bleeding edge stuff such as zkSNARKS a la Zcash. And along the way we can consider some interesting new optimizations, such as BulletProofs, which are a new strategy for constructing range proofs that is only logarithmic in the bit length of the value message, rather than linear, and shrinks the supplemental proof data that needs to accompany a Stealth transaction by rather a large margin. Additionally, although I dare not speak on the subject just yet, I am intrigued of late by MimbleWimble, another new and stunningly clever transaction system based on Pedersen commitments which has some really nice storage and pruning characteristics. And I do wonder if some aspects of that could be included as well, although that is an open question for now.

And with that I’d like to say THANK YOU, for listening. I hope that I have provided you all a little bit of an introduction as to who I am and what I am hoping to achieve, as well as to provide some excitement for things to come.

---

See Also

• Stealth on BitShares - Development Phase II

---

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 @malacandrahyoi.