I keep getting this error

I keep getting this error

I updated to v1.7.0+4 and used half of my notes and it worked, not sure which one did the trick
There were some code changes to add support for concurrent voting.
1.7.0+4 is the min version.
With an entirely separate set of notes, YWallet iOS is crashing for me when attempting to vote in poll #2.
I installed YWallet Desktop using the Linux appimage, and restored the same wallet seed. The wallet is fully synced, and shows all the transactions responsible for creating the notes that I want to vote with in the wallet history, but none of these notes show up in the voting UI. For the second poll, I added notes to the wallet during the registration period and then sent them back out to cold storage in txid 736b4871590a2e134945ba33bc654554a8739f0cf2323387a6246626c1b76ebd. The desktop wallet doesnât show any valid notes for me to vote with in either poll.
EDIT: @hanh my guess is that the Linux appimage hasnât been updated with the fix to the previous UI bug?
depends on the version you useâŚ
I got the image from Installation - YWallet and I notice now that thatâs back on 1.6.3; where can I find 1.7.0+4? on iOS I have 1.7.0+552/2dd73642
EDIT: found it on github: Releases ¡ hhanh00/zwallet ¡ GitHub and with the most recent version on desktop, it appears that I was able to cast my vote.
Were you using a note with 0 value on it? I found that when I combined votes and included a note with a 0 value I got this error. When I voted and de-selected the note with 0 value it worked.
The latest beta version supports multiple concurrent polls and has a database schema change. If you participated in an earlier poll, you have some incompatible tables.
Therefore, a clean install is recommended.
Production releases have schema migration code.
can we have results now?
The choices are in the image on post Coin Weighted Poll - #140 by aquietinvestor
| Choice | Votes (ZEC) |
|---|---|
| 0 | 29 |
| 1 | 155 |
| 2 | 974 |
| 3 | 103 |
| 4 | 13592 |
| 5 | 12144 |
| 6 | 3271 |
| 7 | 1117 |
| Choice | Votes (ZEC) |
|---|---|
| 0 | 100 |
| 1 | 0 |
| 2 | 4325 |
| 3 | 117 |
| 4 | 273714 |
| 5 | 147388 |
| 6 | 3000 |
| 7 | 1154 |
Option 4 (Hybrid Deferred) is the most popular.
Thanks to everyone who participated. We have a turnover of more than 460,000 ZEC!
The image contains only one set of choices, which were for the second poll, not the first (given that the first poll was a test poll with a different question set, per Coin Weighted Poll - #66 by aquietinvestor). Can you clarify?
It is interesting to me that in Poll 2, Option 4 (Hybrid Deferred) and Option 5 (20% Lockbox) received several orders of magnitude more support than the other options. I wonder how much of that is down to available note sizes constraining choice?
The fist poll was poll 0⌠hehe
poll 1 and 2 have the same questions but different registration windows.
I donât understand what note size constraint you are referring to. Could you clarify the question ?
PS: It may be due to the choices of the zwhale zooko was talking about.
Because notes had to be created during the registration period, that was the only opportunity to split or merge notes into âvoting valuesâ. If someone didnât realise this, but happened to have notes created in that registration window, then they could only vote in increments corresponding to whatever note value they happened to have. In particular, I could imagine someone moving funds to a voting wallet but not realising they need to split up, resulting in only having a single note to vote with.
I think it has more to do with the difference in wealth though.
The limitation could be lifted by supporting multiple candidates in the same ballot (and encrypting it)
either way the experiment was a success @hanh @str4d what are your thought about fully auditing the code and implementing in all wallets
coin voting which will generate fees is always good for zcash as a protocol
I think that the possibilities open up if we implement extended memos, as well: votes could be sent in memos to a well-known IVK, so that any observer of the chain who holds that key could count the votes.
I am considering using homomorphic encryption like Paillier at a later time.
Yeah, combining coin weights with privacy techniques used by e.g. Helios would be useful to limit disclosure of note amounts and linkage of them to vote options.
If my math is correct, Zookoâs whale friend(s) added about 400,000 new ZEC into the vote! (taking the difference between Poll 1 and Poll 2 totals)