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

Addition of draft material for Stealth Development, Phase II, comprising BSIPs 1200 through 1206 (temporary numbers).

master
Christopher Sanborn 2018-03-16 12:15:45 -04:00
parent adb233735f
commit f32a60c08e
8 changed files with 305 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
README.md
View File

@ -45,3 +45,10 @@ 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) | Op-codes for Confidential Asset operations | Chris Sanborn | Protocol | Draft
[1202](bsip-1202.md) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol | Draft
[1203](bsip-1203.md) | Retrieve Stealth UTXO sets by block-height range | Chris Sanborn | Protocol | Draft
[1204](bsip-1204.md) | Blockchain scanning for inbound Stealth transactions | Chris Sanborn | Protocol | Draft
[1205](bsip-1205.md) | Derivation of Stealth Addresses from BIP44/SLIP48 Seeds and Brain Keys | Chris Sanborn | Informational | Draft
[1206](bsip-1206.md) | Metadata hiding via Garlic Routing and other means | Chris Sanborn | Informational | Draft

74
bsip-1200.md Normal file
View File

@ -0,0 +1,74 @@
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 six BSIPs which define components of that development.
## 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 privide 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 should be reasonably assured that their privacy is complete, and not underminable by easy-to-make procedural mistakes.
### "Blind" 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 propose by this and associated BSIPs are as follows:
#### Asset Hiding
Confidential Assets (CA) extends Confidential Transactions (CT) to include asset hiding. It is described in a paper (link) by Greg Maxwell. 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 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. 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 comunicate to the recipient a "transaction receipt" that contains, in encrypted form, data that the recipient needs in order to take posession 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) and [BSIP-1204](bsip-1204.md).
#### Backups of Stealth Balances
In [BSIP-1205](bsip-1205.md) we propose standardized derivation of Stealth addresses to enable backup seeds or brain keys 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-1206](bsip-1206.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 - https://people.xiph.org/~greg/confidential_values.txt

23
bsip-1201.md Normal file
View File

@ -0,0 +1,23 @@
BSIP: 1201 (unassigned)
Title: Op-codes for Confidential Asset operations
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>
## Abstract
Confidential Assets (CA) extends Confidential Transactions (CT) 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.
## Motivation
## Rationale
## Specifications
## Discussion
## Summary for Shareholders
## Copyright
This document is placed in the public domain.
## See Also

86
bsip-1202.md Normal file
View File

@ -0,0 +1,86 @@
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.)
## Discussion
### Overview of alternative untraceability solutions
(Compare/contrast with other schemes for providing untraceability, including ZeroCoin accumulators, master-node facilitated tumbling, MimbleWimble, etc.)
#### 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.))
#### 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)
* 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 - https://people.xiph.org/~greg/confidential_values.txt
[2] RingCT - https://eprint.iacr.org/2015/1098

28
bsip-1203.md Normal file
View File

@ -0,0 +1,28 @@
BSIP: 1203 (unassigned)
Title: Retrieve Stealth UTXO sets by block-height range
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>
## Abstract
To extend the WebSocket API to include a method to retrieve Confidential (blind or stealth) UTXO sets by block-height range.
## Motivation
The current API specification only allows for the retrieval of a single UTXO (Unspent Transaction Output), and requires the requestor to know in advance the Pedersen commitment of the desired UTXO. The method of request does not allow for discovery of inbound transactions, and this is the reason why the current implementation of blind transactions depends on participants transmitting out-of-band receipts to the recipient. This introduces a risk of lost funds should the receipt go untransmitted, or become lost.
To support automatic discovery of inbound funds, it is proposed to allow wallet clients to retrieve entire sets of Confidential UTXOs (CTXOs) and scan them client-side to determine which ones are directed to the scanning wallet. This BSIP documents a proposed API extension to allow retrieval of CTXOs by block-height range to facilitate this purpose. Complementing this BSIP is BSIP 1204(temporary) which documents the broader process of scanning for inbound transactions, including necessary changes to the Stealth Memo format to enable discovery.
## Rationale
## Specifications
## Discussion
## Summary for Shareholders
## Copyright
This document is placed in the public domain.
## See Also

23
bsip-1204.md Normal file
View File

@ -0,0 +1,23 @@
BSIP: 1204 (unassigned)
Title: Blockchain scanning for inbound Stealth transactions
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>
## Abstract
A confidential (blind or stealth) transaction (CTXO) does not identify the recipient. As such, there is no direct way for a wallet to query the p2p network for inbound transactions. Instead, a wallet must either (a) inspect all CTXOs and test a challenge condition on each one, or (b) transmit to the p2p node some kernel of the challenge so that the p2p node can select an inclusive CTXO set. The latter option likely undermines unlinkability. At present, the WS API offers no mechanism for retrieving whole sets of CTXOs between certain block-height ranges, thus a wallet must know the Pedersen commitment of CTXO that they are interested in. This is the reason for transaction receipts. Lost or untransmitted receipts can result in lost funds. It is proposed that the Witness Node component be updated to (a) index not just the Pedersen commitments, but also the stealth memo and/or range proof fields of CTXOs, and (b) afford an API method to retrieve CTXOs in a specified block range, so that wallets can scan and identify inbound transactions. This will obviate the need for both receipt transmission and receipt storage by sender and recipient. The stealth memo format may also need updating to support challenge tests.
## Motivation
## Rationale
## Specifications
## Discussion
## Summary for Shareholders
## Copyright
This document is placed in the public domain.
## See Also

34
bsip-1205.md Normal file
View File

@ -0,0 +1,34 @@
BSIP: 1205 (unassigned)
Title: Derivation of Stealth Addresses from BIP44/SLIP48 Seeds and Brain Keys
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

30
bsip-1206.md Normal file
View File

@ -0,0 +1,30 @@
BSIP: 1206 (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