Topic: Bitcoin Hack... (Read 3329 times)

 

wer lust hat kann ja mal hiermit versuchen

http://directory.io/

Hier die Tabelle aller Public/Private Keys, viel spaß beim knacken

Meine Idee war eigentlich anders. Aber auch ein nettes Angriffsszenario, aber gut das dies auch nicht funktionieren wird...

es wird immer die kette mit der meißten ARBEIT genommen, nicht die, die am längsten ist.

Beispiel:
Eine kette 10000 blocks lang auf (komplett) difficulty 1 ist 10000*1 = 10000 wert
Eine kette 1000 blocks lang auf (komplett) diffculty 100 ist 1000*100 =100000 wert
Die zweite Blockchain würde vom Netz übernommen werden.

Wenn ich 3ds richtig verstehe, dann wäre das auch anders möglich: Man nimmt sich den aktuellen Block und fängt an zu rechnen. Das Bitcoinnetzwerk an sich erechnet weitere Blöcke aber man rechnet einfach genütlich weiter an diesen einen den man sich gegriffen hat. Irgendwann hat man ihn und man rechnet dann einfach an den neuen eigegen erstellten weiter so als ob es den rest des netzwerkes nicht gäbe. Man macht so weiter und da hier nur entsprechend wenig rechenpower vorhanden ist geht in diesem nun eigenen netzwerk die difficulty runter, und das immerzu. Man nimmst immer langsamere Hardware und dei difficulty geht immer weiter runter. Dann, irgendwann, während das Bitcoinnetzwerk schon viele tausende block erstellt hat und man selbst gerade mal ~40 stück oder so, setzt man seine asic farm auf die eigene kette an. Es werden nun SEHR schnell block erzeugt. So schnell, dass man nach kurzer Zeit mehr blöcke hat als das Bitcoinnetzwerk selbst. Man hat also bezüglich der Anzahl an blocks die längste Kette.
Jetzt noch diese Kette ins Netzwerk injizieren und Popcorn auf machen.

War das so in etwa deine Idee?

wenn Du den Windowsrechner auf wissenschaftlich umstellst dann kommt
12345678901234558765432109876544 raus
das e+31 sagt dass das ergebniss 31 stellen hat nicht aber 0en

zu großen zahlen wie
26959535291011309493156476344723991336010898738574164086137773096960
ist nur eine bearbeitungsbethode
ich sag nur C64 und low-byte und high-byte
ein sql kann ohne probleme mit 63 stellige zahlen umgehn

Du nicht, ich schon.

Versuch mal eine ordentliche Fliesskommabibliothek einzubinden und nicht mit den Standard-Bibliotheken zu arbeiten. Ich benutze allerdings Delphi. Aber das sollte es für C++ wohl auch geben.

Und dann sind auch mehr Stellen hinter dem Komma möglich

PS: Taschenrechner mit 8 Stellen rechnen 9 Stellig. Schau dir einfach mal die Quellcodes solcher Teile an(gibt genug Opensource).

Ja, weiß ich.
Die meisten Tischrechner haben nur 8 Stellen, wissenschaftliche für die Schule 12 oder so. Der Windowsrechner schafft 16 (Windows 7), bevor er in die e's verfällt.
Aber das oben angegebene Ergebnis ist nicht aus einer "1e+32" gekommen, weil dabei am Ende Nullen stehen.
Der Windowsrechner kann witzigerweise 1234567890123456 * 9999999999999999 = 1,234567890123456e+31 rechnen, und das wäre ja eine Zahl, bei der nach 16 Stellen Nullen kommen, also 1234567890123456000000000000000, und das ist falsch. Hinreichend genau "for everyday use", mathematisch aber falsch. Zuwenig Signifikanz in der Mantisse
Damit könnte man also die Rechnung von oben gar nicht durchführen, geschweige denn so ein Ergebnis bekommen.

Das war was ich meinte.
Wie das intern geht, ist mir bekannt, ich programmiere schließlich "Bare Metal" mit

 

wieso hören die meisten Rechner mit 8 Stellen auf?

Also ein Intel-PC hat eine 80Bit Fliesskommaeinheit.

http://de.wikipedia.org/wiki/IEEE_754. Das sind mehr als 8 Stellen, aber korrekterweise sind es eben auch keine 256 Stellen oder mehr.

Aber Verschlüsselung ist keine Fliesskommaberechnung. Hier wird einfach eine fortlaufende Bitfolge manipuliert. Die festgelegten Rechenschritte in der CPU werden dazu nicht benutzt. Man benutzt eigene Ausführungen. Diese basieren auf Integer-algorythmen.

http://de.wikipedia.org/wiki/Integer_%28Datentyp%29#Maximaler_Wertebereich_von_Integer

Es gibt den BigInteger, der dann frei definiert wird und das Betriebssystem passt die Berechnung an.
Die Zahlen-Buchstaben Darstellung ist nur für uns gemacht, damit wir es lesen und verstehen können.
Den eine Adresse aus 256 Zeichen 0 und 1 ist nichtmehr visuell zu verarbeiten für den Mensch.

0100100101010010100100100100100010010010000100111001001011010010011100101111101 0101101011011011101010101101010101001001001001001000100101101011101111011011011 0110101101010101110111011011011010101111010011111011011010010110101110111100100 1011010111011110110

0100100101010010100100100100100010010010000100111001001011010010011100101111101 0101101011011011101010101101010101001001001001001000100101101011101111011011010 1110101101010101110111011011011010101111010011111011011010010110101110111100100 1011010111011110110

Bei der HEX-Darstellung wird es schon etwas lesbarer und nun dürftest du auch mit dem Auge erkennen wo ich die zwei Zahlen verändert habe.

4952 9248 9213 92D2 72FA B5B7 55AA 9249 12D7 7B6D AD57 76DA BD3E DA5A EF25 AEF6

4952 9248 9213 92D2 72FA B5B7 55AA 9249 12D7 7B6B AD57 76DA BD3E DA5A EF25 AEF6

Auch die Darstellung einer Adresse bei Bitcoin in Form einer Zahlen-Buchstaben Codes ist nur eine visuelle Umrechnung bei der Bildschirmdarstellung. Der Computer rechnet nicht mit diesen Zeichen, sondern er wandelt das in die 0 - 1 Folge um und alle Rechenvorschriften gelten dann auschliesslich für diese binäre Berechnung. Und bei Integer kann der Rechner auch solch gewaltige Zahlen wie PI verarbeiten. Und zwar auch auf 100.000 Stellen genau. Obwohl er in seiner Fliesskommaeinheit maximal 80Bit hat(entspricht grob 16 Stellen in der visuellen Darstellung).

Lass dich also nicht von den visuellen Darstellungen in die Irre führen, sie sind nur für den Mensch gemacht.

Edit:
http://www.heise.de/newsticker/meldung/Pi-Berechnungsrekord-auf-handelsueblichem-PC-899930.html

Bin gerade drüber gestolpert.

Und bevor nun wieder ein Dezimalargument kommt(PI besteht ja nur aus Nachkommastellen) lese dir die IEEE754 genau durch. Alle zahlen im PC werden als x,y * 10^z dargestellt. Mit einem Absolutwert von 0-9 vor dem Komma(x). Eine 10,3 wird als 1,03 * 10^1 interne in der Fliesskommaeinheit dargestellt.

Meine Frage wegen dem Rechner war mehr so aufgrund der "die meisten Rechner hören mit 8 Stellen auf, der Windowsrechner kann sicherlich mehr, aber auch keine soooo großen Zahlen".

Meine Überlegung mit der 0x0..1-diff war auch nur mehr theoretischer Natur.
Wenn die Rechenleistung weiter exponentiell oder steiler steigt und der ganze Kram überhaupt noch aktuell und bezahlbar ist usw., aber das wären ja schon mehr theoretische Überlegungen.
Mir ging es um das Prinzip, das die Diff irgendwann "zu ende" ist und nicht mehr höher werden kann.
Danke für die Erklärung, scheint ja so zu sein, auch wenn das weit weg ist. Wobei: den Spruch mit dem "Wozu sollte irgendjemand mehr als 64kByte benötigen" kennst du ja sicher auch. Ich bin mir sicher, ich hab ihn falsch wiedergegeben, aber du weißt was ich meine.

Und: Der Comic ist cool. Statistik ftw.
Jedes 7. Kind ist ein Chinese... Wo sind hier in DE eigentlich die Millionen von Chinesen?

Habe es mit Wolfram Alpha berechnet - oder war das eine allgemeine Frage bzgl. Computer-Hardware?

Der Maximalwert der Difficulty ist langfristig ausreichend, wir werden den Wert nicht erreichen:

Das reicht nicht. Der Zusammenhang ist linear, investieren wir doppelt so viel Zeit, können wir die doppelte Difficulty "knacken". Wir haben jetzt etwa eine Difficulty von 700*10^6 und brauchen etwa 10 Minuten, um einen Hash zu finden. Damit wir die genannte Difficulty von ~3*10^67 knacken können, brauchen wir also 3*10^67 / 700*10^6 * 10 Minuten. Das sind ~4*10^59 Minuten - das Alter des Universums wird bei Wikipedia mit ~7*10^15 Minuten angegeben.

Wenn unsere ASIC-Hardware noch eine Million mal schneller wird, wären es noch 4*10^53 Minuten. Es reicht einfach nicht.

Ok, mit 50% Wahrscheinlichkeit dauert es nur 2*10^53 Minuten.




(http://xkcd.com/1252)

Warum würde jemand soetwas wollen ?
Wer die Power hätte die Chain zu ändern könnte dem entsprechend mit verdienen ein block sind 25 K $ * 6 * 24 / 2 = 1 800 000 $ Am Tag + fees

Das stimmt. Aber es muß ja nicht in 10Min. passieren. Deswegen ja der "Puffer-Blockchain"...
Wenn man z.B. mit einem "Verbindungs-Block" eine "Puffer-Blockchain" die 100 Blöcke vorausberechnet enthalten würde, hätte man 10*100-1 Minuten Zeit den "Verbindungs-Block" zu errechnen. Ab dann wäre die eigene, gehackte Blockchain wieder genauso lang wie die offizielle...

Hinzu kommt, das man beim SHA Bruteforce ja nicht wirklich alle Variationen durchgehen muß (Das nur im Worst-Case). Es entscheidet ja quasi auch das Glück ob man einen passenden Hash gefunden hat.

Mit zunehmend effizienteren ASICs wird es auch immer wahrscheinlicher...

Von daher muß man eh irgendwann mal am System was ändern. Nur die Frage wann...

Frage mich sowieso ob es nicht Sinn macht einfach mal den Hasing-Algorithmus zu ändern, damit der ASIC-Wahn erst einmal wieder beendet ist...

Mich interessiert jetzt eher, mit welchem Rechner man so große Zahlen bearbeiten kann?

Und: wenn ich das richtig verstehe, und in 20 Jahren Milliarden von Uber-Neptunes ihren Dienst tun, kann das Netz die Diff irgendwann nicht mehr weiter anheben, weil mehr als 0x0000...1 geht nicht?
Ja klar, Protokollanpasung und so, aber mal ohne solche Mogelei: dann kommen wir ja in die Echtzeitverarbeitung, weil dann ja immer schneller Blöcke (wörtlich) rausgeblasen werden.
Cool!

Doch muss man, denn Brute force gegen SHA256 ist mit dem Bitcoin-Netzwerk nicht möglich. Wenn das ginge, wäre SHA256 nicht mehr sicher und wir bräuchten nicht so komplizierte Attacken (wir könnten beliebige Transaktionen erfinden etc.).

Dazu ein kleiner Vergleich:

Mit der aktuellen Difficulty sieht ein Hashwert, welcher den Anforderungen genügt, so aus:

0x0000000000000003243754D8431FC1A4BD7A2B2DF50AFE67A1E8734E06E67803 (http://blockexplorer.com/b/271921)

Ein Hex-Wert mit 15 führenden Nullen. So ein Wert wird vom gesamten Netzwerk im Schnitt alle 10 Minuten erzeugt. Du willst einen Wert erzeugen, bei dem alle 256 bit vorgegeben sind. Nehmen wir also an, du möchtest diesen Hash erzeugen:

0x00000000000000000000000000000000000000000000000000000000000000001

Die Difficulty stellt das sehr anschaulich dar. Einen Hash mit 63 führenden Nullen alle 10 Minuten zu erzeugen entspricht einer Difficulty von 26959535291011309493156476344723991336010898738574164086137773096960. Welcher Pool soll das schaffen?

Berechnung: 0xFFFF0000000000000000000000000000000000000000000000000000 / 0x1
Lesestoff: https://en.bitcoin.it/wiki/Target, https://en.bitcoin.it/wiki/Difficulty

Na dann
Warten wir mal ab

This message was too old and has been purged

Man muß nicht SHA256 dafür knacken, sondern einfach per Bruteforce rechnen.
Da wir schön effektive ASIC Maschinen haben, kann man ja zig TH/s rechnen...

Was ist, wenn ein großer Pool auf die Idee kommt?

Vermutlich nicht. Denn dazu müsstest du SHA256 knacken: du möchtest, dass der Output der Hashfunktion einen definierten Wert annimmt (die Prüfsumme des ersten Blocks der gepufferten Kette).

Das ist im Gegensatz zum Minen eines neuen Blocks nicht so einfach, da man nicht irgendeinen beliebigen Hash mit bestimmen Voraussetzung (führende Nullen entsprechend der Difficulty) nehmen kann, sondern einen genau festgelegten Output bräuchte.

Eine 51%-Attacke ist vermutlich einfacher als SHA256 zu knacken (ist aber schlecht vergleichbar).

@3ds:
Ja, aber du musst ja einen vorgegebenen Wert erreichen, und SHA ist ja darauf ausgelegt, schnell zu sein, zumindest in einer Richtung.
Den Inhalt zu manipulieren, bis ein bestimmter Wert kommt, ist sicherlich machbar, aber eigentlich der rückwärtsweg,  und der ist quasi unmöglich.
Zudem ist die Blockgröße ja begrenzt, so extrem wie bei dir werden die Unterschiede nicht.

Das was du vorhast ist genau das normale hashen, die Nutzdaten müssen ja passen (echt sein), nur die Nonce wird angepasst, nur darüber wird der Block "richtig".

Glaub mal, wenn das so leicht wäre, würde ASICMiner seine Farm drauf ansetzen...

@Evil-Knievel
Nicht?
Stimmt. Du brauchst "im Schnitt" 51%, denn das Luck zählt mit. Wenn deine Farm zwar lahm aber glücklich ist, könnte sie die Kette auch so überholen, ja.
Ist bloß im Mittel so, das sich das Glück ausgleicht, also irgendwann auf die Bremse geht.
Und dann überholen dich die anderen wieder.

Ist aber mittlwerweile so unwahrscheinlich geworden, rein aufgrund der Maschinenzahl, selbst große Pools schaffen das nicht.