[BOUNTY] $5000 BitUSD - LibSecp256k1 integration with FC

Started by bytemaster, March 06, 2015, 12:09:10 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Akado

Quote from: topcandle on November 16, 2015, 09:53:28 PM
Quote from: Akado on November 16, 2015, 09:34:29 PM
https://www.reddit.com/r/Bitcoin/comments/3t0kff/core_switched_to_libsecp256k1_for_verification/
LOL. Delayed a few months.

What's there to laugh about.  Bitshares has delayed many features it promised....

Many features that haven't been implemented by anyone. What's there to laugh about is people adore when Bitcoin implements some features and despise other projects that have those exact same features. That's what there's to laugh about. The irony of bitcoin having a great libertarian spirit behind it yet, their community is closed like the same banks they hate.
[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

topcandle

[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Akado

[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

vikram

Quote from: pc on March 11, 2015, 10:07:17 PM
PR submitted: https://github.com/BitShares/fc/pull/4

Speedup of --rebuild-index is insignificant on my system, around 5%. Possibly more on an SSD. The indexing is heavy on IO, so not much speedup to be expected here.

Speedup of wallet_rescan_blockchain is 4% for the mixed implementation and 25% for pure libsecp256k1.

Note that block/transaction signature validation is skipped until after the most recent checkpoint, otherwise IO may not necessarily dominate.

ElMato


cube

Quote from: BTSdac on March 12, 2015, 01:26:42 AM
very good work  +5%

Please remember to vote for dev-pc.bitcube. Give him your encouragement and love. :)
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

BTSdac

[url="//github.com"]github.com[/url] :pureland
BTS2.0 API :[url="ws://139.196.37.179:8091"]ws://139.196.37.179:8091[/url]
BTS2.0 API 数据源ws:[url="//139.196.37.179:8091"]//139.196.37.179:8091[/url]

robrigo


cass

█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

pc

PR submitted: https://github.com/BitShares/fc/pull/4

Speedup of --rebuild-index is insignificant on my system, around 5%. Possibly more on an SSD. The indexing is heavy on IO, so not much speedup to be expected here.

Speedup of wallet_rescan_blockchain is 4% for the mixed implementation and 25% for pure libsecp256k1.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 [url="http://bitcoin.quisquis.de"]http://bitcoin.quisquis.de[/url]

alt

Quote from: heyD on March 10, 2015, 12:28:20 AM
Quote from: bytemaster on March 10, 2015, 12:05:15 AM
Quote from: jsidhu on March 09, 2015, 10:57:21 PM
Quote from: vlight on March 09, 2015, 09:44:47 PM
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

We are working to reduce RAM and CPU.

Very glad to see you come back to the most critical topic.
+5%
+5% +5% +5%

muse-umum

Quote from: bytemaster on March 10, 2015, 12:05:15 AM
Quote from: jsidhu on March 09, 2015, 10:57:21 PM
Quote from: vlight on March 09, 2015, 09:44:47 PM
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

We are working to reduce RAM and CPU.

Very glad to see you come back to the most critical topic.
+5%

bytemaster

Quote from: jsidhu on March 09, 2015, 10:57:21 PM
Quote from: vlight on March 09, 2015, 09:44:47 PM
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

We are working to reduce RAM and CPU. 
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

jsidhu

Quote from: vlight on March 09, 2015, 11:02:33 PM
Quote from: jsidhu on March 09, 2015, 10:57:21 PM
Quote from: vlight on March 09, 2015, 09:44:47 PM
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

Well, for me when syncing less than 100 hours left, it takes only 1GB of RAM(2GB unused), but uses HDD heavily.

On my ubuntu installations I always run out of 2 GB ram.. even after sync and restarting.. maybe jus tmemory leak in latest release... and my delegate always runs out i had to create a 4 gb swap file and that gets half used but then i start to miss blocks because its slow.. so i just restart it once eveyr few weeks
Hired by blockchain | Developer
delegate: dev.sidhujag

vlight

Quote from: jsidhu on March 09, 2015, 10:57:21 PM
Quote from: vlight on March 09, 2015, 09:44:47 PM
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

Well, for me when syncing less than 100 hours left, it takes only 1GB of RAM(2GB unused), but uses HDD heavily.

jsidhu

Quote from: vlight on March 09, 2015, 09:44:47 PM
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
Hired by blockchain | Developer
delegate: dev.sidhujag

vlight

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

bytemaster

Quote from: pc on March 09, 2015, 10:33:01 AM
Quote from: bytemaster on March 06, 2015, 12:09:10 AM
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.

Quote from: vikram on March 06, 2015, 06:29:09 PM
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.
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

cube

Quote from: svk on March 09, 2015, 12:46:00 PM

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. :)
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

svk

Quote from: pc on March 09, 2015, 10:33:01 AM
Quote from: bytemaster on March 06, 2015, 12:09:10 AM
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.

Quote from: vikram on March 06, 2015, 06:29:09 PM
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! :)
Worker: dev.bitsharesblocks

pc

Quote from: bytemaster on March 06, 2015, 12:09:10 AM
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.

Quote from: vikram on March 06, 2015, 06:29:09 PM
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.)
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 [url="http://bitcoin.quisquis.de"]http://bitcoin.quisquis.de[/url]

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
Quote
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.
BitShares committee member: abit
BitShares witness: in.abit

julian1

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

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

jsidhu

Quote from: vikram on March 06, 2015, 06:29:09 PM
Quote from: jsidhu on March 06, 2015, 07:32:17 AM
Quote from: testz on March 06, 2015, 02:09:55 AM
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?
Hired by blockchain | Developer
delegate: dev.sidhujag

liondani

It's getting interesting again.  :)

Sent from my ALCATEL ONE TOUCH 997D
[url="https://www.steempeak.com/@liondani"]https://www.steempeak.com/@liondani[/url]


xeroc

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

jsidhu

Quote from: xeroc ¯\_(ツ)_/¯ on March 06, 2015, 07:54:31 AM
Quote from: jsidhu on March 06, 2015, 07:32:17 AM
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.
Hired by blockchain | Developer
delegate: dev.sidhujag




cube

ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

cass

█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

svk

Quote from: pc on March 06, 2015, 08:40:08 AM
I'll take the challenge.

Awesome! :) I asked about this on github a while back, it looks like it could be a real gamechanger in terms of scanning speed for the client.

This is a quote from Gavin Andresen in his blog post talking about increasing the block size of Bitcoin:

QuoteOf course, we won't be running current code on tomorrow's hardware; we'll be running better code. CPU usage should go down by a factor of about eight in the next release when we switch to Pieter's libsecp256k1 library for validating transactions.
Worker: dev.bitsharesblocks

pc

Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 [url="http://bitcoin.quisquis.de"]http://bitcoin.quisquis.de[/url]

cube

Quote from: bitmarket on March 06, 2015, 03:53:23 AM
For the non-techies.... what is this about?

Bitcoin uses secp256k1 to digitally sign and verify transactions. This link may give a clue - http://bitcoin.stackexchange.com/questions/36136/is-libsecp256k1-faster-than-openssl
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

xeroc

Quote from: jsidhu on March 06, 2015, 07:32:17 AM
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

jsidhu

Quote from: testz on March 06, 2015, 02:09:55 AM
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?
Hired by blockchain | Developer
delegate: dev.sidhujag

bitmarket

Host of [url="//bitshares.tv"]BitShares.TV[/url] and Author of BitShares 101

testz


eagleeye

Bytemaster read Rgcryptos blog https://rgcrypto.wordpress.com

He may have found the secret sauce for bitshares success or failure.  I understand this is not related.
TheValueSwan
www.thevalueswan.com

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

To get the bounty the pull request must be merged and proven to work with BitShares main client.   
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.