Duration of the "two transaction formats allowed" hardfork transition phase

[rbrunner7]

Maybe it's a bit early to discuss things concerning the hardfork to Seraphis and Jamtis, which is of course quite far out, but I think it may still be useful for aspects that may influence early on how we best implement and/or plan things.

If the format of transactions changes Monero hardforks usually take place as two hardforks in rapid succession: After the first one, both transaction formats "old" and "new" are allowed, after the second one only the "new" one. The idea is to make sure no already submitted transactions get lost. After all, when the first block with the first hardfork height gets mined there may be still old-format transaction waiting in the pool, and we want to remain able to process those, at least for a transition phase.

There also may be some transactions still "on the way", e.g. with cold signing, or multisig transactions.

For the last 2 or 3 hardforks the duration of the transition time was merely a single day.

What do we aim for regarding the transition phase between CLSAG transactions and Seraphis/Jamtis transactions?

You could argue that this transition is much more radical than the "usual" Monero hardforks, and because of this it's a good idea to make the phase much longer, maybe even weeks, to give the whole Monero "ecosystem" more time to adjust.

Such a long phase has pros and cons however.

Just one possible positive aspect: The first hardfork that enables Seraphis transactions can be a very strong wake-up call to "laggards" in the ecosystem that did not yet add support for Seraphis. After this call we won't just throw them off the network, but give them a grace period of a few weeks to finally get their act together.

Just one possible negative aspect: The introduction of new addresses for every existing wallet, and all newly created wallets anyway, is probably already quite a challenge for Monero users. If during a long transition phase one part of them is still only reachable under their "old" address (because they did not yet switch to a Seraphis-supporting wallet and can't receive "new" transactions yet), and the other part is only reachable with "new" addresses, this might heighten the confusion, and complicate the transition instead of making it easier.

[UkoeHB]

There might not be too many steps between the current seraphis library and supporting the construction of legacy txs. The seraphis lib already has legacy balance recovery and the ability to make CLSAGs (but not pre-ringct ring sigs for legacy enotes with cleartext amounts; in seraphis those are spent in CLSAGs but in the current protocol they are not). So, it is theoretically possible to have a seraphis wallet that can make legacy txs, and then delete all that code after it is fully deprecated.

One problem with that approach is the 'split balance' UX issue, because only legacy enotes can be spent in legacy txs. So a seraphis wallet that is making seraphis txs will see its available legacy balance decline.

[rbrunner7]

One problem with that approach is the 'split balance' UX issue, because only legacy enotes can be spent in legacy txs. So a seraphis wallet that is making seraphis txs will see its available legacy balance decline.

Yes. I had a small insight about this recently, and maybe it helps people thinking about it: With a long period where both legacy and Seraphis transactions are supported, it's like a blockchain that supports two coins simultaneously.

[Rucknium]

Not having given it a whole lot of thought, I think about 1 week of grace period would be a good compromise.

A major difference between the Seraphis hard fork and previous hard forks is that the address format will change. With previous hard forks, if a user used fully updated software, they might not have even realized that a hard fork had happened. With Seraphis, a user has to transmit or receive an alternative address. There can be a long time lag between transmitting the address and the construction of the transaction.

Having two transaction formats can diminish privacy by creating two user pools. I don't think we should let that grace period extend too long. By the way, I don't see how the beginning of the grace period sends any explicit warning to any non-updated services. Their transactions would continue to work until the end of the grace period.

Most important is better communication with Monero ecosystem entities. The role of @plowsof or similar could be useful here.