From ca933464620c480bcc439705b27652dcf9a6896b Mon Sep 17 00:00:00 2001 From: SW van Heerden Date: Fri, 31 May 2024 15:46:22 +0200 Subject: [PATCH 1/3] depricate emoji_id, and add tariaddress --- src/RFC-0155_TariAddress.md | 147 ++++++++++++++++++ ...C-0152_EmojiId.md => RFCD-0152_EmojiId.md} | 0 src/SUMMARY.md | 3 +- 3 files changed, 149 insertions(+), 1 deletion(-) create mode 100644 src/RFC-0155_TariAddress.md rename src/{RFC-0152_EmojiId.md => RFCD-0152_EmojiId.md} (100%) diff --git a/src/RFC-0155_TariAddress.md b/src/RFC-0155_TariAddress.md new file mode 100644 index 0000000..14a7cda --- /dev/null +++ b/src/RFC-0155_TariAddress.md @@ -0,0 +1,147 @@ +# 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 describes the specification for Tari Address. Tari Addresses are encoded wallet addresses used to verify wallet addresses, features and networks. +This address should have human readable network and features identification. It should contain all information required to send transactions to a wallet owning an address. + +## Related Requests for Comment + +None + +## Description + +Tari [Communication Node]s are identified on the network via their [Node ID]; which in turn are derived from the node's +public key. Both the node id and public key are simple large integer numbers. The communication private key should be kept +private by the node at all times to ensure that a node cannot be spoofed. + +The most common practice for human beings to copy large numbers in cryptocurrency software is scanning a QR code or copying and pasting a value from one application to another. These numbers are typically encoded using hexadecimal or Base58 +encoding. The user will then typically scan (parts) of the string by eye to ensure that the value was transferred +correctly. + +For Tari, we propose encoding values, the node ID in particular and masking the network identifier, for Tari, using emojis. The advantages of this approach are: + +* Emoji are more easily identifiable; and, if selected carefully, less prone to identification errors (e.g., mistaking an + O for a 0). +* The alphabet can be considerably larger than hexadecimal (16) or Base58 (58), resulting in shorter character sequences + in the encoding. +* Should be be able to detect if the address used belongs to the correct network. +## The specification + +### Emoji map +An emoji alphabet of 256 characters is selected. Each emoji is assigned a unique index from 0 to 255 inclusive. The +list of selected emojis is: + +| | | | | | | | | | | | | | | | | +|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| +|๐Ÿฆ‹|๐Ÿ“Ÿ|๐ŸŒˆ|๐ŸŒŠ|๐ŸŽฏ|๐Ÿ‹|๐ŸŒ™|๐Ÿค”|๐ŸŒ•|โญ|๐ŸŽ‹|๐ŸŒฐ|๐ŸŒด|๐ŸŒต|๐ŸŒฒ|๐ŸŒธ| +|๐ŸŒน|๐ŸŒป|๐ŸŒฝ|๐Ÿ€|๐Ÿ|๐Ÿ„|๐Ÿฅ‘|๐Ÿ†|๐Ÿ‡|๐Ÿˆ|๐Ÿ‰|๐ŸŠ|๐Ÿ‹|๐ŸŒ|๐Ÿ|๐ŸŽ| +|๐Ÿ|๐Ÿ‘|๐Ÿ’|๐Ÿ“|๐Ÿ”|๐Ÿ•|๐Ÿ—|๐Ÿš|๐Ÿž|๐ŸŸ|๐Ÿฅ|๐Ÿฃ|๐Ÿฆ|๐Ÿฉ|๐Ÿช|๐Ÿซ| +|๐Ÿฌ|๐Ÿญ|๐Ÿฏ|๐Ÿฅ|๐Ÿณ|๐Ÿฅ„|๐Ÿต|๐Ÿถ|๐Ÿท|๐Ÿธ|๐Ÿพ|๐Ÿบ|๐Ÿผ|๐ŸŽ€|๐ŸŽ|๐ŸŽ‚| +|๐ŸŽƒ|๐Ÿค–|๐ŸŽˆ|๐ŸŽ‰|๐ŸŽ’|๐ŸŽ“|๐ŸŽ |๐ŸŽก|๐ŸŽข|๐ŸŽฃ|๐ŸŽค|๐ŸŽฅ|๐ŸŽง|๐ŸŽจ|๐ŸŽฉ|๐ŸŽช| +|๐ŸŽฌ|๐ŸŽญ|๐ŸŽฎ|๐ŸŽฐ|๐ŸŽฑ|๐ŸŽฒ|๐ŸŽณ|๐ŸŽต|๐ŸŽท|๐ŸŽธ|๐ŸŽน|๐ŸŽบ|๐ŸŽป|๐ŸŽผ|๐ŸŽฝ|๐ŸŽพ| +|๐ŸŽฟ|๐Ÿ€|๐Ÿ|๐Ÿ†|๐Ÿˆ|โšฝ|๐Ÿ |๐Ÿฅ|๐Ÿฆ|๐Ÿญ|๐Ÿฐ|๐Ÿ€|๐Ÿ‰|๐ŸŠ|๐ŸŒ|๐Ÿ| +|๐Ÿฆ|๐Ÿ|๐Ÿ‘|๐Ÿ”|๐Ÿ™ˆ|๐Ÿ—|๐Ÿ˜|๐Ÿ™|๐Ÿš|๐Ÿ›|๐Ÿœ|๐Ÿ|๐Ÿž|๐Ÿข|๐Ÿฃ|๐Ÿจ| +|๐Ÿฆ€|๐Ÿช|๐Ÿฌ|๐Ÿญ|๐Ÿฎ|๐Ÿฏ|๐Ÿฐ|๐Ÿฆ†|๐Ÿฆ‚|๐Ÿด|๐Ÿต|๐Ÿถ|๐Ÿท|๐Ÿธ|๐Ÿบ|๐Ÿป| +|๐Ÿผ|๐Ÿฝ|๐Ÿพ|๐Ÿ‘€|๐Ÿ‘…|๐Ÿ‘‘|๐Ÿ‘’|๐Ÿงข|๐Ÿ’…|๐Ÿ‘•|๐Ÿ‘–|๐Ÿ‘—|๐Ÿ‘˜|๐Ÿ‘™|๐Ÿ’ƒ|๐Ÿ‘›| +|๐Ÿ‘ž|๐Ÿ‘Ÿ|๐Ÿ‘ |๐ŸฅŠ|๐Ÿ‘ข|๐Ÿ‘ฃ|๐Ÿคก|๐Ÿ‘ป|๐Ÿ‘ฝ|๐Ÿ‘พ|๐Ÿค |๐Ÿ‘ƒ|๐Ÿ’„|๐Ÿ’ˆ|๐Ÿ’‰|๐Ÿ’Š| +|๐Ÿ’‹|๐Ÿ‘‚|๐Ÿ’|๐Ÿ’Ž|๐Ÿ’|๐Ÿ’”|๐Ÿ”’|๐Ÿงฉ|๐Ÿ’ก|๐Ÿ’ฃ|๐Ÿ’ค|๐Ÿ’ฆ|๐Ÿ’จ|๐Ÿ’ฉ|โž•|๐Ÿ’ฏ| +|๐Ÿ’ฐ|๐Ÿ’ณ|๐Ÿ’ต|๐Ÿ’บ|๐Ÿ’ป|๐Ÿ’ผ|๐Ÿ“ˆ|๐Ÿ“œ|๐Ÿ“Œ|๐Ÿ“Ž|๐Ÿ“–|๐Ÿ“ฟ|๐Ÿ“ก|โฐ|๐Ÿ“ฑ|๐Ÿ“ท| +|๐Ÿ”‹|๐Ÿ”Œ|๐Ÿšฐ|๐Ÿ”‘|๐Ÿ””|๐Ÿ”ฅ|๐Ÿ”ฆ|๐Ÿ”ง|๐Ÿ”จ|๐Ÿ”ฉ|๐Ÿ”ช|๐Ÿ”ซ|๐Ÿ”ฌ|๐Ÿ”ญ|๐Ÿ”ฎ|๐Ÿ”ฑ| +|๐Ÿ—ฝ|๐Ÿ˜‚|๐Ÿ˜‡|๐Ÿ˜ˆ|๐Ÿค‘|๐Ÿ˜|๐Ÿ˜Ž|๐Ÿ˜ฑ|๐Ÿ˜ท|๐Ÿคข|๐Ÿ‘|๐Ÿ‘ถ|๐Ÿš€|๐Ÿš|๐Ÿš‚|๐Ÿšš| +|๐Ÿš‘|๐Ÿš’|๐Ÿš“|๐Ÿ›ต|๐Ÿš—|๐Ÿšœ|๐Ÿšข|๐Ÿšฆ|๐Ÿšง|๐Ÿšจ|๐Ÿšช|๐Ÿšซ|๐Ÿšฒ|๐Ÿšฝ|๐Ÿšฟ|๐Ÿงฒ| + + + +The emoji have been selected such that: +* Similar-looking emoji are excluded from the map. For example, neither ๐Ÿ˜ or ๐Ÿ˜„ should be included. Similarly, the Irish and + Cรดte d'Ivoire flags look very similar, and both should be excluded. +* Modified emoji (skin tones, gender modifiers) are excluded. Only the "base" emoji are considered. + +The selection of an alphabet with 256 symbols means there is a direct mapping between bytes and emoji. + +### Encoding + + The emoji ID is calculated from a node public key `B` (serialized as 32 bytes) and a network identifier `N` (serialized as 8 bits) as follows: + +* Use the [DammSum](https://github.com/cypherstack/dammsum) algorithm with `k = 8` and `m = 32` to compute an 8-bit checksum `C` using `B` as input. +* Compute the masked checksum `C' = C XOR N`. +* Encode `B` into an emoji string using the emoji map. +* Encode `C'` into an emoji character using the emoji map. +* Concatenate `B` and `C'` as the emoji ID. + +The result is 33 emoji characters. + +### Decoding + +The node public key is obtained from an emoji ID and a network identifier `N` (serialized to 8 bits) as follows: + +* Assert that the emoji ID contains exactly 33 valid emoji characters from the emoji alphabet. If not, return an error. +* Decode the emoji ID as an emoji string by mapping each emoji character to a byte value using the emoji map, producing +33 bytes. Let `B` be the first 32 bytes and `C'` be the last byte. +* Compute the unmasked checksum `C = C' XOR N`. +* Use the DammSum validation algorithm on `B` to assert that `C` is the correct checksum. If not, return an error. +* Attempt to deserialize `B` as a public key. If this fails, return an error. If it succeeds, return the public key. + +#### Checksum effectiveness +It is important to note that masking the checksum reduces its effectiveness. +Namely, if an emoji ID is presented with a different network identifier, and if there is a transmission error, it is possible for the result to decode in a seemingly valid way with a valid checksum after unmasking. +If both conditions occur randomly, the likelihood of this occurring is `n / 256` for `n` possible network identifiers. + +Since emoji ID will typically be copied digitally and therefore not particularly subject to transmission errors, so it seems unlikely for these conditions to coincide in practice. + +## Change Log + +| Date | Change | Author | +|:-------------|:-------------------------|:--------------| +| 2022-11-10 | Initial stable | SWvHeerden | +| 2022-11-11 | Algorithm improvements | AaronFeickert | + +[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) From b5716e02c9cb38434c604760ba0cd585149ac3d3 Mon Sep 17 00:00:00 2001 From: SW van Heerden Date: Mon, 3 Jun 2024 08:28:29 +0200 Subject: [PATCH 2/3] add 155 --- src/RFC-0155_TariAddress.md | 97 ++++++++++++++++++++++++------------- 1 file changed, 62 insertions(+), 35 deletions(-) diff --git a/src/RFC-0155_TariAddress.md b/src/RFC-0155_TariAddress.md index 14a7cda..dbe5da9 100644 --- a/src/RFC-0155_TariAddress.md +++ b/src/RFC-0155_TariAddress.md @@ -57,10 +57,26 @@ None ## Description -Tari [Communication Node]s are identified on the network via their [Node ID]; which in turn are derived from the node's -public key. Both the node id and public key are simple large integer numbers. The communication private key should be kept +Wallet addresses should give all the information necessary to send transactions to the wallet who's address it is. To start of a wallet needs to advertise its features that it supports as +well as what network it on. To keep this human readable, we need independent identifiers for both the features and the network. + +For normal interactive MW transactions it would need a public key to communicate to. The private key of this MUST be kept hidden by the node at all times to ensure that a node cannot be +spoofed. Because this needs to be kept hidden we can use this as a spend key to derive the actual spend key for the UTXO. + +As soon as we want to send non-interactive transactions, things get a bit more complicated. If the receiving wallet is a normal wallet it has access to all the nessasary +information required to spend the transaction. But if the receiving wallet contains a Hardware device such as a ledger, the wallet cannot know the spending information, +this introduces the need for a secondary view key. The wallet can give out the private key of this to another party to view the UTXOs. But this key cannot be used +to spend the UTXO. + +We can also enclude a checksum to detect errors when we encode this as bytes. This address can also be very easily encoded with emojis if we assign an emoji to each u8. + + +Tari [Communication Node]s are identified on the +network via their [Node ID]; which in turn are derived from the node's public key. Both the node id and public key are simple large integer numbers. The communication private key should be kept private by the node at all times to ensure that a node cannot be spoofed. + + The most common practice for human beings to copy large numbers in cryptocurrency software is scanning a QR code or copying and pasting a value from one application to another. These numbers are typically encoded using hexadecimal or Base58 encoding. The user will then typically scan (parts) of the string by eye to ensure that the value was transferred correctly. @@ -74,7 +90,48 @@ For Tari, we propose encoding values, the node ID in particular and masking the * Should be be able to detect if the address used belongs to the correct network. ## The specification -### Emoji map +### Address + +Each address is divided into 4 parts: View key, Spend key, Network and Features. + +#### View key +This is the key used by node to provide view access to its transactions. An entity possessing the private key of this key pair SHOULD be able to view all transactions +a wallet has made. + +#### Spend key +This is the key used to calculate the spend key of a UTXO and communicate to the node over the network. This private key of this key pair SHOULD be kept +secure and hidden at all costs. + +#### Features +This is used to indicate features that the wallet supports or not supports. At current this is only used to indicate if the wallet supports interactive and or one-sided transactions. +This is an encoded u8 with each bit indicating a feature. + +#### Network +This is the Tari network the wallet is on, for example: Esmeralda, Nextnet etc. + +#### Checksum +We only include the checksum when encoding the address as bytes, hex or emojis. For the checksum, we use: [DammSum](https://github.com/cypherstack/dammsum) algorithm with `k = 8` and `m = 32` to compute an 8-bit checksum. + +### Encoding + +#### Bytes +When creating a byte representation of the wallet, the following is used: +[0] - Network encoded into u8 +[1] - Features raw u8 +[2..33] - Public view key encoded as u8 +[35..65] - Public spend key encoded as u8 +[66] - DammSum checksum + +For nodes that do not have a view key, the view key and spend key is treated as being the same, their addresses can be encoded as follows: +[0] - Network encoded into u8 +[1] - Features raw u8 +[2..33] - Public spend key encoded as u8 +[34] - DammSum checksum + +#### Hex +Encode each byte in the byte representation as two hex characters. + +#### Emoji encoding An emoji alphabet of 256 characters is selected. Each emoji is assigned a unique index from 0 to 255 inclusive. The list of selected emojis is: @@ -104,44 +161,14 @@ The emoji have been selected such that: Cรดte d'Ivoire flags look very similar, and both should be excluded. * Modified emoji (skin tones, gender modifiers) are excluded. Only the "base" emoji are considered. -The selection of an alphabet with 256 symbols means there is a direct mapping between bytes and emoji. - -### Encoding - - The emoji ID is calculated from a node public key `B` (serialized as 32 bytes) and a network identifier `N` (serialized as 8 bits) as follows: - -* Use the [DammSum](https://github.com/cypherstack/dammsum) algorithm with `k = 8` and `m = 32` to compute an 8-bit checksum `C` using `B` as input. -* Compute the masked checksum `C' = C XOR N`. -* Encode `B` into an emoji string using the emoji map. -* Encode `C'` into an emoji character using the emoji map. -* Concatenate `B` and `C'` as the emoji ID. - -The result is 33 emoji characters. - -### Decoding - -The node public key is obtained from an emoji ID and a network identifier `N` (serialized to 8 bits) as follows: - -* Assert that the emoji ID contains exactly 33 valid emoji characters from the emoji alphabet. If not, return an error. -* Decode the emoji ID as an emoji string by mapping each emoji character to a byte value using the emoji map, producing -33 bytes. Let `B` be the first 32 bytes and `C'` be the last byte. -* Compute the unmasked checksum `C = C' XOR N`. -* Use the DammSum validation algorithm on `B` to assert that `C` is the correct checksum. If not, return an error. -* Attempt to deserialize `B` as a public key. If this fails, return an error. If it succeeds, return the public key. - -#### Checksum effectiveness -It is important to note that masking the checksum reduces its effectiveness. -Namely, if an emoji ID is presented with a different network identifier, and if there is a transmission error, it is possible for the result to decode in a seemingly valid way with a valid checksum after unmasking. -If both conditions occur randomly, the likelihood of this occurring is `n / 256` for `n` possible network identifiers. +Encode each byte as emoji listed in the corresponding index -Since emoji ID will typically be copied digitally and therefore not particularly subject to transmission errors, so it seems unlikely for these conditions to coincide in practice. ## Change Log | Date | Change | Author | |:-------------|:-------------------------|:--------------| -| 2022-11-10 | Initial stable | SWvHeerden | -| 2022-11-11 | Algorithm improvements | AaronFeickert | +| 2024-05-31 | Initial stable | SWvHeerden | [Communication Node]: Glossary.md#communication-node [Node ID]: Glossary.md#node-id \ No newline at end of file From 58be0c2f94714a12de6268bcd9a453ef13efc946 Mon Sep 17 00:00:00 2001 From: SW van Heerden Date: Mon, 3 Jun 2024 08:47:06 +0200 Subject: [PATCH 3/3] edits --- src/RFC-0155_TariAddress.md | 100 ++++++++++++++---------------------- 1 file changed, 38 insertions(+), 62 deletions(-) diff --git a/src/RFC-0155_TariAddress.md b/src/RFC-0155_TariAddress.md index dbe5da9..2b82b6c 100644 --- a/src/RFC-0155_TariAddress.md +++ b/src/RFC-0155_TariAddress.md @@ -48,92 +48,69 @@ technological merits of the potential system outlined herein. ## Goals -This document describes the specification for Tari Address. Tari Addresses are encoded wallet addresses used to verify wallet addresses, features and networks. -This address should have human readable network and features identification. It should contain all information required to send transactions to a wallet owning an address. +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. -Wallet addresses should give all the information necessary to send transactions to the wallet who's address it is. To start of a wallet needs to advertise its features that it supports as -well as what network it on. To keep this human readable, we need independent identifiers 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). -For normal interactive MW transactions it would need a public key to communicate to. The private key of this MUST be kept hidden by the node at all times to ensure that a node cannot be -spoofed. Because this needs to be kept hidden we can use this as a spend key to derive the actual spend key for the 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. -As soon as we want to send non-interactive transactions, things get a bit more complicated. If the receiving wallet is a normal wallet it has access to all the nessasary -information required to spend the transaction. But if the receiving wallet contains a Hardware device such as a ledger, the wallet cannot know the spending information, -this introduces the need for a secondary view key. The wallet can give out the private key of this to another party to view the UTXOs. But this key cannot be used -to spend the UTXO. +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. -We can also enclude a checksum to detect errors when we encode this as bytes. This address can also be very easily encoded with emojis if we assign an emoji to each u8. - - -Tari [Communication Node]s are identified on the -network via their [Node ID]; which in turn are derived from the node's public key. Both the node id and public key are simple large integer numbers. The communication private key should be kept -private by the node at all times to ensure that a node cannot be spoofed. - - - -The most common practice for human beings to copy large numbers in cryptocurrency software is scanning a QR code or copying and pasting a value from one application to another. These numbers are typically encoded using hexadecimal or Base58 -encoding. The user will then typically scan (parts) of the string by eye to ensure that the value was transferred -correctly. - -For Tari, we propose encoding values, the node ID in particular and masking the network identifier, for Tari, using emojis. The advantages of this approach are: - -* Emoji are more easily identifiable; and, if selected carefully, less prone to identification errors (e.g., mistaking an - O for a 0). -* The alphabet can be considerably larger than hexadecimal (16) or Base58 (58), resulting in shorter character sequences - in the encoding. -* Should be be able to detect if the address used belongs to the correct network. ## The specification ### Address -Each address is divided into 4 parts: View key, Spend key, Network and Features. +Each address consists of four parts: View key, Spend key, Network, and Features. #### View key -This is the key used by node to provide view access to its transactions. An entity possessing the private key of this key pair SHOULD be able to view all transactions -a wallet has made. +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 -This is the key used to calculate the spend key of a UTXO and communicate to the node over the network. This private key of this key pair SHOULD be kept -secure and hidden at all costs. +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 -This is used to indicate features that the wallet supports or not supports. At current this is only used to indicate if the wallet supports interactive and or one-sided transactions. -This is an encoded u8 with each bit indicating a feature. +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 -This is the Tari network the wallet is on, for example: Esmeralda, Nextnet etc. +Specifies the Tari network the wallet operates on, e.g., Esmeralda, Nextnet, etc. #### Checksum -We only include the checksum when encoding the address as bytes, hex or emojis. For the checksum, we use: [DammSum](https://github.com/cypherstack/dammsum) algorithm with `k = 8` and `m = 32` to compute an 8-bit 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 creating a byte representation of the wallet, the following is used: -[0] - Network encoded into u8 -[1] - Features raw u8 -[2..33] - Public view key encoded as u8 -[35..65] - Public spend key encoded as u8 -[66] - DammSum checksum - -For nodes that do not have a view key, the view key and spend key is treated as being the same, their addresses can be encoded as follows: -[0] - Network encoded into u8 -[1] - Features raw u8 -[2..33] - Public spend key encoded as u8 -[34] - DammSum checksum +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 -Encode each byte in the byte representation as two hex characters. +Each byte in the byte representation is encoded as two hexadecimal characters. -#### Emoji encoding -An emoji alphabet of 256 characters is selected. Each emoji is assigned a unique index from 0 to 255 inclusive. The -list of selected emojis is: +#### 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: | | | | | | | | | | | | | | | | | |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| @@ -155,14 +132,13 @@ list of selected emojis is: |๐Ÿš‘|๐Ÿš’|๐Ÿš“|๐Ÿ›ต|๐Ÿš—|๐Ÿšœ|๐Ÿšข|๐Ÿšฆ|๐Ÿšง|๐Ÿšจ|๐Ÿšช|๐Ÿšซ|๐Ÿšฒ|๐Ÿšฝ|๐Ÿšฟ|๐Ÿงฒ| +These emojis are selected to ensure: -The emoji have been selected such that: -* Similar-looking emoji are excluded from the map. For example, neither ๐Ÿ˜ or ๐Ÿ˜„ should be included. Similarly, the Irish and - Cรดte d'Ivoire flags look very similar, and both should be excluded. -* Modified emoji (skin tones, gender modifiers) are excluded. Only the "base" emoji are considered. - -Encode each byte as emoji listed in the corresponding index +* 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