This is an excellent proposal, and I think overall has everything I was hoping it will have. I had some comments on the RPC interface, but otherwise, this is excellent!

Some feedback from a person who I don't yet have explicit permission to identify:

My question and concern are following:

• Should we somehow notify the user that block mod 500 is coming so he leaves the wallet intentionally open or should this be strictly random? I guess average user will not know how it works and not saying to him that block mod 500 is about to happen might increase the anonymity of a transfer because even user will not know that a transfer is about to happen.

I don't think there's a need to notify the user. We do need to document that zcashd should be left running during a migration. [Edit: noted here.]

• Every 500 blocks means basically every 21 hours so it is fine as I was scared that it would be repeating every 24 hours so it may hit to someones sleeping pattern. Probably just a wierd idea but What if this will be determined based on previous blockhash making it random? The same may go for the amount distribution functions.

Yes, this was intentional. I think a random distribution is unnecessarily complicated, although @tromer did also suggest that.

• Then to what address will be the funds sent to? Can user select his sapling address the funds will be migrated to or it will be always a new one (which is I guess better from anonymity standpoint)? Will those transactions be somehow marked so we know that this transaction comes from the migration method so we can notify the user about it - I guess that the “confirmed_migration_transactions”: nnn, in the ‘getmigrationstatus’ will be returning an object of migration transactions currently happening/done in the current batch. But what about the past transactions (assuming user has a lot of ZEC)? This information should be stored just locally.

Several people suggested being able to configure the destination address, and I think we will include this.

• An advantage of knowing the destination address prior running migration may be in the case if something goes wrong and wallet.dat gets corrupted. Then there is a chance that user has backed up the private key of the address prior it got corrupted.

Yes, that's a good point.

@str4d @tromer @bitcartel @adityapk00 Can you review the responses provided to your comments and let us know if you're okay with approving this PR?

Looks good to me!

It's quite likely I'm overlooking something obvious, but it's not at all clear to me why there's the batching-of-transactions at a common (500-block) interval. The transactions will still look like "migration" transactions (filled with a certain value of sproutZEC, paying saplingZEC). And a hypothetical network-omniscient adversary will still see the IPs from which the batches of 1-5 transactions emerge. And I can't think of heuristics used by lesser adversaries that get confused by a bunch of transactions appearing at arbitrary intervals. What is the specific de-anonymization fear that this synchronization addresses?

The ZIP currently does not mention specifying a from address (mentioned in earlier comment),also:

If this option is not present then the migration destination address is
the address for Sapling account 0, with the default diversifier [#zip-0032]_

Thus it appears the ZIP has been written from the perspective of a node being used by just a single user (making it safe to migrate funds to the default diversifier address).

However, a node operator might have multiple users in the same wallet, and may have the requirement of migrating users on an ad-hoc basis i.e. users who opt-in.

To avoid service disruption, a node operator might want to reduce the time it takes to migrate (within reason) so perhaps there could be range of confirmaton / block magic values.

Also, in a multi-user environment, the node operator would probably want support for multiple (concurrent) migrations.

Some of this might be out of scope for the ZIP but it would be worth considering how the ZIP would be interpreted by node operators in a multi user environment.

@bitcartel I'll add an explicit comment to the ZIP saying that that the RPC has been designed assuming a single-user wallet. (The migration algorithm itself isn't dependent on that.)

Edit: added "It is not required to support the case of single wallet being used by multiple
users whose funds should be kept distinct."

@gojomo wrote:

It's quite likely I'm overlooking something obvious, but it's not at all clear to me why there's the batching-of-transactions at a common (500-block) interval. The transactions will still look like "migration" transactions (filled with a certain value of sproutZEC, paying saplingZEC). And a hypothetical network-omniscient adversary will still see the IPs from which the batches of 1-5 transactions emerge. And I can't think of heuristics used by lesser adversaries that get confused by a bunch of transactions appearing at arbitrary intervals. What is the specific de-anonymization fear that this synchronization addresses?

The intent is to minimize any information leakage from the times at which transactions are submitted (for example due to when nodes are online).

Mentioned in meeting:

• batching of transactions at a common interval e.g. 500, is a predictable event and could result in an attack such as flooding the network at the event time so that migration transactions do not get mined or have an insufficient fee and therefore expire.
• a randomized block interval within a 500 range should result in a uniform distribution of migration transactions across all migration tool users, eliminating the predictable event.

We discussed the issue @bitcartel raised during zcashd sprint planning/review.

It's a trade-off between improved privacy by ensuring that all migration transactions happen at the same time versus eliminating the risk that someone might try to exploit that to flood the network. I guesstimate the risk of a successful attack as Low, as it would take a fair amount of effort to fill up 20 blocks in a row (which is what would be required, given that the migration transactions should have the default expiry time of 20 blocks).

If someone does mount a successful attack, the impact is limited (migration of users' funds will be delayed but no risk of loss of funds, etc.), and we can mitigate it by changing the migration tool's behaviour in the next suitable release.

So, we're going to progress with the common 500-block interval.

Upto @daira and @eirik if they want to add some of the observations and concerns raised on this ticket on the ZIP before moving out of draft.

Can we add active measures for cycling connections for anti-surveillance and anti-eclipse purposes? I have been sketching up some ideas to disrupt metadata collection around turnstile transactions (both targeted and dragnet). Happy to discuss & get something coded up if this is not already implemented?

I’ve been thinking through the outline of “A glimpse through the turnstile: a statistical post-mortem of the Zcash migration” as a mental exercise to think of heuristics that we can take preemptive action to disrupt.

e.g. ToC
1 - Introduction
2 - Methods
2.1 - On-chain data collection
2.2 - Metadata collection
2.3 - OSINT collection
3 - Theory
4 - Results
4.1 - Estimating number of sprout pool users
4.2 - Shielded rich list & the Gini coefficient
… etc

TL;DR: To spoil the analyses in 4.1 and 4.2 I would lean towards reducing the maximum value per turnstile transaction (currently almost 1000 ZEC).

Regarding 4.1: A big question is “how many individuals had funds in the sprout shielded pool?” The number of turnstile transactions provides an upper bound on that headcount (assuming one person will have multiple transactions, and transactions represent at most one person). Then Number_of_heads <= Number_of_turnstile_txns … Lowering the transaction cap to increase number of transactions per person widens the inequality and makes the upper bound less useful/representative.

Regarding 4.2: Maybe this is a “bug or feature?” situation, but I personally would like to minimize the ability to empirically fit any economic metric (or its bounds)... There is some “real” Gini coefficient in the sprout shielded pool, and the fact that outputs are broken up means that the observed “fractured” Gini coefficient will be a lower bound on the real value. I have a hunch that a turnstile observer might be able to combine known turnstile breakdown rules with the fractured Gini coefficient to probabilistically reconstruct the real Gini coefficient (e.g. Monte Carlo). The more fractured the observed distribution is, harder it is to model the original distribution.

Lowering the maximum turnstile value will add a lot of noise to these heuristics, (also against metadata collection if combined with the practice of connecting to a disjoint set of peers for each turnstile transaction broadcast). Currently the fee is fixed per transaction (to improve fungibility/indistinguishability), so users may object to increasing number of necessary transactions. This could be addressed by fixing the turnstile fee in ZEC/kB, which brings the same fungibility/indistinguishability benefits without incentivizing fewer transactions.

I dunno, just some thoughts. Sorry if this is the wrong place to brain-dump, I will relocate if there is a more appropriate channel. :- )

(edit: also a quick note that enforcing this at the consensus protocol level would be a good way to prevent anybody creating "Turbo Turnstile" wallets that exceed the fixed fee or max amount to jump ahead of the crowd, fingerprinting their own software in the process)

TL;DR: To spoil the analyses in 4.1 and 4.2 I would lean towards reducing the maximum value per turnstile transaction (currently almost 1000 ZEC).

@daira, how would the time-to-migrate table be affected if we reduced the exponent range from 6 - 9 to 6 - 8? This would remove the ability to select values in the range 100 - 990 ZEC (though only around 22.5% of transactions, for a balance well exceeding 990 ZEC, would be expected to fall in this range with the current ZIP), as well as reduce the probability of selecting values in the range 10 - 99 ZEC. If this resulted in (say) a 5x performance hit, that would push out the median for migrating 10,000 ZEC to just under three months.

Other than the point above, ACK on the ZIP contents.

I'm inclined to reduce the exponent range to {6..8} as suggested. I will rerun the simulation of how long the migration takes, taking into account that change (and also outputting the number of transactions as suggested). Any dissent for changing this?

Great, lowering to {6..8} should filter out the loudest information leaks. 👍

I updated the turnstile denomination notebook with the new exponent range.

I'm still trying to understand benefits of this structure in the probability distribution function. We could achieve some privacy by using a continuous PDF. Alternately, we could use non-overlapping discrete denominations, e.g. 0.001 ZEC, 0.005 ZEC, etc, which would offer privacy from a different angle. The current algorithm effectively produces a compromise between the two options. It's not clear to me whether they interfere constructively or destructively, with respect to privacy.