Comment by ccamrobertson | Hacker News Reader

Comment by ccamrobertson | Hacker News Reader

Parent Full thread

> So, would this require the full balance of the note effectively to be “spent” and sent to a new multisig UTXO? Wouldn’t you also need access to the decryption key from your server in order sign with both signatures? And who pays the TX fee? Is all the key rotation work done on your servers?

> Also, in order to rotate the key, a user would surely need a separate networked device able to interact with the note. I imagine one would also need to install your specific app as well.

Effectively yes -- working on preparing the security overview here, but we need to be in the loop on the re-key procedure. We will open source that app so that in theory you do not need to rely on that, however, you will need to communicate with our server in this case.

> Would there be an open protocol by which a person could perform key rotation if you go out of business and shut down your servers? If your servers go down, I can’t think of how there would be any way for a user to rotate the user key.

This is a great idea, however, it would require us to select another entity to hold the encryption keys (probably not unreasonable). Currently if there is no way to rotate the keys in this case.

> How are you paying to keep the lights on so that these notes keep working though expiration? You all need a revenue source, but there isn’t anything on your website that indicates how you would make money.

One idea we have is charging a small amount to re-key the notes in addition to network fees. We have not implemented this. We do believe, however, that this would be reasonable and fund continued operation of the servers. I should also note that our hope is to amortize some of the server costs in the notes since their operation isn't particularly intensive.

> 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.

> 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).

Reply on news.ycombinator.com