mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

There is a lot of work to do with libsecp. The implementations of multisig in
secp-zkp and rust-secp are insecure against malicious key generation (this is
easy to overcome, just require all participants to sign with their key shard
to each other, but there is some risk that the new libsecp version will make
incompatible signatures, forcing some ugly shimming).

Presumably the Schnorr code was pulled from rust-secp? This is pulled from
secp-zkp. So they're all the same implementation, but it's one that has been
removed from upstream libsecp and won't be coming back.

We can use ECDSA as a placeholder, the API pretty-much slots in, but given
that it has no security proof and is not a PoK and its algebraic structure
is a mess, we absolutely must not release a chain with any value on it that
uses ECDSA to sign kernels.

Also, as you notice, MimbleWimble is really useless without Schnorr. You
can't even do coinjoin (incl through ValueShuffle) without multisignature
kernels (or multi-kernel transactions, which we've banned for cutthrough
reasons), so the privacy story isn't even that great.

My personal feeling is that we consider upstream libsecp Schnorr support to
be a blocker and just wait it out. Note that we're still missing sum-Merkle
tree code, and I understand Peter Todd has some thoughts on additional
structures we should be committing to that he hasn't written out, so there's
plenty of work to do even without a kernel signature algo ready to go.


Andrew


On Wed, Mar 22, 2017 at 02:52:11PM -0400, Ignotus Peverell wrote:
> Hi all,
> 
> Most of our transaction schemes, whether scriptless scripts for lightning [1], multisig [2] or more robust 2-party transactions [3] all rely on Schnorr signatures. So it would seem reasonable to drop standard ECDSA in favor of Schnorr as default.
> 
> However on the implementation side, things are less clear cut. I can count 4 different versions of libsecp256k1 (one on bitcoin-core, one under Blockstream Elements, one under Andrew's Rust binding and one in the Grin repo), 3 of which have some Schnorr support. I _think_ the Schnorr implementation there is enough to support most of what we have in mind, but we may need to expose a few more utility functions (similarly to what I had to do for Pedersen Commitments).
> 
> So I can see 2 strategies:
> - Stick with ECDSA for now until Schnorr is brought back in the Bitcoin Core repo (which seems the best supported), then add Schnorr support.
> - Clean up our version of secp256k1 to make it a bona-fide vendor branch, add what we need there (eventually merging back upstream if desired) and standardize on Schnorr. I'm not sure the Schnorr impl is still compatible with the latest Bitcoin Core secp256k1 tree though.
> 
> I have a slight preference on 2 as it seems it'd be a better starting base but it's a little more hazardous and I'd love others' opinions. If Andrew or Peter could chime in on what would work best with the libsecp256k1(-zkp or not) plan it'd be really helpful as well.
> 
> - Igno
> 
> [1] https://lists.launchpad.net/mimblewimble/msg00086.html
> [2] https://lists.launchpad.net/mimblewimble/msg00047.html
> [3] https://lists.launchpad.net/mimblewimble/msg00087.html

> -- 
> Mailing list: https://launchpad.net/~mimblewimble
> Post to     : mimblewimble@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mimblewimble
> More help   : https://help.launchpad.net/ListHelp


-- 
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

Attachment: signature.asc
Description: PGP signature