I wanted to put back on the table an idea proposed by @tromer (in this comment: Technical AMA w/ Zcash core devs Feb 24, 2017 noon PST - #48 by tromer) during the February Technical AMA. The idea is to exclude t-addresses from any “freshness requirement”. I love this idea, because I think it appropriately balances the tension between auditability and preserving the cold-storage / durability features of Bitcoin
As a buyer of Zcash, I agree that being able to audit the total number of Zcash in existence is a very important feature to pursue. In the context of Bitcoin, it is comforting to be able to look at the blockchain and see that the total number of Bitcoins is as it should be. In making the transition to buying Zcash, it is jarring to have to “trust the crypto” instead.
I don’t feel comfortable with money that becomes invalid absent some action taken by the holder of the money. To me, that seems like a problem, not a feature. I don’t think we should abandon the cold-storage, completely-disconnected-from-the-network-for-an-indefinite-amount-of-time capabilities of Bitcoin.
As for the tighter-upper-bound that @zooko has mentioned, I don’t think this is needed, especially if it sacrifices cold storage.
As for eliminating t-addresses completely, I understand that the use of z-addresses is essential to fungibility, but I favor keeping t-addresses precisely because it would enable the @tromer idea of excluding t-addresses from the freshness requirement. Perhaps make z-addresses the default in wallet implementations (to encourage adoption of z-addresses), but keep t-addresses for cold storage purposes.