Large Bitcoin Collider (Collision Finders Pool)

[rico666]

I would prefer a flag, to start at a specific block, instead of a range(which is limited to one day work). So i don't need to start over again, once it has done the work of one day.
Like in a loop, ./LBC -c 4 <start-block>     and just go on with the work like forever

I know what you mean and LBC will have in the next (or one of the next) version a very sophisticated way of defining search space. Additionally to

auto
<from>-<to>

it will offer also
janitor
<from>

and you will be able to enter the numbers in various formats

12121                  (normal - old - 1M block)
#2382392832       (concrete key number)
#b10101010101   (same, but binary)
#xffa100d            (guess...

Oh - 'janitor' will explicitely ask the server for leftovers no one had a look at so far (or didn't deliver PoW).

etc.


Rico

[1714063780]

1714063780

[1714063780]

1714063780

[1714063780]

1714063780

[1714063780]

1714063780

[1714063780]

1714063780

[1714063780]

1714063780

[donGeilo]

Great, that sounds nice!
And thx for your nice work so far!!!

[SparkedDev]

"There is also a small bounty to be found within the next few blocks: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq and when that is found, there will be another one. ;-)"

How great is your "small bounty" actually?

Since when are Hero Members incapable of browsing blockchain.info?

Rico

Since it become unreliable do to the constant lag they see.
https://blockr.io is the go to for many people now.

[rico666]

I bet most of you - if you are not Satoshi Nakamoto - have asked themself "Why oh why didn't I mine for da precious BTC back in 2009?"

The answer is actually trivial: It's either because you didn't see its value (as at that time it had none) or you were unaware (because others also didn't see its value therefore the news "have you checked out this new cool cryptocurrency..." didn't spread).

If you do not participate in the LBC yet, you will ask yourself the same question in a year or so. Deja Vu at its finest.

2016-07-10 0.0000000000000000000000000000000000000000000000000000000000%
2016-09-17 0.0000000000000000004524764939984744324231018884855317923702%
2016-09-21 0.0000000000000001253458951869845883453371545658596111253200%
2016-09-24 0.0000000000000043042164539298425445359190647758710199397875%
2016-09-26 0.0000000000000073909029565816723002553643394779850994024627%
2016-09-26 0.0000000000000094983619014185236171698521342910676276368576%

If you participate in the LBC, you know that number. If you don't - find out.

Very soon, the (yes - still small) probability to find an address with funds will be 16384 times higher than it was (then) 10 days ago.
Done.
The math behind this is simple, the pool has searched an additional 14bits of search space since then.

Now contrary to BTC mining this seems to be inverse. You do not need to participate now. The later you get in, the better probability you start with.

Right.

Except... you know this, I know this. The pool knows this. The pool is aware of when a client started and how many blocks it contributed since then.
Since we all want to serve up justice (right?), the pool will take that information into account in the future.

How? What? You may ask.

I could say "Wait and see". I could say "I don't know yet". I could explain how, but I won't now.

Suffice to say, the possibilities how to steer justice are many. Early adopters can get "better blocks" a.k.a more promising search space, there can (and will) be bounties for all where exactly these parameters will be taken into account for an aliquot share. You know - the old school aliquot... "pro-rata". "Proportionately" for the younger among us.

Some are probably already aware of the new options that have popped up in the LBC help

Code:

...
 Options:
    --address <BTC P2PK address>
      Give a BTC address for rewards to this client. NYI
...
    --secret <[oldpassword:]password>
      Set or change password for enhanced security (changing BTC address).

They are there for a reason and the NYI will vanish soon.



Rico - serving justice since 1970

[Hamukione]

Havent been able to setup the server yet.

Will have time this week.

I also want to invest into the project.

I have 1 BTC that I can throw into this.
For either hardware to test this on, or anything else that might be needed.

I am at your service Rico

EDIT:
Can you link to any sources so I can learn more about this?
And maybe even help one day.

[rico666]

I also want to invest into the project.
I have 1 BTC that I can throw into this.

Thank you for the nice/generous offer. When I started this, I made the decision to stem the cost for pool operation myself.
I intend to keep it that way, both for idealistic as well as for legal reasons. This is a hobby/geek project and I shall never make money out of this, because I'm pretty sure somewhere some legal a**orifice would then like to construe this as "commercial interest".

Therefore, no banners, no "begging" for pool support and - not even taking unsolicited grants like this.

You still can support the pool with your 1 BTC another way:
https://bitcointalk.org/index.php?topic=25804.msg16267353#msg16267353
https://bitcointalk.org/index.php?topic=25804.msg16273114#msg16273114

I am willing to pay also an incentive for a GPU-based LBC miner. If we can make a formal "pot" with the incentive, I'm pretty sure there is now more than enough monetary incentive to either hack oclvanitygen to our bidding or do something LBC specific. I'm already in the process of writing up a formal requirements specification.

If the more generic question "What can I do to help?" comes up, here's a few things:

Hack

If you are a good hacker and know OpenCL and/or CUDA ... see above!

Help to spread the news

While I can maintain this English thread - and to a certain degree also the German one (as we don't have a Czech one, I can't be of any help there) - I would certainly welcome if someone could maintain HQ information about the project in other languages that are inaccessible to me. Don't underestimate the language barrier.

Think of a situation when this becomes well aware in the Chinese boards and some day some manufacturer would approach us with some ASICs  

Also, while bitcointalk.org certainly is a good megaphone for this project, it certainly isn't the only one and I'm not even sure it's the biggest. I would like to see some  /r/bitcoin information maintenance of this project, but I am afraid I don't find the time to do so myself.

I'm also very old school so I do own neither a Facebook, nor a Twitter account...

Help with the documentation

I'm trying to document as good as I can, but in a rapidly changing project like this, there will inevitably be some outdated information. Also, I may already be getting a little bit project-blind and assuming the user-in-spe knows things he simply can't know. Both making it harder for newbies to participate. Actually IF you are a newbie, exactly this situation is valuable.

Of course you are expected "to read it all", but if you then see inconsistencies, outdated information, missing information... assemble and report that (I prefer bulk processing).

If you can do a small How-To in some other language, then by any means do it!



Rico

[Hamukione]

Well, I can do a danish translation of just about everything you can provide to me.

Material that can make it easier to understand and maybe more updates would be nice

I just got another pc today which should be like the other one I have at home.
Will see when I can have both setup and running with linux and have them mining 24/7.

My money is still up for graps for developers that can help this project to move forward.

[rico666]

In case you're wondering why no news: Heavy development and testing.
Next release will be a big one, so despite RERO, it may take another week or even two.

Meanwhile pool runs und churns.
As the image is too big for bitcointalk, click on this to view.


Rico

edit: Pool performance 24h average pretty steady at 23.5 MKeys/s, short term fluctuations between 21 MKeys/s and 29 MKeys/s

[johan11]

My terminal works, but on pool stats no change.

Edit: I use VM and my ID changed, if i use more procesor and more memory for my VM machine. 

[Hamukione]

Just got my first rig up and running thanks to you Rico <3

Doing 1 million keys pr sec atm.

If anyone needs any help, then PM and ill do my best to guide you.

[Hamukione]

Is it possible to have a longer or full list of all active "miners"?

And how do I check what ID I have so I can find myself on there.
(When I overtake everyone else with an army of computers)

[rico666]

And how do I check what ID I have so I can find myself on there.

http://lbc.cryptoguru.org:5000/stats

Read the text above the client list...


Rico

[rico666]

Two days ago, the pool found the private key to

https://blockchain.info/address/1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1

Which is one of the "monitoring" (at least I call them so) addresses from the transaction
Ryan mentioned in his 1,3,7 cracking article.

I suppose, at the current speed we will hit the private key to

https://blockchain.info/address/1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF

within 24-48 hours. Any bets?


Rico

[starsoccer9]

One question/concern I have if it was not already brought up, but does the server check for a response of some sort to confirm that a block was completely searched?

For example if I have block 50-100 and at block 60 I close my client, does the server know that my block was not completed and someone else will need to finish looking through it?

[rico666]

...does the server check for a response of some sort to confirm that a block was completely searched?

Basically yes - not a single block, but a block interval. See the green text in "Yesterdays bug"

For example if I have block 50-100 and at block 60 I close my client, does the server know that my block was not completed and someone else will need to finish looking through it?

If you simply run the client in "auto" mode (as 99% of clients do), you got the blocks 50-100 from the server, because the client asked the server "give me work for X cpus for Y time". This is a get_work message client -> server and at the same time a promise to finish that work.

Now if you close that client as in your example, your client will not deliver at the end of the cycle a proof of work that the given interval was searched. Therefore ALL of the blocks in the promised interval are considered not having been done and will be reissued again.

---

If you manually define which blocks your client should compute (-p <from>-<to> see "Going no-auto") the server does not even know about your clients work until it finishes its self-imposed work. Only upon finishing, it delivers PoW to the server and the server will add this manual interval to the list of blocks done and also credit the client these blocks done.

This is a part of the server log. The IPs and the client-Ids (except 1ff65d1e0f08af7529e9c9f0a591f263) I have changed. The timestamps and the block ranges are original. For readability I also added client name aliases.

Code:

...
1475124925   127.0.0.1 [11673395, 11674010] <<< 60b725f10c9c85c70d97880dfe8191b3 (A)
1475124926   127.0.0.1 [11692283, 11692898] >>> 60b725f10c9c85c70d97880dfe8191b3 (A)
1475125025   127.0.0.2 [11668291, 11671482] <<< 3b5d5c3712955042212316173ccf37be (B)
1475125025   127.0.0.2 [11692899, 11696090] >>> 3b5d5c3712955042212316173ccf37be (B)
1475125073   127.0.0.3 [11662369, 11663844] <<< 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125073   127.0.0.3 [11696091, 11697566] >>> 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125088   127.0.0.4 [11674011, 11674036] <<< e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125089   127.0.0.4 [11697567, 11697592] >>> e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125118   127.0.0.5 [11697593, 11698960] >>> 1ff65d1e0f08af7529e9c9f0a591f263 (rico)
...

Most of the time, we see a client delivering (<<<) pow of an interval done and immediately getting (>>>) a new interval.
You can see that A gets [11692283, 11692898] after having delivered [11673395, 11674010].
Roughly 100 seconds later, B delivers [11668291, 11671482] and gets [11692899, 11696090]. As you can see it starts off where end of work for A was. Same with C and D. Last entry is my workstation, where I started up LBC at the time, so it fetches a work interval (starts where end-of work for D was) and there is no previous delivery.

As mentioned in the referenced text, sometimes clients do not deliver promised work within a certain time frame, so the work will be reissued.
Then there is also a global overview of blocks done, which looked today morning like that:

Code:

[["0",10255010],[10255652,10292471],[10292937,10639099],[10639113,10928680],[10929361,10934248],[10934857,10964934],[10965579,10990212],[10990841,11036530],[11037955,11040222],[11040863,11086284],[11087069,11105776],[11106417,11133744],[11133759,11274716],[11274731,11392940],[11394309,11413182],[11413803,11437418],[11437471,11583428],[11583443,11718436],[11730757,11745286],[11751343,11754328],[3515625000000,3515625030841],...

You can see the pool "forefront" somewhere behind 11754328, this is where new work intervals will be reissued. The [3515625000000,3515625030841] is an interval that is the result of a manual -p where someone ran their client for a day.

You can also see, there are missing intervals in there. First one 10255011-10255651. These are 640 blocks that have been not or not yet delivered back after they have been promised. If the clients who promised them will not deliver back, this range will be reissued by the server.
So yes, the blocks 0 - 10255010 (the first ~ 10753157365760 keys) have been searched completely already. As the holes are getting filled, this first interval grows.

Rico

[yo-blin]

Hi
I have a Windows 2008R2 x64 virtualized on the vmware esxi 5.5

I try run LBC and have error:

>perl c:\lbc\LBC -l 0 -c 1 -t 1:0
Unconditionally setting CPUs to 1 on Windows
Use multiple -c 1 calls instead.
No working generator executable found.

If I run with any parametres in c  - LBC -l 0 -c x -t 1:0
aslo print those message

[rico666]

Hi
I have a Windows 2008R2 x64 virtualized on the vmware esxi 5.5

I try run LBC and have error:

>perl c:\lbc\LBC -l 0 -c 1 -t 1:0
Unconditionally setting CPUs to 1 on Windows
Use multiple -c 1 calls instead.
No working generator executable found.

If I run with any parametres in c  - LBC -l 0 -c x -t 1:0
also print those message

go into the LBC directory, there issue the "perl LBC -c 1 -t 60 -l 0"

for your 1-shot try. LBC looks for the generator executable only in the current directory.

It should work, but you should seriously consider letting this run on Linux 64bit. The Generator there is 13 times faster, uses less memory (and -c X for X > 1 is also no problem).
You can ignore the "-c 1" message if you set the "-c 1" yourself. See also "Yesterdays bug"

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.

Rico

[yo-blin]

Hi
I have a Windows 2008R2 x64 virtualized on the vmware esxi 5.5

I try run LBC and have error:

>perl c:\lbc\LBC -l 0 -c 1 -t 1:0
Unconditionally setting CPUs to 1 on Windows
Use multiple -c 1 calls instead.
No working generator executable found.

If I run with any parametres in c  - LBC -l 0 -c x -t 1:0
also print those message

go into the LBC directory, there issue the "perl LBC -c 1 -t 60 -l 0"

for your 1-shot try. LBC looks for the generator executable only in the current directory.

It should work, but you should seriously consider letting this run on Linux 64bit. The Generator there is 13 times faster, uses less memory (and -c X for X > 1 is also no problem).
You can ignore the "-c 1" message if you set the "-c 1" yourself. See also "Yesterdays bug"

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.

Rico

Thanks - that works!

If I have 20 CPU core on intel E7 4870 - I will must run 20 process?

What version  the Linux you recommended?

[rico666]

Thanks - that works!

If I have 20 CPU core on intel E7 4870 - I will must run 20 process?

What version  the Linux you recommended?

Seriously, if you have such a machine, start LBC on a Linux instance
on your CPU you will get under windows ~ 25 000 keys/s, under Linux at least 300 000 keys/s - per core

get this version: http://62.146.128.45/download/LBChrd-0.837_l64.tbz2

If you install it in some Linux VM and give that VM X cores, give it 550MB * X + 300MB RAM. (4 cores -> 2.5GB, 8 cores -> 4.7GB etc.)
If you use 8 cores on your machine, you should be able to check 2.5 mio keys per second.

Which Linux version?

Anything non-archaic should do.
LBC requires Perl 5.16 or newer, but that has been released 2012 (http://perldoc.perl.org/perlhist.html), so there should be no problems in any modern Linux distro.
Unless you run of course Debian Wheezy - which has 5.14

A modern Ubuntu or OpenSUSE should probably be the way of least resistance.

Rico

[Hamukione]

Holy Shizz...

A CPU with 20 cores xD

I gotta do some research and see if I can get some hardware that can compete with that xD.

1 Client running strong atm with just about 1 million keys pr sec.
Another one will come up today or tomorrow at the latest

EDIT: Any difference between Intel and AMD CPUs?

What specs would be the most ideal?