<merope> "xmr-ack: why not run your own..." <- I did that originally and had it all set up but I didnt know if there would be any factors where the optimization would differ. Also I’m using Xmr2csv to export some transactional information quickly, I’ve never worked with C++ before and would need to recompile it to work with my local net.

<xmr-ack[m]> "I did that originally and had it..." <- You know what, you’re probably right. It will be easier to run my own net and then extract all the data using the monerion explorer

Interesting. So basically instead of doing a new ECDH for each transaction, the key exchange only happens at the first transaction and then you get a unique sequence of keys for each counterparty. The obvious privacy problem is that the recipient will know that the repeated payments are from the same sender.

tevador: can you take a look at the architecture diagram I linked above?

UkoeHB: looks good, maybe also add some interface for hardware wallets?

tevador: I was thinking hardware wallets can be a MasterKey implementation

although tbh I don't understand how hw wallets work currently

ah, that might also work with 3 MasterKey implementations: Polyseed, Legacy and HW

UkoeHB: what do you think about deterministic sender nonces?

OK, found an existing discussion monero-project/monero #6638

Guess I’d have to see a specific proposal

I think my last big task with seraphis (aside from finishing the paper) will be building a PoC for that wallet architecture, along with fairly extensive unit tests to demo everything. That PoC, along with the Seraphis library, should encompass most of the really hard work necessary to get Seraphis into Monero. The remaining work should be regular software engineering tasks like implementing interfaces, data storage and

transfer, etc. (i.e. no significant protocol or architecture design work).

I pushed a Jamtis update with some clarifications and incomplete test vectors (no merchant wallets yet)

I also changed the address signatures to be deterministic