Buy new address scheme, do you mean instituting a new kind of address other than the current 95 character one?

That is one possibility. The main thing is the address's public keys would be constructed different from how they are now, so all users would need to replace existing addresses.

UkoeHB: Do you plan to publish a pre-print of that scheme soon?

<selsta> "IMO one more required multisig..." <- I agree. However I the whole thing has at least 6 multisig rounds (based on instances of "sends" in Section 4 & 5 of Sarang's report: 4 "sends" in Section 4 + 2 "sends" in Section 5).

dEBRUYNE: only for Seraphis, but the adjustment would use the same ideas

Maybe I will add an Appendix or write an Addendum

is there any place that interested parties are tracking blocked hosts?

blocked hosts?

yes.

Yes.

Well, used to anyway. selsta did.

thanks

UkoeHB: The adjustment would not change the address format, correct/

?

right

UkoeHB: I see

When would you be able to publish this such that other researchers can review the scheme?

Actually I already sketched it at the bottom of my Seraphis gist: gist.github.com/UkoeHB/24f6be6125684046c5c4d9f49351bccf. It's probably unreadable though.

How would the lowercase-k terms be defined in the compatible-address version?

Same as current one-time addresses

Except maybe different domain separation for the sender-receiver secret

`k_{a, recipient}` would be the private view key

Now that I say that, I realize subaddresses are a problem.

bah

In subaddresses, your public view key is `k^v * K^{s,i}`. In other words, your 'subaddress private view key' is `k^v*k^{s,i}`. I think this means it is completely impossible to support both the current address format and subaddresses, without making multisig a PITA.

Protocol design feels like balancing 10 balls on top of each other. Sorry for the premature hype :)