Looking at the blockchain it appears that the majority of Transparent—>z-address movements are made by miners or the ECC (multiple 2.5 combined output combined).
I therefore assume that the majority of Z-Z should have as source (or receiver?) miners or the ECC (unless someone prints coins in the shielded pool).
I personally find hard to use shielded transactions, not for a lack of wallets that supports it, but rather for a lack of merchants accepting z-addresses.
I agree that merchant adoption needs to get a lot better (e.g., see the education aspect on which I posted earlier today).
But note that the metric you observe doesn’t really say much about who does shielded transactions. It just tells you how funds enter the shielded pool. Even in the hypothetical world where everybody used z→z for all their payments and fund movement transactions, you’d still see block rewards sent to t-addresses and then shielded (by miners and ECC) using t→z transactions.
Also, you can actually expect this metric to improve when the Shielded Coinbase ZIP gets merged and activated, since using block rewards will no longer require t→z shielding. But this won’t reflect any merchant adoption…
Remember, you can send from your shielded z-address, to a merchant’s t-address, and your shielded balance and shielded address remains hidden from the blockchain. In that case, the amount of the transaction will be displayed on the blockchain, which is often helpful for showing the merchant proof of payment. IMO, until view keys are developed, z–>t is the ideal way to pay merchants.
Viewing keys won’t give us per-transaction proof of payment. For that, we need the payment disclosure feature, not yet available for Sapling.
(Oddly, payment disclosure are not mentioned in @nathan-at-least’s ECC R&D and Engineering Flight Plan or any recent GitHub updates I’ve noticed… I hope this is loose terminology rather than intentional omission.)
Well this is one part of the general barrier: “I’m used to the Bitcoin-ish way of doing things, where everything is easily visible on-chain and on block explorers, and now I have to learn/implement a whole new way of doing things”.
I wonder how many prospective users looked at this deeply enough to realize that this particular issue (“how can I prove that I sent the payment?”) doesn’t even have a satisfactory solution yet.
In the z->t case, there’s a perfectly-satisfactory existing solution: the merchant generates a receiving t-address specifically for that interaction (as they would already be doing for any Bitcoin transaction), and then proof-of-payment is simply providing a transaction ID in the block chain. This doesn’t prove that it was a specific address that sent the payment, but that is irrelevant for a merchant (and unnecessarily privacy-leaking); all they need is to be able to definitively state whether or not they received a payment associated with a particular merchant-client interaction (i.e. “did this address receive the amount I expected?”) and for a user to be able to prove that such a payment exists (which is trivially inspectable on the block chain for z->t).
In the z->Sapling case, this workflow can be replicated with diversified addresses (merchant generates a new diversified address for every interaction, and once they reach 2^87 interactions they switch to a new key), or the merchant can require that the memo field contain a specific value (and then just ignore any payment without it). What is lacking is the ability for a user to simply point at a transaction in the chain and say “this was it!” - the merchant can still claim that the transaction was not to the address they specified, or with the required memo field contents. Refuting this requires the user to provide the merchant with the necessary information to decrypt a transaction, and this is built into the Sapling protocol: the user can derive ock (the per-output recovery key) and provide the tuple (transaction id, output index, ock) to the merchant. Anyone with this information can decrypt the specified output and verify that it indeed was sent to a specific Sapling address, with a specific amount and memo field content.
There is an even stronger property that one might want, which is where a user proves that they (or more precisely, anyone with access to their spending keys) were the one that made a specific transaction, rather than simply that the transaction exists (since once the above payment disclosure has been created, anyone can use it to show the existence of said interaction). I posit this is not required for normal merchant interactions: the merchant only cares that they are paid for their goods or services, and the user only cares that the merchant can see that a payment has been made. For situations where it is required, creating this stronger proof would I think require caching at least some of the randomness from the transaction generation process (in order to re-derive one of the re-randomized keys used for signatures in the transaction), which is not currently cached by any implementation.