Open mobias17 opened 1 year ago
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.
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
The full view key she wants to pass to her accountant Bob.
Quick look into
sparkwallet.cpp
to find: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 missingviewKey
in/output not possibleAlice 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
Further the paper says that
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 missingfullViewKey
output not possiblegetBalnceOf “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.