> Correct, except that the speedup from is_even(y) over
is_quadratic_residue(y) affects signing and not keypair generation.
Isn't this the same thing since in the spec it generates the public key in
the signing algorithm? If you pre-generate public key and pass it in there
would be no speedup to
I've been working on developing exactly this for a hardware wallet in working
on as well. So far I only had a rough sketch of how the comments would flow.
I'd be thrilled to see this standardized.
Thanks much,
--Brandon, sent by an android
-Original Message-
From: Stepan Snigirev via
This topic appeared in the list a few times so I would like to discuss it
in more detail and maybe push forward to standardization.
We have to accept that any hardware wallet or an air-gapped computer we use
to sign transactions can be compromised. It may happen via a supply chain
attack or
As a replacement for paper, something like this makes sense v.s. what you
do with a ledger presently.
However, shamir's shares notoriously have the issue that the key does exist
plaintext on a device at some point.
Non-interactive multisig has the benefit of being able to sign transactions
Hi Everyone,
Seed phrase security has been a subject of discussion for a long time now.
Though there are varying opinions on the subject but the conflict usually
arises due to different security models used by different individuals. The
general practice in the space has been to use paper or metal
> Let me put change (1) into my own words.
Correct, except that the speedup from is_even(y) over is_quadratic_residue(y)
affects signing and not keypair generation.
> With change (2), I feel like including this auxiliary random data is overkill
> for the spec. [...] I feel similarly about
