Reduce usage of Bouncy Castle types in public API, replacing with java.security types where necessary.

[msgilligan]

Since we are trying to migrate to a more modular approach to our use of Elliptic Curve Cryptography (see Issue #1874), we should reduce/deprecate/eliminate our usage of Bouncy Castle types in our public API (and our implementation in general)

PR #3351 is an example of a change that does this.

Where types such as ECPoint or ECCurve are being used, we should replace them by the equivalents in java.security, such as java.security.spec.ECPoint, java.security.spec.EllipticCurve, etc.

[shinghim]

Mind if i take a look at this?

[msgilligan]

Mind if i take a look at this?

You want to help us make an implementation?

[msgilligan]

Note that we have a major new project in the works to create a new API for secp256k1 on the JDK: https://github.com/bitcoinj/secp256k1-jdk

I think one of the next steps should be to create an experimental branch of bitcoinj that tries to use the secp256k1-api to wrap all the basic ECC operations currently in the code.

I started down the path proposed in this issue and quickly realized that there's not much we can do with just migrating from Bouncy Castle types to JDK types. We need to look at the bigger picture of refactoring to secp256k1-api first.

[shinghim]

Should I create a new issue and track it there?

[msgilligan]

Should I create a new issue and track it there?

Let me create a new (epic) issue for the overall project. I've been meaning to do this.

[msgilligan]

See Issue #3389 for the overall plan. It does not replace this issue because we will want to work towards using the java.security types where necessary, but that must be done within the context of the overall plan.