New BSIP 0050: Stealth development, Phase II #88
Comments
|
Well-written, but unfortunately these BSIPs are all incomplete. Can you give us a status update, or a timeline how you plan to proceed? |
|
Got some work coming in on the parent repo at https://github.com/Agorise/bsips/commits/master. Will merge changes into these issues whenever there’s a cohesive chunk worth calling attention to. A lot of background reading and outlining not yet reflected in the docs. Acknowledged that what’s presently here is incomplete. Want to have discussion going even as solutions are being crafted. My most recent work is on 1203 “Detection of Inbound Transactions”, as this one will benefit current CT-based functionality and still carry over to the new stuff, when a favored approach to untraceability (e.g. RingCA) is settled upon. |
christophersanborn
changed the title
|
Draft merged. |
(From: https://github.com/Agorise/bsips/blob/master/bsip-1200.md)
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!!)
Motivation
The initial phase of Stealth development was proposed and implemented in BSIP-0008, 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], 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] 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.
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]. 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.
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.
Backups of Stealth Balances
In BSIP-1204 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, 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
[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
The text was updated successfully, but these errors were encountered: