See above


and later then (a.k.a. on subsequent invocations)


or use the config file (also see above) if you do not want to type it over and over again nor if you want it to be seen on command line.


Rico

I expected some hiccups - that's why I posted the docs in advance

* Id is too short (8-32 chars)
* You need to set a password, so you have to provide some old password.

As you had none before, you can take an arbitrary one

so if you do


it should work. You should see a message "Password set". From then on -s mypassword is enough.
If you would like to change it, you need to do -s mypassword:newsecretpass




Rico

 

update in progress. Please wait with the shitstorm until it's over.

Pool in perfect working condition again.


Rico

LBC client update announcement

LBC client will auto-update itself to a new version >= 0.990 soon. This version has some long awaited features, so you might want to give them a try:

1. Set own id

You will be able to set your own id with the -id <string> command line parameter. String may be any of the 63 "word characters" (a-zA-Z0-9_) - no space - and must be between 8 and 32 (inclusive) characters in length.


With this, you will be able to start your LBC clients on different machines under the same id and therefore contribute "as one" to the stats.
If you PM me with the MD5 ids you had so far and you'd like to aggregate, I will move their contributed GKeys to your desired id in the DB.

Of course, the automatic issued md5-id will continue to work, so if you do not want to set an id, just don't. You can - of course - set some arbitrary md5 id  

I hope, you are aware this feature gives you some freedom that could be abused, so should there be some profanities appearing in the stats or anything shady I have not taken into account yet, I reserve the right to modify the ids and in severe (recurring) cases to ditch them. If you have to have an own id, try to be unique, try to be funny or just keep some inconspicuous md5 and impress by the #Gkeys next to it.

2. Set a secret/passwort

By setting an id you could assume an arbitrary identity and with such obtain information that's not meant for you (e.g. now with -q "query"). Soon, there also will be a possibility to attach a BTC address to your id for payments of bounties, incentives, grants and unclaimed found bitcoins. *crowd moans*

So it makes sense to protect your id by a password, which is done by the --secret [oldpwd:]pwd  command line parameter. It certainly makes sense to set a password right when setting an id. e.g. like this:


From then on, you use LBC as you did so far, only you have to use the -id and -s parameters in addition, else


or


Yes, the password is stored salted + SHA256 hashed on the server. Should you forget it, all I can do is to remove it or set another one, I can't bring it back (yet :-)).

3. Current Speed

When LBC measures the speed of the generator, it does so on one core. The result serves as bootstrap information when asking the server for a certain amount of work. Depending on the system load, the number of cores working, temperature etc., the key generation rate may differ significantly. Therefore, the new LBC client will perform measures of the current performance and show you after each "round":
This is how it looks like on my system (shortened):


You can see how the 1-core performance (of ~730000 keys/s) drops to around 600000 keys/s when all 4 physical cores are active and the 4 logical cores themself bring only about 150000 keys/s each.

4. Local config file

Entering command line parameters can become tedious. Also, giving the secret on command line may expose this information to other users on the computer. LBC now supports configuration by a config file in JSON-format. If a file lbc.json is found, it is taken as the default config file for LBC. It can look e.g. like this:


Of course, the command line parameters still work and have higher precedence. So if you start LBC without any command line parameters and this file is present, it will use 4 CPUs, send the id and secret to the server and ask for 20-minute chunks of work. If you start LBC with -c 2, this will take precedence and despite the information in the config file, it will use only 2 CPU cores.


5. Other

Feature: no_update flag. If you feel uncomfortable with LBC auto-updating, you can use this flag to  prevent this behavior
Bugfix: The failing test with LBC -x (expected 4, found 0) has been fixed.


Questions?


Other Updates:

Server:

- mostly manual updates
- what happens when something is found https://lbc.cryptoguru.org/man/user#found-
- how to use pulsed operation to fire up LBC only at nighttime https://lbc.cryptoguru.org/man/user#pulsed-operation
- elaborated on maximum keyrate and physical/logical CPU performance https://lbc.cryptoguru.org/man/admin#generator-speed

Generator:

Again a tiny performance gain of 1.5% for the avx2 generator, by compiling it with gcc 6.3.0 instead of 5.4.0


Rico

eh... no. The false positive rate should not become a problem and for that the number of the addresses with funds on them is about right. If the number of P2PKH addresses with funds on them should suddenly double or triple, we'd probably use only the 10M most funded, but it's not about speed, it's about false positive rate.


Oh that conspiracy theory.  Drink much?

We're looking at all Common P2PKH, not just "early Satoshi bitcoin addresses". Of course - if this project could help so that Satoshi can move his coins and not be bothered ("I'm not Satoshi, I just happened to find/buy the keys") - then I'm happy to provide this plausible deniability for him.


Donald Trump is paying for that - with Mexican money.


Rico

Too slow or often with restrictions or cached (e.g. only updated once every 2 seconds).
So you have to use it at least in combination with other scraping methods.

Rico

So you're saying you would want to develop such a bot, with the input from traders?
Sure - why not.

As for the desktop application - you are aware that HFT has arrived in the BTC world?
And even if we're not talking about HFT, you still want your bot to have that ms advantage when setting/pulling an order over the other bots.
For that, you certainly do not want your bot to be based behind a lame ADSL/VDSL/Cable connection in your home, you want it to be located at your/some ISP that gives you decent ping times to the exchange of your heart.


Rico

Hi,


the question is not stupid at all. Ever since the pool has found it's 1st "real private key" i.e. of an address with unspent input and the following discussions which can be seen in this thread, I thought about whether/how to take the "BTC holders" as you name them out of the equation.

The approach as you suggest has a technical and a motivational problem:

The search space is 2¹⁶⁰ bits, which is roughly 10^48.1. Even if we take the 2^137.5 into account until something is found, that's still about 10^41.4. The bloom filter currently used has 2^32 bits, 20 hash functions and holds around 9 M entries - resulting in a false positive probability of 10^-27. This means, that on average, during our search of the search space until something is found, we will hit about 10^14.4 false positives.

While you can raise the probability (I'd not speak of speed) of a find by adding more "targets" into the bloom filter, you inevitably also raise the number of false positives. Current parameters given, we will have a false positive every thousand trillion trillion generated keys, potentionally we will - as is - see over one hundred trillion of these. Raising the number of hash functions would hurt speed, raising the size of the bloom filter is additional memory requirement. I can imagine the pool to become a million times faster than it is now and then the current false positive rate starts to fail us.
While the 512MB are currently not a problem for main memory, uploading the bloom filter as global memory to a GPU and leaving enough for a couple thousand kernels, is only viable with GPUs that have 3GB or more.

I know that all this is only because we're at the moment taking the constraints from the brainflayer bloom filter implementation as given and that a specific redesign of the BLF allowing maybe dozens of millions of "control addresses" would give us a way bigger fishing net than we have now. However, we have searched almost 3 x 10¹⁴ keys now and had already two or so false positives (plus the 7033bd97579b0105561056fcfc1ddcaa8a04abf0 -> 40000031337 find which I'm still not sure what that was about), so jeopardizing the BLF false positive probability is not some path I'd like to follow.

Then there is the motivational part as mentioned: Myself, I can mobilize around 2-3Mkeys/s intermittently - if I was to average that down to continuous operation, not much more than 1Mkey/s would be left. If I read old articles in the thread and see how I had around 150Kkeys/s before the pool went online (and it had about 300Kkeys/s then), I'm not sure the pool would be today churning nearly 60 Mkeys/s if people weren't motivated to participate.

Now I certainly don't want that motivation to be to "steal other peoples funds" and to the best of my knowledge no such thing has happened with the pool (although a prominent core-dev shouts otherwise). I know that RyanC has announced a bounty of around 5 BTC / min $3000 for the find of a collision, maybe there are other bounties too. Not sure if a reward/bounty-only system would mobilize sufficient computational power.

I still do believe, that the pool can fulfill it's main task of finding a collision without stealing from people. If - of course - such a thing did happen, the option to fold the pool altogether is still open. While I haven't released all parts of the source that would allow someone else to immediately set up a similar thing, it's not impossible. I did it, any other fairly competent hacker with enough time on his hands can too. In fact, we can never be sure if there is not already one or more clandestine projects doing a similar thing - but with different purpose.

Also, there are other aspects to this pool and the addresses with funds we are checking against. How many lost bitcoins are there? Is it stealing if we find these and if - say - within a year the owner does not appear distribute them among the pool participants, charity or if the finder keeps them then? If I was to find the hard drive with the private key(s) to 7500 BTC on some landfill (https://www.theguardian.com/technology/2013/nov/27/hard-drive-bitcoin-landfill-site) and if I kept it - would that be stealing them? If I did not find the drive, but just the keys - would that be stealing them?

I know everybody has his opinion about this. My opinion - after lots of discussions - is that whatever will happen, right now the LBC pool is a unique project walking in uncharted territory. The engineer in me thinks this is fun. The bitcoin enthusiast in me (฿ → ∞) honestly believes  this project is as designed a constructive contribution to the bitcoin ecosystem.


Rico

Thanks to all for the ongoing support and interest in the project. I'm being asked about my current work on the project (mostly GPU  ), so I decided to keep some info about the pending work and development on the LBC here.

Basically, LBC consists of 3 main components: The server, the client and the generator.

The server is what drives the web pages at https://lbc.cryptoguru.org, takes work from clients, issues new work, keeps track of what has been done already, computes stats and is the top-level instance to check PoW to make sure clients do not cheat about work done. It has some mechanisms to protect the server against DoS and blacklists misbehaving clients.

The client is the "local intelligence" on your machine. It talks to the server when asking for work or when delivering PoW of work done. It fires up the generator(s) according to the amount of work promised to do, which depends on the time committed and the capabilities of the local machine. The client also tries to make deployment of itself as easy as possible and handles updates of itself, the generator and the blf-file.

The generator is the low-level workhorse. Its sole purpose is to generate hash160s from private keys of a given range and to compare the generated hash160s against those in the BLF file (a bloom filter) containing all known hash160 with funds on them. The generator (or generators if you have a multi-CPU system) is fired up by the LBC client with the correct partitioning of search space, it is given a challenge parameter and has to answer with the correct response to be evaluated by the LBC client.

So the TODO will mention work TBD on these 3 components. Depending on time available, urgency, personal preferences and mood (hey - I'm doing it for fun) I'll shift my attention between these 3. E.g. I've been working for the past - at least - month on the generator workhorse optimizing it. And while there are some very promising things that could be done (EC arithmetics as pointed out by arulbero), there are some equally pressing things regarding the "intelligence" part i.e. the LBC client. So expect the next big thing(tm) to come from that component.

I should mention, that I got quite some motivation to look at the GPU generator again and managed to complete a nice and swift GPU-hashing prototype. That is, on my M2000M (640 cores) hashing h160 with almost 100Mhash/s which is not optimized yet. I was wondering if I did a hybrid CPU/GPU generator where I'd do the EC on the CPU(s) and offload the hashing to the GPU, I could have that pretty quick and maybe get again a nice speedup (my notebook does atm ~2.8Mkeys/s and I guess with GPU offloading the hashing that should be at least 6.7 Mkeys/s)


Rico

I gave my nose a blow, unfortunately no GPU client appeared in my handkerchief.
Any other suggestions how I should "try"?


Rico

If you have access to a Knights Landing CPU (http://ark.intel.com/products/codename/48999/Knights-Landing), please ping me if you would like to try a generator, I have AVX-512 binaries available.

A single Intel Xeon Phi 7290 can give you 50 MKeys/s! That's right - about as much as the total pool speed right now.


Rico

Anyone with an AVX2 capable CPU (haswell, broadwell), might want to restart LBC for a generator auto-update.

Your keyrate will go up by ~20%.


Rico

ich sehe gerade oben: i5-2300 @ 2.8GHz, da kommen die 397 000 wohl hin.

1073 Mkeys in 10 oder 15 minuten? Bei 3 CPUs und 10 minuten bist Du bei 596111 keys/s, das wäre sehr gut. Bei 15 Minuten  bist Du pro Kern bei 397407 keys/s - immer noch respektabel. Welche CPU hast Du denn? Die Angabe "Your maximum speed ..." beim Benchmark ist ausschlaggebend.

BTW: ich habe gerade einen optimierten AVX2 generator auf den FTP server geschoben. Da sind ca. 20% mehr Performance drin.
Also wer so eine CPU hat, möchte vielleicht LBC restarten (führt dann ein auto-Update durch).

-> https://lbc.cryptoguru.org/man/admin#generator-speed

sind noch nicht alle up-to-date, weil mir noch zu einigen das Feedback fehlt (Intel i7-4510U @ 3.1GHz sicher mindestens 460 000 mit dem neuen Generator laut Feedback und Screenshot ~535 000)


Rico

https://en.wikipedia.org/wiki/The_Million_Pound_Bank_Note

It is interesting how - by the mere claim of wealth - people start spinning (probably in the hope to get their share).


Define "plenty", for this defines if partnership with you is worth a consideration.
10BTC... so two man-months of R&D, or 1 month R&D and some marketing
or 14 days of R&D some marketing and some infrastructure.

 

Good luck.

Also, do not forget that VCs these days do not simply offer "money", but "smart money".

This advice was provided free of charge.


Rico

"Ich" nicht, letzter Fund war am 16.1. - zwischen den Funden dauert das schon eine Weile, auf den letzten haben wir 3 Monate gewartet.
Der Pool hat momentan über 40MKeys/s und wir nähern uns den 48bit (von 160) abgeklapperten Suchraums.

Bei der Geschwindigkeit können wir im Schnitt in 33 Tagen #49 der Puzzle Transaction gefunden haben.

arulbero hat im englischen Thread einen Interessanten Vorschlag gemacht, der die public key Generierung fast zum Nulltarif verdoppeln könnte. Ich sehe mir das bei Gelegenheit an.


Rico

I am running blockparser from time to time, so the top BTC addresses looked like that about a week ago

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
              Balance                      Hash160                             Base58                  nbIn        lastTimeIn          nbOut        lastTimeOut
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
         131439.82180613 e95dbb25283cc35d4a6aefa76c0382e63ce0fa36 3Nxwenay9Z8Lc9JBiywExpnEFiLp6Afp8v     83 Fri Jan 13 21:31:52 2017      20 Fri Jan 13 21:31:52 2017
         124178.00014420 bcadb700c24da04b17feb9aa9bd71e368a4b623c 1JCe8z4jJVNXSjohjM4i9Hh813dLCNx2Sy     20 Fri Dec 23 07:58:33 2016       1 Wed Aug 24 11:48:26 2016
          83136.54056264 4fafd53c1d1359fafb95a231ef16e64c01112cf2 38xMwnXgYmnzvbmqz8TFZ1zxnwVcdv1uq4    684 Sun Jan 15 14:07:57 2017     280 Sun Jan 15 14:07:57 2017
          79957.12659773 a0b0d60e5991578ed37cbda2b17d8b2ce23ab295 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF     89 Wed Dec 28 09:53:40 2016       0 Thu Jan  1 00:00:00 1970
          69370.10690994 b3dd79fb3460c7b0d0bbb8d2ed93436b88b6d89c 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx     69 Sat Nov 12 03:16:46 2016       1 Thu Apr 23 14:10:25 2015
          66650.59640465 3d03002dbed5cb1dc10fc6bcb0886d2df32f2838 16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt    170 Sun Nov 13 23:32:38 2016       0 Thu Jan  1 00:00:00 1970
          66583.22391617 cd4b7b8f9db1b0c709fd0c9f0534fca6a9f40495 1KiVwxEuGBYavyKrxkLncJt2pQ5YUUQX7f    120 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
          66452.06624862 f9e6bbcdc83d8f351014e07495f386fe1067ec7b 1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK    114 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
          66378.80961189 6a6015e3793207af6dff7c48ee9e193d73547cdc 1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR    181 Thu Feb 18 17:09:28 2016       0 Thu Jan  1 00:00:00 1970
          66235.82427687 8b70193546504fa3623598722575f70b5b1c6455 1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa    125 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
          66233.73859546 908b47d6a15d89c3ee34df1bc68a00ec4ff70c9b 1EBHA1ckUWzNKN7BMfDwGTx6GKEbADUozX    127 Fri Aug 26 09:33:37 2016       0 Thu Jan  1 00:00:00 1970
          66205.47375047 27ed35ebcf72744ec3b4a0f4dbb83d7620acf443 14e7XAZbepQp9MXXzjNG3fNLoAUpaBAXHW    132 Fri Apr 29 10:29:14 2016       0 Thu Jan  1 00:00:00 1970
          66170.69605917 f33a3af3695f041e2ea6271f1fe6309abac4dd58 1PB4xXUFyy4kSNqroCBVaQuCuw9VcN3be4    171 Fri Feb 12 04:57:18 2016       0 Thu Jan  1 00:00:00 1970
          66163.44524020 53f9818e8d2d23c3163c01a33d83e49ebfa16ac4 18f1yugoAJuXcHAbsuRVLQC9TezJ6iVRLp    124 Wed Mar  9 23:07:42 2016       0 Thu Jan  1 00:00:00 1970
          53880.05741758 d74de95f65799793f16b91ed8a152110652d3ec0 1LdRcdxfbSnmCYYNdeYpUnztiYzVfBEQeC     21 Fri Feb 12 04:57:18 2016       0 Thu Jan  1 00:00:00 1970
          48260.47200000 95d214e83ce3f9c635fdc049c4d6bf0fd40306ad 1EfBMK9q6rGFZazeF7jyNdTgqGYgcDgRE5     13 Wed Aug 24 05:31:56 2016       0 Thu Jan  1 00:00:00 1970
          45072.71428633 c5464169a9aabad0e361ccf1d436d3e843708e7d 3Kg7Cmooris7cLErTsijq6qR1FH3cTiK2G  20897 Fri Jan  6 20:05:00 2017      10 Fri Jan  6 20:05:00 2017
          44998.00006000 3d9e561f21d312f9b8b46e74169263e2452d5591 16cou7Ht6WjTzuFyDBnht9hmvXytg6XdVT     58 Fri Jul  8 14:53:10 2016      55 Thu Jun  2 14:09:27 2016
          44864.42498338 e552a6a2afa8ae80a773dc9bb95f8c25c5b3bdd3 1MuYkciQTfRsU94ReAe5MiAfUpCrbLBcFR  20887 Fri Feb 12 04:57:18 2016       0 Thu Jan  1 00:00:00 1970
          44097.99133500 563362991b8627e0def8c69b086339e59dc11e4c 18rnfoQgGo1HqvVQaAN4QnxjYE7Sez9eca    173 Fri Jan 13 08:56:02 2017       9 Wed Mar 30 15:49:12 2016
          44009.11740108 2e0d00d098274c907a59713677da96f9bd9e49b7 15CVfJUC1LKn1GKZx6RM5UMbFfnTd8vTT4     29 Sun Jul  3 09:57:42 2016       0 Thu Jan  1 00:00:00 1970



You can get a lot of other information from a blockparser run too. E.g. the oldest most funded BTC address. Which is:


 200.00000000 bcade5c8ddf6a571e438575771ce766ae7a01948 1JCeMgVeDzLdxz3G5vRin2ydNxUp6E5yFf      1 Wed Feb 11 23:32:48 2009       0 Thu Jan  1 00:00:00 1970



Which - I'm sure only by pure coincidence - is also the only one that has the same bcad hash160 prefix like the 2nd most funded BTC address.



Rico

No Bitcoins are lost forever. Sooner or later we will find at least one of the 2⁹⁶ keys there are to every bitcoin address.

Rico

RobertVan = DemonDracula = scammer

Self moderated threads, he dilligently deletes.

https://bitcointalk.org/index.php?topic=1720981.0

Unfortunately too lazy to change his offer.



https://bitcointalk.org/index.php?topic=1752629.0


Rico

I gave SHA256 quite some attention and there is a puzzling fact to SHA256:

I ended up using most of the code from OpenSSL 1.1.0c as it proved to be faster than supervanitygen code, which in turn uses
The Intel reference implementation from 2012: https://github.com/klynastor/supervanitygen/tree/master/sha256

What puzzles me most is that I should get in between 320MB/s and 560MB/s with the Intel reference implementation on my CPU. It's padded to 64bytes, so this would mean something between 5Mhash/s and 8MHash/s for compressed keys. Should be at worst 3.3 seconds for the 2^24 compressed keys. Still, the 4.5s I get from OpenSSL is better than what I could get from the 2012 Intel code.

So either I am not using the optimized code from Intel well, or there is meanwhile better optimized code (I haven't inspected the OpenSSL implementation, as reading thr OpenSSL code is ... let's say even worse than libsecp256k1 code), or I cannot simply transfer the 320MB/s to 320MB/s / 64bytes or....
Intel had 2015 a writeup about improving openssl: https://software.intel.com/en-us/articles/improving-openssl-performance

Basically the LBC generator is now about twice as fast as supervanitygen, as it does 730 000 keys/s (supervanitygen 767 000), but contrary to supervanitygen HRD-core does both uncompressed and compressed (supervanitygen only compressed).

Your suggestion about doubling the key rate by using the complement private keys is as of now the only thing that could significantly raise keygen rate. Maybe I could hit 1Mkeys/s on one core on my CPU, but I believe this is really it what can be done with CPU - unless someone can come up with something really surprising.


Rico

Hi,

first let me thank you for your input, I very much apreciate that. After developing this thing for over 6 months, I am of course aware about several things (like I don't have to worry about side-channel attack and other security issues). I also believe that there is not much left from the original brainflayer code in the HRD-core generator. The original brainflayer gave me a keygen rate of 520000 keys/s, whereas I am now at 730000 keys/s.


At the moment the time cost for generating 16777216 uncompressed public keys is ~ 6 seconds on my machine. Which - if I compute correctly - boils down to ~0.36 us per private key. the other 16 seconds are required for creating a compressed key (negligible), to compute the hash160 of both the uncompressed and the compressed key and to check these hash160s against the bloom filter.

Of these 16seconds, 7s is the two RIPEMD160 computations and 8s the two SHA256 computations. Rest is bloom, startup/init etc.


I have posted the code already.


If I am not entirely mistaken, I compute 1 inverse each 4096 private keys (8192 addresses).



Rico