Legacy knowledge proofs

[DangerousFreedom1984]

Hello, the knowledge proofs framework for legacy enotes still have to be implemented. I would like to discuss how it should be done. First, no new functionality will be added since these proofs will only be valid for one transaction, which is the transaction containing legacy enotes as inputs and seraphis enotes as outputs.

So the proofs that will apply for legacy enotes are:

SpentProof: -Remake pre-RingCT scheme with used inputs in a new message like we have today (the advantage of not using more complicated schemes like clsag or grootle is to keep it simple for version 1 and version 2 txs).

InProof: -Schnorr with address (similar as it is today)

OutProof: -Since we will have only Seraphis recipients allowed in wallet3 then the code is already implemented. (Sp Enote Ownership Proof) -During the transaction period wallet2 may be used to make Outproof if transactions for legacy addresses are allowed.

ReserveProof: -Similar scheme that we have today but has to be rewritten.

Any comments?

[UkoeHB]

these proofs will only be valid for one transaction, which is the transaction containing legacy enotes as inputs and seraphis enotes as outputs.

We also need to continue supporting old proof types, since old transaction history needs to be accessible through the new wallet.

[DangerousFreedom1984]

True. The verification function should be there but not the generation function. So we would have to copy the verify_* from wallet2 somehow

[UkoeHB]

The verification function should be there but not the generation function.

Generation is also needed. Users shouldn't suddenly be unable to make proofs about their past txs.

[DangerousFreedom1984]

Yes. But I was thinking about making the generation using the LegacyRecord and maybe changing something on these proofs but thinking better now then both functions should be rewritten in wallet3 but keep the same format and compatibility.

[DangerousFreedom1984]

I would like to talk about the wallet2 file that your current wallet generates in the context of the legacy proofs. Currently all the information that your wallet needs to generate the knowledge proofs is there. So I believe that are 3 scenarios (maybe more) to consider when we move to seraphis_wallet and want to make a legacy knowledge proof (a proof of v2 transactions - that happened before the seraphis hf):

1) Using wallet2 file

• If the wallet file is there, dont touch it. If it is not, create a new one in the wallet2 format using the wallet2_basic (jeffro api). Probably a 'wallet2_basic_scanner' should be built for this purpose. (I could do that, I think it would be useful).
• Use the wallet2 file to generate legacy proofs

2) Not using wallet2 file

• Rescan the blockchain to check owned legacy enotes and create legacy knowledge proofs from that.
• Not possible to create out_proof, see the addresses you sent to or retrieve other info since they are only in the wallet2 files.

3) Not using wallet2 file even if it exists.

• Import all the wallet2 info into a seraphis_wallet file and from there generate the knowledge proofs.
• Use the info imported from wallet2 to create the knowledge proofs.

I implemented scenario 1 as it seems safer (less information is lost) and it is easier to integrate. See example.

Notice that you would only need to generate/verify these proofs for transactions that happened before the hard-fork. After the hardfork, I believe that people would most likely want to prove that a legacy enote (output) sent funds to a seraphis address. In this case the seraphis knowledge proofs could be used - seraphis sent_proof in this case. So this is out of the scope of this discussion.

[j-berman]

Option 3 is the ideal long-term route I think. I picture the wallet flow to be something like:

• Open wallet
• If wallet2 cache and keys files exist:
  • Migrate into new Seraphis lib class structure
• Else:
  • Use new Seraphis lib class structure
• Construct legacy knowledge proofs entirely from Seraphis lib class structure

This way we don't have to consider edge case circumstances like the wallet2 cache is scanned up to block X and X is < Seraphis hard fork. Plus we'll need the Seraphis legacy scanner to pick up everything needed for the legacy proofs anyway when restoring. This seems the cleanest route to totally deprecating wallet2.cpp/.h.