Skip to content

Instantly share code, notes, and snippets.

@UkoeHB

UkoeHB/jamtis.md

Forked from tevador/jamtis.md
Created April 11, 2022 21:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save UkoeHB/16e1ccf54312010fd1bbfbb4483b4593 to your computer and use it in GitHub Desktop.
Save UkoeHB/16e1ccf54312010fd1bbfbb4483b4593 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
jamtis.md

JAMTIS

This document describes a new addressing scheme for Monero.

Chapters 1-2 are intended for general audience.

Chapters 3-7 contain technical specifications.

Table of Contents

1. Introduction

1.1 Why a new address format?

Sometime in 2023, Monero plans to adopt a new transaction protocol called Seraphis [1], which enables much larger ring sizes than the current RingCT protocol. However, due to a different key image construction, Seraphis is not compatible with CryptoNote addresses. This means that each user will need to generate a new set of addresses from their existing private keys. This provides a unique opportunity to vastly improve the addressing scheme used by Monero.

1.2 Current Monero addresses

The CryptoNote-based addressing scheme [2] currently used by Monero has several issues:

  1. Addresses are not suitable as human-readable identifiers because they are long and case-sensitive.
  2. View-only wallets need key images to be imported to detect spent outputs [3].
  3. Too much information about the wallet is leaked when scanning is delegated to a third party.
  4. Generating subaddresses requires view access to the wallet. This is why many merchants prefer integrated addresses [4].
  5. Addresses are susceptible to man-in-the-middle (MITM) attacks [5].
  6. Subaddresses that belong to the same wallet can be linked via the Janus attack [6].

1.3 Jamtis

Jamtis is a new addressing scheme that was developed specifically for Seraphis and tackles all of the shortcomings of CryptoNote addresses that were mentioned above. Additionally, Jamtis incorporates two other changes related to addresses to take advantage of this large upgrade opportunity:

  • A new 16-word mnemonic scheme called Polyseed [7] that will replace the legacy 25-word seed for new wallets.
  • The removal of integrated addresses and payment IDs [8].

2. Features

2.1 Address format

Jamtis addresses, when encoded as a string, start with the prefix xmr1 and typically consist of 181 characters. Example of an address: xmr1majob1977bw3ympyh2yxd7hjymrw8crc9kinodkm8d3wdu8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfnod5h7s49bfyji1936w19tyf396ypjo9n64runqjrxwp6k2s3phxwm6wrb5cob6c1ntrg2mugeocwdgnnr7u7bgknya9arksrj

There is no longer any "main address" - all Jamtis addresses are equivalent to a subaddress.

2.2 Recipient IDs

Jamtis introduces a short recipient identifier (RID) that can be calculated for every wallet and every address. RID consists of 25 alphanumeric characters that are separated by hyphens for better readability. The RID for the above address is regne-hwbna-u21gh-b54no-8x36q. Instead of comparing long addresses, users can compare the much shorter RID. RIDs are also suitable to be communicated via phone calls, text messages or handwriting to confirm a recipient's address. This allows the address itself to be transferred via an insecure channel.

2.3 Certified addresses

To protect from MITM attacks, Jamtis addresses can be optionally signed by the owner of the wallet. The main use cases are:

2.3.1 Identity verification

When Alice and Bob meet, Bob can write his RID on a piece of paper and give it to Alice. When Bob sends Alice an address in the future, Alice will know the address belongs to Bob because it is signed with a key that matches the RID Bob gave her.

2.3.2 Undeniable payments

When proving a payment [9], Alice can convince Charlie that the address she made a payment to belongs to Bob, because the address was signed by Bob's key. If the address were not signed, Bob could claim that the address is not his, but Alice's own address.

2.3.3 Online commerce

Dave runs an online shop at https://eshop.example.com. To assure his customers, he can create a special DNS record under the domain name eshop.example.com that validates his Monero public key and he can provide certified Monero addresses to all his customers. When shopping at Dave's website, Alice can feel safe to send her Monero to the provided address, because her wallet software will confirm that the address is owned by the domain eshop.example.com.

2.4 Light wallet scanning

Jamtis introduces new wallet tiers below view-only wallet. One of the new wallet tiers called "FindReceived" is intended for wallet-scanning and only has the ability to calculate view tags [10]. It cannot generate wallet addresses or decode output amounts.

View tags can be used to eliminate 99.6% of outputs that don't belong to the wallet. If provided with a list of wallet addresses, this tier can also link outputs to those addresses. Possible use cases are:

2.4.1 Wallet component

A wallet can have a "FindReceived" component that stays connected to the network at all times and filters out outputs in the blockchain. The full wallet can thus be synchronized at least 256x faster when it comes online (it only needs to check outputs with a matching view tag).

2.4.2 Third party services

If the "FindReceived" private key is provided to a 3rd party, it can preprocess the blockchain and provide a list of potential outputs. This reduces the amount of data that a light wallet has to download by a factor of at least 256. The third party will not learn which outputs actually belong to the wallet and will not see output amounts.

2.5 Wallet tiers for merchants

Jamtis introduces new wallet tiers that are useful for merchants.

2.5.1 Address generator

This tier is intended for merchant point-of-sale terminals. It can generate (and certify) addresses on demand, but otherwise has no access to the wallet (i.e. it cannot recognize any payments in the blockchain).

2.5.2 Payment validator

This wallet tier combines the Address generator tier with the ability to also view received payments (including amounts). It is intended for validating paid orders. It cannot see outgoing payments and received change.

2.6 Full view-only wallets

Jamtis supports full view-only wallets that can identify spent outputs (unlike legacy view-only wallets), so they can display the correct wallet balance and list all incoming and outgoing transactions.

2.7 Janus attack mitigation

Janus attack is a targeted attack that aims to determine if two addresses A, B belong to the same wallet. Janus outputs are crafted in such a way that they appear to the recipient as being received to the wallet address B, while secretly using a key from address A. If the recipient confirms the receipt of the payment, the sender learns that they own both addresses A and B.

Jamtis prevents this attack by allowing the recipient to recognize a Janus output.

2.8 Robust output detection

The detection of outputs received to current Monero subaddresses is based on a lookup table. This can sometimes cause the wallet to miss outputs that are received to subaddresses not present in the lookup table [16].

Jamtis addresses and outputs contain an encrypted address tag which enables a more robust output detection mechanism that does not rely on a lookup table and can reliably detect outputs sent to arbitrary wallet addresses.

3. Notation

3.1 Serialization

  1. Fixed-size integers are serialized in little endian byte order.
  2. Private keys are serialized as 256-bit integers.
  3. String constants are serialized in ASCII encoding and always include an implicit null byte at the end.
  4. Elliptic curve points are serialized as 256-bit integers, with the lower 255 bits being the y-coordinate of the point and the most significant bit being the parity of the x-coordinate.
  5. The function BytesToInt256(x) deserializes a 256-bit little-endian integer from a 32-byte input.
  6. The operator || concatenates the serialized representations of its inputs.
  7. The function Padb(x) outputs x || 0x00 || 0x00 || ... || 0x00 where the number of padding zero bytes is such that the total length of the output is a multiple of b bytes.

3.2 Hash functions

The function H(x) refers to the keccak-256 hash function. The following other functions based on H are used:

  1. H1(x) = H(x)[0] is hash function with an output length of 1 byte.
  2. H8(x) = H(x)[0:8] is hash function with an output length of 8 bytes.
  3. H16(x) = H(x)[0:16] is hash function with an output length of 16 bytes.
  4. Hs(x) = BytesToInt256(H(x)) mod ℓ refers to a "hash to scalar" function, where ℓ is a prime number.
  5. Hp(x) refers to an unspecified "hash to point" function, which outputs elliptic curve points.
  6. KeyDerive(k, x) = Hs(Pad136(k) || x) is a function to derive elliptic curve private keys.
  7. SecretDerive(k, x) = H(Pad136(k) || x) is a function to derive secret keys for symmetric cryptography.

3.3 Elliptic curve

This specification assumes the use of the ed25519 elliptic curve, which includes a cyclic subgroup 𝔾 of prime order ℓ = 2252 + 27742317777372353535851937790883648493.

  1. Uppercase letters usually refer to elements of 𝔾.
  2. Lowercase letters usually refer to elements of Zℓ (scalars).
  3. Scalar multiplication is denoted by a space between the scalar and the group element, e.g. K = k G.
  4. Scalar multiplication may be prepended with the number 8, which means that the point is also multiplied by the ed25519 cofactor to ensure the result belongs to the group 𝔾.

3.3.1 Base points

The following three base points are used:

Point Derivation Serialized (hex)
G generator of 𝔾 5866666666666666666666666666666666666666666666666666666666666666
U Hp("seraphis U") 126582dfc357b10ecb0ce0f12c26359f53c64d4900b7696c2c4b3f7dcab7f730
X Hp("seraphis X") 4017a126181c34b0774d590523a08346be4f42348eddd50eb7a441b571b2b613

3.4 Block cipher

The function BlockEnc(k, x) refers to the application of the Blowfish [11] permutation using the secret key k on the 64-bit little-endian integer x. The function BlockDec(k, x) refers to the application of the inverse permutation using the key k.

3.5 Recoverable signatures

In order to save space, certified addrfesses use a recoverable Schnorr signature scheme specified in this section as a set of two functions SignIdent and RecoverIdent.

3.5.1 SignIdent

This function accepts two parameters: a private key k and an abitrary octet string data.

  1. Select a deterministic nonce r = KeyDerive(k, data || "SignIdent nonce")
  2. Calculate R = r G
  3. Calculate e = Hs(R || data)
  4. Calculate s = (e-1*k - r) mod ℓ
  5. Return the tuple (R,s)

3.5.2 RecoverIdent

This function accepts two parameters: the signature tuple (R,s) and an abitrary octet string data.

  1. Calculate e = Hs(R || data)
  2. Calculate u = e*s mod ℓ
  3. Calculate K = u G + e R
  4. Return K

3.5.3 Security

If an adversary changes R or data, the resulting public key K will change unpredictably.

If an adversary replaces s with s' = (s + e-1*m) mod ℓ, the public key will change to K' = K + m G. For this reason, the private signing key k must never be constructed by adding an offset to an existing key.

3.6 Hash identifier

We define a HashIdent function that accepts an arbitrary octet string data and returns H16(data) encoded in base32 using the ID32 scheme [12].

4. Wallets

4.1 Wallet parameters

Each wallet consists of two main private keys and a timestamp:

Field Type Description
km private key wallet master key
kvb private key view-balance key
birthday timestamp date when the wallet was created

The master key km is required to spend money in the wallet and the view-balance key kvb provides full view-only access.

The birthday timestamp is important when restoring a wallet and determines the blockchain height where scanning for owned outputs should begin.

4.2 New wallets

4.2.1 Standard wallets

Standard Jamtis wallets are generated as a 16-word Polyseed mnemonic [7], which contains a secret seed value used to derive the wallet master key and also encodes the date when the wallet was created. The key kvb is derived from the master key.

Field Derivation
km BytesToInt256(polyseed_key) mod ℓ
kvb kvb = KeyDerive(km, "view-balance key")
birthday from Polyseed

4.2.2 Multisignature wallets

Multisignature wallets are generated in a setup ceremony, where all the signers collectively generate the wallet master key km and the view-balance key kvb.

Field Derivation
km setup ceremony
kvb setup ceremony
birthday setup ceremony

4.3 Migration of legacy wallets

Legacy pre-Seraphis wallets define two private keys:

  • private spend key ks
  • private view-key kv

4.3.1 Standard wallets

Legacy standard wallets can be migrated to the new scheme based on the following table:

Field Derivation
km km = ks
kvb kvb = KeyDerive(km, "view-balance key")
birthday entered manually

Legacy wallets cannot be migrated to Polyseed and will keep using the legacy 25-word seed.

4.3.2 Multisignature wallets

Legacy multisignature wallets can be migrated to the new scheme based on the following table:

Field Derivation
km km = ks
kvb kvb = kv
birthday entered manually

4.4 Additional keys

There are additional keys derived from kvb:

Key Name Derivation Used to
kga generate-address key kga = SecretDerive(kvb, "generate-address key") generate addresses
kfr find-received key kfr = KeyDerive(kvb, "find-received key") scan for received outputs
kid identify-wallet key kid = KeyDerive(kga, "identify-wallet key") certify addresses
ket encrypt-tag key ket = SecretDerive(kga, "encrypt-tag key") encrypt address tags

The keys kga and kfr separate the view access into two tiers. The first one provides the ability to derive all public addresses that belong to the wallet and the latter is used to calculate the sender-receiver shared secret when scanning for received outputs.

The key kga has two additional child keys kid and ket, which are used in different cryptographic algorithms when generating an address.

4.5 Key hierarchy

The following figure shows the overall hierarchy of wallet keys. Note that the relationship between km and kvb only applies to standard (non-multisignature) wallets.

key hierarchy

4.6 Wallet access tiers

Tier Knowledge Off-chain capabilities On-chain capabilities
AddrGen kga generate public addresses none
FindReceived kfr recognize all public wallet addresses eliminate 99.6% of non-owned outputs (up to § 5.3.5), link output to an address (except of change and self-spends)
ViewReceived kga, kfr all view all received except of change and self-spends (up to § 5.3.14)
ViewAll kvb all view all
Master km all all

4.6.1 Address generator (AddrGen)

This wallet tier can generate public addresses for the wallet. It doesn't provide any blockchain access.

4.6.2 Output scanning wallet (FindReceived)

Thanks to view tags, this tier can eliminate 99.6% of outputs that don't belong to the wallet. If provided with a list of wallet addresses, it can also link outputs to those addresses (but it cannot generate addresses on its own). This tier should provide a noticeable UX improvement with a limited impact on privacy. Possible use cases are:

  1. An always-online wallet component that filters out outputs in the blockchain. A higher-tier wallet can thus be synchronized 256x faster when it comes online.
  2. Third party scanning services. The service can preprocess the blockchain and provide a list of potential outputs with pre-calculated spend keys (up to § 5.2.4). This reduces the amount of data that a light wallet has to download by a factor of at least 256.

4.6.3 Payment validator (ViewReceived)

This level combines the tiers AddrGen and FindReceived and provides the wallet with the ability to see all incoming payments to the wallet, but cannot see any outgoing payments and change outputs. It can be used for payment processing or auditing purposes.

4.6.4 View-balance wallet (ViewAll)

This is a full view-only wallet than can see all incoming and outgoing payments (and thus can calculate the correct wallet balance).

4.6.5 Master wallet (Master)

This tier has full control of the wallet.

4.7 Wallet public keys

There are 3 global wallet public keys. These keys are not usually published.

Key Name Value
Ks wallet spend key Ks = kvb X + km U
Kid identify-wallet key Kid = kid G
Kfr find-received key Kfr = kfr G

The keys Ks and Kfr are required by lower wallet tiers.

For better UX when opening or restoring a wallet, the wallet is identified by HashIdent("Monero RID" || Kid).

5. Addresses

5.1 Address generation

Jamtis wallets can generate up to 256 different addresses. An address is identified by a 64-bit integer j with the most significant 8 bits set to zero.

Each Jamtis address consists of three public keys and an encrypted tag:

  • K1j = Ks + kxj X
  • K2j = kaj Kfr
  • K3j = kaj G
  • tj = BlockEnc(ket, j)

The private keys kaj and kxj are derived as follows:

Keys Name Derivation
kaj address keys kaj = KeyDerive(kga, "address key" || j)
kxj spend key extensions kxj = KeyDerive(kga, "key extension" || j)

All addresses contain 3 unique public keys and are thus unlinkable by default.

Wallet software MUST NOT generate addresses with j >= 256.

5.2 Sending to an address

When sending amount a to someone else's address (K1, K2, K3, t), the sender does the following:

  1. Generate a random nonzero scalar r from Zℓ.
  2. Calculate the ephemeral public key Ke = r K3
  3. Calculate the derived key Kd = 8*r K2
  4. Calculate the view tag v = H1("view tag", Kd)
  5. Calculate the shared secret q = Hs("sender-receiver secret", Kd)
  6. Encrypt the address tag t~ = t XOR H8("address tag", q)
  7. Derive a one-time output public key Ko = K1 + q X
  8. Calculate the blinding factor b = Hs("blind", q, r G)
  9. Encrypt the amount a~ = a XOR H8("amount", q, r G)
  10. Calculate the amount commitment C = b G + a H
  11. Output (Ke, v, t~, Ko, a~, C)

5.3 Receiving an output

The receiver does the following to examine a potential output (Ke, v, t~, Ko, a~, C):

  1. Calculate the nominal derived key Kd' = 8*kfr Ke
  2. Calculate the nominal view tag v' = H1("view tag", Kd')
  3. If v' != v, abort.
  4. Calculate the nominal shared secret q' = Hs("sender-receiver secret", Kd')
  5. Decrypt the nominal address tag t' = t~ XOR H8("address tag", q)
  6. Decrypt the nominal address index j' = BlockDec(ket, t')
  7. If j' >= 256, abort.
  8. Derive the address spend key K1j = Ks + kxj X
  9. If K1j != Ko - q' X, abort.
  10. Derive r' G = Ke / kaj
  11. Decrypt the nominal amount a'= a~ XOR H8("amount", q, r' G)
  12. Calculate the nominal blinding factor b' = Hs("blind", q, r' G)
  13. Calculate the nominal amount commitment C' = b' G + a' H
  14. If C' != C, abort (possible Janus attack).
  15. Calculate the partial private spend key ksp = kvb + kxj + q
  16. Derive the linking tag Kt = (Ks - kvb X) / ksp
  17. Set the boolean s to the spend status of the linking tag Kt
  18. Output the private values (a, b, j, ksp, s)

5.4 Change and self-spends

Change outputs and self-spends are special because the sender is the same as the receiver. There are heuristics that can be applied by lower wallet tiers to recognize when outputs are being spent based on the presence of outputs that send funds back to the wallet [13].

To protect from such attacks, the output construction and recognition is modified for change and self-spends.

5.4.1 Self-spend detection

When a wallet software is constructing a transaction to an address (K1, K2, K3, t), the following IsSelfSpend function MUST be called to detect self-spends:

  1. Decrypt the nominal address index j' = BlockDec(ket, t)
  2. If j' >= 256, return false.
  3. Derive the address spend key K1j = Ks + kxj X
  4. Return K1j == K1.

5.4.2 Output construction

  1. The shared secret from § 5.2.4 is calculated as q = DeriveKey(kvb, "self secret" || Ke)
  2. For change outputs, the encrypted address tag from § 5.2.6 is set to t~ = j XOR H8("address tag", q)
  3. For self-spends, the encrypted address tag from § 5.2.6 is set to t~ = (j + 256) XOR H8("address tag", q)
  4. The blinding factor from § 5.2.8 is calculated as b = Hs("blind", q)
  5. The encrypted amount from § 5.2.9 is calculated as a~ = a XOR H8("amount", q)

The distinction between change outputs and self-spends is done to preserve the transaction history (self-spends should be visible in the history, change outputs not).

5.4.3 Output recognition

Change outputs and self-spends can only be detected by wallet tiers ViewAll and Master because it requires the private key kvb. Whenever an output with a matching view tag is discovered in a transaction that spends a previous wallet output:

  1. Derive the nominal shared secret as q' = DeriveKey(kvb, "self secret" || Ke)
  2. Decrypt the nominal address index j' = t~ XOR H8("address tag", q')
  3. If j' >= 257, abort.
  4. If j >= 256, this may be a self-spend. Set j = j - 256. Otherwise this may be a change output.
  5. Derive the address spend key K1j = Ks + kxj X
  6. If K1j != Ko - q' X, abort.
  7. Decrypt the nominal amount a'= a~ XOR H8("amount", q)
  8. Calculate the nominal blinding factor b' = Hs("blind", q)
  9. Continue from § 5.3.13

5.5 Transaction size

Jamtis has a small impact on transaction size.

5.5.1 Transactions with 2 outputs

The size of 2-output transactions is increased by 8 bytes. The encrypted payment ID is removed, but the transaction needs two encrypted address tags t~ (one for the recipient and one for the change). Both outputs can use the same value of Ke.

5.5.2 Transactions with 3 or more outputs

Since there are no "main" addresses anymore, the TX_EXTRA_TAG_PUBKEY field can be removed from transactions with 3 or more outputs.

Instead, all transactions with 3 or more outputs will require one 40-byte tuple (Ke, t~) per output.

6. Address encoding

6.1 Address structure

An address has the following overall structure:

Field Size (bytes) Description
Header 6* human-readable address header (§ 6.2)
K1 32 address key 1
K2 32 address key 2
K3 32 address key 3
t 8 address tag
Signature 64 for certified addresses (§ 6.3)
Checksum 8* (§ 6.4)

* The header and the checksum are already encoded in base32

6.2 Address header

The address starts with a human-readable header, which has the following format consisting of 6 alphanumeric characters:

"xmr" <version char> <network type char> <address type char>

Unlike the rest of the address, the header is never encoded and is the same for both the binary and textual representations. The string is not null terminated.

The software decoding an address shall abort if the first 3 bytes are not 0x78 0x6d 0x72 ("xmr").

The "xmr" prefix serves as a disambiguation from legacy addresses that start with "4" or "8". Additionally, base58 strings that start with the character x are invalid due to overflow [14], so legacy Monero software can never accidentally decode a Jamtis address.

6.2.1 Version character

The version character is "1". The software decoding an address shall abort if a different character is encountered.

6.2.2 Network type

network char network type
"t" testnet
"s" stagenet
"m" mainnet

The software decoding an address shall abort if an invalid network character is encountered.

6.2.3 Address type

type char address type
"a" anonymous
"c" certified

The software decoding an address shall abort if an invalid address type character is encountered.

6.3 Signature

All Jamtis addresses are by default unlinkable to the wallet that created them. However, the owner of the wallet may optionally attach a signature that links the address to the wallet identity key Kid. The signature is present if the address type character in the address header is "c".

The signature field is encoded as:

(R,s) = SignIdent(kid, "Monero address signature" || Header || K1 || K2 || K3 || t)

When parsing a certified address, the wallet software can calculate the receiver's identity key as:

Kid = RecoverIdent((R,s), "Monero address signature" || Header || K1 || K2 || K3 || t)

6.4 Checksum

The purpose of the checksum is to detect accidental corruption of the address. The checksum consists of 8 characters and is calculated using a BCH code [15] with a degree-8 polynomial. The checksum can detect all errors affecting 4 or fewer characters and will fail to detect more errors with a chance of less than 1 in 1012. [TODO: Specify the BCH polynomial.]

6.5 Binary-to-text encoding

An address can be encoded into a string as follows:

address_string = header + base32(data) + checksum

where header is the 6-character human-readable header string (already in base32), data refers to the 3 address public keys, the address tag and the optional signature. The checksum is the 8-character checksum (already in base32). The base32 encoding uses the character set ybndrfg8ejkmcpqxot1uwis2a345h769.

6.5.1 Address length

Address type length
anonymous 181
certified 283

6.5.2 QR Codes

While the canonical form of an address is lower case, when encoding an address into a QR code, the address should be converted to upper case to take advantage of the more efficient alphanumeric encoding mode.

6.6 Recipient authentication

6.6.1 Recipient identifiers

Because addresses are bulky and opaque, Jamtis defines a concise, more human-friendly identifier for each address, called the Recipient identifier (RID). RIDs are calculated depednding on the address type:

Address type RID
anonymous HashIdent("Monero RID" || Header || K1 || K2 || K3 || t)
certified HashIdent("Monero RID" || Kid)

6.6.2 Validating an RID

There are 4 ways how an RID may be validated when sending to an address:

  1. It may be already present in the sender's address book.
  2. It may be entered manually by the user. In this case, it's best to obtain the RID from the receiver using a different communication channel than the one used to transfer the address.
  3. The user may enter a domain name (e.g. example.com) and the RID is validated by performing a TXT DNS lookup of a subdomain equal to the RID (e.g. regne-hwbna-u21gh-b54no-8x36q.example.com). [TODO: Specify the contents of the TXT field.]
  4. The user may enter an onion address and the public key is decoded from the onion address (v3 onion addresses encode an ed25519 public key that's also usable in Monero) and compared to the address public key.

6.6.3 Authentication workflow

When sending to an address, wallet software should follow this authentication workflow:

  1. The address is parsed and verified that it's well-formed.
  2. The RID is calculated.
  3. If the RID is present in the local address book, the recipient's name is loaded and displayed with a green check mark. Skip to step 8.
  4. The user is presented with a "recipient validation dialog", where they are asked to enter an RID or a domain name.
  5. If the address RID matches the one that was entered or obtained via DNS or the onion domain, the RID is displayed as validated with a yellow check mark. Skip to step 7.
  6. If the RID doesn't match the address, no DNS record was found or the user dismisses the dialog, the RID is displayed with a red cross mark as "unverified".
  7. The user is asked to enter the remaining payment parameters.

7. Test vectors

TODO

References

  1. https://github.com/UkoeHB/Seraphis
  2. https://bytecoin.org/old/whitepaper.pdf
  3. https://www.getmonero.org/resources/user-guides/view_only.html
  4. monero-project/meta#299 (comment)
  5. https://www.reddit.com/r/Monero/comments/mcvuxc/beware_crypto_stealing_malware/
  6. https://web.getmonero.org/2019/10/18/subaddress-janus.html
  7. https://github.com/tevador/polyseed
  8. monero-project/monero#7889
  9. https://www.getmonero.org/resources/user-guides/prove-payment.html
  10. monero-project/research-lab#73
  11. https://en.wikipedia.org/wiki/Blowfish_(cipher)
  12. https://github.com/tevador/id32
  13. https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4006358
  14. https://github.com/monero-project/monero/blob/319b831e65437f1c8e5ff4b4cb9be03f091f6fc6/src/common/base58.cpp#L157
  15. https://en.wikipedia.org/wiki/BCH_code
  16. monero-project/monero#8138
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment