UkoeHB
commented
1 year ago The first wallet would need only an update with hopefully quite modest internal modifications because it must be able to see which outputs it owns got spent by Seraphis transactions. If it doesn't to that, and continues to use all outputs for transaction building, even the ones already spent by Seraphis transactions, the network will reject those transactions as double-spend attempts.
In this case the user would see their balance decline in a confusing way, because seraphis change enotes would be invisible. An additional indicator or alert message would need to be displayed alongside balances recovered by wallet2.
Maybe, as a first since Monero exists, and despite it went successfully went through many hardforks already, the future hardfork to Seraphis and Jamtis may need a quite different approach for Monero wallet apps to support it. In this issue I try to write down what are the fundamental problems and describe a possible solution:
Technically, every time Monero hardforks, you get two cryptocurrencies that follow different rules: the "old" before the hardfork, and a "new" one that starts with the first new block in the chain after the hardfork.
So far the differences between those two distinct cryptocurrencies were never big enough to be a real problem for Monero wallet apps, all the more thanks to the fact that
wallet2implemented most of the differences for them already and became able to handle "old" and "new" coins alike.So it went without saying that if you used e.g. Cake Wallet or Monerujo as you wallet app, no fundamentally new app would be released when a hardfork approached, but mere updates to the app you already had. At no point in the process you would have two wallet apps installed side-by-side.
A first and not yet much detailed analysis of the situation with Seraphis and Jamtis lets me suspect the following: This approach, so far more or less taken for granted, may run into quite some difficulties.
Let's look at a single wallet app that is able to work with Monero as it is now, plus is able to continue to work in the transition phase where "old" and "new" transactions are supported alike, and finally switches to Seraphis-and-Jamtis-only after the network goes through the second hardfork. (See issue #22 about the mentioned transition period.)
Such continued operation during the whole time would need quite some support in the UI: First, the UI rejects Jamtis addresses. During the transition phase it allows to use both traditional and Jamtis addresses, and then finally only Jamtis addresses. Available balance during the transition period would depend on the address type used, and the UI would have to inform the user accordingly, because the supply of "old" coins would gradually decrease as more and more coins in the wallet would be Seraphis coins that you can't send to "old" addresses.
Maybe there would be more things needed in the UI that I could not yet recognize to allow seamless operation through it all. This is probably not trivial to implement.
Internally going for a single app also complicates matters considerably: Such an app would probably have to deal both with
wallet2and the new Seraphis and Jamtis wallet classes, both quite complex beasts all alone already.Currently the Seraphis library code supports scanning the blockchain for all types of outputs from ancient with amounts visible, all the RingCT based variants and finally Seraphis enotes. But it does not, or at least not yet, support creating CLSAG transactions. With this, creating transactions in a wallet app to old addresses during the transition phase has to use
wallet2, which may turn out to be quite a challenge technically, up to the question whether internally the app would even have to deal with two files per wallet for some time.This all leads me to the following question: Wouldn't it be better to avoid all this complexity and all these troubles by choosing a different approach this time? The approach would be to offer two distinct wallet apps where there is now only one.
So every Monero wallet app going for this approach would get a new Seraphis-and-Jamtis-only app that you could install alongside the first app. Before the hardfork to Seraphis it would basically work as a view-only wallet, able to scan the blockchain and telling you your balance, but not yet able to make any outgoing transactions. That would have to wait until Seraphis transactions get enabled on the network through the hardfork.
The first wallet would need only an update with hopefully quite modest internal modifications because it must be able to see which outputs it owns got spent by Seraphis transactions. If it doesn't to that, and continues to use all outputs for transaction building, even the ones already spent by Seraphis transactions, the network will reject those transactions as double-spend attempts.