Stepan have you spent any time considering a scheme that could involve HD
keys, preregistering n (ie. 1000) preimages, or something similar to reduce
the number of rounds at time of signing?
Would a zero knowledge solution allow for a reduction in rounds?
On Wed, Feb 26, 2020 at 7:13 PM Stepan
+1 love that progress is being made on this. Excited to implement it once
it’s ready.
Would love if things like the incrementing number were included in the
standard as well.
Cheers!
On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
Thanks for starting this initiative; it has been a long standing goal of
mine to implement and release this protocol. Your blog post on the topic
actually inspired me to pick up this work again a few months ago.
Jonas Nick has implemented the protocol in the secp256k1 library for
Schnorr sigs
Dear ZmnSCPxj,
> I think it would be unsafe to use a deterministic scheme, that takes as
input the message m and the privkey only.
Yes, using only the message and the private key is unsafe. Signer should
use all the data coming from the host, so f(sha256(n), m, privkey) is a
good candidate. If
Good morning Stepan,
> 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
bitcoin-dev
To: bitcoin-dev@lists.linuxfoundation.org
Sent: Wed, 26 Feb 2020 19:13
Subject: [bitcoin-dev] Nonce blinding protocol for hardware wallets and
airgapped signers
This topic appeared in the list a few times so I would like to discuss it
in more detail and maybe push forward
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
