idea(s): 'receiver does shielding' to help light wallets?

[gojomo]

I am likely far behind the team's latest thinking on these sorts of things, but was wondering if there aren't ways that a light wallet, perhaps with no internal ability to generate sends-to-z-addresses, can lean specifically on (software/services of) the intended receiver for help. After all, the received may be a more sophisticated user with better systems, and is also the one entity to which the existence of a payment is necessarily revealed.

(These thoughts overlap with delegated-proving #1113 et al or out-of-band sending #2432 et al.)

These 1st 2 scenarios are (I think) compatible with existing software/Sprout-realm:

Scenario 1: Light wallet only can do t-sends, but user has learned of a z-address they'd like to send to. Even if hypothetically the wallet could do a z-send, user might want to send exact amount of ZEC payment into 'shielded' realm, with change back to t-address.

In this case, might an approach that's roughly privacy-equivalent, from both participants' perspectives, be to use the z-address 'transmission key' to create a t-address that's a "stealth address", and send the ZEC to that? The recipient might then (at the cost of another transaction) sweep it into shielded-space at their own pace/discretion.

Scenario 2: The light-wallet is capable of using a remote delegating proving service, but may not have previously configured one that they rely upon.

But now, the desired z-payee advertises their own delegated-proving-service entry point, to make it easier for light wallets to pay them. (Perhaps this is sent alongside the z-address, perhaps even signed with the transmission key; or maybe there's a directory service that, if you know a z-address, can retrieve a signed zaddr-provingservice binding.)

If the sender is only using t-funds, and receiving change to a t-address, using a sender-nominated prover seems to provide no privacy loss compared to using their own prover. (In both cases, recipient can deduce the payment transaction and see the t-inputs and t-output(s).) Only if the sender was going to use a shielded change address is there some extra disclosure to the recipient. (But, IIUC the current delegating-process, using shielded inputs for now means trusting the prover with spending keys, so the 1st gen of delegating wallets may keeping t-funds.)

This next scenario is speculative, and perhaps already near-enablement by Sapling++ ideas like #2277 et al or #2432 et al.

Scenario 3: The sender has z-funds and spending keys, and wants to send the recipient some derivative of those keys that only allows the recipient to shielded-pay themself an exact amount, with the remainder going back to the sender's desired change address(es). Ideally, also, this is a unidirectional send - the sender only needs to observe the result on the network/blockchain. Could there be a new proof circuit specifically to enable such constrained spending keys – verifying the value known by the recipient-prover is "the original key modified by the conditions, which are also evident in the JoinSplits"?

[daira]

Stealth addresses alone are fundamentally less secure than JoinSplit transfers. Consider an adversary who can see which user submits which transaction. To such an adversary, the transfer to the stealth address is linked to the payer, and the transfer out of the stealth address (even if that is a JoinSplit transfer) is linked to the payee. So the payer and payee are linked, and transaction privacy is not achieved. Contrast with using two JoinSplit transfers, where (regardless of whether an adversary can see who submits each transaction) an input to the second transfer could be any output from any previous transfer up to the anchor.

[gojomo]

I see, I was thinking more of blockchain observers than omniscient network observers, though of course the latter adversary is relevant as well. If in fact the recipient (with their preference for z-addresses, more computing power, etc) may be able to obscure the source of their submissions, this pattern might still offer an incremental benefit, depending on the recipient's own concerns.

(Speculative: might a scheme which can mint/shield a t-txout without transparently revealing it be possible, via some sort of shared-state between t- and z-realms and some sort of de facto nullifier for a t-txout, that prevents a later normal t-spend of the same amount if attempted?)

[daira]

While stealth addresses could provide some incremental privacy benefit to the use of transparent addresses, our focus is on improving the performance and functionality of JoinSplits, since those provide strictly stronger privacy properties without compromises.

There are lots of other possible schemes that improve on t-addresses, but remember that one of the primary reasons we have t-addresses is compatibility with code written for Bitcoin. If we adopt one of those schemes, the t-addresses involved would no longer be compatible with Bitcoin.

[gojomo]

Definitely, full shielded JoinSplit efficiency is the ideal.

But it still seems months until any broadly-available light-wallet might offer transparent-to-shielded transactions (via delegated proving), and a year or years before a light-wallet can do its own shielded transactions (via other optimizations & more powerful mobile devices). Baby steps that nudge light-wallet users from a transparent-only mode may be worthwhile – provided such steps are not too confusing in their permutations, or too distracting to the team, etc. (Those are are big caveats, of course.)

So without yet advocating any approach, I'm just trying to dump some ideas into the record under the theme of "receiver helps shield" – to know if these techniques already have names/decisions associated with them, or if they may trigger other better ideas, etc.

If Bitcoin's stealth addresses were applicable, I'd see that as leveraging, rather than discarding, the choice to have t-addresses for Bitcoin code/experience re-use. I now realize that because z-address transmission keys use a different ECC curve, they couldn't be used to directly deduce a t-address (stealth or otherwise). So perhaps consider a variant on 'scenario 1' - the t-only-user sends to a new t-address they've created, and includes the private key for that address in the OP_RETURN, encrypted to the z-address transmission-key. It is then something the z-address holder may sweep to another t- or z-address at their discretion – but the sender can also repossess if unclaimed. (Perhaps a convention for this t-halfway-to-z could be called a 'ztealth send'?)

For a transaction-origin-omniscient adversary, the two sides are still linked. But it's now up to the discretion of the z-address holder if they participate, and the ZEC aren't necessarily in limbo forever if the z-address-holder isn't paying attention (or otherwise reluctant to get entangled with t-side transactions). And users of t-only-light-wallets can then sorta-send to z-addresses, rather than just being told: "wait N years until software and your phone can support that". Potentially, z-address recipients could advertise their willingness to accept ZEC by this convention by appending a "+T" to their advertised z-address.

Regarding the other 'speculative' parenthetical I made: has such a "secret mint" been previously named/discussion? I mean, roughly, a spend-to-a-t-address that looks, the the outside world, like any other t-to-t-spend. But, it's really a burn making those values unspendable in the t-realm. (For example, to a legacy-invalid script-hash.) The information in the transaction, however, is enough to feed a zk-proof that the value is now unspendable in the t-realm, and should instead be spendable in the shielded-realm.

I can see how this would run counter to some desired monetary-base-audit goals ZCash has usually espoused. (Only when both the t-realm and z-realm are eventually sunsetted with their value evacuated through t-balances to new realms would the level of active money be verifiable.)

But, it would seem to have some nice qualities for expanding the potential anonymity set - any amount that looks like an idle 'hodl' in t-realm might in fact be circulating in z-realm. And it would enable an even better form of "receiver helps shield", a bit like the 'ztealth send' above. (The light-wallet t-only-user sends to the right t-address, but uses another secure channel to give the intended recipient the info needed for the burn-to-shielded zk-proof. Maybe that info is enough to move the t-balance to any shielded-address; maybe the info is only good enough to complete-the-mint to an exact originator-specified address – their own address, or a single intended other recipient. The omniscient adversary who sees the origin of all emitted transactions only links the first t-transfer to the sender; the recipient's full activity is zk-protected.)

[daira]

I think you're overestimating the time until light clients will be able to support doing shielded transactions. Sapling should enable that. Implementing the other features suggested would take as long as delegated proving (for the ones that don't require a circuit change) or Sapling (for the ones that do), but it would result in a worse UI, because users would have to choose between even more ways of doing things with subtly different privacy properties.

[nathan-at-least]

We should set a timeline to review the assumption that light client roll out will be fast enough. There may be a chicken-and-egg problem where users won't want to use a shielded address in a light client, because legacy services can't interact directly with shielded addresses, so adoption doesn't bootstrap.

OTOH, if I understand the motivation of this ticket, in such a world, light client users could begin to use shielded addresses while still interacting a bit more directly with those services.

[ravibhojwani]

could I code : can we use a browser ext ? mozilla seems keen , chrome themes , looking at Nimiq it’s a beautiful template