Users will be able to pick from the following migration strategies:
“Good - 3 tx over 3 days”
“Excellent - 5 tx over 5 days”
“Paranoid - 10 tx over 7 days”
When the user starts the migration, zcash-wallet-ui will:
Break up each z-Addr’s balance into ‘x’ parts, picking round numbers as much as possible.
Choose ‘y’ random block heights in the given migration window for when to migrate parts of the balance.
Write to local disk the picked block heights and balance parts,so we can continue across restarts.
Generate new intermediate t-Addresses, and make the user backup wallet.dat
When a chosen block height arrives, move the ‘x’ amount from the z-Addr to a t-address, and then one block later, move it to the target sapling address.
I’m thinking a progress box like this will keep track of the migration:
Feedback?
I think it’ll be OK to pick round numbers (hopefully powers of 10) to break up the balance into.
while the sprout->t-addr will happen randomly, the t-addr->sapling will happen the very next block. This might make it obvious that this is a part of the migration, but I think that will be clear anyway, even if we wait a random number of blocks for it.
Any other privacy / safety concerns I should watch out for?
I’m planning on migrating from my Z-address to a few separate T-addresses at random days/times/amounts then re-consolidate them to my new Sapling address.
Also, as far as security goes I wouldn’t deviate from the default 0.0001 ZEC tx fee so that the transactions don’t stand out (tx fees are transparent)
I’d recommend having the form UI default to excellent - users will check for other options if 5 days is too long.
I second the clearing of local disk space and the use of the default miner fee. I’m assuming you want the dev fee so possibly make that a separate transaction or part of a multi outlet if possible?
The chaff (ie: least significant decimal places) of the last transaction would be the only remaining part thats slightly unique as all the other transactions are being rounded to make them similar.
As this would be a ridiculously small fraction of a cent, maybe it should be added to your dev fee. A tiny extra benefit to you but makes everything slightly more anonymous.
It was just a random thought, probably not a very good one…
Adding chaff to the dev fee would definitely help, if the dev fee is private (paid to a Sprout address, ideally with the memo set to “Wallet dev fee” or something so people can remember later). That way, when you eventually transfer your own funds from Sprout to Sapling, the unique value revealed would be the sum of the received chaff, which would (if left to accumulate before being transferred) be harder to correlate to any t->Sprout transfers. (There may be an argument that it helps with your own migration privacy from Sprout to Sapling, via some kind of blinding of your own chaff with the received chaff, but it would also make it slightly-to-somewhat more likely that chaff-containing turnstiles are yours, so this would need much more analysis). If the dev fee isn’t shielded, then the unique value is still directly leaked in one of the transactions.
