Re: [bitcoin-dev] Schnorr signatures BIP

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

Note:

This spec cannot be used directly with a shamir scheme to produce
single-round threshold multisigs, because shares of point R would need to
be broadcast to share participants in order to produce valid single
signatures.

(R, s) schemes can still be used "online", if share participants publish
the R(share).... but, not sure if it matter much, this choice eliminates
offline multiparty signing in exchange for batch validation.








On Sun, Aug 12, 2018 at 12:47 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I think it's just an oversight. We should specify that we use the standard
> encoding from section 2.3 of http://www.secg.org/sec1-v2.pdf except that
> we allow only compressed public keys.
>
> Andrew
>
>
> On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev
> wrote:
> > Is it intentional that the encoding of public (and private) keys is
> > unspecified? I'd consider at least the encoding of the public key to be
> > part of the signature scheme, so ideally it should be specified already
> > in this BIP. On the other hand, there may be good arguments against it,
> > but I'm not aware of any.
> >
> > This issue leads to a discrepancy between the specification and the
> > test vectors because the data fields of test vectors "are given as byte
> > arrays", including public and secret key. As a consequence, even the
> > Python reference implementation in the BIP draft doesn't work on test
> > vectors (in a strict sense).
> >
> > Best,
> > Tim
> >
> >
> > On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote:
> > > Hello everyone,
> > >
> > > Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> > > over the same curve as is currently used in ECDSA:
> > > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> > >
> > > It is simply a draft specification of the signature scheme itself. It
> > > does not concern consensus rules, aggregation, or any other
> > > integration into Bitcoin - those things are left for other proposals,
> > > which can refer to this scheme if desirable. Standardizing the
> > > signature scheme is a first step towards that, and as it may be
> > > useful
> > > in other contexts to have a common Schnorr scheme available, it is
> > > its
> > > own informational BIP.
> > >
> > > If accepted, we'll work on more production-ready reference
> > > implementations and tests.
> > >
> > > This is joint work with several people listed in the document.
> > >
> > > Cheers,
> > >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> "A goose alone, I suppose, can know the loneliness of geese
>  who can never find their peace,
>  whether north or south or west or east"
>        --Joanna Newsom
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4889 bytes --]