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
Topic: Large Bitcoin Collider Thread 2.0 - page 18. (Read 57143 times)
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
There are many examples:
https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money
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
2256 bits, but a mere 2160, 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 2159 private keys in the 1st place.
"Bah! 1bit", I hear you say. Yep - 1bit. This 1bit means halving of
the search space. So 2159/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 2224 difficulty at the miners, or up to
2160 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 264 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.
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
Quote
Supposing you could generate a billion (230) 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
2256 bits, but a mere 2160, 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 2159 private keys in the 1st place.
"Bah! 1bit", I hear you say. Yep - 1bit. This 1bit means halving of
the search space. So 2159/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 2224 difficulty at the miners, or up to
2160 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 264 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.
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.
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.
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.
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.
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.
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.
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.
Can't run 2nd GPU.
PC specs
i7-6950X
2x GTX 1080 Ti
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]
PC specs
i7-6950X
2x GTX 1080 Ti
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
Thanks for your effort, going to give it a try now!
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.
Code:
GPU authorized: yes
New client '1.165-LBC.bz2' found.
Some files were updated - please restart LBC.
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.
Claiming Finds:
Tomorrow it will be 6 months since our 1st find (https://lbc.cryptoguru.org/trophies) went into custody.
Quote
2016-10-11 03:00:34 GMT
The pool found a private key to f6cc30532dba44efe592733887f4f74c589c9602 (1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg) as 0x22306e3f1a72. At the time of the find, there were 0.007899 BTC on that address.The funds were transferred to custody at 16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE. See the announcement and the modalities of the return of the funds to their rightful owner here.
The pool found a private key to f6cc30532dba44efe592733887f4f74c589c9602 (1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg) as 0x22306e3f1a72. At the time of the find, there were 0.007899 BTC on that address.The funds were transferred to custody at 16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE. See the announcement and the modalities of the return of the funds to their rightful owner here.
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.
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.
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.
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.
Quote
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.
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...
Time = 7
for testing...
Code:
real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
OpenCL program written.
Will use 4 CPUs.
New generator found. (DL-size: 0.25MB)
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 3969272 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.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC
GPU authorized: yes
Will use 4 CPUs.
Ask for work... got blocks [4974781375-4974787774] (6710 Mkeys)
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
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.
There's something weird going on with your 1.067 client
edit: server put your client in blacklist, contact me for clarification.
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.
There's something weird going on with your 1.067 client
edit: server put your client in blacklist, contact me for clarification.
edit: Version 1.140 on Server which does not need this workaround. Problem was only in "LBC -x" - not in normal operation.
Hmm but ./LBC -x still gives an error here!
Starting with ./LBC seems to work...but correct way?
Code:
real-duke@C1-Ubuntu:~/gcollider$ ./LBC -u
New client '1.140-LBC.bz2' found.
Finished update run - system up to date.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
Will use 4 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 5246127 keys/s per CPU core.
Generator validity check failed.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC
GPU authorized: yes
Will use 4 CPUs.
Ask for work... got blocks [4941330847-4941353694] (23957 Mkeys)
oo
real-duke@C1-Ubuntu:~/gcollider$ ls -all
insgesamt 526140
drwxrwxr-x 2 real-duke real-duke 4096 Mai 1 21:38 .
drwxr-xr-x 28 real-duke real-duke 4096 Mai 1 21:31 ..
-rwxrwxrwx 1 real-duke real-duke 55018 Feb 19 13:41 1.021-LBC
-rwxrwxrwx 1 real-duke real-duke 55108 Mär 8 22:47 1.031-LBC
-r--r--r-- 1 real-duke real-duke 63819 Mai 1 00:20 1.067-LBC
-r--r--r-- 1 real-duke real-duke 63819 Mai 1 00:20 1.138-LBC
-rw-rw-r-- 1 real-duke real-duke 28 Mai 1 21:34 bench.pst
-rwxrwxrwx 1 real-duke real-duke 4488 Mär 9 18:16 diagnostics-OpenCL.txt
-rw-rw-r-- 1 real-duke real-duke 536870912 Apr 24 23:41 funds_h160.blf
-rwxrwxrwx 1 real-duke real-duke 395888 Apr 16 20:59 gen-hrdcore-avx2+gpu-linux64
-rwxrwxrwx 1 real-duke real-duke 1131720 Apr 16 20:31 gen-hrdcore-avx2-linux64
-rwxrwxrwx 1 real-duke real-duke 20814 Mär 26 13:45 hash160_deparsed.cl
-r-xr-xr-- 1 real-duke real-duke 63826 Mai 1 21:33 LBC
-rwxrwxrwx 1 real-duke real-duke 124 Apr 16 22:56 lbc.json
real-duke@C1-Ubuntu:~/gcollider$
LOL nice rumours about my hardware 
C1 is my Intel Standalone PC and C2 is my little AMD Notebook...both are no ARM Systems as far as I know
"C" means nothing more than "Computer" in this case.
C1 is my Intel Standalone PC and C2 is my little AMD Notebook...both are no ARM Systems as far as I know
"C" means nothing more than "Computer" in this case.
Rico, he's running it on a machine named "Ubuntu-C2", which suggests of it being an ODROID-C2. That's an ARM single board computer and LBC is not going to run on it.
I see "C1-Ubuntu", which I would now intuitively translate to "Collider1-Ubuntu".
Given the fact that he is running a GTX1060, I seriously doubt he has an ARM board below that.
Given another fact, that the LBC client has recognized AVX2, I would be very interested to see an ARM with avx2 features.
As mentioned, the problem was that "LBC -x" did not start the generator explicitely with the "./" current path prefix. It's fixed in 1.140
Jump to: