Bitcoin Hack...

[3ds]

Wenn ich das richtig verstehe, setzt sich bei mehreren Blockchains die längere durch, oder?

Wie wäre dieses Angriffsszenario:

Man erzeugt eine Kette von Blocks, die nicht an der aktuellen Blockchain hängt, sagen wir dazu mal "Puffer-Blockchain".
Dann nimmt man den aktuellen letzten Block der offiziellen Blockchain und rechnet einen "Verbindungs-Block", der die Blockchain mit der eigenen "Puffer-Blockchain" verbindet. Schafft man es, sendet man das Ergebnis ins Netzt. Somit sollte diese als Gültige Blockchain akzeptiert werden.

Irgendwie kann ich mir vorstellen, das es nicht funktionieren wird. Aber wie wird das verhindert?

Einen "Verbindungs-Block" zu errechnen wird schwierig sein, aber nicht unmöglich, oder?

In den Blocks sind Zeitstempel drin, oder? Aber wie genau sind die? d.h. man muß im zuvor berechneten "Puffer-Blockchain" Zeitstempel in der Zukunft anlegen, wie dann auch halbwegs passen?


Nochwas:

Wie wird eigentlich entschieden, welche Transaktionen in einen Block aufgenommen werden? Das machen doch die Miner und können selbst entscheiden, oder? Dabei könnten sie auch nur Transaktionen mit Fees nehmen, oder nicht?
Ich stelle mir das so vor, das es einfacher ist einen Block zu errechnen, um so weniger Transaktionen darin vor kommen. Warum also nicht nur einen Teil der Transaktionen nehmen, die am meisten Fees haben und alle anderen Ignorieren?
Oder gewinnt immer der Block, der am größten ist?

[amigaman]

Der Inhalt des Blocks beeinflusst die Schwierigkeit nicht.
Ja, die Fee entscheidet neben anderen Faktoren (z.B. Alter), ob die Transaktion mitgenommen wird. Kein Miner wird gezwungen, bestimmte Transaktionen aufzunehmen.
Um Blöcke schneller als das Netz zu berechnen, müsste man ebenso mehr Rechenleistung haben. Stichwort 51%-Attacke.
Blöcke können nicht vorberechnet werden, weil jeder Block basierend auf dem vorherigen errechnet wird.

Du müsstest also mit massiver Rechenpower irgendwo forken und dann schneller als alle anderen sein, bist du 2 Blöcke im voraus bist. Dann gilt auf einmal deine Chain.
Auch hier: 51%-Attacke.

Also eher in der "theoretisch machbar, aber..."-Kategorie.

[fex]

Das ist unmöglich. (Edit: unter der Annahme, dass SHA256 funktioniert)

Jeder Block enthält im Header eine Prüfsumme des vorherigen Blocks, d.h. der erste Block der "gepufferten" Kette lässt sich nicht ausrechnen, da es keinen Vorgänger gibt. Normalerweise stellt man eine "happened before"-Relation zwischen zwei Blocks her (diese Relation und nicht der Zeitstempel ist entscheidend).

siehe auch: https://en.bitcoin.it/wiki/Block_hashing_algorithm, http://de.wikipedia.org/wiki/Happened-Before

[3ds]

Ich weiß das jeder Block die Prüfsumme des vorherigen Blocks enthält.

Zur Berechnung der "Puffer-Blockchain" fängt man einfach mit einer Zufälligen Prüfsumme des vorherigen Blocks an.

Im "Verbindungs-Block" muß man halt den Inhalt solange Variieren, das es mit der Zufälligen Prüfsumme übereinstimmt. Das ist natürlich schwierig, aber ich vermute einfacher als die 51% Attacke...

Der Inhalt des Blocks beeinflusst die Schwierigkeit nicht.

Wieso? Ob ich einen SHA von 1Byte bilde oder von 1TB macht doch einen Unterschied.

Kann man irgendwo sehen wie groß die Blöcke im schnitt sind? Bei https://blockchain.info/de/stats steht das nicht.

[Evil-Knievel]

This message was too old and has been purged

[amigaman]

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

[fex]

Ich weiß das jeder Block die Prüfsumme des vorherigen Blocks enthält.

Zur Berechnung der "Puffer-Blockchain" fängt man einfach mit einer Zufälligen Prüfsumme des vorherigen Blocks an.

Im "Verbindungs-Block" muß man halt den Inhalt solange Variieren, das es mit der Zufälligen Prüfsumme übereinstimmt. Das ist natürlich schwierig, aber ich vermute einfacher als die 51% Attacke...

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]

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?

[Evil-Knievel]

This message was too old and has been purged

[Red_Evil]

Es reicht theoretisch eine Grafikkarte um den Hack durchzuführen.
Du musst nur den ersten Block ausrechnen. Wenn eine gewisse Zeit kein Block in deiner Chain gefunden wird reduziert sich die Difficulty um den Faktor 4. Über die Zeit passt sich deine Difficulty halt so an, dass du alle 10 Minuten einen Block in deiner Chain findest ... dann haust du einen ASIC Miner rein, der die hunderte von Blocks pro Minute rechnet (da die Difficulty immer nur um den Faktor 4 Steigen kann maximal).

Am schluss veröffentlichst du (in der Zukunft zu dem Zeitpunkt deiner Fingierten Uhr) deine Alternative chain. Voila.

Na dann
Warten wir mal ab

[fex]

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?

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

[amigaman]

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!

[3ds]

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?

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

[Red_Evil]

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?

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

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

[fex]

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

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

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!

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

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

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.

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.

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

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

(http://xkcd.com/1252)

[amigaman]

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?

[Chefin]

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.

[amigaman]

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

 

[Chefin]

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

[Bytekiller]

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.

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