Yes, we've already established that you're primarily interested in stealing from people and that you're unable to understand that many others are not exactly supportive of your goals.
You are aware, that this is already beyond the threshold of legal action? I am trying to find a hash160 collision. If you have evidence that I have stolen something in the past or evidence I plan to steal something in the future, please either present that evidence or keep it near when the lawyer knocks on your door. Until then, you may educate yourself: https://lbc.cryptoguru.org/man/theoryAnd if you continue with your allegation(s), I really have no problem to step out of (pseudo)-anonymity and let my lawyers drill your sorry ass until they hit crude oil. And this is not even a rude statement. You seem to think that people who don't slavishly help you steal from others are bad or incompetent people, or at least that you can get them to help you by insulting them as though they were. For someone who claims to be so old, you sure don't seem very wise.  Final warning. I can benevolently assume, that your reactions are based on the false assumption I am someone who does or wants to steal from people. Under such an assumption I would probably also interact "harshly" with my counterpart. So I give you that. But unless you have the slightest proof for your allegation/assumption, the time to stop it has come. Congrats, by ignoring the _constant time_ in the function documentation you just leaked the users secret to a timing side-channel-- and _still_ managed to end up with code considerably slower than simply changing to non-constant time competently.
Ok. Hasn't explained why cmov implementation looks like it does, because right now - after this explanation - it seems to me cmov is short for "constant time move" - which would lead us to my original *thumbs up*... Rico |
|
|
|
könnten wir nicht auch versuchen moneros oder andere zu finden?
Du meinst Kollisionen? Erstmal finden wir eine hash160 Kollision und dann sehen wir weiter. Oder wenn ich irgendwann keinen Bock mehr habe, dann gebe ich den Code frei, aber noch habe ich Bock.  Es ist übrigends nicht so einfach das mal auf andere Cryptos zu übertragen. So ein Projekt muss den Generierungs-Pfad (Privatschlüssel -> Adresse) durchlaufen und die sind meist nicht optimiert. Gerade habe ich mit gmaxwell ein "freundschaftliches" Gespräch gehabt und festgestellt, dass z.B. für die Core-Entwickler eigentlich nur die Geschwindigkeit der pubkey Validierung von Interesse ist. Es gibt beim Bitcoin in dieser Hinsicht noch mehrere Kathedralen zu bauen, also werde ich da erst einmal mithelfen, bevor ich überhaupt an andere Cryptos denke. Rico |
|
|
|
You broke it....
Best generator chosen: gen-hrdcore-sse41-linux64
Ask for work... Not an ARRAY reference at /usr/local/share/perl/5.22.1/Math/BigInt/Calc.pm line 1180.
Kind of. Let me guess: You are updating from .899 to .960 There are some things broken along the path, because I fixed so many things. - libgmp can be completely ditched now.
- instead of Math::BigNum::GMP it uses core modules - no need to install anything
- but it needs recent versions of Math::BigNum[::Calc]
- You also will need LWP::Protocol::https because of the SSL communication
> make sure you have openssl-devel (or equivalent) installed
> cpan
cpan> upgrade
cpan> install LWP::Protocol::https
Sorry for the hassle, but this fixes a nasty bug in bignum computations, where all block numbers above 40 digits were rounded - thus computed wrong. Fortunately we are still in the 12-15 digit space. It also will lower installation footprint and hassle in the future. Rico |
|
|
|
It's a trivial optimization that already existed in three other places in the code. Thanks for noticing that it hadn't been performed there, and providing code for one of the two places it needed to be improved, but come on-- you're just making yourself look foolish here with the rude attitude while you're clearly fairly ignorant about what you're talking about overall. Case in point:
...verification ... verification ... verification
Gee - you haven't seen my rude attitude yet. And you won't, because I am honestly too old for these cockfights. It is evident you are completely project blind. Verification is king. Well - it isn't for me, right now I am interested in generation performance. Now the big revelation dear Maxwell: This is what libraries are about.A library(sic!) is not about serving just the purpose of sci-fi fans. And a librarian who is a sci-fi fan and is carried away by his fandom in a way he bars or neglects other uses of the library, is a BAD librarian. Don't be a bad librarian. Your reaction was expected. Now my "trivial" optimization is hardly worth it. Hey - it makes the relevant functions faster by 6-7 orders of magnitude, but as it brings only 0.5% for DA HOLY VERIFICATION ... nah. Elegantly this also allows you to sweep under the carpet the question why the rubbish code remained for so long in the lib. "Not worth it" I suppose... where did I read that?  edit: Odd to hear that, since the libsecp256k1 code has received many positive comments about its clarity and origination. One researcher described it as the cleanest production ECC code that he'd read. Style preferences differ, of course, -- lets see what your own code looks like ftp://ftp.cryptoguru.org/LBC/client/LBC <blink> <blink> So you take my intentionally deformatted code as counterexample of coding style ... *gasp* I don't think that futile attempt does even qualify as pathetic. Let's see a snapshot from my editor. https://i.imgur.com/JWSJlee.pngetc. Better luck next time. /edit But what is strange is that it is _extensively_ documented.
Ok. Let's take this piece of code and dissect it a little bit - shall we? I am fair and take what is supposedly one of the best commented pieces "secp256k1_gej_add_ge" secp256k1_fe_cmov(&rr_alt, &rr, !degenerate);
secp256k1_fe_cmov(&m_alt, &m, !degenerate);
/* Now Ralt / Malt = lambda and is guaranteed not to be 0/0.
* From here on out Ralt and Malt represent the numerator
* and denominator of lambda; R and M represent the explicit
* expressions x1^2 + x2^2 + x1x2 and y1 + y2. */
secp256k1_fe_sqr(&n, &m_alt); /* n = Malt^2 (1) */
secp256k1_fe_mul(&q, &n, &t); /* q = Q = T*Malt^2 (1) */
/* These two lines use the observation that either M == Malt or M == 0,
* so M^3 * Malt is either Malt^4 (which is computed by squaring), or
* zero (which is "computed" by cmov). So the cost is one squaring
* versus two multiplications. */
secp256k1_fe_sqr(&n, &n);
secp256k1_fe_cmov(&n, &m, degenerate); /* n = M^3 * Malt (2) */
So Malt is m_alt and Ralt is rr_alt - yeah sure, why not. What's more interesting is the correspondence between the code and the comments. q = Q = T*Malt^2 (1)WTF is Q and what is (1)? Oh - my advanced intuition tells me (1) is the magnitude of the result, but I could be wrong - some time to verify that needed. So the comment does not correspond to the code. The comment corresponds to the sum (not meant in an arithmetic sense) of the previous codes - it seems. Interesting... But this is all only prologue. Let's look at the last two lines of the code snippet: So the lib computes n = n², but if degenerate is true this computation is discarded as n is set to m. It claims in the aforementioned "documentation" this is a very witty thing to do. Methinks. I could be wrong. If I am right, the code is pretty bad, if I am wrong, I've been misled after all I know about the code (say 20 hours diddling with it in total). Personally, I'd compute the sqr only in case !degenerate. So the cost would actually be one squaring - sometimes - versus nothing. And this is just one tiny little example of a myriad of weirdnesses all around the code. So given what the perfect documentation tells me cmov being conditional move, the code would have been better written as: if (degenerate) {
n = m;
}
else {
secp256k1_fe_sqr(&n, &n);
}
Hm. Works. Is faster. Tests says "no problems found". And now the code makes sense. Of course it is only a trivial thing. Probably not worth the effort. Right? So conditional move you say? /** If flag is true, set *r equal to *a; otherwise leave it. Constant-time. */
static void secp256k1_fe_cmov(secp256k1_fe *r, const secp256k1_fe *a, int flag);
yes? Why do I see then this epic kludge in the code? static SECP256K1_INLINE void secp256k1_fe_cmov(secp256k1_fe *r, const secp256k1_fe *a, int flag) {
uint64_t mask0, mask1;
mask0 = flag + ~((uint64_t)0);
mask1 = ~mask0;
r->n[0] = (r->n[0] & mask0) | (a->n[0] & mask1);
r->n[1] = (r->n[1] & mask0) | (a->n[1] & mask1);
r->n[2] = (r->n[2] & mask0) | (a->n[2] & mask1);
r->n[3] = (r->n[3] & mask0) | (a->n[3] & mask1);
r->n[4] = (r->n[4] & mask0) | (a->n[4] & mask1);
#ifdef VERIFY
if (a->magnitude > r->magnitude) {
r->magnitude = a->magnitude;
}
r->normalized &= a->normalized;
#endif
}
Let's continue with the "extensive documentation": secp256k1_fe_sqr(&t, &rr_alt); /* t = Ralt^2 (1) */
secp256k1_fe_mul(&r->z, &a->z, &m_alt); /* r->z = Malt*Z (1) */
infinity = secp256k1_fe_normalizes_to_zero(&r->z) * (1 - a->infinity);
secp256k1_fe_mul_int(&r->z, 2); /* r->z = Z3 = 2*Malt*Z (2) */
secp256k1_fe_negate(&q, &q, 1); /* q = -Q (2) */
secp256k1_fe_add(&t, &q); /* t = Ralt^2-Q (3) */
Hm. Ah. There is our Q. We assume it is an alias for q. Why - who knows? Makes things more interesting. Again, we have our "the comment is the sum of previous code" and suddenly we use the alias only. Yeah why not. Best of all is to be able to have a subtraction in the comment, when the code says "add". This is way more thrill. And allow me for a final remark: ... even though this is purely internal code and is not accessible to an end user of the library.
WTF? The "end user of the library" is of exactly 0 (in words: zero) interest to our discussion. Hint: All this was only a remark. My energy is probably better spent in setting up my own FE arithmetics and a complete reimplementation of the GE API which as is absolutely ignores the natural flow of the data and need for MULADD, resp SETSUM 3-ARG operations. Don't worry, I won't disturb the intellectual incest any more. It could be considered rude. Good luck. Rico |
|
|
|
Komisch ist das ich nur mit einem core arbeiten kann.
Selbst wenn ich 3 starten möchte sagt er 1 core use
Er braucht pro Prozess ca 550 MB RAM. Wenn er feststellt, dass die Anzahl der gewünschten Prozesse mehr Speicher benötigen würde als vorhanden ist, drosselt er runter. Ggf. der VM mehr Speicher geben. Ggf. schauen was > cat /proc/cpuinfo
> free
sagen. Aber Du hast doch geschrieben, dass bei Dir die CPU Auslastung irgendwo bei 80% liegt - oder? Also muss das doch schon mal funktioniert haben. Rico |
|
|
|
There is no question that at this moment sipa's secp256k1 lib is the fastest solution on the market.
And you can complain all you want about messy coding or poor documentation, but unless you provide an alternative to prove that it can be done so much better... well, then it's just going to be a moaning.
And just a moaning isn't very professional.
Strange. I was under the impression that field_get_b32: min 0.647us / avg 0.666us / max 0.751us
field_set_b32: min 0.551us / avg 0.571us / max 0.624us
becomes
field_get_b32: min 0us / avg 0.0000000477us / max 0.000000238us
field_set_b32: min 0us / avg 0.0000000238us / max 0.000000238us allowed me a tiny little bit of moaning. Rico |
|
|
|
huhu schau mal ist das normal?
wenn ich dann enter drücke geht es normal weiter.
Ja, ist es. Misslungener Bildschirmschoner. SHIFT drücken reicht auch schon und man wurstelt nicht in die Bildschirmausgabe. Kannst aber lassen. Er arbeitet auch so weiter. Ich drücke ab und zu schift um zu sehen ob noch alles in Ordnung ist. So einmal die Woche.  wenn ich den client neu starte bzw den pc neu starte,
fängt er dann wieder von vorne an?
und merkt er sich schon gefundene adressen?
Wenn Du den PC ausschaltest/neu startest/er abstürzt etc. ... => Deswegen wird die Datei "FOUND.txt" angelegt. Die ist natürlich auch über Neustarts/Abstürze etc. persistent. D.h. Ja, er merkt sich schon gefundene Adressen. Er fängt nicht von vorne an, sondern fragt beim Server einfach die aktuelle Arbeit an und bekommt was zugewiesen. Der Server kümmert sich darum, dass nichts (unnötig) doppelt gemacht wird. Rico |
|
|
|
Test check failed! Expected 4 hits and got 2!
This happens at the moment. Probably it's the test itself failing (I had the generator showing uncompressed/compressed keys swapped.) Basically if you do ./gen-hrdcore-avx2-linux64 -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000
on the command line, it should spill out 4 lines (with hash160 and priv keys + 1 line challenge response). This is proof that all still works. I expect this to be fixed in the next version. Rico |
|
|
|
There are 3 benchmarks
bench_internal
bench_verify
bench_sign
which are built by ./configure --enable-benchmark
As for the difference in test speed, might have to do with some lines in tests.c which indicate a different number of rounds (plus tests for endomorphism) if endomorphism is on.
Built your program with endomorphism (./configure --enable-endomorphism) and report back with the results, should be faster.
Ok - I did. bench_verify shows speedup with endomorphism ecdsa_verify: min 42.0us / avg 42.2us / max 43.0us (with) ecdsa_verify: min 57.7us / avg 57.8us / max 58.4us (without) bench_internal shows no improvements (within measure tolerance) except one: wnaf_const: min 0.0887us / avg 0.0920us / max 0.102us (with) wnaf_const: min 0.155us / avg 0.161us / max 0.171us (without) I doubt this would cause the speedup from above. Rico |
|
|
|
And you can't seriously expect from and coder to work on his personal hobby project and then deliver it with the industry standards documentation.
Depends on the coder - I guess. As long as I have interest in my hobby project, I want it to be perfect. I for one have no problem to admit that my LBC projects still sucks badly in many places right now. I intend to improve. Documentation, Ease of use, Speed, One of them is to get decent EC performance on a GPU - that's why I am looking into this at all. What kind of documentation would you even expect from a lib that provides a simple EC math functions? The function names are descriptive enough if you understand the operations they provide. And if you don't understand the math behind it then no document is going to help you anyway.
Well - for me the names are pretty bad. "secp256k1_fe_cmov" *thumbs up* But it's not only that. The data structures are pretty sideways too. Actually I understand the math pretty well, that's why I am so puzzled about what I see - still unsure if the lib is seriously doing what I think it's doing. I don't think the person who wrote this did really care for performance - he probably just wanted something that sucked less. Sipa you say? Why did he abandon the project? Was it just some proof of work? Rico |
|
|
|
also den ordner habe ich noch nicht.
Zum nun 4. oder 5. Mal: es ist kein Ordner - es ist eine Datei. mit dem schlüssel komme ich nicht so wirklich klar. wo öffnest du die wallets denn dann?
./bitcoin-tool --output-format base58check --public-key-compression (un)compressed --network bitcoin --input-type private-key --input-format hex --output-type private-key-wif --input <hier der hex-code> Gerade kommt mir, dass es eigentlich keine schlechte Idee wäre das Bitcoin tool gleich auf die LBC Appliance mit zu installieren. Rico |
|
|
|
One question I have regarding secp256k1 is whether endomorphism is safe, and if yes, shouldn't it be enabled in bitcoin builds if it's faster (benchmarks show that it is)?
I don't think patents are any problem with the endomorphism code. The code itself is the problem. Not sure which benchmarks you are referring to, but if I take a (very coarse) look on benchmarks on my system, USE_ENDOMORPHISM is nothing you'd like to enable: Times for tests:
gcc version 6.3.1 20170109 (GCC)
1) CFLAGS -g -O2
real 0m14.365s
user 0m14.357s
sys 0m0.007s
2) CFLAGS -O3 -march=sklake
real 0m13.549s
user 0m13.547s
sys 0m0.000s
3) CFLAGS -O3 -march=sklake & USE_ENDOMORPHISM 1
real 0m15.660s
user 0m15.660s
sys 0m0.000s
4) CFLAGS -g -O2 & USE_ENDOMORPHISM 1
real 0m16.139s
user 0m16.137s
sys 0m0.000s
5) CFLAGS -g -O2 & undef USE_ASM_X86_64
real 0m14.849s
user 0m14.847s
sys 0m0.000s
6) CFLAGS -O3 -march=sklake & undef USE_ASM_X86_64
real 0m14.520s
user 0m14.517s
sys 0m0.000s
So yes, the beef seems to be in better assembler code and ditching endomorphism. On modern CPUs, ditch that old gcc too and use -O3 (forget what you've heard about it in the past years). Rico |
|
|
|
Can you show another library for the same application within a factor of _five_ of the performance? Or with more than 1/5th the documentation?
I'm just ... beside myself at your comment, it's not even insulting: it's just too absurd.
Good. We seem to live in different worlds then, each others world seeming absurd to the other one. I for one, find your "argument" of requesting to be shown another lib doing the same thing with 5 perf 1/5 docs quite absurd. It's like claiming that anything in the world by definition cannot suck when there is nothing else that sucks less. Really absurd. No I haven't, because reading the secp256k1 code is a major PITA, but thanks for the pointer. That wheel would probably be the next thing I'd reinvented. If you open a PR on the function you should add it to the bench_internal benchmarks as you go.
What's a PR? Press release? Ah. pull request I suppose. You're assuming too much. E.g. that the whole world runs on - or is - git. Is there any place where R&D discussion about further development is ongoing? Before I'd start re-implementing that mess from scratch I'd prefer to participate in some "official endeavor". same place it's always been https://github.com/bitcoin-core/secp256k1/If that is the "discussion" place, no wonder I didn't see it. Srsly? Disinterest in spoon feeding people who sound like wanna-be thieves who thefts would scare ordinary people away from Bitcoin and whom can't even be bothered to RTFM (there has been fairly detailed documentation for the library for years) is not evidence of a lack of interest in further development.
My dear young gmaxwell: Evidently, after you did the diligent work opening a PR , benchmarked the code in the process, reformatting it for the worse, but reordering it for the better, found out and stated that my code is about 6-7 orders of magnitude faster than the original code (and I am not primarily a C hacker) ... you have the guts to use the term "wanna-be" when addressing any of your texts towards me? Let alone the fact that there was such a tremendously suboptimal code for such a long time should teach you something. Let me assure you, your perception of the situation here is skewed at best. From what I see in the secp256k1 lib, the collective who did the job are good programmers with potential. Motivated, young, inexperienced, but potential. If it wasn't for the LBC hobby project of mine, I would have never had looked in the mess that is the secp256k1 library. I did and I commented. You don't like the comment, maybe feel it being insulting, puzzling or absurd. Fine. I have high hopes that before you are in your mid-40ties you will understand what my comment was about. As I said: "potential". Rationalizing the poor state of an open source project is something I came across in the Linux world since the 90ties. To me, your statements are neither new nor original. So should you - some day - come to the conclusion that you could attract a certain kind of programmers when the open source software reaches a certain kind of quality, it'd be swell. Let me tell you it's not about "spoon feeding people who sound like wanna-be thieves". It's about preparing the ground for people who may have twice your experience and otherwise scoff at the project. No offence - ofc. Rico |
|
|
|
Yay! Thanks to LBC I had the motivation to look into the secp256k1 lib and could make two subroutines faster by 6 to 7 orders of magnitude (that's 1 to 10 million times faster) https://github.com/bitcoin-core/secp256k1/pull/437field_get_b32: min 0.647us / avg 0.666us / max 0.751us
field_set_b32: min 0.551us / avg 0.571us / max 0.624us
becomes
field_get_b32: min 0us / avg 0.0000000477us / max 0.000000238us
field_set_b32: min 0us / avg 0.0000000238us / max 0.000000238us
So some day your dear bitcoin client will be faster thanks to this. Seems I was wrong and secp256k1 hackers actually are interested in improving secp256k1, which motivates me to look at some other parts of secp256k1 where I sense more code smell... If only the docs were better (a.k.a. existent), I could spend more time on code than doing detective work. Rico |
|
|
|
oooook ich habe den fehler selbst gefunden.
aber wo finde ich den found ordner?
-c 3 gell? Es gibt keinen found Ordner. Im Verzeichnis "collider" - oder halt entsprechend "in dem Verzeichnis in dem sich das LBC Skript befindet", erscheint bei Fund eine Datei FOUND.txt. Einfach mal im Verzeichnis collider > ls -al eingeben. Bei mir ist ein bischen mehr da, aber sind ja auch development Geschichten. # ls -al
total 204
drwxr-xr-x 3 root root 4096 Oct 10 11:35 .
drwxr-xr-x 7 root root 4096 Jan 6 22:33 ..
-rw-r--r-- 1 root root 118 Oct 2 13:19 FOUND.txt
-rwxr-xr-x 1 root root 92 Sep 28 10:58 hook-end.sh
-rwxr-xr-x 1 root root 164 Sep 28 10:58 hook-error.sh
-rwxr-xr-x 1 root root 34 Sep 28 10:58 hook-find.sh
-rwxr-xr-x 1 root root 164 Sep 28 10:58 hook-start.sh
-rwxr-xr-x 1 root root 1278 Oct 9 22:34 janitor.pl
-rwxr-xr-x 1 root root 62156 Oct 9 22:48 LBC
-rw-r--r-- 1 root root 43665 Sep 28 11:05 LBCdiag.txt
-rwxr-xr-x 1 root root 279 Oct 9 22:34 make_blf
-rwxr-xr-x 1 root root 2544 Sep 24 22:12 make_dist
-rw-r--r-- 1 root root 9568 Sep 18 20:17 README.txt
-rwxr-xr-x 1 root root 6104 Oct 9 22:34 sh.common
-rwxr-xr-x 1 root root 30235 Oct 9 22:34 sh.platform
drwxr-xr-x 4 root root 4096 Oct 9 22:48 .svn
Mal schauen was in der FOUND.txt drin ist... # cat FOUND.txt
f0225bfc68a6e17e87cd8b5e60ae3be18f120753:c:(hex)priv:0000000000000000000000000000000000000000000000000000122fca143c05
Kleine Notiz am Rande - gegenwärtig ist der Pool bei 0000000000000000000000000000000000000000000000000000db1d53800000 Rico |
|
|
|
huhu,
ich neheme an die found datei wird erst erstellt wenn etwas
gefunden wird oder?
lg
Ja. Genau genommen FOUND.txt Wenn Du ein LBC -x gemacht hast, dann müsste auch eine erstellt worden sein, denn da findet er ja beim testen 4 hits. Er sagt dann auch "You might want to delete FOUND.txt..." damit man nicht jedesmal einen Herzkasper bekommt wenn die Datei da ist. Rico |
|
|
|
Benchmark info not found - benchmarking... 'gen-hrdcore-sse42-linux64' not found/executable.
You could also try ./LBC -u which should perform a couple of auto-updates. If all fails, there is still the manual way. LBC has recognized the sse4.2 generator to be best for your CPU, so you can: - go to http://ftp://ftp.cryptoguru.org/LBC/generators/
- fetch the newest one with sse42 in it (170105-5aef41bea5c64dbf8c977195b67ba796.gen-hrdcore-sse42-linux64.bz2 as of now)
- bunzip2 it
- rename it to gen-hrdcore-sse42-linux64
- make sure it's executable
Rico |
|
|
|
What function do you use in your program?
secp256k1_gej_add_ge_var, and mainly in a descendant of the secp256k1_ecmult_gen2 function from here: https://github.com/ryancdotorg/brainflayer/blob/master/ec_pubkey_fast.cWhich - meanwhile - looks like this in my code: 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_set_ge(&o1, &prec[2560 + seckey[21]]);
secp256k1_gej_add_ge_var(&s6, &o1, &prec[2816 + seckey[20]], NULL);
secp256k1_gej_set_ge(&o1, &prec[3072 + seckey[19]]);
secp256k1_gej_add_ge_var(&s7, &o1, &prec[3328 + seckey[18]], NULL);
secp256k1_gej_set_ge(&o1, &prec[3584 + seckey[17]]);
secp256k1_gej_add_ge_var(&s8, &o1, &prec[3840 + seckey[16]], NULL);
secp256k1_gej_set_ge(&o1, &prec[4096 + seckey[15]]);
secp256k1_gej_add_ge_var(&s9, &o1, &prec[4352 + seckey[14]], NULL);
secp256k1_gej_set_ge(&o1, &prec[4608 + seckey[13]]);
secp256k1_gej_add_ge_var(&s10, &o1, &prec[4864 + seckey[12]], NULL);
secp256k1_gej_set_ge(&o1, &prec[5120 + seckey[11]]);
secp256k1_gej_add_ge_var(&s11, &o1, &prec[5376 + seckey[10]], NULL);
secp256k1_gej_set_ge(&o1, &prec[5632 + seckey[9]]);
secp256k1_gej_add_ge_var(&s12, &o1, &prec[5888 + seckey[8]], NULL);
secp256k1_gej_set_ge(&o1, &prec[6144 + seckey[7]]);
secp256k1_gej_add_ge_var(&s13, &o1, &prec[6400 + seckey[6]], NULL);
secp256k1_gej_set_ge(&o1, &prec[6656 + seckey[5]]);
secp256k1_gej_add_ge_var(&s14, &o1, &prec[6912 + seckey[4]], NULL);
secp256k1_gej_set_ge(&o1, &prec[7168 + seckey[3]]);
secp256k1_gej_add_ge_var(&s15, &o1, &prec[7424 + seckey[2]], NULL);
secp256k1_gej_set_ge(&o1, &prec[7680 + seckey[1]]);
secp256k1_gej_add_ge_var(&s16, &o1, &prec[7936 + seckey[0]], 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);
}
I am highly dissatisfied with the code and the runtime still. All I managed by the tree-addition was to spare myself one secp256k1_gej_add_var call. All this EC arithmetic looks so clumsy... I'll probably try to find some more efficient way how to form the sum of N secp256k1_gej values. Rico |
|
|
|
Hi, Bekommst DU als Betreiber der Infrastruktur dahinter auch eine Info über den Fund? Und zweigst die ggf. gefundenen Coins dann auf eine separate Adresse ab, auf der sich dann der Besitzer bei dir melden soll?
Oder bekommt der Finder an sich, der die Computingpower zur Verfügung stellt, die Adresse und priv. Key zur eigenen Verwendung?
Alles in der Doku beschrieben und 100x diskutiert: https://lbc.cryptoguru.org/man/theory#the-case-for-fundsinsbes: Clearly, this approach is not feasible, because the overhead for doing that would use a multiple times the ressources as if you had a single client working on the task. So this approach would render the whole problem unparallelizable. bzw: https://bitcointalk.org/index.php?topic=1573035.msg16182353#msg16182353There is no way the server could keep up with the generated private keys. All PK generation and checking occurs on the client and after the client has checked the keys, they are discarded. All the server does is distributing chunks of work to the clients, receiving ACKs for work done and performing multi-interval arithmetic to ensure nothing is left out and nothing is done (unnecessarily) twice.
The main reason for the offline processing is speed and scalability - of course. But I also like to leave the decision what to do with a PK found in the clients hands to not get involved in case the client decides to ... hmm ... reward himself. Google translate oder der freundliche Forumsnachbar von nebenan helfen. Prinzipiell könnte der eine zentrale Server niemals mit den generierten Keys Schritt halten. Für den Fall jemand glaubt der Client wird im Falle eines Fundes irgendwie von Server gesteuert: https://lbc.cryptoguru.org/about#how-do-i-know-the-pool-doesn-t-scam-me-Einfach Kabel rausrupfen und manuell einen Bereich eingeben wo man garantiert was findet. Fund wird angezeigt, FOUND.txt wird erzeugt. Rico |
|
|
|
ja juhuu super vielen dank für die hilfe.
aber was ist wenn ich es verpasse?
ich sitze ja nicht die ganze zeit vorm pc
Natürlich schreibt er seinen Fund auch in eine Datei namens FOUND.txt - geht also nix verloren. Für die Fortgeschrittenen gibt es dann hooks: https://lbc.cryptoguru.org/man/user#hooksDa kann man sich dann selbst was schreiben was er tun soll im Findungsfall. :-) Das kann vom Rumgepiepe bis zum Mailversand eigentlich alles sein. Rico |
|
|
|
|
Show Posts
