If it was easy ...

This may be a very dumb question, but could Seraphis with both types of address formats be deployed to allow a transitional period?

And then phase out "legacy" address format in a later hard fork?

As addresses aren't published on-chain there isn't a fungibility issue unless the formats affect it some other way I'm not aware of.

I guess not? Because the old format would not have the information required by the new format, so it would not be able to build a transaction

Otherwise you wouldn't need a change in format

(Right?)

Yeah if the old format could be supported easily then I wouldn’t bother recommending a new format.

Well, I had a new idea that could make it work - less efficient than Triptych even under the best assumptions though.

Thus the idea of both address formats at once for a transitional period, and then another fork to disable "legacy" addresses and gain all of the benefits of the new format. Is that a possibility?

Yes I think it can be done. There would be a period where the blockchain contains mixed output types, which may make node/wallet code a bit more complex.

Transactions would be indistinguishable on-chain still, correct? Just added complexity in the short-term for code.

No transactions would have two different input and output types, making them distinguishable.

Added my new idea for address compatibility to the Seraphis gist if anyone wants to look... Probably won't pursue it further, unless I decide to do a benchmark.

This idea reflects the versatility of Seraphis' approach to membership proofs.

UkoeHB: are you capable to write proofs for Seraphis or it will separate work for someone eles ?

* ... it will be ...

I will need help. Right now I don't think anyone has committed to doing so.

If someone writes it in python, I can convert to C++ and plug into monero, like I did for BP. I don't grok crypto near well enough to do it fully from paper though.

(as in, I'll fuck something up and not see it)

In ~1-2 months I would like to write my own C++ prototypes of the two Seraphis variants, at which time I can also write a prototype for the inefficient address-friendly scheme. The prototypes can be used for benchmarks to better inform discussions.

translation of cryptography into code is much easier task than mathematical proofs of the cryptography. Just to be clear, I was talking about math proofs for cryptogaphy, the work that surae and sarang did previously.

Yes I know. I responded to you, then to moneromooo

I have a preprint draft for Seraphis that is pretty well developed, but has no formal proofs.

Oh a new idea on address compatibility? Sweet

sarang revised again to fix some errors

Ah ok, thanks

FWIW having good protocol modularity (which is the case for designs like Seraphis and Spark) can certainly make protocol-level security analysis and proofs more straightforward, since you can often rely on security properties of protocol components

e.g. range proofs, one-of-many proofs, representation proofs

<UkoeHB> "I have a preprint draft for..." <- I would try to help on this (as much as I can).

Maybe I will make a github