Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[rico666]

Ich habe mit meinem Skript keine Rechenpower was ihm zur Verfügung steht, wollte nur mal schauen wie sicher BTC sind und habe den Schluss das sie ziehmlich sicher sind. Würde aber niemals alle meine Coins auf einer Adresse lagern, nicht das er sie noch findet.

Und nö, hinter schwedische Gardinen will ich nicht 😀

Keine Sorge.

War schon oft genug Sachverständiger vor Gericht. Das Gutachten, das den Staatsanwalt aus dem Saal spült, bekämst Du kostenlos.


Rico

[rico666]

Beobachte das Projekt oder den Ableger nun schon eine Weile... hätte nicht gedacht, dass es so schnell geht! WoW!

Danke, aber mit World of Warcraft hat das Projekt Nichts am Hut. 

Würde aber niemals alle meine Coins auf einer Adresse lagern, nicht das er sie noch findet.

Je mehr Adressen, desto besser. Wenn es statt der gegenwärtigen 9 mio P2PKH Adressen, die Funds draufhaben, 18 mio Adressen gäbe, wäre der effektive Suchraum im Schnitt nur noch ca. 135.75 Bits, bis man auf eine trifft.

Wer vor dem Pool Muffensausen hat, soll seine Coins einfach auf eine (oder mehrere) P2SH Adresse schieben - da sucht der Pool nicht. Noch nicht. 


Rico

[willi9974]

Warum was ist mit den keys?

[rico666]

Die normalen Privaten Schlüssel mit dem Beginn 5J fangen erst extrem viele Keys später an, da Rico ja mit seinem Generator sozusagen Directory.io durchsucht nach der Reihenfolge der Keys.

Genau das ist aber der große Irrtum. Ich behaupte:

Wenn SHA256 und RIPEMD160 genau so funktionieren wie sie funktionieren sollten, also für eine gleichmäßige Verteilung der Hashwerte sorgen, dann befinden sich alle Bitcoin Adressen bereits in den 160 ersten Bits Suchraum. Und dann nochmal in den nächsten 160bit Suchraum, und dann nochmal, und dann...

Und das wiederholt sich 2⁹⁶ mal.

Natürlich sind sie nicht in diesen Suchräumen immer an der gleichen Stelle und auch nicht in der gleichen Reihenfolge und vielleicht sogar nicht immer alle. Aber prinzipiell ist es ja so, dass es 2⁹⁶ private Schlüssel zu einem hash160 gibt. Reicht ja nur Einen davon zu finden.

Wenn diese Hypothese nicht stimmt, dann verteilen die Hashfunktionen nicht gleichmässig und dann haben sie eh ein ganz anderes Problem.


Rico

[rico666]

https://bitcointalk.org/index.php?topic=1573035.msg16523548#msg16523548

Wobei ich im Moment eigentlich keine Zeit für so einen Mist habe. (Jarvis Betatest)

edit:

Ok - was ist passiert?

Sieht so aus, als hätte ich (ja, ich - mein Client) den Privatschlüssel zu https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg
gefunden. Naja "sieht so aus": Für euch sieht das so aus, für mich ist das so, denn ich konnte den Schlüssel in mein Wallet importieren und die Funds auf die Addresse https://blockchain.info/address/16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE transferieren.

Nein, ich habe nicht die Absicht diese 7.x Millies zu behalten. Wenn sich der Eigentümer meldet (Fristen wie in der EU nach Fundrecht üblich), runde ich den Betrag sogar auf 0.01 BTC auf und gebe ihm den zurück. Wenn nicht, geht das als Bounty an die Poolmitglieder.

Ich vermute stark, dass es sich tatsächlich um eine Kollision handelt, weil kein Mensch wäre so blöd und würde einen PK mit 45.x Bits Länge verwenden. Daher denke ich auch, dass der rechtmäßige Eigentümer ohne Probleme einen alternativen PK vorweisen kann. Wenn nicht, soll er bitte nachweisen wie er zu diesem PK kam (kaputte Software?).

Der Fall zeigt aber auch zwei weitere Sachen:

a) Ich liege mit meiner Suchraum-Hypothese vermutlich richtig
b) Die ersten 50bit Suchraum wurden eben nicht bereits - wie von Ryan C. behauptet - komplett durchsucht.

Kann ich beweisen, dass https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg nicht ursprünglich mir gehört hat?
Wohl kaum, denn wenn ich eines Negativbeweises fähig wäre, würde ich mir als erstes Gott vorknöpfen.

Aber diese Adresse lag da schon seit Mai 2014, also über 2 Jahre, bevor ich auch nur einen Gedanken an einen Collider verschwendet habe. Zudem - wie gesagt - mit einem wirklich schlechten Schlüssel, wenn ich also damals (grandios vorausschauend und von langer Hand geplant) diese BTCs hinterlegt hätte, dann muss ich überdies mächtig Eier in der Hose haben, weil ein 45.x Bit PK über 2 Jahre in der Blockchain zu lassen...

Kurzum: Der erste richtige/tatsächliche Fund und ich hoffe sehr, dass sich der Eigentümer meldet. Wenn er dann nämlich einen anderen PK zu dieser Adresse hat, als vom Pool gefunden wurde, haben wir das Corpus Delicti.


Rico

[deadlock1]

Schön, nehmen wir mal an, dein Collider hat einen Schlüssel gefunden (was nicht bewiesen ist, aber ok, glauben wir das mal).

Dieser Schlüssel wurde vermutlich von einem User manuell erzeugt und dann umgesetzt.

Du gibst ja zu, dass der Schlüssel schlecht ist, also vermutlich handgemacht ( mach ich auch oft zum Test o.ä., allerdings achte ich schon darauf, dass er nicht zu einfach ist!).

Dass nur ein Minibetrag drauf war, unterstützt meine  These! Rechne doch bitte mal deinen Stundenlohn aus, hat sich die Aktion für dich wirklich gelohnt?  

Ich habe auch schon privkeys gefunden, auf welchen ein paar Satoshis drauf waren, diese wurden im Wiki oder im Forum als Beispiel verwendet und einige User waren wohl so leichtsinnig diese öffentlichen Beispiele zu verwenden. Oder es war ihnen egal, da es nur ein Test war mit kleinen Beträgen.

Das beweist jetzt nicht, dass der Collider funktioniert, nur weil du ein Testbeispiel mit winzigem Restguthaben aus vermutlich manuell angelegten Tests gefunden hast.

[rico666]

Schön, nehmen wir mal an, dein Collider hat einen Schlüssel gefunden (was nicht bewiesen ist, aber ok, glauben wir das mal).

Oh wie gütig. Danke. Könntest vielleicht noch gleich nachschieben wie ein von "euch" (ist das Pluralis Majestatis oder was?) zu akzeptierender Beweis aussehen müsste?

Dieser Schlüssel wurde vermutlich von einem User manuell erzeugt und dann umgesetzt.

Das ist nicht bewiesen und auch nicht wahrscheinlich. Schon mal einen Blockexplorer bemüht?
https://blockchain.info/address/1LgLVFKWnvYffKQdwYoKoPQvMvWNDYcS4x
Die 1PV... sieht für mich wie ein ganz normaler unspent Output aus.
Unterscheidet sie sich für Dich irgendwie von all den anderen?

Der Schlüssel ist tatsächlich schlecht und zwar so schlecht, dass den kein User manuell erzeugt.
Selbst eine schlechte Brainwallet -> durch einen SHA256 gejagt hat nicht die führenden 210 bits mit Nullen vollgekleistert.
Also keine mir bekannte.

Du gibst ja zu, dass der Schlüssel schlecht ist,

Ich gebe es nicht zu, ich stelle es fest.

also vermutlich handgemacht

Ich sehe nicht, wei man diesen Schluss ziehen kann.

Dass nur ein Minibetrag drauf war, unterstützt meine These!

Ich sehe Dich schon im Mittelalter nachweisen, dass eine Frau die nicht ertrinkt wenn man sie ins Wasser wirft aus Holz und folglich (alternativlos) eine Hexe sein muss und verbrannt gehört. Ehrlich - ganz deutlich vor meinem geistigen Auge sehe ich das.

Guggst Du  im obigen Blockexplorer nach. Sieht nach Standard Output aus. Etliche andere Adressen haben oder hatten nicht größere Beträge drauf.

Rechne doch bitte mal deinen Stundenlohn aus, hat sich die Aktion für dich wirklich gelohnt?  

Wäre da nicht der Smiley (den ich jetzt benevolent als "Satire" interpretiere), müsste ich fragen "Bist Du blöd?"

WENN es etwas gibt, was mich für die investierte Arbeitszeit entschädigt, dann ist es die Möglichkeit hier im Forum Deppen öffentlich vorzuführen. Und dazu gehören auch unqualifizierte Skeptiker.

Das beweist jetzt nicht, dass der Collider funktioniert, nur weil du ein Testbeispiel mit winzigem Restguthaben aus vermutlich manuell angelegten Tests gefunden hast.

Ich habe ja auch nicht vor den Collider nach dieser kleinen Schwalbe abzuschalten. Vielmehr sehe ich mit Spannung in die Zukunft um dann die Fakten gegen das Gerede hier im Forum abzugleichen.




Rico

[deadlock1]

also vermutlich handgemacht

Ich sehe nicht, wei man diesen Schluss ziehen kann.

Ganz einfach: Diese 2 Programme hier haben gefühlt schon 50.000 User verwendet (das ist keine Empfehlung!):

https://gobittest.appspot.com/Address

https://gobittest.appspot.com/PrivateKey

Da gibst du 11 Zahlen oder Buchstaben (A,B,C,D,E,F), sogenanntes Hexadezimalsystem   , ein und dann sind die ersten 210 Bits leer. Dann bekommst du deinen Public Key und deine Bitcoin-Adesse. Schonmal deine 44 Bits in Hexa umgewandelt??? Vielleicht kommt da ja mein Name!  

Wenn du die 11 Zeichen auf der 2. Seite eingibst unter "Private key to wallet import format", dann kannst du den später in dein Wallet importieren.

Das machen viele so, wenn sie unterwegs sind und keinen Zugang zu dem einem Wallet haben. Allerdings werden die Programme vorher lokal gespeichert und die Internetverbindung aus Sicherheitsgründen bei der Erzeugung unterbrochen. Der PrivKey + PublicAdress in 2 Minuten erzeugt und kann später locker in das Wallet eingefügt werden! (nur 11 Zeichen ist allerdings ziemlich unsicher wie man sieht!!!!)

Selbst eine schlechte Brainwallet -> durch einen SHA256 gejagt hat nicht die führenden 210 bits mit Nullen vollgekleistert.

Wenn es mit der obigen Seite generiert wurde und nur 11 Zeichen eingegeben wurden, hat es genau DEN EFFEKT!

[rico666]

Da gibst du 11 Zahlen oder Buchstaben (A,B,C,D,E,F), sogenanntes Hexadezimalsystem   , ein und dann sind die ersten 210 Bits leer. Dann bekommst du deinen Public Key und deine Bitcoin-Adesse. Schonmal deine 44 Bits in Hexa umgewandelt??? Vielleicht kommt da ja mein Name!  

Vielleicht auch nicht.


Code:

"0n?r

Wenn es mit der obigen Seite generiert wurde und nur 11 Zeichen eingegeben wurden, hat es genau DEN EFFEKT!

Es hat AUCH diesen Effekt. Natürlich - wenn wir von einem so kurzen PK reden.

Der Begriff "a posteriori" sagt Dir was?


Rico

[deadlock1]

Da gibst du 11 Zahlen oder Buchstaben (A,B,C,D,E,F), sogenanntes Hexadezimalsystem   , ein und dann sind die ersten 210 Bits leer. Dann bekommst du deinen Public Key und deine Bitcoin-Adesse. Schonmal deine 44 Bits in Hexa umgewandelt??? Vielleicht kommt da ja mein Name!  

Vielleicht auch nicht.


Wenn du einen DEAD Hexa-Code in deinem 44 Bit-Code findest, ist es von mir. Das sind dann Totcoins. Egal, du darfst alles behalten, was du von meinen Überresten findest! An meine Experimentalphase habe ich kaum noch Erinnerungen.

[rico666]

Wenn du einen DEAD Hexa-Code in deinem 44 Bit-Code findest, ist es von mir. Das sind dann Totcoins. Egal, du darfst alles behalten, was du findest! An meine Experimentalphase habe ich kaum noch Erinnerungen.

Da sieht man gleich, wer schon mal einen LBC benutzt hat und wer noch nicht. 

https://bitcointalk.org/index.php?topic=1573035.msg16530267#msg16530267

Die PKs kommen aus dem HRD_core immer als hex daher. Kein DEAD drin diesmal, aber ich werde das im Hinterkopf behalten.


Rico

[deadlock1]

Man kann die Elliptische Kurve auf diese Art nicht austricksen!

Aber die Idee, (zu kurze) manuell erzeugte Private Keys abzugreifen, ist nicht schlecht. Das war klug von dir bei 0 anzufangen. Wer rechnet denn damit, dass das tatsächlich jemand versucht!?  Sicherheitslücke Mensch!  

Viel Erfolg!

[rico666]

Man kann die Elliptische Kurve auf diese Art nicht austricksen!

Davon redet ja keiner. Aber man kann sich an die Schulmathematik erinnern und weiß, dass zwischen einer Menge von der Mächtigkeit 2²⁵⁶ und einer von der Mächtigkeit 2¹⁶⁰ einfach keine bijektive Abbildung hinzubekommen ist. Das ist ein Problem hinter der EC. (also später im Prozess), da kann die EC vorher rumturnen wie sie lustig ist.

Aber die Idee, (zu kurze) manuell erzeugte Private Keys abzugreifen, ist nicht schlecht. Das war klug von dir bei 0 anzufangen. Wer rechnet denn damit, dass das tatsächlich jemand versucht!?  Sicherheitslücke Mensch!  

Du hast es immer noch nicht verstanden. Aber egal - kommt schon noch. Kommt Zeit, kommen Gegenbeispiele.

Das war nicht ganz so klug von Satoshi hinter den SHA256 einen RIPEMD160 zu klemmen. Hätte er doch nur einen RIPEMD256 hergenommen. Naja er war vermutlich auch nur ein Mensch oder RIPEMD256 zu der Zeit nicht verfügbar. Ansonsten ist natürlich die Idee diese zwei Standards zu mischen schon elegant.


Rico

[rico666]

Ich sehe immer noch etliche Windows Clients, die den Go-Generator nutzen. Mittlerweile weiß sicher jeder, dass der neue (nur für Linux verfügbare) HRD-core Generator bedeutend schneller ist.

Ich kann mir allerdings vorstellen bzw. verstehe, dass die Mühe nur wegen dem LBC irgendwo in einer VM noch ein Linux zu installieren und dann noch obendrauf den LBC zu installieren für einen Windows User abschreckend sein kann. Ehrlich gesagt: Wäre ich nicht der Autor, wär's mir auch zuviel Gefrickel.

Ich habe daher heute eine Appliance geschmiedet. Sprich eine fertig installierte Linux-VM, die bereits einen aktuellen LBC samt allen benötigten Programmen und Dateien an Bord hat. Das ist momentan so Plug&Play, wie es nur geht.

Wenn der Download von ca. 1GB kein unüberwindliches Hindernis darstellt, dann kann man einen schnellen Collider auf Windows wie folgt bekommen:

• Man hat 64bit Windows und die CPU Virtualisierung ist eingeschaltet (Virtualization im BIOS)
• VMware Player für Windows downloaden und installieren (~75MB): http://www.vmware.com/products/player/playerpro-evaluation.html
• LBC Appliance downloaden (~960MB): ftp://ftp.cryptoguru.org/LBC/appliance
  Ist ein aktualisiertes Arch-Linux 64bit, mit einem fertig installierten LBC Jarvis 0.886 - einschl. neuer .blf, xdelta3, gcc
  
• Nur wenn man was braucht um ein .7z Archiv zu entpacken: http://www.7-zip.org/a/7z1604-x64.exe

1) archlinux.7z auspacken, braucht 2GB auf der Platte
2) VMware Player starten, Archlinux Image auswählen, auf "Play" drücken
3) Das Arch Linux ist von: http://www.osboxes.org/arch-linux/
    Nach dem Booten sieht man ein login, da gibt man ein
    username: osboxes
    password: osboxes.org
4) Im Kommandozeilen-Prompt gibt man ein

cd collider
./LBC -x

von da an: http://lbc.cryptoguru.org:5000/man/user


Rico

[rico666]

Bei updates hat LBC auf 1GB Maschinen bisher einen "out of memory angezeigt". Das kam daher, weil Dateien für einen hexdigest komplett in den Speicher geholt wurden. Ist mit Version 0.893 abgeschafft. LBC müsste nun schätzungsweise so ab 700MB Hauptspeicher (inklusive was das OS benötigt) laufen.

Des weiteren habe ich jetzt auch den "Pulsbetrieb dokumentiert" - siehe http://lbc.cryptoguru.org:5000/man/user#pulsedops
Damit kann man LBC selbst auf so schwachbrüstigen Maschinen wie den t2.micro Instanzen von Amazon btreiben.

(Ich habe so eine Maschine für 1 Jahr kostenlos bekommen und weiß nicht was ich sonst damit anfangen sollte)

Auf den Maschinen gibt es "CPU Credits", die sich relativ schnell verbrauchen, aber langsam wieder regenerieren. Mit einem "Pulsbetrieb" für den LBC (10 minuten an, 5700 Sekunden schlafen, 10 minuten an, ... etc.) kann man da LBC auch betreiben. Gibt zwar "nur" 2.8 GKeys am Tag, aber besser als mit einem rostigen Draht ins Auge gepiekst.


Rico

[Hardstyles]

hat schon jemand was gefunden?

intressantes project

[rico666]

hat schon jemand was gefunden?

Ja, http://lbc.cryptoguru.org:5000/trophies


Rico

[rico666]

Die News in Kürze:

• Ab Freitag 21., wird der Pool Client-Version 0.870 als Mindestvoraussetzung verlangen und so keine clients mit Go-Generatoren mehr akzeptieren.
• Der Pool hat heute Nacht ~ 2 Uhr GMT #46 der "Puzzle Transaction" gefunden - siehe Trophies
• Momentan macht der Pool ca 40MKeys/s, das wird noch steigen (plusminus auf 60MKeys), weil ich sehen möchte ob/wie der Server skaliert.

Vermutlich wird der Pool also in den nächsten 24h ca. 5 TKeys (5 Billionen Keys = 10 Billionen Adressen) checken.
Alle natürlich gegen die ca. 9 Millionen Adressen mit Funds drauf, also 90 Trilliarden checks.

Gut - ne? 


Rico

[rico666]

Die Wahrscheinlichkeit innerhalb 24h auf eine Adresse mit Funds zu stossen sind derzeit

0.000000000000002005488413420504643341989521735159876506643936%.

Irgendwie musste ich etwas schmunzeln als ich das mal mit Wahrscheinlichkeiten anderer ... "Tätigkeiten" so verglichen habe

0.00000000000000200548% (damals)
0.00000000000017024754% (heute)
0.00000000000020353947% (heute)

Immerhin - ca. 85101mal größere Wahrscheinlichkeit.


Rico

[schnebihacked]

Die Wahrscheinlichkeit innerhalb 24h auf eine Adresse mit Funds zu stossen sind derzeit

0.000000000000002005488413420504643341989521735159876506643936%.

Irgendwie musste ich etwas schmunzeln als ich das mal mit Wahrscheinlichkeiten anderer ... "Tätigkeiten" so verglichen habe

0.00000000000000200548% (damals)
0.00000000000017024754% (heute)
0.00000000000020353947% (heute)

Immerhin - ca. 85101mal größere Wahrscheinlichkeit.


Rico

Du meinst wohl eher 150x höher