Why do you move funds from the address to itself? What is the reason?

https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS

VERY GOOOD!!!  

I read that pages, but I don't understand what kind of "proof of work" we are talking about.

I mean: I'm interested in a "proof of correct work". This kind of proof needs not only to you, but to everyone is running this client.
My incentive is: I'm sure that I (and we all) are working in the correct way.

My question is: do you check in some way that my work is correct or you check only that I run your code without tampering? It is different.

For example incentive firework from SlarkBoy is good as a control system too. And money is not even necessary to perform this kind of control.


We are searching for something extremely rare. So sentences like:

"I do trust the LBC codebase"
"anyone with attention deficit hyperactivity disorder would be in the wrong place here"

are not soothing to me 

Probably I'm only frustrated, I would really be sorry if we don't hit #51 

Do we know for sure that there is a key for each bit?

I think we need to have another control (and incentive) system for our work. We cannot run for weeks and get at this point with the doubt that we have lost (in some way) a key.

EDIT: for example, how do you know (and I know) that I made effectively a search between keys "a and b"?  What is the proof of my work?

I think that if oclvanitygen computes 270 Maddress/s, that means that it computes only 135M of x-coordinates (x = coordinates of points of the curve that represent the public keys) and not even a single y-coordinate.
Then the strings: "02x" and "03x" produce 2 addresses ( 2 for each x):

"02x" --> compressed public key
"03x" --> compressed public key


Current LBC generator computes 100 Mkey/s, that means that it computes 100M of x-coordinates + 100M of y-coordinates, then

"04xy" --> uncompressed public key
"02 or 03x" --> compressed public key

Total: 200 Maddresses/s.

Potentially our generator could computes other 2 addresses (not in the same time) from the same x/y, because there are other 2 points related to the same x,y coordinates:

"04x(-y)"  --> uncompressed public key
"03x / 02x" --> compressed public key

Note: sha256 should take half time if only applied to strings like "02x" or "03x" (only 256bit) respect of "04xy" (more than 512 bit).
That's why oclvanitygen seems faster than LBC.

Essentially the cost of compute an uncompressed public key is higher than that related to compressed key (because of y and because of sha256)

Could you share with us some informations about how do you got this speed?  Is it expensive?

This pool could reach a very high speed if it were more people able to use a lot of CPU like you do.   

Something like that?

https://www.leadergpu.com/

How? GPU-client on dedicated servers?

I'm the only one stuck to 12Mkeys/s? 

What do you suggest as alternative?

I'm using t = 20

I'm using aws instances to run LBC client (version CPU only).

I chose 2 instances-type  (https://aws.amazon.com/ec2/instance-types/):

1) m4.4xlarge  (16vCPU)   about 0,13$ per hour (spot instance)
2) m4.16xlarge (64vCPU)   about 0,55$ per hour (spot instance)

generator:  gen-hrdcore-avx2-linux64

1)

2)

The problem is the speed:

1) about 6,3Mkeys/s                2) about 12Mkeys/s

obviously I have 2 different config files "lbc.json" , 1) --> "cpus":   16,   2)  --> "cpus":   64.

Why is instance #2  so slow?

April fool's prank?

Cpu + GMP library: on your pc you could get 16,7M / 4s or 16,7/ 2s with complement or 16M / 1s with endomorphism.
My function "double_add" now takes 6s on my cpu (on your pc I guess it takes less than 3s), then 4s is a reasonable estimate. If the goal is 15Mkeys/s, CPU + GMP library are enough, otherwise you have to implement an efficient representation of field's elements (like secp256k1 library does) and/or use GPU.

About GPU and multiprecision library:
https://pdfs.semanticscholar.org/d807/b453c7f10bc547971a9344e81a88af934ad0.pdf

I was thinking, if sha256/ripemd160 is too fast compared to CPU pk generation, you could search for P2SH "addresses" too.

For example, with only 3 pubkeys, you could generate about 20 addresses (probably more):

6

+6

+3

I am performing some tests about endomorphism.

I remind the idea, we would like to generate:

a) 1G,  2G,  3G,  ......., kG, .......... , 2^160G
b) 1G',  2G', 3G', ......., kG', .........., 2^160G'    where G'=lambdaG
c) 1G'', 2G'', 3G'', ......., kG'',.........., 2^160G''   where G''=lambda^2G

We are sure that each row has different elements, because G, G', G'' have period n. But of course we cannot be sure that each element of b) for example is not an element of a) too. If we generated n keys instead of just 2^160, we would get the entire group of all n points, and then all the 3 rows would have the same elements. Only the order would be different.

But we have to generate only "few" elements.
Let's look at the rows a) and b) and at the relation between 2 corresponding elements: kG' = k*(lambdaG) = lambda*(kG). Where are these elements of b)?

My guess is:
multiplication by lambda produces 2^160 elements of b) evenly distributed in the space of the keys (keys respect of the generator G).

If that were true, how often would we have a "collision" (double computation of the same key in 2 distinct rows) between the 2 rows?
If the keys of the b) row are actually evenly distributed, the probability for each new key of b) to fall in the range 1-2^160 should be 2^160/2^256, about 1/2^96. If we generated 2^160 elements, we'd have 2^64 collisions.

To deal with this hypothesis, I generated 2^30 keys of the row b) (lambda1, lambda2, lambda3, ..., lambda2^30); none of these were in the range (1,2^160), so I checked how many were in larger ranges (like for example (1,2^238), and in that case I got about 2^12 'collisions' (2^238/2^256 * 2^30 = 2^12). So my hypothesis seems to have been confirmed by these results.

In summary, since we have to generate only 2^160 keys, we can accept (but obviously it's up to you) to have a double computation for one key each 2^96, only 16 'collisions' in the first 2^100 keys.

A question remains: do you want to generate random keys outside from your initial range? In case of collision, how can somebody prove to you that it is his key, since that key is indistinguishable from the others?

If you want instead to let go of endomorphism, I remind you that your generation's speed will be halved (from 1,1 M to 2,1 M for each point).

6,2 s: CPU generates 16.7 M of public keys (x,y)
1,8 s: GPU performs SHA256 / ripemd160 of (x,y) and (x) <-compressed, what do you mean "compressed key is done with GPU"? Do you use 1 or 2 compressed keys? The x is always the same, you don't need to compute the y so you can generate 2 compressed keys for each uncompressed. Do you generate 33M of addresses each 8s or 50M of addresses?

Anyway at the moment the cpu is the bottleneck, gpu does his work at least x3 faster than cpu...

Hi,


CPU only for public keys generation + GPU for sha256/ripemd160? Why in the meantime the pool performance has fell down?


I have a new version of the ecc_for_collider:

1) + complement private keys

2) + comments

https://www.dropbox.com/s/3jsxjy7sntx3p4a/ecc_for_collider07.zip?dl=0

The file foo.py performs 16,4 M of useless products; just to appreciate the efficiency of the generation of public keys of the script gen_batches_points07.py:

main_batch --> (x,y)   3,5M + 1S for each point

batch2 --> (betax,y)     1M for each point

batch3 --> (beta^2*x,y) 1M for each point

batch_minus --> (x,-y)  (betax,-y) (beta^2*x,-y)  0M and 0S

Total:  about 1,1M for each point!
If you know the performance of the field multiplication in your C code, you can have an idea of the performance you could reach. How long it takes your C code to perform 16,4 M multiplications (operands: big numbers and multiplication mod p)?

In the next days I want to perform some tests about endomorphism, just to be sure that everything is ok (for example  we'd like to avoid  twice computation of the same key)

Imagine you want to generate a batch from 10000 to 14096 (the script actually generates batches of 4097 points)

First you generate the key k = 12048 (always we start with the middle point, to exploit the symmetry), this is the only point (a pivot point) of the batch that we get with the slower function mult


k can be any number greater than 2048 (otherwise, if k=3 for example, kG+3G gives a error because you are trying to use the addition formula instead of the double...) The first batch you can create with this script goes from 1 to 4097, the start key in that case would be k=2049.

Then the script generates three batches, each batch has 1 point + 2048 couple of points:

first batch: this is the batch you are more interested of, because it has 4097 points in your range, including the point 12048G:

(12048),(12048+1,12048-1),(12048+2,12048-2),....,(12048+2048=14096,12048-2048=10000)

the script computes this batch with the function double_add_P_Q_inv

Element #0 of the list is always kG, element #1 is the couple kG+1G, kG-1G, #2 is the couple kG+2G, kG-2G,  and so on ... --> #2048 is the couple kG+2048,kG-2048G


Batch 1 and 2: these keys are not in your range, here we use endomorphism:

batch1:
(12048*lambda), ((12048+1)*lambda,(12048-1)*lambda), ((12048+2)*lambda,(12048-2)*lambda),  ...., (10000*lambda,14096*lambda)

batch2:
(12048*lambda^2),   ((12048+1)*lambda^2, (12048-1)*lambda^2),   ((12048+2)*lambda^2, (12048-2)*lambda^2),  ....,  (14096*lambda^2, 10000*lambda^2)

EDIT:
You don't worry about each key, in my opinion you have to store only a private key for 3 batches, you can think at the single key in the middle of the batch like a special seed. 99,9999% of the batches doesn't match any address with bitcoin, so when a match occurs only then you have to regenerate the entire 3 batches from this single seed to fetch the correct private key. Batch 1 and 2 are sequence of keys each different from each other, so you are sure that you are not wasting your computational efforts. I'm almost sure about the last sentence, there can't be more than three points with the same y, it is not possible checking the same key twice. Note that the 3 batches are related, they must be computed together.

Imagine you know that the pool has searched so far from key 1 to 2^50, then you know that the pool has searched keys 1*lambda, 2*lambda, 3*lambda ...  to 2^50*lambda (mod n) too, and keys 1*lambda^2, 2*lambda^2, 3*lambda^2,... to 2^50*lambda^2 (mod n).



I dare: if you use complement too, you can generate 16M keys in less than half a second (with cpu, I don't know for GPU)


My code uses 3,5M + 1S for each point of the first batch, and only 1M for each point of the other 2 batches.
So the average is: 5,5/3= 1,83M + 0,33S for point, let's say about 2,1M for point.


Now your speed is 16M/6s = 2,7 M/s for each cpu core.

If you could achieve a 8x - 10x improvement, let's say a 8x, so you could perform at least 21M/s. If you use (X,Y) --> (X,-Y) too, 42M/s. Let's say at least 40M k/s for each core, 15x respect of your actual speed.
With a 8-core cpu, you could generate more keys than your entire pool can handle at this moment.


Maybe tomorrow I'll add more comments on the code. Anyway read again this post, I edited it.

EDIT2:

this is a version with more comments:

https://www.dropbox.com/s/6o2az7n6x0luld4/ecc_for_collider06.zip?dl=0

Ok, I don't know how to use the lists on Python  

This version is faster (at least 50%) with only few modifications:

https://www.dropbox.com/s/wrbolxzbiu3y9su/ecc_for_collider04.zip?dl=0


Another update of the library with endomorphism:

https://www.dropbox.com/s/7v5i36n4k6d849b/ecc_for_collider05.zip?dl=0