Pages:
Author

Topic: Large Bitcoin Collider (Collision Finders Pool) - page 40. (Read 193404 times)

hero member
Activity: 589
Merit: 507
I don't buy nor sell anything here and never will.
Hi,

I read a bit about this project at lbc.cryptoguru.org and (addressing anybody and everybody who is doing this) I have a few questions:

1. The "About" section claims that the reason "why" is because somebody said it wasn't possible. That certainly makes sense but once the first "collision" was found the point was proven and there is nothing to prove anymore so why keep going?

2. If a "collision" is found the amount (if any) is "misplaced" (i.e. stolen) into so-called custodial address. The reason for that is because when the discovery is announced somebody else could quickly find the same and steal it. And the reason why the discovery is announced in the first place is.. to prove the point that has already been proven? Again, why this whole thing still keeps going? To prove the point was a valid and perfectly understandable reason. What valid reason is there now?

3. The webpages are full of "rightful owner" this, "rightful ownership" that, but how is this rightful owner supposed to find out about what really happened, i.e. that they in fact weren't robbed, they were just "robbed"? Assuming that every owner of bitcoins in the whole world will somehow magically become aware of some random thread at some random Internet forum and from now on will be anxiously reading it every day for the rest of their lives is just insane. From their point of view their bitcoins were stolen, end of story.
Now this is somewhat an uncharted territory but the same way as manufacturing, sale etc. of some weapons is illegal, and also developing and distributing of software to circumvent copy protection schemes (cracks) is in some jurisdictions illegal, it's not unreasonable to imagine that this software might be deemed illegal in some jurisdictions as well and everybody participating (abetting) might face criminal prosecution. So yet again, since the original goal was already reached is it really worth it to keep going and risk all the possible repercussions?

4. So far only empty or almost empty addresses have been found but what will happen when some reasonable amount (hundreds or thousands BTC) is found? Will the "announcing" and "misplacing" happen again? If somebody has such an amount in one address they are either stupid or they have many similarly loaded addresses. If the latter is the case then aren't you afraid what may happen to you and your dear ones if you piss off the wrong people? I don't see it entirely unrealistic if some angry criminals tracked you down and murdered you and your whole family, and they will most certainly not care one single bit about your "proving the point", "custodial address" etc. bullshit. Internet is not as anonymous as you might think. Is it really worth it to keep doing something that doesn't have any upside, only many downsides?
Maybe you don't value your own life but do you really have the right to put other innocent human beings in grave danger? Maybe you don't have any family, maybe you don't have any friends, but those murderers won't really investigate your personal life, they will just murder you and whoever will be near you at the moment. To make an example of you, to discourage others. Sure the probability of this happening is very low but so is the probability of being shot by a stray bullet, dying in a car/train/airplane fatal accident etc. etc., and yet all those things happen to people on daily basis.

5. When you get a hit do you also test derived addresses, i.e. assuming what you just found might be the top of a HD tree? Since the hit frequency seems to be quite low the slowdown would be negligible.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
So:

1)

164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N funds are on their way to custody at 1CTota4HeLLEgg5x5jv5xxp3Rw2SqTdKiW
see - https://blockchain.info/tx/2f00dc3f462f406ec8e96f402dbc0c342f36b69425c28e6ab0472fe0b62119a6

2)

There is a new BLF file (170201) on the FTP server, upon restart, your LBC clients should patch your blf files.

3)

Pool at 70+ Mkeys/s  (edit: 64Mkeys/s = 500 000 pages on directory.io per second, we are now at 74 Mkeys/s)

4)

Oh yes - and the private key to 164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N is 0xe09c93a2ec81


Rico
legendary
Activity: 2296
Merit: 1057
What to do with https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N?

1. Shall we leave it as is and everyone believes the pool has found the private key?
2. Shall we do the usual transfer to custody and publish the private key?
3. Shall we leave it there and just publish the private key?

Voting for 2
full member
Activity: 177
Merit: 101
What to do with https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N?

1. Shall we leave it as is and everyone believes the pool has found the private key?
2. Shall we do the usual transfer to custody and publish the private key?
3. Shall we leave it there and just publish the private key?

Personally I vote for 2. In the hope the rightful owner notices this and comes back to us - hopefully with a different private key.
1. won't give us a chance to get any alternate key. 3. could and I'd personally compensate the rightful owner in case the funds were transferred by someone else (which 100% they would - so might as well go with 2.)



Rico


Voting for 2 also.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
What to do with https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N?

1. Shall we leave it as is and everyone believes the pool has found the private key?
2. Shall we do the usual transfer to custody and publish the private key?
3. Shall we leave it there and just publish the private key?

Personally I vote for 2. In the hope the rightful owner notices this and comes back to us - hopefully with a different private key.
1. won't give us a chance to get any alternate key. 3. could and I'd personally compensate the rightful owner in case the funds were transferred by someone else (which 100% they would - so might as well go with 2.)



Rico
legendary
Activity: 1638
Merit: 1001
Hurry up! You must find something before bitcoin breaks $10000!

I think what this poster is trying to say is:

"you should not be doing this so transparently.  It would be better if you did this privately and clandestinely so that no one knew about this kind of activity"

"the fact that collisions are computationally possible makes it a moral or ethical choice whether to investigate them or refrain from investigating them.  My moral or ethical choices are different from yours, and superior to yours, and I am superior to you"

"a search of my post history will reveal what interesting or impactful bitcoin projects I have worked on.  Please perform this search to evaluate what functional value I bring to the bitcoin technical space"

legendary
Activity: 1120
Merit: 1037
฿ → ∞
Try  v//u instead of v/u, we have different versions of python.

Yep - // did the job. The output is the same. I try to cast this into C and integrate it in the code so far.

Rico
legendary
Activity: 1932
Merit: 2077
This is my output:

Code:
antonio@ubuntu:~/src/python$ ./gen_couple_points.py 
kG
0xbfcdf2
0xa884186c5d47633c9b58ae542b8b6797230c8e67808ade960793d4bc0e546cd3L
0xd74beb0250afe97f2d1ab66a02e689447b87a2df62383f4717b9452607a9b4ffL
*******
mG
0x1d1
0x87be732373bd4b738627fb63bd4d50bfd6f2bb81f804b52829549fe93fe1ac2eL
0xf6a9186ff147b9b5ffc844b2ec0e255a1ae5537d75624288ce8421f87e94e1a4L
*******
kG+mG
0xbfcfc3
0xc6292537e08b2fcad6e378b1673c446f279bed612ba928ad63d05cf6bbb8165L
0x3a744f5375e3207a53345975fc610cea7fb47dd738307e26d86e5d6bb775197dL
*******
kG-mG
0xbfcc21
0x893c80077fa3d8fcdc1fd6db146a389fec56e312bba27c3f7b3380c636a85e60L
0x6e8da51c1c82ffdbc0073bfcc00463cc50ec9dbf237efbb275503cf64886b5afL
*******

Try  v//u instead of v/u, we have different versions of python.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
I made a very simple python script, 2 files --> https://www.dropbox.com/s/j84xr2ypa5zplry/ecc_for_collider.zip?dl=0

ecc_for_collider.py  (a very small library)
gen_couple_points.py (a test program, it computes kG+mG, kG-mG, given kG and mG)

The script works  Smiley

For a very special definition of "works".  Wink

I spent some quality time with it and best I came up with was:

Code:
$ python gen_couple_points.py 
kG
0xbfcdf2
0xa884186c5d47633c9b58ae542b8b6797230c8e67808ade960793d4bc0e546cd3
0xd74beb0250afe97f2d1ab66a02e689447b87a2df62383f4717b9452607a9b4ff
*******
mG
0x1d1
0x87be732373bd4b738627fb63bd4d50bfd6f2bb81f804b52829549fe93fe1ac2e
0xf6a9186ff147b9b5ffc844b2ec0e255a1ae5537d75624288ce8421f87e94e1a4
*******
kG+mG
V: 115792089237316195423570985008687907853269984665640564039457584007908834671663
U: 100968868457032376717032254508194871768455479323471896895268685981853755980682
V: 100968868457032376717032254508194871768455479323471896895268685981853755980682
U: 0.0
Traceback (most recent call last):
  File "gen_couple_points.py", line 34, in
    kmx, kmy = jac_to_aff(jkmx, jkmy, jkmz)  # 3M for the inverse + (1S + 3M) to normalize x and y -> 6M + 1S         
  File "/data/soft/lin/LBC/generator/HRD/arulbero-ECC/ecc_for_collider.py", line 84, in jac_to_aff
    invjaz=inv(jaz,p)       
  File "/data/soft/lin/LBC/generator/HRD/arulbero-ECC/ecc_for_collider.py", line 33, in inv
    q = v/u
ZeroDivisionError: float division by zero

I have Python 3.6.0 on my system, so I gave the prints braces, removed the TABs from the files and included a print in the while:

Code:
def inv(a,p):   
        u, v = a%p, p
        x1, x2 = 1, 0
        while u != 1 :
                print("V:",v)
                print("U:", u)
                q = v/u
                r = v-q*u
                x = x2-q*x1
                v = u
                u = r
                x2 = x1
                x1 = x
        return x1%p

to see what's going on with u. I will debug a little bit more, so if you have any hints what to do, please tell. Else JFYI.

Rico
legendary
Activity: 3431
Merit: 1233
Hurry up! You must find something before bitcoin breaks $10000!
legendary
Activity: 1932
Merit: 2077
....
2. Outside the Box

IMO, for any substantial optimizations, it is required to think outside the box. The box here being the libsecp256k1 library. This library provides us with an API - a set of functions - which is functionally complete, but may sometimes be obstructive for certain tasks. If you look at the use case from above, it would certainly be nice if we had a function that could efficiently sum up affine points into jacobian.

That's why I started to hack my own libsecp256k1, extending it with functionality for the LBC use case (public key generation).

I made a very simple python script, 2 files --> https://www.dropbox.com/s/j84xr2ypa5zplry/ecc_for_collider.zip?dl=0

ecc_for_collider.py  (a very small library)
gen_couple_points.py (a test program, it computes kG+mG, kG-mG, given kG and mG)

The script works  Smiley

*********************************************************************
ecc_for_collider.py

function add_a_a_j(x1, y1, x2, y2)  

--> input kG=(x1,y1) , mG=(x2,y2)

--> output kG + mG = (x3,y3,z3)    (0
--> 4M + 2S
Code:
        h=(x2-x1)  % p
r=(y2-y1)  % p

a=r**2 % p    # 1S
        b=h**2 % p    # 1S
c=b*h  % p    # 1M   c=h**3
        d=x1*b % p    # 1M   d=x1*h**2
e=y1*c % p    # 1M   e=y1*h**3

x3 = (a-c-2*d)    % p   # 0M   r**2 - h**3 - 2*x1*h**2
        y3 = (r*(d-x3)-e) % p   # 1M   r*(x1*h**2 - x3) - y1*h**3
z3 = h                  # 0M   x2-x1
This is the classic "mixed" jacobian-affine addition (with Z1 and Z2 = 1)   ("A"+"A" --> J)
I use only affine coordinates (for the operands), because I know already all coordinates of any points kG, G, 2G, mG, 2048G, this is the first advantage of this method.

function symmetric(x1,y1,x2,y2,x3,z3inv,z3inv2)
This function exploits the symmetry of kG+mG / kG-mG respect of kG
 
--> input: kG, mG, kG+mG (all in affine coordinates!), (z3)^-1 and (z3)^-2 of kG+mG  

--> output: kG-mG (in affine coordinates)

-->  4M (including jacobian to affine)

Code:
def symmetric(x1,y1,x2,y2,x3,z3inv,z3inv2):

x4 = (x3+4*(y1*y2)*z3inv2)       % p   #2M
y4 = (z3inv*(x4-x1)*(y1+y2) -y1) % p   #2M
  
        return x4,y4


If kG = (x1,y1), mG = (x2,y2) ,  kG+mG = (x3,y3) then you have:

kG-mG = (x4,y4) = (  x3+4*y1*y2)/(x2-x1)^2  ,  (x4-x1)*(y1+y2)/(x2-x1)  -y1 )
*******************************************************************

First compute kG (in affine coordinates, I changed my mind) (remember: my k stands for your k+2048)

You could compute then:

1) first k+1, k+2, k+3, ..., k+2048  ("A"+"A"->"J")    4M + 2S for each point with the function add_a_a_j
2) then jacobian to affine change  6M + 1S for 2048 points (you have already this function, don't look at mine for that)
3) then you compute k-1, k-2, k-3, ...., k-4, k-2048 ( at 1) you have to memorize the inverse of k+1,k+2,k+3,... to do that): 4M using the function symmetric.

Total: 14M + 3S for 2 points,  7M + 1,5S for each point (including jacobian to affine)

I didn't took care of the generation of the first point, k*G (more precisely: (k+2048)G)

With my proposal you have to perform 2 inverse for batch, 1 to get (k+2048)G in affine coordinates, 1 to the points from k+2049 to k+4096. You save then 3M x 2048 points (at least)

-----------------------------------------------------------------------------------------------------------------------------
EDIT:  maybe an another improvement is possible: if we use the symmetric function for generate all points?

If we have kG and kG+mG (and mG) --> we get kG-mG and viceversa  (with symmetric function)

if we have kG and kG-mG (and mG)  --> we get kG+mG .

Now, if we have kG+mG and kG (and mG), we can get kG+2mG!   Shocked

Infact kG and kG+2mG are symmetric respect to the point kG+mG    kG=(kG+mG)-mG, kG+2mG=(kG+mG)+mG


The only problem is: we don't have yet kG+mG in affine coordinates, I have to do some computations... maybe tomorrow  
legendary
Activity: 1120
Merit: 1037
฿ → ∞
hi, can I use my own blf file and rename to funds_h160.blf?

You can, but you should do it offline - the generator will give wrong answers to the challenge-response between the LBC client and the generator and thus end up in blacklist pretty fast.


Rico
member
Activity: 114
Merit: 11
hi, can I use my own blf file and rename to funds_h160.blf?
legendary
Activity: 1140
Merit: 1000
The Real Jude Austin
***placeholder***

What do you think about?

Wow! Thanks a lot for all these ideas. I will need some time to go through that and answer then.
Just reserving this space to do it here. Some things are very promising - very exciting.


Rico


Such fart smellers...
legendary
Activity: 1120
Merit: 1037
฿ → ∞

1. Affine vs. Jacobian additions

I'd like to start with the comments on the hrdec_mult_gen2 code. It is an evolutionary descendant of secp256k1_ecmult_gen2 from https://github.com/ryancdotorg/brainflayer/blob/master/ec_pubkey_fast.c. If you strip away all the - in our case - unnecessary bittwiddling, the core of that sub was 32 invocations of

Code:
secp256k1_gej_add_ge_var(r, r, &prec[j*n_values + bits], NULL);

where r was incrementally added the precomputed affine points (r = r + ax).

Now - if I have two affine points a1 and a2 I'd like to sum up in a jacobian coordinate j, I could do

Code:
secp256k1_gej_add_ge_var(j,j,a1);
secp256k1_gej_add_ge_var(j,j,a2);

as with the original code or I could do

Code:
secp256k1_gej_set_ge(ja1,a1);
secp256k1_gej_set_ge(ja2,a2);
secp256k1_gej_add_var(j, ja1, ja2);

The gej_set_ge runtime is negligible, so I end up with (12M + 4S)  (J+J --> J)  versus 2 x (8M + 3S)   (J+A --> J) - which is 16M + 6S
If I happen to be lucky and have a number 2n of points to add (which is the case here), I can do a tree-addition and safe one operation compared to the incremental += addition.



2. Outside the Box

IMO, for any substantial optimizations, it is required to think outside the box. The box here being the libsecp256k1 library. This library provides us with an API - a set of functions - which is functionally complete, but may sometimes be obstructive for certain tasks. If you look at the use case from above, it would certainly be nice if we had a function that could efficiently sum up affine points into jacobian.

That's why I started to hack my own libsecp256k1, extending it with functionality for the LBC use case (public key generation).

e.g. if you look at the field element functionality, you have some primitives like negation, addition, normalization etc.

If you look at the gej_ad_ge_var function  itself, you have there such things like:

Code:
secp256k1_fe_negate(&h, &u1, 1); secp256k1_fe_add(&h, &u2);
secp256k1_fe_negate(&i, &s1, 1); secp256k1_fe_add(&i, &s2);

And although they are inlines, still a specialized

Code:
// hrdec_fe_sub_m1                       r = a - b (1)
SECP256K1_INLINE static void hrdec_fe_sub_m1(secp256k1_fe *r, const secp256k1_fe *a, const secp256k1_fe *b) {
  r->n[0] = 0xFFFFEFFFFFC2FULL * 4 - b->n[0] + a->n[0];
  r->n[1] = 0xFFFFFFFFFFFFFULL * 4 - b->n[1] + a->n[1];
  r->n[2] = 0xFFFFFFFFFFFFFULL * 4 - b->n[2] + a->n[2];
  r->n[3] = 0xFFFFFFFFFFFFFULL * 4 - b->n[3] + a->n[3];
  r->n[4] = 0x0FFFFFFFFFFFFULL * 4 - b->n[4] + a->n[4];
}

is faster instead of a negate+add (provided you are aware of the magnitude). So in my opinion, we must not constraint our thinking by the things offered from the secp256k1 toolbox, but rather allow for the genesis of own tools.




I'll elaborate on your other comments later.

To be continued...

Rico
legendary
Activity: 1932
Merit: 2077
I had another idea.

First we take a look at your code, then my proposal.

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

                                FROM JACOBIAN TO AFFINE COORDINATES


Let's start from static void hrdec_ge_set_all_gej_new(secp256k1_ge *r, const secp256k1_gej *a)

Your code:
Code:
....
for (i = 1; i < 4096; i++) {
    secp256k1_fe_mul(&az[i], &az[i - 1], &a[i].z);
  }

  secp256k1_fe_inv_var(&u, &az[--i]);  // sets i to 4095 here  <---- You perform only 1 inverse

  while (--i) {
    secp256k1_fe_mul(&az[i + 1], &az[i], &u);
    secp256k1_fe_mul(&u, &u, &a[i + 1].z);
  }

To avoid to compute 4096 inverse field elements, you are using the "Simultaneous inversion" algorithm
in this way you perform only 1 inverse + 3*4095M = 1I + 12285M. You trade each inverse for 3 multiplication.

My proposal: only 1,5 multiplication for each inverse -->  1 inverse + 1,5*4095M = 1I + 6144M (the details later)


Your code:
Code:
for (i = 0; i < 4096; i++) {
    r[i].infinity = a[i].infinity;
    secp256k1_ge_set_gej_zinv(&r[i], &a[i], &az[i]);
  }

From secp256k1  ( https://github.com/bitcoin-core/secp256k1/blob/master/src/group_impl.h ):
Code:
static void secp256k1_ge_set_gej_zinv(secp256k1_ge *r, const secp256k1_gej *a, const secp256k1_fe *zi) { 
75     secp256k1_fe zi2;
76     secp256k1_fe zi3;
77     secp256k1_fe_sqr(&zi2, zi);          --> you can compute this only 2048 instead of 4096
78     secp256k1_fe_mul(&zi3, &zi2, zi)  --> you can compute this only 2048 instead of 4096
79     secp256k1_fe_mul(&r->x, &a->x, &zi2);
80     secp256k1_fe_mul(&r->y, &a->y, &zi3);
81     r->infinity = a->infinity;
82 }

So you perform additional operations: (3M + 1S) * 4096 = 11228M + 4096S  to pass from jacobian to affine coordinates
                                              
                                                 (X,Y,Z) --> (X/Z^2,Y/Z^3)  
 
I think there is a way to perform only (3M + 1S)*2048 + 2M*2048 = 10240M + 2048S

Total:   1I + 23513M + 4096S   <->  1I + 16384M + 2048S    (about  -33%)

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

Then let's look at the generation of uncompressed public keys:

Your code:
Code:

hrdec_mult_gen2(&batchpj[0], start);

for (i = 1; i < 4096; ++i) {
    hrdec_gej_add_ge(&batchpj[i], &batchpj[i-1], &incr_a);             // increment public key
  }

.....

static void hrdec_mult_gen2(secp256k1_gej *r,
                const uchar *seckey) {

  secp256k1_gej o1;
  secp256k1_gej s1, s2, s3, s4, s5, s6, s7, s8,
                s9,s10,s11,s12,s13,s14,s15,s16;


  secp256k1_gej_set_ge(&o1, &prec[      seckey[31]]);
  secp256k1_gej_add_ge_var(&s1, &o1, &prec[ 256 + seckey[30]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[512 + seckey[29]]);
  secp256k1_gej_add_ge_var(&s2, &o1, &prec[ 768 + seckey[28]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[1024 + seckey[27]]);
  secp256k1_gej_add_ge_var(&s3, &o1, &prec[1280 + seckey[26]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[1536 + seckey[25]]);
  secp256k1_gej_add_ge_var(&s4, &o1, &prec[1792 + seckey[24]], NULL);

  secp256k1_gej_set_ge(&o1, &prec[2048 + seckey[23]]);
  secp256k1_gej_add_ge_var(&s5, &o1, &prec[2304 + seckey[22]], NULL);

....
secp256k1_gej t1;
  
  secp256k1_gej_add_var(&t1,  &s1,  &s2, NULL);
  secp256k1_gej_add_var(&s1,  &s3,  &s4, NULL);
  secp256k1_gej_add_var(&s2,  &s5,  &s6, NULL);
  secp256k1_gej_add_var(&s3,  &s7,  &s8, NULL);
  secp256k1_gej_add_var(&s4,  &s9, &s10, NULL);
  secp256k1_gej_add_var(&s5, &s11, &s12, NULL);
  secp256k1_gej_add_var(&s6, &s13, &s14, NULL);
  secp256k1_gej_add_var(&s7, &s15, &s16, NULL);


  secp256k1_gej_add_var(&s8, &t1, &s1, NULL);
  secp256k1_gej_add_var(&s1, &s2, &s3, NULL);
  secp256k1_gej_add_var(&s2, &s4, &s5, NULL);
  secp256k1_gej_add_var(&s3, &s6, &s7, NULL);

  secp256k1_gej x1,x2;

  secp256k1_gej_add_var(&x1, &s1, &s2, NULL);
  secp256k1_gej_add_var(&x2, &s3, &s8, NULL);

  secp256k1_gej_add_var(r, &x1, &x2, NULL);
}

From secp256k1 ( https://github.com/bitcoin-core/secp256k1/blob/master/src/group_impl.h )
Code:
static void secp256k1_gej_add_var(secp256k1_gej *r, const secp256k1_gej *a, const secp256k1_gej *b, secp256k1_fe *rzr) { 
362     /* Operations: 12 mul, 4 sqr, 2 normalize, 12 mul_int/add/negate */
363     secp256k1_fe z22, z12, u1, u2, s1, s2, h, i, i2, h2, h3, t;
364
 
.....

So you are using the Point Addition (12M + 4S)  (J+J --> J) https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates#Point_Addition_.2812M_.2B_4S.29

instead of the more efficient :  Mixed Addition (with affine point) (8M + 3S)   (J+A --> J) (same link)

Code:
414  static void secp256k1_gej_add_ge_var(secp256k1_gej *r, const secp256k1_gej *a, const secp256k1_ge *b, secp256k1_fe *rzr) { 
415     /* 8 mul, 3 sqr, 4 normalize, 12 mul_int/add/negate */
416     secp256k1_fe z12, u1, u2, s1, s2, h, i, i2, h2, h3, t;

Maybe there is a reason (if you compute kG, kG + G, (k+1)G + G, why G is not in affine coordinates?), I must admite I don't understand well these piece of code.

Do you use the same function (secp256k1_gej_add_var) in hrdec_gej_add_ge too?
Code:
for (i = 1; i < 4096; ++i) {
    hrdec_gej_add_ge(&batchpj[i], &batchpj[i-1], &incr_a);             // increment public key
  }

In any case, I understand that you perform at least (8M +3S)*4096 op (or not?)

And it seems to me that you don't exploit at all the fact that the keys are consecutive (I'm sorry in advance if I'm wrong, I really can't read code in general, not only yours Roll Eyes )
 

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

My proposal: instead of generating  k*G,  k*G + G,  (k+1)*G + G, ....

you could

1) precompute G, 2*G, 3*G, ...., 2048*G

2) then generate as first point of the batch: (k+2048)*G = k'*G (jacobian coordinates -> (X1, Y1, Z1)) better (X1,Y1,1)

3) then generate the following couples:  

k'*G+1*G , k'*G-1*G
k'*G+2*G, k'*G-2*G
.......................................
k'*G+m*G, k'*G-m*G
.......................................
k'*G+2048*G, k'*G-2048*G


In this way:

a) k'G is always equals to (X1,Y1,Z1,1) (jacobian affine coordinates)

b)  m*G = (X2,Y2,1) is always in affine coordinates!

c) k'*G - m*G = k'*G+(-m*G) and +m*G / -m*G have the same X2, and Y2 opposite

then you can use the same X2 in 2 operations (and the same inverse!)

Mixed Addition (with affine point) in your case --> (4M 3M + 1,5S):
Code:
U1 = X1  (Z2=1)      
U2 = X2*Z1^2    -->  1/2M (you have to compute Z1^2 only once in the batch, X2 is the same in +mG and -mG)
S1 = Y1    
S2 = Y2*Z1^3     --> 1/2M (you have to compute Z1^3 only once in the batch, and remember that mG ->Y2, -mG -> -Y2)
        
H = U2 - U1   =   X2*Z1^2 - X1    --> 0 M
R = S2 - S1   =   Y2*Z1^3 - Y1     -->  0 M
X3 = R^2 - H^3 - 2*X1*H^2          -->   (1 + 1/2)S + 2*1/2 M = 1,5S + 1M (H is the same each 2 addition)
Y3 = R*(X1*H^2 - X3) - Y1*H^3.     -->   1M + 1/2M = 1,5M (Y1 is the same,  H is the same each 2 addition )
Z3 = H*Z1  --> 1/2 M               --> (Z3 is the same each 2 addition, then the inverse is the same too!)
return (X3, Y3, Z3)

Total:  4M 3M + 1,5S


What do you think about?
newbie
Activity: 19
Merit: 0
great reply fellas great clarification
full member
Activity: 177
Merit: 101

So short story:

with LBC, you can wiggle in extreme keyspace, but you really should focus on the 1st 2160 bits.
shifty252 found buggy software @ https://rawgit.com

end of story

Rico


I agree with Rico. No FUD spreading, just buggy software(the brainwallet). The only thing i want to add is that LBC allowing fast checking above the limit will yield false collisions which can easily reveal the real private key.

Also, with the new generator i get 565000 keys/s per core
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Looking at the logs, I see


1485762709  xxx.xxx.xxx.xxx [276439977, 276447880] <<<                      Hitler_Army v0.993
1485762709  xxx.xxx.xxx.xxx [276541497, 276549400] >>>                      Hitler_Army
1485762713  xxx.xxx.xxx.xxx [276447881, 276455176] <<<                      Hitler_Army v0.993
1485762714  xxx.xxx.xxx.xxx [276549401, 276556696] >>>                      Hitler_Army


 Roll Eyes

Quote
I hope, you are aware this feature gives you some freedom that could be abused, so should there be some profanities appearing in the stats or anything shady I have not taken into account yet, I reserve the right to modify the ids and in severe (recurring) cases to ditch them. If you have to have an own id, try to be unique, try to be funny or just keep some inconspicuous md5 and impress by the #Gkeys next to it.

Message from Satan_Army to Hitler_Army: Have a new name ready before/when you enter the top30.
I'm quite tolerant and personally I wouldn't care, but the server is in Germany and given their lack of humor in these things...
so @client_operator: PM me with a desired alternate name. ___88___ is the utmost I could do.

Rico
legendary
Activity: 1120
Merit: 1037
฿ → ∞
I run...

Code:
LBC -id haze_the_great -s x:mypassword -c 1 -t 1

and I get...

Code:
unknown option: id
Formal error processing command line options!

Are you sure you're running 0.993 version of the client?

Maybe a
Code:
LBC -u
first?


Rico


Pages:
Jump to: