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

also willst du keinen privaten schlüssel zu einer adresse finden? was willst du dann?



der beweis ist schon erbracht? es wurden ausreichend kollisionen gefunden und sie verteilen sich genügend gestreut im suchraum?


EDIT:


deshalb immer schön deine bitcoins stückeln, gell.

https://lbc.cryptoguru.org/man/theory

Wenn Du da drin etwas findest, was nicht stimmt, nehme ich gerne Korrekturvorschläge entgegen.

Ob der Pool eine Kollision gefunden hat oder nicht, ist offen (= strittig):

https://lbc.cryptoguru.org/trophies

Denn genauso gut kann ich anzweifeln, dass f6cc30532dba44efe592733887f4f74c589c9602 und 378e8af588e6433032d0f5fb548431408c4bcb3c originär tatsächlich mit den Privkeys erzeugt wurden, die der Pool gefunden hat.

also auch EDIT:


Also zu "charakter" eines Algorithmus kann ich Nichts sagen, das ist ein wenig zu esoterisch und somit nicht mein Fachgebiet.

Was ich sagen kann ist, dass es keine Verdichtung von Information gibt. Es gibt eine Reduktion oder eine Transformation von Information. Erstere ist unumkehrbar, also meinst Du vermutlich das. Wenn diese unumkehrbar ist, gibt es auch keinen Weg (nichtmal den einzigen über eine Kollision) auf die Ausgangsinformation zu kommen.

Nochmal: die Gleichverteilung der bekannten Hash-Algorithmen wurde exzessiv untersucht und für gut befunden. Auch den sog. Avalanche-Effekt weisen diese auf. (1bit Änderung am Input resultiert im Schnitt in der Änderung von 50% der bits beim Output). Arulbero hat im englischen Thread sogar noch seine eigenhändig vorgenommenen statistischen Untersuchungen zu diesem Thema gepostet.

EDIT2: (Du machst mir Spaß)

Quantencomputer sind das Vorzeigeprodukt für die Behauptung eine Geschwindigkeitsverdoppelung reduziere den Suchraum um 1bit. Ein N-bit Algorithmus auf einem N-bit Quantencomputer ausgeführt hat potentiell eine O(1) Laufzeit. Jedes Qbit verdoppelt die effektive Geschwindigkeit eines Quantencomputers. Ein 256qbit Quantencomputer könnte folglich - mit dem richtigen Algorithmus - einen validen (merke: nicht den originalen) SHA256 Input zu einem gegebenen Output instantan finden.

Das ist auch kein "überproportionales Parallelisieren". Die Rechengeschwindigkeit wächst einfach nur genauso exponentiell wie der Suchraum (N Qubits:bits), das ist geradezu harmonisch proportional.


Rico

wie führst du den beweis ohne je eine kollision gefunden zu haben?

EDIT:


das ist die lineare annahme. kann man mathematisch beweisen.

der algorithmus hat aber einen "charakter" den er in die ergebnisse "einfliessen" lässt.

es ist eine verdichtung von informationen welche nicht umkehrbar ist. der einzige weg auf die ausgangsinformationen zu kommen ist nach kollisionen in einem riessigen suchraum zu suchen. kennt man den "charakter" des algorithmus kann man den suchraum eingrenzen da man weiss dass die ergebnisse in bestimmten bereichen des suchraums bevorzugt auftreten.

EDIT2:

sobald man die suchprozesse überproportional parallelisieren kann (quantenmechanik) spielt die grösse des suchraums keine grosse rolle mehr für den bruteforce angriff. es wird dann eine ökonomische frage sein ob man zum ziel kommt. man hat eine adresse mit 1 BTC drauf und muss 10 BTC dafür aufwenden um die kollision zu finden. also lässt man es.

Nimm Du es mir bitte nicht übel, aber nach knapp 8 Monaten Entwicklung, wobei ich meine eigene SHA256 Implementierung sowohl auf CPU wie auch auf GPU vorgenommen habe (genauer gesagt zwei Implementierungen, jeweils eine für uncompressed und compressed public keys) und eine eigene RIPEMD160 Implementierung, speziell auf den SHA256 output (hier als Input) zugeschnitten - wiederum für CPU und GPU...

nach ausführlichen Benchmarks schnellster Code weltweit (von dem was öffentlich zugänglich ist)...

bin ich mir wirklich nicht sicher, was ich von der Aussage "Du vergisst den Hash Algorithmus" halten soll. Nicht nur vergesse ich diesen nicht, ich kenne ihn in- und auswendig. (Und kann deswegen auch sagen, dass die RIPEMD160 Autoren ziemlich einfallslos von SHA256 abgekupfert haben)

---

Es gibt kein "schieben in bestimmte Bereiche des Suchraums". Diese Kryptoanalyse haben SHA256 und RIPEMD160 lange hinter sich. Sie verteilen uniform - das macht sie ja zu guten Hash Algorithmen. Genau weil sie jedoch uniform verteilen, kann man auch von einem Abbild aller Privkey -> Adresse Paare in den ersten 160bit "des Suchraums" ausgehen. RIPEMD160 sei Dank.

---

Ich gebe zu, ich bin gemein. Ich stelle Fragen, zu denen ich lange die Antwort kenne. In diesem Fall eben Äquivalenz von Suchgeschwindigkeit und effektiver Suchraum (bezogen auf eine Zeitkonstante). Sprich:

Brauche ich mit Prozess A für 8bit 256 Jahre und finde einen Prozess B, der doppelt so schnell ist wie A, dann braucht Prozess B eben 128 Jahre. Was effektiv die Zeit ist, die A für 7bit bräuchte. Klar? Natürlich kann man den Suchraum auch effektiv verkleinern indem man analytisch vorgeht und z.B. Symmetrien aufdeckt (pro Symmetrie hat man auch oft eine Reduktion von 1bit) - das bleibt ja weiterhin unbenommen.

Und wer den englischen Thread verfolgt hat, weiß, dass gerade diese Analysen für ECC nochmals eine erhebliche Steigerung der Suchgeschwindigkeit nach sich ziehen werden.


Rico

nimm es mir nicht übel, aber du vergisst den hash algorithmus. um die kollision zu finden darf man nicht davon ausgehen, dass der suchraum die wahrscheinlichkeit linear mit abziehen von bits verringert vergrössert wird. der algorithmus "schiebt" die ergebnisse in bestimmte bereiche des suchraums. deshalb sprach mezzo von kryptoanalyse. man versucht diese gewichteten bereiche zu finden.

EDIT: platt ausgedrückt, suchst man sich im falschen teilbereich des suchraums zu tode während in den "richtigen" bereichen des suchraums die wahrscheinlichkeit steigt mehrere kollisionen zu finden

EDIT2: aber es ist trotzdem ein interessantes projekt. hoffentlich läuft es noch lange oder besser solange BitCoin existiert.

Durch die Fähigkeit auch ohne wolframalpha nachdenken zu können.


Rico