Differential D13916 Diff 40389 doc/standards/ecash-alias.md

Changeset View

Standalone View

doc/standards/ecash-alias.md

	Show All 33 Lines
	Phase 2			Phase 2

	- NFT airdrop to existing holders			- NFT airdrop to existing holders
	- 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 '00'.
	3. A push of the Alias.			3. A push of the Alias.
	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 without a preceding `4c`, e.g. `150076458db0ed96fe9863fc1ccec9fa2cfab884b0f6` is a valid address push. `4c150076458db0ed96fe9863fc1ccec9fa2cfab884b0f6` is not.
				FabienUnsubmitted Not Done Inline Actions So it can be pushed with OP_PUSHDATA4 ? Fabien: So it can be pushed with OP_PUSHDATA4 ?
				bytesofmanAuthorUnsubmitted Done Inline Actions Updated spec to be less ambiguous here. In this case...it could yes, but then the address would be invalid. bytesofman: Updated spec to be less ambiguous here. In this case...it could yes, but then the address…
				FabienUnsubmitted Not Done Inline Actions I don't think this is the right approach. This whole ambiguousity of the spec push format is a hint that whatever you add to this spec, it's a good time to implement a proper method for parsing a script data push. Once you have this method that works for all the different flavors of push, then you can start restricting to some method that makes sense depending on what you're pushing. What you have here is premature optimization and you can be sure that it will break your code when the spec evolves. Fabien: I don't think this is the right approach. This whole ambiguousity of the spec push format is a…
				3. Transactions containing more than one OP_RETURN output cannot be valid alias registrations.

	### 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 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.

	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 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 Registration Payment Amount			### The Registration Payment Amount
	▲ Show 20 Lines • Show All 54 Lines • Show Last 20 Lines