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

Imposante Zahlen.
Nehmen wir an, ihr findet etwas.
Beispielsweise eine meiner Adressen und räumt diese leer.
Ist das nicht defacto Diebstahl?

Edit:
Waren unter den 500 Billionen Keys Treffer?

(citation needed)

Die Rechnung würde ich gerne sehen.


Wenn ich mir irgendeine chart seite ansehe, dann steht da momentan "Difficulty 440,779,902,287" - plusminus.
Also knapp 441 Milliarden mal schwerer als 2009. Das würde bedeuten, mit einem 2009er PC würde ich
441 mrd. * 10 minuten brauchen - oder? Da komme ich auf 8390410 Jahre.

Zwei mal hintereinander schaffe ich - bei gleichbleibender Difficulty - in 8390410² Jahren. Sind ja stochastisch unabhängig die Ereignisse,
70398979968100 Jahre. mit einem 2009er PC. Bei einem 64er müsste man den Geschwindigkeitsunterschied zum 2009er PC nehmen,
quadrieren und auf o.g. Endergebnis aufmultiplizieren.

Ich möchte nur anmerken, dass der Pool irgendwann August 2016 in Betrieb gegangen ist - mit ca. 300 Kkeys/s, Am 17.1.2017 hatte er
250 Billionen Schlüssel durch. Am 25.2.2017 hatte er 500 Billionen Schlüssel durch.

Ich hatte im August 2016 das gleiche Notebook das ich jetzt auch habe. Heute schafft mein Notebook 7.5 Mkeys/s - also 25mal mehr
als der ganze Pool zu Beginn. Ich weiß noch, wie ich mir gewünscht habe, dass der Pool mal 25-27 Mkeys/s schafft, weil das
laut Ryan Castelluccis Hochrechnung die Speed gewesen sein soll, mit der die 1-50 puzzle transactions leergeräumt wurden.

Heute wären 25 Mkeys/s lahm.

---

Ich bin gerade dabei die libsecp256k1 zu kippen und einen ganz neuen ECC Code einzubauen Mein Notebook sollte dann
irgendwas zwischen 15 und 24 Mkeys/s haben.


Rico

Also nur im das mal in Relation zu stellen:
Die Wahrscheinlichkeit so eine Nadel im Heuhaufen zu finden ist geringer, als mit einem C64 zu minen und zwei Blöcke in Folge zu finden.


Edit:
Zumindest momentan. In sechzig Jahren sieht es anders aus und von euch aufgebaute Know-How bezahlt kann sich machen.

Also, über den Finderlohn für den Gegenwert von momentan 57000€ würde ich mich freuen.
Wenn du das als Peanuts wegsteckst, bitte.
Und es gibt sicher noch andere, größer gefüllte Adressen, das genannte war ein Beispiel...
Wie ist es mit dem Verlust von MtGox?
Oder dieser?
Sind nur 13BTC, kommen aber immer wieder welche dazu. Warum auch immer.

Schließlich kann niemand die BTC außerhalb der Blockchain lagern, und es sind ja schon über 15 Millionen gemined worden, da werden also schon noch einige Brocken drin sein.

Dazu muss man wissen, dass dieser "Schatz" in 50 BTC Häppchen auf unterschiedlliche Adressen aufgeteilt ist. Man kann also mit dem Brute-Force Ansatz bei einem Treffer immer nur maximal 50 BTC (manchmal vielleicht noch etwas Dust Spam dazu) finden.

@Rico666
Ach so, die Puzzles liegen an definierten Stellen...
Entschuldige bitte, Google hat mich über die "Puzzle-Transaction" nicht aufklären können, früher oder später landet das alles bei Rico, dem LBC oder hier im Forum.
Danke für die Aufklärung.

@denk0815
Mining nicht?
Und stell dir mal vor du findest den sagenumwobenen Schatz von Satoshi, und darfst 0,1% Finderlohn einhalten. Oder sogar 100%
Dann lohnen die paar kWh definitiv.
Außerdem macht es Spaß, weil man es mit seinem normalen PC noch kann, und wenigstens eine Chance hat was zu sehen.
Mining ist zumindest mit PC unmöglich, und selbst mit einem Miner unwirtschaftlich und teuer.
Und man lernt was. Ne Menge. Wenn man will.

Nach kurzem Überfliegen stellt sich mir eine Frage:
Ist es nicht irrwitzig unwirtschaftlich?

#51 ist zwischen 2^50 und 2^51

Wir sind derzeit bei 2^48.92 und Y keys/s schnell. Ein Tag hat 86400 Sekunden, Ab da ist's 5. Klasse. 


Rico

Danke.
Endlich hast du meine Vermutung bestätigt. 
Verzeih meine unmathematische Ausdrucksweise, ich bin ja lernwillig, aber unstudiert. 

Das man natürlich über eine gezielte Suche rumpfuschen kann mit der Suchzeit, sieht man ja jedesmal an den 4 Testadressen.

Bei -p kann man ja auch nur "die Seite (directory.io)" zuteilen, oder? Also, ich kann nicht sagen "zeig mir den Schlüssel zu Adresse xxx" sondern nur "klapper Seite xxx" ab, aber auf welcher Seite meine Adresse steht ist die Frage.
Von daher kann man die Puzzles nur nochmal "lösen", wenn sie zufälligerweise schon gefunden wurden und der Finder die Seite angegeben hat.
Ich gehe also immer vom Ideal aus: nur der Poolserver teilt den Suchraum zu.

Und ich denke auch, das der LBC noch massiv an Speed zulegt, wenn du weiter Updates einbaust, die den Prozess beschleunigen, und ja auch immer wieder User dazukommen.
Ich meinte nur prinzipiell, das es lange dauert, und der von dir gegebene Grund "bis der LBC da ist, dauerts noch" ist genau wo ich hinwollte.

Ich könnte meine BTC also sehr wohl "mutwillig" verstecken, wenn ich den LBC beobachte und die Ware immer transferiere wenn er in die Nähe meiner Seite kommt.
In der Hoffnung, das niemand zufällig meine Seite via "-p" anwählt, das wäre natürlich fatal, aber isso.


Wo wir gerade dabei sind:
Auf der Stat-Seite steht, das #51 in x bis y Tagen gefunden werden wird.
Wie kommst du da drauf? Kannst du bestimmen, in welchem Bereich der Key ist?
Also quasi "Seite 1 Mio bis 2 Mio, irgendwo da drin isser"?
Kann man einen Teil der Bits der Seite zurückberechnen?

100%


Theoretisch. Nämlich dann, wenn alle Clients im Auto-mode fahren würden (sprich den Suchraum vom Server zugeteilt bekommen - das läuft effektiv auf eine inkrementelle Suche hinaus).
Praktisch jedoch, gibt es noch den "-p" Parameter, wo Leute/Clients selbst bestimmen können welchen Suchraum sie abgrasen möchten.
Und das machen die auch, wenn sie z.B. die Puzzle-Transactions selbst finden wollen (einfach mal sehen wie das aussieht bei einem hit).

Da wo der LBC schon war - das ist noch ein winziger Suchraum. Ich gehe davon aus, dass wir noch viel schneller werden und dann sind 2^49 Schlüssel "nix".

Wenn ich meinen Key vor dem LBC verstecken müsste, dann würde ich mir tatsächlich einen Key bei 2^159 + n aussuchen, sprich in einem Band nach 50% unseres Suchraums. Denn:

• bis der LBC da ist, dauerts noch
• der Key ist im 2^160 Wertebereich, also ist die Wahrscheinlichkeit für einen Kollisionszwilling in diesem Bereich geringer.

Also fiele die Wahl auf Seite (2^159 + rand(2^158)) / 128 (auf directory.io)

Und ich würde wohl eine Uncompressed Adresse nehmen, weil die sieht der LBC zwar auch, aber die ganzen anderen Tools wie oclvanitygen nicht.


Rico

Okay, du hast recht. Die Anzahl der Keys hat sich danach von 2^160 auf (2^160)-1 reduziert. Das ändert die Wahrscheinlichkeit, dass der nächste private key wieder zu deiner Adresse gehört aber nur sehr unwesentlich.....

Ich gebe aber ehrlich zu, dass ich hier auch nur über Halbwissen verfüge und vielleicht ist es auch Blödsinn was ich sage...

Ähm, doch, in diesem Fall hat der Würfel ein Gedächtnis, denn der Suchraum ist ja reduziert?!
Innerhalb des Suchraumes ist für jede Adresse ein Key zu erwarten, aber da es 2^160 Keys gibt, und der Suchraum 2^160 ist, sollte jeder Key genau einmal drin sein.
Ich gehe davon aus, das es Ausreißer gibt, die nicht oder mehrfach im Suchraum sind, aber die Regel sollte "einmal" sein.
Also kann der LBC meinen Würfelstand nicht nochmal würfeln, weil der Würfel in Wirklichkeit ein Zähler ist.

Das ist ja genau das was ich versuche zu beschreiben.
Und ich meine nicht, das ich Angst hätte das der LBC eine meiner gewürfelten Adressen findet.
Sondern das der LBC eben genau jede Adresse einmal findet, aber nicht sagen kann, welche wann dran ist.
Also spare ich auf eine die er schon gefunden hätte, wenn denn Geld drauf gewesen wäre und sie somit in der BLF gewesen wäre, und dann kann der den Key nicht mehr finden, auch wenn sie drin ist, da er den passenden Zählerstand (Die Seite auf directory.io) schon überschritten hat.

Oder?

Das mit der gigantischen Zahl von 2^96 Schlüssel pro Adresse wusste ich schon, und bin immer wieder beeindruckt, das sooo viele Clients jeder für sich und völlig unkontrolliert Adressen würfeln können, ohne das sich das jemals überschneidet. Zumindest ist es extreem unwahrscheinlich, das zwei Leute würfeln und beide zwei verschiedene PrivKeys bekommen für den gleichen Pubkey.

Mir ging es um das Suchprinzip, und jetzt kommts was ich meinte:
Der Server zählt ja quasi die Seiten von directory.io durch. Das ist ja auch ein Zähler, keine Liste, also wird als Seed für den Hash eine fortlaufende Zahl benutzt. Der Hash ist dann eine wirre pseudozufällige Zahl, die keinen Rückschluss auf den zugrundeliegenden Seed zulässt, sonst hätte man alle Verschlüsselungen schlagartig ausgehebelt.

Der LBC scannt aus Vereinfachung nur 2^160 Keys, und wenn man davon ausgeht, das es ja 2^256 Adressen gibt und die Schlüssel statistisch schön verteilt sind, so ist zu jeder der 2^256 Adressen/PubKeys ein PrivKey in dem 2^160er Suchraum, die anderen 2^96-1 Privkeys sind in den anderen Suchräumen, die der LBC nicht macht.
Soweit noch ok?

Dann kommt mein Problem:
Der LBC generiert Schlüssel nach dem gleichen Prinzip, und aktuell ist er auf Seite 4065 Billionen und irgendwas.
Ich nehme nun einen bereits gelisteten Schlüsselsatz von Seite 1 und kann da BTC bunkern, die der LBC nicht sieht, selbst wenn die BLF meinen Kontostand enthalten würde. (Jaja, Seite 1 . Seite 471108152017, der dritte von unten.)

Schließlich kann kein anderer Schlüssel aus dem Suchraum passen, denn im 2^160er Suchraum ist jeder Schlüssel statistisch genau einmal drin. Ja, es gibt vielleicht welche, die gar nicht oder zweimal dabei sind, aber statistisch haben die meisten Menschen mehr Beine/Arme/Augen/Ohren als der Durchschnitt.
Von daher ist meine Adresse & mein Schlüsselpaar sicher, denn der LBC sucht hinter mir, kommt also erst wieder, wenn der Server neu gestartet wird und bei Null anfängt zu zählen.
Bei Seite 1 wäre es easy, "0"->Hash->passt->arm.
Bei Seite 4065 Billionen: "grooooße Zahl"->Hash->passt->arm.
Aber eben: der LBC muss erstmal bis dahin zählen, und das dauert "ewig".

Und nu:
Reden wir aneinander vorbei, oder bin ich zu doof?

Es kann Adressen geben, die dem LBC "vielleicht entkommen", weil die BLF nicht aktuell genug ist. Das hängt aber von der Updatefrequenz der BLFs ab und nicht von der gesamten Laufzeit des LBC.

Was ich versucht habe klarzumachen (und nicht sicher bin ob mir das gelungen ist), dass es hier kein "davor" oder "dahinter" gibt wenn man sich den Suchraum anschaut. Man kann den Privkey inkrementieren, aber das hat mit dem numerischen Wert des hash160 herzlich wenig zu tun, der springt scheinbar chaotisch hin und her.

Du bist zu sehr in dem Gedanken verfangen es gäbe nur einen privkey zu einer Adresse. Wirklich. Dem LBC ist es ja egal welchen der 2^96 privkeys er findet. Und da diese prinzipiell gleichmäßig über den gesamten Suchraum (2^256) verteilt sind, wird sich im Schnitt auch einer davon in den ersten 2^160 bits befinden.

Einer davon. Der muss numerisch mit dem "originalen privkey" überhaupt nichts zu tun haben. Aber ja: Wenn die BLF 2 Wochen nicht aktualisiert wurde, dann sind alle Adressen, die vor 2 Wochen noch leer waren für den LBC immer noch leer. Und alle Adressen, die in den 2 Wochen geleert wurden, könnten einen hit provozieren, beim Nachsehen aber bereits leer sein.



Rico

Danke für die Antwort, aber du hast da zuviel reininterpretiert!

Es geht mir nicht darum, das der LBC meine paar Satoshis klaut, sondern ich hatte Überlegungen mit Bekannten.
Und die sind drauf gekommen, das der LBC ja im Vergleich zum Adressraum relativ langsam sucht, das dauert ja Monate, minimum, für einen vollen Scan.
Wenn jetzt ständig Bewegung in der Blockchain ist, könnte ja Guthaben auf eine Adresse "von eben" oder "bekannt aber leer" kommen, und...
- letzteres (Blockchain-bekannte Adresse mit 0 BTC wird gefüllt) würde der LBC erst wieder mit der neuen BLF-Datei scannen, d.h. Clients mit alter BLF finden nichts, obwohl sie evtl. sogar im Suchbereich wären.
- ersteres (Guthaben auf Adresse im bereits abgegrasten Suchraum verschoben) hat neben dem Problem der alten BLF auch noch, das der LBC ja gerade erst da war, und demnach erst in Monaten wiederkommt und hier nachsieht.

Der LBC kann ja nicht den ganzen Suchraum immer wieder durchgehen, sondern wir sind aktuell bei 49 bits, d.h. Bit 49 ist 1, alle darunter werden quasi gezählt, also 1...000, 1...001, 1...010 usw.
Wenn meine neue Adresse einen Schlüssel mit "Bit 49=0" hat, dann waren wir da schon, und die Suche nach einer Kollision mit meiner neuen Adresse würde wieder die gesamte Laufzeit des LBC brauchen.
Oder?

Ich bin sicher, das ich da ganz falsch bin, aber wenn du es nicht weißt, weiß es keiner.
Wenn ich recht hätte, würde das ja bedeuten, das der LBC nur Adressen mit Guthaben finden kann, die effektiv während der gesamten Laufzeit des LBC unberührt waren (bzw. zufällig gerade passend in den zu durchsuchenden Bereich fallen), und das wäre ja schade.

Ja, das passiert ja auch: ftp://ftp.cryptoguru.org/LBC/blf/



Ich sage es ungern, aber es sollte keine "Angst weil meine Adresse demnächst gescannt wird" geben. Weil nämlich das Gegenteil - die "Zuversicht , dass meine Adresse weit weg ist" auch nicht existieren sollte. Bzw. so eine Zuversicht ein Trugschluss ist.

Stell' Dir vor, Dein Privatkey ist irgendeine große Zahl 2^240 irgendwas. Der LBC knödelt momentan bei 2^49 rum. Ist doch hübsch weit weg - oder?

Falsch!

Eine Kollision ist ja genau der Vorgang, dass ein Schlüssel - und der kann durchaus nur im 2^49 Wertebereich sein - in die gleiche Adresse aufgelöst wird, wie eben ein Schlüssel aus dem 2^240 Wertebereich. Die Wahrscheinlichkeit ist klein, aber nicht 0. Die Stats-Seite zeigt ja diese Wahrscheinlichkeit für die nächsten 24 Stunden an.

Wenn Du Angst haben solltest, dass der LBC Deinen Schlüssel findet, dann kann ich vorerst nur empfehlen auf eine P2SH Adrese zu transferieren, weil wir da (noch) nicht suchen.


Rico

Ich hätte da mal eine Verständnisfrage.

Der LBC sucht ja alle Adressen mit Guthaben ab.
Die stehen in einer Datei, extrahiert aus der Blockchain, nehme ich an.
Da sich die Adressen ständig ändern und erweitern, muss auch diese Datei erweitert werden, oder?

Wenn ich jetzt Angst hätte, das meine BTC in Gefahr sind, weil "meine Adresse" demnächste gescannt wird: könnte ich das Guthaben transferieren, auf eine Adresse im bereits durchsuchten Bereich, weil da nicht mehr gesucht wird? (Zumindest bis zum nächsten Update der "Schlüsseldatei"...)
Oder sogar erst mit einem kompletten Neustart des LBC-Systems, also ab "Bit 0"?

Wo ist mein Fehler? (Ich bin mir sicher, das ich da was falsch verstanden habe...)

Hallo Ricco,

läuft jetzt alles.  Vielen Dank.


Gruß Carsten.

Ja, die Datei sollte ausführbar sein, hook-find heißen, dein Kommando in Zeile 2 oder 3 stehen haben und in Zeile 1 sollte eben jenes #!/bin/bash stehen, welches besagt "Dies ist ein Shellskript, also bitte als solches ausführen".


Rico