Public transactions using the shielded protocol

[jackgavigan]

Currently, we have transparent transactions (which are based on Bitcoin-style UTXOs) and shielded transactions (which use zk-SNARKs and notes). We're also working on Selective Disclosure (#406).

We may want to start thinking about making it possible to make shielded transactions "public" by, for example, giving the Sender the option of attaching the disclosure key/tuple cleartext to the shielded transaction.

I'm dubbing these "public transactions" (for the time being, at least) to distinguish them from transparent transactions. An alternative descriptor might be "pre-disclosed transactions".

[daira]

What's the use case for this that can't be satisfied by transparent transactions?

[jackgavigan]

Short term: Creating the equivalent of transparent transactions for ~UIT~ ~UDA~ ZSAs. Long term: Creating the equivalent of transparent transactions for ZEC after we deprecate Bitcoin-style transparent transactions

[str4d]

Another way to frame this is to allow transactions to toggle whether certain data included in the transaction is public or encrypted (think "Selective Disclosure" for transaction fragments). I think this would fit well with a FlexTrans-style transaction, and would also allow for use-cases where we only want parts of the output notes to be public (e.g. just their value). We may also want the ability to add other data fragments, e.g. the recipient address (which in the current protocol is not even stored in the ciphertext), though we wouldn't want this to be free-for-all - the fragments should be validated in some way.

[nathan-at-least]

In a discussion with @jackgavigan just now he helped me realize that we should separate the general property of "transparency" from the specific implementation of "t-addrs". A motivation for this ticket is to provide transparency atop Sapling-like transactions, so that we can deprecate t-addrs without losing transparency. Does that clarify the motivation for you @daira?

One technical benefit is that if we can reduce the verifier node (e.g. miner) and wallet protocol to a single transaction semantics (Sapling-like) that simplification can improve the overall architecture. Specifically, we could drop UTXO tracking, Script evaluation, opcode/performance limit tracking. Performance becomes easier to reason about. (Of course there are other properties of t-addrs aside from transparency we need to consider for deprecating them, but that's not the focus on this ticket.)

We were discussing how if we could focus on supporting only Sapling-like for scalability, this could simplify that problem space a lot. So, it would be best if we could do that while still having a means of achieving transparency for users who need it.

[daira]

I asked what the use case was. The current reasons I know of to use t-addresses are: they are faster, they support multisig and HTLC, and they have wider ecosystem support. All of those can and should be supported for non-transparent transactions. What are use cases for transparency, specifically, that can't be addressed by viewing keys and payment disclosures?

[jackgavigan]

• Future turnstiles
• A donor may want to make a public donation to a charity
• Aid organisations may wish to be transparent about how their funds are being spent
• An exchange may wish to provide proof of solvency

[nighthawk24]

Those are valid use cases @jackgavigan

They can be covered with Viewing Keys support. e.g. Donor sends funds z2z to a new Shielded Address "A" with a Memo of the donation and then sends the funds from "A" to the Charity's donation address "B" and makes public the Viewing Key of "A".

Same for Orgs/Exchanges who can move funds z2z and make the Viewing Keys public (reminds me of the famous MtGox 424242.42424242 BTC transaction https://www.blockchain.com/btc/tx/3a1b9e330d32fef1ee42f8e86420d2be978bbe0dc5862f17da9027cf9e11f8c4)

[str4d]

e.g. Donor sends funds z2z to a new Shielded Address "A" with a Memo of the donation and then sends the funds from "A" to the Charity's donation address "B" and makes public the Viewing Key of "A".

This issue is about how the donor might go about making that viewing key public, in a standard / well-understood way. Obviously they could post it on Twitter or their own website, but we know how fragile URLs are. By comparision, we currently require shielded coinbase outputs to be "transparent" because we effectively force their "viewing key" (specifically the OVK) to be [0; 32], but few block explorers (probably none) understand this and expose those outputs.

[nuttycom]

@str4d that's a perfectly valid solution though, right? It's not currently supported in wallets, but there are no changes needed to the protocol for a wallet to to add a "make this transaction public" checkbox which then just uses the all-zeros OVK.

[nuttycom]

Also, I'll note that turnstiles don't depend upon transparent (Bitcoin script) functionality at all - turnstiled amounts are a property of the shielded parts of the transaction.

[daira]

It's not currently supported in wallets, but there are no changes needed to the protocol for a wallet to to add a "make this transaction public" checkbox which then just uses the all-zeros OVK.

If we want to do it that way, it would need a change to the Usage of Outgoing Viewing Keys section of ZIP 316.