Large Bitcoin Collider Thread 2.0

[rico666]

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

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

[1714873483]

1714873483

[1714873483]

1714873483

[1714873483]

1714873483

[1714873483]

1714873483

[1714873483]

1714873483

[Real-Duke]

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

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

Yep and even a little faster now like announced  

Code:

./LBC
GPU authorized: yes
Will use 4 CPUs.
New generator found. (DL-size: 0.28MB)
Benchmark info not found - benchmarking... done.
Your speed is roughly 6122220 keys/s per CPU core.

oooooooo (24.51 Mkeys/s)

Compared to ~20.51 MKeys/s before  

[SlarkBoy]

Can't run 2nd GPU.

Code:

root@......:~/LBC# ./LBC .................. --gpu --cpus 10 --time 20 --delay 600 -gdev 1
GPU authorized: yes
Ask for work... got blocks [5113159823-5113222222] (65431 Mkeys)
oooooo......ooooooooooooo

root@......:~/LBC# ./LBC .................. --gpu --cpus 10 --time 20 --delay 600 -gdev 2
GPU authorized: yes
Ask for work... got blocks [5113222223-5113284622] (65431 Mkeys)
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
^CPlease end LBC gracefully with 'e'
1 just got out of the pool with exit code: 255 and data: 
6 just got out of the pool with exit code: 255 and data: 
2 just got out of the pool with exit code: 255 and data: 
4 just got out of the pool with exit code: 255 and data: 
0 just got out of the pool with exit code: 255 and data: 
7 just got out of the pool with exit code: 255 and data: 
8 just got out of the pool with exit code: 255 and data: 
5 just got out of the pool with exit code: 255 and data: 
3 just got out of the pool with exit code: 255 and data: 
9 just got out of the pool with exit code: 255 and data: 
Sending invalidation info.
^CPlease end LBC gracefully with 'e'
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "HASH(0x4cdfe00)") at ./LBC line 4151.

ps aux
root      3134  1.3  0.0      0     0 pts/1    Z+   13:52   0:00 [kardashev-haswe] <defunct>

PC specs
i7-6950X
2x GTX 1080 Ti

[rico666]

Can't run 2nd GPU.

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.

[Hamukione]

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.

[SlarkBoy]

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.

Ok good. Now both GPU working.

[rico666]

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. 

[Hamukione]

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.

[rico666]

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

Supposing you could generate a billion (2³⁰) per second

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.

[Hamukione]

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

[SopaXT]

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?

[rico666]

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?

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.

[rico666]

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

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

[rico666]

Uh   - finally commanding AWS GPU hardware:

Code:

ubuntu@ip-172-31-42-141:~/collider$ ./LBC -x -gpu
GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly 3466192 keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
Ending test run.

As with everything Amazon: Assume just the half of what they promise. They say you have 32 vCPUs? Assume you have only 16.
Their GPU hardware says max worksize 1024? Guess what...

I'll make a new kardashev-haswell capable of running on AWS. Please don't tell Unknownhostname or we're screwed.  

edit: p2.8xlarge ~90 Mkeys/s - the sharp spike you can see in the stats from 2017-05-16 - 2017-05-23

edit2: more convenience - no separate LBC startup for multi-GPU operation

Code:

root@ip-172-31-39-222:~/collider# ./LBC -c 32 -gopt dev=1-8:lws=512
GPU authorized: yes
Ask for work... got blocks [5158380559-5158410766] (31675 Mkeys)
oooo....ooooo (85.29 Mkeys/s)

[SopaXT]

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.

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

[Hamukione]

Anyone that got some spare time that wants to fiddle with my machine?
I am a retard to Linux and cant get this thing going on my "server" with an i7 920 on.

Will run 24/7, with a quadro 4000 when I earn my GPU auth xD

[rico666]

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

[rico666]

Originally, I intended to make sure in -gopt dev=x,y,z (see above) each device is given just once.  I was enthusiastic about AWS support so I pushed the release out sooner than I had implemented that filtering.

Turns out, its a feature!  

Normally gopt dev=x,y,z distributes CPU processes evenly on the given GPU devices. But what if you had two GPUs in your system where one was faster than the other? You would not want both to get the same share of work.

Or you have two same GPUs on your system, but one is for your Desktop and you want to put a lower load on this. Normally you would have to start - again - a separate LBC process for each GPU to achieve non-symmetric workload.

Not with our feature.  

Assume GPU 1 has only 2GB VRAM and GPU 2 has 4GB VRAM. Naturally this limits the number of processes that can run on 1, but why should we constraint GPU 2 because of this? Assume you have 10 cores to fire on the GPUs and you want to have 3 on GPU1 and 7 on GPU2. Solution:

-c 10 -gopt dev=1,1,1,2,2,2,2,2,2,2

Now that's an extreme example where we basically had to enumerate all CPU processes explicitely for their GPU assignment. What if we simply have two 1080 (plenty of vram) and would like to assign 12 of our cores in a  1:2 ratio to both these GPUs? Solution:

-c 12 -gopt dev=1,2,2

Now GPU1 gets 4 processes, GPU2 gets 8 processes. 1:3 ratio? Simple:

-c 12 -gopt dev=1,2,2,2

GPU1: 3 processes, GPU2: 9 processes

So I like that feature very much and will keep it as is.


I intend to develop -gopt further. As is, it accepts dev and lws "subparameters". Each subparameter is delimited by ":". Another sub-parameter in future may be:

"bloom=0" (to keep bloom filter check on host CPU, which should allow to use GPUs with less than 512MB VRAM).
Nope. nobloom=<devs> with the possibility to declare a set of devices which shall not use on-GPU bloom filter check.

I have not yet decided about implementing other GPU features to be optional.

[rico666]

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.

Code:

$ make test
time ./kardashev -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -L 10 -g
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
0c96c911f51bee4250b3d2a2b86b8853fb8c5830:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x35
82bf3725df95cd4260b003d21063a1b85a66ab21:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x36
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
...

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.

[BitcoinUKmedia]

Such an interesting project. Could the collider be applied to alts with smaller market caps and fewer address?