Not bashing, but besides recovering lost private keys, what legal activities can you do with this?
Science
Evil-Knievel are you sale the product or not, I send the message your not replay, what ever your work is good
by virbbbq
Topic: This message was too old and has been purged (Read 50681 times)
Science
Evil-Knievel are you sale the product or not, I send the message your not replay, what ever your work is good
by virbbbq
What kind of science?
technology (science) development, it not affect any one because there are lot of keys, each and every address you open all most contain 0 balance, some............ so don't worry feel free
bitcoin one kind of technology (science) like the same
by virbbbq
What kind of science?
This message was too old and has been purged
Not bashing, but besides recovering lost private keys, what legal activities can you do with this?
Proof of Concept Video:
- Working on real bitcoin network with real addresses and real coins.
- All transactions can be verified on blockchain.info
- Randomly generated Bitcoin Adresses are used (however they are all special-weak). This again shows you that there is an infinite number of weak bitcoin addresses.
- Sorry for all the cursing: It has been a long day
http://www.youtube.com/watch?v=TC43aOdsf4g&hd=1
What is up to sale:
After 18 days of excessive work, I have today finished my hobby project:
It's a ECDSA private key cracker for the secp256k1 curve which is for example used in bitcoin.
What does this tool make better than others:
Existing Bitcoin Private Key crackers go through the whole palette of algorithms that are used in bitcoin - to mention some we have ECDSA, sha256, ripemd160 and base58 encoding.
Actually, we do not need to do most of them at all. My tool bases on elliptic curve cryptography only.
A known bitcoin public key has to be converted to hexadecimal and embedded into the software - then using elliptic curve mathematic only it can quite efficiently search through the search space.
Exact functioning:
- Keyspace is reduced in a precomputation phase by calculating several thousand rendezvous points (they are hardcoded in the software but may be changed at any time).
- This precomputation phase is inspired by the "Baby-Step-Giant-Step" algorithm.
- The target public key is then (using ecdsa arithmetic) reduced subseqentially until hitting one of the rendezvous point. Given G is the generator point, and R=x*G the rendezvous point (which private key is known),
we then may get the original privatekey by just taking PrivKey=x+iterations where iterations equals to the number of decrements were needed to hit R.
Open CL Extras:
- Kernel currently works with a global work size of 81920 (value can be adjusted for your graphics card). Meaning in every iteration step 81920 reductions can be made to the public key you try to crack.
- Given the rendezvous point table of size 768 (may be extended anytime) we can do 81920*768 = 62914560 key comparisons per cycle.
- Rendezvous-Table checks are based on just 32bit of x-coordinate to keep it fast! If a collision is found a local verification is performed on the CPU to see if its just a partial collision or a full match. This relaxes the GPU
- Midpoint Feature - So even when your computer shuts down or gets restarted - the work you have already done is remembered
- my HD7970 is at the moment capable of doing 150 MEGAKEYS per second - just a question of time until a rendezvous is being hit
- Speedup is possible with a better Modular-Multiplication. Currently implemented as Double and Add, you could use Montgomery or FFT to get tremendous speedups
Is it for beginners?
No! You should be exactly know what your doing. Even though the code is straight forward, you need to know what is being done exactly and where you need to manipulate parameters if you want to change something.
Documentation and Source Code?
Included (as a QT Project buildable on linux and windows)
Price:
I am asking you 2 BTC for the whole package. It has taken me lots of time to research everything and implement it cleanly. And who knows, this tool is giving you good chances to get one of these lost 10 MILLION US$ accounts
Disclaimer:
This project is for research purpose only, or to recover lost private keys. It may not be used for any illegal activities and I cannot be held responsible for anything you do with it.
http://imageshack.com/a/img854/1821/qlf9.png
- Working on real bitcoin network with real addresses and real coins.
- All transactions can be verified on blockchain.info
- Randomly generated Bitcoin Adresses are used (however they are all special-weak). This again shows you that there is an infinite number of weak bitcoin addresses.
- Sorry for all the cursing: It has been a long day
http://www.youtube.com/watch?v=TC43aOdsf4g&hd=1
What is up to sale:
After 18 days of excessive work, I have today finished my hobby project:
It's a ECDSA private key cracker for the secp256k1 curve which is for example used in bitcoin.
What does this tool make better than others:
Existing Bitcoin Private Key crackers go through the whole palette of algorithms that are used in bitcoin - to mention some we have ECDSA, sha256, ripemd160 and base58 encoding.
Actually, we do not need to do most of them at all. My tool bases on elliptic curve cryptography only.
A known bitcoin public key has to be converted to hexadecimal and embedded into the software - then using elliptic curve mathematic only it can quite efficiently search through the search space.
Exact functioning:
- Keyspace is reduced in a precomputation phase by calculating several thousand rendezvous points (they are hardcoded in the software but may be changed at any time).
- This precomputation phase is inspired by the "Baby-Step-Giant-Step" algorithm.
- The target public key is then (using ecdsa arithmetic) reduced subseqentially until hitting one of the rendezvous point. Given G is the generator point, and R=x*G the rendezvous point (which private key is known),
we then may get the original privatekey by just taking PrivKey=x+iterations where iterations equals to the number of decrements were needed to hit R.
Open CL Extras:
- Kernel currently works with a global work size of 81920 (value can be adjusted for your graphics card). Meaning in every iteration step 81920 reductions can be made to the public key you try to crack.
- Given the rendezvous point table of size 768 (may be extended anytime) we can do 81920*768 = 62914560 key comparisons per cycle.
- Rendezvous-Table checks are based on just 32bit of x-coordinate to keep it fast! If a collision is found a local verification is performed on the CPU to see if its just a partial collision or a full match. This relaxes the GPU
- Midpoint Feature - So even when your computer shuts down or gets restarted - the work you have already done is remembered
- my HD7970 is at the moment capable of doing 150 MEGAKEYS per second - just a question of time until a rendezvous is being hit
- Speedup is possible with a better Modular-Multiplication. Currently implemented as Double and Add, you could use Montgomery or FFT to get tremendous speedups
Is it for beginners?
No! You should be exactly know what your doing. Even though the code is straight forward, you need to know what is being done exactly and where you need to manipulate parameters if you want to change something.
Documentation and Source Code?
Included (as a QT Project buildable on linux and windows)
Price:
I am asking you 2 BTC for the whole package. It has taken me lots of time to research everything and implement it cleanly. And who knows, this tool is giving you good chances to get one of these lost 10 MILLION US$ accounts
Disclaimer:
This project is for research purpose only, or to recover lost private keys. It may not be used for any illegal activities and I cannot be held responsible for anything you do with it.
http://imageshack.com/a/img854/1821/qlf9.png
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
http://key.btc123.com/
Just for clarification:
In fact it is mathematically much more complex than this, but the basic principle is as follows:
Imagine the black line being the complete search space. This searchspace has hundreds to thousands of rendevous points (depicted in red).
Addresses which lie in the middle of two (marked green in the picture) rendezvous points (e.g. the maximum distance to each neighboring rendezvous point) are going to take a long time to crack.
However, all keys that are in a certain area around these rendezvous points (certain area however can also mean several billion apart of course) are being cracked very easily (in a manner of days). Those weak addresses are marked blue in the picture.
Now there is not just black and white but many different nuances, from very easy over tough but doable to very hard
The number of weak addresses is almost unlimited, so I can give you dozen examples that would hit one of the rendezvous points pretty easily.
I will try to make a video presentation by the next week, just to describe the technical background behind this. Its too much to write down.
In fact it is mathematically much more complex than this, but the basic principle is as follows:
Imagine the black line being the complete search space. This searchspace has hundreds to thousands of rendevous points (depicted in red).
Addresses which lie in the middle of two (marked green in the picture) rendezvous points (e.g. the maximum distance to each neighboring rendezvous point) are going to take a long time to crack.
However, all keys that are in a certain area around these rendezvous points (certain area however can also mean several billion apart of course) are being cracked very easily (in a manner of days). Those weak addresses are marked blue in the picture.
Now there is not just black and white but many different nuances, from very easy over tough but doable to very hard
The number of weak addresses is almost unlimited, so I can give you dozen examples that would hit one of the rendezvous points pretty easily.
I will try to make a video presentation by the next week, just to describe the technical background behind this. Its too much to write down.
Could you give any literature reference about this?
Yes he can, but it the complexity. Such difficult. Much hard. Rendezvous points & shit.
Btw rendezvous really just means a spot. So addresses in between the green spots are being cracked so hard. Such crack.
Send him cash.
So this guys wants $1000+ from every single person who wants to buy this? Well thats me out.
If anyone buys it then I have a bridge I want to sell them.
So this guys wants $1000+ from every single person who wants to buy this? Well thats me out.
Just for clarification:
In fact it is mathematically much more complex than this, but the basic principle is as follows:
Imagine the black line being the complete search space. This searchspace has hundreds to thousands of rendevous points (depicted in red).
Addresses which lie in the middle of two (marked green in the picture) rendezvous points (e.g. the maximum distance to each neighboring rendezvous point) are going to take a long time to crack.
However, all keys that are in a certain area around these rendezvous points (certain area however can also mean several billion apart of course) are being cracked very easily (in a manner of days). Those weak addresses are marked blue in the picture.
Now there is not just black and white but many different nuances, from very easy over tough but doable to very hard
The number of weak addresses is almost unlimited, so I can give you dozen examples that would hit one of the rendezvous points pretty easily.
I will try to make a video presentation by the next week, just to describe the technical background behind this. Its too much to write down.
In fact it is mathematically much more complex than this, but the basic principle is as follows:
Imagine the black line being the complete search space. This searchspace has hundreds to thousands of rendevous points (depicted in red).
Addresses which lie in the middle of two (marked green in the picture) rendezvous points (e.g. the maximum distance to each neighboring rendezvous point) are going to take a long time to crack.
However, all keys that are in a certain area around these rendezvous points (certain area however can also mean several billion apart of course) are being cracked very easily (in a manner of days). Those weak addresses are marked blue in the picture.
Now there is not just black and white but many different nuances, from very easy over tough but doable to very hard
The number of weak addresses is almost unlimited, so I can give you dozen examples that would hit one of the rendezvous points pretty easily.
I will try to make a video presentation by the next week, just to describe the technical background behind this. Its too much to write down.
Could you give any literature reference about this?
minerpeabody, I have just checked your solution and it indeed meets all requirements in the original posting.
So it looks like you have perfectly succeeded the task and thus qualified to claim the bounty.
Current Mt.Gox BTC Price: 1 BTC = 915 US$
If I calculate correctly, 200 US$ = (200/915)*1BTC = 0.2185... BTC - I will round it up to 0.22.
All you have to do, is provide me your BTC address.
Back on topic, perhaps?So it looks like you have perfectly succeeded the task and thus qualified to claim the bounty.
Current Mt.Gox BTC Price: 1 BTC = 915 US$
If I calculate correctly, 200 US$ = (200/915)*1BTC = 0.2185... BTC - I will round it up to 0.22.
All you have to do, is provide me your BTC address.
( Insofar as it ever was on topic past the first few posts
)minerpeabody, I have just checked your solution and it indeed meets all requirements in the original posting.
So it looks like you have perfectly succeeded the task and thus qualified to claim the bounty.
Current Mt.Gox BTC Price: 1 BTC = 915 US$
If I calculate correctly, 200 US$ = (200/915)*1BTC = 0.2185... BTC - I will round it up to 0.22.
All you have to do, is provide me your BTC address.
Back on topic, perhaps?So it looks like you have perfectly succeeded the task and thus qualified to claim the bounty.
Current Mt.Gox BTC Price: 1 BTC = 915 US$
If I calculate correctly, 200 US$ = (200/915)*1BTC = 0.2185... BTC - I will round it up to 0.22.
All you have to do, is provide me your BTC address.
( Insofar as it ever was on topic past the first few posts
) Question for the mathmaticians: can you somehow take advantage of taking the ellipital
curve from 2D to 3D, either along the vertical or X axis? Seems like there could be some
voodoo you could do with a corresponding point on the opposite side kind of thing. :-D
curve from 2D to 3D, either along the vertical or X axis? Seems like there could be some
voodoo you could do with a corresponding point on the opposite side kind of thing. :-D
Sure, this would be absolute plausible. I am right now modelling the ECDSA search space as a five dimensional torus.
Yes, your mathematical ingenuity knows no bounds yet your reputation for paying your debts is heading for the gutter:
https://bitcointalksearch.org/topic/this-message-was-too-old-and-has-been-purged-427712
This message was too old and has been purged
Question for the mathmaticians: can you somehow take advantage of taking the ellipitical
curve from 2D to 3D, either along the vertical or X axis? Seems like there could be some
voodoo you could do with a corresponding point on the opposite side kind of thing. :-D
curve from 2D to 3D, either along the vertical or X axis? Seems like there could be some
voodoo you could do with a corresponding point on the opposite side kind of thing. :-D
Evil, you are starting to lose credibilty because you have not responded to the claim of bounty in your thread here:
https://bitcointalksearch.org/topic/this-message-was-too-old-and-has-been-purged-427712
https://bitcointalksearch.org/topic/this-message-was-too-old-and-has-been-purged-427712
Whether order of N or sqrt N I believe the N for vanitygen is 2^160 because any key pair that hashes to the address will do. However for cracking the key directly N is 2^256
It is not sufficient to find a collision in the 2^160 space.
Even if you find a Keypair, that Hashes to the same RIPEMD160 Bitcoin Address - it would be impossible to sign any outgoing transaction as you have to do it with the full 256bit private key
Listen to yourself here. First you say "if you find a Keypair" then later on in the same sentence you say "it would be impossible to sign" because you "have to do it with the full 256bit private key" but the first phrase in the same sentence is "you find a Keypair".
If I find a keypair that hashes to a specific Bitcoin address then by definition I have one of the (on average) 296 possible private keys that will allow me to move the funds at that address.
I stand by my statement that the search space for a specific Bitcoin addresses is N=2160 and the search space for a specific public key is N=2256
So it turns out that attacking secp256k1 is much more efficient and dangerous than looking for address collisions. Hash functions are designed to be collision resistant, therefore the best you can do is about 2^159 ON AVERAGE operations for RIPEMD-160. There is no group composition/operation with hash functions and that is why we use them.
So we are in agreement that the search space for vanitygen, if used as a Bitcoin address cracker, is 2160 and it is impossible to use vanitygen as a Bitcoin address cracker.
We also agree that the search space for cracking a specific public key is 2256 which is 296 times larger than the search space for cracking a Bitcoin address.
If you are able to quickly compare to 240 known keys in parallel then you have somewhat reduced your search space for cracking a specific public key from 2256 down to 2256 / 240 = 2216
We also agree that the search space for cracking a specific public key is 2256 which is 296 times larger than the search space for cracking a Bitcoin address.
If you are able to quickly compare to 240 known keys in parallel then you have somewhat reduced your search space for cracking a specific public key from 2256 down to 2256 / 240 = 2216
This message was too old and has been purged
Whether order of N or sqrt N I believe the N for vanitygen is 2^160 because any key pair that hashes to the address will do. However for cracking the key directly N is 2^256
It is not sufficient to find a collision in the 2^160 space.
Even if you find a Keypair, that Hashes to the same RIPEMD160 Bitcoin Address - it would be impossible to sign any outgoing transaction as you have to do it with the full 256bit private key
Listen to yourself here. First you say "if you find a Keypair" then later on in the same sentence you say "it would be impossible to sign" because you "have to do it with the full 256bit private key" but the first phrase in the same sentence is "you find a Keypair".
If I find a keypair that hashes to a specific Bitcoin address then by definition I have one of the (on average) 296 possible private keys that will allow me to move the funds at that address.
I stand by my statement that the search space for a specific Bitcoin addresses is N=2160 and the search space for a specific public key is N=2256
Jump to: