Can't run 2nd GPU.



PC specs
i7-6950X
2x GTX 1080 Ti

Nice to see this is still going on.

Finally back after a long break and busy times.

Might be time to start up the server again and see what a nVidia Quadro card can do.
I know I did around a million keys pr sec with the cpu alone.

Ah! My most devotee minion is back. 

You will be pleased to hear, that the CPU should be able to do about twice as much now and with the GPU acceleration a x6 or x7 speedup on top of that.

Meanwhile there are people with 150+ Mkeys/s machines. If they only kept them running. 

Recently I read another masterpiece on LBC feasibility:
https://breadwallet.com/blog/large-bitcoin-collider/. As tweets are
not the right medium to transport all the information about what's
wrong with this, let's look at it here:

First, I would like to state that I agree with the headline "LBC poses
no threat to Bitcoin". Of course I agree for a completely different
reason than the usual - wrong - grade school arithmetic exercises also
presented in the breadwallet blog.

You must know, there are already quite some of these texts and they
all fall into the same template category

• Think of some premise that seems outrageous (thus not achievable) today
• Throw your elementary math on it (perform equivalence transformations)
• Get some equally outrageous result which you consider "proof" of your premise

There are many examples:
https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money
plus like 100 threads on bitcointalk.

It has been fun watching these pamphlets, but it's getting
boring. Moreover, it's getting sad that such texts still seem to meet
the appreciation of a nodding flock. So - sorry Aaron Lasher, please
don't take it personally - I feel I have to start beating up these
pamphlet-generators. By argument ofc.

The author of the article is CMO (I guess that's Chief Marketing
Officer), and claims to have studied Math and Psychology at least to
the BA-level. I take that as a given and send my compliments for the
nice share of psychology in the text. I also do not take his text
personally, because his aim certainly wasn't to badmouth LBC, rather
than to calm down worried users.

The Mishaps

If you are Chief Marketing Officer for a Bitcoin Business, you should
have your numbers right. Especially those numbers that are important
if you want to act as a proponent to Bitcoin. Such as the number of
addresses with funds on them. You know - this number says something
about the adoption of Bitcoin and naturally you want to make the
adoption rate look good. If you - as a CMO - claim there are 5M
addresses at a time when there are 16.1M addresses with funds on them,
you're not doing a good CMO job.

Of course marketing people get the benefit of the doubt as being
tech-unsavvy so I take all the occasions where Aaron didn't get the
numbers right as non-intentional. He simply didn't know better rather
than tuning them for a purposeful deception. E.g. when claiming that
the address 1G1W1DbeUeH2AKKicqMNuhEuaoqPDNuXDF represents the number
4,036,794,190,046,444,310,490,975,774,115,813,708,619,807,673,368,708,224,110

Or when mixing up keys and addresses.

Or when mixing up the BTC-network hashrate (SHA256d) with the
key-generation (ECC+hash160).

Or ... you get the idea

The Spaceship

Before I dissect his calculations, let's take a step back and look at
his premises. Representing the search space, there is a chess board
with an edge length of quite some light years. Arbitrary squared. He
also uses inches instead of a metric norm.

There is a "Spaceship" - capable of travelling with the speed of light
and still not being able to cover any significant part of the chess
board.

This is the outrageous part. We all know mankind is still unable to
reach anything near the speed of light and except for some hardcore
sci-fi fans (probably even these), most take that as a given. To make
things even more plain, this spaceship is left in the dust by some
super-spaceship (equivalent to the Bitcoin network) which is about 312
million times faster than the speed of light. Even this
super-spaceship will need 2.25 quadrillion years
(2,250,000,000,000,000) to find - allegedly - an address with funds on
it.

Phew. Impossibru!

Yep! LBC poses no threat to Bitcoin. q.e.d

...

Or does it?

The Fallacies

Before I even go into the details, let's take a look at the most
evident craftmanship error Aaron made: The number of addresses with
funds on them. 16.1M compared to his 5M. Let's be generous and assume
only a factor of 3 (when it's 3.22, and we'll see that decimal places
do matter) he was off. Let alone this folds his 2.25 quadrillion years
to 0.75 qn. We saved a whopping 1.5 quadrillion years! MAGIC!

Now if you are not taking the same drugs as creationists do, you will
assume our universe is a mere 13.8 bn years old. So you consider 0.75
qn years equally irrelevant. Well, the message should have been the
1.5 qn years off, but now that we found such a big ... hmmm
... rounding error, let's look at the calculations in more detail:

Aaron got it right that we do not need to have a look at all
2²⁵⁶ bits, but a mere 2¹⁶⁰, he divided the
latter with his 5M addresses (should have been 16.1) to get the space
"until 1st hit". Hm. Is the search space even right? Aaron
unfortunately is constantly mixing up "private keys" and "addresses",
even more so that he sees a 1:1 relation between these.

Now if the LBC had it's own CMO pet, it would present the pool rate in
MAddrs/s instead of Mkeys/s, because that number would be twice as
big. You remember: the LBC is looking at both uncompressed and
compressed addresses. What does that mean? Well (if we leave the
advanced math discussion aside), it means we should be able to look
only at 2¹⁵⁹ private keys in the 1st place.

"Bah! 1bit", I hear you say. Yep - 1bit. This 1bit means halving of
the search space. So 2¹⁵⁹/16.1M and we are at almost 362 tn
years search time instead of our 2.25 quadrillion years. Holy sh*t
that's some difference. But wait - that's still the search time for
our super-spaceship. Nothing will ever go with 312 million
times the speed of light!

Well - the bitcoin network does evidently - at least in this crude comparison.

"Going with the speed of light" - in the text above would translate to
a key generation rate of 5.9 Gkeys/s for the LBC. So far, we had a
peak of 2.5 Gkeys/s, so something above 0.4c, so we're at least doing
better than NASA. Oh - and this keyrate was 90% contributed by a
single man. With CPUs. LBC - as is, i.e. with no code change - could
handle about 50 Tkeys/s, so 8474 times the speed of light according to
Aarons magnificent universe.

So it's important to know, that the "speed of light" in the
breadwallet-text is a mere psychological trick. If you convert it into
some real-world keyrate (5.9Gkeys/s) it certainly loses some of it's
mystical aura.

Moreover, the constant (not even linear) nature of the comparison
becomes apparent. As if the LBC was to remain at a certain keyrate for
"quadrillions of years". Gimme a break!

What's really going on?

For now, LBC is mainly an engineering task and a little bit of a
mathematical task. The math will become more and more important should
we hit some engineering barriers. There are no barriers in sight for
the near future. LBC is still a baby project both in terms of code
maturity as well as in terms of size. There are like 20 clients
contributing. Twenty!

Judging LBCs impact on Bitcoin based on it's current state is like
judging Bitcoins impact on global economy based on its current
state. You have to do a lot of extrapolation and you should know that
you are bad at it.

Let me be more specific: All the calculations in texts like the one
I'm answering to are bullshit. The "super-spaceship" with its 4
Exahash/s is a mere 8 years old. You cannot possibly make a
calculation showing this instance will take xxx quadrillion years to
search. How fast will the hashrate be in another 8 years? No one
knows. Neither do I, nor does Aaron. Except I don't claim I do know.

How fast will the key generation rate of LBC be in 8 years? No one
knows. Neither do I, nor does Aaron.  It may be 0, it may be way more
than 4EKeys/s or it may be something in between.

If 8 months ago someone told me, that the LBC would cover 1 million
pages on http://directory.io/ per second, checking every single
address listed there against 15+M addresses with funds on them
and that this speed would be considered really slow (it's what
we currently have), I would think of him being a crackpot. If I was to
make such claims when LBC started (with its 150 Kkeys/s), I would
probably have had earned the "crackpot" title myself.

Our software is meanwhile more than 400 times faster than it was 8
months ago. The hardware available today is on average 50% faster than
it was 8 months ago. In 8 years? Well, you will get a high-end Volta
GPU on eBay for $50 (probably less), so I assume 1Gkeys/s per user
will be the low average. When my notebook delivered about 1.5Mkeys
MORE with the new kardashev generator a couple days ago, it was not
even thrilling anymore. "1.5Mkeys/s. Hm. So what?" 8 months ago, this
would have been 10 times the total pool capacity.

But ... but .... But exponential!

Yes, Bitcoin uses exponential functions for its protection. It can
throw up to 2²²⁴ difficulty at the miners, or up to
2¹⁶⁰ search space at the searchers (Yes: LBC pool
participants are "searchers"). But that's it. The 160 and 224 as you
can see are finite numbers. That's no infinite exponential function.

And our spaceships are also getting exponentially faster. Don't forget
that - should you once again feel the urge to write up a text like the
one I'm answering.  Do not fall prey to the "I think of some
outrageous premise and then perform various equivalence calculations
on it".

Because if you do, you may end up with a nice picture of the sun, or a
space-ship, or digging the Mount Everest, or any other mathematical
vomit. Your only achievement will be the generation of a text
containing not even a linear extrapolation, but a constant
extrapolation based on seemingly outrageous premises.

If you must, just assume the speed of key generation gets doubled
every year and see with how many quintillion years search time you'll
end up with. Doubling? Every year? Impossible? I would not be
surprised if the superposition-units in regular off-the-shelf PQCs in
25 years will be able to perform a search of 2⁶⁴ keys per
second.

Of course by then - if BTC still exists - it will have migrated to
novel post-quantum standards. The question remains what will happen to
all the lost and forgotten BTCs until then.

On Profitability

LBC is not a commercial project and it does not promise any
gains. Still, there may be a profitability aspect to it.

At the current difficulty, your CPU would have to search for 10653936
years to find a block (12.5 BTC+fees) 11645110 years for the estimated
next difficulty, due in 8 days. You see the difficulty is rising way
faster than you can cover with time. => You will never find a block
solo-mining with your CPU anymore.

When searching addresses, there is no rise in difficulty, quite the
contrary, the more addresses there are in use, the easier it becomes
to find one.

Is there a specific BTC difficulty when searching becomes more
"profitable" than mining? Of course. Also, the mining-difficulty
cannot be looked at without a block reward.

If LBC would not evolve any further - i.e. software to remain at same
speed - by 2036 it would be theoretically more profitable to search
for BTC addresses with your CPU than to mine blocks (with your CPU).

(For this calculation, you have to extrapolate the difficulty, the
number of addresses in use and take the BTC/block reward into account
and we're talking trillions of years)

https://en.bitcoin.it/wiki/Controlled_supply

Should BTC value continue to rise, I assume that long before this date
- not later than 2030 - it may become financially interesting to
search for "old forgotten BTCs on P2PKH addresses" (because by the
time we certainly will have other types) than to mine new ones. This
is the latest date when Chinese ASIC manufacturers will start to
provide Keygen-ASICs.

There may be a 1 million BTC search incentive. It remains to be seen,
if the BTC community agrees to "invalidate" these old BTC addresses
before anyone can find them or how much these will be worth by 2030.

If you think 2030 is a long way to go, you should stop talking about
"quadrillions of years" because it does not suit your event horizon.

Hey, I think I have an idea for a pool search project (but it would require rewriting the client a bit): Searching for P2SH puzzles.
There have been multiple P2SH scripts which consisted of only one opcode (byte), likely made as a challenge. I think that with the pool speed, we'd easily find some longer scripts which can be spent (if they were created, of course).

What do you think?

For now, I also want to learn more. E.g. about GPU programming, especially OpenCL.
While the OpenCL code in LBC is actually faster than the one in OpenCL-vanitygen,
it seems it is still far below it's potential.

If hashcat benchmarks are to be believed, my low-mid-range GPU
should be able to perform at least 270 Mega-hash160 per second!!!
(compared to the current LBC implementation: 46 Mega-hash160 that put around 85% load on it)

And we're talking regular hash160 = RMD160(SHA256(x)), not the tuned Bitcoin-hash160
(where you have fixed input sizes for SHA256 and a very restricted input size for RMD160, both resulting
in significant speedup of the code - which we use.)

In short: Although we have problems to put load on GPUs, it looks like the GPU would be able - with the
correct programming - take 10times more load than we currently expect. We're not using the GPU
vectorization capabilities at all :-(

I thought about asking some professionals for help
https://streamhpc.com/development/making-the-release-version-of-prototype-code/
but I'm afraid of the cost...

That still means the same RIPEMD-160 hash, so yes.

New version of the client is available. Generators have also been updated to accept "GPU worksize" parameter.
Biggest changes:

• comfortable multi-GPU operation
• support of Amazon GPU instances (p2.xxxx)

This is only of interest for people with multi-GPU setups or those who want to run LBC on Amazon GPU Instances, almost everyone else (*) will not need the new features. LBC will now distribute the workload to all given CPUs and GPUs in a balanced way. In previous versions, you had to start up a separate LBC client with -gdev X parameter for every GPU you had. No more.

Assume you have 4 GPUs and 32 CPUs. LBC will assign 8 CPUs to each GPU:

./LBC -c 32 -gpu -gopt dev=1-4

Or you have 32CPUs and 8 GPUs and are on Amazon:

./LBC -c 32 -gpu -gopt dev=1-8:lws=512

Assume you would like to distribute the work of your 16 CPUs only to GPUs 1,3,5,7

./LBC -c 16 -gpu -gopt dev=1,3,5,7


So the old -gdev X parameter is gone and replaced by the more generic (and more complex) gopt parameter.
If you have just one GPU, you do not need to care about all this. (-gopt dev=1 is default)

BTW: dev=1-4 isthe same as dev=1,2,3,4 or dev=1,2,3-4 etc. just shorter. dev=1-2 and dev=1,2 are also equivalent


(*) there may be one exception, if you have old GPUs and get a "CL_OUT_OF_RESOURCES" error. In this case, you could try -gopt with lws=X where X is 512 or 256 or 128 or 64

and still: 30.958 seconds on 1 CPU core for 2 x 10 x 2²⁴ keys.

(10.8 Mkeys/s per core) GPU load about 40% higher than before. That's nearly a doubling of the speed!  

The hashes 0c96c911f51bee4250b3d2a2b86b8853fb8c5830 and 82bf3725df95cd4260b003d21063a1b85a66ab21 from the test below (are the symmetric siblings of what we compute now) are from​http://www.directory.io/904625697166532776746648320380374280100293470930272690489102837043110636675

where I use 1CvKupTzRqsDi5Zf4QdbVYhmaQUkF667hM (82bf3725df95cd4260b003d21063a1b85a66ab21) and 129Zk4KrdjCtTkPDKDA9yKEoyQMKg7nnY4 (0c96c911f51bee4250b3d2a2b86b8853fb8c5830) for testing.

Privkey shown is still wrong, should be e.g.

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140-0x35
instead of
0000000000000000000000000000000000000000000000000000000000000001+0x35

but that's cosmetics.


So why is it brittle, unoptimized and still shitty?

brittle because I had a bug in the symmetry code that did not find uncompressed keys. Fixed.  

The symmetry computation is still done @ CPU and while it's no big deal (256bit subtraction), we want to get load from CPU to GPU - right?
So I'll do that before I release it. Also, there are still lots of optimizations missing, so I am quite confident to be able to achieve a per-core rate more like 5.8 Mkeys/s * 2 (~11.6 Mkeys/s per core) -> 23.2 Maddrs/s per core with around 25% GPU load per CPU core on my machine.

So watch out, next release will give you GPU users a nice speed bump.

edit: 11.9 Mkeys/s per core now (shittyness levels bearable - symmetry computation on GPU already) ... time to make a release.