Now, if you restore a wallet from seed, you loose destination addresses for your outgoing transactions, because those are not recorded in the blockchain in a way that allows recovery

I guess that's still the same for Seraphis?

If yes, would there a way to improve that does not make transactions at least 32 bytes bigger per output (the destination address encrypted with some key under control of the wallet)?

Guess not, but I think can't do harm by asking :)

Maybe that question is connected to the "return address" feature that was discussed once?

<rbrunner> "If yes, would there a way to..." <- I have been thinking a lot about it lately too. My answer now is that we cannot do much better than the current system. If you want to save the outgoing data, you have to do it locally and take care of it yourself. All the other possibilities like storing more data on the blockchain just for having the possibility to recover this information later or having deterministic

transaction keys (or deterministic ka_sender in seraphis terms) that you could rebuild the one-time-address if you suspect from an address, seem to be the wrong way to go. I guess we could do small improvements wallet-wise by exporting/importing only the transaction information to build transaction proofs if necessary but again all of that has to be managed locally.

Well, I would not say strictly the *wrong* way to go, because maybe it's not about right or wrong, but more about "Is it worth it?", about trade-offs between the added feature and bigger blockchain.

If I remember correctly that also was the argument not to introduce return addresses: Making each and every transaction bigger for a feature that will get used only very few times is not a good idea

But good that you are looking into this, dangerousfreedom, it would be a pity to miss a simple way to improve if there was one if we anyway turn everything on its head by introducing Seraphis

<dangerousfreedom> "I have been thinking a lot about..." <- I agree with this take.