-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC-API: Implement message signing #1536
base: master
Are you sure you want to change the base?
Conversation
properties: | ||
hd_path: | ||
type: string | ||
example: m/84'/0'/0'/0/0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does make sense, but, I find myself wondering - would it be better if we do the address -> hdpath conversion ourselves in joinmarketd? I don't think at the API client level (so, JAM), they necessarily have access to a conversion function between address and path, but we do (in wallet.py or cryptoengine.py).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just mimicked behaviour of wallet-tool.py
. Should we accept both path or address here in your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the workflow probably starts with a user wanting to sign on a specific address. Of course nothing wrong with path also, though.
docs/api/wallet-rpc.yaml
Outdated
- message | ||
- address | ||
properties: | ||
signatture: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with b262d18.
jmclient/jmclient/wallet_rpc.py
Outdated
request_data = self.get_POST_body(request, ["hd_path", "message"]) | ||
result = wallet_signmessage(self.services["wallet"], | ||
request_data["hd_path"], request_data["message"]) | ||
if type(result) == str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you set out_str
to False
in the call above, then you will always get the tuple returned.
The thing is, wallet_signmessage
returns a str either if there is an error, or if out_str is False, so that it can output the full info string (it's for the command line, so that's why it's default). Bad design really, though not very important. The errors are only raised if the input hd path is invalid or the message is missing. For this RPC use case that doesn't apply, we input those programmatically so there's no human error. Errors just get caught by the exception raises.
So TLDR I don't think you need this if/else, but you do need to set out_str
to False
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, my mistake, somehow didn't notice that default is True
not False
. With False
it does not always return tuple, it returns tuple with successful signing, string on error. So if/else is needed.
Yes, design here isn't the best, but, OTOH, it's not the most critical functionality, so maybe not worth spending too much time redesigning it.
Addressed in 59ee058.
Thanks, looks good.
Good point, hmm, that is annoying. |
Maybe you can change the network on-the-fly in the test: use a call like seen in this code: joinmarket-clientserver/jmclient/jmclient/configure.py Lines 901 to 911 in fa17236
, remembering to change it back to whatever it was, after finishing the signmessage test. |
Or maybe it's simpler and more elegant to just allow message signing with regtest / signet / testnet too? |
I didn't answer this last week because I couldn't remember why I/we only allowed this for mainnet. Now I look at the code it really doesn't make any sense; the function |
59ee058
to
b3dfa4f
Compare
Rebased. There could be improvements with regtest / testnet / signet signing and tests, but I think this is already useful, that could addressed later. @theborakompanioni WDYT? |
I think it is nice. Great work. 💪 |
Yes, currently only mainnet. Can be added for other networks too, but that should be separate PR, has nothing to do with RPC API itself. |
b3dfa4f
to
63df0ca
Compare
Rebased |
63df0ca
to
8cddf24
Compare
Rebased |
CI test failure is not related to these changes. |
8cddf24
to
b5de1a1
Compare
Rebased |
b5de1a1
to
0b3c464
Compare
Rebased |
0b3c464
to
15acd02
Compare
Rebased to run OpenAPI Diff CI action. |
Hey @kristapsk, I'm currently working on Jam issue #633, which is about signing a message. I noticed that the JM |
Yes, it's possible, but needs some coding, will look at it. Signing by path was how it was originally implemented in |
Hey @kristapsk, earlier in this conversation, you talked about allowing message signing with regtest / signet / testnet too. Can you please shed some light on that? How can someone achieve that? Like, I have added the (regtest", "testnet", "signet") networks under the sign_message function in cryptoengine.py. Here's the code:
Will this approach work, or is my approach wrong? |
I have also made some changes to the RPC-API to support the address. Please take a look at the code.
Changes_made :
Final-code:
Filename :
Changes_made :
Final-code:
Thank you for your time. |
15acd02
to
58d19f8
Compare
Rebased. |
@amitx13 Will look at your comments later. |
Resolves #1533.
My first attempt at adding new RPC-API endpoint, there could be mistakes.
Didn't add tests in
jmclient/test/test_wallet_rpc.py
as message signing is currently supported for mainnet only, not regtest (but I tested HTTP 400 response with regtest).