Differential D13994 Diff 40759 doc/standards/ecash-alias.md

Changeset View

Standalone View

doc/standards/ecash-alias.md

	Show All 36 Lines
	- Tradeable aliases; aliases tied to NFT possession			- Tradeable aliases; aliases tied to NFT possession

	## Phase 1 details			## Phase 1 details

	Aliases are registered by creating a "Registration Transaction" with the following properties:			Aliases are registered by creating a "Registration Transaction" with the following properties:

	1. An output paying the required amount to a designated "Registration Address", and			1. An output paying the required amount to a designated "Registration Address", and
	2. An output with an OP_RETURN containing 4 data pushes:			2. An output with an OP_RETURN containing 4 data pushes:
	1. A push of the 4-byte protocol identifier.			1. A push of the 4-byte protocol identifier. Must be pushed with `04`.
	2. A push of a version number.			2. A push of a version number. Must be pushed as `OP_0`.
	3. A push of the Alias.			3. A push of the Alias. Must be pushed with `0x01-0x15`.
	4. A push of a CashAddr payload. This information defines the "Alias Address".			4. A push of a CashAddr payload. This information defines the "Alias Address". Must be pushed with `15`

	### The Registration Address			### The Registration Address

	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. Since the transaction history of this address cannot change, wallets supporting this alias system may cache valid aliases up to a known blockheight to minimize on-chain polling.			Registration fees are paid to a single address. This address is polled via the chronik client for its transaction history, whereby incoming txs are parsed for valid registration txs. Since the transaction history of this address cannot change, wallets supporting this alias system may cache valid aliases up to a known blockheight to minimize on-chain polling.

	The designated registration address will either be the IFP address or an address that periodically sends funds from valid registrations to the IFP address. Automatically processing hot wallet refunds for invalid transactions would not be feasible from the IFP address.			The designated registration address is the IFP address.

	### The Registration Payment Amount			### The Registration Payment Amount

	The required amount to be paid to the registration address is determined by the number of bytes in the alias, with shorter aliases having a higher fee. Aliases may be between 1 and 21 bytes.			The required amount to be paid to the registration address is determined by the number of bytes in the alias, with shorter aliases having a higher fee. Aliases may be between 1 and 21 bytes.

	This amount may change during Phase 1. This change may be enforced by verifying the correct fee against registration blockheight.			This amount may change during Phase 1. This change may be enforced by verifying the correct fee against registration blockheight.

	### The Protocol Identifier			### The Protocol Identifier
	Show All 11 Lines
	If one alias can be human indistinguishable from another alias, then all aliases will also be copy-paste only inputs.			If one alias can be human indistinguishable from another alias, then all aliases will also be copy-paste only inputs.

	In the initial release of this feature, aliases are limited to lowercase alphanumeric characters (a-z, 0-9) to mitigate edge cases such as zero-width spaces and language specific character similarities.			In the initial release of this feature, aliases are limited to lowercase alphanumeric characters (a-z, 0-9) to mitigate edge cases such as zero-width spaces and language specific character similarities.

	An alias may be between 1 and 21 bytes in length, inclusive.			An alias may be between 1 and 21 bytes in length, inclusive.

	### The Alias Address			### The Alias Address

	The Alias Address is defined in a 21-byte push containing a CashAddr payload. The first byte will be the version byte indicating the type of address, and the following 20 bytes are the hash.			The Alias Address is defined in a 21-byte push containing a CashAddr payload. The first byte is the version byte indicating the type of address, and the following 20 bytes are the hash.

	An Alias Address may have many aliases. Each alias maps to one and only one Alias Address.			An Alias Address may have many aliases. Each alias maps to one and only one Alias Address.

	### Additional Validity Criteria:			### Additional Validity Criteria:

	- Must be a valid eCash transaction with 1 confirmation			- Must be a valid, finalized eCash transaction with 1 confirmation
	- Have the lowest blockheight of any other alias registration transaction for the same alias			- Have the lowest blockheight of any other alias registration transaction for the same alias
	- When the same alias is registered in the same block by different addresses, the valid alias will be determined by the registration with the alphabetically first txid.			- When the same alias is registered in the same block by different addresses, the valid alias is the registration with the alphabetically first txid.
				- For the case of an alias registration transaction with more than one alias registration OP_RETURN outputs:

				1. If the registration fee covers the total required fee for all registered aliases, they are all valid. If not, none are valid.
				2. If such a tx attempts to register the same alias multiple times, none of the registrations are valid

	Invalid transactions that do not match the criteria above should be ignored by the app parsing the payment address history.			Invalid transactions that do not match the criteria above should be ignored by the app parsing the payment address history.

	## Recommended Usage			## Recommended Usage

	It is recommended that user facing applications interpret the ".xec" extension to indicate an eCash Alias. For example, if a user wishes to send XEC to someone based on their Alias, they could enter the Alias with .xec extension (eg. "myalias.xec") into the "To:" field in the wallet. The wallet software would then send the XEC to the appropriate address by looking it up in the index of Aliases and the associated eCash addresses.			It is recommended that user facing applications interpret the ".xec" extension to indicate an eCash Alias. For example, if a user wishes to send XEC to someone based on their Alias, they could enter the Alias with .xec extension (eg. "myalias.xec") into the "To:" field in the wallet. The wallet software would then send the XEC to the appropriate address by looking it up in the index of Aliases and the associated eCash addresses.

	## Known risks			## Known risks
	Show All 12 Lines