Tja ... Fortschritt ist unaufhaltsam. Der aktuelle Generator macht - zumindest auf meinem Notebook - 0.5 mio keys (= 1 mio Adressen) pro Sekunde pro CPU Kern. Der nächste Generator dann 1 mio Keys (= 2 mio Adressen) pro Sekunde. Damit ist dann nach aktuellem Kenntnisstand so ziemlich das Ende der CPU-Fahnenstange erreicht. Folglich werden wir uns dann GPU Generatoren zuwenden, erste Bemühungen in der Richtung gibt es bereits. Also wenn es einer hinbekäme, mir oclvanitygen so zurechtzubiegen, dass der output identisch zum derzeit verwendeten generator ist und da zumindest die 2 mio adressen pro Sekunde rausploppen... dafür wäre ich bereit BTCs auf den Tisch zu legen.
Ich zahle 1 BTC, wenn ich bis Ende Oktober ein OpenCL oder CUDA Programm bekomme, das - vergleichbare Performance zu oclvanitygen (nicht weniger als 90% der oclvanitygen-Performace) bietet
- in einem per CLI definierten Bereich PKs inkrementell zu compressed und uncompressed hash160 berechnet
- diese hash160 gegen einen bloom filter oder assoziatives array von mind 10 mio hash160 abgleicht
Rico |
|
|
|
Work of a whole day gone
500 Can't connect to 62.146.128.45:5000
The work is not entirely gone (for you), as your client checked the (manually given) range, so you know the result of something being in there or not. It's just that on communication with the server, the server recognized the id of your client being blacklisted (there was a history) and refused connection. So in that case, the 500 was to be expected. If anything, the work is lost for the pool, but as is, it takes only PoWs of clients it trusts... Rico |
|
|
|
Working on it, documentation sucks ass for go-opencl. Might use PyOpenCL. Very documentation, much information: https://documen.tician.de/pyopencl/All I need to do is output the private key in bytes for compressed and uncompressed, correct? And in order...which is simple. You need to output the two hash160es in bytes for compressed and uncompressed public keys (of a private key which gets incremented). Well - it'd be a start, I could probably continue from there. We still would need the checking against either a bloom filter or a normal associative array of the funds be done on GPU also as the CPU couldn't keep up. Every effort counts - same as relay race. Rico |
|
|
|
If anyone knows WTF they are doing with Go and OpenCL please feel free to help, haha.
Trying to make an OCL version of LBC for teh fast.
This would be tremendous to have. And very much needed:  (screenshot courtesy of my development server)  Let me spell it out for you: https://blockchain.info/address/1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaSRico |
|
|
|
It almost seems like he is only allowing 1 connection per host.
Unfortunately, the current client is very brittle handling timeouts. If the server doesn't answer within a few seconds you get this 500. Currently new code is already in place that handles this gracefully and does 3 retries within 90 seconds. Maybe I'll make that even configurable. edit:Done. (configurable) And the sleeping is done like Ethernet anti-collision strategies: Progressive random waits. # LBC -c 1 -t 1
Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 2
Sleeping 6.965 s...
Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 1
Sleeping 19.968 s...
Problem connecting to server (500 Can't connect to 128.0.0.1:5000). Retries left: 0
500 Can't connect to 128.0.0.1:5000
I believe with this the "500" should be a thing of the past. Rico |
|
|
|
Tadaa. Fetching adequate work... got block interval [14679478-14691797]
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo80df54e1f6
12f2fc5bdc05c9d21a83aa8d20791e:c:(hex)priv:00000000000000000000000000000000000000000000000000000e02b35a358f
Rico |
|
|
|
Ich als Bauer brauche erst mal Land
...
50.000 für Strom und Benzin
...
Wer kann mir was Liefern?
...
Um Strom, Gas und Wärme zu erzeugen brauche ich noch:
Rindergülle
Maissilage
Raps
...
@dunnerjunge. Sobald die Anlage läuft kann ich Strom und Biodiesel liefern.
Deadlock. Ohne Rinderscheisse kein Strom, ohne Strom keine Rinderscheisse. Alle tot. Nochmal. Rico |
|
|
|
Currently its 200% of the ETA as declared by the client. So if the client asks for work for 10 minutes and does not deliver within 20 minutes, blocks will be reissued.
New LBC client will have slightly different time semantics. --time <duration>
Time constraint in case client is in pages 'auto' mode. This
puts an upper limit on the client runtime. Format is h:m You are
free to enter '60' for an hour instead of '1:0' If you specify a
pages interval, this option has no effect.
So no seconds anymore, as that granularity doesn't make sense. No days either. While testing the new code, I got bitten by habit  - of course: # LBC -c 4 -t 1800
Limiting work to 1 day.
Fetching adequate work... got block interval [13045018-13241689] (206225 Mkeys)
-> dammit Ctrl+C
So silly me, instead of 30 minutes, I gave it 1800 minutes and the client got a block interval for 1 day. Because I cancelled the job, it never delivered and today the server decided to reissue. While the forefront at the time of reissue was somewhere beyond block 14000000, this "1 day of work of my 4 Skylake cores" got thrown before the pack. Less than 2 hours later, it has been munched and we are at 14000000+ again.  Rico |
|
|
|
1. How long does the server allocate to a client to find a block before reissuing?
Currently its 200% of the ETA as declared by the client. So if the client asks for work for 10 minutes and does not deliver within 20 minutes, blocks will be reissued. However, if the original client still delivers them after that, they'll be accepted too. It's just that at that time another client might have done them already (double work). 2. When was the balances data created?
September 24th. The new version will fortunately have a way to incrementally update the balances data as often as it will make sense. Rico |
|
|
|
Und ja, eine Nazeige bei der Polizei erscheint mir durchaus angebracht.
Dann mach aber auch und red' nicht nur 'rum. Ratschlag: (edit) Vorher bitte noch die folgenden Sachen für illegal erklären: Am besten gleich die ganze Bitcoin-Showse für illegal erklären. Aber nur in Deutschland - bitte. Immerhin sieht das sehr stark danach aus als würde man eine Straftat vorbereiten.
Was haben wir gelacht. ... wenn es nicht so traurig wäre. Rico PS: Woran erkennt man einen deutschen Thread? Die Teilnehmer können sich nicht entscheiden ob etwas unmöglich oder illegal ist. PPS: Wer Ironie findet, darf sie behalten. |
|
|
|
Ach Chefin... Im Prinzip gehts hier also um Diebstahl
Nein. Und deswegen spare ich mir auch eine detailierte Antwort auf den Rest Deines Textes. Wäre gut, wenn Du vor dem Posten ein wenig das Hirn einschaltest. Ich weiß, ich weiß - ist heutzutage ein seltenes Ereignis in Diskussionsforen. Versuch's trotzdem. Es ist ja ok, wenn Du (oder sonstwer) das Projekt "nicht mag". Aber dann nur uninformiert rumkläffen ist auch nicht so der Bringer. In erster Näherung wäre hilfreich etwas mehr zu dem Projekt zu lesen. Vielleicht auch mal auf den einen oder anderen Link klicken, lesen, nachdenken. Z.b. bei den konkreten o.g. Adressen würde man dan feststellen, dass diese so bis #50 bereits 2015 leergeräumt wurden. Ganz offensichtlich gibt es also eine Truppe, die im Geheimen das macht (machte), was wir öffentlich vorführen. Des weiteren muss man feststellen, dass diese Adressen ganz offensichtlich mit Absicht a) so plaziert wurden b) so befüllt wurden, damit man eine Art Vorwarnsystem hat, wie sicher x bits in einem BTC Privatschlüssel sind. Beweis1: Art und Verteilung der Funds, ganz spezifische PKs (Artikel von Ryan lesen bildet) Beweis2: Obwohl die ersten 50 von den 256 bereits leergeräumt sind, werden die übrigen stehen gelassen. Egal wie man an das Geld rankommt, ihr hängt allesamt drin und glaubt mir, die IPs werden per Gericht rausgeprügelt von den Betreibern.
Ganz ehrlich: Mit dem vielen Schaum vor'm Mund, glaube ich Dir erstmal weniger. ...Chefins weitere lächerliche juristische Einschätzungen gelöscht... Also in dem Sinn: viel Spaß.
Danke. Du bist natürlich frei das Projekt bei Deiner nächstgelegenen Gendarmerie(*) zu melden. Rico (*) keine Verdauungskrankheit. |
|
|
|
EDIT: Any difference between Intel and AMD CPUs?
I had no experience with LBC on AMD, but one of the beta testers used it on AMD (250 000 keys/s per core - don't know which CPU model though). So It works evidently. Any AMD CPU that has at least a "Westmere"-similar instruction set should run fine. What specs would be the most ideal?
I observe the best performance on Skylake CPUs. Ideal seems to be: - as many physical cores as possible (use those, leave hyperthreaded cores for the OS
 ) - as high frequency as possible
- AVX2
One 2.8GHz Skylake core does over 500 000 keys/s with the avx2 version of hrd-core Rico |
|
|
|
Thanks - that works!
If I have 20 CPU core on intel E7 4870 - I will must run 20 process?
What version the Linux you recommended?
Seriously, if you have such a machine, start LBC on a Linux instance on your CPU you will get under windows ~ 25 000 keys/s, under Linux at least 300 000 keys/s - per core get this version: http://62.146.128.45/download/LBChrd-0.837_l64.tbz2If you install it in some Linux VM and give that VM X cores, give it 550MB * X + 300MB RAM. (4 cores -> 2.5GB, 8 cores -> 4.7GB etc.) If you use 8 cores on your machine, you should be able to check 2.5 mio keys per second. Which Linux version? Anything non-archaic should do. LBC requires Perl 5.16 or newer, but that has been released 2012 ( http://perldoc.perl.org/perlhist.html), so there should be no problems in any modern Linux distro. Unless you run of course Debian Wheezy - which has 5.14 A modern Ubuntu or OpenSUSE should probably be the way of least resistance. Rico |
|
|
|
Hi I have a Windows 2008R2 x64 virtualized on the vmware esxi 5.5 I try run LBC and have error: >perl c:\lbc\LBC -l 0 -c 1 -t 1:0
Unconditionally setting CPUs to 1 on Windows
Use multiple -c 1 calls instead.
No working generator executable found. If I run with any parametres in c - LBC -l 0 -c x -t 1:0 also print those message go into the LBC directory, there issue the "perl LBC -c 1 -t 60 -l 0" for your 1-shot try. LBC looks for the generator executable only in the current directory. It should work, but you should seriously consider letting this run on Linux 64bit. The Generator there is 13 times faster, uses less memory (and -c X for X > 1 is also no problem). You can ignore the "-c 1" message if you set the "-c 1" yourself. See also "Yesterdays bug"The windows client refuses now to be called with anything else than -c 1, respectively sets the number of CPUs always to 1. Unfortunately there is a small annoying message even if you set -c 1, but it's not breaking anything.
Rico |
|
|
|
Und welche Wunder vollbringt so eine teure private Bank im Gegenzug für dies hohen Kosten?!
Hat ja x3t9fi geschrieben: Es gibt deutlich mehr Freiheiten und die MA's unterstützen auch in gewissen Punkten oder geben sehr, sehr gute Auskunft... ;-)
Solche Privatbanken sind ok, aber lohnen meist nur für eine wirklich betuchtere Kundschaft. Da geht es gar nicht darum ob man nun auf der Bank 100k oder 500k hat (weil das ohnehin Beträge sind, die nur für mildes Lächeln sorgen), sondern wie "international" man sonst auch aufgestellt ist. Man hat ja dann entsprechend Wohnsitze in mehreren Ländern, dort auch sog. Assets... Wobei ich ja - die Schweizer werden es mir nicht verübeln - immer noch mehr Vaduz-Fan bin. Aber auch das ist nicht mehr was es mal war. Sogar bei den Dödeln der Deutschen Bank kommt man in eine andere Kategorie ab 2M Portfolio. Da gibt Dein persönlicher DB-Sklave dann auch ganz andere Auskunft als üblich... Mit 8,33 EUR monatlicher Grundgebühr - entfällt ab 5k Durchschnitts-Kontostand - ist es da natürlich nicht getan. Rico |
|
|
|
...does the server check for a response of some sort to confirm that a block was completely searched?
Basically yes - not a single block, but a block interval. See the green text in "Yesterdays bug"For example if I have block 50-100 and at block 60 I close my client, does the server know that my block was not completed and someone else will need to finish looking through it?
If you simply run the client in "auto" mode (as 99% of clients do), you got the block s 50-100 from the server, because the client asked the server "give me work for X cpus for Y time". This is a get_work message client -> server and at the same time a promise to finish that work. Now if you close that client as in your example, your client will not deliver at the end of the cycle a proof of work that the given interval was searched. Therefore ALL of the blocks in the promised interval are considered not having been done and will be reissued again. --- If you manually define which blocks your client should compute ( -p <from>-<to> see "Going no-auto") the server does not even know about your clients work until it finishes its self-imposed work. Only upon finishing, it delivers PoW to the server and the server will add this manual interval to the list of blocks done and also credit the client these blocks done. This is a part of the server log. The IPs and the client-Ids (except 1ff65d1e0f08af7529e9c9f0a591f263) I have changed. The timestamps and the block ranges are original. For readability I also added client name aliases. ...
1475124925 127.0.0.1 [11673395, 11674010] <<< 60b725f10c9c85c70d97880dfe8191b3 (A)
1475124926 127.0.0.1 [11692283, 11692898] >>> 60b725f10c9c85c70d97880dfe8191b3 (A)
1475125025 127.0.0.2 [11668291, 11671482] <<< 3b5d5c3712955042212316173ccf37be (B)
1475125025 127.0.0.2 [11692899, 11696090] >>> 3b5d5c3712955042212316173ccf37be (B)
1475125073 127.0.0.3 [11662369, 11663844] <<< 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125073 127.0.0.3 [11696091, 11697566] >>> 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125088 127.0.0.4 [11674011, 11674036] <<< e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125089 127.0.0.4 [11697567, 11697592] >>> e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125118 127.0.0.5 [11697593, 11698960] >>> 1ff65d1e0f08af7529e9c9f0a591f263 (rico)
...
Most of the time, we see a client delivering (<<<) pow of an interval done and immediately getting (>>>) a new interval. You can see that A gets [11692283, 11692898] after having delivered [11673395, 11674010]. Roughly 100 seconds later, B delivers [11668291, 11671482] and gets [11692899, 11696090]. As you can see it starts off where end of work for A was. Same with C and D. Last entry is my workstation, where I started up LBC at the time, so it fetches a work interval (starts where end-of work for D was) and there is no previous delivery. As mentioned in the referenced text, sometimes clients do not deliver promised work within a certain time frame, so the work will be reissued. Then there is also a global overview of blocks done, which looked today morning like that: [["0",10255010],[10255652,10292471],[10292937,10639099],[10639113,10928680],[10929361,10934248],[10934857,10964934],[10965579,10990212],[10990841,11036530],[11037955,11040222],[11040863,11086284],[11087069,11105776],[11106417,11133744],[11133759,11274716],[11274731,11392940],[11394309,11413182],[11413803,11437418],[11437471,11583428],[11583443,11718436],[11730757,11745286],[11751343,11754328],[3515625000000,3515625030841],...
You can see the pool "forefront" somewhere behind 11754328, this is where new work intervals will be reissued. The [3515625000000,3515625030841] is an interval that is the result of a manual -p where someone ran their client for a day. You can also see, there are missing intervals in there. First one 10255011-10255651. These are 640 blocks that have been not or not yet delivered back after they have been promised. If the clients who promised them will not deliver back, this range will be reissued by the server. So yes, the blocks 0 - 10255010 (the first ~ 10753157365760 keys) have been searched completely already. As the holes are getting filled, this first interval grows. Rico |
|
|
|
..schon mit 50-100k Konten eröffnen.
Das ist ja auch nicht das Problem. Ich dachte eher an die laufenden Kosten. Da füngt man nämlich mit 100k an und 1 Jahr später ist man bei 90k. Rico |
|
|
|
|
Show Posts
Natürlich wäre schneller noch schöner und daran wird ja auch gearbeitet.
