Bitcoin Forum
May 27, 2024, 12:13:15 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Project Development / Re: HashBasher 1.0 by HashHyena on: October 17, 2014, 03:24:47 AM
Just a quick note to add.

DO NOT try using this application with bitpays insight server on the web, their server uses the rate limiter and will blacklist your IP after 500-1,000 queries.
2  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 03:21:36 AM
Also, we released the first part of many pieces of software to the public tonight for balance fishing on a local machine. ( https://bitcointalk.org/index.php?topic=826097.0 ) for those who are here with legit reasons other than to troll or prove how narrow minded you are. Feel free to grab a copy and try your hand at it. We will be releasing the blockchain parsing application soon that first exports all addresses with positive balances, then groups them so you know which ones to fish for when your generating addresses. We anticipate it will be about 3 weeks before we get that launched fully as we want to test it heavily in house before anyone else tries it on their PC.

3  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 03:16:27 AM
Read the release notes, They dont hide what they do, and when they have errors. Believe that when the armory team finds a problem with their client that involves security, it gets patched IMMEDIATELY before anything else is done. Armory may not have always been the safest, but they are the best from a business standpoint at taking care of their problems, and they are very quickly becoming the most secure wallet client a person can have, although they are not quite there yet.

I'm waiting for them to include support for compressed keys.

I dont know if they ever will, they already support Hex, Base58, and mini keys. Compressed keys are not used too often and i dont believe they are main stream enough.

BTW, i dont know if you have ever heard of Turbid, but since you are looking for solid Entropy, their project is pretty good and open source. you could make one for a decent price.

Here is the paper, you can find more on google by searching Turbid RNG

http://www.av8n.com/turbid/paper/turbid.htm

Its an open source style of the more expensive RNG's that use audio that i mentioned earlier.
4  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 03:09:11 AM
Good info. Now you alluded to armory having something in its source code that was recently fixed. What was it?

Read the release notes, They dont hide what they do, and when they have errors. Believe that when the armory team finds a problem with their client that involves security, it gets patched IMMEDIATELY before anything else is done. Armory may not have always been the safest, but they are the best from a business standpoint at taking care of their problems, and they are very quickly becoming the most secure wallet client a person can have, although they are not quite there yet.
5  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 02:32:31 AM

DABS,

THANK YOU. Seriously !!!!!!!!!!!!!!!

Yes, i can comment.

The avalanche effect in a semiconductor junction is probably one of the better known sources of Entropy in terms of hardware. I myself and a few of the team own TrueRNG's.

Not all HWRNG's are created equally, and some are more faulty that PSRNG's when you look at the bitmap analysis. (part of the reason why the bad ones dont show it openly)

In my opinion of course, i would say the TrueRNG is worth the money if you intend on storing any real money in something protected by cryptography.

Some of the better HWRNG's that are more secure use ambient noise at the time of reading to generate entropy as well. Go sit in a crowded coffee shop and generate your keys with it and you are for sure secure. I use to have one myself (super expensive) until i spilled coffee on it.
6  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 02:20:39 AM
Stop beating around the Bush, disclose your findings

You're kidding right?

We already did. But let me summarize it for you.

There are a lot of wallet clients in existence that use faulty PSRNG's. The easiest way to find and "prove" this is to parse the blockchain for a list of all addresses ever used. Then group them by the first X characters, (we use X=6 as that is still quite easy to generate using most brute force tools including vanitygen)

Then turn your list into a bar graph, you will find that LARGE amounts of addresses fall in a very small portion of address space.

Because of this, you are cutting out a HUGE portion of the space if you are trying to brute force an address for 1. but most importantly you are opening yourself up to a "birthday attack" of sorts as it is not difficult by any means to compile massive lists of address/private key when your target is only address that start with 1xxxx,1xxxxx,1xxxxx, etc.......

On second thought, we already covered this, i dont feel i need to write it all out again.

The processes is simple, check the address before you database it for a positive balance, then monitor the database in real time for any incoming transactions. (there is a reason satoshi dice is keeping all of its coins in vanity addresses)
7  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 01:58:25 AM
TL/DR

If you can clean it up into a short list of direct questions i can reply, but i am not reading through that entire mess to find the questions.

Thank you.

Cryptography is a complex subject, and cannot always be discussed in 5-word sentences (I even bolded the parts that actually needed addressing). I will try, but you may not like the results.

1. You claim nearly all CSPRNG is flawed. Then, as a workaround, you recommend vanitygen, which uses a.... CSPRNG (a fairly common one, OpenSSL). Can you explain the difference?

2. Your dartboard scheme for creating entropy is slow and biased, the sort of thing no cryptographer would ever come up with. Why did you?

3. You claim that "paperwallets" are superior because they use entropy from a mouse. You cite a bunch of wallet clients you claim to have found "through heavy testing" to be faulty, and yet every one that you cited also uses real-world entropy, just like "paperwallets". Armory, in particular, uses mouse input plus several other sources of real-world entropy. How could a cryptography expert miss this fact?

4. You've made extraordinary claims. If you are unwilling or unable to provide extraordinary proof (which is understandable for a work-in-progress), you will likely be ridiculed unless you can at least provide extraordinary professional credentials for your "few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education." Why have you done neither?

Is that better?

Thank you chris, that is much better

1: With vanitygen you add your own entropy by selecting an address with a 1XXXXXXX prefix, there is nothing random about it short of what comes after 1XXXXXX by selecting XXXXXXX you move yourself out of the over used "random" space

2: I wont argue this, instead i issue a challange, 1, Get drunk, i mean tipsy drunk. 2, attach 5 note cards (3X5) to the wall. 3, stand back 20-25 feet from them. 4, try and hit one, then try and hit the same one again. Smiley    (in short, its fun, and more random than you will get from most other sources)

3: I really dont want to get too much into this one, If your making this claim, i assume you have looked through the entire source code for armory before (prior to their latest 2 releases) so there really is no need for discussion here.

4: Right, and wrong at the same time. We are not making claims nor trying to convince anyone of anything, that would be futile around here to say the least, this is a community filled with sheeple, trolls, and the under educated with a few bright minds mixed in to try and balance it out. We knew this coming in. Instead, we are releasing some of the software we have developed to allow others to do it themselves. As more participate, the "thefts" (hopefully will be returned to their rightful owners upon proving a point) will begin to happen more often, and sooner or later someone will hit something BIG or nail someone of importance and when they speak up, then there will be nothing left to discuss.

 


This is worthless, you never give reasonable answers.

^^ AWWWWW you hurt our feelings  Kiss
8  Bitcoin / Project Development / HashBasher 1.0 by HashHyena on: October 17, 2014, 01:52:25 AM
Hash Basher V 1.0

The Hash Hyena team is happy to release its first of many tools to come. Hash Basher 1.0

Hash Basher is a java based balance checker software able to check upwards of 1,000 addresses per second for a positive balance.

Dependencies;

JRE & JDK

Bitcoin insight

VMware if you are not already running linux as your main OS

a modified version of the ever popular vanitygen software which outputs in .csv format (provided, or you can compile your own)

Download link for Hash Basher & the modified vanitygen: Here


Instructions

1: Install VMware workstation

2: Install Ubuntu 14 on your VM with a Min of 120gb VHD

3: Install Bitcoin QT & Bitcoind on your VM

   > $ sudo apt-add-repository ppa:bitcoin/bitcoin
   > $ sudo apt-get update
   > $ sudo apt-get install bitcoin-qt
   > $ sudo apt-get install bitcoind

4: Start Bitcoin QT and let it download the blockchain 100%

5: Install Node.js LEGACY on your VM

   > $ sudo apt-get install nodejs npm nodejs-legacy

6: Install Bower on your VM

   > npm install -g bower

   If you get an error message use the below code

   > sudo chown -R $USER /usr/local
   > npm install -g bower

7: Install Insight on your VM

   > $ git clone https://github.com/bitpay/insight.git && cd insight
   > $ npm install

8: Open your bitcoin configuration file

     Open "files" then hit ctrl+h to show hidden files, open .bitcoin and open bitcoin.conf

9: add the following to your bitcoin.conf file then save the file

   rpcallowip=*
   rpcport=8332
   rpcconnect=127.0.0.1

10: Start Bitcoind

   > $ bitcoind (you will not see anything once you hit enter, give it a minute then close it, you can see if it is running in the system monitor it should continue to run after you close the terminal)


11: Open a notepad (gedit) in your VM and copy the following

     INSIGHT_NETWORK=livenet BITCOIND_USER=user BITCOIND_PASS=pass npm start

12: replace "user" & "pass" with the user & password specified in your bitcoin.conf file

13: Either save the file as an executable in your insight folder or save it as a text document that you can copy and paste from

14: If you saved the file from 13 as an executable, double click it, it should start insight for you. Go to your browser and go to localhost:3000 and you should see insight syncing. Wait until it sync's 100% before doing anything else

15: if you saved the file from 13 as a text file, open a new terminal window

   > $ cd insight
   > $ COPY AND PASTE THE LINE FROM THE FILE HERE

16: if you get the econn refused error, you either do not have bitcoind running, or bitcoind is not 100% synced with the network.

------- This conculdes the Insight setup portion ------

In your windows desktop

1: create a new folder

2: place the main.java & run.bat file in the folder

3: Open a blank notepad

4: in notepad, click open, then navigate to the folder where you pasted the files

5: in the dropdown where it says .txt select "all files"

6: Open run.bat

7: change the "C:\ path to your java bin" with the location of java on your PC, if you do not have JDK and JRE installed, install them, then replace the "c:\ path" then save the file

8: In your VM open a new terminal and type "ifconfig" to get the ip address of your vm

9: in windows open a browser and go to xxx.xxx.xxx.xxx:3000 (your VM's IP address) and you should see insight load in the browser.

10: open a new notepad, again browse to the folder you copied the files, and open the main.java file

11: replace the xxx.xxx.xxx.xxx:3000 line with your VM's insight address you just tested in step 9. Then save the file

---- Your program should now be configured -------

With the version of vanitygen supplied (or compile your own)

generate a file to check the balance's of by running the steps below

1: open a command prompt

2: cd (the location of vanitygen)

3: vanitygen -k -o in.csv 1(your prefix)

4: the version of vanitygen supplied outputs the files directly to the csv format needed by the balance checker, if you use the normal vanitygen, you will need to find your own program to parse them into the correct format.

5: copy the in.csv file to the folder where you put the java program from above.

6: click the run.bat file, you should see a new command prompt open and start checking balances.

--- side notes -----

The program works 100X faster if you ask it to check the balances of addresses with the same prefix. for

example all the addresses start with "1A" instead of just asking it to search for all addresses (if you just put 1 as your prefix in vanitygen)

If the program finds a balance it will print it in the out.txt file the second it is found.

We have clocked the program at .8ms per address or roughly 1,000 addresses per second. DO NOT expect these

results if your PC has little resources, low ram, or a slow CPU. Each of our machines is running 8 core i7

5960X's with 16 gigs of ram (4 cores and 8 gigs to the VM)

DO NOT expect to find someones private key with a positive balance this way. We had been running 20 machines

24 hours a day (checking roughly 1,728,000,000 a day) for 9 months before we found a single collision

(466,560,000,000 in total to find a .00000001 balance address)

There are ways to increase your odds at finding a positive balance in which we have used to collect over

20BTC with now, those will be explained later. Still without a lot of money to invest, your odds are slim to

none. Although if thousands of people start trying it will start happening more and more often.

Do not delete your files once you check their balances. We will be releasing a software soon that allows you

to index them and monitor the balance of them in real time non stop for all of eternity. You would be wasting

computer power and electricity to not save and index them when we launch the software.



Support from the team will be handled in this thread only, and only until it gets to difficult to find the people who need support mixed in with all of the trolls. If you are having difficulties and do not seem to be getting a reply from us, please try messaging us directly and we will make every attempt to get you up and running as soon as we can.



9  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 17, 2014, 01:22:16 AM
TL/DR

If you can clean it up into a short list of direct questions i can reply, but i am not reading through that entire mess to find the questions.

Thank you.

Cryptography is a complex subject, and cannot always be discussed in 5-word sentences (I even bolded the parts that actually needed addressing). I will try, but you may not like the results.

1. You claim nearly all CSPRNG is flawed. Then, as a workaround, you recommend vanitygen, which uses a.... CSPRNG (a fairly common one, OpenSSL). Can you explain the difference?

2. Your dartboard scheme for creating entropy is slow and biased, the sort of thing no cryptographer would ever come up with. Why did you?

3. You claim that "paperwallets" are superior because they use entropy from a mouse. You cite a bunch of wallet clients you claim to have found "through heavy testing" to be faulty, and yet every one that you cited also uses real-world entropy, just like "paperwallets". Armory, in particular, uses mouse input plus several other sources of real-world entropy. How could a cryptography expert miss this fact?

4. You've made extraordinary claims. If you are unwilling or unable to provide extraordinary proof (which is understandable for a work-in-progress), you will likely be ridiculed unless you can at least provide extraordinary professional credentials for your "few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education." Why have you done neither?

Is that better?

Thank you chris, that is much better

1: With vanitygen you add your own entropy by selecting an address with a 1XXXXXXX prefix, there is nothing random about it short of what comes after 1XXXXXX by selecting XXXXXXX you move yourself out of the over used "random" space

2: I wont argue this, instead i issue a challange, 1, Get drunk, i mean tipsy drunk. 2, attach 5 note cards (3X5) to the wall. 3, stand back 20-25 feet from them. 4, try and hit one, then try and hit the same one again. Smiley    (in short, its fun, and more random than you will get from most other sources)

3: I really dont want to get too much into this one, If your making this claim, i assume you have looked through the entire source code for armory before (prior to their latest 2 releases) so there really is no need for discussion here.

4: Right, and wrong at the same time. We are not making claims nor trying to convince anyone of anything, that would be futile around here to say the least, this is a community filled with sheeple, trolls, and the under educated with a few bright minds mixed in to try and balance it out. We knew this coming in. Instead, we are releasing some of the software we have developed to allow others to do it themselves. As more participate, the "thefts" (hopefully will be returned to their rightful owners upon proving a point) will begin to happen more often, and sooner or later someone will hit something BIG or nail someone of importance and when they speak up, then there will be nothing left to discuss.

 
10  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 14, 2014, 07:02:04 PM
Hash Hyena, I have a couple of questions / points which I hope you can address. The first is related to your interim key generation recommendations.

"any other" RNG does not really solve the problem as we have found through heavy testing that Armory, Electrum, MultiBit, and just about every other wallet client out there has the same problems. The problem really is ANY RNG that is based on software.
1: use vanitygen to generate an address which falls far out of reach of the clustered address space, for example, the odds of your address eventually becoming part of someones catalog if it starts with 11121******************* is 667% more likely to happen then if your address starts with 1iBPq******************* for example.

Given that vanitygen is just another CSPRNG, and therefore flawed by your reasoning, why would you recommend it over any of the others you mention above (all of which use, exclusively or at least in part, the same OS-provided source of entropy)? In fact, vanitygen intentionally decreases entropy when it throws out generated keys which do not match the predetermined pattern, which would (slightly) decrease the security of the generated keys.

2: Use real world high entropy sources, a deck of cards, Hexadecimal dice, numbers and letters pulled from a hat. Myself personally and a few of the guys already on the team for this project we throw darts at a very large dart board that we made that has 0-9, a-f listed about 400 times each in a random pattern on a 4' X 4'  custom dart board we made. The entropy is higher if you are drunk when throwing the darts as your hand eye coordination makes it like trying to hit a moving target  Wink

First of all... how did you generate the random pattern of digits on your dartboard to begin with?

Regardless, any single set of random data is of course itself randomly biased, including your dartboard, and re-using it naively like this (I assume you don't create a new dartboard for each throw) combined with human bias will introduce that bias into its output. For example, it's very likely that there exists a hex digit on your dartboard which occurs less frequently on the periphery than it does towards the middle. Since I presume you'd avoid aiming your darts such that they might miss the dartboard, this hex digit is more likely to occur in your generated output.

In fact, a much better approach which would lead to less biased random numbers (assuming that the individual target boxes are small enough) would be to use a regular repeating pattern for the dartboard, where each 4x4 section contains exactly all 16 hex digits. How is it that nobody on your team caught this?

(This is to say nothing of the fact that throwing 64 darts at a dart board is silly-inefficient compared to just shuffling (well) a deck of cards...)


Next, moving back to your assessment of alternative clients:

"any other" RNG does not really solve the problem as we have found through heavy testing that Armory, Electrum, MultiBit, and just about every other wallet client out there has the same problems. The problem really is ANY RNG that is based on software.

Paperwallet is a better source as it uses coordinates of a mouse on the screen so it has i direct input which affects the output. Something like that built into a wallet client would not be feasible as no person is going to sit behind a PC at bitpay and wiggle a mouse every time someone needs a payment address generated.

First it should be noted that all of the clients you mention above (including BitAddress.org, which is I assume the paper wallet to which you refer) begin with the same source of OS-provided entropy (/dev/random on Linux/BSD or CryptGenRandom on Windows). Even though these two sources of entropy are in part provided by deterministic processes, they also use external human-influenced sources to maintain their internal state, e.g. the starting of programs, the initiating of or receiving of network traffic, the timings of writing to or reading from disks, etc. It is inaccurate to claim that the wallet clients you mentioned do not use significant amounts of human-source entropy.

Next, let's move on more specifically to your assertion that "through heavy testing that Armory ... has the same problems." Given that Armory gathers entropy from some of the same sources [github.com] as "paperwallet" (in fact it gathers entropy from many more human-influenced sources than "paperwallet"), can you explain why Armory has a flawed CSPRNG, whereas "paperwallet" does not?


Given that you've said
there are about a dozen of us [developers] working on this now, along with a few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education
I find it extremely discouraging that you can make such basic errors as those outlined above. The net effect is to make me exceedingly skeptical of not only your overly-broad claims (which cannot be proven nor refuted due to their vague nature), but also of your abilities as mathematicians and cryptographers and even your intentions. Posting your team's professional qualifications (names, degrees, and peer-reviewed publications) would go a long way toward alleviating some of these concerns, even if you choose not to be more specific regarding these alleged vulnerabilities still under investigation.

I also hope that you can specifically address the questions above.

TL/DR

If you can clean it up into a short list of direct questions i can reply, but i am not reading through that entire mess to find the questions.

Thank you.
11  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 14, 2014, 12:33:24 AM
I the mean time, any developers who want to jump on board to help speed up development for the user friendly platform, please message us, there are about a dozen of us [developers] working on this now, along with a few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education.

This is an interesting project, but I have some questions as a spectator of it. Do they do it as a hobby in their free time? If not then who is paying the team? Are they on a payroll? What is your budget that you are dedicating to this whole operations? Because you can't do it with 3.3 BTC.

We are a little confused  as to your questions. Are you asking do we get paid to play around with brute forcing and birthday attacking the bitcoin address key space? Or is someone paying us to exploit the PSRNG faults in most wallet clients?

As for budget, we dont have nor need one. The whole project is nothing more than a now large and ever growing collection of people from various aspects that relate to the project in some fashion either writing code, improving methods, researching and calculating various stuff or just dedicating a little computing resources to the project. The core team funds our own hardware ( hard drives, electricity, servers, and massive raw computing power) It is all play money, dedicated to being wasted on having fun with exploiting anything bitcoin we can. Any exploits, faults, issues we find with any wallet client, web service, etc. usually results in a report being sent to the service provider notifying them of the issue. One of the biggest wallet clients in use today had one of the biggest problems that was easy to exploit. within 2 weeks of reporting it with a demonstration to show exactly what was happening they had released the next version which fixed the problems.

^ they wished not to be named to avoid false panic as everyone that downloads the latest release will no longer have the issue.
12  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: October 04, 2014, 01:24:26 PM
Any news from Hash Hyena?

Hi Burt,

a lot of progress, and a small amount of BTC claimed already, but nothing we would brand as "news" yet. Poke around the web a bit over the past week and a half and you will start to see a pattern or trend of people asking "did anybody else have their bitcoin stolen"? or things of that nature,  but we have not hit a target big enough, or enough small targets to brand it or make it news worthy as any publication of anything at the moment will result in nothing but a bunch of trolling from the mindless masses of sheeple in the crypto currency space. As time progresses more and more clear patterns emerge where the real source of the missing bitcoins come into question things will become more clear. For now, if you are one of those unlucky few who have become victims. Please maintain the address your BTC was hijacked from as we will be returning it to its rightful owners once enough have been collected to make an impact, all you will need to do is show you can send a transaction from the hijacked address showing you were the original holder of the private keys for that address.

In the interim, anybody wanting copies of some of the tools we are using, and help getting set up so you too can participate, please contact us and we can get you some of the pre-release versions with limited functionality (still enough to start grinding away at claiming BTC). we are aware that there will be people with malicious intents using this software and we can do nothing about that, but we ask that you refrain from doing so and that any BTC you can claim and move is returned to its rightful owners upon proving they were in possession of the keys for that address in the first place

Things you will need beyond our tools.

Either a dedicated Linux machine, or a VM with at least 2gigs of ram.
JRE and JDK
a host machine with fair amount of hard drive space and recommended 4 gigs of ram.

We will gladly walk you through getting everything set up until requests exceed our time limits, please keep in mind we are still working hard at finishing all the tools so everyone can participate so we are limiting our time in "setup assistance"
13  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 24, 2014, 03:24:08 PM
One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays

Hey, I wasn't trolling. I thought you were. I was just answering. I did not realize it at first but you are talking about a possible fault in the PSRNG. I personally use vanitygen because it seemed like a good idea for cold wallets.

The only time I let bitcoin core generate addresses for me was when I was sending bets to satoshidice.... a long time ago.


Quote
This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.

Since I use vanitygen, then I guess my coins are safe. There's another program out there called paperwallet or paperwal that, to me, seems to use the entire address space. Those generated addresses would probably be secure.

And of course, when I am really bored, I roll 100 dice. (or take random pictures and generate a key out of that.)

Basically, use any other RNG but not the one in bitcoin core. The android client had a big problem some time ago, related to the RNG.

Our apologies for accusing you of trolling,

"any other" RNG does not really solve the problem as we have found through heavy testing that Armory, Electrum, MultiBit, and just about every other wallet client out there has the same problems. The problem really is ANY RNG that is based on software.

Paperwallet is a better source as it uses coordinates of a mouse on the screen so it has i direct input which affects the output. Something like that built into a wallet client would not be feasible as no person is going to sit behind a PC at bitpay and wiggle a mouse every time someone needs a payment address generated.

The bottom line is, computers cannot generate randomness on their own, for it to be truly random it needs human input. The solution will be in the scope of something that requires a 3rd authentication process to spend bitcoins from an address. We ourselves have had many discussions on what a solution would be, but we do not have the answer yet. only ideas. 
14  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 24, 2014, 03:08:48 PM
It is true that faulty random number generation can lead, and in the past has led, to bad things happening including loss of BTC.

If it is true that there is a widely distributed faulty random number generator being used to generate private keys and digital signatures then that needs to be found and fixed as soon as possible.

This all leads to a very interesting side issue:  how can you ever prove you have taken someone else's BTC using this or any other method?  Ideally you would have someone very reputable come forward and say "someone took my BTC in this transaction" and post the transaction.  This could be followed by the party that took them coming forward and signing a message with the private key of the destination address of the transaction in question.

The reputation of the person that lost the BTC in the transaction would have to be beyond reproach as there are many ways to fake this whole "Proof of Theft" scenario.

I believe that your idea of having someone of high reputation run your program, with it they create a verifiable address collision, and then they report the address collision would also work as proof that you are on to something.

We greatly feel the same way. hence the reason we are taking to time to re-develop the entire platform to make it basic user friendly on our own dime and then giving it away to the world. We could talk about doing it all day long, but as you said, the proof is in the pudding. Some of the higher reputation members would need to build large catalogs themselves and then find a collision. We are not doing this to troll, not for the thrills of stealing bitcoin, surely not to make a profit as the hard drives and hardware we have had to buy ourselves exceeded a cost that we could ever hope to recover through BTC theft. This is simply to allow easy access to the right people that need to do this in order to "prove" it. We have done it, we can prove it, but not to a level which will satisfy the community, so we are going to allow everyone to take a shot at it in hopes that the right person gets it done.
15  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 24, 2014, 02:58:23 PM
Wouldn't one of those hardware random number generators solve this?  Could something like http://www.entropykey.co.uk/ be incorporated into a wallet system.

Yes, to a point. The biggest part of the fault is that the PSRNG's after a period of generation across a large scale tend to cluster outputs, meaning a large part of addresses fall in a small part of the key space. As a temporary solution for added security if you yourself are trying to store any amount of bitcoin long term, we can recommend one of a few methods for now.

1: use vanitygen to generate an address which falls far out of reach of the clustered address space, for example, the odds of your address eventually becoming part of someones catalog if it starts with 11121******************* is 667% more likely to happen then if your address starts with 1iBPq******************* for example.

If you extract a total list of all bitcoin addresses ever used. Then turn them into a line graph based on the first 6 characters of the address then sort them alphabetically and numerically you will see better what we are talking about. A scary large amount of addresses fall within a very small percentage of the total available address space. That in and of itself is roughly 60% of why we have been able to be successful with our project.

2: Use real world high entropy sources, a deck of cards, Hexadecimal dice, numbers and letters pulled from a hat. Myself personally and a few of the guys already on the team for this project we throw darts at a very large dart board that we made that has 0-9, a-f listed about 400 times each in a random pattern on a 4' X 4'  custom dart board we made. The entropy is higher if you are drunk when throwing the darts as your hand eye coordination makes it like trying to hit a moving target  Wink

3: store your bitcoin in multiple addresses to ensure that the prize isn't sitting in one location, myself i have about 40 addresses with positive balances at any given time. Not a single one has more than BTC5 in it, and not a single one has ever been online. I use paperwallets created from a 5 year old laptop with no hard drive or NIC card in it. I use the darts to generate keys, then use an ubuntu live cd to make the paper wallets on my own custom template which folds and then fits inside of a 4 screw acrylic baseball card holder. I then keep the acrylic cases spread between a few separate safety deposit boxes at a few banks. Most of them are left in my will to my wife and daughter.

There are several safer ways to store bitcoin and keep it safe. The security problem is not in finding safe ways to store bitcoin, the problem is in using bitcoin for commerce as those wallet clients and even the bitcoin core itself continue to dump addresses into the clustered regions of the address space. When it becomes a serious problem, retailers will lose faith in it as a payment method and adoption of acceptance will begin to fall.

 
One day, maybe in a few months or a few years, we might slowly migrate over to 512 bits. Suddenly, you're just wasting disk space.

And don't forget about compressed keys.

Any disk space spent in the processes of trying to force the hand of the bitcoin core devs to fix a problem is not wasted. Your very narrow minded comment shows you have very little understanding of core address concepts and where security faults lay. 512 bits would just require re-building new data tables and populating them with new data based on the faults in PSRNG's. yes it would now require double the disk space to store them until better compression methods are developed, but it still does not fix the problem.

Your feeble attempt at trolling with such replies only discredits your comments and speaks poorly on your intelligence or ability to understand where the problem lays

You might be interested in the 50 BTC reward offered in the following post.  The offer has expired but you might be able to talk Greg into extending the deadline just for you.

So you claim you can crack some random keys provided by people on the forum? Oh really.

Well here, I'll make it very profitable for you then:

Quote
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I, Greg Maxwell, do hereby promise to pay 50 BTC to the first person that
provides the discrete log of _any_ of the following randomly generated
200,000 secp256k1 public keys. This offer is open until 2014-04-01.

None of the below public keys have been used on the Bitcoin blockchain as
of the time of the creation of this offer.

04abb9239d3a5131de45b977807c62bf879119b05c3da33e37d8e7be0901985ce73b6ca6dff5b97 34d1225ce0120bbe023066669c29e23d3ea82de9a57dd259b63

Full message at https://people.xiph.org/~greg/keysfun.asc

Surely if you can crack a single key provided by a person in the thread cracking any one of 200k keys should be a cinch.

This in itself is not an achievable target. If he used true entropy not from software or a computer, these 200k addresses fall across the entire keyspace, the problem is that to date mainly due to commerce and the bitcoin core, a VERY LARGE amount of addresses fall in a very small portion of the space.

The project is not aimed at trying to target a specific address, or even 200k specific addresses, the project is aimed at cataloging those small portions of address space which are heavily over populated with positive balances based on the core PSRNG's faults thus seriously increasing the odds of gettins someones bitcoins. The address is not what is important, the address space is. If that makes any sense.
16  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 24, 2014, 01:25:52 PM
Ok, we can keep it going here for now so long as the OP does not get upset over it.

The process in grabbing bitcoin from "collisions" successfully is a little more complicated than even you guys are pointing out now. But you are all on the right track. 95% of the equation is faults in the PSRNG's that almost all wallets or services use. So although that makes it a wallet problem. The wallet problem makes it a Bitcoin security problem as we all know that a computer can never truly generate random numbers.

We will explain how we have had success in a much greater depth in the weeks to come which will make it make a lot more sense. But still the magic is in having others, hopefully some of you with a few TB to spare do it yourselves. Once you do it successfully then the speculation and "i am a genius with big numbers" rhetoric can stop and we can all continue to bash away at the faults in the system forcing change and security. Sadly probably killing the price of BTC for a few months in the process.

It may sound malicious, and in the short term it is, but in the long run, its better to have it happen now while bitcoin is young so it can be fixed then years down the road when an issue like this could kill bitcoin forever. That is the reason we are going to open source the entire project. A few of us could do everything including steal YOUR bitcoin if that chance came up. But no matter what there would be tons of opposition saying that it was staged, faked, or whatever no matter how much you claimed you got ripped off. Let everyone have a chance at doing it themselves, Make a game out of it, track statistics through a web interface, etc. let the world have some fun with it, sooner or later people are going to realize that it is really happening, and change will be forced.

The reason it is taking time to get the platform released publicly is because we ourselves used a very complex Oracle DB which cost a small fortune. Not everyone can afford Oracle licenses, and to be honest, most already existing DB platforms either under perform for this purpose, or over complicate things so the basic user could not work it. So we are developing a way to replicate our platform WITHOUT using and existing DB technology so even the most basic of user can use and understand everything.

Please feel free to continue to speculate, post the fancy statistics and exponents on how impossible this all is as if the math is the only thing that matters. (that is not sarcasm, having all of that on the table when we get the time to show how it is done when we launch will make things easier to understand) and we will do our best to get this all launched as soon as we can.

I the mean time, any developers who want to jump on board to help speed up development for the user friendly platform, please message us, there are about a dozen of us [developers] working on this now, along with a few dozen mathematicians, statisticians, and even a half dozen cryptographers with over 45 years combined education. We are not hostile, in fact we are quite the friendly bunch. Although the process is malicious, the end result could save our precious bitcoin from total failure. It can happen, ask any one of the core developers, there are a lot of faults in BTC that could cause it to die if exploited, they wont list them for you, but the will confirm they exist and it is very possible. We just happened to find one.

Thanks for reading  Cool
17  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 23, 2014, 06:59:41 PM
We just wanted to add,

We can have this discussion on another thread soon, we do not want this to hijack DSV's thread. we just wanted to make a quick announcement in a place where interested parties were hanging out. If you feel you have some trolling to do, message it to us for now you can copy/paste it in a few days when we get our own thread up and running. Lets let the OP keep his thread clean and on topic.
18  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 23, 2014, 06:44:14 PM
Amazing to see the community pulling together to finally point out a serious weakness in Bitcoin. We. the Hash Hyena's have been hiding in the shadows for a long time for developers to put their talents to use in forcing hard fixes to some of these weaknesses.

Thank you to all of you developers for your efforts. We do not care how much a misinformed community may laugh at the probabilities, and big numbers like they mean impossibility. Its real, it has happened, and it will continue to happen.

For any developer that would like the proof, and like to join forces with the Hash Hyena's on the "Hash Hyena" project to further development on our new platform that we intend to open source and soon release to the world please message us directly through BitcoinTalk.

For the rest of you, If you want to get leaps and bounds ahead of everyone else in the game when we officially launch the Hash Hyena software do these two things.

1: start stocking up on hard drives. The more storage space the better. ( we currently have 1.18PB and growing )

2: run the line of code below in vanitygen, make tons and tons of output files and start storing them, we will soon release the program that converts them into .csv files that we use for importing. The more files you have when we launch the further you are ahead of everyone else when this all goes public in a few short weeks or months.

Code:
vanitygen64 -k -o output.txt 1

We will be releasing a batch file for those of you with high performance CPU's to run multiple outputs at a time in a nice little packaged .rar download. We will be starting our own thread soon
Hyena?  Do you mean Laughing Hyena as in this is a total joke Hyena?  Or, worse yet you are serious and just not very good at basic math?

Or better, just over 1 PB worth of data storage and we managed to nab a few transactions from the blockchain already. Next, it has nothing to do with basic math, there is nothing basic about the math behind any cryptographic function. Lastly, who needs 50% of the addresses? if a few thousand people had a few quadrillion addresses each it makes up a large enough percentage that a person is no longer chasing a moving target. It also means that every time you move your bitcoins, you have to wonder...... Has someone got the key for this address?

Ask yourself, how many bitcoin supporters are going to feel comfortable with their investment knowing that 15%, 10%, 5%, hell eve 1% of all bitcoin addresses are indexed and monitored. (the fed has already done this, that is where this project stemmed from)

Imagine everyone involved in crypto currency to date had the ability to randomly generate addresses using the same faulted PSRNG system that 80% of wallets use and fill even 100 gigs of space on a hard drive. How comfortable do you feel with your investment then?

Imagine as hard drives and storage become cheaper, As is we are already buying 6TB drives for $190usd. You can already go make a $70 investment and buy a 1TB external. With our software's it would take maybe a week for you to fill it and monitor it in real time. take that multiplied by even a thousand, and growing daily. How comfortable are you with your investment then?

Imagine next year when Segate launches its first 10TB 5,200rpm HDD for only $350. (already in the works) Thats pocket change for most of us here....... You get the point. How comfortable are you with your investment then?

If you can honestly say that you still have no worries about your bitcoin after taking all that into consideration, then you sir are an idiot with no common sense.

Granted we are not giving you the WHOLE story yet, waiting on a few final developments that will make it all more platform neutral and basic user friendly so we are not just talking about it but letting everyone do it. But in summary, about a year ago, we were where you are now. In the very recent past, we have hijacked about 3.3BTC from a total of 5 addresses.

Developers who want to join the team and help spread awareness get the source now pending their contributions as well as a basic overview of how it works. The rest will have a beta platform within the next month or so to start cataloging their outputs, in a few months anyone who has some hard drive space that wants to catalog some bitcoin addresses has a chance to play along.

Final disclaimer,

Yes, if we find bitcoins we are taking them but this is not about being thieves. its about making people aware that 75% of the hype about bitcoin security is FALSE, even by the admission of some of the current bitcoin core developers. A direct quote from one of them in a recent interview "It is scary how many people have invested so much money in such a young technology that is filled with security flaws". We ourselves could not possibly steal enough bitcoin to make a difference, but as a community (full of thieves anyways) we could chip away at it and tally up enough hijacked coins over time to force the hand of the developers to assess the important and most prominent security flaws NOW before it drives bitcoin into the ground.

If you want to troll, go for it, we all love a good laugh and 80% of us on this forum are only here to see the dumb stuff anyways. Otherwise, just hang on and we will get you software soon so you can participate and put some of those old no longer used hard drives to good use.

BTW: Yes Hyena's laugh, ever wonder why? THEY ARE THE BIGGEST THIEVES IN THE ANIMAL KINGDOM
19  Bitcoin / Project Development / Re: 2^256 Deep Space Vagabond on: September 23, 2014, 01:50:44 PM
Amazing to see the community pulling together to finally point out a serious weakness in Bitcoin. We. the Hash Hyena's have been hiding in the shadows for a long time for developers to put their talents to use in forcing hard fixes to some of these weaknesses.

Thank you to all of you developers for your efforts. We do not care how much a misinformed community may laugh at the probabilities, and big numbers like they mean impossibility. Its real, it has happened, and it will continue to happen.

For any developer that would like the proof, and like to join forces with the Hash Hyena's on the "Hash Hyena" project to further development on our new platform that we intend to open source and soon release to the world please message us directly through BitcoinTalk.

For the rest of you, If you want to get leaps and bounds ahead of everyone else in the game when we officially launch the Hash Hyena software do these two things.

1: start stocking up on hard drives. The more storage space the better. ( we currently have 1.18PB and growing )

2: run the line of code below in vanitygen, make tons and tons of output files and start storing them, we will soon release the program that converts them into .csv files that we use for importing. The more files you have when we launch the further you are ahead of everyone else when this all goes public in a few short weeks or months.

Code:
vanitygen64 -k -o output.txt 1

We will be releasing a batch file for those of you with high performance CPU's to run multiple outputs at a time in a nice little packaged .rar download. We will be starting our own thread soon
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!