Bytemaster, please don't make stealth transfers require only a single key permission to spend the blinded output balances. That would mean there would be no way to have multisig protection of balances received through stealth transfers starting from the moment they are received. The user could of course quickly move the balances to another account (obviously not their main account since that would just compromise the privacy of the stealth transfer unless it was funneled through a CoinJoin-like process first [1]) with appropriate permissions set up shortly after receiving it, but this would be an annoying (and costlier) inconvenience. And if the funds were sent unsolicited, there can be an arbitrarily long period of time during which the funds can be stolen by an attacker who knows the account's active private key and is scanning the blockchain with it looking for opportunities to make money.
Of course stealth transfer recipient's having many different permission structures harms privacy. If only one account has an M-of-N multisig set up for a particular value of M and N, then sending a stealth transfer to that account while respecting their multisig permissions would create an output balance with a M-of-N multisig spending permission, which would clearly associate the supposedly stealth balance output to the named account.
For maximum privacy while still balancing usability, I think all stealth transfer output balances on the blockchain should follow the same spending permission system that I will describe next. Each account that specifies that it can receive stealth transfers should also specify three public keys: a hot key, a cold key, and a third-party key. Each of these keys will be converted into an obscured version for use in the output balance using child key derivation. The obscured hot key will be derived from the hot key using a child index of sha256(sha256(V)), where V is the shared secret. The obscured cold key will be derived from the hot key using a child index of sha256(sha256(sha256(V))). And, the obscured third-party key will be derived from the third-party key using a child index of sha256(sha256(sha256(sha256(V)))). The different hashes are used so that if any of the three keys are the same, that equality relationship will not also be visible with the obscured keys. Furthermore, the index for deriving the obscured third-party key from the third-party key (for use in possibly signing a spending transaction) can be shared with the third-party without exposing the decryption key for the memo or the blinding factor for the blinded balances to the third-party. To spend the balance the network would require a signature from either the obscured cold key OR signatures from both the obscured hot key and the obscured third-party key. The idea is to allow the cold storage private key alone to be able to spend/recover the funds [2], or alternatively to spend/recover the funds using the hot private key and cooperation with the owner of the private key corresponding to the third-party key assigned to the account (this allows two-factor authentication even for spending output balances of stealth transfers). Now if the user is not interested in relying on a third-party, the third-party key in the account can be also set to the hot key, thus allowing either the cold storage private key or the hot active private key to spend the balance. Regardless of the setup, the public always sees output balances with three unique keys in the spending permissions, so they cannot determine whether it is a multisig setup or not.
I also think it is important to add EdDSA cryptography to Graphene so that users have a computationally and user friendly way of computing threshold signatures. The new multisig permission system in Graphene is very powerful but it has two characteristics that can be perceived as flaws in some cases. First, the number of signatures needed (and thus transaction fees) scales with the number of parties that need to sign, whereas threshold signatures are indistinguishable from a single normal signature. Second, the permissions structure is public (some entities, such as companies and organizations, may wish to hide such information with the opaque threshold signatures even though it comes at the cost of having to manually update public keys any time a single key in the permission hierarchy needs to change and also needing to coordinate the signature generation process off-chain). Furthermore, threshold signatures become very useful in stealth transfers because any of those three keys can have their independent opaque threshold scheme (I think... do hierarchical deterministic wallets using EdDSA still allow threshold signature generation?). So you can imagine that the third-party key added to an account would actually be a result of some threshold scheme set up by the two-factor security company.
[1] By the way, I think it is so important to make sure the blockchain has all the support it needs to make CoinJoin-like processes easy and efficient to do, and then also have some standard code built into the wallet frontend and backend that implements that process. It would be great if the following was possible. The user's wallets could submit to the wallet host a pseudo-transaction with blinded input operations that each pay a small unblinded fixed fee, blinded (with random blinding factors) output operations that each pay a small unblinded fixed fee, and the blinding factor difference to make the balance proof possible. Then the host waits to collect these pseudo-transactions (for the same asset type) from many different users and aggregates them together in random order into a single transaction (the wallet host will have to balance inputs and outputs by adding to the transaction a commitment to 0 value with a blinding factor equal to the sum of the collected blinding factor differences, and also sign that commitment with the blinding factor to prove it is committed to a 0 value). Then the wallet host sends the completed unsigned transaction to all those users so they can verify, sign, and send the signatures to the wallet host who would then finally broadcast the final signed CoinJoin transaction. The wallet host knows the metadata of which inputs map to which outputs (but not the amounts which are blinded), but the public doesn't know either the amounts or the mapping.
[2] I believe it is also necessary for the hot active private key to always be set up such that it can be derived from the cold storage private key since the hot active private key is needed to derive the one-time private key for the output balances of the transaction which is in turn needed to calculate the shared secret V. In fact, going from the one-time private key to V also requires knowing the recipients public key, which means the recipient of the transaction must be known. Since there is so much free space available thanks to the blinding proofs, it shouldn't be any problem to use some of that space to store important information to help recovery. For example a decryption key derived from the one-time private key could be used to decrypt a fixed-size first segment of the encrypted memo that stores information meant for the senders eyes only. This information would store a small checksum and the account ID of the recipient (and perhaps even the recipient public key as well to speed the process up if space isn't a problem) which would provide enough information to then derive V. The encrypted memo may even have a fixed-size second segment which can be decrypted by an observer (assuming the recipient account assigned an observer account for stealth transfers) and would have a checksum to let the observer know that this transaction output was meant for them and the account ID of the recipient so that the observer would know who to inform of the transaction. Then the rest of the encrypted memo would be the third segment which would be the original encrypted memo that uses V as the encryption/decryption key. The observer could scan the blockchain with just a single key to quickly determine whether the transaction outputs of a stealth transfer concerned them or not, and if it did, with a little more work could determine the recipient account that (if the account was a customer of the observer) would need to somehow be informed of the existence of this transaction since it would very likely be a stealth transfer of some asset to the recipient. That way senders don't need to rely on off-chain methods of communicating the existence of a balance output to the recipient, and also it is in theory possible for the user to recover all stealth balances without needing full access to the blockchain by delegating the scanning task to the user's observer (perhaps after compensating the observer with some fee) and without needing to reveal any information to the observer that could allow it to steal (or even view the balance of) the funds.
Edit: Actually, after thinking about the cryptography more, I believe what I missed was that the "free" space in the signature used in the memos could only be useful for those who are supposed to be able to see the unblinded values. If I understand it correctly, the random nature (to those without a decryption key) of the encrypted memo means that outsiders cannot tell which version of the commitment in the ring for each blinded bit is the "corrected" one, but those with the decryption key would easily be able to deduce that information and thus figure out what the underlying value actually is. So, again assuming I understood correctly, it is only possible to design the cryptography to share the "free" memo space between the sender and receiver (both of which must be able to get access to the plain-text amount), but not an observer who is not supposed to know the plain-text amount (the observer would just need a separate small fixed-size memo field outside of the signature if we would want it to be able to do its job).
Topic: What if BitShares could have perfect privacy? (Read 17520 times)
