Skip to content
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

New HIP: Verifiable Address Provider (VAP) #49

Open
wants to merge 31 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
a374d59
Create HIP-xxx-TCAP.md
befranz Mar 29, 2022
3a200ec
Update HIP-xxx-TCAP.md
befranz Mar 29, 2022
3ae84c8
Update HIP-xxx-TCAP.md
befranz Mar 29, 2022
08ab9b4
Update HIP-xxx-TCAP.md
befranz Mar 29, 2022
8a4b14c
Update HIP-xxx-TCAP.md
befranz Mar 29, 2022
a13d33b
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
995a502
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
966bfc5
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
56ff57e
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
e4a1525
Update email
0xStefan Mar 30, 2022
4525ea2
Update HIP-xxx-TCAP.md
0xStefan Mar 30, 2022
728547b
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
0ce515e
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
fc5bcbe
Update HIP-xxx-TCAP.md
befranz Mar 30, 2022
2b6a032
Update HIP-xxx-TCAP.md
befranz Mar 31, 2022
9eb8d6f
Merge branch 'master' into patch-1
befranz Mar 31, 2022
f331eba
Merge pull request #1 from 0xStefan/patch-1
befranz Mar 31, 2022
5967440
Merge pull request #2 from 0xStefan/patch-2
befranz Mar 31, 2022
115e45b
Update HIP-xxx-TCAP.md
befranz Mar 31, 2022
d1b06d4
Create HIP-xxxx-VSAP-DNS.md
befranz Mar 31, 2022
05ae9ab
Update HIP-xxxx-VSAP-DNS.md
befranz Mar 31, 2022
d4d8be0
Update HIP-xxxx-VSAP-DNS.md
befranz Mar 31, 2022
40272c4
Update HIP-xxxx-VSAP-DNS.md
befranz Mar 31, 2022
b2ff18c
Update HIP-xxxx-VSAP-DNS.md
befranz Mar 31, 2022
3c86426
Create HIP-xxxx-VAP.md
befranz Apr 15, 2022
17924c6
Update HIP-xxxx-VAP.md
befranz Apr 15, 2022
103552c
Delete HIP-xxx-TCAP.md
befranz Apr 20, 2022
08af05f
Delete HIP-xxxx-VSAP-DNS.md
befranz Apr 20, 2022
3278f1c
Update HIP-xxxx-VAP.md
befranz Apr 20, 2022
6849284
HIP-xxxx : Extended Claim Period
befranz Jun 10, 2022
b5de17f
HIP-xxxx : Extended Claim Period
befranz Jun 10, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
node_modules
docs/content/*
!docs/content/proposals/_index.md
docs/public
docs/public
.DS_Store
58 changes: 58 additions & 0 deletions HIP-xxxx-Extended-Claim-Period.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# HIP-xxxx : Extended Claim Period

```
Number: HIP-xxxx
Title: HIP-xxxx : Extended Claim Period
Type: Informational
Status: Draft
Authors: befranz <[email protected]>
Created: 2022-06-10
```

## Abstract

This HIP describes how the current 4 year claim period for reserved names on Handshake which will end in February 2024 should be extended.

The reserved names are divided into three different groups since they are handled differently:

* All current ICANN TLDs reserved on Handshake (Group 1, 3, 5, 9 - 1,516)
* All current ICANN domains eligible to claim more than 504 HNS (Group 2, 4 - 79)
* All current ICANN domains eligible to claim less than 504 HNS (Group 0 - 88,448)

The reserved name list contains 90,043 names (see References), over 4,000 are claimed by June 2022.

## Motivation

There are several reasons the current 4 year claim period and the associated claimable amount of HNS for reserved names on Handshake should be changed.

* Avoiding possible future conflicts with currently reserved ICANN TLDs
* Giving holders of legacy domains more time to claim their reserved names
* Enabling any currently active legacy domain to claim their reserved name over the extended period
* Removing financial benefits to register expired ICANN domains with reserved names on Handshake
* Motivating holders of high value legacy domains to claim their reserved names rather sooner than later

## Basic Rules

After the initial claim period ending with block 210,240 (144 blocks/day * 365 days * 4 years) the extended claim period of another 210,240 blocks will start and end with block 420,480.

The current list of reserved names remain unchanged.

## ICANN TLDs

Any current ICANN TLD reserved on Handshake will be reserved forever. During the extended claim period the claimable amount of HNS will decrease gradually over time ending with 0 HNS at the end of the extended claim period.

## ICANN domains with claimable amount greater than 504 HNS

Reserved names claimable by those domains expire after eight years. During the extended claim period the claimable amount of HNS will decrease gradually over time ending with 0 HNS at the end of the extended claim period.

## ICANN domains with claimable amount less than 504 HNS

Reserved names claimable by those domains expire after eight years. During the extended claim period only 10 HNS are claimable next to the reserved name. This makes sure that any reserved name is still claimable but the financial benefit is removed for those which were only registered to claim the associated amount of HNS.

## List of Reserved Names

In the discussions about this topic there's some consent to greatly reduce the list of reserved names for the extended claim period. But this leads to some difficult decisions which names to remove. Looking at the [Alexa Ranking](https://github.com/handshake-org/hs-names/blob/master/names/alexa.json) many popular domains - especially with ccTLDs - are not in the Top 10,000. But also for example spacex(.com) is at place 16,681. In this case I recommend to not change the list of reserved names but remove the financial benefit to claim rather useless names. Those who are interested to claim their name will also do it if just a small amount of HNS is part of the name. 10 HNS should be enough to register/move/renew the claimed name.

## References

[Reserved Names Ranking and Claimable HNS](https://github.com/befranz/HIPs/blob/master/reserved-names-ranking.csv)
61 changes: 61 additions & 0 deletions HIP-xxxx-VAP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# HIP-xxxx : Verifiable Address Provider (VAP)

```
Number: HIP-xxxx
Title: HIP-xxxx : Verifiable Address Provider (VAP)
Type: Informational
Status: Draft
Authors: befranz <[email protected]>
0xstefan <[email protected]>
Created: 2022-04-20
```

## Abstract

This HIP describes a verifiable way how a Handshake name can be used as alias for a crypto receiving address. Following wording and examples refer to this use case but basically this protocol can be used to provide any key/value pair in a verifiable fashion.

Like [HIP-2](https://github.com/handshake-org/HIPs/blob/master/HIP-0002.md) an address is provided as single line, but with an additional signature created by the [signmessagewithname](https://hsd-dev.org/api-docs/#signmessagewithname) Handshake function.

Value and signature is fetched via URL defined on chain as TXT record.

## Motivation

At first glance it's similar to HIP-2 but there's big difference in requirements the name owner needs to meet. With HIP-2 it's highly recommended to store data on a secure system the name owner has control of, in practice it means name owner needs to set up and run an authoritative name server and a web server/HIP-2 server to make sure nobody can change the addresses associated to a name.

With this HIP name owner only needs to set a TXT record on chain. Signed addresses can be stored anywhere. Service provider like niami can facilitate the steps of signing, storing and retrieving data.

This HIP can work as a fallback for HIP-2.

## TXT Record on Chain

Name owner sets a URL as base for all her addresses:

```TXT "VAPURL=<URL>"```

Example:

```TXT "VAPURL=https://api.niami.io/vap/0xstefan/"```

The wallet will add the asset symbol (like `hns` for Handshake) to the URL to get associated address and signature.

## Message to sign/verify

Data is signed by Handshake function [signmessagewithname](https://hsd-dev.org/api-docs/#signmessagewithname), URL and address are separated by white space.

```
<VAPURL><Asset> <Address>
https://api.niami.io/vap/0xstefan/hns hs1qlat47aa9m2k7pg2k0yylmqgy9h0me0jyf9rgwf
```

## Data to store online

Following data is stored online at `<VAPURL><Asset>`

```
<Address> <Signature>
hs1qlat47aa9m2k7pg2k0yylmqgy9h0me0jyf8rgwf A+D6OaTysDA90PxDLXaTx4jV/+hPkpWzhZqDbCVq9IE4B7lc/50X+jB/H9kTBYWkyGf1Bb862vS/0aQGF9dOmg==
```

## References

[SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) can be used as a symbol reference.
Loading