Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[willi9974]

Jetzt hast du es geschafft mein Interesse zu wecken :-)

Kannst Du etwas über den Blockparser sagen?

- wie geht das?
- brauch ich dazu einen BTC Core Node?
- kann man den Blockparser (2 Mio Adressen in einer Sekunde abfragen) auf Windows installieren?

Wie bist Du vorgegangen / wie geht das / etc.
Kannst Du dazu was sagen, das würde mich sehr interessieren...

PS: Gerne auch per PM / Mail oder WhatsApp....

Viele Grüße
Willi

[1714095284]

1714095284

[1714095284]

1714095284

[1714095284]

1714095284

[rico666]

Der blockparser ist nicht von mir.

Was er macht ist folgendes: Er geht die blockchain durch (man braucht diese also lokal) und gibt eine Liste der Adressen mit Funds aus. Die sieht dann ungefähr so aus:

Code:

---------------------------------------------------------------------------
          State of the ledger at block 425733 (minted : Thu Aug 18 12:39:39 2016)
---------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
              Balance                      Hash160                             Base58                  nbIn        lastTimeIn          nbOut        lastTimeOut
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
         140955.81971855 e95dbb25283cc35d4a6aefa76c0382e63ce0fa36 3Nxwenay9Z8Lc9JBiywExpnEFiLp6Afp8v     67 Sat Aug 13 14:47:06 2016      15 Thu Aug  4 17:39:49 2016
          83553.31541517 b3b9f5025c397c07e7e37db7e5c9259ac95cd344 3J5KeQSVBUEs3v2vEEkZDBtPLWqLTuZPuD    441 Fri Aug 12 02:23:15 2016     301 Thu Aug 11 03:26:25 2016
          79957.11605233 a0b0d60e5991578ed37cbda2b17d8b2ce23ab295 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF     88 Fri Jul 29 02:50:12 2016       0 Thu Jan  1 00:00:00 1970
          78172.33497629 c5464169a9aabad0e361ccf1d436d3e843708e7d 3Kg7Cmooris7cLErTsijq6qR1FH3cTiK2G  20889 Sun Jul  3 15:23:05 2016       4 Tue May 17 17:14:55 2016
          69370.10526197 b3dd79fb3460c7b0d0bbb8d2ed93436b88b6d89c 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx     66 Fri Aug 12 02:23:15 2016       1 Thu Apr 23 14:10:25 2015
          66650.59620465 3d03002dbed5cb1dc10fc6bcb0886d2df32f2838 16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt    168 Fri Apr 29 10:29:14 2016       0 Thu Jan  1 00:00:00 1970
          66583.22391617 cd4b7b8f9db1b0c709fd0c9f0534fca6a9f40495 1KiVwxEuGBYavyKrxkLncJt2pQ5YUUQX7f    120 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
          66452.06624862 f9e6bbcdc83d8f351014e07495f386fe1067ec7b 1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK    114 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
          66378.80961189 6a6015e3793207af6dff7c48ee9e193d73547cdc 1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR    181 Thu Feb 18 17:09:28 2016       0 Thu Jan  1 00:00:00 1970
          66235.82427687 8b70193546504fa3623598722575f70b5b1c6455 1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa    125 Sat Feb 13 06:40:01 2016       0 Thu Jan  1 00:00:00 1970
...

Der Aufruf (bei mir) ist

Code:

./parser allBalances -w 17000000 > allBalances2.txt

Der LBC client kann entweder diese Liste direkt parsen (langsam), oder aber er legt ein Storable (binary blob des Hashes) ab und benutzt das.
Naja und einen Wert abfragen ob er in einem Hash (assoziatives Array) ist, ist in so ziemlich jeder Programmiersprache trivial.

Wie gesagt, aktualisiere ich diese Daten von Zeit zu Zeit. Da das ca. 20GB Speicher braucht, mache ich das auf einem Server von mir und die Clients bekommen bereits das geparste aufbereitete Datenhäppchen.

Mit Windows kenne ich mich überhaupt nicht aus - ich weiß höchstens wie man ein Spiel startet. Zum Arbeiten benutze ich normalerweise richtige Betriebssysteme.

Rico

[rico666]

Mit Windows kenne ich mich überhaupt nicht aus - ich weiß höchstens wie man ein Spiel startet. Zum Arbeiten benutze ich normalerweise richtige Betriebssysteme.

Nichtsdestotrotz gibt es nun Windows clients für 64 und 32bit Systeme (http://lbc.cryptoguru.org:5000/download)

Bei mir stürzen diese zwar nach einer Weile ab  bei den Betatestern jedoch nicht, also bitte: wer probieren mag, probiere.
Einen kleinen Nachteil haben die Windows-Clients gegenüber den linux-Clients: sie benötigen mehr Speicher.

Pro CPU Thread braucht die 64bit Windows Version ca. 3.5GB (Linux: 1.9GB). Sorry, geht momentan nicht besser.
Das ist eben der Preis für den offline-Balancecheck (= Speed).

Bei Problemen gibt es nun auch eine Diagnosefunktion (LBC --info), die Daten benötige ich, wenn ich auf Bugsuche gehen soll.


Rico

[cagrund]

Jepp, bei mir das selbe Problem. Der Download-Link für die WIN-Versionen zeigt in's nix ... 

Gruß Carsten.

[rico666]

Jepp, bei mir das selbe Problem. Der Download-Link für die WIN-Versionen zeigt in's nix ... 

Öööh ... tralala 

War ein Intelligenztest für die Windows-User.  Ich habe den jetzt abgeschaltet.


Rico

[curiosity81]

Halte ich fuer aussichtslos. Auch, weil Du naemlich auf ein bewegliches Ziel schiesst. Was heute Adressen mit nonzero Balance sind, dass sind sie in 10 Jahren nicht notwendigerweise mehr. Bzw. wenn Du den Suchraum zu x% mit negativem Ergebnis abgegrast hast, ist dann in den x% vllt nach Abschluss schon eine nonzero Balance enthalten. Da Du das  (2^160 Privatekeys) nicht abspeichern kannst so entgeht Dir das.

[rico666]

Halte ich fuer aussichtslos. Auch, weil Du naemlich auf ein bewegliches Ziel schiesst. Was heute Adressen mit nonzero Balance sind, dass sind sie in 10 Jahren nicht notwendigerweise mehr. Bzw. wenn Du den Suchraum zu x% mit negativem Ergebnis abgegrast hast, ist dann in den x% vllt nach Abschluss schon eine nonzero Balance enthalten. Da Du das  (2^160 Privatekeys) nicht abspeichern kannst so entgeht Dir das.

Kurze Zwischenfrage: Wie oft wurden Satoshis Bitcoins seit 2009 bewegt? Zumindest im Suchraum des Pools können diese "abgehakt" werden.

Nächste Frage: Was ist mit all den Adressen zu denen die Keys verschwunden/verloren sind? Oder auf irgendeiner englischen Mülldeponie liegen? Welch' beweglich Ziel geben die ab?

Wer sagt ich kann keine 2^160 Privatkeys abspeichern? 
https://bitcointalk.org/index.php?topic=1587485.0


Rico

[curiosity81]

Halte ich fuer aussichtslos. Auch, weil Du naemlich auf ein bewegliches Ziel schiesst. Was heute Adressen mit nonzero Balance sind, dass sind sie in 10 Jahren nicht notwendigerweise mehr. Bzw. wenn Du den Suchraum zu x% mit negativem Ergebnis abgegrast hast, ist dann in den x% vllt nach Abschluss schon eine nonzero Balance enthalten. Da Du das  (2^160 Privatekeys) nicht abspeichern kannst so entgeht Dir das.

Kurze Zwischenfrage: Wie oft wurden Satoshis Bitcoins seit 2009 bewegt? Zumindest im Suchraum des Pools können diese "abgehakt" werden.

Dann gilt aber nicht mehr das Argument, dass du den Suchraum stark verkleinern kannst, weil Du ja nur (!) einen PK mit Adresse mit positiver Balance finden musst. Hingegen musst Du exakt einen PK erwuerfeln, welcher die Satohsi-Adresse ergibt.

Nächste Frage: Was ist mit all den Adressen zu denen die Keys verschwunden/verloren sind? Oder auf irgendeiner englischen Mülldeponie liegen? Welch' beweglich Ziel geben die ab?

Keins, aber diese Adresse ergeben praktisch einen konstanten Faktor in Deiner Rechnung, und dessen Einfluss ist zu gering um das Problem stark zu vereinfachen (Behaupte ich jetzt mal einfach so). Auch wenn dieser Faktor theoretisch nicht konstant ist, so nehmen die Betraege auf den Adressen mit der Dauer, die Bitcoin existiert, ab. D.h., auch wenn sich die Wahrscheinlichkeit erhoeht, solch eine Adresse zu finden, ist der Gewinn vernachlaessigbar.

Wer sagt ich kann keine 2^160 Privatkeys abspeichern? 
https://bitcointalk.org/index.php?topic=1587485.0

Ich! Selbst wenn im Schnitt ein PK nur ein Byte ausmacht, und das ist sehr optimistisch gerechnet, dann brauchst Du 2^160 Bytes = 1.5*10^48 Bytes. Um das in Relation zu setzen:

Ein Mol enthaelt 6.022*10^23 Teilchen, was exakt 12 g Kohlenstoff C12 entspricht. Nimm das im Quadrat, also 6.022*10^23 Mol Kohlenstoff und Du hast in etwa 10^25 g = 10^22 kg Kohlenstoff C12 (~3.6*10^47 Teilchen). Der Mond wiegt etwa 10^23 kg (grob = 3.6*10^47*10 Teilchen). D.h. Du muesstest jedes Kohlenstoffatom anfassen, welches im Erdmond enthalten ist, wenn dieser aus Kohlenstoff C12 bestehen wuerde (und Kaese ist bekanntlich zum Grossteil Kohlenstoff). Zmdst in der Groessenordnung (ich habe uebrigens sehr generoes gerundet).

[rico666]

Dann gilt aber nicht mehr das Argument, dass du den Suchraum stark verkleinern kannst, weil Du ja nur (!) einen PK mit Adresse mit positiver Balance finden musst. Hingegen musst Du exakt einen PK erwuerfeln, welcher die Satohsi-Adresse ergibt.

Du - wir sind hier nicht im Heise-Forum. Die Beiträge sollten schon einen Mindest-Qualitätsstandard erfüllen.  

Das Argument mit dem verkleinerten Suchraum ergibt sich aus dem SHA256->RIPEMD160 Tandem und der Tatsache, dass RIPEMD160 durch folding (im mathematischen Sinn) bewirkt, dass wir pro öffentliche Adresse plusminus 2⁹⁶ private Keys haben.

Da ist es erstmal unerheblich, ob wir nur einen PK oder 10 mio PK suchen wollen, denn diese ergeben - wie Du unten fast richtig ausführst - einen konstanten Faktor (eigtl. Divisor, aber ja 1/Faktor). Der ist 10⁷ (ca. 2²³), also ist der Suchraum "nur" 2¹³⁷ groß bis man "etwas" findet.

So lange man noch nicht 50% des Suchraums abgearbeitet hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" geschieht natürlich geringer, als die Wahrscheinlichkeit, dass etwas "vor einem" geschieht. Wenn sich aber die Bitcoin-Community nicht malevolent gegen einen verschworen hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" auftaucht sogar noch geringer als 50%, da es ja die immobilen Bitcoin Adressen gibt (verloren, DontSendBitcoinEater..., Satoshi etc.). Im übrigen werden Satoshi ca. 1 mio BTC zugerechnet, die natürlich nicht auf einer Adresse liegen.

... so nehmen die Betraege auf den Adressen mit der Dauer, die Bitcoin existiert, ab. D.h., auch wenn sich die Wahrscheinlichkeit erhoeht, solch eine Adresse zu finden, ist der Gewinn vernachlaessigbar.

Gewinn? Ich verstehe nicht, was Du sagen willst.

Ich! Selbst wenn im Schnitt ein PK nur ein Byte ausmacht, und das ist sehr optimistisch gerechnet, dann brauchst Du 2^160 Bytes = 1.5*10^48 Bytes.

Nochmal: Und im Heise-Forum regt man sich auf, wenn die Meldung kommt, deutsche Programmierer seien nur Mittelfeld...  

Um das in Relation zu setzen:

Ein Mol enthaelt 6.022*10^23 Teilchen, was exakt 12 g Kohlenstoff C12 entspricht. Nimm das im Quadrat, ...  und Du ... muesstest jedes Kohlenstoffatom anfassen, welches im Erdmond enthalten ist, wenn dieser aus Kohlenstoff C12 bestehen wuerde (und Kaese ist bekanntlich zum Grossteil Kohlenstoff). Zmdst in der Groessenordnung (ich habe uebrigens sehr generoes gerundet).

Seit wann sind (12g)² der Mond?  


Rico

[curiosity81]

Dann gilt aber nicht mehr das Argument, dass du den Suchraum stark verkleinern kannst, weil Du ja nur (!) einen PK mit Adresse mit positiver Balance finden musst. Hingegen musst Du exakt einen PK erwuerfeln, welcher die Satohsi-Adresse ergibt.

Du - wir sind hier nicht im Heise-Forum. Die Beiträge sollten schon einen Mindest-Qualitätsstandard erfüllen.  

Das Argument mit dem verkleinerten Suchraum ergibt sich aus dem SHA256->RIPEMD160 Tandem und der Tatsache, dass RIPEMD160 durch folding (im mathematischen Sinn) bewirkt, dass wir pro öffentliche Adresse plusminus 2⁹⁶ private Keys haben.

Da ist es erstmal unerheblich, ob wir nur einen PK oder 10 mio PK suchen wollen, denn diese ergeben - wie Du unten fast richtig ausführst - einen konstanten Faktor (eigtl. Divisor, aber ja 1/Faktor). Der ist 10⁷ (ca. 2²³), also ist der Suchraum "nur" 2¹³⁷ groß bis man "etwas" findet.

So lange man noch nicht 50% des Suchraums abgearbeitet hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" geschieht natürlich geringer, als die Wahrscheinlichkeit, dass etwas "vor einem" geschieht. Wenn sich aber die Bitcoin-Community nicht malevolent gegen einen verschworen hat, ist die Wahrscheinlichkeit, dass etwas "hinter einem" auftaucht sogar noch geringer als 50%, da es ja die immobilen Bitcoin Adressen gibt (verloren, DontSendBitcoinEater..., Satoshi etc.). Im übrigen werden Satoshi ca. 1 mio BTC zugerechnet, die natürlich nicht auf einer Adresse liegen.

... so nehmen die Betraege auf den Adressen mit der Dauer, die Bitcoin existiert, ab. D.h., auch wenn sich die Wahrscheinlichkeit erhoeht, solch eine Adresse zu finden, ist der Gewinn vernachlaessigbar.

Gewinn? Ich verstehe nicht, was Du sagen willst.

Ich! Selbst wenn im Schnitt ein PK nur ein Byte ausmacht, und das ist sehr optimistisch gerechnet, dann brauchst Du 2^160 Bytes = 1.5*10^48 Bytes.

Nochmal: Und im Heise-Forum regt man sich auf, wenn die Meldung kommt, deutsche Programmierer seien nur Mittelfeld...  

Um das in Relation zu setzen:

Ein Mol enthaelt 6.022*10^23 Teilchen, was exakt 12 g Kohlenstoff C12 entspricht. Nimm das im Quadrat, ...  und Du ... muesstest jedes Kohlenstoffatom anfassen, welches im Erdmond enthalten ist, wenn dieser aus Kohlenstoff C12 bestehen wuerde (und Kaese ist bekanntlich zum Grossteil Kohlenstoff). Zmdst in der Groessenordnung (ich habe uebrigens sehr generoes gerundet).

Seit wann sind (12g)² der Mond?  


Rico

Ok, offensichtlich mal wieder der Dunning-Kruger-Effekt. Ich spreche im ersten Satz von Teilchen, im zweiten von Gramm: 12g*(6*6*10^23*10^23). Klingelts jetzt?

Du disqualifiziert Dich gerade selbst als Gespraechspartner, insbesondere weil Du nicht genau liest.

Bye und viel Spass beim Strom verbraten.

[rico666]

Ok, offensichtlich mal wieder der Dunning-Kruger-Effekt. Du disqualifiziert Dich gerade selbst als Gespraechspartner.

(10^23)^2 sind 10^46. Der Rest ist trivial.

Bye und viel Spass beim Strom verbraten.

Ach komm - sei keine Memme. Und der reineditierte DK ist auch ganz nett.

Nur weil man Dir in anderen Foren den Dunning-Kruger um die Ohren gewatscht hat, musste den nicht bei jeder Gelegenheit selbst rausholen.
So hätte ich die "Diskussion" (eigtl. Tutorial) ja schon bei Deiner ersten Einlassung beenden können.

Ich schlage einfach vor, Du lernst noch etwas über Datenstrukturen. Kannst ja mal bei Tries, Bloom Filtern, Golomb-Kodierung u.ä. anfangen.
Wenn Du etwas nicht kapierst, kannst Du mir gerne eine PM senden, ich erkläre Dir das dann.


Rico

[rico666]

Bis jetzt noch keine Adresse gefunden wo was drauf ist --> ca. 10 Mio Adressen wurden geprüft

Der Pool prüft derzeit 5 Mrd. Adressen die Stunde... mit im Schnitt 3-4 aktiven Clients. 

10mio Adressen hat mein Notebook derzeit in 25 Sekunden durch. Ich wünschte, ich würde mich besser in OpenCL oder CUDA auskennen. Die GPU im Notebook macht bei oclvanitygen 15MKeys/s - theoretisch sollte ich dadurch noch einen Speedup von ca. 30 hinbekommen.


Rico

[willi9974]

Respekt!

Vielleicht teste ich deinen Windows Client auch mal.
Ist der auf Basis von Perl?
Kann ich da den Quellcode einsehen oder ist das mit Perl2EXE in eine Exe Datei umgewandelt.
Ich lass auf meinen BTC Rechner keinen Software laufen die ich nicht kenne...

Viele Grüße
Willi

[rico666]

Ist der auf Basis von Perl?

Perl ist sozusagen der Kleber, der die Kommunikation mit dem Server übernimmt und den/die Generatoren steuert.
Der Generator selbst ist compiliertes Go. Die ursprünglichen Sourcen sind hier: https://github.com/saracen/bitcoin-all-key-generator
Aber mittlerweile habe ich den arg getrimmt/modifiziert.

Die Windows-Version macht mich aber nicht so glücklich. Braucht elend viel (mehr) Speicher und scheint auch nicht so stabil zu sein.

edit: genau genommen stürzt sie zuverlässig ab, wenn man mehr als eine CPU auslasten will. (-c x für x > 1) Workaround: in mehreren
Fenstern einfach "perl LBC -c 1 -t 1" starten, so oft wieviele CPUs (oder Speicher) man hat/nutzen will.

Den Perl Source kann man im Editor ansehen

Code:

#!/usr/bin/env perl

use
strict;
use
warnings;

use
bignum
lib =>
'GMP';
use
utf8;

use
Config;
use
Data::Dumper;
use
Digest::MD5
qw(md5_hex);
_use_eval_cpan(
'File::Spec'
)
;
.... snipp (geht natürlich noch weiter)

Muss man zwecks besserer Lesbarkeit evtl. mit perltidy drüberhuschen.

Kann ich da den Quellcode einsehen oder ist das mit Perl2EXE in eine Exe Datei umgewandelt.
Ich lass auf meinen BTC Rechner keinen Software laufen die ich nicht kenne...

Das ist sehr vernünftig, allerdings muss die Software nicht auf einem "BTC Rechner" laufen. Da wird keine Blockchain, Wallet o.ä. benötigt.

Momentan probiere ich aus den Client auf einer kostenlosen Amazon-Instanz laufen zu lassen. Die help bekomme ich angezeigt. Aber die EC2 t2.micro kisten haben nur 1GB RAM...

Code:

[ec2-user@ip-xx-xxx-xx-xxx ~]$ sudo ./LBC -c 1 -t 60
Benchmark info not found - benchmarking... done.
Reading balances... storable found - using that (faster)... Out of memory!

Mal schauen ob mir da was einfällt...


Rico

[rico666]

Vielleicht teste ich deinen Windows Client auch mal.

Ist keine offizielle Release, aber endlich die erste Win version, die stabil läuft.

http://62.146.128.45//download/LBC-0.827_w64.zip

Braucht sogar nicht mehr Speicher als die Linuxversion FALLS man nur eine CPU pro Prozess nutzt.

Also

perl LBC -c 1 -t 600

notfalls halt in mehreren Fenstern eingeben, dann laufen eben x LBC prozesse, von denen jeder eine CPU nutzt.
Das ist überhaupt kein Problem, der Server kommt mit sowas klar.

Wenn man -c 3 oder so eingibt, läuft es zwar immer noch stabil, aber die Speicherhölle geht los.
Also: zweimal LBC -c 1 starten ist wesentlich schonender als einmal LBC -c 2

edit: mindestens zwei Win clients haben die ganze Nacht über Daten geknuspert und sind ohne Probleme durchgelaufen. 

Rico

[dArkjON]

Vielleicht Blöde Fragen, aber habt Ihr schonmal ein Wallet gefunden ?
Was passiert dann mit den Coins ?  und ist es am Ende nicht "Diebstahl" eine Key Kombination zu "erraten" und dann die Coins zu entführen ?

Freu mich auf eine Antwort !

[dArkjON]

Was passiert dann mit den Coins ?  und ist es am Ende nicht "Diebstahl

...na ja: werden Passende Paaren gefunden, dann werden nur Rechnungseinheiten (nach Bafin) auf eine andere Adresse verschoben, ist also kein Diebstahl HA, Ha, ha

Was ich mich eher Frage, ist so ein Netzwerk nicht eigentlich eine "Selbstzerstörung" des Coin Netzwerkes ?
Wenn alle Cold Wallets gefunden wurden und alle Paperwallets geleert sind, wo lagern die Pool Betreiber Ihr Coins dann sicher ?

Sicherlich ist die vorhandene Rechenleistung nicht ausreichend dafür, sowas kann sich aber schnell ändern...

[fronti]

Was passiert dann mit den Coins ?  und ist es am Ende nicht "Diebstahl

...na ja: werden Passende Paaren gefunden, dann werden nur Rechnungseinheiten (nach Bafin) auf eine andere Adresse verschoben, ist also kein Diebstahl HA, Ha, ha

Was ich mich eher Frage, ist so ein Netzwerk nicht eigentlich eine "Selbstzerstörung" des Coin Netzwerkes ?
Wenn alle Cold Wallets gefunden wurden und alle Paperwallets geleert sind, wo lagern die Pool Betreiber Ihr Coins dann sicher ?

Sicherlich ist die vorhandene Rechenleistung nicht ausreichend dafür, sowas kann sich aber schnell ändern...

wenn man eine solche menge an Daten spiechern und auch wieder Effektiv durchsuchen kann, dann hat nicht nur bitcoin probleme.
alleine die Energie die man dann aus den Sternensystemen abzeihen müsste um eine Suche zu starten reicht vermutlich um damit ein paar schwarze Löcher zu erstellen..

[rico666]

Bei mir läuft Version 0.827 auf Windows wesentlich besser als die älteren Versionen.

Ich habe mir zum starten einfach folgendes Batch-Script erstellt:

Code:

@echo off
cd %userprofile%\Desktop\LBC-client
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1

Nice.

Mittlerweile gibt es jedoch version 0.832 und die verlangt der Server auch. Leider leider war die Windows-version zwar stabil, hat aber nicht alle hash160 gefunden die sie sollte...
Lange Geschichte, könnte man nun breittreten wer der größere Idiot ist - ob ich oder Windows. Belassen wir es dabei, dass jetzt der Windows client tatsächlich belastbar ist.

Zu dem obigen Skript habe ich folgenden Verbesserungsvorschlag. Der Client ist nun wirklich stabil und mit -c 1 sind schon etliche Win clients mehr als 48h durchgelaufen.
-t 1 ist daher überflüssig. Ich würde es mit folgenden Zeiten probieren:

Code:

@echo off
cd %userprofile%\Desktop\LBC-client
start perl LBC -c 1 -t 3600
start perl LBC -c 1 -t 1100
start perl LBC -c 1 -t 600
start perl LBC -c 1 -t 60

Ist ein kleiner Geheimtipp, weil dann finden einige der Windows Clients "Löcher" in den Intervallen, die einem fetten -c 20 -t 3600 linux client entgehen... 


Rico

[rico666]

Ich hätte da aber noch ein Angliegen...

Da zumindest ich und eventuell auch andere eine schwache Internetleitungen haben, wäre es möglich das Zip Paket auch ohne "balances.pst" hochzuladen?

Wäre schön, wenn du das umsetzten könntest.

Das gibt's aber schon immer:

http://62.146.128.45/download/LBC-client/LBC
http://62.146.128.45/download/LBC-client/gen-gocpu-linux64
http://62.146.128.45/download/LBC-client/gen-gocpu-linux32
http://62.146.128.45/download/LBC-client/gen-gocpu-windows64.exe
http://62.146.128.45/download/LBC-client/gen-gocpu-windows32.exe


Außer dem LBC hat sich nix geändert, folglich reicht der erste link und sind magere 17kB. Halt das alte LBC damit ersetzen.


Rico