diff --git a/src/RFC-0155_TariAddress.md b/src/RFC-0155_TariAddress.md new file mode 100644 index 0000000..2b82b6c --- /dev/null +++ b/src/RFC-0155_TariAddress.md @@ -0,0 +1,150 @@ +# RFC-0155/TariAddress + +## TariAddress specification + +![status: stable](theme/images/status-stable.svg) + +**Maintainer(s)**:[SW van Heerden](https://github.com/swvheerden) + +# Licence + +[ The 3-Clause BSD Licence](https://opensource.org/licenses/BSD-3-Clause). + +Copyright 2024. The Tari Development Community + +Redistribution and use in source and binary forms, with or without modification, are permitted provided that the +following conditions are met: + +1. Redistributions of this document must retain the above copyright notice, this list of conditions and the following + disclaimer. +2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following + disclaimer in the documentation and/or other materials provided with the distribution. +3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products + derived from this software without specific prior written permission. + +THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS", AND ANY EXPRESS OR IMPLIED WARRANTIES, +INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +WHETHER IN CONTRACT, STRICT LIABILITY OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +## Language + +The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", +"NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in +[BCP 14](https://tools.ietf.org/html/bcp14) (covering RFC2119 and RFC8174) when, and only when, they appear in all capitals, as +shown here. + +## Disclaimer + +This document and its content are intended for information purposes only and may be subject to change or update +without notice. + +This document may include preliminary concepts that may or may not be in the process of being developed by the Tari +community. The release of this document is intended solely for review and discussion by the community regarding the +technological merits of the potential system outlined herein. + +## Goals + +This document outlines the specification for Tari Address, which are encoded wallet addresses used to verify wallet addresses, features, and networks. +The address should have human-readable network and feature identification and contain all information required to send transactions to a wallet owning an address. + +## Related Requests for Comment + +None + +## Description +Wallet addresses should contain all the necessary information for sending transactions to the corresponding wallet. Initially, a wallet must declare its supported features and the network it +operates on. To maintain readability, distinct identifiers are required for both the features and the network. + +For typical interactive Mimblewimble (MW) transactions, a public key is necessary for communication. The private key associated with this MUST BE securely stored by the node to prevent spoofing. +This private key functions as the spend key for deriving the actual spend key for the Unspent Transaction Output (UTXO). + +However, when non-interactive transactions are initiated, the process becomes more complex. If the receiving wallet is a standard one, it possesses all the essential information for spending +the transaction. Yet, if the recipient utilizes a hardware device like a ledger, the spending information is inaccessible to the wallet. Thus, a secondary view key becomes necessary. +While the wallet can share the private key of this view key with another party for UTXO viewing purposes, it cannot be used for spending. + +Additionally, a checksum can be included to detect errors when encoding the address as bytes. Emojis can also be easily incorporated into the encoding process by assigning each u8 an emoji. + +## The specification + +### Address + +Each address consists of four parts: View key, Spend key, Network, and Features. + +#### View key +This key allows a node to grant view access to its transactions. Possession of the private key in this key pair SHOULD enable an entity to view all transactions associated with a wallet. + +#### Spend key +Utilized to compute the spend key of a UTXO and communicate with the node over the network. The private key associated with this key pair must be securely kept hidden. + +#### Features +Indicates the supported features of the wallet, such as interactive and one-sided transactions. Currently, this is represented by an encoded u8, with each bit denoting a specific feature. + +#### Network +Specifies the Tari network the wallet operates on, e.g., Esmeralda, Nextnet, etc. + +#### Checksum +The checksum is only included when encoding the address as bytes, hex, or emojis. For the checksum, the: [DammSum](https://github.com/cypherstack/dammsum) algorithm is employed, +with `k = 8` and `m = 32`, resulting in an 8-bit checksum. + +### Encoding +#### Bytes +When generating a byte representation of the wallet, the following format is used: +[0]: Network encoded as u8 +[1]: Raw u8 representing features +[2..33]: Public view key encoded as u8 +[35..65]: Public spend key encoded as u8 +[66]: DammSum checksum + +For nodes lacking a distinct view key, where the view key and spend key are identical, their addresses can be encoded as follows: +[0]: Network encoded as u8 +[1]: Raw u8 representing features +[2..33]: Public spend key encoded as u8 +[34]: DammSum checksum + +#### Hex +Each byte in the byte representation is encoded as two hexadecimal characters. + +#### Emoji Encoding +An emoji alphabet of 256 characters has been selected, each assigned a unique index from 0 to 255 inclusive. +The list of chosen emojis is as follows: + +| | | | | | | | | | | | | | | | | +|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| +|๐Ÿฆ‹|๐Ÿ“Ÿ|๐ŸŒˆ|๐ŸŒŠ|๐ŸŽฏ|๐Ÿ‹|๐ŸŒ™|๐Ÿค”|๐ŸŒ•|โญ|๐ŸŽ‹|๐ŸŒฐ|๐ŸŒด|๐ŸŒต|๐ŸŒฒ|๐ŸŒธ| +|๐ŸŒน|๐ŸŒป|๐ŸŒฝ|๐Ÿ€|๐Ÿ|๐Ÿ„|๐Ÿฅ‘|๐Ÿ†|๐Ÿ‡|๐Ÿˆ|๐Ÿ‰|๐ŸŠ|๐Ÿ‹|๐ŸŒ|๐Ÿ|๐ŸŽ| +|๐Ÿ|๐Ÿ‘|๐Ÿ’|๐Ÿ“|๐Ÿ”|๐Ÿ•|๐Ÿ—|๐Ÿš|๐Ÿž|๐ŸŸ|๐Ÿฅ|๐Ÿฃ|๐Ÿฆ|๐Ÿฉ|๐Ÿช|๐Ÿซ| +|๐Ÿฌ|๐Ÿญ|๐Ÿฏ|๐Ÿฅ|๐Ÿณ|๐Ÿฅ„|๐Ÿต|๐Ÿถ|๐Ÿท|๐Ÿธ|๐Ÿพ|๐Ÿบ|๐Ÿผ|๐ŸŽ€|๐ŸŽ|๐ŸŽ‚| +|๐ŸŽƒ|๐Ÿค–|๐ŸŽˆ|๐ŸŽ‰|๐ŸŽ’|๐ŸŽ“|๐ŸŽ |๐ŸŽก|๐ŸŽข|๐ŸŽฃ|๐ŸŽค|๐ŸŽฅ|๐ŸŽง|๐ŸŽจ|๐ŸŽฉ|๐ŸŽช| +|๐ŸŽฌ|๐ŸŽญ|๐ŸŽฎ|๐ŸŽฐ|๐ŸŽฑ|๐ŸŽฒ|๐ŸŽณ|๐ŸŽต|๐ŸŽท|๐ŸŽธ|๐ŸŽน|๐ŸŽบ|๐ŸŽป|๐ŸŽผ|๐ŸŽฝ|๐ŸŽพ| +|๐ŸŽฟ|๐Ÿ€|๐Ÿ|๐Ÿ†|๐Ÿˆ|โšฝ|๐Ÿ |๐Ÿฅ|๐Ÿฆ|๐Ÿญ|๐Ÿฐ|๐Ÿ€|๐Ÿ‰|๐ŸŠ|๐ŸŒ|๐Ÿ| +|๐Ÿฆ|๐Ÿ|๐Ÿ‘|๐Ÿ”|๐Ÿ™ˆ|๐Ÿ—|๐Ÿ˜|๐Ÿ™|๐Ÿš|๐Ÿ›|๐Ÿœ|๐Ÿ|๐Ÿž|๐Ÿข|๐Ÿฃ|๐Ÿจ| +|๐Ÿฆ€|๐Ÿช|๐Ÿฌ|๐Ÿญ|๐Ÿฎ|๐Ÿฏ|๐Ÿฐ|๐Ÿฆ†|๐Ÿฆ‚|๐Ÿด|๐Ÿต|๐Ÿถ|๐Ÿท|๐Ÿธ|๐Ÿบ|๐Ÿป| +|๐Ÿผ|๐Ÿฝ|๐Ÿพ|๐Ÿ‘€|๐Ÿ‘…|๐Ÿ‘‘|๐Ÿ‘’|๐Ÿงข|๐Ÿ’…|๐Ÿ‘•|๐Ÿ‘–|๐Ÿ‘—|๐Ÿ‘˜|๐Ÿ‘™|๐Ÿ’ƒ|๐Ÿ‘›| +|๐Ÿ‘ž|๐Ÿ‘Ÿ|๐Ÿ‘ |๐ŸฅŠ|๐Ÿ‘ข|๐Ÿ‘ฃ|๐Ÿคก|๐Ÿ‘ป|๐Ÿ‘ฝ|๐Ÿ‘พ|๐Ÿค |๐Ÿ‘ƒ|๐Ÿ’„|๐Ÿ’ˆ|๐Ÿ’‰|๐Ÿ’Š| +|๐Ÿ’‹|๐Ÿ‘‚|๐Ÿ’|๐Ÿ’Ž|๐Ÿ’|๐Ÿ’”|๐Ÿ”’|๐Ÿงฉ|๐Ÿ’ก|๐Ÿ’ฃ|๐Ÿ’ค|๐Ÿ’ฆ|๐Ÿ’จ|๐Ÿ’ฉ|โž•|๐Ÿ’ฏ| +|๐Ÿ’ฐ|๐Ÿ’ณ|๐Ÿ’ต|๐Ÿ’บ|๐Ÿ’ป|๐Ÿ’ผ|๐Ÿ“ˆ|๐Ÿ“œ|๐Ÿ“Œ|๐Ÿ“Ž|๐Ÿ“–|๐Ÿ“ฟ|๐Ÿ“ก|โฐ|๐Ÿ“ฑ|๐Ÿ“ท| +|๐Ÿ”‹|๐Ÿ”Œ|๐Ÿšฐ|๐Ÿ”‘|๐Ÿ””|๐Ÿ”ฅ|๐Ÿ”ฆ|๐Ÿ”ง|๐Ÿ”จ|๐Ÿ”ฉ|๐Ÿ”ช|๐Ÿ”ซ|๐Ÿ”ฌ|๐Ÿ”ญ|๐Ÿ”ฎ|๐Ÿ”ฑ| +|๐Ÿ—ฝ|๐Ÿ˜‚|๐Ÿ˜‡|๐Ÿ˜ˆ|๐Ÿค‘|๐Ÿ˜|๐Ÿ˜Ž|๐Ÿ˜ฑ|๐Ÿ˜ท|๐Ÿคข|๐Ÿ‘|๐Ÿ‘ถ|๐Ÿš€|๐Ÿš|๐Ÿš‚|๐Ÿšš| +|๐Ÿš‘|๐Ÿš’|๐Ÿš“|๐Ÿ›ต|๐Ÿš—|๐Ÿšœ|๐Ÿšข|๐Ÿšฆ|๐Ÿšง|๐Ÿšจ|๐Ÿšช|๐Ÿšซ|๐Ÿšฒ|๐Ÿšฝ|๐Ÿšฟ|๐Ÿงฒ| + + +These emojis are selected to ensure: + +* Exclusion of similar-looking emojis to avoid confusion. +* Only the "base" emoji are considered; modified emojis (e.g., skin tones, gender modifiers) are excluded. +* Match emoji's used by Yat. + +Each byte is encoded using the emoji listed at the corresponding index. + +## Change Log + +| Date | Change | Author | +|:-------------|:-------------------------|:--------------| +| 2024-05-31 | Initial stable | SWvHeerden | + +[Communication Node]: Glossary.md#communication-node +[Node ID]: Glossary.md#node-id \ No newline at end of file diff --git a/src/RFC-0152_EmojiId.md b/src/RFCD-0152_EmojiId.md similarity index 100% rename from src/RFC-0152_EmojiId.md rename to src/RFCD-0152_EmojiId.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 7868939..b1d3daf 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -11,7 +11,7 @@ - [RFC-0132: Merge Mining Monero](RFC-0132_Merge_Mining_Monero.md) - [RFC-0140: Synchronizing the Blockchain: Archival and Pruned modes](RFC-0140_Syncing_and_seeding.md) - [RFC-0150: Wallets](RFC-0150_Wallets.md) - - [RFC-0152: Emoji ID](RFC-0152_EmojiId.md) + - [RFC-0155: TariAddress](RFC-0155_TariAddress.md) - [RFC-0160: Block Binary Serialization](RFC-0160_BlockSerialization.md) - [RFC-0170: Network Communication Protocol](RFC-0170_NetworkCommunicationProtocol.md) - [RFC-0171: Message Serialisation](RFC-0171_MessageSerialisation.md) @@ -61,6 +61,7 @@ - [RFC-0010: Tari code structure and organization](RFCD-0010_CodeStructure.md) - [RFC-0121: Consensus encoding](RFCD-0121_ConsensusEncoding.md) - [RFC-0130: Mining](RFCD-0130_Mining.md) + - [RFCD-0152: Emoji ID](RFCD-0152_EmojiId.md) - [RFC-0180: Bulletproof range proof rewinding](RFCD-0180_BulletproofRewinding.md) - [RFC-0300: The Digital Assets Network](RFCD-0300_DAN.md) - [RFC-0301: Namespace Registration](RFCD-0301_NamespaceRegistration.md)