Sapling to Orchard migration pathways for wallets

3rd Party Applications
1

As we get close to the mid-January activation of Halo 2 and subsequently using Unified Addresses with the Orchard Pool. It would be a good idea for a community discussion around user experience decisions made by wallets developers.

Today, @NighthawkApps defaults to Sapling Shielded Address for sending and receiving ZEC.
And supports T-address for receiving Transparent ZEC with the only option to Shield all funds.

For the upcoming upgrade, here is a pathway for Nighthawk to work with Unified Addresses:

  1. Replace Sapling Shielded Address with Orchard Shielded Address(UA) on the “Receive” screen.
  2. Allow Send/Receive ZEC and view transactions history from Orchard Shielded Address(UA) only.
  3. Limit funds in Sapling Shielded Address to be manually sent to Orchard Shielded Address(UA) only.
  4. Support Receiving funds on T-address and enable Manual/Auto shielding of transparent ZEC received on both UA & T-address.

NOTES:

  1. Exchanges can send transparent ZEC to UA.
  2. All Exchanges/Service Providers may not immediately upgrade to support UAs, so we need to continue supporting T-address for wallet users.
  3. Migrating ZEC from Sapling Shielded Pool to Orchard Shielded Pool will publicly expose user funds on the block chain. We might want to warn users about this.

The updated workflows will need to be worked out in the designs for Nighthawk which are in-progress for the current Milestone 3. We will be conducting user feedback and reviews with a small cohort of crypto wallet users soon.

Please provide any comments/suggestions/inputs on anything we might have missed.

Thank you.

9 Likes
2

Quick note (I’m short on time right now):

The way that we want HD-derived Unified Addresses to be produced (currently outlined here, soon to be documented in ZIP 316), the Sapling and transparent components of the UA for account 0 will be the Sapling shielded address that mobile wallets were already using, and (assuming use of BIP 44) the transparent address that was already being used for auto-shielding. This has the benefit that funds sent to the prior Sapling and transparent addresses will show up in the wallet’s UA balance, without the wallet needing to have multiple shielded viewing keys it needs to scan.

7 Likes
3

This is technically accurate, but some users or developers might misunderstand “expose user funds on the block chain” as exposing their identity, or exposing linkage to their other past or future transactions. That would be a misunderstanding.

In fact, since the user’s funds start at rest in a shielded pool and end at rest in a shielded pool, they are protected — at the blockchain layer — from being linked to anything else such as their other past or future transactions.

The reason that the amount of the migrating funds gets exposed publicly on the blockchain is not a bug — it’s a feature. It comes from the requirement that everyone in world can see a public accounting of how many ZEC have moved into and out of which pools (the transparent pool, Sprout, Sapling, and soon Orchard), in order to provide public assurance that the monetary base is sound and to enforce the soundness of the monetary base even if there was counterfeiting in an older pool. (Which, by the way, is something that has never happened on the Zcash blockchain, unlike in Bitcoin, Stellar, Bytecoin, Bitcoin Private, Zcoin/Firo, and other blockchains…) This is a transparency requirement, which we always have to trade off against privacy requirements.

There are (at least) two possible ways to migrate funds from the Sapling pool to the Orchard pool. If you do it the simple way — a single transaction that sends all of your Sapling funds to your new Orchard zaddress — then it exposes the exact amount of funds that are migrating, and the exact timing, but it doesn’t expose — on the blockchain — any linkage to any of your past or future transactions.

If you do it the more sophisticated way — a multi-stage “migration” process such as ECC implemented for the Sprout to Sapling transition — then this exposes even less on the blockchain. It leaves someone scrutinizing the blockchain with uncertainty about how many people moved funds, how much of the migrating funds belonged to which users, and when exactly they did it.

The fly in the ointment of all this is, as always, information leakage at the network layer. Everything I wrote above is true if the adversary looks only at the blockchain layer, but if they also look at the p2p network layer and/or the TCP/IP layer, they can see a lot more about what the users are doing, such as their IP address.

Hopefully network-layer privacy technologies such as Tor Arti and Nym will fix the leakage problem at that layer!

13 Likes
4

Indeed, it doesn’t explicitly create such linkage. But even exposing just the amount could indirectly create linkage to identity and actions, due to auxiliary information or common habits.

So it would be good to have migration tooling that mitigates leakage of even the amount, as was the case for the Sprout-to-Sapling migration function in zcashd. And figure out how to integrate it into light-wallet/mobile apps.

2 Likes
5

Having a turnstile for NU5 seems like a very useful thing to wash the taint of the trusted setup

1 Like
6

Thank you for helpful link.

7

If using zcashd 5.0.0, would this be using the z_sendmany command? After using the zcashd-wallet-tool, I have my first UA :sunglasses: I hope a more detailed guide is put together, very exciting.

notes: https://zcash.github.io/

1 Like
8

Yes, 20 characters