06:02:13 <Inge> If it was easy ...
11:28:19 <sethsimmons> This may be a very dumb question, but could Seraphis with both types of address formats be deployed to allow a transitional period?
11:29:10 <sethsimmons> And then phase out "legacy" address format in a later hard fork?
11:29:10 <sethsimmons> 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.
11:44:36 <merope> 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 
11:44:45 <merope> Otherwise you wouldn't need a change in format 
11:44:49 <merope> (Right?)
11:53:22 <UkoeHB> Yeah if the old format could be supported easily then I wouldn’t bother recommending a new format.
11:54:01 <UkoeHB> Well, I had a new idea that could make it work - less efficient than Triptych even under the best assumptions though.
12:08:22 <sethsimmons> 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?
12:14:50 <UkoeHB> 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.
12:42:11 <sethsimmons> Transactions would be indistinguishable on-chain still, correct? Just added complexity in the short-term for code.
12:48:36 <UkoeHB> No transactions would have two different input and output types, making them distinguishable.
14:26:31 <UkoeHB> 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.
14:29:07 <UkoeHB> This idea reflects the versatility of Seraphis' approach to membership proofs.
14:30:11 <wfaressuissia> UkoeHB: are you capable to write proofs for Seraphis or it will separate work for someone eles ?
14:36:19 <wfaressuissia> * ... it will be ...
14:36:29 <UkoeHB> I will need help. Right now I don't think anyone has committed to doing so.
14:37:19 <moneromooo> 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.
14:37:37 <moneromooo> (as in, I'll fuck something up and not see it)
14:40:51 <UkoeHB> 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.
14:42:49 <wfaressuissia> 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.
14:43:11 <UkoeHB> Yes I know. I responded to you, then to moneromooo
14:43:57 <UkoeHB> I have a preprint draft for Seraphis that is pretty well developed, but has no formal proofs.
14:57:09 <sarang> Oh a new idea on address compatibility? Sweet
15:27:12 <UkoeHB> sarang revised again to fix some errors
15:27:43 <sarang> Ah ok, thanks
15:38:24 <sarang> 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
15:38:36 <sarang> e.g. range proofs, one-of-many proofs, representation proofs
19:21:59 <coinstudent2048[> <UkoeHB> "I have a preprint draft for..." <- I would try to help on this (as much as I can).
19:25:19 <UkoeHB> Maybe I will make a github