Differential D13868 Diff 40257 doc/standards/ecash-alias.md

Changeset View

Standalone View

doc/standards/ecash-alias.md

	Show First 20 Lines • Show All 84 Lines • ▼ Show 20 Lines
	### Additional Validity Criteria:			### Additional Validity Criteria:

	- Must be a valid eCash transaction with 1 confirmation			- Must be a valid 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 will be determined by the registration with the alphabetically first txid.

	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

				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

	Resolving conflicting alias registrations at the same blockheight by choosing the alphabetically first txid is arbitrary. It would be possible for someone to watch for broadcast registration transactions, send multiple transactions registering the same alias, and have a good chance of securing the alias before the original registrant.			Resolving conflicting alias registrations at the same blockheight by choosing the alphabetically first txid is arbitrary. It would be possible for someone to watch for broadcast registration transactions, send multiple transactions registering the same alias, and have a good chance of securing the alias before the original registrant.

	However, such an attack runs the risk of forfeiting multiple registration fees. In a sense, labeling such behavior "attack" is dubious.			However, such an attack runs the risk of forfeiting multiple registration fees. In a sense, labeling such behavior "attack" is dubious.

	The intent of Phase 1 is to determine popularity and viability of the system overall. If the system gains traction, a more sophisticated, extensible, and decentralized system may be rolled out by airdropping NFTs to registrants. If the system is unpopular, it may remain a single address permanent database.			The intent of Phase 1 is to determine popularity and viability of the system overall. If the system gains traction, a more sophisticated, extensible, and decentralized system may be rolled out by airdropping NFTs to registrants. If the system is unpopular, it may remain a single address permanent database.

	Phase 1 is rolled out using the blockchain instead of a server so that the registrations may be permanent, even if the system later becomes unmaintained.			Phase 1 is rolled out using the blockchain instead of a server so that the registrations may be permanent, even if the system later becomes unmaintained.

	## Extensibility			## Extensibility

	Permanently tying an alias to a single address is not the desired endpoint for the system. Payment codes, support for HD wallets, and other novel ways of adding additional privacy and security into the system are all desired features. Since most of the technology for these features is either unavailable or not in current use, this will not be supported in Phase 1. Lessons learned from practical implementation of Phase 1 will support extensible implementation in Phase 2.			Permanently tying an alias to a single address is not the desired endpoint for the system. Payment codes, support for HD wallets, and other novel ways of adding additional privacy and security into the system are all desired features. Since most of the technology for these features is either unavailable or not in current use, this will not be supported in Phase 1. Lessons learned from practical implementation of Phase 1 will support extensible implementation in Phase 2.