(Also, I tweeted your project out!
) 
Topic: Large Bitcoin Collider (Collision Finders Pool) - page 57. (Read 193404 times)
Very interesting progress you've made on your project so far. I'm not understanding the bounty part though, what is that exactly?
(Also, I tweeted your project out! )
(Also, I tweeted your project out!
) 
Moores law would relate there ? so a growth of 100% every two years or average 1.5^34 which would be 970739.737366476
Is the GTX 1080 now nearly a million times faster then your ZX spectrum ? if so maybe you can speculate on the future potential.
Is the GTX 1080 now nearly a million times faster then your ZX spectrum ? if so maybe you can speculate on the future potential.
Yes, Moore gives a pretty good estimate. A modern i7 is about 400 000 times faster than the Z80 in the good old Speccy, a 1080 adds a factor of 30 on top of that. So the 1080 is about 12 million times faster. Which means that everything I could possibly have computed with the ZX Spectrum in the past 34 years, the 1080 would finish in 89 seconds.
It seems this pool will soon check more keys daily than it has checked for its whole life time so far (40 days). Soon. Mark my words.
Rico
The bounty has been claimed. 
Let's hope by its "true owner".
Rico
Let's hope by its "true owner".
Rico
While I do have fun with this project (at least when all runs well), I take it seriously and it's not just meant as some weird kind of faucet. I think I know statistics pretty well.
I also think I know the speed of my ZX Spectrum (1982) and of my GTX 1080 (2016). That's 34 years and the speedup is ... homework for everyone interested.
Let's see if this pool, or bitcoin or we all are here in 34 years before we speak of the "age of the universe".
Rico
Moores law would relate there ? so a growth of 100% every two years or average 1.5^34 which would be 970739.737366476I also think I know the speed of my ZX Spectrum (1982) and of my GTX 1080 (2016). That's 34 years and the speedup is ... homework for everyone interested.
Let's see if this pool, or bitcoin or we all are here in 34 years before we speak of the "age of the universe".
Rico
Is the GTX 1080 now nearly a million times faster then your ZX spectrum ? if so maybe you can speculate on the future potential.
If bitcoin is still strongly used in 34 years everyone holding bitcoin now will be able to retire I think. Probably we find out sooner one way or the other
The actor shot in that scene just passed away in real life, RIP
Why do you think it's an HD wallet? The first output was sent to an address with a private key of 0x01. That would never be generated by an HD wallet.
Yes, I'm probably wrong. The remainder after the nth bit doesn't seem that deterministic.
After some more thought I believe it is either a witty joke or an "early warning system" exactly against this kind of incremental brute force search we (and as it seems others) do.
Speaking of which:
Our pool bounty has been found hours ago, but still not claimed.
https://blockchain.info/address/1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP
I wonder what the operator of 540bbf4beaaa58ca981d0917da0c3a82 who got and delivered the block containing the PK of the bounty address is doing???
Either he's asleep and letting his comp cracking keys, or he got an heart attack when he saw the FOUND message, or ... don't know.
But evidently there seems not to be some omnipotent clandestine cracker running around in the lower 50bits PK search space, else the bounty would have been gone by now.
So lesson learned: Watch your LBC directory for a FOUND.txt file people!
Rico
FWIW, I just posted this: https://rya.nc/forensic-bitcoin-cracking.html
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
Congrats, that's an HD wallet you hit.
Why do you think it's an HD wallet? The first output was sent to an address with a private key of 0x01. That would never be generated by an HD wallet.
Trying this on a windows machine now seems to be running fine but only works if you call the perl before the lbc program variables.
Yes.
Also how can I be sure it's pulling new blocks and not ones previously collided?
Pretty sure, as I have explained above to quite some extent. The server is juggling with intervals done/not done/issued/pending and I dare to say that is working with mathematical precision. There is lots of work to do, we cannot afford to do it over and over again (if it's not necessary). There are circumstances, when work is being done twice, but in these (rare) cases it's unavoidable. In general, your client boldly goes where no client has gone before.
Quote
Lastly is there a way we can use our gpu for this instead of cpu?
Not yet.
https://bitcointalksearch.org/topic/m.16267353
https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification
...
Maybe someone with the skills finally wants to earn some BTC doing this.
Rico
PS: Congrats to operator of 540bbf4beaaa58ca981d0917da0c3a82! You should have found the bounty. Please do claim it, so I know everything is working as it should.
Trying this on a windows machine now seems to be running fine but only works if you call the perl before the lbc program variables. I'm new to this but assume it's working however like you said windows forces only one core at a time. Does this mean we should open more command line windows to get more cores used?
Also how can I be sure it's pulling new blocks and not ones previously collided?
Lastly is there a way we can use our gpu for this instead of cpu?
Also how can I be sure it's pulling new blocks and not ones previously collided?
Lastly is there a way we can use our gpu for this instead of cpu?
I feel the need to explain what happened yesterday in greater detail and also what I have done to make sure something like that doesn't happen again.
Also, give you some insight in the pools work distribution operation.
First I would like to describe the fun - almost dramatic - situation that led to the discovery of the bug.
The bounty (https://blockchain.info/address/1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP) was in a block that was about to be issued "any moment now".
"client X" finally asked the server for work which contained the block. You must know, that the whole client<->server interaction is a game of promise and deliver. When a client asks for work, he gives nothing but a promise to work on the assigned block(s). The server knows when this work was issued and the server also knows about the clients computation speed. Therefore the server knows when the delivery of the promised work is due. The server waits for 200% of this time, because the client may have a higher load and not be able to utilize its capacity 100% to check blocks. The user might have halted the process (under Linux Ctrl+Z) for some time to start it later on. There may be some network lag etc. etc. If after more than double of the promised time, the client does not return a POW of the checked block (client-id, interval), the server considers that interval not having been checked and will reissue it to the next client who asks for work (which actually may be the same client-id). In the meantime however, the server will not issue blocks from the promised interval to other clients to avoid double work.
However, "client X" did not deliver the interval back in time, so its interval was open to reissue.
Meanwhile, other clients asked for work and delivered it back, so basically the interval for reissue is a "hole" in the work done. Have a look at this JSON representation:
The "holes" are the intervals between the intervals. Like 653588-653707, then 654826-654847 etc. This happens all the time, is a natural process and expected. Clients promise and do not/cannot deliver, so work is done later. Naturally the holes have different sizes, depending on the computational strength of the client who promised and did not deliver. Now if a slow client promised and did not deliver, the resulting "hole" is small. Which actually means, that it becomes inaccessible for "fat" clients who ask for (promise to do) bigger chunks of work. These get new work at the current "forefront" of the pool.
Nevertheless, a new (another) "client Y" came along and asked for work within the hole in the intervals that contained the bounty. And guess what? He didn't deliver also. Meanwhile the hole/interval containing the bounty was even smaller (like 3 blocks). That's when I was reminded of the pulp fiction scene of missed shots.
FINALLY, a "client Z" came along, claimed the blocks and ... delivered. AND ... nothing happened! I thought WTF? I gave my notebook (Linux) the specific block number and .. HIT. WTF? WTF? I went to my Windows machine, gave it the specific block number and ... NOTHING!
In this very moment there was a rapid change of operation of my sweat glands.
Potentially, every win-client was not getting hits despite them being there. Every second of operation added to wasted work. And this at a time when we finally had stable win clients and the pool evidently got more and more clients. For a second, I thought "Maybe I can fix it without telling anyone and embarrassing myself?" Nope. I had to stop the pool operation to prevent issuing of work which would have been moot anyway. I stopped the pool, put out a quick message here and started a frantic bug hunt.
I compared the output of the Linux and Win versions of the generators byte-by-byte. Same. Of course - I did that test before.
I issued a "LBC -x" on Linux: correct 3 hits. I issued "LBC -x" on Windows: bummer! 2 hits
It's not "not working" - it's somehow a little bit not working? WTF2?
Ok. I hacked some debug information into LBC and let it print out what the LBC client "thinks" it sees coming from the generator right before the hash160 check. And there it was: Some 50000 bytes down the stream, the Linux and Win versions started to differ. What was going on? I pinned down the exact location of the 1st change and there I saw it: Linux "0a0a6f" Windows "0a0a0d6f". Naturally, all subsequent hash160 checks for the current block in the Windows version were 1 byte off and could not match.
CRLF anyone? The windows client considered the stream from the generator to be a text stream. Which at the time when it was a text stream (base58) was perfectly ok. But since the client 0.823 when the stream became binary, this was not ok. Oh this was so badly not ok. For Linux, it didn't matter, as the default mode of operation on incoming pipes is ":raw" don't change anything. But on Windows, the default mode of operation on incoming pipes is ":crlf" - yeah munge the data by default.
And the problem is - of course known and documented http://perldoc.perl.org/functions/binmode.html
So the fix was a binmode ":raw" on the pipe filehandle. Then LBC -x on windows had it's 3 hits. Then the windows client showed a hit when processing the specific block containing the bounty.
I put in some information here, had the pool server accept only clients 0.831 or higher (unfortunately it cannot do that separately on OS versions, so Linux clients had to update too although for them it was not necessary - collateral damage) put the new versions for download, rolled back the "forefront" of the pool and started up the pool.
Phew!
There were of course some more details done. When checking the Windows client via LBC -x, I realized, that there was no way, a user could determine if the check ran successful if there were only some hits. So now the check checks itself and will bail out if there are not exactly 3 hits. The windows client refuses now to be called with anything else than -c 1, respectively sets the number of CPUs always to 1. Unfortunately there is a small annoying message even if you set -c 1, but it's not breaking anything.
----
All in all, I certainly hope this was the last incident of this type and hopefully the dust will settle now and everything will run smooth. Good hunting everyone!
Rico
Also, give you some insight in the pools work distribution operation.
First I would like to describe the fun - almost dramatic - situation that led to the discovery of the bug.
The bounty (https://blockchain.info/address/1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP) was in a block that was about to be issued "any moment now".
"client X" finally asked the server for work which contained the block. You must know, that the whole client<->server interaction is a game of promise and deliver. When a client asks for work, he gives nothing but a promise to work on the assigned block(s). The server knows when this work was issued and the server also knows about the clients computation speed. Therefore the server knows when the delivery of the promised work is due. The server waits for 200% of this time, because the client may have a higher load and not be able to utilize its capacity 100% to check blocks. The user might have halted the process (under Linux Ctrl+Z) for some time to start it later on. There may be some network lag etc. etc. If after more than double of the promised time, the client does not return a POW of the checked block (client-id, interval), the server considers that interval not having been checked and will reissue it to the next client who asks for work (which actually may be the same client-id). In the meantime however, the server will not issue blocks from the promised interval to other clients to avoid double work.
However, "client X" did not deliver the interval back in time, so its interval was open to reissue.
Meanwhile, other clients asked for work and delivered it back, so basically the interval for reissue is a "hole" in the work done. Have a look at this JSON representation:
Code:
[["0",653587],[653708,654825],[654848,657098],[657111,657122],[657135,660588],[660608,672324],[672392,674026],[674055,674193],[674222,676045],[677393,677444],[677775,678894],[69545491,69545512],.....
The "holes" are the intervals between the intervals. Like 653588-653707, then 654826-654847 etc. This happens all the time, is a natural process and expected. Clients promise and do not/cannot deliver, so work is done later. Naturally the holes have different sizes, depending on the computational strength of the client who promised and did not deliver. Now if a slow client promised and did not deliver, the resulting "hole" is small. Which actually means, that it becomes inaccessible for "fat" clients who ask for (promise to do) bigger chunks of work. These get new work at the current "forefront" of the pool.
Nevertheless, a new (another) "client Y" came along and asked for work within the hole in the intervals that contained the bounty. And guess what? He didn't deliver also. Meanwhile the hole/interval containing the bounty was even smaller (like 3 blocks). That's when I was reminded of the pulp fiction scene of missed shots.
FINALLY, a "client Z" came along, claimed the blocks and ... delivered. AND ... nothing happened! I thought WTF? I gave my notebook (Linux) the specific block number and .. HIT. WTF? WTF? I went to my Windows machine, gave it the specific block number and ... NOTHING!
In this very moment there was a rapid change of operation of my sweat glands.
Potentially, every win-client was not getting hits despite them being there. Every second of operation added to wasted work. And this at a time when we finally had stable win clients and the pool evidently got more and more clients. For a second, I thought "Maybe I can fix it without telling anyone and embarrassing myself?" Nope. I had to stop the pool operation to prevent issuing of work which would have been moot anyway. I stopped the pool, put out a quick message here and started a frantic bug hunt.
I compared the output of the Linux and Win versions of the generators byte-by-byte. Same. Of course - I did that test before.
I issued a "LBC -x" on Linux: correct 3 hits. I issued "LBC -x" on Windows: bummer! 2 hits
It's not "not working" - it's somehow a little bit not working? WTF2?Ok. I hacked some debug information into LBC and let it print out what the LBC client "thinks" it sees coming from the generator right before the hash160 check. And there it was: Some 50000 bytes down the stream, the Linux and Win versions started to differ. What was going on? I pinned down the exact location of the 1st change and there I saw it: Linux "0a0a6f" Windows "0a0a0d6f". Naturally, all subsequent hash160 checks for the current block in the Windows version were 1 byte off and could not match.
CRLF anyone? The windows client considered the stream from the generator to be a text stream. Which at the time when it was a text stream (base58) was perfectly ok. But since the client 0.823 when the stream became binary, this was not ok. Oh this was so badly not ok. For Linux, it didn't matter, as the default mode of operation on incoming pipes is ":raw" don't change anything. But on Windows, the default mode of operation on incoming pipes is ":crlf" - yeah munge the data by default.
And the problem is - of course known and documented http://perldoc.perl.org/functions/binmode.html
Quote
On some systems (in general, DOS- and Windows-based systems) binmode is necessary when you're not working with a text file. For the sake of portability it is a good idea always to use it when appropriate, and never to use it when it isn't appropriate.
So the fix was a binmode ":raw" on the pipe filehandle. Then LBC -x on windows had it's 3 hits. Then the windows client showed a hit when processing the specific block containing the bounty.
I put in some information here, had the pool server accept only clients 0.831 or higher (unfortunately it cannot do that separately on OS versions, so Linux clients had to update too although for them it was not necessary - collateral damage) put the new versions for download, rolled back the "forefront" of the pool and started up the pool.
Phew!
There were of course some more details done. When checking the Windows client via LBC -x, I realized, that there was no way, a user could determine if the check ran successful if there were only some hits. So now the check checks itself and will bail out if there are not exactly 3 hits. The windows client refuses now to be called with anything else than -c 1, respectively sets the number of CPUs always to 1. Unfortunately there is a small annoying message even if you set -c 1, but it's not breaking anything.
----
All in all, I certainly hope this was the last incident of this type and hopefully the dust will settle now and everything will run smooth. Good hunting everyone!
Rico
I have another suggestion:
Is it possible to update the LBC with out having to download everything all over again?
If possible, an "upgrade" link that just provides the necessary binaries to update.
This will save on download time and HD space.
Is it possible to update the LBC with out having to download everything all over again?
If possible, an "upgrade" link that just provides the necessary binaries to update.
This will save on download time and HD space.
Same request was in the german thread, https://bitcointalksearch.org/topic/m.16291208
In this case, download of
http://62.146.128.45/download/LBC-client/LBC
is sufficient and it's a meagre 17kB. Just replace the old LBC with it.
I was thinking about some autoupdate/incremental update but hadn't yet the time to implement that.
Rico
I have another suggestion:
Is it possible to update the LBC with out having to download everything all over again?
If possible, an "upgrade" link that just provides the necessary binaries to update.
This will save on download time and HD space.
Thanks,
Jude
Is it possible to update the LBC with out having to download everything all over again?
If possible, an "upgrade" link that just provides the necessary binaries to update.
This will save on download time and HD space.
Thanks,
Jude
The price of Bitcoin will not budge because of this project. Even if >100BTC was found, nobody is going to worry about this I think the developer here is just having a bit of fun and giving anyone who wants to join in a chance of finding a small bounty. Projects like this have existed since BTC was born. If you have nothing constructive to contribute and all you post is pure negativity and FUD, then I am sure you can find another thread/forum that you can vent in. We get it, you disapprove. Now move on and stop being a nuisance (no offense intended).
While I do have fun with this project (at least when all runs well), I take it seriously and it's not just meant as some weird kind of faucet. I think I know statistics pretty well.
I also think I know the speed of my ZX Spectrum (1982) and of my GTX 1080 (2016). That's 34 years and the speedup is ... homework for everyone interested.
Let's see if this pool, or bitcoin or we all are here in 34 years before we speak of the "age of the universe".
Rico
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
The price of Bitcoin will not budge because of this project. Even if >100BTC was found, nobody is going to worry about this I think the developer here is just having a bit of fun and giving anyone who wants to join in a chance of finding a small bounty. Projects like this have existed since BTC was born. If you have nothing constructive to contribute and all you post is pure negativity and FUD, then I am sure you can find another thread/forum that you can vent in. We get it, you disapprove. Now move on and stop being a nuisance (no offense intended).
Mistercoin-
Sun Sep 18 19:17:59 CEST 2016
Shitty bug in Windows client which caused it not to find all matches. I found out after client got a block containing the bounty, delivered it back and no bounty was claimed. In the binary stream, Windows replaced some "0a" with "0a0d" - or whatever. So yeah, it's official: I'm an idiot for relying on UNIX default behavior. Now that stream is set unconditionally to ":raw". => Bug found and fixed, new versions in the making. Pool will demand at least version 0.831 which you will find for download shortly.
Sun Sep 18 19:36:55 CEST 2016
Packages are available for download.
Would the operator of client 06be1b85e82e538529d23390c6fd06c5 contact me via PM: I will give you the bounty out-of-band, because you would have found it
Please everyone do a LBC -x first. This should simulate 3 hits under various conditions. Only then you can be 100% sure you will find everything. (needs to be done only once)
Sun Sep 18 19:48:53 CEST 2016
Had to roll back 25000 blocks. We all know how small the chance is that they contained something an old buggy windows client overlook, but just to be sure.
1 day of work lost.
Rico
And - BTW - we seem to have quite some new clients, the pool capacity is rising
Which means, the bounty will be found definitely today - probably within the next6-8 ~2 hours like now.
edit: Thriller! Some client already claimed the block containing the bounty, but did not deliver it back, so the server will reissue it again...
edit2: Unbelievable. Do you know that scene from pulp fiction? https://youtu.be/Vr6aIURrFvE?t=77
I am being reminded of that. Congrats to client 273870c7c71bfe2e82e2a537580e63cf you threw away the 2nd chance the pool gave you.
So pool is reissuing again. Hey! We have time.
Rico
Which means, the bounty will be found definitely today - probably within the next
edit: Thriller! Some client already claimed the block containing the bounty, but did not deliver it back, so the server will reissue it again...
edit2: Unbelievable. Do you know that scene from pulp fiction? https://youtu.be/Vr6aIURrFvE?t=77
I am being reminded of that. Congrats to client 273870c7c71bfe2e82e2a537580e63cf you threw away the 2nd chance the pool gave you.
So pool is reissuing again.
Hey! We have time.Rico
Is that threads or actual physical cpu. Theres cpu with 44 threads or 22 cores now and quite a few old server chips with about half that so maybe thats a useful source of power. Not sure its all minor compared to gpu parallel processing power though I couldnt even crack a secure rar password nevermind something as involved as this
On windows, it's threads, but you should - on windows - assign each thread it's own CPU. So on aforementioned server, for max performance, start around 20 times perl LBC -c 1
AND
use http://62.146.128.45//download/LBC-0.827_w64.zip
as this is a Windows version without the aforementioned instability. Several clients with this version ran for over 48h now.
Or wait a couple of hours, as I will put a more polished windows 0.830 (or so) in the download section today.
Rico
Nevermind downloaded the latest version and now no error.
C:\Users\Worker1\Downloads\LBC-latest_w64\LBC-client>perl LBC -c 4 -t 10:0
Reading balances... storable found - using that (faster)... done.
Fetching adequate work... got block interval [669627-669682]
..Attempt to free unreferenced scalar: SV 0x1537d6978, Perl interpreter: 0x14662
bca8 at C:/Strawberry/perl/vendor/lib/Term/ReadKey.pm line 334.
..........Free to wrong pool 21b86ce50 not 2c69badf0 at C:/Strawberry/perl/vendo
r/lib/Term/ReadKey.pm line 334.
Get that every time I run it, and the perl interpreter crashes. Windows 7 64 bit, installed the strawberry perl.
C:\Users\Worker1\Downloads\LBC-latest_w64\LBC-client>perl LBC -c 4 -t 10:0
Reading balances... storable found - using that (faster)... done.
Fetching adequate work... got block interval [669627-669682]
..Attempt to free unreferenced scalar: SV 0x1537d6978, Perl interpreter: 0x14662
bca8 at C:/Strawberry/perl/vendor/lib/Term/ReadKey.pm line 334.
..........Free to wrong pool 21b86ce50 not 2c69badf0 at C:/Strawberry/perl/vendo
r/lib/Term/ReadKey.pm line 334.
Get that every time I run it, and the perl interpreter crashes. Windows 7 64 bit, installed the strawberry perl.
FWIW, I just posted this: https://rya.nc/forensic-bitcoin-cracking.html
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
Congrats, that's an HD wallet you hit.
Rico
Attention! Windows version crashes if you try to use more than 1 CPU. And it also crashes if you want to use 1 CPU for longer periods 
Workaround: start in as many windows as you have/want-to-use CPUs . It's super-paranoia and super-annoying, but at the moment your best bet to participate with Windows.
I'm figuring out better ways around this situation.
Rico
Workaround: start in as many windows as you have/want-to-use CPUs Code:
perl LBC -c 1 -t 1
I'm figuring out better ways around this situation.
Rico
Is that threads or actual physical cpu. Theres cpu with 44 threads or 22 cores now and quite a few old server chips with about half that so maybe thats a useful source of power. Not sure its all minor compared to gpu parallel processing power though I couldnt even crack a secure rar password nevermind something as involved as this
FWIW, I just posted this: https://rya.nc/forensic-bitcoin-cracking.html
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
The first unspent output on the transaction described should be somewhere between 2^51 and 2^52, but it's only worth a few dollars.
Jump to: