Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 27.

dArkjON

hero member

Activity: 683

Merit: 513

http://bitcoin-engrave.com/ & https://bitcore.cc

Quote from: ?? on ??

Quote

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...

dArkjON

hero member

Activity: 683

Merit: 513

http://bitcoin-engrave.com/ & https://bitcore.cc

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 !

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: willi9974 on September 13, 2016, 03:43:25 AM

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: willi9974 on September 13, 2016, 03:43:25 AM

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.

Quote

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

willi9974

legendary

Activity: 3500

Merit: 2792

Escrow Service

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

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: willi9974 on August 25, 2016, 01:12:50 AM

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: curiosity81 on September 07, 2016, 04:20:28 AM

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

curiosity81

legendary

Activity: 1778

Merit: 1070

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: curiosity81 on September 07, 2016, 01:01:47 AM

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. Wink

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.

Quote from: curiosity81 on September 06, 2016, 03:24:39 PM

... 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.

Quote

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... Roll Eyes

Quote

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? Wink

Rico

curiosity81

legendary

Activity: 1778

Merit: 1070

Quote from: rico666 on September 06, 2016, 03:43:27 PM

Quote from: curiosity81 on September 06, 2016, 03:24:39 PM

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.

Quote from: curiosity81 on September 06, 2016, 03:24:39 PM

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.

Quote from: rico666 on September 06, 2016, 03:43:27 PM

Wer sagt ich kann keine 2^160 Privatkeys abspeichern? Wink

https://bitcointalksearch.org/topic/bitcoin-adressen-als-sammlerobjekt-1587485

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

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: curiosity81 on September 06, 2016, 03:24:39 PM

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? Wink

https://bitcointalksearch.org/topic/bitcoin-adressen-als-sammlerobjekt-1587485

Rico

curiosity81

legendary

Activity: 1778

Merit: 1070

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

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: cagrund on September 06, 2016, 03:19:56 AM

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

Öööh ... tralala Cool

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

Rico

cagrund

legendary

Activity: 1372

Merit: 1000

CTO für den Bundesverband Bitcoin e. V.

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

Gruß Carsten.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: rico666 on August 26, 2016, 05:12:24 AM

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 Huh

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

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

willi9974

legendary

Activity: 3500

Merit: 2792

Escrow Service

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: willi9974 on August 25, 2016, 04:32:58 PM

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

willi9974

legendary

Activity: 3500

Merit: 2792

Escrow Service

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

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: willi9974 on August 25, 2016, 01:12:50 AM

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.

Quote

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.

Quote

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.

Quote

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

Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 27. (Read 51041 times)