NUT-XX - Mint Remote signer standard #250
Conversation
|
I still need to add test vectors for the key derivation |
change tittle Co-authored-by: Pavol Rusnak <[email protected]>
grammar correction Co-authored-by: lollerfirst <[email protected]>
|
@crodas Can you look at where cdk deviates from this and bring the two in line? Also we should use a common proto file. Think it would be best to create a cashubtc repo for the proto files and remove it from the nuts directly and instead link to it. Think @lollerfirst did one for the management rpc. |
remote-signer.proto
Outdated
| bool active = 3; | ||
| uint64 input_fee_ppk = 4; | ||
| Keys keys = 5; | ||
| uint64 version = 6; |
There was a problem hiding this comment.
Added it to the structure and the keyset rotation call
remote-signer.proto
Outdated
| } | ||
|
|
||
| // Witness type | ||
| message Witness { |
There was a problem hiding this comment.
|
@crodas I added the final_expiry to be optional |
|
I will apply the changes we discussed in CDK this week, specially whatever is in here and dropping the redundant amount field. |
|
@lescuer97 I think cashubtc/cdk#1179 was the thing we discussed, is there anything else missing? /cc @thesimplekid |
|
There are a number of gaps and vulnerabilities in the deterministic derivation path function that are addressed in this proposed NUT spec: #292 Namely, leading and trailing whitespace, capitalization differences, and functionally equivalent unicode character sequences can cause visually identical currency units to hash to different derivation paths. Also, the lack of a reserved range for currently hard coded currency unit derivation paths could lead to backwards incompatible derivation path conflicts. These properties could be exploited by attackers using specially crafted currency unit strings. If y'all would like to review PR 292 I think it would be complementary to this spec proposal and they could potentially go at the same time. |
|
@thesimplekid @vnprc added some features form this #292 pr. should have the details that we discussed |
|
demo showing the spec with 3 signers: remote_signer_demo_compresed_free_convert.mp4 |
| 2. Apply Unicode Normalization Form C (NFC). | ||
| 3. Convert the normalized string to uppercase using Unicode-aware semantics. | ||
|
|
||
| | Input unit | Canonical form | Index | |
There was a problem hiding this comment.
When you say 'index' here, do you mean 'unit reference'? This is essentially the first mention of 'index' in this doc, and I don't know what it is.
(I see many others have commented already. Apologies in advance if I now ask a few questions that have already been answered 😀)
There was a problem hiding this comment.
hi! it just talks about the actual index number that is going to be used later on the derivation path
There was a problem hiding this comment.
hi! it just talks about the actual index number that is going to be used later on the derivation path.
Should probably use better naming
10 participants
This is a standard for Mints to be able to communicate with a remote signer for cryptographic operations as well as keyset information.
Their is also a standard way for signers to derive their keysets from their master key.
The goal of this nut is to better isolate the private keys of the mint and standardize the communications between the signer and mint.
Implementations: