Some questions/concerns about buckets

So I was reding up on:
https://github.com/zcash/zcash/wiki/Public-Alpha-Guide
and got to know this concept called “buckets”. Lets say I have 1000 ZEC in my zcaddress. I decide to send 1 ZEC to my friend. Several questions:

  1. I forget to save/backup encryptedbucket2 with the change of (999 ZEC). Did I just lost all 999 ZEC?
  2. When you generate new transaction you always have to take whole amount (1000 ZEC) and return the surplus via newly generated encryptedbucket2 to yourself and then save/backup encryptedbucket2?
  3. Am I correct in presuming that encryptedbucket1 or encryptedbucket2 contents are safe to store/send/backup as plain text without additional encryption i.e. nobody can derive some sensitive info from this.
  4. What happens to my 1000 ZEC if my friend does not execute zcrawreceive on encryptedbucket1 I have sent him. What if he decides to execute it after a year?
  5. Does encryptedbucket1 have to be send by email, written down for him or by some other external means i.e. no way to do it internally through zcash?
2 Likes
  1. Yes, you lost it. Yes, that’s a bad UX. No, it’s not going to stay that way :slight_smile:
  2. Yes, JoinSplit transactions operate the same way as transparent transactions in that regard - the remainder goes into a change output (more precisely, JoinSplits always have two outputs, and one or both of them might have nonzero value).
  3. Yes. You need the private key of the zcaddress that the output was sent to in order to decrypt the corresponding encryptedbucket.
  4. The 1 ZEC you sent to your friend is his from the moment that the transaction doing the send is secured in the blockchain (abstracting over confirmation times etc.). The zcrawreceive simply decrypts and validates the encryptedbucket; it doesn’t affect its spendability, which is dictated by the contents of the blockchain. Your 999 ZEC similarly is yours, independently of the 1 ZEC (again, assuming the transaction is accepted and secured).
  5. Currently you have to send it out-of-band, so yes via email, text etc. Eventually the encryptedbuckets will be stored on the blockchain, and the client software will parse the blockchain to find the outputs it has control of (just like for transparent transactions), and you won’t need to do anything.
3 Likes

Thank you for your reply, str4d. Few more questions in relation to possible future online javascript client:

  1. Will it be possible to delegate zcrawpour (AKA JoinSplit) operation to some external service. Seems a little unlikely, because it is computationally expensive. Also as I understand for this operation you need rawtx and zcaddress as arguments, so from this point it would be possible for external online service to do (since you don’t have to send your private key)
  2. If encryptedbuckets will be stored on blockchain in the future, will it be possible for online service to find your buckets for you without revealing your private key to the online service? As I understand you would need a private key for that, public key not sufficient.

We’ve discussed both of these ideas for outsourcing proving (1), and to outsource receiving (2).

For outsourcing receiving, see this ticket: Detection Keys · Issue #288 · zcash/zcash · GitHub

For outsourcing proving, we’ve had some discussions and have a probably viable protocol sketched out. We haven’t documented that well (and it won’t be available in our 1.0 launch). I just created a ticket to track that here: Payment Offloading protocol for light wallets. · Issue #1113 · zcash/zcash · GitHub