Bitcoinbasics, vielleicht eine Moeglichkeit BTCs geziehlt zu generieren

[cYnd]

hat wenigsten jemand sich die muehe gemacht, mich mit den zwei strings zu widerlegen, oder kann ich davon ausgehen, dass sie stimmen?

Warum prüfst du das nicht selbst?
Letztens noch ein interessantes Video gefunden:
https://youtu.be/Ep7nY8aicn8

Die vorherigen Theorie-Videos sind auch sehr hilfreich.
Und in dem Beispiel sagst du also jetzt, dass du einen Weg gefunden hast, die Zahl zu erraten oder zumindest einzugrenzen...

pp
habe zufaellig was interesantes gefunden:
https://en.wikipedia.org/wiki/Peppercoin
da wiederspricht sich wiki
https://en.wikipedia.org/wiki/Cryptocurrency
peppercoin ist naemlich acht jahre aelter als btc.
also ist btc genauso orginell wie windoof
ist interessant, wie viele sachen gekauft werden, um in schubladen zu verschwinden und von brennstoffzellen bis quanten-teilen gibt es da ja wirklich genug beispiele.
wollte ich nur noch erwaehnen, um diesem thread wenigstens noch ein bisschen sinn zu geben, bevor ich ihn aufgebe...

Den zusammenhang zwischen Peppercoin und Bitcoin (abgesehen dass beide "Coin" im Namen tragen) musst du mir mal erklären. Ich sehe da nämlich keinen. Zumal der Artikel sehr kurz ist und keine Details bedeutet.
Nur weil Peppercoin ein kryptografisches System ist bzw. als kryptografischer sicher gilt(galt?) heißt das ja noch lange nicht, dass es was mit Bitcoin und dezentraler Blockchain zu tun hat

[1715506580]

1715506580

[1715506580]

1715506580

[1715506580]

1715506580

[1715506580]

1715506580

[hodlcoins]

Das ist nicht das einzige Verständnisproblem in diesem Thread.

Alleine schon das jemand 16515463,618461 postet und dann erwartet, das alle draufspringen und sagen "yay, endlich hat jemand bewiesen das es SHA-Kollisionen gibt".
Aber nicht vergessen, das sind Strings, keine Zahlen, aber "mit Zahlen ist das in dem Programm einfacher"
Wow, jemand nimmt ungefähr 0,3% des Algorithmus wahlfrei raus und sucht zwei Werte die in dieser Formel vergleichbare Ergebnisse erzielen. Was aufgrund der deterministischen Natur des Ganzen und der verwendeten Größe der Zahlen vollkommen unmöglich erscheint.
Jessas, sowas kann man vermutlich in 3 Minuten in QBasic zusammenklatschen und alle Zahlen <24 bit suchen die gleiche W-Einträge erzeugen.

Kein Wunder, das sich alle von fori getrollt fühlen, denn Trolle sind wie Spione: am besten sind sie, wenn sie nicht wissen, das sie Trolle|Spione sind.

[twbt]

Kein Wunder, das sich alle von fori getrollt fühlen, denn Trolle sind wie Spione: am besten sind sie, wenn sie nicht wissen, das sie Trolle|Spione sind.

Genau. Sie sind wie Dunning und Kruger, die sich über die Zähne von Briefmarken in einem Numismatiker-Forum unterhalten, weil sie sich eigentlich für Narkotika interessieren, aber ihnen schlicht das Geld für ebensolche fehlt.

[bitcoinfori]

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.

[hodlcoins]

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.

[bitcoinfori]

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

[bitcoinfori]

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.

[hodlcoins]

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.

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.

so wie ich das sehe, hast du das nicht mal laufen lassen. dann haettest du sicher einige fehler gleich selber gemerkt.

Ja ach.

nur so nebenbei: glaubst du wirklich, dass dein prg den a-wert in deiner lebenszeit um eins erhoeht?

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!

ausserdem machtst du die gleiche operation immer und immer wieder. ist also nicht sehr optimiert.

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.

das w-array enthaelt naemlich in den ersten 16 stellen die orginalnachricht.

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.

also nochmal zum mitschreiben: wenn ich das w-array von einem hash kenne, kenne ich die orginalnachricht.

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.

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.

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

also brauche ich garnicht riesen grosse bloecke, weil laut informationstheorie die kollision in der gleichen laenge mindestens einmal auftauchen muss.

Ja, natürlich.

so, aber jetzt habe ich schon wieder einiges preisgegeben, was ich an sich nicht mehr wollte.

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?

[Chris601]

*klick auf Merit*  

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

[bitcoinfori]

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.

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.

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.

nur so nebenbei: glaubst du wirklich, dass dein prg den a-wert in deiner lebenszeit um eins erhoeht?

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

ausserdem machtst du die gleiche operation immer und immer wieder. ist also nicht sehr optimiert.

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.

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)

das w-array enthaelt naemlich in den ersten 16 stellen die orginalnachricht.

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.

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.

also nochmal zum mitschreiben: wenn ich das w-array von einem hash kenne, kenne ich die orginalnachricht.

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.

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.

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.

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

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 brauche ich garnicht riesen

grosse bloecke, weil laut informationstheorie die kollision in der gleichen laenge mindestens einmal auftauchen muss.

Ja, natürlich.

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

so, aber jetzt habe ich schon wieder einiges preisgegeben, was ich an sich nicht mehr wollte.

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?

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

[hodlcoins]

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.

[Chris601]

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.

[curiosity81]

[...] ich nicht der meinung. da ist e=m*c viel genitaler. und es waere wirklich schoen, wenn mir jemand einen aufenthalt in [...]

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.

[bitcoinfori]

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

[bitcoinfori]

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?

[mezzomix]

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?

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

[bitcoinfori]

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?

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

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.

[Sukrim]

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

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

[bitcoinfori]

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

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

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

[Sukrim]

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.