Topic: Bitcoinbasics, vielleicht eine Moeglichkeit BTCs geziehlt zu generieren - page 8. (Read 8395 times)

hallo,
scheinst ahnung zu haben.
wie du schon gesagt hast, w0...w15 ist ein teil der orginalnachricht. wenn ich also das w-array komplett habe, habe ich 16 * 4 zeichen von diesem teil der orginalnachricht.
wenn die orginalnachricht kuerzer als das ist, habe ich sie komplett, was bei recht vielen passwoerter zb. zutrifft.
da es z.zt. nur um kollisionen geht, brauche ich die genaue oder ganze orginalnachricht ueberhaupt nicht, koennte sie aber einfach durch weitersuchen irgendwann mal rausfinden.
wenn ich von der w-funktion schreibe, meine ich einfach nur den verlauf der einzelnen werte des w-arrays.
da das nur einfach eine summe aus vier summanden ist, hat diese funktion einen recht karakteristischen verlauf. wenn diese summe mit ueberlauf waere, haette ich sie jetzt schon, aber die addition ohne ueberlauf macht die inverse funktion etwas komplizierter, aber meiner meinung nach nicht unmoeglich.
anfangs hatte ich angenommen, dass der ueberlauf viel weniger stattfindet, was sich aber als falsch herausgestellt hat.

wenn ich den w63-wert errechnet habe, hat dieser nichts mit einer kollision zu tun, sondern sagt mir nur, dass alle moeglichen kombinationen, die diesen wert haben, eine moeglich kombination fuer eine kollision sind.
damit mache ich den look forward.
also alle die diesen wert nicht haben, brauche ich ueberhaupt nicht zu probieren, weil es keine moeglichket gibt, dass es eine kollision sein koennte.
fuer den nonce funktioniert das allerdings leider nicht, weil ich da ja keine kollision, sondern nur die nullen moechte.
koennte mir an sich irgendeinen hash vorgeben und dann die kollision suchen, aber das waere dann nicht unbedingt der optimalste, ausser ich habe unheimlich viel glueck und ich will ja kein glueck, sondern optimierung.

das wort angriff gefaellt mir zwar nicht unbedingt, kannst es aber so nennen, wenn man moeglichkeiten aufzeigt, wie man das umgehen kann, wofuer es an sich gemacht ist...

auch wenn ich es jetzt schon einige mal erklaert habe, hoffe ich, dass es jetzt mit diesen worten halbwegs klar geworden ist. muss jetzt allerdings zu meiner gerichtsverhandlung...

Weniger Rechenleistung als Bruteforce zu benötigen, wäre ein Angriff auf Hashfunktionen.

Die "W-Funktion" ist doch nur 32 bit lang, natürlich tust du dir da viel leichter, Kollisionen zu finden. Wie genau würdest du eine Kollision dort ausnutzen, um einen kompletten SHA256/384/512 Hash (teilweise) vorhersagbar zu machen? Außerdem sehe ich nirgendwo die Vorraussetzung, dass diese Funktion möglichst stark gegenüber preimage-Angriffen sein muss, ich nehme an, sie soll einfach nur die Inputs einigermaßen gut aufteilen und miteinander verknüpfen. Sieht man auch schön daran, dass w0-w15 einfach 1:1 der Input sind...

hallo @Sukrim,
scheinst der einzige zu sein, der mich hier ernst nimmt. ich will nicht beweisen, dass sha angreifbar ist und noch weniger, dass ich es kann. dass kollisionen existieren weiss jeder und ist ja auch logisch.
dass diese ueber brute force ermittelbar sind, ist auch jedem klar.
also brauche ich da ueberhaupt nichts zu beweisen.
alles was ich an sich vor hatte, war den brute force inteligenter zu machen, also in den bereich von kleinerer rechenkapazitaet zu bringen. anfangs fuer die nonce-berechnung, was aber jetzt so ziemlich verloren gegangen ist.
mein ansatzpunkt ist zur zeit die w-funktion, bzw. das w-array.
diese funktion hat eigenschaften und ist meiner meinung nach beobachtbar, d.h. rueckwaertsgangfaehig.
da ich bis jetzt aber noch nicht sehr viel damit weitergekommen bin, habe ich erst mal die suchmenge von brute force auf die w63-werte eingeschraenkt, die auch ein erfolgseerlebniss haben koennen. also damit die gesammtmenge vom brute force unheimlich reduziert, da der w63 rueckrechenbar ist.
der eigendliche sinn sollte sein, aufzuzeigen, dass nicht mal der sha512 wirklich sicher ist, wenn man die entsprechenden moeglichkeiten hat, wo ich aber leider nicht dazu gehoere.
wenn ich es schaffen sollte, in der w-funktion zurueckzugehen, dann waeren damit die hashfunktionen so ziemlich gestorben, also ist die wahrscheinlichkeit dafuer recht klein, aber wie sie hier schon geschrieben haben, auch ein blindes huhn...
und es gibt ja auch jede menge lotogewinner, obwohl da die wahrscheinlichkeit wirklich winzig ist.

du scheinst oesterreicher zu sein. schoenes land. falls du mal in suedamerika vorbeikommst, koennen wir ja mal einen tee trinken gehen

Python sollte eigentlich recht einfach handzuhaben sein. Wenn es eher simpel ist und du dich eh schon gut mit diversen Zahlentypen auskennst (z.B. wie man Overflows etc. erkennt) könntest du es auch gleich in C schreiben. Speichermanagement ist dann halt nicht so lustig...

Für einen einfachen Beweis, dass du Hashes (teilweise) angreifen kannst sollte Python aber schon locker reichen.

auch wenn die wahrscheinlichkeit hoch ist, aber ich moechte keine werbung fuer dieses produkt machen. hat reichlich viele bugs, auch wenn es mit visual basic arbeitet...
g-basic haben sie mir noch im studium beigebracht, genau wie pascal, und sonstiges, dass heute keine bedeutung mehr hat.
es direkt in assambler zu machen, ist mir zu aufwendig. nicht mal delfi, der nachfolge von pascal ist noch aktuell.
also was schlaegst du vor?

hab mich mal versucht in lazarus einzuarbeiten, bin aber halt nicht mehr so flexibel...

Ja, gibt es. Dort läuft Excel dann aber nicht mehr so toll, du solltest das dann schon in etwas brauchbareren Programmiersprachen formulieren.

das war an sich ernst gemeint

aber wenn ich die btc geknackt haette, dann wuerde ich hier sicher nicht mehr rumhaengen.

da mein schlaptop nur 4g ram hat und das tabellenkalkulationsprogramm nach 1,8 g abstuerzt, habe ich etwas laenger gebraucht. vor allem bis ich rausgefunden habe, wie die daten dabei nicht verloren gehen.

aber bei meinem limit von ca 300 000 versuchen sind nie mehr als 30 paare drin, auch wenn ich laengere zeichenkentten nehme. hab es bis jetzt bis acht ausprobiert, glaube aber nicht, dass sich mit mehr noch viel aendern wird.

um einen bestimmten w63-wert rauszufinden habe ich noch nicht genug geduld gehabt. nach ein paar stunden suche habe ich abgebrochen.

gibt es sowas wie "cloudcpuzeit", die man mieten kann? wuerde es gerne mal auf etwas potenterem ausprobieren.

War doch klar, dass der Kurs abstürzt, nachdem Du erfolgreich den Nonce und damit Bitcoin geknackt hast.

hallo,
nur, dass es hier nicht zu langweilig wird:
kann  mir jemand von den kapos hier erklaeren, warum der btc-kurs so uebel am abstuerzen ist?

will ja nicht sagen, wie gewonnen so zerronnen, aber irgendeinen normalen grund muesste das doch haben. vor allem weil keine andere kypto so einen aufschwung hat. gehen die penner jetzt wieder auf normales geld zurueck?

hallo,
also ich finde es toll, dass ich hier immernoch so viel echo habe und vor allem von kapos.
alle schreiben, dass es nur muell ist, aber so lange sie es schreiben, ist es besser als nichts.
ehrlich gesagt, ist der hauptzweck an sich nur noch unterhaltung.
meine konkreten fragen waren an sich andere, sind aber an sich ja auch nebensaechlich.
dass ich basic gelernt habe ist erst schlappe vierzig jahre her, aber die konzepte habe ich an sich meiner meinung nach klar.
dass vier byte in den longint fuer die berechnung eingehen, weiss ich schon und bei meinen sechsstellligen proben habe ich damit zwar nur die ersten zwei longints halbwegs belegt, aber ich gehe davon aus, dass die w-funktion sich nicht so verschieden mit mehr belegungen verhaelt.
selbst, wenn noch viel mehr gleiche w63 werte auftauchen, als ich dachte, habe ich an sich schon eine vorauswahl fuer den brute force, um ihn schneller zu machen.
dass es nur noch um kollisionen geht, tut mir leid, aber ich bin nun mal in diese richtung weitergegangen, da ich an sich meistens den leichteren weg gehe. und da nun mal der w63-wert recht einfach ausrechenbar ist, wird das halt meine vorauswahl.
wieviel das im endefekt in optimierung ausmacht, weiss ich nicht, aber da es nur 13 paare in meinen 300 000 werten waren, gehe ich davon aus, dass es das brute forcen um einiges schneller machen kann.
und der sha ist ja meiner meinung nach genau so angelegt, dass es moeglichst wenig gleiche geben sollte.

da das brute forcen nur mit wirklich grossen rechnern einen sinn hat, werde ich das wahrscheinlich nicht ausprobieren koennen.

waere halt schoen gewesen, wenn mir jemand geschrieben haette, dass die w63-werte von meinen gefunden strings uebereinstimmen (oder auch nicht), anstatt es als muell darzustellen.
aber egal.

also ich hoffe, die chips waren schoen salzig...

Genitaler als was?

Genitaler als E=m*c*c.

Und was für ein Genital überhaupt? Und von wem?

Na dann gute Nacht. Wenn der gute alte Einstein das schon gewusst hätte. Gab es also doch noch ne grössere Eselei ... obwohl, Esel haben ja bestimmt auch grosse Genitale.

Wen es interessiert, der google doch mal den Begriff:

Vollbitverschlüsselung

und lese die entsprechenden Kommentare. Der eine oder andere wird ein Deja-vu haben.

Er weiß, was der LBC ist. Das wurde schon in diesem Thread hier behandelt. Fori hat auch schon im LBC-Thread rege mitgeschrieben (mit genauso wenig Hintergrund wie hier) und selbst Rico hat sich in diesem Thread hier schon gemeldet gehabt.

Alter.  

Ein Merit ist ein Merit, und du kannst so viele sMerit (sendable Merit) vergeben wie du hast.
Ein Merit ist so was wie bei Facebook ein Like.

Der Text "123" ist genau das: ein Text. Er besteht aus den 3 Zeichen "1", "2" und "3", deren ASCII-Code nun mal 49, 50 und 51 sind.
Wenn du also einen Text aus Bytes selber baust, gibst du "Byte mit Wert 49" an, und raus kommt "1"
Und das macht CHR: "Erzeuge ein Zeichen mit ASCII-CODE x".
STR macht aus einer Zahl einen String. Damit kannst du aus der Zahl 1234 den String "1234" erzeugen, und nein, das ist nicht das gleiche!
Das war jetzt mal BASIC für Anfänger.

Das dir nicht aufgefallen ist, das deine Zahlen < 32bit sind und so nur eine Stelle im Array belegen, mal geschenkt.
Das du nicht weißt was der LBC ist, geschenkt. (Such hier im Forum, dann kommst du drauf. Macht was du willst, nur eben auf die einzig möglche Art: Brute Force)
Aber bei den Kollisionen siehst du den Wald vor lauter Bäumen nicht:
- Du willst aus einem Hashblock den W-Block errechnen
- Das geht, weil W ja pro 512bit Nutzdaten 512bit (die ersten 16 Longs) Nutzdaten enthält.
- Geistesblitz!
- Du rechnest aus dem Hashblock den W aus und hast den Nutzblock.
- Yay

Dumm nur das das nicht geht.
Und du brauchst das Array nicht errechnen, weil die Originaldaten schon drin sind, wie dir ja aufgefallen ist. Den Rest des Arrays zu errechnen ist also sinnlos.
Das Array an sich zu errechnen ist allerdings unmöglich, aber aus mir unbekannten Gründen geht das bei dir nicht rein.
Daher meine Anmerkung: Es wäre sinnvoller für alle, wenn du ein wenig aus dem Fenster sehen würdest.

Deine Tabelle mit 6-stelligen Zahlen (die du vermutlich als Strings benutzt, was mal eben nur 6 Bytes mit je 10 Möglichkeiten also knapp über 3 Bit entspricht) ist vollkommen sinnlos, weil SHA nunmal jede Menge 32bittige Zahlen benutzt.
Nur weil was mit "123456" geht bedeutet das nicht das es auch mit 4294967296 geht. Und ja, die Anführungszeichen fehlen da absichtlich

Ich bin mir sehr sicher, das du da allen möglichen Scheiß ausrechnest, aber nichts davon hat auch nur im entferntesten mit SHA, Hash oder W-Arrays zu tun, wenn es alleine schon daran scheitert ob du Zahlen oder Strings benutzt.

dass mich hier niemand ernst nimmt, habe ich irgendwie schon gemerkt. dass der sha so eine geniale funktion ist, bin
ich nicht der meinung. da ist e=m*c viel genitaler. und es waere wirklich schoen, wenn mir jemand einen aufenthalt in
so einer klinik bezahlen wuerde. schaetze aber, dass du nicht zu diesen gehoertst.
und meiner meinung nach ist die w-funktion von sich selber abhaenig. waere wirklich toll, wenn man sie auf deine weise wirklich so vereinfachen koennte.


also habe es mal ueberschlagen. mein schlapptop wuerde so ca 2 jahre brauchen, um die erste schleife um eins
raufzusetzen, so wie er z. zt. rechnet zumindest. das waeren dann so ca 2 000 millionen jahre, bis er wirklich das programm abgearbeitet haette.
kann natuerlich sein, dass du einen besseren rechner hast.
und das ist nicht um kollisionen zu finden, sonder nur um kandidaten fuer moeglich kollisionen zu haben, falls du kollisionen finden moechtest, musst du diese kandidaten noch durchprobieren, weil der gleiche w63-wert nicht gleich gleicher hash ist. hoffe, dass das jetzt klar geworden ist.
was du mit lbc meinst weiss ich nicht.


finde ich gut, dass du so viel ahnung hast. dann kannst du mir bestimmt helfen, und schreiben, warum
"123" nicht st r(1) & s tr(2) & s t r(3) und nicht ch r(49) & c hr(50) & c h r(51) ist.   *)
beim meinem teil kommen da verschiedene hashwerte raus. kann natuerlich auch am interpreter liegen, aber ich kann mir das wirklich nicht erklaeren. damit werden die zwei die ich vorher gefunden habe, nicht mehr sehr glaubwuerdig.
also im prinzip waren es s t r(65) & s t r (69) wie s t r (236) & s t r(106) und s t r(135) & s t r(75) wie s t r(213) & s t r (52)


naja, mit dieser syntax komme ich nicht so ganz zu recht. fuer mich fehlen da irgendwie die ersten 15 und die bit-anzahl am schluss auch.


gut, dass es hier nicht um raten, sonder um rechnen geht. und an sich hatte ich schon weiter oben geschrieben, dass es jezt richtung kollisionen geht. also nicht nicht mehr so viel mit den bloecken zu tun hat. und ich versuche ironie zu vermeiden.


also die zwei paaerchen, die ich in meinem ersten 65-tausender versuch gefunden habe, haben sich nicht als sehr
representativ erwiesen. habe mal mit 6 zahlen probiert und in 300-tausend schon ganze 13 paaerchen gefunden. dabei ist aber das tabellenkalkulationsprogramm hoffnungslos abgestuerzt. verschwendet einfach zu viel speicher. 6k fue eine zelle ist einfach zu viel bei diesen mengen, vor allem, weil ich mir einen assoziativspeicher "gebaut" habe.
086465   118508
059002   119633
098461   124827
101564   145286
025498   158572
169677   183773
196857   202690
210344   211591
030032   286548
128534   288675
188613   289858
110696   295937
091265   307751
das heisst fuer mich, dass ich den brute force fuer eine kollision auf ca 0.04 promill damit verringern koennte, wenn
meine theorie stimmt. also ca 20 tausend mal damit schneller machen koennte.


also warum sollt ich dann nach bloecken suchen, die groesser sind als ein hash, wenn ich die kollision schon vorher
gefunden haben haette koennen?


dafuer bezahlt mir leider niemand was, mache ich aber gerne, wenn ich einen sponsor haette.


*) nur noch eine kurze erklaerung. aufgrund der komandos hier oben im text hat mich der server bockiert. ich dachte zuerst, dass es an etwas anderem liegt, habe aber ein paar leerzeichen dazwischen eingefuegt, damit ich es jetzt posten kann.
man lernt nie aus.

@cris601: ich finde keinen beitrag schlecht. jeder ist besser als keiner. also der einzige beitrag, der schlecht waere, ist der, den man weglaesst.

das mit dem merit ist eine echt gute idee. kann mir das jemand etwas genauer erklaeren? gibt es da eine einstufung, was einer "wert" ist und wieviele kann man davon "ausgeben"?

*klick auf Merit*  

Im Ernst, es gibt in diesem Thread mittlerweile wirklich viele tolle Beiträge. Schade, dass viele davon nicht verstanden werden.

Du bist nicht wirklich davon ausgegangen, das a) dich jemand ernst nimmt und dir ein lauffähiges Programm schreibt, und b) das das nebenbei auch noch der Mathematik größte Funktion ever mal eben so umdreht?
Du gehörst nicht in den Knast, du gehörst in eine Klinik. Und nicht die für gebrochene Knochen.

Ja ach.

Jau, tut sie. Zählt ja nur 32 bit, das dauert so lange auch nicht.
Ist jetzt nix für die Mittagspause, geht aber.
Bei angesetzten 100 Durchgängen pro Sekunde ist das Teil in 12000h fertig und hat alle Kollisionen gelistet. Nach ca. 18 Monaten also.
Da kann der LBC aber einpacken!

Also, so ähnlich wie du? Du versuchst auch immer wieder was neues. Was das gleiche alte ist wie gestern, nur mit einem "warte, jetzt hab ichs" davor.

Was meinst du wozu da "wbuf[15]=in" steht? Das kopiert deine "Originalnachricht" ins W-Array. Dein Original ist ja auch nichtmal 12bit groß.
Selbst da hast du es noch nicht geschnallt.

Nope. Nur die ersten 16 Longs eines Blocks von 16 Longs. Du brauchst also jede Menge W-Arrays. So 2000 Stück für einen normalen BTC-Block. Und du kennst nicht ein einziges Array durch den Hash.
Achnee, brauchst du nicht, denn die Nachricht wird ja in einen Block von 512 bit geschnitten und dieser in das W-Array kopiert, um es zu vermischen.
Du könntest also viel einfacher direkt den Qelldatenstrom raten anstatt die 4x so großen W-Arrays, wäre viel einfacher.
Jetzt musst du nur noch einen Weg finden, aus dem Hash wieder auf die ganzen 512-Bit-Blöcke zurückzurechnen. Werden so viele schon nicht sein, das schafft dein Excel schon.

Ach so. Du sparst 1/64tel des Aufwands. Anstatt 2048bit also nur noch 2016bit. Und du fragst mich ernst ob mein Programm a wohl einmal rum bekommt???

Ja, natürlich.

Also nix, wie immer. Und doch wieder, wie immer.

Gibt's eigentlich nichts sinnvolleres was du machen könntest?
Aus dem Fenster kucken zum Bleistift?

hallo,
wollte an sich ein neues topic in off-topic aufmachen, werde es aber lassen.
dachte, dass ich ja nicht so sein kann, und werde hier noch ein paar sachen posten, die ich rausgefunden habe.

was mich am meisten gewundert hat, ist, dass mein tabellenkalkulationsprg im debug-mode schneller laeuft und weniger cpu verbraucht, aber das nur nebenbei.

das mit den zahlen-strings wollte ich mal auf grossbuchstaben ausweiten (nicht auf mir sitzen lassen) und hatte die schlechte idee, gleich in meinem kleinen prg die sortierung zu machen. hat mich sehr viel zeit gekostet und ist dadurch auch sehr langsam geworden. zwei abstuerze und kein echter erfolg.

das naecheste, dass ich gefunden habe, war bei drei-buchstaben-kombinationen (fuer mehr reicht meine rechenpower leider nicht)
nur "ENM" und "YPG", die allerding noch 3 unterschied haben, also 2 bit verschieden haben.

da der w-wert ein longint ist, also bis 2 giga geht, ist das an sich schon fasst gleich, aber eben nur fasst.
bringt mir also nichts zum weitermachen. weiss jetzt nur, dass er bis zu den drei buchstaben keine "goldenen" w-kombinationen gibt.

was mich bei den zahlen-strings noch gewundert hat, ist, dass laengere strings scheinbar groessere w-werte haben, ist aber allerdings nur so ein gefuehl.

wuerde meinen algorythmus gerne auf einem etwas besseren rechner ausprobieren, aber das wird wohl noch ne weile dauern. bis dahin versuche ich ihn halt zu optimieren und stunden lang rechnen zu lassen.
wenn mir da jemand ein paar strings mit gleichen w-werten ausrechnen koennte, waere das natuerlich sehr schoen, glaube nur nicht, dass hier welche in der lage dazu sind, oder rechenzeit dafuer opfern wollen.

hallo,
besten dank, dass du dir die muehe gemacht hast, aber leider hast du dir das eis noch nicht verdient.
1. deine w-funktion ist naemlich leider falsch. ausserdem hast du noch ein paar gedankenfehler in deinem kleinen prg.
2. so wie ich das sehe, hast du das nicht mal laufen lassen. dann haettest du sicher einige fehler gleich selber gemerkt.
nur so nebenbei: glaubst du wirklich, dass dein prg den a-wert in deiner lebenszeit um eins erhoeht?
ausserdem machtst du die gleiche operation immer und immer wieder. ist also nicht sehr optimiert.

die verstaendnissschwierigkeit die du meiner meinung nach noch hast, scheint mir etwas schwerwiegender.
das w-array enthaelt naemlich in den ersten 16 stellen die orginalnachricht.
also nochmal zum mitschreiben: wenn ich das w-array von einem hash kenne, kenne ich die orginalnachricht.
der witz dabei ist, von einem hash kenne ich das w63 element vom w-array. alle kombinationen, die dieses element auch haben, sind kandidaten fuer den gleichen hash. also zum zurueckrechnen, oder besser um die menge einzuschraenken, die ich dann durch brute force ausprobiere, um eine kollision zu finden.
also brauche ich garnicht riesen grosse bloecke, weil laut informationstheorie die kollision in der gleichen laenge mindestens einmal auftauchen muss.
so, aber jetzt habe ich schon wieder einiges preisgegeben, was ich an sich nicht mehr wollte.

also ab jetzt dann bitte in privat.

pp: @cYnd, wenn du rausfindest, was windoof mit apple zu tun hat, dann verstehst du hoffentlich, was ich gemeint habe...

Was zum Henker bringts dir, das zwei kleine Zahlen die gleichen Werte im W-Array ergeben?
Weder nutzt SHA so kleine Zahlen, noch hat der Inhalt des W-Arrays irgendwelche voraussagbaren Einflüsse auf die SHA-Funktion.

for a = 0 to $ffffffff
wa=calculatew(a)
for b = 0 to $ffffffff
wb=calculatew(b)
if wa=wb then print a;"hat den gleichen W wie";b
next b
next a

function calculatew(long in)
  for c = 0 to 63
    wbuf[c] = 0
  next c
  wbuf[15]=in
  wbuf[31]=in>>7 xor in>>18 xor in>>3
  wbuf[17]=in>>17 xor in>>19 xor in>>10
return wbuf

Krieg ich jetzt ein Eis?

Nein, im Ernst, es gibt pro Block alle 64 Bytes ein neues Array mit 64 Longs, und das wird zu einem ganz kleinen Teil in den Hash einbezogen.
Vollkommen nutzlos, festzustellen das zwei 64 Bytes lange Blocks einen gleichen W ergeben, denn pro Block wird ein W-Array erzeugt und verXORt.

hallo,
achja, haette ich fasst vergessen. der ton ist ja wieder beim alten, also werde ich nicht darauf eingehen.
das video ist zwar ganz schoen, aber reichlich grundsaetzlich. trotzdem danke fuer den link, aber wenn ich das nicht schon gewusst haette, wuerde ich hier schon aus scham garnicht nicht mehr weiterschreiben.

@hodlcoins: dann bitte ich dich, die drei minuten in ein qbasic-prg zu investieren und mir noch ein paar strings mit gleichem w-wert auszurechnen. haettest mir reichlich viel zeit ersparen koennen, wenn du das vorher gemacht haettest. also wenn deine behauptung nicht nur heisse luft war, dann erwarte ich einen post von dir.

fuer alle die immernoch glauben, dass es eine verstaendnissschwierigkeit von mir ist, die kann ich beruhigen, es ist eher eine komunikationsschwierigkeit, und die kann man einfacher loesen.

der witz beim hash ist ja eben genau, dass jeder weiss, dass es kollisionen gibt.
kollision sind, fuer die die es noch nicht wissen, gleiche sha fuer verschiedene eingaben.
also wenn ich aus diesen gigantischen mengen an moeglichkeiten nicht durch probieren, sondern durch rechnen herausfinden kann, welche eingaben den gleichen sha haben, dann kann ich in der blockchain aendern, wie ich lust habe, muss nur den nonce mit angleichen.

aber dieser thread war an sich nicht fuer soetwas gedacht. der der sich die muhe gemacht hat, alles durchzulesen, was ich schaetze, dass die wenigsten machen, hat sicher festgestellt, dass es anfangs um das nonce-finden ging, da das ja reichlich viel strom schuckt. also schaetze ich, es ist besser, ich lasse das ganze bis hier her.

@cYnd: wenn ich es nicht selber herausgefunden haette, wuerde ich es nicht hier posten. fuer mich haben diese beiden stringpaare den gleichen w63 wert, der aus dem hash rueckrechenbar ist und wurden mit einem billignotebook in recht annehmbarer zeit gefunden. wie es @hodlcoins ausgedrueckt hat, in einem drei minuten aufwand. gut, ich habe etwas laenger gebraucht, aber ich bin ja auch kein freak.