View Keys and Payment Proves

[mobias17]

The following Issue and its individual points refer mostly to section 6 View Keys and Payment Proves of the paper “Lelantus Spark: Secure and Flexible Private Transactions” . It seems that the implementation is not complete and/or not documented enough. Apologies for the parts which are indeed implemented and not found by me.

Let’s maybe dissect the parts along a user story.

Alice has a charity organization and sells for the good cause paintings in her. She decides for Firo to receive anonymous donations and also so that painting buyers can shop without revealing to her their full wealth. Further Alice has chosen Firo Spark, as it comes with the incoming view key and the full view key.

She wants to make public the donation amounts she received for her charity with the incoming view key as it

“is used in Identify operations to determine when a coin is directed to an associated public address, and to determine the coin’s value and associated memo data. This permits two use cases of note. In one case, blockchain scanning can be delegated to a device or service without delegating spend authority for identified coins. In another case, wallet software in possession of a spend key can keep this key encrypted or otherwise securely stored during scanning operations, reducing key exposure risks.”

The full view key she wants to pass to her accountant Bob.

Quick look into sparkwallet.cpp to find:

// Generating spark key set first time
spark::SpendKey spendKey = generateSpendKey(params);
fullViewKey = generateFullViewKey(spendKey);
viewKey = generateIncomingViewKey(fullViewKey);

Alice is set up, shares her donation address, and can do her transactions (receive / spend spark). Now she wants to publish her donation address as well as the viewKey so that other can transparently see the amount she collected. She looks into QT and can’t find anywhere the possibility to reveal the viewKey also the cli doesn’t offer a possibility to get the viewKey out…

• DumpViewKey function missing
• GUI viewKey in/output not possible

Alice breaks open the code a bit to get her viewKey out and publishes it with her donation address. Eve, who is interested in the charity of Alice sees the address and the view key and is curious to see how much she collected. She takes the published information and finds out… There is no possibility to import the viewkey nor is it possible to pass it as parameter to a CLI function to get the balance or history of the account.

• ViewIncoming “Account/Address” “ViewKey” missing.
• getBalnceOf “Account/Address” “ViewKey” missing.

Well, viewKey is one thing. Now that the tax season approaches Alice passes to the fullViewKey, that she cracked out earlier, to her accountant Bob. She informs him that there is no need to get a full QT-GUI setup as there is not possibility to import the fullViewKey there for the time being. Alice argues, the

“full view key is used in Recover operations to additionally compute the serial number and tag for coins directed to an associated public address. These tags can be used to identify a transaction spending the coin. Providing this key to a third party permits identification of incoming transactions and detection of outgoing transactions, which additionally provides balance computation, without delegating spend authority. Users like public charities may wish to permit public oversight of funds with this functionality. Other users may wish to provide the functionality to an auditor or accountant for bookkeeping purposes. In the case where an address is used in threshold multisignature operations, a cosigner may wish to know if or when another cohort of cosigners has produced a transaction spending funds.”

Further the paper says that

“Address owners can securely provide third parties with opt-in visibility into incoming transactions or all transactions associated to the address; this functionality allows for offloading chain scanning and balance computation without delegating spend authority.”

So Bob is confident that with a fullViewKey he will be able to send CLI calls to public nodes and get all the data required to perform the tasks Alice expects. Well, Bob has a hard time and it seems that there is no RPC function he can pass the fullViewKey to, to get his job done. Besides the missing function he notices that most wallet related RPC function require an authentication. So even if there were a function, if he doesn’t have the RPC-authentication of the public node he can’t perform the task without tunning a full node himself.

• DumpFullViewKey function missing
• GUI fullViewKey output not possible
• getBalnceOf “Account/Address” “FullViewKey” missing.
• GetSparkAllSparkAdresses “Account” “FullViewKey” missing.
• GetSparkAllUsedSparkAdresses “Account” “FullViewKey” missing.

[Next part not described in Section 6 just thinking further – feature request(?)]
Bob and Alice came along with a solution outside the Network. Now Bob wants to invoice Alice for his service and prepares a transaction passes it offline to Alice for signature, as only she has the signing authority. Bob gets the signed transaction offline back from Alice. As he has no full node running, but he can’t find a call functions with public nodes where he could submit the signed transaction to a public node and broadcast it to the network….

Summary

Center pieces of Lelantus Spark are implemented! 😊 However, it seems that core elements of the paper from section 6 have not undergone development and so spark is not complete on this end. There are no indications known to me, that spark would come in multiple waves where the missing parts are factored in later. Whether the transaction signing and verification by the view key of such tx is working properly has not been tested from my end yet, due to possible missing implementation/documentation/functionality stated above. From my understanding the view keys are on account level, not on address level (I might be wrong here). An extraction function of the account and the corresponding viewKeys would be highly appreciated.
In my humble opinion, all the functions (besides the Dump/retrieve functions) should be implemented in a way that they can be queried from every node in the network without RPC-authentication at the public nodes end in order to provide for more light wallet use cases without full node running.

[reubenyap]

Hi @mobias17!

Thank you for the long question and for your interest in Firo!

Currently, we do intend to build view keys out ASAP but payment proofs are a little more complex and will probably come in a later release since its application is more niche.

The algorithms for view keys are actually all there as in the identification and recovery algorithms as they are also used for standard spends too. However, what is still outstanding is mainly how the scanning and UX should be handled and we hope to resolve that soon.

Our team has experienced a bunch of delays due to health, war and other type of situations and also with the bear market, funding is tight and we haven't had the ability to engage additional developers to speed up the process. We are trying to meet our deadline to deliver Spark by 2023 but I think January 2024 might be a safer bet for activation since people are off from holidays and able to do the necessary ecosystem upgrades.