1-click Sapling turnstile migration proposal for zcash-qt-wallet


#1

I’ve been bouncing around a “1-click” sapling turnstile migration for zcash-qt-wallet, and I’d love to get some feedback from experts here.

This is what it’ll look like:

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:
image

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?

#2

I like it! just make sure the migration progress dialog isn’t a blocking modal one! :slight_smile:


#3

The ‘restart info’ written to disk should be purged after the last transaction confirms ?


#4

Wow, this looks really good! Nice work :sunglasses:

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)


#5

This looks great!

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?

Very cool!


#6

Another thought… add the last few decimal places to your dev fee, avoids chaff on the turnstiled transactions.


#7

Sorry, I didn’t get this. Is the suggestion that I make one tx for the dev fee instead of adding it to every tx?


#8

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…


#9

Oh, I get it now. I hadn’t thought of the chaff. That’s a good point about that being unique.


#10

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.


#11

Right. This makes sense. The dev fee is shielded, so accumulating it in a sprout address will probably be a good idea for privacy


#12

Quick update: The prototype is now working on Tesetnet.