Large Bitcoin Collider (Collision Finders Pool)

[Jude Austin]

I had the same idea.

I've been searching for a collision for years using a custom address generator that checks against my Insight server.

I had a similar idea for a pool but a little nicer:

Everyone connected searches for a collision.

If a collision is found the private key is sent from the miner to the server encrypted.

Then on the front page of the pool announce the finding, transfer the funds with a message to the owner.

If the owner signs a message with the address their funds are refunded, if not, distributed to the miners.

This way nobody just steals peoples coins if a collision occurs.

I could make a "pool" and "miner" for this but I didn't think people would be interested.

[johan11]

I had the same idea.

I've been searching for a collision for years using a custom address generator that checks against my Insight server.

I had a similar idea for a pool but a little nicer:

Everyone connected searches for a collision.

If a collision is found the private key is sent from the miner to the server encrypted.

Then on the front page of the pool announce the finding, transfer the funds with a message to the owner.

If the owner signs a message with the address their funds are refunded, if not, distributed to the miners.

This way nobody just steals peoples coins if a collision occurs.

I could make a "pool" and "miner" for this but I didn't think people would be interested.

Yes interest, and  if you need i first beta tester

[rico666]

If a collision is found the private key is sent from the miner to the server encrypted.
Then on the front page of the pool announce the finding,

So far so good.

transfer the funds with a message to the owner.

Which owner? The original owner or the new owner? Transfer where? A new address is needed to transfer.

If the owner signs a message with the address their funds are refunded, if not, distributed to the miners.

What period would you see as sufficient to wait? 1 year? More? Less?


Rico



PS: The LBC Pool found it's 1st bounty.

[deisik]

PS: The LBC Pool found it's 1st bounty.

Why didn't the Bitcoin price crash already?

[rico666]

PS: The LBC Pool found it's 1st bounty.

Why didn't the Bitcoin price crash already?

Because a Bounty is supposed to be found? Especially if it has been placed/planted intentionally in the pools vicinity?

Next Bounty: https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8


Rico

[deisik]

PS: The LBC Pool found it's 1st bounty.

Why didn't the Bitcoin price crash already?

Because a Bounty is supposed to be found? Especially if it has been placed/planted intentionally in the pools vicinity?

Next Bounty: https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8

Well, let us know when you find something worthy of general public's attention. Or, rather, let me be the first to know so that I could safely and timely get rid of my Bitcoin stash (however small it might be) before the markets implode on hearing the news...

Or even try to short some coins

[rico666]

Well, let us know when you find something worthy of general public's attention. Or, rather, let me be the first to know so that I could safely and timely get rid of my Bitcoin stash (however small it might be) before the markets implode on hearing the news

Given the amount of crap you have unloaded so far to the general public (nothing worthy of general public's attention), I think you'll hear it 1st in the news than from me.

Rico

[Jude Austin]

I found the Bounty.

[ryanc]

FYI, someone already did a search of the addresses of the first 2^50 private keys.

Do you have source code for your tool? Some people don't like running random binaries, and I've already released code that's a lot faster than the speeds you're reporting for doing sequential address searching.

[rico666]

FYI, someone already did a search of the first 2^50 addresses.

Do you have source code for your tool? Some people don't like running random binaries, and I've already released code that's a lot faster than the speeds you're reporting for doing sequential address searching.

• Link to previous search project?
• How about reading the README.txt?
• How about contributing your code (and to kill two birds with one stone? ... well 3 actually)

@Jude Austin: congrats.
https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8
Another bounty will be planted.

Rico

[ryanc]

• Link to previous search project?
• How about reading the README.txt?
• How about contributing your code (and to kill two birds with one stone? ... well 3 actually)

@Jude Austin: congrats.
https://blockchain.info/address/1TinnSyfYkFG8KC3gZ72KpYxBXsxSadD8
Another bounty will be planted.

Rico

Your README makes no indication of source being available, and I didn't want to download the whole archive to look.

I'm not aware of the person who did the 2^50 search having published any results, I've just inferred it was done. I've got a blog post about that in progress to be posted soon.

My code's up at https://rya.nc/brainflayer, and I think you could use it as-is with a wrapper script. It includes the ability to do search existing addresses for matches. I think I get around 550k/sec on my i7-2600 running on all cores. I always simply include all addresses seen on the blockchain regardless of whether they've got a balance.

A friend and I did a talk at a conference last month which briefly mentions sequential search: https://vimeo.com/177318833.

Vanitygen uses some techniques to generate addresses without computing individual private keys, and is similar to a randomly ordered search. I could probably hack something together that does that style of search against a large list of addresses, though I think it would be a waste of energy to run that.

[ryanc]

Oh, also, while I'm commenting about this, I'll mention that if you want to do a massive private key search, you may also want to search for transaction nonces as well. I think that should at least triple your chances of finding something, though the odds are still absurdly small.

[rico666]

Your README makes no indication of source being available, and I didn't want to download the whole archive to look.

It seems either we are talking about different READMEs then, or we at least have different text understanding traits.

Code:

Q: Is this software secure?

A: If you have a genuine version - yes. To make sure, never download
   anything that claims to be LBC from any other source than
   http://lbc.cryptoguru.org:5000/download
   If you want to be extra-sure, check the md5sums at 
   http://lbc.cryptoguru.org:5000/downloads/LBC-client/md5sums
   for the MD5 sums of all relevant files. On your command line,
   verify the files by doing
   > md5sum "filename"

Q: No, I mean can I trust *you*?

A: Send me 100BTC and I will send them back to you. After this, answer
   the question for yourself. The LBC is compiled Perl source - it's
   scattered, but ultimately you can look at it in the text
   editor. The generate binary is a derivative of
   https://github.com/saracen/bitcoin-all-key-generator
   with just added command line parsing for block offsets.
   Other than that, observe the LBC thread(s) on bitcointalk.org
   for any complaints. If in doubt, don't use the software.

Ah brainflayer... I have played with it in the past and I will certainly look at the talk about sequential search.
Right now it seems like a nice exercise in bloom filter application, but at the moment I'm unable to see it's use for any of my projects.

I think I get around 550k/sec on my i7-2600 running on all cores. I always simply include all addresses seen on the blockchain regardless of whether they've got a balance.

Currently I get on 4 cores of my notebook 8M/min (~ 133k/sec) and checking only against addresses with funds, which is slower than your 550, although I wouldn't say a lot. However, I believe, a single modern CPU core should be capable of generating and testing around 500k/sec, so that is my goal. Not to speak of GPU...

Unfortunately my C is rusty at best, assembler virtually nonexistant, so while I would like (and actually have) hack something togther in C, it was even slower than the Go implementation. I'd love to use the Intel SHA256 implementations (http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/sha-256-implementations-paper.html), but right now I'm not up to it.

Right now I'm busy providing clients for different OSes and architectures, which has the nice side effect that you will be able to plug in your own key generators.

Vanitygen uses some techniques to generate addresses without computing individual private keys...

It actually does exactly what we do: It simply chooses a private key and then increments it. IIRC the docs vanitigen 1 million times, oclvanitygen 100 million times.

...though I think it would be a waste of energy to run that.

  We'll see.

Rico

[ryanc]

It actually does exactly what we do: It simply chooses a private key and then increments it. IIRC the docs vanitigen 1 million times, oclvanitygen 100 million times.

Hmm. Looks like you're right, though it does a batch conversion of point format. I should try to add that optimization to brainflayer. Doubling the key rather than incrementing it should still be faster, though.

[rico666]

Hmm. Looks like you're right, though it does a batch conversion of point format. I should try to add that optimization to brainflayer. Doubling the key rather than incrementing it should still be faster, though.

Do you really think a shift vs. an increment is that much of a difference? I'd bet, that a more efficient SHA256 and/or RIPEMD160 implementation makes tons of CPU cycles difference and the shift/increment is negligible compared to that.

Also, handling the big integer numbers (potentially up to 2²⁵⁶) seems to take its toll. At least I observe a significant penalty for 32bit systems.


Rico

[ryanc]

Do you really think a shift vs. an increment is that much of a difference?

I'd bet, that a more efficient SHA256 and/or RIPEMD160 implementation makes tons of CPU cycles difference and the shift/increment is negligible compared to that.

I was told that doubling is more efficient than incrementing by gmaxwell, and I am planning on testing that with libsecp256k1 for one of my other projects soon (maybe this weekend?).

You can speed up ripemd160 a little by using fixed padding for a 256 bit input. I am not aware of a good x86_64 assembly implementation of ripemd160, but this could probably speed things up a little more. Profiling the code might be worth while.

[Jude Austin]

I wonder if a pattern in private keys could be found using machine learning?

Just feed a list of known private keys/addresses and see if it can find a pattern?

What do you think?

[rico666]

I wonder if a pattern in private keys could be found using machine learning?

Just feed a list of known private keys/addresses and see if it can find a pattern?

What do you think?

To quote you: "I had the same idea"


Nothing seems better suited than hashing to provide a perfect training set for neural networks. Lots of outputs (hashed value - input for the NN) and their respective inputs (in that case output for the NN) .... and then give it a new set to find inputs (NN output).

However, I think that this idea has already been tried and SHA256 (and probably RIPEMD160 too) looks like noise to the NN. So you get ... noise back.

I do have cuDNN here, so I could try it in practice, but I won't come around to it until October.

Rico

[rico666]

Windows x86 clients for 64it and 32bit available

Also some client contributor stats at http://lbc.cryptoguru.org:5000/stats


Rico

[MyBTT]

May I ask, do you guys store private keys on a server? Because the chance of a collision is currently so miniscule, but if bitcoin picks up, someone generating and using an address in the future it's much more probable.