From 1e14988f46ae422717f2676eb5370686e266c308 Mon Sep 17 00:00:00 2001 From: RightSexyOrc Date: Tue, 18 Oct 2022 15:13:47 +0000 Subject: [PATCH 1/3] first commit for this chip --- ...-name-service-wallet-address-resolution.md | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md diff --git a/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md new file mode 100644 index 00000000..cc43c73e --- /dev/null +++ b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md @@ -0,0 +1,75 @@ +CHIP Number | < Creator must leave this blank. Editor will assign a number.> +:-------------|:---- +Title | Name Service Wallet Address Resolution +Description | +Author | Right Sexy Orc @rightsexyorc +Editor | < Creator must leave this blank. Editor will be assigned.> +Comments-URI | < Creator must leave this blank. Editor will assign a URI.> +Status | < Creator must leave this blank. Editor will assign a status.> +Category | Informational +Sub-Category | Guideline +Created | 2022-10-18 +Requires | +Replaces | +Superseded-By | + +This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). All media associated with this CHIP should be added to the `assets/chip-` folder, which you may create after you receive your CHIP number. + +Copy the template file to the `chips` folder, rename it to `chip--`, fill it out, and submit it as a pull request. + +## Abstract +Give a single-paragraph description of your proposal. The abstract should stand on its own -- someone who reads it should be able to understand the gist of your proposal without reading anything else. + +## Motivation +Describe why you are creating this proposal. Make sure to include: + * What problem are you trying to solve? + * How would this proposal benefit Chia's overall ecosystem? + * What are the use cases for this proposal? + * How technically feasible will this be to implement? + +This section is especially critical if you are proposing changes to Chia's core protocols. It should clearly answer all of the above, as well as explain exactly why the current protocol is inadequate. + +## Backwards Compatibility +If your proposal has any backwards incompatibilities, you must list them here. Make sure to include: + * Which aspects of your proposal are not backwards compatible? + * Which alternatives did you consider, and why did you not propose them? + * How severe are the incompatibilities introduced? + * How does your proposal address these incompatibilities? + +## Rationale +Describe the reasons for designing your features in the way you have proposed. Make sure to include: + * Why did you choose your design? + * What design decisions did you make? + * What alternative designs did you consider? + * How have you achieved community consensus for your design? Provide links to discussions if available. + * What objections were raised during your discussions with the community, and how does your design address them? + +## Specification +List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. + +This section should be _detailed_. It needs to allow for competing interoperable implementations. When applicable, it may include technical diagrams to accompany your design. + +## Test Cases + * Most Standards Track proposals will require a suite of test cases, which you may add to the `assets/chip-` folder. + * Some Process proposals will require test cases, depending on the significance of new features being added. + * Informational proposals typically will not require test cases. + +Your proposal will have a greater chance of success if you err on the side of including more test cases. Use your best judgment. + +## Reference Implementation +Most Standards Track proposals, as well as some Process proposals, also will require a reference implementation to be included. It should be added to the same folder as your test cases, `assets/chip-`. + +Regardless of this proposal's category, the reference implementation does not need to be completed in order to move the CHIP into _Draft_. However, it must be provided before the CHIP can be moved into _Review_. + +## Security +This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: + * Security-related design decisions + * Important discussions + * Any security-related guidance + * All threats and risks, as well as how you are addressing them + +## Additional Assets +Give a listing of files associated with this CHIP. This list will be added upon as the CHIP moves along the process of approval. All new files should be added to the `assets/chip-` folder. You should link to each individual file here, using relative links. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From f0981f6dec45e9afabb4aded29b010e3eff81846 Mon Sep 17 00:00:00 2001 From: RightSexyOrc Date: Wed, 19 Oct 2022 17:11:00 +0000 Subject: [PATCH 2/3] filling in draft part 1 --- ...-name-service-wallet-address-resolution.md | 85 ++++++++++++------- 1 file changed, 54 insertions(+), 31 deletions(-) diff --git a/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md index cc43c73e..f9c39f84 100644 --- a/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md +++ b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md @@ -1,53 +1,72 @@ CHIP Number | < Creator must leave this blank. Editor will assign a number.> :-------------|:---- Title | Name Service Wallet Address Resolution -Description | -Author | Right Sexy Orc @rightsexyorc +Description | A standard for NFTs to provide resolution of a name into a Chia address +Author | Right Sexy Orc: Keybase @rightsexyorc Editor | < Creator must leave this blank. Editor will be assigned.> Comments-URI | < Creator must leave this blank. Editor will assign a URI.> Status | < Creator must leave this blank. Editor will assign a status.> Category | Informational Sub-Category | Guideline Created | 2022-10-18 -Requires | -Replaces | -Superseded-By | - -This is the template for all CHIPs to use. Please fill it out according to the guidelines laid out in [chip001](/CHIPs/chip-0001.md). All media associated with this CHIP should be added to the `assets/chip-` folder, which you may create after you receive your CHIP number. - -Copy the template file to the `chips` folder, rename it to `chip--`, fill it out, and submit it as a pull request. +Requires | 0007 +Replaces | +Superseded-By | ## Abstract -Give a single-paragraph description of your proposal. The abstract should stand on its own -- someone who reads it should be able to understand the gist of your proposal without reading anything else. +This CHIP provides a method for an NFT to indicate a name that can map, or resolve, to a Chia blockchain address, with an optional expiry block number. ## Motivation -Describe why you are creating this proposal. Make sure to include: - * What problem are you trying to solve? - * How would this proposal benefit Chia's overall ecosystem? - * What are the use cases for this proposal? - * How technically feasible will this be to implement? +Chia blockchain addresses are long and hard for humans to memorize, communicate and transcribe. + +Name services such as Domain Name Service (DNS) and Ethereum Name Service (ENS) are examples of methods for solving this problem for IP addresses and Ethereum blockchain addresses. + +This proposal benefits the ecosystem by facilitating transaction creation, as well as Chia adoption by a larger number of humans. + +Use cases for this address resolution include helping people communicate their payment address to others using their memory when they don't have their address available, and helping people transcribe their address when communicated verbally. It can also reduce error rates when copied and pasted in a computer manually, by making verification easier. -This section is especially critical if you are proposing changes to Chia's core protocols. It should clearly answer all of the above, as well as explain exactly why the current protocol is inadequate. +This proposal has already been implemented by Namesdao and our team has received confirmation by name holders of instances where it helped them communicate a payment address to others, so technical feasibility has been demonstrated and there has been some validation of use cases. ## Backwards Compatibility -If your proposal has any backwards incompatibilities, you must list them here. Make sure to include: - * Which aspects of your proposal are not backwards compatible? - * Which alternatives did you consider, and why did you not propose them? - * How severe are the incompatibilities introduced? - * How does your proposal address these incompatibilities? +No backwards incompatibilities ## Rationale -Describe the reasons for designing your features in the way you have proposed. Make sure to include: - * Why did you choose your design? - * What design decisions did you make? - * What alternative designs did you consider? - * How have you achieved community consensus for your design? Provide links to discussions if available. - * What objections were raised during your discussions with the community, and how does your design address them? +We looked to leverage existing patterns and designs when we designed this approach. + +We looked especially to the Ethereum Name Service, which also uses an NFT approach. + +We also looked to integrate with and leverage the existing primitives and design of the Chia blockchain. + +A Chia NFT-based approach would leverage the existing infrastructure built throughout the ecosystem as well as existing primitives such as offers. Various wallets already support transfers and display of NFT's, and various NFT and blockchain explorers already support the standard as well. Additionally, various participants in the Chia community already are owners of NFT's and in many cases, have experience transferring or purchasing NFT's. + +For design decisions, we decided to embed the name and expiry block into the metadata URI, and also to use DID-backed NFT's. + +We considered exploring DID based possibilities, but there is very limited DID adoption beyond DID-backed NFT's, and no Accepted status CHIP specification. + +One objective raised was based on the belief that name resolution required loading of the offchain metadata, but that is not the case, since the data is in the NFT's URI's itself. The design has been integrated into the [chia-crypto-utils developer toolkit](https://github.com/irulast/chia-crypto-utils), which is a toolkit used by many wallet developers, and thousands of Names have been registered through [Namesdao](https://www.namesdao.org/). + ## Specification -List the full technical design specification of any new feature you are proposing. This must include details of all syntax and semantics required to implement each new feature. -This section should be _detailed_. It needs to allow for competing interoperable implementations. When applicable, it may include technical diagrams to accompany your design. +Names are referenced in lowercase. If there is no dot extension at the end of the name, e.g. .xch, They will be interpreted as .xch extension names, e.g. _namesdaotime will reference _namesdaotime.xch. + +A Wallet Address-resolving Name Record on the Chia blockchain is a NFT1 coin minted by the Namespace's DID. A name record consists of five important values: + + 1. the NFT coin id (provided per NFT1) + 2. The name, which is lowercase (required) + 3. The expiry block, an integer (optional) + 4. The Chia blockchain NFT owner address, per the NFT1 specification (provided per NFT1) + 5. Minter DID (per NFT1) + +A. To extract the Name and Expiry Block from a Name NFT: + + 1. Extract the second-to-last URI for the metadata file. + 2. Remove the .json ending + 3. Separate the text following the last "/" and split by the last "-" into two fields. + 4. The (optional) expiry block is the second field. + 5. URL-decode the first field to obtain the name. + +B. The Wallet address for the name is the NFT owner address, per the NFT1 specification (CHIP-0005). ## Test Cases * Most Standards Track proposals will require a suite of test cases, which you may add to the `assets/chip-` folder. @@ -57,11 +76,15 @@ This section should be _detailed_. It needs to allow for competing interoperable Your proposal will have a greater chance of success if you err on the side of including more test cases. Use your best judgment. ## Reference Implementation -Most Standards Track proposals, as well as some Process proposals, also will require a reference implementation to be included. It should be added to the same folder as your test cases, `assets/chip-`. +We will provide a code sample for parsing the name and expiry block from a URI. -Regardless of this proposal's category, the reference implementation does not need to be completed in order to move the CHIP into _Draft_. However, it must be provided before the CHIP can be moved into _Review_. +Additional information is available in [Namesdao's NDIP-0002](https://github.com/theNamesdao/ndips/blob/main/ndips/ndip-0002.md). ## Security + +A compromise of the Namespace's DID would let an attacker issue new Names. Each Namespace must take measures to secure its DID, as must any DID-backed NFT minter. + + This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: * Security-related design decisions * Important discussions From 4cd4e7e5e4130f3e8c2367c40014b916e27326eb Mon Sep 17 00:00:00 2001 From: RightSexyOrc Date: Thu, 20 Oct 2022 23:28:30 +0000 Subject: [PATCH 3/3] draft version 1 --- ...-name-service-wallet-address-resolution.md | 55 ++++++++++++------- 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md index f9c39f84..d86dceef 100644 --- a/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md +++ b/CHIPs/chip-thenamesdao-name-service-wallet-address-resolution.md @@ -23,7 +23,7 @@ Name services such as Domain Name Service (DNS) and Ethereum Name Service (ENS) This proposal benefits the ecosystem by facilitating transaction creation, as well as Chia adoption by a larger number of humans. -Use cases for this address resolution include helping people communicate their payment address to others using their memory when they don't have their address available, and helping people transcribe their address when communicated verbally. It can also reduce error rates when copied and pasted in a computer manually, by making verification easier. +Use cases for this address resolution include helping people communicate their payment address to others using their memory when they don't have their address available, and helping people transcribe their address when communicated verbally. It can also reduce error rates when copied and pasted in a computer manually, by making human verification of the transcription easier. This proposal has already been implemented by Namesdao and our team has received confirmation by name holders of instances where it helped them communicate a payment address to others, so technical feasibility has been demonstrated and there has been some validation of use cases. @@ -39,18 +39,22 @@ We also looked to integrate with and leverage the existing primitives and design A Chia NFT-based approach would leverage the existing infrastructure built throughout the ecosystem as well as existing primitives such as offers. Various wallets already support transfers and display of NFT's, and various NFT and blockchain explorers already support the standard as well. Additionally, various participants in the Chia community already are owners of NFT's and in many cases, have experience transferring or purchasing NFT's. -For design decisions, we decided to embed the name and expiry block into the metadata URI, and also to use DID-backed NFT's. +As a design decision, and to maintain required data on-chain, we decided to embed the name and expiry block into the metadata URI, and also to use DID-backed NFT's. We considered exploring DID based possibilities, but there is very limited DID adoption beyond DID-backed NFT's, and no Accepted status CHIP specification. -One objective raised was based on the belief that name resolution required loading of the offchain metadata, but that is not the case, since the data is in the NFT's URI's itself. The design has been integrated into the [chia-crypto-utils developer toolkit](https://github.com/irulast/chia-crypto-utils), which is a toolkit used by many wallet developers, and thousands of Names have been registered through [Namesdao](https://www.namesdao.org/). +One objection raised was based on the belief that name resolution required loading of offchain metadata, but that is not the case, since the data is in the NFT's URI itself. Thousands of Names have been registered through [Namesdao](https://www.namesdao.org/). The design's reference implementation has been integrated into the [chia-crypto-utils developer toolkit](https://github.com/irulast/chia-crypto-utils), which is a toolkit used by many wallet developers. ## Specification -Names are referenced in lowercase. If there is no dot extension at the end of the name, e.g. .xch, They will be interpreted as .xch extension names, e.g. _namesdaotime will reference _namesdaotime.xch. +### Primary Resolution -A Wallet Address-resolving Name Record on the Chia blockchain is a NFT1 coin minted by the Namespace's DID. A name record consists of five important values: +Names are referenced in lowercase. Primary resolution is performed exclusively using the Chia blockchain. + +If there is no dot extension at the end of the name, e.g. .xch, the name will be interpreted as a .xch extension name, e.g. _namesdaotime will reference _namesdaotime.xch. + +A Wallet Address-resolving Name on the Chia blockchain is a NFT1 coin minted using the Name Service's DID. A name record for resolving the Name consists of five important values: 1. the NFT coin id (provided per NFT1) 2. The name, which is lowercase (required) @@ -60,39 +64,48 @@ A Wallet Address-resolving Name Record on the Chia blockchain is a NFT1 coin min A. To extract the Name and Expiry Block from a Name NFT: - 1. Extract the second-to-last URI for the metadata file. + 1. Get the second-to-last metadata URI. 2. Remove the .json ending 3. Separate the text following the last "/" and split by the last "-" into two fields. - 4. The (optional) expiry block is the second field. - 5. URL-decode the first field to obtain the name. + 4. URL-decode the first field to obtain the name. + 5. The (optional) expiry block is the second field. B. The Wallet address for the name is the NFT owner address, per the NFT1 specification (CHIP-0005). +Full node and blockchain explorers should resolve names directly from the blockchain using this technique. + +### Secondary Resolution Services + +Name Services or third-parties may provide secondary name resolution services that may help an application avoid the need to index all names on the blockchain or have a full copy of the blockchain. + +Two techniques can be used for verifying secondary name resolver data, depending on the application. + + 1. The secondary resolver may supply the NFT coin id, so that a full node wallet can look up the NFT coin quickly and verify from its own copy of the blockchain without having to index all names locally. This uses the secondary resolver in a trustless way, though it might not resolve all registered names if not all have been added correctly to the secondary resolver. + + 2. The secondary resolver may return data that is PGP signed with a public key of the name service or third party secondary resolution service provider. This could be useful for a light wallet, and avoid the risk of man-in-the-middle attacks and domain seizures. + + ## Test Cases - * Most Standards Track proposals will require a suite of test cases, which you may add to the `assets/chip-` folder. - * Some Process proposals will require test cases, depending on the significance of new features being added. - * Informational proposals typically will not require test cases. + * Test resolving unregistered name + * Test resolving expired name + * Test resolving recently transferred name + * Test resolving newly registered name -Your proposal will have a greater chance of success if you err on the side of including more test cases. Use your best judgment. ## Reference Implementation -We will provide a code sample for parsing the name and expiry block from a URI. +Implemented by [Namesdao](https://www.namesdao.org/) + +We will provide a code sample for parsing the name and expiry block from a URI value. Additional information is available in [Namesdao's NDIP-0002](https://github.com/theNamesdao/ndips/blob/main/ndips/ndip-0002.md). ## Security -A compromise of the Namespace's DID would let an attacker issue new Names. Each Namespace must take measures to secure its DID, as must any DID-backed NFT minter. - +A compromise of the Namespace's DID would let an attacker issue new Names. Each Name Service must take measures to secure its DID, as must any DID-backed NFT minter. -This section is mandatory for all CHIPs. List all considerations relevant to the security of this proposal if it is implemented. This section may be modified as the proposal moves toward consensus. Make sure to include: - * Security-related design decisions - * Important discussions - * Any security-related guidance - * All threats and risks, as well as how you are addressing them ## Additional Assets -Give a listing of files associated with this CHIP. This list will be added upon as the CHIP moves along the process of approval. All new files should be added to the `assets/chip-` folder. You should link to each individual file here, using relative links. +N/A ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).