Added more links and references

bsip-1200.md

@@ -47,13 +47,13 @@ Specific features and enhancments proposed by this and associated BSIPs are as f
 
 #### 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 is in [BSIP-1201](bsip-1201.md).
+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.  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.)
+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).
 
@@ -82,4 +82,8 @@ Lastly, in [BSIP-1205](bsip-1205.md), we propose methods of hardening wallets ag
 
 * Phase One of Stealth development: [BSIP-0008](bsip-0008.md)
 
-[1] Confidential Transactions - https://people.xiph.org/~greg/confidential_values.txt
+[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

@@ -9,7 +9,7 @@
 
 ## 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.
+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.
 
 ## Motivation
 ## Rationale
@@ -21,3 +21,7 @@ Confidential Assets (CA) extends Confidential Transactions (CT) to include asset
 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 

bsip-1202.md

@@ -45,7 +45,7 @@ It should be noted that one drowback of this scheme is that it is no longer poss
 
 ## Specifications
 
-(Detailed description of RingCT with annotations for how it would be adapted to BitShares Stealth transactions.)
+(Detailed description of RingCT with annotations for how it would be adapted to BitShares Stealth transactions.) [[2]](#see-also)
 
 ## Discussion
 
@@ -53,11 +53,19 @@ It should be noted that one drowback of this scheme is that it is no longer poss
 
 (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.
@@ -68,6 +76,7 @@ It should be noted that one drowback of this scheme is that it is no longer poss
   * 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
@@ -81,6 +90,14 @@ This document is placed in the public domain.
 
 ## See Also
 
-[1] Confidential Transactions - https://people.xiph.org/~greg/confidential_values.txt
+[1] Confidential Transactions (Greg Maxwell) - https://people.xiph.org/~greg/confidential_values.txt
 
-[2] RingCT - https://eprint.iacr.org/2015/1098
+[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