Seraphis Address Schemes

[UkoeHB]

Seraphis Address Schemes

Seraphis is not compatible with CryptoNote addressing, due to a different key image design compared to CryptoNote. However, it is compatible with a variety of interesting addressing schemes. In this issue I'd like to present those schemes, so discussion can have a point of reference.

To implement Seraphis in Monero, or another existing CryptoNote-derived cryptocurrency, it would be necessary for all users to generate new public addresses from their private keys (old public addresses would become unusable). They would not need new wallets, just addresses.

The Schemes

Here are the adddress scheme variants. The 'tiers' are levels of wallet permissions. A Tier 3 wallet can always do everything, while a Tier 2 wallet can never spend funds. A 3-key address would be ~50% longer than existing addresses. Note that 'Janus' refers to the ability to detect a Janus attack.

Type	Tier 1	Tier 2 (+ Tier 1)	Tier 3 (+ Tiers 1 & 2)	Address Size (#keys)
Plain A	none	view received	spend, view spent	2
Plain B	view received	view spent	spend	2
Plain C	none	view received, view spent	spend	2
Plain D	compute view tags	view received, view spent	spend	3
Janus A	view received, Janus	view spent	spend	3
Janus B	view received (no amounts)	view amounts, view spent, Janus	spend	3
Janus C	view received (no amounts), view spent	view amounts, Janus	spend	3
Janus D	none	view received, view spent, Janus	spend	3
Janus E	compute view tags	view received, view spent, Janus	spend	4

• Plain A is functionally equivalent to CryptoNote (however, users would still need new public addresses). The biggest weakness of this scheme is needing Tier 3 to identify spent outputs, which leads to the annoying 'export key images' UX for multisig and hardware wallets.
• 'Plain' variants can mitigate Janus using Tier 1 if data is added to output/transaction memos (one 16-byte encrypted txout private key nonce per output).
• 'Janus' variants mitigate Janus by adding an extra key to addresses. Conveniently, adding this extra key allows more diverse addressing schemes (as shown in the table).
• 'View amounts' generically means 'decrypt messages stored in output memos'. This includes amounts and any miscellaneous encrypted memos that might be stored in memos.
• (@tevador on the 'compute view tags' variants): A Tier 1 wallet would only be able to identify a 2^-T blockchain subset that contains all of the wallet's actual outputs (here T is the size of the view tag). This would preserve more privacy when using an external scanning service at the cost of more computation for the client to filter out the false positive outputs. The size of the view tag T should be selected as a compromise between anonymity and the amount of data to be downloaded.
  • With all other variants, 'compute view tags' and 'view received' are the same.

Finally, I want to point out that Tier 2 always (except for Plain A) has 'full-view' authority. The main difference between schemes lies in Tier 1 capabilities.

P.S.

Moving to a new address scheme means it is possible to deprecate normal addresses entirely (i.e. only use subaddresses). This would allow a uniform address format, which would improve UX. Users could use their 'index 0' subaddress in place of their current normal address (or some similar convention).

Deprecating normal addresses is not required, it is just an option to consider.

[LocalMonero]

Unifying to just one type of address should be a design goal. The UX and DX gets exponentially worse with each additional address type.

[rbrunner7]

Regarding Janus, do I read this correctly: The question is whether we judge the Janus attack to be serious enough to merit even longer addresses than today, as a sensible choice?

[UkoeHB]

Regarding Janus, do I read this correctly: The question is whether we judge the Janus attack to be serious enough to merit even longer addresses than today, as a sensible choice?

Yes, but part of the question is also if we want one of the Janus address schemes, due to their basic utility compared to plain schemes (I think Janus B and C are big improvements, since they allow third party scanning without leaking amounts).

[rbrunner7]

Yes, but part of the question is also if we want one of the Janus address schemes, due to their basic utility compared to plain schemes (I think Janus B and C are big improvements, since they allow third party scanning without leaking amounts).

Thanks, I indeed overlooked the "amounts visible or hidden" dimension until now. Interesting.

[boogerlad]

For Janus C Tier 1, "view received (no amounts), view spent" does that mean spent amounts are visible?

[UkoeHB]

For Janus C Tier 1, "view received (no amounts), view spent" does that mean spent amounts are visible?

No... view spent just means 'view what outputs have been spent' (i.e. compute key images for received outputs to check if they exist in the ledger).

[boogerlad]

As you said, Janus B and C allow for third party scanning without leaking amounts, which I think makes services like MyMonero way more useful. What would the UX differences be between B and C? As in, in what situation would it be useful for services like MyMonero to know which outputs are spent and presumably when they are spent?

[UkoeHB]

What would the UX differences be between B and C? As in, in what situation would it be useful for services like MyMonero to know which outputs are spent and presumably when they are spent?

If a scanning service can identify spent outputs, then your personal wallet doesn't have to do any scanning. However, this has privacy costs, since the service will learn more information about your transaction flows (i.e. if the service became large enough, then it could basically eliminate the utility of ring signatures).

[UkoeHB]

If a scanning service can identify spent outputs, then your personal wallet doesn't have to do any scanning. However, this has privacy costs, since the service will learn more information about your transaction flows (i.e. if the service became large enough, then it could basically eliminate the utility of ring signatures).

On the other hand (I forgot...), a scanning service that can see all your received outputs can also infer most/all of your spent outputs. The reason is, most/all of the transactions you make will A) have 1+ of your owned outputs in each input's ring members, B) send a change output to you.

Since a scanning service can identify most spent outputs, Janus C might be simply better than Janus B. With Janus B, identifying spent outputs with Tier 1 is not reliable enough to be provided as a feature of a scanning service, but it is reliable enough to degrade privacy. With Janus C, the UX of scanning improves, while the privacy costs stay the same.

Caveat: If membership proofs referenced the entire ledger, instead of a small ring, then inferring spent outputs would not work as well (if at all). Since achieving membership proofs on that level is a big goal of privacy-coin research, a 'forward-looking' designer might favor Janus B over Janus C. This way, if ideal membership proofs are ever implemented, the privacy dynamic around scanning is optimized.

[tevador]

I haven't studied Seraphis in detail, but I'm wondering if there could also be another option:

Type	Tier 1	Tier 2 (+ Tier 1)	Tier 3 (+ Tiers 1 & 2)	Address Size (#keys)
Plain D/Janus E	view tag	view received, view spent, Janus(?)	spend	3

A Tier 1 wallet would only be able to identify a 2-T blockchain subset that contains all of the wallet's actual outputs (here T is the size of the view tag in bits). This would preserve more privacy when using an external scanning service at the cost of more computation for the client to filter out the false positive outputs. The size of the view tag T should be selected as a compromise between privacy and the amount of data to be downloaded.

I put a question mark next to Janus because I'm not sure if this scheme can also mitigate Janus without some additional TX data.

[UkoeHB]

@tevador yes I think it is possible. I will add this to the table. It would cost +1 in the address size compared to other schemes.

[chaserene]

Is it possible to devise an addresses scheme that won't have to be changed for a long time, e.g. not even with further ring size increases like Arcturus? Requiring everyone who wants to receive to generate a new address is a big pain point, breaking numerous use cases, both known and unknown.

[UkoeHB]

Is it possible to devise an addresses scheme that won't have to be changed for a long time, e.g. not even with further ring size increases like Arcturus? Requiring everyone who wants to receive to generate a new address is a big pain point, breaking numerous use cases, both known and unknown.

Why would any of the above schemes need to be changed, once implemented?

[chaserene]

@UkoeHB I don't know in advance. I'm following the logic that van Saberhagen didn't expect it either that it will need to be changed.

[UkoeHB]

@UkoeHB I don't know in advance. I'm following the logic that van Saberhagen didn't expect it either that it will need to be changed.

Likewise, there is no way for any of us to know in advance what the future will bring.

That being said, Seraphis is designed so membership proofs (e.g. ring signatures) are almost entirely independent of addressing. You can easily change the membership proof type without risking changes to the address scheme. In that sense, Seraphis is far more robust against address changes than CryptoNote.

[xxmeta]

I think Janus detection should be a priority.

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

I lean towards Janus A.

[UkoeHB]

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

@xxmeta I think it is unlikely we can prevent people from offering scanning services without completely unifying all three wallet tiers. Why do you favor Janus A over Janus B/C? Janus B's Tier 1 is significantly weaker than Janus A's Tier 1, and I think Tier 1 is what scanning services would use.

[xxmeta]

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

@xxmeta I think it is unlikely we can prevent people from offering scanning services without completely unifying all three wallet tiers. Why do you favor Janus A over Janus B/C? Janus B's Tier 1 is significantly weaker than Janus A's Tier 1, and I think Tier 1 is what scanning services would use.

I agree with you now about the 3rd party service risk. In light of that, Janus A & B are similar to me. I think the Janus attack can still be practically applied if users use a Tier1 key for fast sync times, so maybe I prefer Janus A for that reason, but the choice is not obvious.

Janus C is less useful I think. I can see many uses for a Tier 1 key that can't view spends, but Janus C doesn't allow that.

[r4v3r23]

@UkoeHB continuing the offline-tx discussion from gitlab:

so Serpahis view-only wallets would eliminate the need to import key images and cut the process down to 3 steps?

1. create transaction on view-only wallet

2. sign tx on offline device

3. broadcast signed tx from online device

[UkoeHB]

@r4v3r23 yes that sounds right to me. 1 -> 2 and 2 -> 3 require communication passes to and then from the offline device.

[r4v3r23]

@r4v3r23 yes that sounds right to me. 1 -> 2 and 2 -> 3 require communication passes to and then from the offline device.

yes Seraphis simplifies the process so that it can be done easily between mobile devices via QR codes

[tevador]

There is no doubt that Seraphis will bring quite large user-facing changes regardless of which exact addressing scheme is used. It may be worthwhile to take this opportunity to rethink the paradigm and move away from addresses completely.

I understand that this might be too radical and it's unlikely to be implemented in Monero, but I'm going to discribe it anyways in case someone cares.

I will preface this with an explaination why addresses are bad, then I will present an alternative and describe how it works from the user's point of view. The cryptographic details are at the end.

The original vision

Satoshi Nakamoto originally thought of addresses as "account numbers" and they were meant to be handled and compared by humans directly (see this comment in Bitcoin 0.1). This was also the reason why Bitcoin addresses were 160-bit hashes - to be as short as possible. A typical v1 Bitcoin address is 34 characters long, which is coincidentally the maximum length an IBAN can have.

Problems of addresses

Nowadays cryptocurrencies are not used just by enthusiasts and the inherited paradigm of base58-encoded account numbers is, in my opinion, a UX nightmare. Especially for Monero, the original vision clearly fails. 100+ character strings encoding 2-3 public keys can hardly be considered as identifiers anymore.

I'd wager that the vast majority of crypto transfers involve copy pasting meaningless strings without any feedback to the user. The main issues of this are:

1. Security. Using humans to verify and pass around cryptographic material is just about the worst option. One of the common attacks involves clipboard address swapping malware.
2. Susceptibility to mistakes. People send funds to the wrong address all the time. This is also the primary reason why integrated addresses are still popular and many people are against deprecating them.
3. Addresses lack context. From a UX standpoint, the public keys only make sense when bundled with an amount, a human-readable name an a reason to pay. The terms "address" and "address book" imply that they are some sort of identifiers, which is wrong. Addresses are meant for a single use.

OpenAlias is not the answer

Someone might argue that OpenAlias is a working alternative to addresses. However, I don't think it can solve the problem for several reasons:

• Not all Monero users can or are willing to register a domain name.
• Putting the whole Monero address into a DNS record is a security issue. If the TXT record is compromised, funds can be redirected to a different address without the sender noticing anything.
• Using OpenAlias leaks information through the DNS system. Whenever an OpenAlias domain name is resolved, an eavesdropper can learn that a particular IP address might be transacting with a particular Monero address.
• OpenAlias is not practical for merchants that need to provide different payment information to every customer. In fact, I've only seen OpenAlias being used for donations and nothing else.

Possible solution

Everytime a Monero address is shared, there is an implicit expectation of a payment. It may either be a donation without a specific amount and specific sender, or an exact amount as a payment for goods or services. The payee is clearly defined in both cases.

Therefore we can replace addresses with payment requests. A payment request encapsulates all the information the payer's software needs to complete the payment:

1. Version field
2. One or more public keys
3. Payment amount (optional)
4. The recipient's email address or domain name (optional)
5. Payment description (optional)
6. Signature of the above fields with a key tied to the recipient's identity

The main difference from the existing Monero payment url scheme is that each payment request is authenticated with a signature.

The way a payment request is transferred to the wallet software can be entirely opaque to the user. There is no need to examine or compare any cryptographic information (with a single exception described in the next section).

Here are some ways how the actual data transfer can happen:

1. Scanning a QR code
2. Clicking a URL with a custom scheme handler
3. Direct HTTP request
4. Manually copying an ASCII-armored string (for text-only protocols)
5. Manually downloading a file from a website/email attachment

All of these can easily support transferring a few hundred bytes needed for a payment request.

Authenticating the recipient

Once the payment request reaches the payer's wallet software, there are 4 options:

1. The payee's authentication key is already stored in the sender's address book. The signature can be verified directly.
2. The payee has a website. In that case, the authentication key can be downloaded from a DNS TXT record. Note that unlike OpenAlias, a compromised TXT record doesn't lead to a loss of funds.
3. The sender and the receiver are communicating through an onion service. Then the onion public key can be used as the authentication key.
4. The payee's authentication key must be verified manually by the sender. This should be done out-of-band and involves comparing short strings that look like this: QP4RJ-HIT6W-Z99R1-YFQPP-6PC1Y.

If the signature of the payment request matches, the user interface should display a prominent symbol, like a check mark: ✔. This is the same paradigm as the padlock symbol for HTTPS and is familiar to users.

(As a side note, the signature also helps with dispute resolution. The current payment proofs cannot resolve the case when Bob claims the address Alice made a payment to is not his.)

User stories

Online shopping

1. Charlie buys goods on shop.example.com for the first time.
2. At checkout, he scans a QR code.
3. A prompt is displayed: "You are paying 10 XMR to shop.example.com (verified ✔). Press OK to continue."
4. Charlie presses OK and enters the wallet password.
5. The payment is done.

Donation

1. Dave wants to donate to a CCS request as he usually does.
2. He clicks a "donate" button in the CCS request and is redirected to his wallet software.
3. A prompt is displayed: "You are transacting with Monero CCS (verified ✔). The payment is for Atomic swaps XMR/BTC. Please enter an amount to pay."
4. Dave enters an amount, confirms and enters the wallet password.
5. The payment is done.

Paying a friend

1. Frank wants to repay a debt to his friend John.
2. He receives a payment request from John via email and drag-and-drops the email attachment into his wallet software.
3. A prompt is displayed: "You are transacting with [email protected] for the first time. Please use an out-of-band communication channel and let them verify that this is their identity: QP4RJ-HIT6W-Z99R1-YFQPP-6PC1Y."
4. Frank calls John to confirm that the identity code is his and adds him into his address book.
5. Frank confirms the payment and enters his wallet password.
6. The payment is done.

Paying an anonymous user

1. Victor buys some goods from an anonymous online vendor via an onion service.
2. The seller provides him with a payment request, which Victor pastes into his wallet software.
3. A prompt is displayed: "You are paying 5 XMR to example3s7zyrievebrzkactalswnhakbpkazjz2ccimxcfqck52pgyd.onion (verified ✔). Press OK to continue."
4. Victor presses OK and enters the wallet password.
5. The payment is done.

Under the hood

This "address-less" scheme is compatible with Seraphis and behaves similar to the "Janus D" option with an extra Tier 1 capability:

Type	Tier 1	Tier 2 (+ Tier 1)	Tier 3 (+ Tiers 1 & 2)	Address Size (#keys)
Janus X	generate payment requests	view received, view spent, Janus	spend	3

Wallet

A wallet is defined by two private keys ks (private spend key), kv (private view key). These can be derived as usual from a mnemonic seed.

There is an associated public spend key Ks = kv X + ks U, where X and U are generators.

Accounts

Each wallet can support up to 2⁶⁴ different identities, here called "accounts".

Each account index i has a private authentication key kai = H(Tident, kv, i). Note that generating authentication keys requires the private view key kv.

The associated public authentication key Kai = kai G is used to verify payment request signatures.

Each account has one public view key Kvi = kv Kai.

Payment requests

Each account can generate up to 2⁶⁴ different payments requests. Each payment request is defined by two indices i and j, where i is the account index and j is the payment index.

The payment request contains the following two public keys:

• Ksi, j = H(Tpayreq, kai, j) X + Ks (spend key)
• Kvi (view key)

Note that the second key doesn't depend on the index j.

Additionally, each payment request contains a Schnorr signature (R, s) where:

• R = r G
• s = r + kai * H(Tsig, R, m), where m is the serialized payment request (the above two public keys and optional metadata).

Sending funds

The sender, when presented with a payment request, first needs to recover the public authentication key Kai. There are four ways to do that:

1. Lookup the key in the address book (either by payee's name or by the key Kvi).
2. Lookup the key in a DNS TXT record (if interacting via a domain name).
3. Decode the key from the onion address (if interacting via an onion service).
4. Recover the key from the Schnorr signature: Kai = H(Tsig, R, m)-1 (s G - R)

In the last case, the key should be validated manually. The validation code is simply H(Tval, Kai) truncated to 120 bits and encoded in Base32 with a Reed-Solomon checksum digit that ensures two validation codes differ in at least 2 characters.

The output is constructed as follows:

1. A random scalar t is generated.
2. The sender-receiver shared secret is: q = H(Tderiv, t Kvi)
3. The one-time output key is: K = H(Tkey, q) X + Ksi, j
4. The output public key is: Q = t Kai
5. The output blinding factor is constructed as C = H(Tblind, q, t G) G + b H

Receiving funds

1. Calculate nominal sender-receiver shared secret: q = H(Tderiv, kv Q)
2. Calculate the nominal spend key Ksi, j = K - H(Tkey, q) X
3. If Ksi, j belongs to this wallet, look up the associated private authentication key kai.
4. Calculate C = H(Tblind, q, (1 / kai) Q) G + b H. If it doesn't match the output commitment, this is a Janus attack.

Wallet tiers

Tier 1 wallet for account i knows the public keys Ks, Kvi and the private key kai. This wallet tier is suitable to be used at the point-of-sale as it can generate and sign payment requests on demand.

Tier 2 wallet knows the public key Ks and the private key kv. This wallet tier can generate new accounts and can see the total wallet balance.

Tier 3 knows both private keys ks and kv and can spend the money in the wallet.

Payment IDs

Payment IDs are not needed in this protocol and can be removed entirely. This protocol can simulate both of the currently used payment schemes in Monero:

1. Integrated addresses are used by merchants to identify payments and provide assurance to customers. This can be achieved by using a long-term account and generating a new payment request for each customer.
2. Subaddresses are used where the recipient doesn't want their online activities linked together by a third party. This can be achieved by using a new account for each online purchase and only using payment requests with j=0.

A combination of these two approaches is also possible.

Edits:

• added an onion verification option as suggested by @LocalMonero
• fixed the calculation of the public spend key to match the Janus D address scheme

[fluffypony]

@tevador I like payment requests, but if LN has taught us anything its that people want both payment requests AND a short, offline string they can pass around (lnurl). Is there anything fundamental in Seraphis that prevents both?

[UkoeHB]

@fluffypony it is possible to do both afaict. It is just a hassle from the implementation side, the more bulky the address scheme gets.

[fluffypony]

@UkoeHB can't be much more cumbersome than 95-character long Monero addresses, or 100+ character long integrated addresses;)

[Mikerah]

@tevador The main issue I see with passing around URLs is the increase risks of phishing attacks. The crypto space has spent a lot of resources and a lot of money lost to learn lessons in that URLs are not the best way to authorize funds moving from wallet to wallet. There has to be some way for a user to ensure that 1) they are sending the funds to the correct recipient and 2) that the recipient can check that they are indeed receiving the right funds from the correct sender.

[LocalMonero]

@tevador a few questions for you:

1. Could you please provide an example on how a payment URL would look like?
2. What about deposits to exchanges, where the amount is open-ended? Requiring the user to input ahead of time how much coins they wish to deposit is a UX nightmare.
3. Which part of the wallet do you expect to implement the DNS record calls?
4. Is relying on DNS for the green checkmark a good idea, given the centralized nature of the control structure over domain names, where states can seize domains essentially at will? Not to mention DNS poisoning in censored jurisdictions like China, where the Chinese government can essentially change the DNS TXT records to whatever they like for whichever domain they like. This isn't going to be limited to China in the future, as the trends indicate.
5. If DNS is no longer considered, is the manual code verification really that different from checking the address? Especially taking into consideration most people just check the first few and last few characters of an address.

[tevador]

@tevador I like payment requests, but if LN has taught us anything its that people want both payment requests AND a short, offline string they can pass around (lnurl). Is there anything fundamental in Seraphis that prevents both?

A bare payment request can also be passed around as a string and would not be significantly longer than a Seraphis-Janus address (~1 scalar longer).

The main issue I see with passing around URLs is the increase risks of phishing attacks.

Which URLs are you referring to?

Could you please provide an example on how a payment URL would look like?

There would not be a payment URL, at least not a human readable one because there is no need for that. QR codes can directly encode binary data and a clickable URL can look something like this: <a href="monero://M_UcZTqiEIsdlaTuJjpeze3Dx1rgxBf-E44gAH5gVM0HthU1xddkJtuHfbNgI-gOUhE6hlNPPijgN6-PIFEZJEe0dHokdvsvaJbqXgETg0ocEiL8zdYDA382S65UsTPrNmLZVLS_G_f7ZXTB1fU01K2dWLS428RTQNbSeJ8vUuQmCrrMYj3CHOb5IU2opFgirxzW0IoOvNuDB2hJQ6vxS5TKau8ofOv2gHxusTmJvrrl4J7d">PAY HERE</a>. The user will just see a "PAY HERE" button.

What about deposits to exchanges, where the amount is open-ended? Requiring the user to input ahead of time how much coins they wish to deposit is a UX nightmare.

That's why the amount is an optional field of the payment request. The only required fields are the 2 public keys and the signature.

Which part of the wallet do you expect to implement the DNS record calls?

That's not relevant to this protocol. AFAIK wallet2 currently implements DNS requests to support OpenAlias.

Is relying on DNS for the green checkmark a good idea, given the centralized nature of the control structure over domain names, where states can seize domains essentially at will? Not to mention DNS poisoning in censored jurisdictions like China, where the Chinese government can essentially change the DNS TXT records to whatever they like for whichever domain they like. This isn't going to be limited to China in the future, as the trends indicate.

There is DNSSEC, which should be a requirement for the green check mark. The idea was that the DNS verification would be used mainly for online shopping when you are already using DNS to access the website.

If DNS is no longer considered, is the manual code verification really that different from checking the address? Especially taking into consideration most people just check the first few and last few characters of an address.

The 25-character uppercase string is much easier to verify than a 95-character case-sensitive one*. Moreover, this verification would only be done once for each party you transact with. It's the same as when you import a GPG key for the first time.

* Currently, there can be valid addresses that differ just in 1 character, for example (spot the difference): 42zDXTDfErPYQDtZGE1JejQ5TsziFp5ep45afwzmjn9hAYxHUzJ5dBZ3udPZsMaQXbRFfBzBZv4CL7CGRfu17scNKXfFtiF 42zDXTDfErPYQDtZGE1JejQ5TsziFp5ep45afwzmjx9hAYxHUzJ5dBZ3udPZsMaQXbRFfBzBZv4CL7CGRfu17scNKXfFtiF

[LocalMonero]

There is DNSSEC, which should be a requirement for the green check mark. The idea was that the DNS verification would be used mainly for online shopping when you are already using DNS to access the website.

DNSSEC is a nightmare, a lot of registrars don't implement it or implement it poorly, and you haven't addressed the other DNS concerns.

The 25-character uppercase string is much easier to verify than a 95-character case-sensitive one

Again, nobody checks the whole 95 chars. People check the first few and last few. The example you gave of 1 char diff is an edge case that will essentially never occur in reality. Checking it once as opposed to every time is a benefit, though.

@tevador you should consider coming up with a different automatic green check mechanism that doesn't rely on DNS, or at least not just on DNS.

[Gingeropolous]

im all for a radical re-think :) . I can't comment directly on the technicals, but having to use DNS gives me the heebie-jeebies.

But yeah, with the possibility that seraphis address schemes will create even larger text strings than we have now, it'd be great if we could come up with something different.

it'd be cool if you could publish something to the blockchain that would function to do something, yeah, u bloat the chain a bit...