Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] ZIP 308: Sprout to Sapling Migration #197
Some feedback from a person who I don't yet have explicit permission to identify:
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.
Yes, this was intentional. I think a random distribution is unnecessarily complicated, although @tromer did also suggest that.
Several people suggested being able to configure the destination address, and I think we will include this.
Yes, that's a good point.
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:
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.