[BOUNTY] $5000 BitUSD - LibSecp256k1 integration with FC

[jsidhu]

But the main part that slows sync is HDD not CPU. The software could also use more RAM that is left unused.

Sorry it already uses too much RAM lol

[vlight]

But the main part that slows sync is HDD not CPU. The software could also use more RAM that is left unused.

[bytemaster]

I would like to have  a drop in replacement that implements this api:
https://github.com/BitShares/fc/blob/master/include/fc/crypto/elliptic.hpp

Using:
https://github.com/bitcoin/secp256k1

I'm making good progress. Results are promising, the ecc_test program runs about 20 times faster with libsecp256k1 than with openssl.

I noticed the current implementation of public_key::mult is broken - it computes the same result as public_key::add, only in a different way. Fortunately, it doesn't seem to be used anywhere in the bitshares code.

Latest Bitcoin Core 0.10 has switched to libsecp256k1 ONLY for signing: https://github.com/bitcoin/bitcoin/blob/aeb92792281b4cb9958f3defc9e36f63e65b778a/doc/release-notes.md#improved-signing-security

If we choose to integrate this into mainline BitShares I will never use it for any more functionality than latest Bitcoin uses it for.

I can provide a "mixed" variant, where signing is done using openssl and verification using libsecp256k1. (My plan is to use a CMake cache var for selecting the ecc implementation to use.)

Good work!   That should help greatly reduce our sync CPU load.

[cube]

Good stuff, keep up the good work! :)

For all who find his work good, please vote for Delegate dev-pc.bitcube! 

Delegate dev-pc.bitcube has been registered for some time now. Please show some love to it. :)

[svk]

I would like to have  a drop in replacement that implements this api:
https://github.com/BitShares/fc/blob/master/include/fc/crypto/elliptic.hpp

Using:
https://github.com/bitcoin/secp256k1

I'm making good progress. Results are promising, the ecc_test program runs about 20 times faster with libsecp256k1 than with openssl.

I noticed the current implementation of public_key::mult is broken - it computes the same result as public_key::add, only in a different way. Fortunately, it doesn't seem to be used anywhere in the bitshares code.

Latest Bitcoin Core 0.10 has switched to libsecp256k1 ONLY for signing: https://github.com/bitcoin/bitcoin/blob/aeb92792281b4cb9958f3defc9e36f63e65b778a/doc/release-notes.md#improved-signing-security

If we choose to integrate this into mainline BitShares I will never use it for any more functionality than latest Bitcoin uses it for.

I can provide a "mixed" variant, where signing is done using openssl and verification using libsecp256k1. (My plan is to use a CMake cache var for selecting the ecc implementation to use.)

Good stuff, keep up the good work! :)

[pc]

I would like to have  a drop in replacement that implements this api:
https://github.com/BitShares/fc/blob/master/include/fc/crypto/elliptic.hpp

Using:
https://github.com/bitcoin/secp256k1

I'm making good progress. Results are promising, the ecc_test program runs about 20 times faster with libsecp256k1 than with openssl.

I noticed the current implementation of public_key::mult is broken - it computes the same result as public_key::add, only in a different way. Fortunately, it doesn't seem to be used anywhere in the bitshares code.

Latest Bitcoin Core 0.10 has switched to libsecp256k1 ONLY for signing: https://github.com/bitcoin/bitcoin/blob/aeb92792281b4cb9958f3defc9e36f63e65b778a/doc/release-notes.md#improved-signing-security

If we choose to integrate this into mainline BitShares I will never use it for any more functionality than latest Bitcoin uses it for.

I can provide a "mixed" variant, where signing is done using openssl and verification using libsecp256k1. (My plan is to use a CMake cache var for selecting the ecc implementation to use.)

[abit]

It's said that LibSecp256k1 is much faster than OpenSSL while verifying signatures. By using it we can improve the client sync speed much, which is a bottleneck by now.

http://www.reddit.com/r/Bitcoin/comments/2weymr/experiment_bitcoin_core_0100_initial_sync_time/coqghm2

Just did a benchmark on libsecp256k1's current master, without GMP, without hand-written assembly, and it's around 3.6x faster than OpenSSL on my machine (64-bit code, i7 cpu). When the assembly is compiled in (which does not require any extra dependencies anymore), it's 4.9 times faster.

[julian1]

This one is supposed to be fast as well, with inline gcc assembler primitives for ARM.

https://github.com/kmackay/micro-ecc

[jsidhu]

Good starting point/example can be Auroracoin sources where it's implemented (see define USE_SECP256K1):
https://compilr.com/einsteinz/auroracoin-core/src/key.cpp

Whole sources from compilr.com can be found here: https://mega.co.nz/#!VJYRXQ7A!7LjU3M8iXWZlf4WIoRdrZw7gYXL_abtNgjxeQTyYxPQ

They just based off of latest btc.... Best to look here instead https://github.com/bitcoin/bitcoin/commit/16a58a86442ad587449f321c0dbab08cc028c2bd

Btw secp256k1  is experimental and bitcoin hasnt given it the nod yet.. Why do this?

Latest Bitcoin Core 0.10 has switched to libsecp256k1 ONLY for signing: https://github.com/bitcoin/bitcoin/blob/aeb92792281b4cb9958f3defc9e36f63e65b778a/doc/release-notes.md#improved-signing-security

If we choose to integrate this into mainline BitShares I will never use it for any more functionality than latest Bitcoin uses it for.

Is the intention to use it for more? If so, then does bitshares do it now or wait?

[liondani]

It's getting interesting again.  :)

Sent from my ALCATEL ONE TOUCH 997D

[santaclause102]

https://groups.google.com/forum/#!topic/raiblocks/z6z2x_uvrH0
https://blake2.net/

Is the above relevant and a subset the category Secp256k1 also belongs to?

[xeroc]

Ah .. I understand .. we are talking about the implementation libsecp256k1 ..

[jsidhu]

Btw secp256k1  is experimental and bitcoin hasnt given it the nod yet.. Why do this?

secp256k1 is a set of parameters for a elliptic curve and not a piece of software
https://en.bitcoin.it/wiki/Secp256k1

There is some verification so it needs to be fully tested... Its not yet.. But as long as it passes some integration and unit tests it should be ok i think.

[TurkeyLeg]

I'll take the challenge.

Awesome! +5% 

[38PTSWarrior]

Yeah