Topic: Large Bitcoin Collider Thread 2.0 - page 18. (Read 57446 times)

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...

It's in the pipeline. We currently have the "problem" of not being able to put enough load on GPUs.
There are some tweaks to the generator we'll have to do 1st, but a GPU-only P2SH search for filling
idle GPU capacity is in the mental incubator already.

I have been made aware, that P2SH addresses actually are probably even more susceptible to collision
attacks than P2PKH - and very GPU friendly, with basically zero ECC requirements.

I am not sure if that is considered a collision also, but if we end up with a P2PKH hash160 from a
P2SH process and vice versa - it could be considered a collision IMHO.

So yes - it will be done eventually.

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?

That... Was an interesting read.

Only made me want to know more about this than before.

If you can make a list of hardware that could be "fun" to play with then I can scavenge and maybe find most of it to you.

I want to learn more master... xD

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.

Hehe, its good to be back Master.

I am currently fixing my friends PC, but will be done with that later tonight..

I hope your GPU version supports my Quadro.
Could be fun to see what its able to do.

Will spin the server up later.

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. 

Ok good. Now both GPU working.

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.

I'll have a look.


Meanwhile I can confirm that the new kardashev generators also run well on WSL (a.k.a. Ubuntu Bash on Windows) as long as you simply install a default OpenCL: http://packages.ubuntu.com/xenial/ocl-icd-libopencl1 (The Ubuntu on WIndows is Xenial). To be clear: It will still only allow you to run the CPU-only generator, but as the binary wants an OpenCL library to be present, the ocl-icd-libopencl1 installation satisfies that requirement.

Can't run 2nd GPU.



PC specs
i7-6950X
2x GTX 1080 Ti

Yep and even a little faster now like announced  

Compared to ~20.51 MKeys/s before  

Looks like it's working 
https://lbc.cryptoguru.org/stats/RealDuke

Thanks for your effort, going to give it a try now! 

Your client may update to version 1.165 on the next startup


and then fetch a "kardashev-xxx" generator, where xxx stands for a CPU architecture
which can be seen in ascending order of new instruction support:

'generic' < 'nehalem' < 'westmere' < 'sandybridge' < 'haswell' < 'skylake'

these correlate somewhat with specific instruction sets the compiler has optimized to. (Like AVX is supported by sandybridge, AVX2 by haswell etc.)

Don't worry if you have an AMD CPU: the right binary for your CPU should be chosen and in case it shouldn't, the 1.165 client has a new option:

    --override |?
      Override the LBC generator choice. You get a list of valid
      generators when giving '?' as argument.


So just do a --override generic if you get a "illegal instruction" error or just try the "next lower" binary.

---

As for speed, the kardashev-generators should be about 5% faster than the old HRD-core generators. While that's not spectacular, it can be 1 Mkey/s (or more) if you had 20 Mkeys/s (or more) - which is pleasant nevertheless.

So for those who do not monitor the News link in my signature, here the "more important" news.


Claiming Finds:

Tomorrow it will be 6 months since our 1st find (https://lbc.cryptoguru.org/trophies) went into custody.


As no one came along to reclaim these funds, they will be moved to the LBC Pot adding some $13 to the  currently present ~$195. *crowd cheers*

---

New generators: Kardashev

In the next few days, I will roll out our next generation of generators (sounds nice - eh?) called "Kardashev". The predecessor "HRD-core" served us well, but in order to break new ground, we needed to make extensive changes which made the resulting generator not just a newer version of HRD-core:

Unified binary

Mainly, the new generators will already have support for GPU computing, it will be on the client to evaluate "GPU-Auth" and start the generator with the appropriate options.
This will reduce the number of binaries we have to maintain/juggle (no +gpu versions anymore). You can see the generators already appearing on our update URL.

In order to have a seamless upgrade, please make sure you run at least LBC client version 1.140.  Because the new generators are all linked against libOpenCL, you have to make sure you do install OpenCL on your machine - even if you use only the CPU version or have a VM. If you were already running a GPU client, you do not need to do anything. If you are on a VM or even intend to run only CPU clients, you still have to install OpenCL. Luckily, you can install some dummy OpenCL package like https://apps.ubuntu.com/cat/applications/ocl-icd-libopencl1/ or the Mesa OpenCL or whatever (feel free to install the Nvidia, AMD ones if you intend to use that Hardware later on) - just make sure a libOpenCL.so is on your system.

HW support:

Reducing the number of binaries we have to juggle while improving the release cycle (testing & automation), allows us to extend the support for various other nice devices out there. Take for example Intel Goldmont a.k.a. Apollo Lake a.k.a. Pentium/Celeron WTF. These nifty little CPUs do have hardware support for SHA256! And some even niftier ARM CPUs do also! So yeah - we intend to support that. Your little settop box may actually perform a formidable search for BTC keys while you are watching a movie (of course without disturbing the movie).

Speed:

As of now, Kardashev generators are only slightly faster than HRD-core. While there is nothing spectacular as of now, make no mistake: We just left a local optimum, went through some performance valley and are releasing the new generators while climbing up the next performance mountain, just about the height of the last peak. Understood?
In terms of efficiency, already the current versions of HRD-core are the best key generation (and checking) software out there. With Kardashev, we intend to take the game to a whole new level. Doubling the speed seems realistic now. We do already have faster prototypes running here...

About:

Oh - and about the name. Kardashev is of course some tribute to our anglo-saxonian friends. I wouldn't mind to call the binary Kardašov, or Kardaschow or Кардашёв, but some people might have trouble with their keyboard.
As for why this name has been chosen: It was an idea sketched out by Ryan Castellucci some months (~10) ago, in reference to the nice but pathetic picture of the sun. Other than that, it should be self-explanatory why the name has been chosen. 

I have no interest in sabotaging you. Why should I? Your client is in blacklist, because there were some weird things going on. I would like to find out what. Blacklist doesn't necessarily mean you would have to start all over. But I would like to discuss what went on in private 1st - for analysis. I have never seen a client behave like that before, so naturally I'd like to find out what happened.

PLEASE -> [email protected]

It may very well be that it's all my fault and the program just misbehaved because of some unforeseen hardware error or whatever. I just don't know yet.


Ah! Please let's discuss this via mail, I'll put in a summary here for the interested - of course.

edit: So with the little information you provided (and no further discussion), I solved this on my own...

After your client got the interval 4942213231-4942216430 to work on - and while it ran - you started a system update, probably including update of the drivers for the GPU, system libraries and what not. This is a plausible explanation for what I saw on my end: This made the client go haywire and it answered to validation challenges with a bunch of errors (namely tampered BLF file, execution time, etc.)

I removed the last two intervals your client worked on from your delivered valid Gkeys (6400 Mkeys = 6.4Gkeys) and janitored (= recomputed) them with my client. I will move your Id from blacklist now, but please

and that is @ALL:

Do not perform extensive system upgrades while the client is running. I mean if you exchange the GPU-driver while the GPU is computing - what do you expect to happen?

All sorted out, tonight Im back ON 

Time = 7
for testing...

Yeah, I noticed I was blacklisted, but was heading out the door on the way to work and didn't have a forum account or time to start playing fiddlesticks trying to figure out why, also I was hoping it would just fix itself by the time I got home.
So what happened? I was a mere few hundred G/Keys from top 30 and then bam rico shells into my computer and sabotages me so that I have to start all over! I knew it! lol.
But in all fairness it could have possibly also been several other factors. I have it running in the background on an arch antergos box. At the time I was doing an update that affected like 300+ items, while also finding random new programs, and while the LBC was running in the background. So maybe  a dependency was updated while it was running, I think some nvdia things got changed, maybe those? idk.

or mail: [email protected]

There's something weird going on with your 1.067 client
edit: server put your client in blacklist, contact me for clarification.