3 ms·

> Effectively yes -- working on preparing the security overview here, but we need to be in the loop on the re-key procedure. I’d love to see how you accomplish

> Effectively yes -- working on preparing the security overview here, but we need to be in the loop on the re-key procedure. I’d love to see how you accomplish this. It seems tricky to be able to sign the replacement transaction without revealing the encrypted private key either to yourselves, or to the mobile app. I guess that you could have the app send the encrypted key up to your servers, where it could be decrypted locally for use and then discarded. But if you are going to do that every time the note changes hands, why not just hold onto the private key? Why mess with encryption keys? You might just need to bite the bullet and maintain custody of the secondary key server side. Is there a particular jurisdiction you are worried about that is motivating you not to want to maintain custody of the secondary key? In the US at least my recollection is that you are a cryptocurrency custodian only if you control all the elements necessary to transfer the bitcoin—meaning you wouldn’t be a custodian because you wouldn’t have access to the user key. I may be wrong about this, though.

ccamrobertson 4y ago
> I’d love to see how you accomplish this. It seems tricky to be able to sign the replacement transaction without revealing the encrypted private key either to yourselves, or to the mobile app. I guess that you could have the app send the encrypted key up to your servers, where it could be decrypted locally for use and then discarded. But if you are going to do that every time the note changes hands, why not just hold onto the private key? Why mess with encryption keys? I had to dig back into the architecture on this part since most of this was written last year waiting on notes. In this case you are correct -- we need to decrypt the key in RAM, use it to generate the new tx along with the new user pub key and send that back for the user to broadcast. Again, the distinction here is that we don't store it which, to your point may or may not matter from a regulatory perspective. I would agree that it would be hand waving and, indeed, false if we claimed that we never could store it at this point (or prior, at the time of creation).

ccamrobertson 4y ago

> I’d love to see how you accomplish this. It seems tricky to be able to sign the replacement transaction without revealing the encrypted private key either to yourselves, or to the mobile app. I guess that you could have the app send the encrypted key up to your servers, where it could be decrypted locally for use and then discarded. But if you are going to do that every time the note changes hands, why not just hold onto the private key? Why mess with encryption keys? I had to dig back into the architecture on this part since most of this was written last year waiting on notes. In this case you are correct -- we need to decrypt the key in RAM, use it to generate the new tx along with the new user pub key and send that back for the user to broadcast. Again, the distinction here is that we don't store it which, to your point may or may not matter from a regulatory perspective. I would agree that it would be hand waving and, indeed, false if we claimed that we never could store it at this point (or prior, at the time of creation).