The sooner this is possible, the better.
I’m all for privacy by default, and even nuking z->t and t->t, but completely removing t->z feels like a little much imo. It could burn a lot of people who weren’t aware that such a change was happening.
How would you feel about auto-converting t->z before sending? Edit, might not be possible.
I don’t believe that is technically possible? I’m not sure how you would calculate a z public key from a t public key such that z private key is also from the t private. I don’t believe the rings have a homomorphism, and I would be super shocked if they did. Also, it would also require a fuckton of compute and space on the blockchain, something I believe miners and the full nodes don’t want to deal with.
what would be the benefit in removing the t-adresses?
Reducing technical debt and attack surface. Once t-addresses are removed, any code that was required to use them can be deleted. Once there is a clear chain height after which t-addresses are unequivocally not used, we can checkpoint the chain state (checking the block hash at that height, and probably intermediate heights as well) and then remove support for even verifying their usage (which would speed up initial sync). Anyone wanting to verify the old chain in full would still be able to start a reindex using the previous version of the software (which would definitely be able to verify at least up to the last height that t-addresses were supported).
We will in fact be able to deploy the above strategy in the short term for Sprout z-addresses. In the Sapling upgrade, we are migrating Sprout z-addresses to the same proving system and curve as Sapling will use; this will increase Sprout proving speed by 2x, reduce Sprout memory usage by a third, and mean that all Sprout JoinSplits going forward rely on the new, much more secure MPC. This also means that once Sapling activates, any Zcash software version after that point (i.e. 2.0.2 and above) will not need the ability to create old-style Sprout proofs, so we can remove all that code. Similarly, once we are confident in the stability of the main chain, we can ensure that all old-style Sprout proofs are valid (using both the standard verifier and third-party implementations), checkpoint the chain with a block hash, and then remove the code to verify them. In the medium-to-long term, once we reach the point where we start disabling usage of Sprout addresses themselves (in favour of Sapling), we could follow a similar process to remove them entirely.
How would you handle the coinbase transactions? Have them pay to notes as well? Would mining distribution be then hidden as well (aside from pools self-reporting)?
The original Zerocash paper had the concept of “Minting” to handle this. We didn’t implement it because a) we could use the vpub_old field to move funds into the shielded Sprout pool, and b) it reduced the extent of changes we needed to make to the inherited Bitcoin Core codebase before launch. Now with Sapling, we can do the equivalent of minting quite cheaply: create an Output proof (which takes on the order of 0.2s to create, and could be pre-computed by mining pools), and then de-commit the value commitment inside the coinbase transaction, so that anyone can verify that the note being created is of the correct value.
This could be implemented in a way that requires revealing the target address, in addition to the amount. We’d need to be able to prove that the revealed address is indeed the one that the notes are being sent to, without making the spends of those notes linkable. I don’t know off-hand whether that is possible without creating a new coinbase-specific circuit; if it did require a new circuit, then I would expect it to be about the same performance as creating an Output proof, as almost all the circuit logic would be identical.