Right now the exchange has two required parts, and one optional, external part. The two required parts are:
The required parts
The OpenCX Client, currently implemented in benchclient and utilized as a shell client in ocx, sends RPC commands to the Opencx Server. The client has its own keys, and signs the commands it sends for authentication. All registration is done with this key, and this is how the server keeps track of deposit addresses (which are used to link users with deposit transactions). ocx stores its private key in ~/.ocx/
The OpenCX Server, which is currently not very abstracted. The server has its own key which it uses as a master key for pretty much everything. All of the key management here is done by wallits, so there's basically none.
The optional part
A lightning node - Currently I use lit for everything. When the lightning node and OpenCX Server successfully complete channel creation, the OpenCX Server registers the public key used for the channel. The indicator for this on the server side is a sigproof, since the lightning node creates a channel with the server, not the other way around. When the funding transaction is confirmed, the public key is credited with the initial push amount. This works so far, but has some issues, most caused by key management being more internal than external for both of these.
How does the server authenticate?
Currently the server authenticates by having the client sign data for each command, and send the signature in the RPC request. The pubkey is extracted from the signature, verified, and the command is executed if the signature is valid. This pubkey is used similarly to a "user" field for things like placing an order.
The issue
The first issue is that while the lightning node has its own public key that is registered on the exchange with the establishment of a channel, the OpenCX Client isn't aware of the key management going on within the lightning node. Since commands need signatures, and the pubkeys associated with the signatures are what the exchange uses to associate commands with accounts, if a client wants to do anything with the balance obtained by a lightning deposit, then it needs to be able to sign RPC requests that authenticate for the same public key that the deposit was made with.
Because there's no notion of key management at all to begin with, this is a roadblock for authentication using only public key stuff. So lightning withdrawal, and withdrawal in general, is not easy to implement right now for balances originating from lightning channels. However, if lightning withdrawal were to be implemented any other way you would probably have to specify a public key, and specify a node for withdrawal, or keep them together. Because there are public keys created at essentially every fund, it gets somewhat difficult to keep track of things compared to the whole "one deposit address per user" model.
The solution(s)
Currently I can only think of ways to solve this problem that involve modifying lit or another lightning node alongside the OpenCX Client. The ocx client itself could be a daemon, with a modified lightning node running, and all key management done within that. There might also be a more robust key management solution.
Right now the exchange has two required parts, and one optional, external part. The two required parts are:
The required parts
The OpenCX Client, currently implemented in
benchclientand utilized as a shell client inocx, sends RPC commands to the Opencx Server. The client has its own keys, and signs the commands it sends for authentication. All registration is done with this key, and this is how the server keeps track of deposit addresses (which are used to link users with deposit transactions).ocxstores its private key in~/.ocx/The OpenCX Server, which is currently not very abstracted. The server has its own key which it uses as a master key for pretty much everything. All of the key management here is done by wallits, so there's basically none.
The optional part
A lightning node - Currently I use lit for everything. When the lightning node and OpenCX Server successfully complete channel creation, the OpenCX Server registers the public key used for the channel. The indicator for this on the server side is a sigproof, since the lightning node creates a channel with the server, not the other way around. When the funding transaction is confirmed, the public key is credited with the initial push amount. This works so far, but has some issues, most caused by key management being more internal than external for both of these.
How does the server authenticate?
Currently the server authenticates by having the client sign data for each command, and send the signature in the RPC request. The pubkey is extracted from the signature, verified, and the command is executed if the signature is valid. This pubkey is used similarly to a "user" field for things like placing an order.
The issue
The first issue is that while the lightning node has its own public key that is registered on the exchange with the establishment of a channel, the OpenCX Client isn't aware of the key management going on within the lightning node. Since commands need signatures, and the pubkeys associated with the signatures are what the exchange uses to associate commands with accounts, if a client wants to do anything with the balance obtained by a lightning deposit, then it needs to be able to sign RPC requests that authenticate for the same public key that the deposit was made with.
Because there's no notion of key management at all to begin with, this is a roadblock for authentication using only public key stuff. So lightning withdrawal, and withdrawal in general, is not easy to implement right now for balances originating from lightning channels. However, if lightning withdrawal were to be implemented any other way you would probably have to specify a public key, and specify a node for withdrawal, or keep them together. Because there are public keys created at essentially every fund, it gets somewhat difficult to keep track of things compared to the whole "one deposit address per user" model.
The solution(s)
Currently I can only think of ways to solve this problem that involve modifying
litor another lightning node alongside the OpenCX Client. Theocxclient itself could be a daemon, with a modified lightning node running, and all key management done within that. There might also be a more robust key management solution.