Yeah, I see that there are several OPEN groups trying to do this (like LBC or GTB).
So, we can imagine that there's a lot more people trying to do it without publicity.
I just want to know if they succeded or not.

Of course, it is amoral. I wish all these guys had set their bloom filters to much more smaller lists with inactive wallets.
But unfortunatelly, (almost) everyone's interested in full lists with any sum and any history

Your idea is broken, because single transaction now costs about $25. Even if you send 1 satoshi.
Actually, it is much more simple to find the owner.
Just take BTC with transaction message "if you are owner, ADD small amount of BTC to this
address and FROM it once again". Only owner can do this.

jhdscript

Your project looks like a "better LBC" because you share reward between members
But sticking to CPU is a showstopper. LBC is also not strong with GPU. Good old opensource oclvanitygen beats crap out of LBC client on highend cards. Why not to use it?

>I am working on the 32 bitcoin puzzle transaction, specifically the 55 bit priv key one.
>First to deliver a working program that helps me open the wallet gets half the 55 bit puzzle transaction wallet.

Hello! Do you know that LargeBitcoinCollider will crack this transaction in just several days?
I think it is better to work on p56 or join LBC and have some chance to win and crack p55.

I can mod oclvanitygen for you, but it is totally unclear why do you think that you will outrun LBC with your 6megakeys if they have 2911megakeys (also if I'm not mistaken LBC's megakeys are twice beafier then vanitygen's as the generate both addresses).

Can you post how do you estimate the range for puzzle transactions? What's the original message?
I guess, with such speed difference it makes sense to work on puzzle 100 or puzzle 100500 already

Google offers $300 "credit" for newcomers to their cloud services. The most efficient hardware is 8core/7.2GB will make 3.0-3.3 megakeys a second. One server costs $150 a month. So you'll have a free server for 2 months.

I guess, buying a videocard to your own PC is much more funds-efficient.

Actually, this project lacks a reasonable comparison of different cards.
I'm not ready to buy a $1000 card like nvidia 2000, but it's totally unclear how would cheaper aftermarket cards behave.
Also, ATI cards were always much stronger for mining, is it the same for LBC?  

Didn't you read the question? 

Hey, guys!

Trying to make list of abandoned non-empty wallets (in java and bitcoinj library), but not getting one moment:
if I process only TransactionOutput (i.e. receiving address) I'll get rubbish? Because withdrawals from these addresses will not be processed?

But for TransactionInput documentation says: The concept of a "from address" is not well defined in Bitcoin and you should not assume that senders of a transaction can actually receive coins on the same address they used to sign (e.g. this is not true for shared wallets).
deprecated method getFromAddress() doesn't return sending addresses.

How other parsers solve this problem?  


What actually I want to do (maybe such parser already exists):

I want a list of abandoned for 3 years wallets. And a yearly snapshots.
The most intriguing part is: were there wallets that became empty in next years?

For example, at 01/01/2013 there were 50k addresses with funds (1++BTC) (without sending transactions from 2010!)
At 01/01/2014 it became 75k adresses (without sending transactions from 2011) BUT n of previous addresses were "recovered"
At 01/01/2015 it became 175k adresses (without sending transactions from 2012) BUT m of previous addresses were "recovered"

etc

rico666 thanks for not sending me to GTFO  Tried to read "What We Do" more attentive.

One question still remains: did you estimate required funds to make FPGA or ASIC clients for LBC? I guess ordinary bitcoin mining ASICs wouldn't be effective (or suitable at all)?

Thanks for the answer, rico666! English is not my native language.
It seems to me that LBC now has rather weak control of clients (correctness of their checks and return of results).
So the effect is: in list of Trophies we see far less records than it should be.

Also the main sense and benefit of pool is sharing award between all members (proportionally to contribution).
But now the single member takes everything (and can even not report the find!).

Actually, I do not see any advantages of being member of LBC versus solo mode.
Yeah, I've read the FAQ, but I totally disagree with the answer.
The range of LBC is known (and I think it is not best).
Solo "miner" can easily use another range without being a member of LBC.

The point of this message is not "hey, everyone, run from LBC", but to make LBC better and possibly more popular.

By the way, don't you think that starting from very beginning is a bad idea?

I guess most of us are hoping to discover abandoned wallets from early 2010-s.
At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves.
So, they at least have seen the result of RNG.
And the secret key with 40 leading zeros looks very stupid.
Yeah, I understand that any value from RNG has the same probability to occur, but still...

Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)?

Hello, guys! Just joined my modest 10Mkps to your great project. But I still have a couple of questions...

1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty? 

2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server?
Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks.

For now it seems like we are sifting with too large sieve?