BitShares Forum
Main => General Discussion => Topic started by: 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
To get the bounty the pull request must be merged and proven to work with BitShares main client.
-
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.
-
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
-
For the non-techies.... what is this about?
-
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?
-
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
-
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
-
I'll take the challenge.
-
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:
Of 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.
-
I'll take the challenge.
+5%
-
I'll take the challenge.
+5%
Way to go!
-
I'll take the challenge.
+5%
-
Yeah
-
I'll take the challenge.
Awesome! +5%
-
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.
-
Ah .. I understand .. we are talking about the implementation libsecp256k1 ..
-
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?
-
It's getting interesting again. :)
Sent from my ALCATEL ONE TOUCH 997D
-
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?
-
This one is supposed to be fast as well, with inline gcc assembler primitives for ARM.
https://github.com/kmackay/micro-ecc
-
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.
-
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.)
-
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! :)
-
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. :)
-
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.
-
But the main part that slows sync is HDD not CPU. The software could also use more RAM that is left unused.
-
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
-
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.
-
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
-
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.
-
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%
-
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%
-
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.
-
wow that was fast @pc :) +5%
-
wow that was fast @pc :) +5%
Yeah what a beast. Good work PC!
-
very good work +5%
-
very good work +5%
Please remember to vote for dev-pc.bitcube. Give him your encouragement and love. :)
-
great work @pc!!
+5% +5%
-
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.
-
https://www.reddit.com/r/Bitcoin/comments/3t0kff/core_switched_to_libsecp256k1_for_verification/
LOL. Delayed a few months.
-
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....
-
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.