@james_katz @elijahhampton @Edicksonjga and especially @Juanky are the folks to thank!
It was a pleasure to help in the launch of this first version.
Need some help getting this to run. I’ve tried both the appimage and .deb files with similar results.
System info:
We had some problems with linux Mint
but we thought these problems are not general… But were wrong. Thanks for testing & we are working on this for the next release that it will be soon… Sorry about that.
Ideas on how to implement zip-317 to Zingolib
I’m pretty sure Zingo Labs guys are already working hard to make Zingo! zip-317 compliant, but here are my ideas on how to do it in a way that needs very little changes to the current code. unfortunately I know jack about Rust, or I would implement it myself.
Even though I can’t code in Rust, I can follow the overall logic of it, so I have a basic understanding of Zingolib architecture, here is my idea on how zip-317 could be implemented:
First of all, in commands.rs
add new command called GetConventionalFee
this command will be called by Zingo-PC using zingolib_execute
through native.node
neon binding. GetConventionalFee
will accept a tos
json object containing recipients and amounts to send. This function will call GetNotesAndFee
function described below.
In wallet.rs
move all note selection logic from send_to_address_inner
to a new function called GetNotesAndFee
.
Function GetNotesAndFee
will receive a list of recipients and amounts, calculate the target_amount
and return orchard_notes
, sapling_notes
, utxos
, target_amount
, selected_value
and zip317_fee
. The zip-317 fee can be easy calculated since we know the inputs (selected notes) and outputs (recipients).
In commands.rs
edit SendCommand
to accept orchard_notes
, sapling_notes
, utxos
, target_amount
, selected_value
and zip317_fee
as extra arguments and call lightclient.do_send
function with those arguments, e.g. lightclient.do_send(tos, orchard_notes, sapling_notes, utxos, target_amount, selected_value, zip317_fee)
.
In lightclient.rs
edit do_send
function to accept previously mentioned arguments. Now the function do_send
will call wallet.send_transaction
with these extra arguments.
Again in wallet.rs
edit send_transaction
and send_transaction_inner
to accept all these extra arguments. send_transaction_inner
will construct the transaction using the selected notes, amounts and fee received as arguments.
Putting it all together:
- User wants to send new transaction and fill up To and Amount on Send screen of Zingo-PC.
- Users click Send Button. Zingo-PC will call
zingolib_execute("GetConventionalFee", tos)
– Heretos
is the recipients and amounts to send. GetConventionalFee
will callwallet.GetNotesAndFee
and will receive the selected notes, target amount, selected value and zip-317 fee.- Zingo-PC will display a modal displaying the zip-317 fee and will ask for confirmation.
- When user confirms the send, Zingo-PC will call
zingolib_execute("send", tos, orchard_notes, sapling_notes, utxos, target_amount, selected_value, zip317_fee)
- Command
SendCommand
will calllightclient.do_send
with received arguments. - Lightclient
do_send
will callwallet.send_transaction
with received arguments. - Wallet
send_transaction_inner
will build the transaction with received selected notes and fee.
I don’t know if I expressed myself cleary, or if it makes any sense … but in my mind it makes sense.
This is the key function. Fees depend on the inputs and outputs, therefore there is a cyclic relationship. Throw in multi receivers uas and it becomes fairly complex.
Any plans on a new release with a release build? People seem interested and they will have a very negative impression of the performance…
We are working now in a new & better sync process, I think we will release both apps with the new sync feature ASAP. Thanks. And we need to resolve the linux problems as well…
I just uploaded a new binaries for linux, can you, please try again the same process with the new binary??? I would really appreciate it. Thanks.
That’s good news, thank you so much.
We created a new pre-release version v1.0.1 including our new zingolib feature using shardtree to sync, we are already testing it so we consider this experimental…
I’ve just opened Zingo PC 1.0.1 and it’s showing me a much higher balance , all in the Sapling pool. I also have the account on Ywallet and it’s showing the correct balance (i.e. I don’t think anyone sent me a lot of ZECs by accident
). I’ll try rescanning
Yes, I noticed the same, it seems like the old promotions from sapling to orchard have no effect now. This is a Bug in the new sync feature affecting to the balance. Well, this version is experimental, Thanks for testing and maybe it’s better to use the stable version 1.0.0, it’s up to you…
Yep, I understand, just making sure it got reported, glad you’re working on it. Thanks!
Hello @zancas! Has anyone besides me tried to sync zingo PC with an initial phrase over 4 years old? My result on macOS is that the entire balance of incoming transactions was summed up by the total cumulative amount and it ends up displaying incorrectly as a large number. In reality there are hundreds of times less funds in the balance.
That’s very interesting, have you attempted a rescan? Ywallet is also available on Mac OS as another option to attempt if you dont have any luck with zingo
Thank you! I’ve only done one scan. Actually there is no problem, I use in parallel all possible platforms from one seed-phrase, more for testing purposes. Because I have to make recommendations myself in Russian-speaking communities and it would be strange if I was lost with that. It’s more of a feedback.
Thanks @artkor we’ll look into this!
Which version are you using? There is a bug in 1.0.1 which is experimental, I had a similar issue as reported above.