Bitcoin Forum
November 19, 2017, 03:45:31 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 »  All
  Print  
Author Topic: Large Bitcoin Collider Thread 2.0  (Read 21906 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 23, 2017, 08:15:05 AM
 #161

Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix.

LBC uses https://metacpan.org/pod/LWP::Protocol::https for HTTPS validation.

Worksforme.

So maybe

$ sudo cpan

cpan> install LWP::Protocol::https

Other than that: ¯\_(ツ)_/¯

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
1511063131
Hero Member
*
Offline Offline

Posts: 1511063131

View Profile Personal Message (Offline)

Ignore
1511063131
Reply with quote  #2

1511063131
Report to moderator
1511063131
Hero Member
*
Offline Offline

Posts: 1511063131

View Profile Personal Message (Offline)

Ignore
1511063131
Reply with quote  #2

1511063131
Report to moderator
1511063131
Hero Member
*
Offline Offline

Posts: 1511063131

View Profile Personal Message (Offline)

Ignore
1511063131
Reply with quote  #2

1511063131
Report to moderator
A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511063131
Hero Member
*
Offline Offline

Posts: 1511063131

View Profile Personal Message (Offline)

Ignore
1511063131
Reply with quote  #2

1511063131
Report to moderator
CrytpSig
Newbie
*
Offline Offline

Activity: 5


View Profile
October 23, 2017, 08:28:02 AM
 #162

Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix.

LBC uses https://metacpan.org/pod/LWP::Protocol::https for HTTPS validation.

Worksforme.

So maybe

$ sudo cpan

cpan> install LWP::Protocol::https

Other than that: ¯\_(ツ)_/¯


Still no luck anyway I can bypass https?

https://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates#5329129
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
October 26, 2017, 10:36:47 PM
 #163

All comands:

sudo apt-get update               
sudo apt-get upgrade               
sudo apt-get update && sudo apt-get -y upgrade               
sudo apt-get install -y linux-image-extra-`uname -r`               
sudo apt install perl bzip2 xdelta3 libgmp-dev libssl-dev gcc make               
sudo apt-get install gcc make tmux libssl-dev xdelta3 nvidia-367 nvidia-cuda-toolkit               
sudo cpan install OpenCL               
sudo cpan force install JSON               
sudo cpan force install LWP               
sudo cpan force install Parallel::ForkManager               
sudo cpan force install Net::SSLeay               
sudo cpan force install LWP::Protocol::https               
sudo cpan force install Parallel::ForkManager                
sudo cpan force install Term::ReadKey               
sudo apt-get install libnet-ssleay-perl               
sudo apt-get install libcrypt-ssleay-perl               
sudo apt-get install LWP::Protocol::https               
sudo apt-get install Parallel::ForkManager                
sudo apt-get install Term::ReadKey               
sudo apt install ocl-icd-opencl-dev               
sudo apt-get install nvidia-375               
sudo apt-get dist-upgrade -y               
sudo reboot               
sudo ./LBC -h               
sudo ./LBC -x               

www.kknd.com.br & www.forumbmwbrasil.com.br
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 28, 2017, 05:06:38 PM
 #164

sudo ./LBC -x               

RUNNING LBC AS ROOT IS NOT REQUIRED OR A GOOD PRACTICE

The LBC app contains a remote code execution vulnerability. Rico assures us that he as taken many steps to avoid a malicious attacker from leveraging the vulnerability. But since root privilege is not required, there is no reason to run LBC as root.

For extra protection, you might consider running LBC inside a Docker container. I provide a base image (dcw312/lbc-base:latest) as well as code to create it and use it at:
https://github.com/dcw312/lbc-client-docker

p.s. Thanks for providing the nvidia libraries. My Docker image does not use that and some extra Docker foo is required to leverage the GPU.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 28, 2017, 07:28:54 PM
 #165

RUNNING LBC AS ROOT IS NOT REQUIRED OR A GOOD PRACTICE

The LBC app contains a remote code execution vulnerability.

It seems impossible for people to remember things that have been said once, so I repeat it again. Hopefully it will last for a couple of months:

a) Running LBC as root is not required, but if you run LBC in a VM, or Docker container, or on a dedicated machine, it's as good as any other command running as root. I do it all the time.

b) The LBC is not an App - go to your sweepy wheepy Android/iOS device for that.

c) The Remote Code Execution is there by design and not a vulnerability.

Same as you do not consider the JavaScript remote code execution in your faggy browser a vulnerability. Or do you?

Quote
p.s. Thanks for providing the nvidia libraries. My Docker image does not use that and some extra Docker foo is required to leverage the GPU.

I have some reports of people successfully doing a PCI passthrough to VMware and KVM virtual machines, so that's definitely an option for a GPU enabled client.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 29, 2017, 05:19:02 PM
 #166

The Remote Code Execution is there by design and not a vulnerability.
My apologies for implying that the RCE was a bug. I was using the word "vulnerability" to refer to the "state of being exposed to the possibility of being attacked" without judgement of it being a "bug" or a "feature". Your analogy to Javascript is a good one. Browsers provide an execution sandbox so to manage the risks of RCE. Users of LBC should, as you say, take appropriate steps to provide an appropriate sandbox.

To avoid repeating yourself further, you might consider having the client print a message on startup, like: "The LBC client contains a feature update itself. In the unlikely event that the LBC server were compromised by an attacker, the attacker would be able to execute arbitrary code on your machine as the user that executes LBC. Please execute LBC accordingly."  This is just a well intended suggestion.

Apologies again for any insult.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 30, 2017, 07:28:19 AM
 #167

Greetings Colliders!

A few hours ago, the LBC computed it's 16000 trillionth address (8000 trillion keys, each key compressed & uncompressed pubkey -> 2 addresses per key). At the current rate of 25-30 tn keys per day, this means 36 days for 1000 tn keys on average. In other words, the LBC checked the equivalent of over 62500 billion pages on http://www.directory.io/ and at the moment is doing so at a rate of 2.5 million of these pages per second.



I have thought a long time how and when to distribute the funds that ended up in the LBC Pot (currently 0.12274528 BTC) and here's how the LBC Pot will be distributed among the participating colliders:

Every time the LBC reaches a bit boundary in the search space (53 bits, 54 bits, ...) the current LBC pot will be distributed proportionally according to the Gkeys delivered among those who were active in the week before the LBC hits this boundary. This means, if you look at your Per-User statistics (e.g. https://lbc.cryptoguru.org/stats/__rico666__) at the time the LBC crosses this boundary, there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far. On the other hand, the speed in there (as long as it is above 0 Mkeys/s) does not have any influence on the payout - only your Gkeys delivered so far do.



There are a lot of dead/dormant accounts, who seem to just have tested LBC and then stopped colliding. And this is perfectly ok.
On the other hand, I don't think it makes sense to keep these accounts around indefinitely as most of them have some single-digit Gkeys, but everyone started out small, so an automated cleanup mechanism should not immediately reap small accounts.

This is what will happen:

Starting with 53bit search space (which is due in about a month given current speed), accounts that have been inactive for (7 + Gkeys_delivered) days will be reaped and their Gkeys will be added proportionally  to the other active accounts. Consider it a kind of Proof of Stake.  Wink

e.g.

Account has delivered 5 Gkeys and is inactive. This account can be inactive for 12 days before it is reaped.
Account has delivered 1000 Gkeys and is inactive. This account can be inactive for 1007 days before it is reaped.

It's clear that accounts that did some serious colliding in the past with several thousand Gkeys do not have to fear to be reaped anytime soon.
But I should point out that as speed of colliding rates changes over time, we may change this rule at some point in the future. (Imagine if the hardware/software in 5 years can give you 1Gkey/s then probably 1 Gkey will buy you 1 hour idle time. Or something like that)

For now, 7 days idle time is ok for everyone, above that: 1Gkey = 1 day.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Offline Offline

Activity: 759


View Profile
October 30, 2017, 03:10:43 PM
 #168

Just my opinion:

when you delete an account, why its Gkeys are added to the other active accounts? Personally I like to know exactly how many keys I have delivered. I don't need the Gkeys from other accounts. I prefer to see an accurate record.

You could gather all the Gkeys from the account deleted in a single generic account "other" that doesn't appear  in the top 30.


A few hours ago, the LBC computed it's 16000 trillionth address (8000 trillion keys, each key compressed & uncompressed pubkey -> 2 addresses per key).

Then the Unknownhostname's share has fallen below 50% of the total amount.
Hereticalsauce
Newbie
*
Offline Offline

Activity: 4


View Profile
October 30, 2017, 11:21:11 PM
 #169

arulbero,
I think this is rico's way to incentivize M/hash to the pool, and reward those who stick with him in his experiment.
Perhaps the re-distributed Gkeys can be assigned to a dead-pool IP of 0.0.0.0 to keep them separate from your work.


I found Google's cloud computing to be quite nice, they are offering a $300 trial of their services, at least for me.
Without asking for more vCPUs, a 24 core  skylake preemptible VM per region will cost $0.20/hour and net ~10 Mkey/s.  
A 96 core will cost $0.84/hr.  
There are GPU options as well, up to eight K80s or four P100.  An eight core Broadwell with four P100s will cost $9.399/hr or $5.799/hr on eight K80s.

Id like to try these once my GPU is authed.
gizmoh
Legendary
*
Offline Offline

Activity: 1302



View Profile
October 31, 2017, 05:29:37 AM
 #170

Quote
there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far

IMO a 2h timeframe is too short.  Probability of power outage/ network downtime lasting over 2hr is quite high.

A number between 6hr to 12hr average point would be more reasonable.

How Ripple Rips you: "The founders of Ripple Labs created 100 billion XRP at Ripple's inception. No more can be created according to the rules of the Ripple protocol. Of the 100 billion created, 20 billion XRP were retained by the creators, seeders, venture capital companies and other founders. The remaining 80 billion were given to Ripple Labs. Ripple Labs intends to distribute and sell 55 of that 80 billion XRP to users and strategic partners. Ripple Labs also had a giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid that was later discontinued.[29] Ripple Labs will retain the remaining 25 billion"
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 31, 2017, 06:28:11 AM
 #171

IMO a 2h timeframe is too short.  Probability of power outage/ network downtime lasting over 2hr is quite high.

A number between 6hr to 12hr average point would be more reasonable.

2h is fine. You can have multiple colliders, even geographically distributed, working for the same id.
Also, I need to be efficient about any functional changes I make to the LBC because of time constraints
taking the individual stats as validation dataset is such an efficiency.

And therefore as announced. It may be a problem if your collider infrastructure is not reliable:
https://lbc.cryptoguru.org/stats/Unknownhostname
But that is - intentionally - your problem you either solve or not.



@arulbero

I may re-think the assignment of forfeited Gkeys. Either assign them to some "Dummy account", or into a separate value of the clients, because I agree that the information what were your Gkeys and what were foreign Gkeys should not be dilluted.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 31, 2017, 04:36:23 PM
 #172

Id like to try these once my GPU is authed.

5b8f5562ac3873408d26852d74434040 is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
6fdafb1d737ef98bcbdceaaff16b2a9c is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
Hereticalsauce is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
QWERTYUIOP555 is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
YorikBlin is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
___vh___ is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
cyberguard is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
ddosddos is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.
ffchampmt is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Hereticalsauce
Newbie
*
Offline Offline

Activity: 4


View Profile
November 01, 2017, 05:21:21 AM
 #173

Hereticalsauce is over 3000 Gkeys and has no gpuauth.
GPUAuth set now.

Thank you, sir.
So, Google wants $140 before they auth me GPU use.  Roll Eyes  
Might just as well buy a video card and run this locally; time to dust off the ol' 5970.
arulbero
Hero Member
*****
Offline Offline

Activity: 759


View Profile
November 01, 2017, 10:10:03 AM
 #174

I want to make some comments on how LBC works.  I take inspiration from this Wuille's comment: https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844

The aim of the following considerations is to help bitcointalkforum's users to understand better what (and why) LBC is doing.

For this reason,  I will make some simplifications, like 20M = 2^24 instead of 20M = 2^24.2535 and so on. In this context above all I care about the concepts.

*************************************************************************************************************************************************************************************************
THE THEORY


The theory:

    1) Preimage search: given a hash H, find X such that Hash(X) = H.

    2) Collision search: find an X and a Y, such that X != Y and Hash(X) = Hash(Y).

These 2 problems look similar, but they are actually very different. In our context, X is a public key, H = hash160(X) is a bitcoin address:

    1) Preimage search:  given a particular address H, find a public key X such that hash160(X) = H.

    2) Collision search:  find two public keys X and Y, such that X != Y and hash160(X) = hash160(Y) .

A preimage search for a 160-bit hash function needs 2^160 steps. A collision search however only needs 2^80 steps.

Example of a preimage search:

  You choose a particular address H.
  Then you generate:

  2^160 public keys Xi and store the corresponding addresses Hi = hash160(Xi)
  in a list L= {H1, H2, H3, .....H2^160}

 If they are all different, you will get surely a match between an Hi and the H you chose (Hi = H). So we say that there are needed 2^160 steps to find an Xi (a pre-image) of H=Hi.

Note: Xi is only one preimage, since we don't know how H was generated, we can't say we have found a collision (we don't have two different public keys but only one that produces for sure H)


Example of a collision search:

Your purpose here is to find a couple ("collision" implies always at least two) of public keys X and Y that generate the same address H, any address H, you can't choose it.
 
 You generate:

  a list L1 of 2^80  random addresses Hi       =>   L1= {H1, H2, H3, .....H2^80}   where Hi = Hash160(Xi)
  and
  a list L2 of other 2^80 random addresses Aj => L2= {A1, A2, A3, .....A2^80}  where Aj = hash160(Yj)
 
  "You sort both lists. Then you go through both lists, and find a hash that exists in both in a single iteration. This is the critical point. It is likely that such a collision exists,
   because even though there are only 2^80 entries in each list, there are 2^160 combinations of entries. Each of those has a 2^(-160) chance to be a collision.
   This is also the explanation of the Birthday Paradox, and such an attack is therefore called a birthday attack.
" (Wuille)
 
  So we say that there are needed 2^80 steps to find an Xi and Yj (a collision) such that Hi=Aj.


If you noted, the difference between the first case (preimage) and the second one (collision) is that in the first case we are looking for something we chose, a particular address (in LBC we have the UTXO data set, we are assuming now for the sake of simplicity it is always the same during the research) and we get only one preimage (one public key), in the second case we find two public keys that correspond to a random address.


To sum up, we can think at these 2 problems using 2 lists:

preimage search:

L1 = {H1, H2, H3, .....H2^160} --> you have to generate randomly 2^160 addresses -> 2^160 steps

L2 = {H}  --> H is the particular prefixed address you chose


collision search:

L1 = {H1, H2, H3, .....H2^80} --> you have to generate randomly 2^80 addresses

L2=  {A1, A2, A3, ..... A2^80}  --> you have to generate randomly 2^80 addresses -> 2^80 steps (2^81 at the most)


The fact that the number of the elements of the 2 lists in the second case is the same (this number is equal - more or less - to the square root of the number of the elements in L1 in the first case) makes less expensive to perform a collision search.
This point is very important.

A metaphor to visualize the difference between a preimage search (looking for a prefixed target using randomly generated elements) and a collision (a chance "encounter" between two elements of two random sequences):

imagine you are in a room.

1) In that room there is a fixed target (a single point). If a fly moves randomly, what are the chances that it hit the target? Very low (this is a preimage, to hit a specific target using randomly generated addresses).

2) Now imagine that the target turns into another fly.
Then we have two flies that move randomly in the room. What are the chances that one hit the other one? Much more. This is a collision.

*************************************************************************************************************************************************************************************************+

*************************************************************************************************************************************************************************************************
THE CURRENT LBC APPROACH


Ok, now how is the LBC's approach in relation to these two problems?

To start, LBC performs a preimage search, where L2 contains not only 1 but 20M = (about) 2^24 addresses taken from the UTXO data set:

preimage search:

L1 = {H1, H2, H3, .....H2^160} --> we can think that it is randomly generated

L2 = {A1, A2, ......, A2^24}  --> UTXO data set, it is not randomly generated!!!

in this case you can note that there are 2^160 * 2^24 combinations of entries, then we can reduce L1 from 2^160 to 2^136 addresses:

L1 = {H1, H2, H3, .....H2^136}  --> the addresses we have to generate to get a single preimage

L2 = {A1, A2, ......, A2^24}      --> the UTXO data set, these are "data", we don't have to compute these

I repeat: we are taking care of a preimage search problem.  In LBC project we call "collision" what actually is a "preimage". Infact our difficulty is nearer to 160 bit than 80 bit. We want to find preimages (public keys) only of some particular hashes (addresses from UTXO).

Now imagine we find a preimage, i.e. we find a public key Xi such that  Hi = Aj for some Aj in L2 (remember: Hi = hash160(Xi))

Then, only if we can prove that the public key Xi is different from the public key Yj that produces Aj, we can claim to have found a real collision too (usually we don't have Yj, how to get this information is a real problem)
Only in this case we can go from a single preimage to two preimages and then get a real collision.

*************************************************************************************************************************************************************************************************

*************************************************************************************************************************************************************************************************

SOME IDEA FOR THE FUTURE

Can we improve the odds to find a preimage/collision?

My guess: we should extend the L2 list (and extend the corresponding bloom filter to not rise the false positive rate, but this is a technical issue)

Remember: if L2 becomes bigger, then L1 becomes smaller, and L1's size is the difficulty of our task (because: size_of_L1 = 2^160 / size_of_L2).
L2's elements can be collected and stored easily, those of L1 don't, L1 is too big.

To extend L2, we have these possibilities:

1)  we wait for bitcoin's net grows up naturally

2)  we generate a few random millions of addresses (but in this way we shift from a preimage search to a purely random collision search task)

3) we use addresses already generated and stored in blockchain even if they have no more bitcoin (always interesting for me; besides, if we find a preimage of one of these addresses, then we will know for sure if we have a collision too, because all the addresses with at least an output transaction have already exposed their public key)


Narrow down the list L1 is a way to speedup our search, on the other hand we need to rise the speed at which we generate the list L1. Any idea is welcome.
To speedup my ECC library I need to realize a couple of assembly functions. I don't know so much about assembly. If someone is able to help me, I will be happy.  Smiley

*************************************************************************************************************************************************************************************************
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 01, 2017, 06:42:12 PM
 #175

I like where you are going with expanding the search space because it puts the focus on proving the likelihood of collision. I think this is the interesting question.

Looking at all used addresses seems the simplest way to expand the search space because those addresses are publicly available.

Has anyone seen a calculation on how many attempts it should take to have a high chance of finding a collision? (The binomial probably) I tried calculating it but the library I used wasn’t able to handle the large numbers.
arulbero
Hero Member
*****
Offline Offline

Activity: 759


View Profile
November 02, 2017, 09:39:47 AM
 #176

Has anyone seen a calculation on how many attempts it should take to have a high chance of finding a collision? (The binomial probably) I tried calculating it but the library I used wasn’t able to handle the large numbers.

This is a very interesting question, in the next days I will add a section called "Probability & LBC".
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 02, 2017, 10:29:15 PM
 #177

From the LBC website: In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.

I was confused about this earlier but I found my point of confusion. I'll add here in the hope it saves others some time.

The public key is exposed when the sender (Alice) lists it as an input to a transaction. I thought that the public key could be compared to the previous transaction or another transaction. While there may be another transaction from Alice that identifies the full public key from her address, there is no verification that the same public key is being used for all transactions from her address. So if we find a key pair X2 that hash160(X1) == hash160(X2), the finder could transfer the money   .

Code:
Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
https://en.bitcoin.it/wiki/Transaction#Principle_example_of_a_Bitcoin_transaction_with_1_input_and_1_output_only
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 03, 2017, 03:08:08 AM
 #178

in the next days I will add a section called "Probability & LBC".

I was able to find this formula:
p(different) ~ e^(n^2 / -2 * T)
https://betterexplained.com/articles/understanding-the-birthday-paradox/

Which calculates the probability of avoiding a collision for a given search size (2^x) as:
Code:
search_range p_different
70 0.999999523163
72 0.999992370635
74 0.999877937138
76 0.998048781107
78 0.969233234476
79 0.882496902585
80 0.606530659713
81 0.135335283237
82 0.000335462627903
83 1.26641655491e-14
84 2.57220937264e-56

with the following python code
Code:
import numpy as np

def print_different(bit):
    T = np.float128(2 ** 160)
    n = np.float128(2 ** bit)
    f1 = np.power(n, 2)
    f2 = np.divide(f1, T)
    f3 = np.divide(f2, -2)
    print bit, np.exp(f3)

search = range(70, 85, 2)
print 'search_range', 'p_different'
for x in search:
    print_different(x)
arulbero
Hero Member
*****
Offline Offline

Activity: 759


View Profile
November 06, 2017, 02:39:50 PM
 #179

Every time the LBC reaches a bit boundary in the search space (53 bits, 54 bits, ...) the current LBC pot will be distributed proportionally according to the Gkeys delivered among those who were active in the week before the LBC hits this boundary. This means, if you look at your Per-User statistics (e.g. https://lbc.cryptoguru.org/stats/__rico666__) at the time the LBC crosses this boundary, there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far. On the other hand, the speed in there (as long as it is above 0 Mkeys/s) does not have any influence on the payout - only your Gkeys delivered so far do.

I feel like we are going to reach the next bit boundary of the search space. Maybe we are already in the week before the end of the 53 bits. Thanks to Unknownhostname.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
November 06, 2017, 02:50:34 PM
 #180

I feel like we are going to reach the next bit boundary of the search space. Maybe we are already in the week before the end of the 53 bits. Thanks to Unknownhostname.

It's very well possible. Last time he managed to push pool performance to 2.5 Gkeys/s with CPUs only.
This time he's back and has weapons of mass collision at his hands.

Pool has 1.2 Gkeys/s already.

The "one week before bit boundary" was exactly this. You can never know when you are "just one week before the bit boundary".

Interestingly, if Unknownhostname overdoes it, he will not be eligible for LBC Pot distribution himself.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!