I’d like to point out that the threat models under which Zerocash and Zcash were designed, have always included the possibility of powerful adversaries with the ability to compromise a subset of devices, redirect some network connections, etc. I’m not claiming that we can provide ideal privacy against such adversaries, but the strong “ledger indistinguishability” property obtained by Zerocash/Zcash goes a long way to protect the counterparties that a compromised user has transacted with using shielded transactions. When we’re able to remove t-addresses, that will provide a substantial further improvement to systemic privacy.
My impression (which I need to confirm by looking at the actual blockchain) is that other than standard multisig scripts, there is negligible use of nontrivial scripts on the Zcash network. So, if we support shielded multisig then that’s sufficient to unblock the removal of t-addresses.
There are proposals, such as P2VK and Zexe, for supporting arbitrary proof statements in a Zcash-like cryptocurrency. This is in principle more flexible than the Bitcoin script system and could support Ethereum-style smart contracts, where (unlike Ethereum or Bitcoin) the statement being proven could be completely private. However, in my opinion just dumping support for that into the low-level consensus protocol without the necessary tooling to write secure contracts would be at best unusable, and at worst a recipe for encouraging people to lock up their money into contracts for which any tiny bug would cause it to be lost. I would expect a few more years of improvement of the tools around zk proof systems to be necessary before Zcash adds something like that.
Note that support for user-issued tokens, which seems to be the main thing people use Ethereum smart contracts for, does not actually require smart contracts.
I’ve quickly checked the protocol, and it seems to me that multi-sig in the same vein as Monero might already be possible with sapling.
If all signatories are fine with the proof authoring key being known to all of them, they can generate nsk and ovk in some manner known to all of them. Whilst it is possible to compute ak through multi-party computation.
For N of N multisig, if everyone has their own key ask_i, with corresponding public keys ak_i = ask_i * G then one can simply set ak = sum_i ak_i without ever needing to compute ask = sum_i ask_i.
For 2 of 3 multisig, Monero has a complicated method that achieves the same thing (it could work for M of N in general, but I believe it needs O(N) rounds).
There are two things I didn’t check that might block this idea.
Firstly, perhaps redDSA signatures don’t commute w.r.t. addition on keys, which would block computation of the signature by all signatories.
Secondly, if it is a consensus rule that ask, nsk and ovk are all derived from sk then the PRF between sk and the other secret keys makes it essentially impossible to do this multi-party computation.
This is what @daira refers to as “RedDSA-based multisignatures” here:
It should require no changes at all to use, because an aggregated N-of-N multisignature is indistinguishable from a regular signature, and so can be used in the existing spendAuthSig slot in a Sapling shielded input.
This would be similarly more complicated for us, particularly as we really want M-of-N threshold multisignatures to be indistinguishable from regular signatures and N-of-N aggregate multisignatures. @daira has outlined (in the issue linked above) some possible ways to do this inside a circuit, but that obviously would require a circuit change, and so could not be implemented until the next time we do one.
The signatures are technically commutative, in that no matter which order the signers apply their signing keys, the resulting signature would correspond to the aggregate multisignature public key. The signing process itself would require at least two rounds, because all signers need to use the same R in order for the signature to work, and thus need to know all other signers’ r_i values. It might require 3 in order to prevent later signers from manipulating their r_i values based on what other signers chose.
There is no consensus rule enforcing how these are derived. In the protocol spec, sk is a convenient way to derive the various values from a single root. We don’t use this in zcashd, instead using the derivation process outlined in ZIP 32 for HD derivation.
If you knew another signer’s r_i, then you could compute their private key from their partial signature. Fortunately, you actually only need the other signers’ R_i values. (Every signer computes the random oracle hash over the combined R, not their R_i.)
But yes, n-of-n multisignatures are completely practical without a consensus change. The devil is in the detail, and we’ll be writing a spec and security proof for that.
This would be similarly more complicated for us, particularly as we really want M-of-N threshold multisignatures to be indistinguishable from regular signatures and N-of-N aggregate multisignatures.
As far as I can tell, the monero 2 out of 3 meets that requirement. here is a simple explanation of how they do 2 out of 3. Unless there is some weird bias in the outcome of ECDH, an address derived like this looks just like any other address.
The real issue is the ammount of rounds needed to set it up. That is, it requires cooperation of all 3 parties to create a 2-3 multisig address. This probably hurts the ‘escrow’ use-case.
All of this presumes it is fine for the spend-authority to be the only thing split up between all 3 parties. Proof authorizing would be available to each individual.
I don’t think it’s particularly difficult to use Zcash’s privacy features.
Just install zec-qt-wallet and enjoy full privacy (it uses Sapling z-addresses by default).
Bitfly’s Flypool is a pool supporting Sapling z-addresses.
Shapeshift also supports z-addresses. It requires KYC nowadays but in any case privacy and anonymity are two different things. The exchange knows the amount and addresses it sent the funds to but has no idea where the funds moved to after that.
Of course, more services can and will implement the “privacy by default” features but it’s totally up to them. Sapling z-addresses are also coming to iOS and Android as both implementations are in the works.