Large Bitcoin Collider Thread 2.0

[arulbero]

Pool has 1.2 Gkeys/s already.

The "one week before bit boundary" was exactly this. You can never know when you are "just one week before the bit boundary".

Interestingly, if Unknownhostname overdoes it, he will not be eligible for LBC Pot distribution himself.

If it were so, at the moment there would be only a few people currently active that could get the LBC Pot (at least in the top 30, from what I can see).

And besides, If we could mantain a 1.5 Gkeys/s speed for 1 year, we would find #54, #55 and #56 by the end of 2018.

EDIT: now we are almost at 2 Gkeys/s, #54 by the end of this year!    And we will hit the next bit boundary in less than 4 days! At this speed, in the next 50 days we will generate as many addresses as we have been generating from the beginning of this project so far.

[1715043171]

1715043171

[1715043171]

1715043171

[1715043171]

1715043171

[Hereticalsauce]

Unknown, what the heck are you running this project on?!

[rico666]

Unknown, what the heck are you running this project on?!

Join our Discord Chat and find out. (Mostly cloud services, pretty big iron machines with 80 - 220 Mkeys/s)

[rico666]

If it were so, at the moment there would be only a few people currently active that could get the LBC Pot (at least in the top 30, from what I can see).

it is so, and at the moment would look something like that:

Eligible users:
5b8f5562ac3873408d26852d74434040
b8a357e43e373ac086bed2c374085298
kknd2017
__rico666__
likizjucdordvd
UnimatrixONE
_maxairz_
cagrund_
__ac0v__
5dcb3e5d07a8ccdbc00912773ca806dd
amthenia
Rexikonn
735912756

Total blocks of eligible users: 2677768070

Satoshi in LBC Pot: 12274528

Distribution as follows:
userid (share in total eligible blocks) -> share in LBC Pot in Satoshi

Code:

5b8f5562ac3873408d26852d74434040 (0.003923506340114063724719818621184769000551) -> 48159.188429907598382857705820653840270795264928 Satoshi
5dcb3e5d07a8ccdbc00912773ca806dd (0.0009264790434221586636515536612549121926008) -> 11372.0929598985023374335776585759348456199124224 Satoshi
735912756 (0.001599170610769139539407533528473210900599) -> 19629.064438662904812364873706183224449307642272 Satoshi
Rexikonn (0.01046480474315312901613618837422316414431) -> 128450.53883436589039617609601267670653792913568 Satoshi
UnimatrixONE (0.3025223849950529882896094134097281995001) -> 3713319.4852485577662444828539612842571535634528 Satoshi
__ac0v__ (0.3143228935432036875396755328403030812149) -> 3858165.1578370728724089984387632196988585640672 Satoshi
__rico666__ (0.03241580104433764497012618422924133231598) -> 397888.65756115166463987301185498115226980135744 Satoshi
_maxairz_ (0.001672999260163707904695420466343823421571) -> 20535.276262858717260005269985910318215129043488 Satoshi
amthenia (0.004009046235285044682753275193097660620025) -> 49209.1502683008689397061934493826420149942232 Satoshi
b8a357e43e373ac086bed2c374085298 (0.02908196302452736319318349329634063490794) -> 356967.36943952580628090019760374542071528695232 Satoshi
cagrund_ (0.1118683112835832716460765028092966990976) -> 1373130.7191630588081513721238747909933810659328 Satoshi
kknd2017 (0.1366251536489491414392733422951002623614) -> 1677009.2739683284071723209396547924331623504192 Satoshi
likizjucdordvd (0.05056748622743865939069174127541225032234) -> 620692.02558831019297350871765380337812457135552 Satoshi

Now, this is only to demonstrate the Sub-Satoshi accuracy of the distribution script and which/how many users currently actually are eligible.

The numbers may change, because I see users who still can make it into the list of eligible users as e.g.
https://lbc.cryptoguru.org/stats/testing123

and also, I will let run the "Gkeys forfeiture reaper" script before the distribution script.
While the Gkeys gained by the forfeiture of others will be recorded in a separate place, they will count for share computation.

edit:

And of course you need to have a BTC address set for payout, else cry (holy crap):

UnimatrixONE would be eligible by activity, but has no BTC address set!
__ac0v__ would be eligible by activity, but has no BTC address set!
__rico666__ would be eligible by activity, but has no BTC address set!
amthenia would be eligible by activity, but has no BTC address set!
kknd2017 would be eligible by activity, but has no BTC address set!
Total blocks of eligible users: 562942816
Satoshi in LBC Pot: 12274528
Distribution as follows:

Code:

5b8f5562ac3873408d26852d74434040 (0.01869944815140868588684503258675566791495) -> 229526.8999190141543612841841470448749807553936 Satoshi
5dcb3e5d07a8ccdbc00912773ca806dd (0.004413265307572554580748038180844286677956) -> 54170.748589227933232920055595842260468597904768 Satoshi
735912756 (0.007620468505987649019043525728197586591104) -> 93537.654049863565538422289769481666144930598912 Satoshi
Rexikonn (0.04979600627854890326906667550403556442223) -> 611222.47335422431254545044234119864849646595744 Satoshi
_maxairz_ (0.007998254657538786319639257995256129176716) -> 98174.800745090243766429022161995224751217490048 Satoshi
b8a357e43e373ac086bed2c374085298 (0.1385989158799390380709645648981867458452) -> 1701236.2737379563610951205388506103611057910656 Satoshi
cagrund_ (0.5322046493617568431675305365296641426542) -> 6532560.8703210665006514622614883853496049722176 Satoshi
likizjucdordvd (0.2406689918572475396861623685770598767176) -> 2954098.2792835569288089112056454416144467292928 Satoshi

[dcw312]

On Rico's advise just now, I added a hook-find file because I am running in the cloud.

https://github.com/dcw312/lbc-client-docker/commit/15874d4dc14fdb48e92b3288ff98bd9645172c26

Rico suggested:

Code:

#!/bin/bash
mail -s 'LBC FOUND' name@example.com < FOUND.txt

Mine sends to a queue that I would prefer not to share.

[rico666]

There are a lot of dead/dormant accounts, who seem to just have tested LBC and then stopped colliding. And this is perfectly ok.
On the other hand, I don't think it makes sense to keep these accounts around indefinitely as most of them have some single-digit Gkeys, but everyone started out small, so an automated cleanup mechanism should not immediately reap small accounts.

This is what will happen:

Starting with 53bit search space (which is due in about a month given current speed), accounts that have been inactive for (7 + Gkeys_delivered) days will be reaped and their Gkeys will be added proportionally  to the other active accounts. Consider it a kind of Proof of Stake. 

e.g.

Account has delivered 5 Gkeys and is inactive. This account can be inactive for 12 days before it is reaped.
Account has delivered 1000 Gkeys and is inactive. This account can be inactive for 1007 days before it is reaped.

It's clear that accounts that did some serious colliding in the past with several thousand Gkeys do not have to fear to be reaped anytime soon.
But I should point out that as speed of colliding rates changes over time, we may change this rule at some point in the future. (Imagine if the hardware/software in 5 years can give you 1Gkey/s then probably 1 Gkey will buy you 1 hour idle time. Or something like that)

For now, 7 days idle time is ok for everyone, above that: 1Gkey = 1 day.

The 53bit search space is nearing completion, and see below for the current forfeiture list.
So in probably less than 24 hours accounts worth ~1300 Gkeys are going to be reaped and redistributed.
If anyone sees an old account of his and wants it to be merged, ping me (Discord).

Code:

                        07012014 - merits (13) < inactive days (61)
07784296c5953af2050fa559e232d3ce - merits (21) < inactive days (83)
27f9e8cdd9bee45f6d943b04d724fbda - merits (8) < inactive days (78)
2ebafbde0b5046923e7c63ea7f085719 - merits (13) < inactive days (26)
3f28ef225fd629b144789cd7b6396019 - merits (14) < inactive days (66)
4a35b30adba2af2ba2c3e543176b3bf2 - merits (8) < inactive days (76)
4d0262b4d8587eaff46cd76a142b9f7d - merits (8) < inactive days (83)
5279ffedcc725c89c21eef937c9b1f1b - merits (12) < inactive days (77)
53734e6a8ae7ca7cef9c9ca2d26b6989 - merits (8) < inactive days (62)
5428f3d893b44cf06cd9e3a23fb684d4 - merits (27) < inactive days (65)
54bff9f1f6ebc70f75500306174379e1 - merits (8) < inactive days (77)
55983aa8ec125415ef295bb6181d2376 - merits (36) < inactive days (98)
56183636ede39effd426430665e29ab1 - merits (8) < inactive days (67)
5adef64d5f5f26f9bb61b5dc1e51ae80 - merits (8) < inactive days (9)
7318cd5b2c9a2bccb63ee749008d1464 - merits (10) < inactive days (78)
7a5e0c4959a68cc0b4abb6cabde3d8cc - merits (8) < inactive days (78)
82b80cce73915a6825c64f806e649ac6 - merits (13) < inactive days (77)
8a4b86be2a3157a53c82aaffebf62ef9 - merits (8) < inactive days (77)
               EasterZombieJStar - merits (161) < inactive days (206)
                  HereticalSauce - merits (133) < inactive days (148)
                      K1LLY0UALL - merits (104) < inactive days (163)
                        MarinaSG - merits (26) < inactive days (50)
                        OoOooOoO - merits (59) < inactive days (118)
                     RobinJonson - merits (129) < inactive days (192)
                  Twolklefarmeur - merits (9) < inactive days (17)
                      ZellDincht - merits (55) < inactive days (203)
                      __george__ - merits (10) < inactive days (12)
a7520deb0d51f0c5ea5821731834b9df - merits (24) < inactive days (65)
                        br123456 - merits (8) < inactive days (185)
cfc3b9abae26b0d43b49dba79ad82c39 - merits (9) < inactive days (90)
dddba64d0bbf5f0fdd392ea65772179b - merits (8) < inactive days (78)
                       depachlbc - merits (97) < inactive days (133)
e026c2d3c48d36b830ebc9d69120bed3 - merits (42) < inactive days (81)
e8427d71a63040e3ac8b11941fd5e651 - merits (8) < inactive days (77)
edae837b39e05377674b20ba9804ae39 - merits (23) < inactive days (79)
f0f13a3775adf04d79fa568f68295a8e - merits (10) < inactive days (64)
f68a5fe027b2d395551b507e3d9ba4ed - merits (15) < inactive days (28)
f829f754fafc9d588a12041c814b1580 - merits (15) < inactive days (28)
f88af2215c8106bc6a43669d799ab1d8 - merits (8) < inactive days (77)
                      floppyjohn - merits (103) < inactive days (148)
                       iamback12 - merits (8) < inactive days (92)
                   ilovebtc00777 - merits (16) < inactive days (93)
                   ishortbitcoin - merits (77) < inactive days (92)
                        jazzjazz - merits (72) < inactive days (164)
                      merror1203 - merits (22) < inactive days (26)
                        morantis - merits (8) < inactive days (121)
                       oootah123 - merits (122) < inactive days (188)
                       skywalker - merits (8) < inactive days (34)
                       slaingerz - merits (42) < inactive days (180)
                   someonenewwho - merits (29) < inactive days (206)
                    tester397564 - merits (21) < inactive days (25)
                      wanwandrew - merits (8) < inactive days (49)
                       wanwanwan - merits (9) < inactive days (49)
Total forfeited Gkeys: 1329.98752593994140625

[dcw312]

At 10:48 PM Thursday (UTC), Rico announced on Discord that we crossed into the 54 bit search space.

[rico666]

New client 1.192 (see News in my sig for changes);

User 735912756 blacklisted for insane spamming. Note from the author: "If you start using AWS for your LBC efforts, please make sure your config is right or bear the consequences."


also, the block forfeiture script ran, result can be inspected here: https://lbc.cryptoguru.org/static/logs/171110-forfeiture_run.log
The acquired blocks are kept separate from the blocks you delivered (done by your work).

You can see them in the "acquired"-field when doing ./LBC -q

Code:

{
  ...
   "done" : 12345,
   "acquired" : 768
}

LBC Pot payout

Code:

# lbcadmin payout
__rico666__ would be eligible by activity, but has no BTC address set!
kknd2017 would be eligible by activity, but has no BTC address set!
testing123 would be eligible by activity, but has no BTC address set!
Total blocks of eligible users: 2264937133
Satoshi in LBC Pot: 12274528
Distribution as follows:
5b8f5562ac3873408d26852d74434040 (0.00528064104991650556333565131231392990721) -> 64817.37642514954519931922543123407743608654688 Satoshi
5dcb3e5d07a8ccdbc00912773ca806dd (0.001196988631825305501757606620510115500853) -> 14692.470477021403489877791676436786998454172384 Satoshi
UnimatrixONE (0.3679931177144950804248216632509949670201) -> 4516941.8271938658705367254005809087505472940128 Satoshi
__ac0v__ (0.3891475852279207610130166027879768087144) -> 4776602.9310124997628355806553858994019155468032 Satoshi
_maxairz_ (0.002621289533160742258889002019818975699579) -> 32175.091770888459357516304184324572155802023712 Satoshi
b8a357e43e373ac086bed2c374085298 (0.03876699212560439751508105103771990655071) -> 475846.53032151069422199278323192204911407331488 Satoshi
cagrund_ (0.1335338785317181693272190261715312696054) -> 1639065.3309861735575156910988751933716470312512 Satoshi
likizjucdordvd (0.06145950718535903839587939679913402700171) -> 754386.44181289070684329674063408099018524544288 Satoshi

[David Rabahy]

How would I be able to tell if one of my addresses was collided?

[BurtW]

How would I be able to tell if one of my addresses was collided?

I believe they will move your Bitcoins for you.  Correct?

[David Rabahy]

Ok, so, if I see some coins move then come here to reclaim them?

[rico666]

Ok, so, if I see some coins move then come here to reclaim them?

Yes.

Or better yet - directly to our LBC Discord Chat: https://discord.gg/YjD2Sx
where we can solve things more interactively.

[dcw312]

New client 1.192 (see News in my sig for changes);

I found the cause of the spam. I was using Amazon EC2 Container Service. With the service you configure how many containers you want running at a time. I think I had it set for 8 "desired tasks". The service will deploy 8 containers, execute their entrypoint file, when a container/task stops running, it will start a new one in its place.

I just ran the container locally by supplying "bash" as an override entrypoint.

Code:

Mac$ sh secret/run-local.sh
 
lbc@22be2fedf198:~$ cat entrypoint.sh 
#!/usr/bin/env bash
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP 
./send-it.sh

lbc@22be2fedf198:~$ sh entrypoint.sh 
New client '1.192-LBC.bz2' found.
New generator found. (DL-size: 0.19MB)
Some files were updated - please restart LBC. 

At this point the container thinks it is done with it's task and stops. The service will replace it with a new container. This is also how Open Shift, Kubernetes, etc work.

So there was just a "groundhog day" (Bill Murray movie) scenario. A fresh container would be made from the image. It would get the update, but think it was finished.

I just reviewed the LBC -h help and see there already is a flag for update.
I think I fixed in: https://github.com/dcw312/lbc-client-docker/issues/7
The entrypoint is now like this:

Code:

./LBC --update
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP 

[rico666]

At this point the container thinks it is done with it's task and stops. The service will replace it with a new container. This is also how Open Shift, Kubernetes, etc work.

So there was just a "groundhog day" (Bill Murray movie) scenario. A fresh container would be made from the image. It would get the update, but think it was finished.

This explanation makes perfect sense, and yes, a preceding ./LBC -u solves that particular problem.


On other topics.

We did test yesterday the first AVX512-enabled generator, seems to bring a slight speedup compared with avx2 binaries (Haswell, Syklake)
I'm looking into some other issues of the client and will make one more update to offer a skylake-avx512 generator "soon(tm)".

[dcw312]

Rico gave me a link to show the hooks documentation. It opened up a "secret manual" that I had never seen before!

Here is the problem with the website I am seeing. Steps to reproduce:
1. Click  https://lbc.cryptoguru.org/man/user#hooks
2. Verify that you see the hooks information
3. Click trophies from the left bar
4. Click Manual from the left bar

Expected behavior: The hooks documentation is visible
Actual behavior: The hooks documentation is not visible on the page

I am using Chrome on Mac.

Can anyone else verify the problem?

[rico666]

Rico gave me a link to show the hooks documentation. It opened up a "secret manual" that I had never seen before!
...
Can anyone else verify the problem?

To quote my answer:

I seem to be old school
When books were a thing
Big technical books. Consisting of several "Parts"
Clicking on manual reveals Parts I to IV
Hooks are documented in Part II - User Manual

[Pustul]

Hi, I stumbled across this project while researching math behind the process of generating BTC addresses. Very interesting project!

I was wondering if this will run on ARM cpus, I tried to set it up on a Raspberry Pi and I have an error during benchmarking:

Code:

Benchmark info not found - benchmarking... ./kardashev-generic: 1: ./kardashev-generic: Syntax error: ")" unexpected
Generator validity check failed. Expected: 5 or 7, Got: 0
With output:
--

I have also tried to set it up on a mining rig I have and it works but I have this warning message when launching the script:

Code:

./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge)

Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD?

[rico666]

I was wondering if this will run on ARM cpus, I tried to set it up on a Raspberry Pi and I have an error during benchmarking:

ARM is not supported, only 64bit x86 compatible (x86_64 a.k.a. AMD64)

Code:

./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge)

Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD?

No, it's complaining because your OpenCL installation is slightly broken.
Reinstalling OpenCL helps. clinfo should work, if you have a Nvidia GPU, nvidia-smi should work, then you are probably good to go.

The performance you see is because you run a CPU-only generator.

In this project, you have to earn your merits and perks. One of them being to be allowed to use a GPU. Which comes after you delivered 3000 Gkeys CPU-only.

[Pustul]

Code:

./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge)

Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD?

No, it's complaining because your OpenCL installation is slightly broken.
Reinstalling OpenCL helps. clinfo should work, if you have a Nvidia GPU, nvidia-smi should work, then you are probably good to go.

The performance you see is because you run a CPU-only generator.

In this project, you have to earn your merits and perks. One of them being to be allowed to use a GPU. Which comes after you delivered 3000 Gkeys CPU-only.

Oh ok I didn't realize it was complaining about OpenCL since it was running on CPU only mode. I will fix it when I get to enable the GPU. For the 3000 Gkeys I am working on it

[rico666]

Oh ok I didn't realize it was complaining about OpenCL since it was running on CPU only mode. I will fix it when I get to enable the GPU. For the 3000 Gkeys I am working on it

It's a tribute to the unified generators (earlier we had different generators for CPU and GPU, now the binary supports both), it needs to dynamically link against a OpenCL library - but you can install a dummy one:

https://github.com/OCL-dev/ocl-icd

Most linux distributions have that as a package.