Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[rico666]

Der Large Bitcoin Colider (LBC - früher: Collision Finder Pool) ist ein Projekt zur verteilten Suche nach alternativen privaten Schlüsseln zu BTC-Adressen die mehr als 0 BTCs enthalten.

Projekt homepage: https://lbc.cryptoguru.org
Downloads: https://lbc.cryptoguru.org/download
Statistiken: https://lbc.cryptoguru.org/stats
Twitter: https://twitter.com/LBC_collider
Discord: Discord CryptoGuru #lbc

----

Der englische Thread: https://bitcointalk.org/index.php?topic=1877935.0



Rico

[1713581015]

1713581015

[1713581015]

1713581015

[willi9974]

Hab einen Miner mit 6 Karten vom Type AMD 480 die derzeit 156MHs - 158MHs ETH minen

Hier ist mein Miner
https://bitcointalk.org/index.php?topic=1581678.msg15881146#msg15881146

Was ist das für ein Projekt, mein Englisch ist nicht das beste, kannst ein paar warme Worte in deutsch darüber verlieren?

Gruß
Willi

[rico666]

Hab einen Miner mit 6 Karten vom Type AMD 480 die derzeit 156MHs - 158MHs ETH minen

Hier ist mein Miner
https://bitcointalk.org/index.php?topic=1581678.msg15881146#msg15881146

Was ist das für ein Projekt, mein Englisch ist nicht das beste, kannst ein paar warme Worte in deutsch darüber verlieren?

Ok.

Bei dem Projekt geht es im Grunde genommen darum private Keys zu finden zu Adressen auf denen Bitcoins liegen.

Das hat zunächst einmal den Aufkleber "unmöglich" und ist für mich daher genau die richtige Herausforderung.
http://directory.io/ kennst Du ja. Nun könnte man versuchen mit wget auf directory.io loszugehen, allerdings würde
- selbst wenn man eine Seite pro Sekunde abarbeitet - unsere Sonne früher verlöschen, bevor man auch nur 10^-56%
des Suchraumes abgegrast hätte.

Unsere Sonne wird nämlich in ca. 157680000000000000 Sekunden kaputt sein und bei 115792089237316195423570985008687907853269984665640564039457584007913129639936 privaten Schlüsseln und 128 davon pro Seite, sinds halt 904625697166532776746648320380374280103671755200316906558262375061821325312 Seiten.

Also muss man schneller sein. Das versucht dieses Projekt. Wie?

1) Es gibt die Möglichkeit die Keys offline zu generieren. Gegenwärtig schaffe ich mit einem (dickeren) Server 300.000 keys pro Sekunde, mithin das Äquivalent von 2343 Seiten auf directory.io pro Sekunde.

(und schon hätte ich 10^-52% des Suchraumes abgegrast bevor unsere Sonne verlöscht)

2) Nun muss man aber wissen, dass der Suchraum gar nicht 256bit ist, sondern im Schnitt nur 160bit, denn es gibt zwar 2²⁵⁶ private Schlüssel, aber diese werden auf 2¹⁶⁰ Adressen abgebildet. Daraus folgt übrigends, dass es im Schnitt pro Bitcoin Adresse 2⁹⁶ private Schlüssel gibt.

3) Dann ist es ja nicht so, dass man nach einer bestimmten Adresse sucht auf der Bitcoins liegen, sondern nach irgendeiner. Davon gibt es derzeit etwas über 9.2 Millionen.

Wollen wir mal kurz nachrechnen:

Suchraum 2¹⁶⁰ geteilt durch 9.2 * 10⁶ bedeutet ich muss 158858873622924230239530960077856849962601 Adressen abnudeln bis ich mit 100% Wahrscheinlichkeit auf eine stoße, die Bitcoins gelagert hat. Mit meinen 300k pro Sekunde brauche ich nur noch 16791272791193580906427676314 Jahre. Das mag sich nach viel anhören, aber immerhin kann ich bereits 0.00000000000939059248% des Suchraumes abhandeln bevor unsere Sonne verlöscht. Das ist gegenüber den 10^-56% von oben doch schon ein Fortschritt.

Das alles noch unter den Voraussetzungen, dass ich alleine suche und dass ich die Schlüsselgenerierung nicht beschleunigen kann. Ich möchte mit dem Collision Finders Pool eine Infrastruktur aufbauen, die diese Suche nach Kollisionen bestmöglich unterstützt. D.h. effiziente Verteilung der Suche auf möglichst viele Teilnehmer und Beschleunigung der Generierung von Adressen.

Was also steht an?

Der Pool funktioniert bereits und verteilt Suchblöcke an Clients von gegenwärtig 3 Betatestern. Die Clients nutzen momentan nur die CPU und vermutlich auch noch nicht besonders effektiv. Ich hoffe in den kommenden Tagen/Wochen

• bessere CPU clients
• wesentliche bessere GPU clients

zu bekommen. Und es ist im Übrigen Waschweiber-Gewäsch man könne ASICs (ggf. die Miner) prinzipiell nicht für so eine Aufgabe herannehmen. Gegenwärtig sind 6 x SHA256 Berechnungen notwendig pro privaten Key (compressed/uncompressed address). Wenn ich mir die Beschleunigung beim Mining ansehe, wo heutige moderne Miner um einen Faktor 1.000.000 und mehr schneller sind als die CPUs mit denen Mining angefangen wurde...

Es ist nicht abwegig, dass man 300GK/s (GigaKeys pro Sekunde) mit ASICs in einem "miner-ähnlichen Gerät" hinbekommen würde.

Es können sich nun im Laufe der Zeit diverse Eigenheiten des RIPEMD160(SHA256(x)) Verfahrens zeigen, vielleicht Informationen die bestimmte Bereiche des Suchraumes lohnenswerter erscheinen lassen als da brute force uniform durchzumarschieren (im übrigen habe ich da bereits eine Vermutung, aber der Rand ist hier zu schmal um sie niederzuschreiben).

Mit so einem operativen Pool steht man dann ja auch schnell Gewehr bei Fuß um solche Gebiete abzugrasen.

Aber um es ganz klar zu sagen: Derzeit ist das Minen von X mit GPUs und ASICs wesentlich "lukrativer" als irgendeine Suche nach Kollisionen.
Deswegen ist diese Suche hier eher was für ungenutzte CPU Kapazitäten.

Ok - so in etwa. Ich hoffe, es wurde etwas klarer, worum es hier geht. Man könnte noch mehr schreiben (wie z.B. dass auch wenn der Pool nie etwas finden würde, dies auch Vorteile hat - nämlich für den Bitcoin als Ganzes, etc.) aber ich denke diese ersten paar Worte sollten reichen.


Rico

[fronti]

Nutz doch die Rechenzeit (und Strom) die du in dem Pool zusammenziehst evtl für was geschickeres, z.b um Vanity Addressen im Auftrag zu berechnen.

Auch frage ich mich, wie du effektiv überprüfen willst, ob du mit einem PrivKey Erfolg hast.
Packst du die alle in eine Wallet.dat oder datenbankabfrage auf eine liste "der Key hat was drauf?"

Wie schnell ist hier deine Abfrage, wenn du schon mit sekunden hantierst?

Das man viele Keys erzeugen kann (man kann ja einen ASIC (keine SHA2 ASICS) dafür bauen ist ja keine Frage.
Und das man da Forschen will, auch dem will ich nicht wiedersprechen, aber für ein Forschungsprojekt ist es noch etwas unklar was das Ziel ist.

..

[rico666]

Nutz doch die Rechenzeit (und Strom) die du in dem Pool zusammenziehst evtl für was geschickeres, z.b um Vanity Addressen im Auftrag zu berechnen.

Das Thema hier lautet nicht: "Bitte liebe Leute ich habe keine Ahnung was ich machen möchte - gebt mir Ratschläge von möglichst langweiligen Projekten, die es anderweitig bereits gibt." 

Auch frage ich mich, wie du effektiv überprüfen willst, ob du mit einem PrivKey Erfolg hast.
Packst du die alle in eine Wallet.dat oder datenbankabfrage auf eine liste "der Key hat was drauf?"
...
Wie schnell ist hier deine Abfrage, wenn du schon mit sekunden hantierst?

Das überprüfe nicht ich, sondern der Client. Jeder Client hat ein Hash aller Bitcoin Adressen die was drauf haben. Das überprüfen ob eine generierte Adresse in diesem Hash ist, is O(1), also "sofort". Also ja, 300.000 Keys pro Sekunde gegen 9.2 mio Adressen gecheckt = 2760000000000 checks die Sekunde. Und das ist noch nicht besonders schnell, ich denke, da geht noch mehr.

Das man viele Keys erzeugen kann (man kann ja einen ASIC (keine SHA2 ASICS) dafür bauen ist ja keine Frage.
Und das man da Forschen will, auch dem will ich nicht wiedersprechen, aber für ein Forschungsprojekt ist es noch etwas unklar was das Ziel ist.

Etwas machen, von dem Viele/Alle behaupten es sei unmöglich. Praktisch klarstellen, ob es tatsächlich unmöglich ist (das sollte dem Bitcoin einen fetten Vertrauensbonus geben) oder irgendwann durch eine Kollision beweisen, dass Praxis und Theorie auseinanderklaffen. In dem Fall würde ich auf ein "Upgrade des Bitcoin" hoffen. Ich gebe gleich zu Bedenken, dass ich mich hier auf eine Diskussion "Das ist unmöglich" nicht einlassen werde. Ich glaube, ich kenne mich mit Stochastik besser aus, als die Meisten hier.

Zur Erinnerung: Das Thema ist "Suche Betatester".


Rico

[lassdas]

Und das ist noch nicht besonders schnell, ich denke, da geht noch mehr.

Das denke ich auch,
mein oller AMD Triple-Core schafft (im vanitygen) schon mehr, ne auchnichmehrsojunge HD5850 bringts auf über 20MKeys/s.

"Unmöglich" is das Ganze natürlich nich, nur unwahrscheinlich,
trotzdem ne lustige Idee, das einfach mal zu testen.

Ich hätte auchnoch n paar ZTEX-FPGAs, die sich für sowas bestimmt auch missbrauchen ließen,
allerdings hab ich keinen Plan davon, wie man die Dinger programmiert. 

[Elwetritsch]

Bei dem Projekt geht es im Grunde genommen darum private Keys zu finden zu Adressen auf denen Bitcoins liegen.

Hi,

ich habe deinen Beitrag oben grade überflogen, und weiß nicht ob ich das richtig verstehe, aber im Prinzip wäre das doch ein Pool mit der Absicht Bitcoinadressen zu knacken? In dem Beispiel ist die Wahrscheinlichkeit quasi nicht vorhanden, aber wenn da genug Leute mit genug Rechenleistung mitmachen... kann das nicht gefährlich werden?!

Gruß
Elwe

[rico666]

ich habe deinen Beitrag oben grade überflogen, und weiß nicht ob ich das richtig verstehe, aber im Prinzip wäre das doch ein Pool mit der Absicht Bitcoinadressen zu knacken?

Naja - "knacken" ist ein hartes Wort. Zum knacken brauchts zwei Dinge 1) den privaten Schlüssel 2) die Absicht das "Konto" auch leerzuräumen. Hier geht's um 1), in den FAQs schreibe ich auch recht deutlich, dass es je nach Jurisdiktion deutlich illegal sein kann 2) zu begehen und das man sich vermutlich mit einem legalen Finderlohn begnügen sollte.

Darüber hinaus lasse ich diese Entscheidung schön feige in den Händen der Clients, deswegen checkt auch der Client die Adressen mit Bitcoins ab und nicht der Server.

In dem Beispiel ist die Wahrscheinlichkeit quasi nicht vorhanden, aber wenn da genug Leute mit genug Rechenleistung mitmachen... kann das nicht gefährlich werden?!

Damit kommst Du ziemlich ohne Umschweife zur Kernfrage. Ich denke früher oder später wird es gefährlich werden und die Leute werden auf P2SH umschwenken, bzw. ihre Bitcoins mehr verteilen (keine hohen Beträge auf einer Adresse). Vielleicht werden sogar die Wallets eine Art auto-distribution unterstützen. Momentan ist das noch kein Thema, aber ich gebe zu bedenken was wir wohl 2009 von einem S9 mit 14TH/s gehalten hätten als eine CPU mit 8MH/s vor sich hingenudelt hat.

Ich sehe es momentan ähnlich wie mit Solomining: Der nächste Block kann 11000 Jahre dauern oder auch morgen da sein.


Rico

[lassdas]

Warum sollte man ein Schloss knacken, wenn man den Schlüssel besitzt? 

Zur Wahrscheinlichkeit des gefährlich werdens ("bevor unsere Sonne verlöscht") sag ich jetz ma nix. 

[MikeBatt]

Na ja, nicht böse sein, aber wer ein solches Projekt startet, will auch das machen was Du unter Punkt 2 ansprichst, möchte den sehen, der ein Wallet knackt mit 100BTC und dann nicht zulangt, sehr schwer vorstellbar, erinnert mich an meine Zeit mit Premiere und co, da wollte auch jeder nur wissen wie man die Karte hackt aus Interesse, aber niemals um damit was zu verdienen, jo was soll man sagen

[rico666]

Na ja, nicht böse sein, aber wer ein solches Projekt startet, will auch das machen was Du unter Punkt 2 ansprichst, möchte den sehen, der ein Wallet knackt mit 100BTC und dann nicht zulangt, sehr schwer vorstellbar...

Ja, mir ist auch schon aufgefallen, dass sich die "Bitcoin Community" - nicht nur hier auf Bitcointalk - gegenseitig für die miesesten Typen unter der Sonne hält. Macht natürlich etliche Sachen schwerer.

Damals - ja damals(tm) war das mit der Linux Community doch deutlich anders, aber da ging es ja auch nicht um Geld. Würde mich aber nicht wundern, wenn das latente Misstrauen einer der Gründe wäre, warum sich Crypto nicht oder wenn dann nur wesentlich schwerer durchsetzt als z.B. Linux oder "das Internet".

Oder es ist wirklich so, dass solche "die Du sehen möchtest" wirklich in der Minderheit sind. Es gibt schliesslich auch solche, die lassen 250 BTC stehen https://bitcointalk.org/index.php?topic=1147035.0

Vielleicht hängt das ja auch damit zusammen, dass um den Bitcoin herum lauter arme Schlucker hängen, die irgendwie auf den großen Reichtum hoffen. Wenn für Dich 100 BTC in etwa 4 Monatsgehälter (netto) wären, würdest Du die Coins auch liegen lassen. Hoffe ich zumindest. Denn bei genauerer Betrachtung ist sogar der potentielle Verdienstausfall durch Knast ja ein Risiko was man nicht eingeht.

Klar gibt es für jeden irgendwo eine Grenze. Ich bin mir auch nicht sicher, ob ich ne Wallet mit 50000 BTC stehen lassen würde, aber 100 BTC? Das sind ja gerade mal 2 Wochen Urlaub. ;-)

Rico

[rico666]

Eine erste funktionierende Pool Statistik läuft seit gestern.
Wir haben bald glorreiche 37 Bits des 160 bit Suchraums abgearbeitet. (Also fast Nichts  )

Ich habe zwei Ideen wie man die Sache interessanter gestalten könnte:

1)  @fronti: Sorry, dass ich die "vanitygen" Geschichte so schnell verworfen habe, denn theoretisch könnte man Vanity-Keys "en passant" - wie der Franzose sagt - also "im Vorbeigehen" generieren. Das wäre für die Poolteilnehmer ggf. ein möglicher Anreiz, denn entsprechende Keys wird der Pool natürlich früher finden als eine Kollision. Momentan will ich die Geschichte robuster hinbekommen - einige Betatester machen da wilde Dinge   - und dann kann ich mich dem Thema zuwenden.

2) Ich habe mir überlegt um die Geschichte spannender zu machen, also zumindest so spannend wie Angeln, dass ich selbst auf einige Adressen, die der Pool innerhalb der nächsten Tage finden sollte einen Betrag überweise. Die Beträge wären sowas wie 6660 oder 66600 Satoshi, also wüsste man, dass sie von mir sind und der Finder darf die auch behalten.

So würde man zumindest die Funktionsfähigkeit des Pools demonstrieren und es wäre auch ein wenig Spaß und Anreiz dabei. Was meint ihr?


Rico

[willi9974]

wäre es nicht einfacher mit vanitygen millionen von Adressen mit Keys zu erzeugen und dann zu schauen ob da was drauf ist auf den Adressen?

[rico666]

Prinzipiell möchte ich irgendwann vanitygen und oclvanitygen dafür missbrauchen, aber die "millionen von adressen" die die erzeugen, müssen kontrolierbar sein, d.h. Nicht einfach per Zufall irgendwo was rauspicken, sondern man müsste z.B. oclvanitygen sagen:

oclvanitygen <start>

<start> wäre der numerische Wert einer privkey und dann würde der - sagen wir - die nächsten 2^24 Adressen (sowohl uncompressed wie compressed) auskotzen.

Das ist das Ziel. Soweit mir bekannt macht oclvanitygen fast sowas. Er pickt sich eine Adresse raus und inkrementiert dann einfach den privkey 100 mio mal. Dieses zufällige rauspicken müsste also durch eine Wahl auf der kommandozeile ersetzt werden und dann müsste er auch noch uncompressed Adressen rausgeben (denn die von Satoshi sind definitiv nicht compressed).

Denn das Einzige was der Pool macht - und was er versucht gut zu machen - ist eine ausgefeilte multi-interval arithmetik, die sicherstellt, dass bei N verteilten clients dennoch keine Arbeit doppelt gemacht wird.

Wenn wir da die vanitygens unkontrolliert loslassen würden, dann wäre das die berüchtigte horde Affen mit Schreibmaschinen, die nach x millionen Jahren durch Zufall ein Werk von Shakespeare ausspuckt.


Rico

edit:

Das "generate" binary (compiled Go source), was ja Bestandteil des clients ist macht ja genau das. Es generiert 2 Millionen adressen und diese werden dann gegen die 9.2 mio Adressen mit Funds abgeglichen. Wenn wir es schaffen das binary durch was schnelleres zu ersetzen (sagen wir ein modifiziertes oclvanitygen), dann erwarte ich einen erheblichen Speed-Up.

[rico666]

2) Ich habe mir überlegt um die Geschichte spannender zu machen, also zumindest so spannend wie Angeln, dass ich selbst auf einige Adressen, die der Pool innerhalb der nächsten Tage finden sollte einen Betrag überweise. Die Beträge wären sowas wie 6660 oder 66600 Satoshi, also wüsste man, dass sie von mir sind und der Finder darf die auch behalten.

Und so sieht das dann in der Praxis aus:

https://blockchain.info/address/1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq

Code:

# LBC -c 10 -t 60
Reading balances... storable found - using that (faster)...  done.
Fetching adequate work... got block interval [13715469-13715478]
...FOUND: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq 1CFmxJisuaGrPCTjeUPJeLAoQPUjTJH57w 1048471
 (13715469) !!!
Visit directory.io page 112357122048 for privkey! Congrats.
.......
Fetching adequate work... got block interval [13715479-13715488]
....

Ich habe die Blockzahlen etwas verändert, da ich die Satoshis stehen lassen werde. Der Pool-Offset wird so gelegt, dass diese Funds von einem Betatester mit Sicherheit Anfang nächster Woche gefunden werden.

@Betatester: Heute Abend werde ich einen neuen client und eine aktuelle balances.pst bereitstellen. Ohne die macht es keinen Sinn nach diesen Funds zu suchen, da in eurer balances.pst noch nicht drin.

Für mich selbst ist das ein Novum, denn bislang hatte ich einen Match nur durch simulierte Daten getestet, nicht mit einer Adresse die tatsächlich "scharf mit Funds" in der Blockchain steht.

Waidmannsheil!

Rico

[rico666]

Wer mag und noch nicht hat: http://lbc.cryptoguru.org:5000/download

Der Download Link für den 0.803 Client funktioniert jetzt für jeden.

Vielen Dank an die Beta-Tester der "closed Beta" Runde für ihre Hilfe bei der Suche und Plättung der Bugs.
Die Installation ist noch ein wenig Kommandozeile, aber für die Linuxer unter Euch sollte das kein Problem sein.

Rico

[willi9974]

Ich verstehe noch nicht wirklich was das für einen Zweck hat.

Wenn Du Adressen erzeugst und deren Keys hast, hast Du im ersten Schritt ja einen mega Datenmüll und zwar sehr viel.
Wie willst Du dann prüfen ob auf einer der erzeugten Adressen eine Balance ist / BTC drauf sind?

Ich hab das mal probiert aber auf keinen grünen zweig gekommen.

Ich hab mal zum Spaß ein Skript geschrieben das mir a) per vanatygen Adressen erzeugt und b) directory.io ausliest, dann habe ich folgenden Datensalat

Code:

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gBfjJue;186gNyfZ8Q3hD3ZEVPszfHWwKbQbRqP7bR
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gLgyoSo;18xQA5GdJd9CXXUmABZxL9RbepuoHydFH4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gShVZbn;1AWe6AUVS1PQktFKdtS9rVFf4L9wCewchG
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gVX1dtG;1BrmxeGfc9vd3NQckM5NDpSi48r2Yg7w6A
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gbWBg5d;1G4LE53w5brSGsxEFt54kwZPthc5x7vwRH
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38giFGwFC;18CFyrpUvpeQNbsXqE3Vjk3bxUNCkS8UPw
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gqbEF1N;1Bd9KdmzksMB3bwwafwQprHHY6cgJWAALx
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38gwwiTYd;1Pb3A5c12ibJcdprVpHDqtNLha41QNmQWN
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38h2h6GAQ;1KTPg9PtnmSopcUDp5TquPHgMRLvnWzVeg
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hBv3KyU;16saHpdTZHvJ2Rhx43EiQeQvqWjSTD2Xvd
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hLXsTfr;1J9h5TMpeuTZE8NsJJAj8bAVcp61YrXMms
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hPp9Mau;14Xv39fuXPC2qKyxAY7fSekioNViH8a8jK
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hWiLJxH;16sJnv15nAEDAqCwUvcUJqu4w4rgyAY9YQ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hc2jMSj;1EYyrdQs6KhzLhCevBizduyBrfn9Pgjpgt
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hkF6hoR;1DWcT9L47Mkw8h7FYhuvU7g8YPW1j6jngr
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hvE6yVp;19MCRFtTxyZV1QP4F9WDXebvqqACpkjCPp
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38hzZo8Un;12z94f5C6ggN1EYnB35dSbQkgCXiy2SAnU
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38i8G4Nai;15oCszDq9dbrBmDbPLDjsdTAoLkPSaowee
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iBkW24p;1NPLrWzMqEBHPRbyRogd5qXeA6JruJmjxu
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iLUCzbM;1Et9w616CjzYCgCkNT4Hdm2tySCHGJQarm
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iRDmLva;16SNCK15B3gNP8x4y7WP2wXAdFjpLRHHnJ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iahohxd;14C8dYwUushpPMY2LEG57u8eKsn2VLCYM4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38igFuFGh;1NPXjqy6TkTHLxC4qrACiQ8MAeSYrhfYga
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38ikNheru;1AWSdy3cGVPzcvtSJJpWaJF7THkyZuafs4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iry8Zco;1A1Td5eZjSQPiNqnSj6ZgbseNKub9wyLS5
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38iymsSZp;1HbhkideKLcgZ86mVRRa4i3xFaka3YMtuw
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38j5bUWrc;1Kh1xnSitQoNnHEYM7dwMT2FgzcLpym8PT
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jCtgGbM;172V5vfwQAy9Nbo7rn5XJ32eTdewB4G1B2
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jHsiGgF;1Hmdy4LPhaZ9YYLLtwumkUhvYciWwgRrFj
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jT46hrg;18sP4wmCgrPYRSxtopy8EtsoDyZ9EPWUB3
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jWh94rQ;1RznVr4omRE7YUrMUFLzdKnBY3CMPsMZo
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jhRDV36;13sakqhCbpfZQXXDJMogGatmzz6PWzmwVP
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jncxVdN;112eEVzFkxz67zku5AjjgEAD6aLBjqW7Jf
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38jwXfC7y;1FTYvehKTsYEeSHBKKZeVvvi5UL5meaUuP
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38k3TTKpg;1DZtBGdvnniNfUrKFdbo37YgdqJPTJq8EV
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38k5AwBtu;1N5i6UYA3nUGUqXeaRBWYLzkezHex6YRrC
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kHPz7VZ;1Ftfr3R7QqXZXTtA7aQmazPt3gMu2vaTSF
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kK8yLZv;1G6WSSuu2XM4qmaHLY93m7iTK8T9gaKwJC
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kU8RgHy;1AjVyemRiNSfMMbWEzpG5sdhx8b6Aqxk7L
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38ka1UnYX;1DR8MkTq77uojyGMA1XddysYwqfotFKX27
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38keyoyPd;1GL7nM2QJBSXU2etdLsJiEDJb5nw3f9BXN
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kn7rznG;1KGTf9okK52jRukuWy8nfPr37cjdE7cLFt
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kvgLREm;1Apx3S1nZtJsda1T4nkG7GVfHUMktsxnp3
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38kyM2aYZ;1Q8vsfiezVSXdBHixdgTCCDKiVVCAJZzN4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38m8268nQ;12NyzMuwc6xjNpaLA2GhWTMwEJrDwcVPC1
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mDajA5a;1ArNMhHE67ySFE89xXUyXxNW5kjZvBiqf4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mM5L47z;1CAdheWf3DTVQZiErXbn1xBE52F7JagLKN
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mWxPVJV;18tyzAjtwEDmuqHcDtyBBiZBrU1gnvnAQr
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mZVJFFi;1PY9nNZP2ZQzKPo97xm2EW8o79j82Zzq4Q
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mkoj4Xa;1JVP32jtfKMr6XWKm6JFPe5Ha6T9X334vd
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mq8En4T;1Gs8jXjSkeuqQeqVVHk8xgTESixLSByJqQ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mwCgcxm;1514jKS9dRj1pWCS7Rrt9ZrCVEhVQcQZvT
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38mzjTi9j;1JSHgEodWFci6kDqtJmPugddX3eAZvg7xv
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nCRDr3q;1L5QnpFfSGFMPQxdxtXxeUdr2v7cqbUHqR
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nFuARLn;17dDeqFNQBMQn5NVPEocu7djPJEAu3y25i
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nMqTXnR;13v8jFS7594jYGWcjMqfhHZ3GQfwGh4Pf2
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nUu4KVX;15rpJiEyrkN6zub5L4M5JtUZomYL6Em78F
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nZ9Vudk;1MD8qoy1ams71NVAdYG4Z9cyb2GmHpqNkN
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nkq9kTk;1CZKEQ1Pb9DPKT5dT6CBH7ZeqhmEK9hRwb
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nt4icJP;13Lzt3cG4PZn1hwJDR9L1vZFCW4aHqD933
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38nvBSgqz;1HEbat1EYYvurX8LXbye77eYd6vxRMLd4j
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38o6x5wEu;1CtjYkMH2uKUA13sa6NDFMunuCo4L9firU
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oCmfnXW;1BbXNMXb2HZ64iKByAhX7Qr3jNdj5Mi6Go
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oJtEmiC;121mp9T26i9epxfZGSZ5YRSLvXXC1ipegd
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oRopUpw;17SpBa9Ubc23TEPk1yFmv2tf4GE2kpJvvS
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oTjJqHF;1CA2yX6JQYD6ST7YGUtjP4xCL4kcUew5LV
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oc18Ngu;1e5SBXV7KuApzC8tajZ7HUjLjfaRmXALv
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38ohtZPiv;1F2Lxt9NY57VG8Nz34tHkS3wPLUUXLVaUt
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38otP5BGq;1QMEjoEarokUTUqGVaE2e7cm7jJFvVirH
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38oucYUsJ;1A9AbURaMBPLh6nrqh2a3aNNAzH8gQQkB4
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38p3w6L4Z;1NRjU8LXZbCbR5N2PiwKsNdwuj8tWp5kbL
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pF3Sx27;13o3vvCJxza4NRhw1LeEExaUuJoHKzZPiG
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pHu1phH;123TF3JXjxL14V9ucP3eZHvb7ZeE2qZ73g
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pQ5Ua1K;1M2ocKqrR5qifNbzVYCBtcE7Qi97hheg4k
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pajrgCY;12X4MfrT6xLRKazp6jd7KL58jGJ4mDW937
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pgGHjxQ;1BAEnbtbEuseu58d4pmRJBnbZ9LjFfAQM7
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pnBKNJv;1NjbgeuGijPYbZvnd1wQAFVakmtX8dLxLb
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38ptep7k1;1JMRWHjtBa9PPBnub7ZWNFHSRSTuRCDQfM
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38pxN4sRx;1PMDg8eJj5vW2Ctumm63L4kt6NYM3Jtkby
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38q2xwY9y;1PcXe4mYkdcDFpgdHi8QiJ3RLwC7J1kEfQ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qFMePDS;178u3hVujR9ScKURh2BAAKromopno3PSxs
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qKwQzX7;1KFanGgeRdJzicphb7YzKWwyTyiprSyDeJ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qRxrrYA;1MCERFiDL65SVr1SFDjMH15vHeLMrnj8Hy
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qaoExzK;1AR6jrhd84pEVwbsJ5kp1UGaMcyAX1rWJx
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qh5YDwi;1CALDsWE3o4wEdmtzSWRFeAUQ7y4gmuyHL
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qm8vHxK;16rgxZMM46n7XZnm1XEPrtJNzQHJe14Ekj
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qumG4CW;189JYoho8RBCdiUr4BY5GFWK2ywiCusVG1
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38qxrEtar;1CjsXA4AA988cLMBnw1YvcimXtdEuThBwH
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38r4hSuch;1HZgTgzDDubVvqrSjGXPu6rAMGWubthrmg
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rGFmStR;1HsRC1oY5H7yP4NUSX8Rg6yyXsUDsjhRgn
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rM3oDVH;14225A1XZe3uYk28vEWRtp1vjUHQpj43SG
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rRqTiwa;1HaQ1ELzkqC9zg7Te2GJRGi6RMT5jdSU2d
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rZi6DeF;1D4BxBQLSxgkfnVbuSt5bSvraFCWRECk7T
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rd1hap4;165mDL2FNvSQnYcvV1PVFk9h7QJwQ7xS7v
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rncckTh;18PpBkX21gmXhxo4nM78jXoCgfd9ERFnWc
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rr8TT4v;1L8Go5ktpuxqBb2EHzbsiF7aC3Z1Keut6y
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38rxYyPJ8;1LXoqaPrFBLZJ2Zq2mAXg7nfEbBKfv6vjf
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38s82iA7c;19anXJvN7KhgSkpxAUpEN56i9zqSNARsTZ
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38sFzD3gY;1K7uQafxGcXuJtkRHBkywiqU4GVrbC2uLj
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38sMaHhJA;1Jz9Y99mSLbqxXYPQxVnb9HBSs9Bf4fKhk
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38sQwrtfx;1EMEY7BEBQNjFQM7MMnJiMeCjcqKpUciU3
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38sY8pJbg;1D73XdFGxDp7zKUrG5rdBc3LyY1BJWaBpk
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38siu2XeJ;191WX2avpAUMe1GgGKMZLfs5NzCqyTZuF2
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38snNYd6C;19Pb6xWQurbNrbKmfQXDFoBmqNLf7CMpNm
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38svx1cS5;1P4HoH9Pekb4RpDdTUsmQ9Udnrj4fdfTC8
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38szATj7e;1AMfNsDPiXBRcgeDGwTQWVgDsLctqmT6Xw
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tBKFqaS;13ee4ERTgyFYJn45Lxo3PJ9ebGAPTLfmA2
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tEBwq1J;17QbH9ibe9pyxnLhQquoQJ1wXG8ivwpVaq
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tK6CV7F;15CRZ765MxBcM3nf1wPvr63aSRi1W3mCNf
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tUio8tf;1NFrAHK53eEtrNPVPD3jg8nVeEzAps3kM6
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tYx5xRU;13YNtiFizi9kuqFZg53ZJ5PsuehDm7e88z
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tjwguPb;1LiwgvPX4rYF3htTgMUgXpMAKYpHcqABmM
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tpdX51T;1LjAzS8Lb2FDLrs64PteUGbPZTPbXahdbo
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEy38tyr8LcZ;19Pe3gHdUafanAa5pq1AU1YwW1kQnYvGEd

Ein zweites Script packt die BTC Adressen und prüft die Balance

Code:

1; 1BYCspdTrrC6ettKHz3sdoYqFHV7GZ4Kme  ; 0 BTC 
2; 13XrvesarJva923Jpf4iRDeZ1FgJ2Z7Xon  ; 0.00007996 BTC 
3; 1Q8VghUJkNeFnaKy553b9buUWKxFYL579G  ; 0.10462131 BTC 
...
...
...
673100; 1MKjF9qh51Uwwc6EWwMGSzQk7LHewD9EeW ; 0 BTC 
673101; 1DDT6DqTQxXdGPm99URmuDohroNMkMwHqg ; 0 BTC 
673102; 18UgBUHhZTzkNtKSE4XVid828gqsEmQfJ4 ; 0 BTC 
673103; 1NEDGtmX3AEXQHNMfJ9sYb1cTVS1s9zhg9 ; 0 BTC 
673104; 1ErBE6PnLU9hL57P6Kid891GscfMrHUCgw ; 0 BTC 
673105; 1CLVwFEcn9goVeRW5rqxp7DadUNnbfWpSt ; 0 BTC 
673106; 1pxMXNrNt6P7HzFnXVqcyv1Df6jn9ibCb ; 0 BTC 
673107; 1BvC5dXkTAeavTHVknutRKfLPX7PHt5zQi ; 0 BTC 
673108; 14CTuVmBHmds4y9tm8eagQZ2pmCZQmWX7E ; 0 BTC 
673109; 1AHuE97RivuBvxSZhCQMvr4JkV5odGDdyG ; 0 BTC 
673110; 14zMz5BZwMq4wvMZjkE9sqT1oXKepVH9pS ; 0 BTC 
673111; 1Mtjp8xiasGkdkHBRtdCyZvonPa26X7vrK ; 0 BTC 
673112; 1CpefwFRA3cHubseHLeBKgnksTTqyf5S2B ; 0 BTC 
673113; 18XqbCCHfvjzzpB6tL4Mn9mVjB3UZdNfx ; 0 BTC 
673114; 1NnupCTNa8ZPUNNx2UETotAEJxQpAiJUDM ; 0 BTC 
673115; 1NdtDUDUWBKzUW7Wt2odH5LqmyFkovpa4s ; 0 BTC 
673116; 14fCGCw5wka6pT1T5ANbXRJJPdRL4JrdKe ; 0 BTC 
673117; 1DihgZ4LmR7q25kXSp4SxcmkzEqNhmi4U5 ; 0 BTC 
673118; 1MB7B2B62LmUfafq5t5Nbj42ZhE9uTF5SM ; 0 BTC 
673119; 15CyiFab12hYfMPrCig1WWtzz8Lp6owNvr ; 0 BTC 
673120; 1EzgwzFsLhpUnVhL26G27aYSTbGUaabfrw ; 0 BTC 
673121; 1Mh4VVHYUFL9ZxEDorgWApoQAau5LSyarv ; 0 BTC 
673122; 1An8Zc1aLvrg4dj3MJ9akjLtz6PtTDcij5 ; 0 BTC 
673123; 1GYm3t8HPp68tpZ3S54A1tnyGfkWUDTige ; 0 BTC 
673124; 1HGw7j1T9Afy1sTttQfW2vQgqJ6MW96gWD ; 0 BTC 
673125; 1BxKaYchUePsgJYZxJwYMwGcL2niBMF2Jq ; 0 BTC 
673126; 1PUUtTRRBX5vh5ntwBeuNkCyyiSP9Z7MX ; 0 BTC 
673127; 17es6JATLqfW9LvQ1DJkcEM1RP2x7eJyyU ; 0 BTC 
673128; 1KazVBVgtCfd4DFiYmxHjsTo6V89GGxvry ; 0 BTC 
673129; 1NnfMKiCRBKJfhhLLD4hdT4idChv39fBBn ; 0 BTC 
673130; 16hCi6A7Pz8SJiorrHQafMKaWyQJDdxap9 ; 0 BTC 
673131; 1BP7tz4rLxrBLUeD3vJ9eLZ7696seUX2Na ; 0 BTC 
673132; 13re4NNmLWNm3i3AtW3sHoaBWd79F7CTZk ; 0 BTC 
673133; 1N7AfNXJZfT9JezgX9VzRQod5YJEzgTQQQ ; 0 BTC 
673134; 1P98yCPx6MhpVQWEnUhCPrwQsibWj4Jbr8 ; 0 BTC 
673135; 15pxy3TLyWVfFVGhvSPjnEejaAykMn66rr ; 0 BTC 
673136; 1CSpPxx2oUuaZUbNYfvcpECQuj3PdVCD6Y ; 0 BTC 
673137; 165DBUzaPaTTbLmZs1BkvBxLHPEYvW6bVL ; 0 BTC 
673138; 1MiycpyfC8wqvF5zKYGrzutRBGBTCVHZVK ; 0 BTC 
673139; 1LDQ39bzzwbqMrq3fJrCXduBbTP8rVJQro ; 0 BTC 
673140; 1LQkS1a9c54aYVBary764TnJAsTUfvKyAi ; 0 BTC 
673141; 1oCPayucu3UaDhbKUe6U9K3arPXBQ46Ji ; 0 BTC 
673142; 1BBRd9rzYKyDaAcEZDWuRGga8yg43LLZSE ; 0 BTC 
673143; 1KQKWvWko7HDXDTkWKGHeXSvWb39vAeiNj ; 0 BTC 
673144; 1CP5LipPkSYfrG9YkdyEeoVTCGZKfVCQPS ; 0 BTC 
673145; 1J6dYgHGH82Qk9dwtd9kaKzDk4fQQyyaDZ ; 0 BTC 
673146; 15aJ33GXpvj2metGQHhnAxV3k5Sey8xxRB ; 0 BTC 
673147; 1H7GMdwDcWpKSq8wE3S2NQ3iDoCDpubg5P ; 0 BTC 
673148; 15JujMgtkL9cnVFMHtARDkGWTktZMoFnDM ; 0 BTC 
673149; 1KmmzPY3YtbWVZkYBirZ2M4eK9am6Y8wTB ; 0 BTC 
673150; 1GpxX9MNGC1cVjCP95XwLYCEAXJTkw7N9J ; 0 BTC 
673151; 1HErwbrEh5mNBrTHqww7NukXLzDxPMdfm3 ; 0 BTC 
673152; 17hmpiDE73ijGNPMK6FjpUd4KQX17J3ZZG ; 0 BTC 
673153; 19MohbX194QUmwdbZJETzUShREcvYwKkmq ; 0 BTC 
673154; 1PUhdczi2VX6133Ks6TvxjM4JDu8JDmumd ; 0 BTC 
673155; 1EcZtJs1yhpKhSQFJXTaHTGV5kE9iNGMnU ; 0 BTC 
673156; 1JJhqztFzwbe2QXBLvrS2zLFbxfwmxfaur ; 0 BTC 
673157; 1FR2xbZWKyxBNkqzPSy74ZeVyc7WA68EAc ; 0 BTC 
673158; 1NGyXY5T8eCSWrpdrA4D3uvNk5qG5hSY9x ; 0 BTC 
673159; 1Hz3HGXELzwUpfeuZDVQ9HeW8PNQG5qGvu ; 0 BTC 
673160; 1HZNMPHWxDhNBRWEMFxwRV3391BF6rWPv1 ; 0 BTC 
673161; 1KG7ge7WpNUD2KbY5Uy9KjR1W7m5ygZEAG ; 0 BTC 
673162; 1PfuQQdx8j9J1kvsfKDThPq2XZqjUh5iVi ; 0 BTC 
673163; 1LNZquqRFBBNsLwutyYNkjMZoaNJ6No7cY ; 0 BTC 
673164; 1HB8oe8HNLN8gqA8GzhB5EXDhstpchR17h ; 0 BTC 
673165; 1BpGTSVgdjkGtAzxa9nFrpgJR1bTEFN1Hc ; 0 BTC 
673166; 1GhHJELEYNBUD1EL1uFUEcx8ojyc9i2QXY ; 0 BTC 
673167; 1HCuzBgFEQ4v1HKixSSibAw1KrW4c2WLos ; 0 BTC 
673168; 1C1f1cz1XQeRUo3XwZ1bopG1PD4oYy9joe ; 0 BTC 
673169; 1DVYLhxFDkPovgU7LZMBfE691167ECFnY7 ; 0 BTC 
673170; 1NAzAGVqnJY2bAUGLkCNwzByS7TUxFrTxk ; 0 BTC 
673171; 1CUtTeJSb9PQDeycAm7W4P4nRfNpzEPTzW ; 0 BTC 
673172; 19mLXMuc5MucRumCs3NzHEobfqQgiE826B ; 0 BTC 
673173; 13ZXooqdLVLzh1xoJh4QkFWh2exjDawwQ2 ; 0 BTC 
673174; 17KS4kHL4ozv1Pqc3V3N8dURR7dksgjwZ1 ; 0 BTC 
673175; 1JnZLJ3emeRSBH63EYJikaJuMem2L5t1HW ; 0 BTC 
673176; 12i6ScEjkXG2jyw5dy78naZBUJZ3s8E8Ed ; 0 BTC 
673177; 1JpzRAoLs1Y9QMUQgBU4J3q4s5ViVAUs19 ; 0 BTC 
673178; 1AiUwBbN18sWQ1bHvV8UUeGAffmorT3dv7 ; 0 BTC 
673179; 1GSi13jYQgyjGSk2TPsCNC9JyDQvEDFgKg ; 0 BTC 
673180; 18BDJhkAjeQgHZ1uWfivLNTmwANoHjdwfT ; 0 BTC 
673181; 18LpKKsTJak3nahoHAkKokMHM1wJURKjB8 ; 0 BTC 
673182; 1J3K44tK8x8q5XbbxfVKFDLEnYBePmNNtu ; 0 BTC 
673183; 1NMh8jhB9WReUymGNZcFrQ4auRUq551jih ; 0 BTC 
673184; 1Kr2Cdk3n7Uxk73NkG15bYSGNQi7g52Cm3 ; 0 BTC 
673185; 1Hfr6n62aKVtDHmXLDaRMCj2dhC2jwnEoy ; 0 BTC 
673186; 1NFeDuKCfv1FdooyufWdZieGbC3QNJujuE ; 0 BTC 
673187; 1AZDjpmXXx2daeTrPMuiJcCEwaSAgnKXkE ; 0 BTC 
673188; 15zyD5N3ir5VxnwS6W3chaFBVteq4sSbLf ; 0 BTC 
673189; 1LCuqoZKB1Ca7HFCoJ7gpSU2ErKBbGKhGf ; 0 BTC 
673190; 1FG3KxGrRytbzJuS7Fnc6Vv35qiRES881P ; 0 BTC 
673191; 1GbzC9p15ySMuhzr2J4rVFWpAjfa8cpi6M ; 0 BTC 
673192; 1DfbFZu1198xqBfPnWUKQp9awFmS1NfjKs ; 0 BTC 
673193; 18PQwf9CpTQX7XQEP1Np3SynSTBwQAvMvn ; 0 BTC 
673194; 17yhtNeJyE3qkXTK1rANQ29hsnDSBo6yF1 ; 0 BTC 
673195; 1BjyP1d6T9NQiSDGFYSYaqLSKvRNdb8NdT ; 0 BTC 
673196; 1NYXKufNp3ZAy1JR2ep9az21q6Q5GrTWKp ; 0 BTC 
673197; 1MskjF94N161NvRMtjpqeFx5UyVSHMUCFx ; 0 BTC 
673198; 19XEBGUFUBgHouB9T1Gf1Ghu8TEQepQ6GY ; 0 BTC 
673199; 1H3KvtBrqFwSsTApJSYToXQ6fcDQptVG9u ; 0 BTC

Als Gegenprobe ob das Skript läuft, habe ich drei Adressen von mir immer als erstes abgefragt, um zu sehen ob auch eine Balance zurück kommt, also es klappt.

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

Wie prüfst Du ob eine Adresse eine Balance "größer 0" hat?


Viele Grüße
Willi

[rico666]

Ich verstehe noch nicht wirklich was das für einen Zweck hat.

Dabei gibst Du mit Deinen Versuchen schon eine Teil-Antwort.
Deine Versuche sind kläglich. Meine Versuche sind ca. 13800 mal besser (edit: oder doch 27600 mal?) , aber immer noch kläglich.
Wenn ich nochmal um den Faktor 1000 besser werde ist's nicht mehr ganz so kläglich, aber immer noch
ungefährlich für Bitcoin.

Also Zweck: Mal schaun' was geht.

Wenn Du Adressen erzeugst und deren Keys hast, hast Du im ersten Schritt ja einen mega Datenmüll und zwar sehr viel.

Naja ... der Müll ist nur von kurzer Lebensdauer, weil er von einem Programm zum anderen "gepiped" wird. Falls das Zielprogramm (check gegen Adressen mit einer Balance) nichts findet, verwirft es den Müll der da kommt.
Zumindest in diesem Projekt. Ich habe noch ein anderes, da wird der Müll gespeichert.

Wie willst Du dann prüfen ob auf einer der erzeugten Adressen eine Balance ist / BTC drauf sind?

Indem der Client ein Hash mit allen Adressen, die eine Balance drauf haben hat und "den Müll" der da vom Generator kommt, dagegen abgleicht.

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

Der LBC Pool hat - außer Bounties - auch noch nichts gefunden und - Stand jetzt - knapp 138 Milliarden Adressen keys (276 Mrd. Adressen) geprüft.

Update:

16-08-28: ~350 Mrd. Adressen
16-08-30: ~420 Mrd. Adressen
16-09-01: ~490 Mrd. Adressen
16-09-03: ~545 Mrd. Adressen
16-09-05: ~600 Mrd. Adressen
16-09-10: ~780 Mrd. Adressen
16-09-13: ~930 Mrd. Adressen
16-09-14: ~1     Bio. Adressen


Rico

[willi9974]

Ah ok, das klingt interessant.
Aber gegen welchen Server checkst du die Balance, also wo fragst du die BTC Adresse ab ob Coins drauf sind, das würde mich am allermeisten interessieren, da ich für jede Abfrage 0,6 Sekunden benötige...

[rico666]

Aber gegen welchen Server checkst du die Balance, also wo fragst du die BTC Adresse ab ob Coins drauf sind, das würde mich am allermeisten interessieren, da ich für jede Abfrage 0,6 Sekunden benötige...

Nochmal: Der check gegen die Balance erfolgt offline. Jeder client hat ein Hash von Adressen (derzeit ca. 9 10 mio) mit Funds drauf. Dieser Hash wird von Zeit zu Zeit aktualisiert.

Diese Adressen bekommt man z.B. von https://github.com/znort987/blockparser

Und so benötigt der Client für einen Abgleich von ca. 2 mio generierten Adressen gegen alle Adressen mit Funds drauf... ca. 1 Sekunde

Das Nadelöhr bei mir ist momentan das Generieren der Adressen ("der Müll" - s.o.). Das möchte ich beschleunigen.


Rico