Bitcoin Forum
April 25, 2024, 01:54:15 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 »
  Print  
Author Topic: Large Bitcoin Collider (Collision Finders Pool)  (Read 193118 times)
Jude Austin
Legendary
*
Offline Offline

Activity: 1140
Merit: 1000


The Real Jude Austin


View Profile WWW
January 29, 2017, 07:29:15 AM
 #381

Best generator chosen: gen-hrdcore-sse42-linux64
Ask for work... Server doesn't like us. Answer: toofast.


toofast. ?

Buy or sell $100 of Crypto and get $10!
1714010055
Hero Member
*
Offline Offline

Posts: 1714010055

View Profile Personal Message (Offline)

Ignore
1714010055
Reply with quote  #2

1714010055
Report to moderator
1714010055
Hero Member
*
Offline Offline

Posts: 1714010055

View Profile Personal Message (Offline)

Ignore
1714010055
Reply with quote  #2

1714010055
Report to moderator
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714010055
Hero Member
*
Offline Offline

Posts: 1714010055

View Profile Personal Message (Offline)

Ignore
1714010055
Reply with quote  #2

1714010055
Report to moderator
1714010055
Hero Member
*
Offline Offline

Posts: 1714010055

View Profile Personal Message (Offline)

Ignore
1714010055
Reply with quote  #2

1714010055
Report to moderator
1714010055
Hero Member
*
Offline Offline

Posts: 1714010055

View Profile Personal Message (Offline)

Ignore
1714010055
Reply with quote  #2

1714010055
Report to moderator
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 29, 2017, 10:00:06 AM
 #382

Best generator chosen: gen-hrdcore-sse42-linux64
Ask for work... Server doesn't like us. Answer: toofast.


toofast. ?

Maybe something went wrong when benchmarking the generator (not executable or so).
The server evaluates the self-proclaimed speed of the client. If it is too fast (I should look up where the threshold is, but unless you have a 6GHz overclocked liquid nitrogen cooled Kaby Lake, your client claimed a speed that is not within the reach of todays CPUs) the server will react as you see.
As I see a sse42 generator chosen, you have a CPU generation that has no AVX2, so either AMD or pre-Haswell, There is  nothing "too fast and at the same time real existant" there.  Smiley


Rico

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

Activity: 19
Merit: 0


View Profile
January 29, 2017, 08:02:35 PM
 #383

whats this mean...  ELI5 please Smiley

bitcoin is ded?


anyone that can answer this? i am genuinely curious and it seems like i am being ignored
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 29, 2017, 08:06:57 PM
 #384

whats this mean...  ELI5 please Smiley

bitcoin is ded?
anyone that can answer this? i am genuinely curious and it seems like i am being ignored

I'm also very interested, but it seems everyone went on dive station (gone into hiding) regarding this.
My best bet would be, that this is an overflow/modulo bug in some specific software, but I really shouldn't be the one commenting on this.

Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  Past BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1140
Merit: 1000


The Real Jude Austin


View Profile WWW
January 29, 2017, 09:08:32 PM
 #385

whats this mean...  ELI5 please Smiley

bitcoin is ded?
anyone that can answer this? i am genuinely curious and it seems like i am being ignored

I'm also very interested, but it seems everyone went on dive station (gone into hiding) regarding this.
My best bet would be, that this is an overflow/modulo bug in some specific software, but I really shouldn't be the one commenting on this.

Rico


I don't understand what he is asking.

Is he asking that due to this project Bitcoin is dead?

Thanks,
Jude

Buy or sell $100 of Crypto and get $10!
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 29, 2017, 09:19:10 PM
 #386

whats this mean...  ELI5 please Smiley

bitcoin is ded?
I don't understand what he is asking.

Is he asking that due to this project Bitcoin is dead?

He's asking about shifty252s comment #369 about the posted alternate key for the BTC address found 2016-10-11 03:00:34 GMT (https://lbc.cryptoguru.org/trophies).


Rico

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

Activity: 1914
Merit: 2071


View Profile
January 29, 2017, 09:42:48 PM
 #387

The pool found:

Private key:
000000000000000000000000000000000000000000000000000022306e3f1a72

Public key :
04
E7D529CEA967BDFCA1F4096C91A35E3BAC67E87EAF5A03895889BEE00412FEC6
59F5D0823DBAAF3768684D3625C7D72909E6C2F56CEAA0DE608A0F3AAB27F4E2

hash 160 --> f6cc30532dba44efe592733887f4f74c589c9602

Address: 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg


From here:

http://prnt.sc/e0nsqp

I don't see a complete pk : 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDVwj9...

then there is not (yet) a proof of collision.
Haze
Full Member
***
Offline Offline

Activity: 149
Merit: 100


View Profile
January 29, 2017, 10:42:03 PM
 #388

I never set an ID or password previously and when I try to set something like this, I get the "server doesn't like us. Answer:wrong secret.". How can I get up and running? Sorry for the noob question.

Code:
$ LBC -id haze -s mypassword -c 1 -t 1
Best generator chosen: gen-hrdcore-skylake-linux64
Ask for work... Server doesn't like us. Answer: wrong secret.

I expected some hiccups - that's why I posted the docs in advance

* Id is too short (8-32 chars)
* You need to set a password, so you have to provide some old password.

As you had none before, you can take an arbitrary one

so if you do

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

it should work. You should see a message "Password set". From then on -s mypassword is enough.
If you would like to change it, you need to do -s mypassword:newsecretpass




Rico


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!
Jude Austin
Legendary
*
Offline Offline

Activity: 1140
Merit: 1000


The Real Jude Austin


View Profile WWW
January 29, 2017, 11:01:27 PM
 #389

whats this mean...  ELI5 please Smiley

bitcoin is ded?
I don't understand what he is asking.

Is he asking that due to this project Bitcoin is dead?

He's asking about shifty252s comment #369 about the posted alternate key for the BTC address found 2016-10-11 03:00:34 GMT (https://lbc.cryptoguru.org/trophies).


Rico


Oh, that's fake isn't it?

The portion of private key they show isn't possible:

Here is the very last address PK:
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetqj84qw

Here is the supposed collision PK:
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDVwj9

5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetqj84qw
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDVwj9...

How can a V come after a U if it's the last PK?

Thanks,
Jude

Buy or sell $100 of Crypto and get $10!
throwawayme3434534554
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
January 30, 2017, 03:43:59 AM
 #390

maybe trying to spread some fud? to cause a price panic?
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 30, 2017, 06:17:11 AM
 #391

maybe trying to spread some fud? to cause a price panic?

I wouldn't be that harsh. I think the worse news would be if someone found a collision, but was afraid to post it.
It seems what happened was this (from my messagebox):

Quote
Until today i knew that the maximum possible value a bitcoin key could have is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

But i learned something new. If a key with value over maximum number of n points is used, then the address generation resets from base point G. For example, by adding 4 to the key i pasted above we get the value 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364145 which produces the same public keys and addreses as 0x4

Quote from: shifty252
Quote from: rico666
That's not a collision, that's the simple modulo p arithmetics.

True, but https://rawgit.com/brainwallet/brainwallet.github.io/f7679dd03f39a04edced641960a7c3df1116fea9/#generator accepts it as a real key.
In theory, a broken bitcoin client could accept a key over the limit and generating a "collision" like this.

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

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

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 30, 2017, 06:21:08 AM
 #392

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



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

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 30, 2017, 08:11:05 AM
 #393

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

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

Activity: 177
Merit: 101


View Profile
January 30, 2017, 08:26:01 AM
 #394


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
throwawayme3434534554
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
January 30, 2017, 06:59:24 PM
 #395

great reply fellas great clarification
arulbero
Legendary
*
Offline Offline

Activity: 1914
Merit: 2071


View Profile
January 30, 2017, 08:05:02 PM
Last edit: February 03, 2017, 10:26:21 PM by arulbero
Merited by Piggy (5)
 #396

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?
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 30, 2017, 09:40:55 PM
Last edit: January 31, 2017, 08:02:31 AM by rico666
 #397


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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  Past BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1140
Merit: 1000


The Real Jude Austin


View Profile WWW
January 30, 2017, 11:51:03 PM
 #398

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

Buy or sell $100 of Crypto and get $10!
SlarkBoy
Member
**
Offline Offline

Activity: 114
Merit: 11


View Profile
January 31, 2017, 09:02:08 AM
 #399

hi, can I use my own blf file and rename to funds_h160.blf?
rico666 (OP)
Legendary
*
Offline Offline

Activity: 1120
Merit: 1037


฿ → ∞


View Profile WWW
January 31, 2017, 09:30:05 AM
 #400

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  Past BURST Activities
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!