Of course if your name is Gregory Maxwell you are allowed to abuse this system. So I happened to tell this young promising programmer, that not all of his actions are 31337 and especially that the libsecp256k1 is also not that Lichtgestalt as which it is presented. Some technical arguments were exchanged until he started to call me a thief. Now - he might have found it insulting me telling him he can't program, still I do believe that calling someone a thief with no basis whatsoever is a different category. So in my 1st rage I threatened to send some lawyers his way, but after some sleep and thought I figured out de-escalating matters would be better and said we'll solve issues like "real men" on the next Bitcoin conference where we'll meet. *BAM* -> negative rating "Wallet thief, threatening violence..." etc. My nice 37+ rating (earned over 2-3 years) turned orange -1 without having ever had business with that "man" immediately. I didn't mind much, because as I found out - everyone can give here everyone else any rating for any reason "e.g. if you have the letter 'z' in your nick" ... Which is funny and makes the system totally moot. (And I still can't believe false accusations are ok in this forum) Unless you have a positive rating such as I had. Because as I happen to buy some digital goods from time to time (namely AWS codes), I never had problems with trust to have newbies go 1st. Today, the newbie told me I do have "caution trading". To sum up: Gregory Maxwell is shit Bitcointalk.org trust system is shit Whoever invented it thought shit Whoever has a different opinion about it than me now is also shit.  - Ok, I'm overdoing it there a little bit and while I am a little bit pissed about it, I just can't get myself to take it seriously. Shit. Rico |
|
|
|
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 |
|
|
|
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 |
|
|
|
For a very special definition of "works". I spent some quality time with it and best I came up with was: $ 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 <module>
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: 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 |
|
|
|
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 |
|
|
|
1. Affine vs. Jacobian additionsI'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 secp256k1_gej_add_ge_var(r, r, &prec[j*n_values + bits], NULL); where r was incrementally added the precomputed affine points (r = r + a x). Now - if I have two affine points a1 and a2 I'd like to sum up in a jacobian coordinate j, I could do 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 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 2 n 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 BoxIMO, 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: 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 // 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
|
|
|
|
|
An Insurance. In times of rising BTC: profit, in times of falling BTC: loss.
So basically it's a bet on rising BTC.
Hopefully your friend has enough BTC to cover the cost of falling BTC.
There are some evident drawbacks to this concept.
1) Given enough BTC and falling prices, this thing would get liquidated fast
2) How does your friend hedge against such a case?
3) How does one know that at least ones deposited BTCs are safe and to be returned in such a case?
Suggestion:
Make two of these portals.
moon.btcfutures.io
dead.btcfutures.io
The 1st one is what your friend planned. The 2nd is the inverse. It's like betting on black and red in the casino at the same time - you cannot lose. Oh wait...
Rico
|
|
|
|
|
Ich sehe, es wurden schon allerlei qualifizierte und technisch untermauerte Argumente dargelegt.
Daher erlaube ich mir kurz direkt auf die Frage "Wieveil RAM macht Sinn?" zu antworten:
Mehr!
Rico
|
|
|
|
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
 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 |
|
|
|
I run... LBC -id haze_the_great -s x:mypassword -c 1 -t 1 and I get... unknown option: id
Formal error processing command line options!
Are you sure you're running 0.993 version of the client? Maybe a first? Rico |
|
|
|
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): 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 So short story: with LBC, you can wiggle in extreme keyspace, but you really should focus on the 1st 2 160 bits. shifty252 found buggy software @ https://rawgit.comend of story Rico |
|
|
|
whats this mean... ELI5 please  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 |
|
|
|
Neben EMVG, WaffG, SprengV, ChemVerbotsV und vielen weiteren, wieder ein neues Gesetz, welches ich in Zukunft ignorieren kann: Dann wird es wieder losgehen und es wird schrecklich. Jeder wird einen anderen Kopf aufhaben, und eins wird das andere nicht mehr mögen. Der Bruder wird den Bruder nicht mehr kennen und die Mutter die Kinder nicht. Gesetze werden gemacht, die niemand mehr achtet, und Recht wird nimmer Recht sein. Aber aus Krieg und Not wird keiner etwas sich merken. Wieder wächst der Übermut. Die Quellenangabe erspare ich mir. Rico |
|
|
|
Ich verstehe prinzipiell nicht, wie eine Quelle BTCs kauft. Eine Euroquelle? Als BTC Verkäufer ist man vor einem Raubüberfall genauso bedroht wie ein Käufer. Gerade im seltenen Fall, wenn man kein Falschgeld aufgedrückt bekommt , hat man ja nach der Transaktion das Bargeld... Ey Du di Bitkojn isch nisch gekomme - Isch machsch disch Messah bis Du Krankenhaus! Rico |
|
|
|
Kurzer Statusbericht: - client wurde auf 0.993 upgedated, man kann nun eigene Id angeben, und auch mit einem Passwort absichern (Vorbereitung für Auszahlungen)
- Die "echte" Key-Rate wird nach jeder Runde im Client angezeigt; Konfigurationsdatei für default, damit man nicht immer alles auf der Kommandozeile eingeben muss.
- no_update flag - für Leute, denen nicht wohl dabei ist wenn LBC sich und andere Files auto-updated.
- Wenn jemand mehrere Ids hatte, kann ich das in der DB konsolidieren.
- Kleiner Speedup wiederum bei AVX2 Generator, mit gcc 6.3.0 statt 5.4.0 compiliert
- Bugfix: Der Test findet wieder korrekterweise 4 Treffer
- Manual (Benutzerhandbuch) erweitert
- Gegenwärtige Pool Performance ~ 50 Mkeys/s
Momentan ist der Pool wirklich noch ein klitzekleines Projektchen. Zwischen 9 und 11 Leuten - mich eingeschlossen - sind dauerhaft aktiv, wobei derzeit einer - nicht ich - 60% der Pool-Performance stellt. Nicht auszudenken, wenn da mal 100-200 Leutchen eindreschen würden... Rico |
|
|
|
whats this mean... ELI5 please 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 |
|
|
|
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. Rico |
|
|
|
You can put these on JudeAustin:
ba6c903275906f7367f83e52e393648e
14ec34f45a80e99744e75b5e313a3d29
117a66a89de5393b34b7e37e8a00b2b6
There might be a couple more, for some reason on my "dedicated" every so often the client ID would change.
I will PM you the IP if you want to check if there are any others.
Thanks,
Jude
15078b42893011a9e1d13c0d53c8774f - also merged Congrats, you're #5 Rico |
|
|
|
|
Also my offer to consolidate everybody's delivered Gkeys to a new id is still on the table.
I consolidated my old 1ff... and the Pleiades prototype also under __rico666__
Just tell me your old id and the new one and I move the gkeys from the old to the new (old id will be deleted from the DB).
Rico
|
|
|
|
|
Show Posts
