Page MenuHomePhabricator

[Standards] Spec for xec aliases
ClosedPublic

Authored by bytesofman on Jan 11 2023, 16:19.

Details

Reviewers
emack
Group Reviewers
Restricted Project
Commits
rABCe4d0591e0236: [Standards] Spec for xec aliases
Summary

T2551

Spec for eCash alias system

Test Plan

Review and suggest improvements

Diff Detail

Repository
rABC Bitcoin ABC
Branch
alias-spec
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 21731
Build 43101: Build Diff
Build 43100: arc lint + arc unit

Event Timeline

Note: should mention desired support for payment codes, HD wallets in the future.

Worth updating with info on the payment address, such as:

  • registration fees are paid to a single address
  • this address will be polled via the chronik client for its transaction history, whereby incoming txs are parsed for valid registration txs
  • caching will be achieved via checking of the address' total transaction count. If it is unchanged since last retrieval, then the registration history will be retrieved from local storage, thereby minimizing the amount of onchain operations.

Also add some additional caveats:

  • the reason for opting for this onchain approach is due to security considerations. Should this feature become popular there may be significant sums of XEC being transacted via these aliases, where an offchain and centralized lookup and registration server would become a highly targed attack vector.
  • Fees received from alias registrations will be repurposed as GNC funds? (This clarification is needed because we are asking other external wallets to put in work to support this).
  • alias are attached to ecash addresses only, not etoken addresses

Note: we should consider reserving shorter aliases until some future blockheight, since this would allow for a period of price discovery / evaluation.

  • Attempt should be made to prevent scam registrations. Should have some kind of reserved list of aliases that points to the IFP address.
  • Potentially want to set a target blockheight for Phase 2. Even if it's missed, should require some kind of action to stay on phase 1. Need to make sure that all supporting wallets move to new system once it is defined by NFTs, since the phase 1 addresses may no longer be correct.

Thinking out loud, we should set the price to be much higher than even an auction-expected result for shorter aliases instead of hard disabling them.

This would be easier to implement and, well, if someone REALLY wants to buy a provisional alias in an experimental system ... so be it, who are we to say no?

Adding disambiguation for length and case sensitivity

This revision is now accepted and ready to land.Mar 2 2023, 22:34
This revision was automatically updated to reflect the committed changes.