oxen-io
/
oxen-core
mirror of https://github.com/oxen-io/oxen-core.git
2
1
Fork 0
Code Issues Projects Releases Wiki Activity

LNS: Update documentation to say wallet addresses are valid for owners

This commit is contained in:
Doyle 2020-03-13 16:16:50 +11:00
parent 0112974dda
commit 02c581168c
1 changed files with 11 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
src/wallet/wallet_rpc_server_commands_defs.h
View File

@ -2855,19 +2855,19 @@ namespace wallet_rpc
struct COMMAND_RPC_LNS_BUY_MAPPING
{
static constexpr const char *description =
R"(Buy a Loki Name System mapping. Loki Name System allows multiple owners that are authorised to update the underlying mapping. An owner can be either a ed25519 public key or a wallet address. By default if no owner is specified, the purchasing wallet's public spend key is used from the wallet as the owner.
R"(Buy a Loki Name System mapping. Loki Name System allows multiple owners that are authorised to update the underlying mapping. An owner can be either a ed25519 public key or a wallet address. By default if no owner is specified, the purchasing wallet's active [sub]address is stored as the owner.
- For Session, the recommended owner is the ed25519 public key of the user's Session ID set to owner
In future, support for mappings on Blockchain wallets and Lokinet addresses will be available. The recommended owner is the monero ed25519 public key of the user's wallet spend key set to owner.
In future, support for mappings on Blockchain wallets and Lokinet addresses will be available. The recommended owner is the wallet's [sub]address.
When specifying owners, either a Monero twist or standard ed25519 public key is supported per mapping. Updating the value that a name maps to requires one of the owner keys to sign the update transaction.
When specifying owners, either a wallet [sub]address or standard ed25519 public key is supported per mapping. Updating the value that a name maps to requires one of the owner's to sign the update transaction. For wallets, this is signed using the subaddress's spend key.
For information on updating & signing, refer to COMMAND_RPC_LNS_UPDATE_MAPPING)";
struct request_t
{
std::string type; // The mapping type, currently we only support "session". In future "lokinet" and "blockchain" mappings will be available.
std::string owner; // (Optional): The public key that has authority to update the mapping.
std::string owner; // (Optional): The ed25519 public key or wallet address that has authority to update the mapping.
std::string backup_owner; // (Optional): The secondary, backup public key that has authority to update the mapping.
std::string name; // The name to purchase via Loki Name Service
std::string value; // The value that the name maps to via Loki Name Service, (i.e. For Session: [display name->session public key]. In future, for wallets: [name->wallet address], for Lokinet: [name->domain name]).
@ -2927,14 +2927,14 @@ For information on updating & signing, refer to COMMAND_RPC_LNS_UPDATE_MAPPING)"
struct COMMAND_RPC_LNS_UPDATE_MAPPING
{
static constexpr const char *description =
R"(Update a Loki Name System mapping's underlying value. The owner (wallet address/ed25519 public key) of the mapping must be able to validate.
R"(Update a Loki Name System mapping's underlying value. The pre-existing owner (wallet address/ed25519 public key) of the mapping must be able to validate. At least one field must be specified to update, otherwise the funtion returns an error message.
The signature is generated from signing a hash generated by using Libsodium's generichash on the {prev_txid field (in the current mapping to update), value (new value to update to)} in binary.
Depending on the owner's public key(s) associated with the mapping the signature can sign the hash in 2 ways. If the owner public key associated with the mapping is-
- a monero public key, the signature is generated by using Monero's crypto::generate_signature on the hash
The signature is generated from signing a hash generated by using Libsodium's generichash on the {new value (if provided), new owner (if provided), new backup_owner (if provided), prev_txid field (in the current mapping to update)} in binary.
Depending on the owner associated with the mapping the signature can be generated in 2 ways. If the owner associated with the mapping is-
- a wallet [sub]address, the signature is generated by using Monero's crypto::generate_signature on the hash with the [sub]address's spend key.
- a ed25519 public key, the signature is generated by using Libsodium's crypto_sign_detached on the hash
Providing the signature is an optional field and if not provided, will default to attempting to sign using the wallet's Monero-style spend keys.)";
Providing the signature is an optional field and if not provided, will default to attempting to sign using the wallet's active [sub]address's spend keys.)";
struct request_t
{
@ -3001,12 +3001,9 @@ Providing the signature is an optional field and if not provided, will default t
struct COMMAND_RPC_LNS_MAKE_UPDATE_SIGNATURE
{
static constexpr const char *description =
R"(Generate the signature necessary for updating the requested record using the wallet's spend key. The signature is
only valid if the queried wallet is one of the owners of the LNS record.
R"(Generate the signature necessary for updating the requested record using the wallet's active [sub]address's spend key. The signature is only valid if the queried wallet is one of the owners of the LNS record.
This command is only required if the open wallet is one of the owners of a LNS record but want the update
transaction to occur via another non-owning wallet. By default, if no signature is specified to the update
transaction, the open wallet is assumed the owner and it's spend key will automatically be used.)";
This command is only required if the open wallet is one of the owners of a LNS record but wants the update transaction to occur via another non-owning wallet. By default, if no signature is specified to the update transaction, the open wallet is assumed the owner and it's active [sub]address's spend key will automatically be used.)";
struct request_t
{