Extract ECC operations to 3rd party module

[dcousens]

As the title says.

For now, I intend to move it to https://github.com/dcousens/libsecp256k1 (I might move that under the bitcoinjs-lib organisation).

By moving it out we can focus on what is important for this library, in this library; and naturally can focus on things like #361 in an external environment.

By doing this, we will have to naturalize (to built-ins or Buffers) such that our API will be more inter-operable.

Also related was #350.

The reason I'm thinking we don't use https://github.com/cryptocoinjs/ecdsa initially, is because, like https://github.com/bitcoin/secp256k1/, the extracted library should be purely for secp256k1.

@jprichardson @rubensayshi @Polve thoughts?

[jprichardson]

The reason I'm thinking we don't use https://github.com/cryptocoinjs/ecdsa initially, is because, like https://github.com/bitcoin/secp256k1/, the extracted library should be purely for secp256k1.

This doesn't follow. ecdsa is only secp256k1. I don't think we should use ecdsa though.

My position hasn't changed much regarding my comments in those other threads. In summary, we should move towards elliptic. However, I can definitely see the case for maximum performance. Is it worth the cost though?

Wouldn't it make more sense to prepare to migrate towards elliptic first and then tackle the issue of migrating towards https://github.com/bitcoin/secp256k1/ later? Or does it make more sense to move towards https://github.com/dcousens/libsecp256k1 (marriage of https://github.com/bitcoin/secp256k1/ + https://github.com/cryptocoinjs/ecurve) now?

[dcousens]

This doesn't follow. ecdsa is only secp256k1

Oh? I wasn't aware of that (sorry).

My position hasn't changed much regarding my comments in those other threads. In summary, we should move towards elliptic. However, I can definitely see the case for maximum performance. Is it worth the cost though?

Agreed, that is the plan. As for the performance cost, I think that is something we can measurably move towards without fundamentally giving up anything; the only problem is that it is going to take a while to do so.

Wouldn't it make more sense to prepare to migrate towards elliptic first and then tackle the issue of migrating towards https://github.com/bitcoin/secp256k1/ later? Or does it make more sense to move towards https://github.com/dcousens/libsecp256k1 (marriage of https://github.com/bitcoin/secp256k1/ + https://github.com/cryptocoinjs/ecurve) now?

As for the migration plan, elliptic simply isn't ready yet, but this move should be done in such a way that gets us API parity, so we aren't wasting effort.

[rubensayshi]

I think creating some wrapper so we can easily switch which package is used would be great and we should go straight for that instead of taking intermediate steps.
Once that is done it's also easy to add any other implementations if there's a desire for it.

I don't like the name libsecp256k1, maybe secp256k1-wrapper or something ...
libsecp256k1 suggests to me that it's another implementation

[ryanxcharles]

My two cents: I would really like to see an elliptic curve library as fast as Fedor's elliptic but with only secp256k1 designed only for bitcoin. The pure javascript analog of libsecp256k1. If ever such a library were created, that's what I would recommend for bitcoinjs-lib.

[dcousens]

I don't like the name libsecp256k1, maybe secp256k1-wrapper or something

Except that would mean we have no freedom to include our own implementation later if that is preferred.

[indutny]

@ryanxcharles I'd say that elliptic was designed with secp256k1 in mind ;) It is using GLV because of it, and everything there was benchmarked and optimized using secp256k1 curve.

[jprichardson]

Anymore thoughts on the direction that we're going here?

[dcousens]

@jprichardson I think with #420 in place for 2.0.0, we can safely iterate on this issue for the remainder of 2.x.y.

The last thing we need to do to be able to easily "break away" and have the freedom of choice to move around in this domain is to resolve #407.

I'm hoping to have a look at that today.

[axic]

Is there any progress on this?

[dcousens]

ping @fanatid, status on node secp256k1 lib?

[fanatid]

I think it's ready for use, probably we should create branch v3.0.0 and merge #440 #456 #459 there, because without this integrate secp256k1 more difficult. I'd also like use dominictarr/varstruct for block/transactions and move hdnode (bip32), script, transactions builder to their own packages.

EDIT: There are a lot of work and probably first we should finish with extracted packages. For example with bitcoinjs-message: bitcoinjs/bitcoinjs-message#2 ;)

[dcousens]

Closing in favour of #623