After the hack last week (see post) MtGox is back online right now.
You have to reclaim your account to regain access to your data. This can be performed by giving MtGox some information about your account on the Claim-Page. Afterwards you have to wait for a confirmation via mail.
If this is done, you can login on the MtGox Website and have fun 
As predicted in my article about the official Froyo (2.2) ROM for Motorola Defy now the next step: Gingerbread (2.3)
First a quick glance at the advantages. Let me quote the german wikipedia.
And finally: it’s much faster than Froyo (2.2).
There are currently several possibilities to upgrade to Gingerbread. First, you could use a leaked (?) Gingerbread 2.3.3 Build 4.5.1-112. But this build will leave you with a non functional camera if you have an older Defy whose camera has a green lens. Only owners of new Defys with the red lens will be happy with this.
A better choice would be the CyanogenMod 7 RC0 CyanogenMod 7 RC1 CyanogenMod 7 RC1v2 which includes a Gingerbread 2.3.4 and a lot of tweaks to speedup your Defy. I found only one issue with CyanogenMod: your camera will make funny pictures if you zoom to 4x or higher.
To install CynanogenMod, you’ll need a 2.2 Defy which is rooted. On the marked you’ll find the 2nd init App. It allows you to boot a second bootloader after the original Motorola bootloader has loaded. This opens the door for CustomROMs like CyanogenMod.
Before launching 2nd init, you should download CyanogenMod and the latest Google Apps to your phone’s SD-Card.
Afterwards you can launch 2nd init and install the new boot-environment. Then, you should reboot your phone and end in recovery-menu. Select Custom Recovery and then wipe your phone by choosing Wipe cache/factory reset. If this has succeeded, you can install the CM7 Zip and then the Google-Apps Zip by selecting Install zip from sdcard.
The final step is to reboot your device and then configure CM7
To optimize your reception, you should start the DEFY Baseband Switcher from the menu and select Europe RT 3.4.2-145.
Congratulations, you have successfully installed Cyanogenmod 7 on your Defy! Following are some screenshots of the new system and a benchmark with 800 Mhz.
Overclocking is quiet easy with CyanogenMod. Just enter the Settings-Menu, click Performance and then CPU-Settings. Here you can set your CPU-Speed.
If you want to switch back to 2.2 (don’t know why you should…) you can just download the SBF for the official 2.2 and install it via RSD-Lite.
Further information can be found in the german Android-Hilfe Forum.
Update 2011-06-26: RC1 of Cyanogenmod 7 released, see text
Update 2011-06-28: and RC1v2 released.
Und weil das Thema gerade so schön ist:
Heute gegen 17 Uhr ist der BTC-Kurs auf MtGox.com schlagartig auf unter 10 Dollar gefallen. Im Anschluss ging es dann bis auf 0.01 Dollar runter. Im Bitcoin-Forum wurden erste Vermutungen geäußert, dass einer der Early-Adopter nun seine Bitcoins (Handelsvolumen zu diesem Zeitpunkt: 500k BTC) zu Geld macht.
Nun ist aber von Mt-Gox bestätigt worden, dass es einen Hack in die Datenbank gab: Huge bitcoin sell off due to comporimised account rollback
Anscheinend halten sich die Verluste in Grenzen und es gibt nun einen Rollback der Mt-Gox Accounts auf den Stand vor dem Zusammenbruch. Alle betroffenen Account-Inhaber (also wohl jeder…) hat eine E-Mail erhalten in der die Situation erklärt wird.
Die Liste mit Account-Daten hat nun auch ihren Weg ins Bitcoin-Forum gefunden, daher sollten sich schon mal alle Benutzer darauf einrichten, in nächster Zeit vermehrt Angebote zum Kauf von Viagra zu erhalten. In wie weit die Passwörter nun gefährdet sind hängt u.a. auch davon ab, ob Mt-Gox einen Salt genutzt hat oder die Passwörter nur gehashed sind.
Welche Auswirkungen dieser Hack nun aber auf das Vertrauen in Bitcoins hat, ist schwer vorherzusehen.
UPDATE 2011-06-20: Mittlerweile hat Mt-Gox Infos zum Hack online gestellt:
It appears that someone who performs audits on our system and had read-only access to our database had their computer compromised. This allowed for someone to pull our database. The site was not compromised with a SQL injection as many are reporting, so in effect the site was not hacked.
Two months ago we migrated from MD5 hashing to freeBSD MD5 salted hashing. The unsalted user accounts in the wild are ones that haven’t been accessed in over 2 months and are considered idle. Once we are back up we will have implemented SHA-512 multi-iteration salted hashing and all users will be required to update to a new strong password.
We have been working with Google to ensure any gmail accounts associated with Mt.Gox user accounts have been locked and need to be reverified.
Mt.Gox will continue to be offline as we continue our investigation, at this time we are pushing it to 8:00am GMT.
When Mt.Gox comes back online, we will be putting all users through a new security measure to authenticate the users. This will be a mix of matching the last IP address that accessed the account, verifying their email address, account name and old password. Users will then be prompted to enter in a new strong password.
Once Mt.Gox is back online, trades 218869~222470 will be reverted
Schön das immerhin ein Salt zum Einsatz kam, wobei ich mich an dieser Stelle immer frage, warum eine Webseite erst gehackt werden bevor Sie merken, dass MD5 nicht das ist, was man als sicher sieht. Zu Beginn wurde es der Aussage nach noch nicht mal gesalzen! Erst jetzt kommt das doch um einiges erstrebenswertere SHA Verfahren in mehreren Iterationen zum Einsatz.
Hätte es nicht bereits ähnlich peinliche Dinge bei Privatbanken gegeben, wäre ich in der Stelle versucht zu sagen, dass Mt-Gox halt aus der Not entstanden und dann ungesund schnell gewachsen ist…
Nachdem bereits gezeigt wurde, dass man Bitcoins kaufen kann, folgt hier nun ein Artikel über die Berechnung von Bitcoins.
Wie bereits erwähnt gibt es auch die Möglichkeit, sich BTC durch Aufwendung von Rechenzeit (sog. Mining) selbst zu berechnen. Man berechnet sich nicht wirklich BTC sondern signiert bisherige Transaktionen in sogenannten Blöcken und erhält als Anerkennung hierfür auf zweierlei Arten BTC:
Der erste Punkt begründet auch, dass eine maximale Obergrenze von möglichen BTC vorhanden ist. Diese liegt bei 21 Mio BTC. Zu diesem Zeitpunkt erhält man für die Signierung von Transaktionen BTC nur noch in Form von Gebühren. Auch zeigt sich, dass das Berechnen von Blöcken immer unlukrativer wird, solange der Großteil der Transaktionen ohne Gebühr erfolgen.
Was geschieht nun bei einer solchen Blockberechnung? Vereinfacht gesagt versucht der Benutzer mittels einer zweifachen SHA256 Funktion (SHA256(SHA256(text)) einen Hash-Wert zu finden, der unterhalb eines bestimmten Grenzwertes, dem sogenannten Target liegt.
Um zu verhindern, dass es zu einer Geldschwemme kommt, wird dieses Target als Stellschraube genutzt. Je nach Rechenleistung des Netzwerkes wird die Schwierigkeit (Current Difficulty) und damit das Target (Current Target) angepasst. Die gewünschte Zielwert liegt hierbei bei 6 Blöcken pro Stunde.
Alle 2016 Blöcke wird die Difficulty so angepasst, dass mit der aktuellen Leistung des Netzwerkes weiterhin durchschnittlich 6 Blöcke pro Stunde berechnet werden.
Die für die Berechnung eines Blocks benötigten Werte werden im Block-Header kombiniert.
| Name | Inhalt | Update sobald… | Größe (Bytes) |
|---|---|---|---|
| Version | Block-Version | …der Client eine neue Version spezifiziert | 4 |
| Vorheriger Block | Hash des letzten Blocks | …ein neuer Block berechnet wurde | 32 |
| Merkle root | 256-bit Hash über alle bisherige Transaktionen | …eine neue Transaktion akzeptiert wird | 32 |
| Timestamp | Aktueller Zeitstempel | …eine neue Zeit vorliegt | 4 |
| Target | Aktuelles Target | …die Difficulty angepasst wird | 4 |
| Nonce | 32-bit Zahl | …ein Hash berechnet wurde (inkrementiert) | 4 |
Aus diesen Werten berechnen nun die Benutzer einen Hash-Wert und vergleichen ihn mit dem Target. Liegt der Hash-Wert über dem Target, wird Nonce angepasst und der nächste Wert berechnet. Da jede dieser Berechnungen unabhängig von vorangegangenen Berechnungen ist, lässt sich der Algorithmus gut auf mehrere Rechenkerne skalieren. Dies machen sich v.a. GPU-Miner zu nutzen (s.u.)
Sobald der Benutzer Werte gefunden hat, die einen passenden Hash generieren, kann er diesen Block sowie die für die Berechnung genutzten Werte veröffentlichen. Die auf diese Art berechneten Hash-Werte sind eindeutige Bezeichner des Blocks und für jeden nachvollziehbar, es ist also nicht möglich, fehlerhafte Blöcke als valide auszugeben.
Der Berechner eines Blockes kann eine beliebige Adresse angeben, welche die Belohnung erhält. Hierzu wird für den neuen Block eine neue Transaktion generiert, welche folgenden Inhalt besitzt:
Input: Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6 Index: 0 Coinbase:07456c696769757303d98c00 Output: Value: 5000000000 scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Es wird hier also keine Quell-Adresse für den Input angegeben sondern das Coinbase Parameter genutzt. Die hier eingefügten Daten werden nicht benötigt, können daher beliebig gesetzt werden.
Durch die Verkettung von Blöcken über den Hash wird eine Block-Chain erzeugt, welche sich bis zum ersten Block des Bitcoin-Systems (dem sog. Genesis-Block) nachvollziehen lässt. Hierdurch kann die Validität aller bisher berechneten Blöcke jederzeit überprüft werden.
Da ein neuer Block eine gewisse Zeit benötigt, bis jeder Teilnehmer des Systems von dessen Existenz erfährt, kann es vorkommen, dass zu einem bestehenden Block nicht nur ein Nachfolger sondern zwei gefunden werden. Dies wird Fork genannt. Für die weitere Berechnung der Block-Chain wird immer der Block, welche die längste Kette zum Genesis-Block besitzet, verwendet. Die Länge der Kette wird hierbei nicht über die Anzahl der Blöcke sondern die akkumulierte Difficulty definiert.
Auf diese Weise werden Forks der Block-Chain nach kurzer Zeit nicht mehr weitergeführt. Benutzer, die trotzdem Folgeblöcke für diese Äste berechnen, erhalten keine BTC als Vergütung.
Bereits getätigte Berechnungen werden unnütz, sobald von einem anderen Benutzer ein Block berechnet wurde. Zu diesem Zeitpunkt muss wieder mit dem ersten Nonce begonnen werden. Daher kann nicht davon ausgegangen werden, dass man sicher nach einer gewissen Zeit einen Block gefunden hat.
Der durchschnittliche Aufwand für die Berechnung eines einzelnen Blocks lässt sich mit der folgenden Formel berechnen:
time in seconds = difficulty * 2^32 / hash per second Beispiel: Difficulty = 20000 Mhash/s = 400 20000 * 2^32 / 400 * 10^6 = 214748,3648 Sekunden = 59,65 Stunden
Da die aktuelle Difficulty aber bereits bei >850000 liegt, würde man bereits 2535 Stunden benötigen.
Um ein Gefühl für die Leistungsfähigkeit der eigenen Hardware zu bekommen lohnt sich ein Blick in die Bitcoin-Wiki:
Vergleich von Mining-Hardware
Anhand der Beispieldaten für die Leistungsfähigkeit von CPUs und Grafikkarten sieht man, dass Grafikkarten (GPU) eine um ein vielfaches höhere Rechenleistung besitzen. Dies liegt an der guten Skalierbarkeit des Rechenvorganges auf mehrere Rechenkerne. GPUs besitzen viele einfache Rechenkerne, die die benötigten Berechnungen relativ langsam, jedoch parallel durchführen.
So kann ein typischer CPU-Kern zwischen 4 (128Bit SSE) und 8 (256Bit AVX) 32-bit Instruktionen pro Taktzyklus durchführen. Eine Grafikkarte kann nur eine einzelne Instruktion durchführen, besitzt dafür aber z.B. 1600 Rechenkerne (HD5870).
Im Vergleich schneidet also eine Quad-Core CPU mit 3Ghz gegenüber einer ATI HD5870 sehr schlecht ab (1:15).
4 Kerne * 3 Ghz * 8 Instruktionen/Takt = 96000000000 Instruktionen/Sekunde 1600 Kerne * 900 Mhz * 1 Instruktion/Takt = 1440000000000 Instruktionen/Sekunde
Um dem Problem des hohen Rechenaufwands sowie der Unsicherheit des Erfolgs zu begegnen, rechnen die meisten Benutzer in Pools. Hierbei wird der Block auf alle teilnehmenden Rechner verteilt und somit der geringer. Sobald ein Block berechnet wurde, erhalten die Teilnehmer prozentual an der geleisteten Arbeit eine Ausschüttung.
Deepbit.net 3000 Ghash/s
Bitcoin.cz 1600 Ghash/s
Für Bitcoin.cz ergibt sich eine durchschnittliche Rechenzeit von 40 Minuten.
In diesem Artikel soll darauf eingegangen werden, wie mit dem gerade installierten Bitcoin-Client Transaktionen abgewickelt werden können und welche Voraussetzungen es hierfür gibt.
Jeder Bitcoin-Benutzer besitzt ein sogenanntes Wallet. Dieses stellt quasi eine digitale Geldbörse dar und sollte immer gut gesichert werden. Falls diese Wallet-Datei einmal versehendlich gelöscht oder verloren geht, sind auch alle Bitcoins des Benutzers verloren.
Wie bereits erwähnt, besitzt ein Benutzer aber eigentlich keine Bitcoins, wie können diese also in einer Datei gespeichert werden?
Der eigentliche Sinn des Wallets ist es, Schlüsselpaare des Benutzers zu speichern. Diese werden mittels ECDSA gebildet. Jeder Teilnehmer des Bitcoin-Netzwerkes kann eine beliebige Anzahl an Schlüsselpaaren generieren und nutzen.
Der öffentliche Teil des Paares bildet hierbei die Adresse, an die Transfers für den Benutzer gerichtet werden können. Aus diesem Teil sowie einer 32bit langen Prüfsumme wird mittels Base58 (Base64 ohne I, O, l, 0, + und /) nun ein zwischen 24 und 33 Zeichen langer String erzeugt. Um zwischen normalen Bitcoin Adressen und solchen, die im offenen Testnet genutzt werden zu unterscheiden, wird der Adresse eine 1 vorangestellt (Testnet: n oder m).
Mithilfe dieser Adressen ist es nun möglich, am Zahlungsverkehr teilzunehmen. Hierfür wird natürlich nun noch ein Startkapital benötigt. Die einfachste Variante ist es, von Bekannten einen kleinen Bitcoin-Betrag überwiesen zu bekommen. Wer niemanden kennt, der bereit ist, die eine oder andere BTC abzugeben, hat zwei weitere Möglichkeiten:
Immer mehr Webseiten bieten Bitcoins zu schwankenden Kursen an. Meist muss man hierfür einen Account registrieren und auf ein Konto Geld überweisen. Sobald dieses dem Account gutgeschrieben wurde, kann man hiermit BTC kaufen. Die meisten Webseiten agieren hierbei als ein Vermittler zwischen potentiellen Käufern und Verkäufern. Hierbei fallen dann pro Transaktion Gebühren an. Die momentan größte Bitcoin Börse ist MtGox mit einem täglichen Transfer-Volumen von etwa 40000 BTC. Der aktuell für ein BTC zu zahlende Preis beträgt je nach Kurs etwa 18 US-Dollar.
Als Alternative stellt sich die “Berechnung” von BTC dar. Hierzu später mehr.
Sobald man nun mit einem Account sowie einem gewissen Kapital ausgestattet ist, kann man erste Überweisungen tätigen. Für eine solche Transaktion benötigt man zuerst einmal eine Zieladresse. Der Einfachheit halber kann diese auch eine weitere selbst generierte Adresse sein. Im Bitcoin-Client gibt man nun die Zieladresse sowie das gewünschte Volumen des Transfers an und bestätigt die Überweisung. Der Client verbreitet nun diese Transaktion im P2P Netzwerk. Im Ziel-Account wird die Überweisung nun angezeigt, jedoch mit dem Vermerk, dass diese noch nicht bestätigt wurde. Erst nach einiger Zeit wechselt der dieser Status in “Bestätigt” mit einer wachsenden Anzahl an Bestätigungen. Dieser Zeitraum variiert, je nachdem wie viele Blöcke in der Zwischenzeit berechnet wurden (siehe Berechnung von BTC).
Zwar kann man auch über unbestätigte BTC verfügen und diese weiter überweisen, diese Transfers bleiben aber wiederum solange unbestätigt, bis der ursprüngliche Transfer bestätigt wurde.
Eine weitere wichtige Eigenschaft von Bitcoin-Transfers ist deren Unumkehrbarkeit. Eine Überweisung kann nicht rückgängig gemacht werden, einmal versendetes Geld ist also verloren.
Eine Transfer-Anweisung besteht aus zwei Teilen, welche wiederum beliebig oft (1-n mal) vorkommen können: Input und Output.
Input: Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6 Index: 0 scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1090db 022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
Previous tx ist hierbei der Hash einer vorhergegangen Transaktion, also der Quelle, aus der die BTC stammen. Index beschreibt, welche Output-Position der Transaktion genutzt wird. ScriptSig enthält eine digitale Unterschrift, welche mithilfe des Private-Keys erzeugt wird. Hierbei wird der Input-Eintrag verschlüsselt. Diese Signatur kann anschließend von jedem Benutzer unter Zuhilfenahme des Public-Keys entschlüsselt werden. Durch dieses Verfahren wird sichergestellt, dass der Ersteller der Transaktion auch der Besitzer der Bitcoins ist.
Durch Akkumulation mehrerer Inputs kann ein BTC Betrag erreicht werden, der höher als der einer einzelnen Transaktion ist. Aus einer Transaktion mit 4 BTC und einer mit 6 BTC wird also ein Output-Value von 10 BTC. Dieses Value muss komplett in Output-Anweisungen umgesetzt werden. Beträge, welche nicht vergeben werden, erhält der Berechner des nächsten Blocks als Fee.
Output: Value: 5000000000 scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Im Output wird einerseits die auszuzahlende Menge BTC sowie die der Hash der Zieladresse angegeben. Um die bereits angesprochene komplette Verteilung der Input-BTC zu erreichen, wird der überschüssige Betrag normalerweise an die eigene Adresse überwiesen.
Beispiel:
Benutzer A will 9 BTC an Benutzer B senden
Input 1: 4 BTC
Input 2: 6 BTCOutput an B: 9 BTC
Output an A: 1 BTC
Im Rahmen der Berechnung von neuen Blöcken (siehe Berechnung von BTC) werden Transaktionen bestätigt. Als Berechner eines Blockes hat man die Möglichkeit, nur Transaktionen zu signieren, die eine Fee beinhalten. Diese wird dem Berechner zusätzlich zu der Belohnung gutgeschrieben.
Daher ist davon auszugehen, dass Transaktionen, welche eine Fee bieten, schneller signiert werden. Dies spielt auch später eine wichtige Rolle, wenn für das auffinden eines Blocks keine oder kaum noch BTC ausgeschüttet werden. Um hier die Motivation aufrecht zu halten, werden Fees nötig.