I am currently working with a small team as part of the wider community for the Mina Protocol. More specifically, we are integrating ZCash Foundation’s lovely FROST implementation to enable multi-threshold wallets on the Mina blockchain.
We have run into a problem wherein Mina requires all commitment elliptic curve elements within its signatures to have even Y values, however, FROST makes no such distinction and produces commitment elements with odd or even Y coordinates. I was wondering whether there is any existing research or implementations which suggest secure modifications to FROST to allow for even Y commitments.
I believe that the redpallas implementation by ZCash Foundation does meddle with parity but does not produce even Y coordiantes for commitments (only group public keys I believe?). Another solution is to constantly rerun the entire signing process within FROST until we get a desired signature but we’d very much like to avoid that if possible.
(Note how you don’t need to re-run the key generation; if the output has a “odd Y”, you can simply negate everything (shares, verifying shares, and group public key) to obtain a valid “even Y” value.)
Ah sorry, I see now that you were talking about commitments. But the same approach should work. Just negate the commitment and the nonce if the commitment is odd, and it should work.
Okay, that sounds simple enough. Does not negating the nonces invalidate all the previous commitments, because participants will only know whether the group commitment has an odd Y value after they have made all their commitments?
I’m referring specifically to this line within FROST signing:
If R turns out to have odd Y, and we negate d_i, e_i, which means we modify B which is the set of commitments <i, D_i, E_i> i \in S where S is the set of participants identifiers. This in turn will modify p_i and so may still produce a completely different group commitment with odd Y
Yep, makes sense. I have an implementation but it requires me to copy and paste a lot of code from the frost-core sign() and aggregate implementations and only changing a few lines. I can’t fit the changes into pre_sign() due to the fact that my change lie between the calculation of binding_factors and the group_commitment.
Is it worth raising an issue on possibly adding a pre_group_commitment() hook to sign() and aggregate()?
Yes, feel free to open an issue describing what would be useful for you.
Another alternative would be to enable the internals feature so that you can reuse the internals function, it still would require copying some of the code but not everything.
I am new to this forum. I have a cryptocurrency accounting program called Cointracker and it says I have some money in a Zcash wallet but I cannot think for the life of me as to what this would be referring to? I bought ZCash early on In my crypto Exposure but cannot recall where this wallet would be? I have an address But do not know how to tell where the wallet is? Does anyone know how to trace the address backwards to determine what this wallet is? Certainly this is somewhat embarrassing but would appreciate anyone’s assistance. I will post the address below.
xpub6CQDy3ajUxBywFQghz1zuieCnTe5H7oAKdmiBCJp5Yo8SFC3XH5kUNMJj2dQiHayKkM7SrQfB9VyYrCQohRrcQ9zChhqhtf9j69wjLLc6AQ
Thank you. It sucks that I can’t recall which wallet it would be. Could it be on an exchange? I didn’t think I had any more ZEC, but the Cointracker aggregator says I do, and from a taxation standpoint, I guess I’m still on the hook for this asset even though I can’t, at this time, get access. I was hoping that the XPUB key could indicate what wallet it might be in.
@conradoplg@Jeephill Import into Zkool, birthday I set to 0. Maybe you can correlate the address to an EX or something you saved.
(The input address that paid the amount HELD over 300k zec so it kinda sounds like it was perhaps a withdrawl from an exchange or some otherwise no longer in use address)
Thanks for the question. Zcash was an early purchase for me in my crypto journey. I signed up for Cointracker and attached all my exchanges for tax purposes. There are two wallets I cannot for the life of me remember inputting into Cointracker; the ZEC “wallet” and a DASH “wallet”. I do not have either of these cryptos in any of my exchanges and not in my cold wallet. I have an Exodus wallet, a Loki wallet, an Atomic wallet, a Trust wallet, Metamask, Phantom, Martian, etc. but no ZEC or Dash in any of them.
Thanks for your help. I am admittedly not very facile with tech and terminology but as I understand it, you took the XPUB code and imported it into Zkool and found out that the tokens I have had likely been transferred from an exchange ( certainly 300k ZEC is a huge amount )?
When you say I may be able to correlate the address to an EX(?) or something I saved, what do you mean?
When you import the key and rescan (which is almost instant for the entire chain), you will see the deposit transaction with the txid which contains information about the tx such as the addresses involved, amounts etc. The transparent side of Zcash lets you see as much as you could see with bitcoin.
Correlating addresses mean that you would have some idea of addresses used in the past so you might be able to find your way to what ever wallet that you used but I don’t know if that’s feasible or not for you.
Again thank you for your assistance. I will try. I will give it some thought. I doubt I can navigate what is necessary to trace the tokens if that’s what you mean by feasible. The amount of ZEC that Cointracker says I have is $2000+. Although I’d love to find and secure the ZEC and DASH tokens, my main concern is paying taxes on crypto that is lost. I would certainly be willing to send half of all recovered funds to you or anyone that can facilitate their recovery. I know it’s not much and likely not worth your time.
