Freitag, 22. August 2014

Testrun Ludum Dare 30

I made a short testrun and I think I'm ready.

A javascript version is available at my dropbox account. But it's nothing special, you can just jump and run and the Box2D debug renderer is still enabled :).

The code, which is undocumented because I was in a hurry, is available at github project which I made for it.

Have a nice weekend everyone, lots of while programming and maybe while watching Capaldi :)

Cheers,
Simon.

Timelapse made with TechnoLapse made by technocf. Thanks!

Tools used for development:

  • Library: LibGDX(Java)
  • IDE: IntelliJ Idea
  • Graphics: Inkscape, Spriter
  • Other tools: TexturePacker, Tiled (map editor).
  • Platforms: Native Java application and Web version (Chrome works best).

Sonntag, 27. April 2014

Brau Dein Bier!

Ludum Dare hat wieder zugeschlagen!

Nachdem ich schon lange nicht mehr an Ludum Dare teilgenommen habe, habe ich am Freitag spontan entschlossen, wieder teilzunehmen. Mit Drei anderen Teilnehmen hat, jeder für sich, ein Spiel programmiert.

Das Thema hieß "Beneath The Surface" und entstanden ist ein Spiel, in welchen man einem Hefeteilchen helfen muss, Zucker in Alkohol zu verwandeln. Da wir uns darauf geeinigt haben, unsere Spiele mit 3000 enden zu lassen, heißt mein Spiel jetzt Beer 3000.

Die anderen Spiele sind noch in Entwicklung. Ich bin schon gespannt auf:

  • Shark 3000
  • Zombie 3000 und
  • Anti Minecraft 3000

Link zum Spiel

Samstag, 1. März 2014

Bitcoin Client nach wie vor in Arbeit

Vor 2 1/2 Wochen habe ich angekündigt einen Bitcoin Client zu programmieren. Da das schon eine Weile her ist, will ich kein kurzes Update geben.

Was wurde bereits Programmiert?

Mittlerweile wurde das Protokoll soweit implementiert, sodass man alle Pakete erstellen kann, um sich zu einem Node zu verbinden. Technisch gesehen: Alle Pakete, die für den Handshake benötigt werden. Jedoch müssen die selben Pakete auch gelesen werden können und das fehlt in der Implementierung noch. Das hört sich nach wenig ist, jedoch muss man dazu sämtliche Grundlagen programmieren, beispielsweise die Umwandlung in die verschiedenen Zahlen, Zeichenketten oder IP Adresse im Protokoll. Jedes Paket hat zudem gewisse Header, was zu diesem Zeitpunkt schon implementiert werden muss.

Wird auch getestet?

Das Ganze implementiere ich mittels TDD (=Test Driven Development). TDD heißt, bevor ich etwas implementiere, wird zunächst der Test geschrieben. Dieser muss erst fehlschlagen, da es noch nicht implementiert wurde (der Test wird damit getestet). Danach wird die Unterfunktion programmiert und der Test gestartet. Schlägt der Test fehl, dann stimmt etwas entweder im Test oder in der Implementierung nicht. Das macht die Entwicklung langsamer, da mehr programmiert werden muss aber dafür deutlich sicherer.

Ein anderer Vorteil von TDD ist, dass man nach einer Optimierung testen kann, ob noch alles funktioniert. Schleicht sich irgendwo ein Fehler ein und ein Unterprogramm liefert falsche Ergebnisse, dann kann man durch Erweiterung der Tests sicherstellen, dass das nie wieder passiert.

Wie lange dauerts denn jetzt noch?

Vor Ende April schaffe ich einen Podcast nicht mehr. Anfang bis Mitte April kann ich es aber schaffen, einen Blogeintrag zu erstellen. Ein Podcast bedeutet mehr Aufwand, und deshalb benötige ich dafür mehr Zeit.

Was kann die erste Version

In der Version soll lediglich die Aktivität des Bitcoins gesnifft werden. Das bedeutet, die erste Version soll sich mit einem Node verbinden, den Handshake erfolgreich durchführen und anschließend die empfangenen Pakete soweit es geht anzeigen.

Also in kurz

  • Fertige Programmierung des Handshakes: Anfang April
  • Blogeintrag zur Version: Anfang bis Mitte April
  • Podcast: Wahrscheinlich Ende April

Happy Bitcoining! Und lasst euch nicht vom Gox stressen!

Dienstag, 11. Februar 2014

Bitcoin selber programmieren

Heute habe ich beschlossen, einen Bitcoin Client selbst zu programmieren. Zusätzlich will ich daraus einen Podcast erstellen, wobei jeder Teilabschnitt als eine Episode zusammengefasst wird.

Welche Programmiersprache?

Zunächst bin ich zwischen C, C++ und Python geschwankt, habe mich jedoch letztendlich für Python entschieden. Warum nicht C oder C++? Weil ich ein Weichei bin! Die Aufgabe ist nicht einfach und obwohl ich der Meinung bin, dass ich das Bitcoin Protokoll relativ gut verstanden habe, reicht es noch lange nicht um dafür zu programmieren. Das Protokoll werde ich erst durch das Programmieren im Detail verstehen. Dadurch muss ich jedoch auch in meiner Programmiersprache möglichst flexibel sein.

Zusätzlich ist Python einfacher für die Zuschauer zu verstehen und nachzumachen.

Welche Lizenz?

Das habe ich nicht entgültig entschieden, auf jeden Fall OpenSource. Die Videos natürlich CC. Ehrensache!

Wen soll denn der Pfusch überhaupt interessieren??

Fresse!

Was kommt als erstes?

Zuerst werde ich versuchen, mich auf das Testnetzwerk zu verbinden und einfach nur mitlesen. Weitere Details sehe ich danach.

Wann geht's los?

Sobald wie möglich.

Montag, 10. Februar 2014

Bitcoin Bug, Preissturz und Mt. Gox

Als ich heute bei Fefe lesen musste, dass der Bitcoin tot sei und anschließend den Abwärztrend des Bitcoins sah, bin ich erst einmal ordentlich erschrocken. Nachdem ich mir aber näher angeschaut habe, was denn der Bug ist, musste ich schnell feststellen, dass Fefe doch manchmal gerne mal übertreibt.

Was war?

Kurz gesagt: Die Bitcoin Börse Mt. Gox wurde betrogen und Privatläute haben nichts zu befürchten. Darüber, ob man von einem Fehler im Bitcoin System sprechen kann oder ob es an dieser Stelle einfach nur unpraktisch ist, kann man sich sicher streiten.

Ganz einfache Erklärung

Nun mal zu den Basics. Um Geld von A nach B zu überweisen, wird im Bitcoin Netzwerk eine Transaktion erstellt. Das ist vereinfacht gesagt eine Sammlung aus Daten, die folgendes enthält:

  • Die Zieladresse und der Betrag bzw mehrere Zieladressen mit den zugehoerigen Betraegen
  • Eine oder mehrere Transaktionen und eine digitale Signatur dazu, um zu bestätigen, dass die Quelle im Besitz der Bitcoins ist.
  • Ein bischen anderes Zeug, das aber jetzt nicht wichtig ist.

Dadurch können in einer Bitcoin Transaktion mehrere Überweisungen in einem Schritt getätigt werden, da mehrere Quellen und Ziele möglich sind.

Um jeder Transaktion einen eindeutigen Namen zu geben, wird eine Prüfsumme über all diese Daten gebildet. Diese Prüfsumme ist jedoch nicht eine normale Summe. Ihre Berechnung ist darauf ausgelegt, dass eine kleine Änderung eine ganz andere Prüfsumme ergibt. Das passiert auch, wenn zum Beispiel Werte vertauscht werden.

Wie es gedacht ist

Lässt man sich von der Tauschbörse Mt. Gox Bitcoins auf ein Konto auszahlen, so erhät man diese Prüfsumme, welche als Name der Transaktion gilt. Diese wird einige Minuten später im Bitcoin Netzwerk "eingebrannt". Hat man keine Bitcoins erhalten, kann man sich an Mt Gox wenden, ihnen schreiben, dass die diese Transaktion nicht geklappt hat und sie zahlen die Bitcoins erneut aus. Das ist so, als wenn man eine Wahre von einem Onlineshop nicht erhält und sie bittet, diese erneut zu senden. Um zu überprüfen, ob die Reklamation stimmt, prüft Mt. Gox, ob der Transaktionsname nicht im Bitcoinnetzwerk vorhanden ist. Da diese Börsen sehr häufig Bitcoins auszahlen, verpacken sie sehr viele Auszahlungen gleichzeitig in einer Transaktion.

Nun der Hack

Jetzt kommen die Übeltäter ins Spiel! Diese lassen sich Bitcons auszahlen und verändern anschließend die Transaktion. Dazu reicht es zum Beispiel aus, zwei Adressen zu vertauschen, wodurch die Prüfsumme und somit der Name der Transaktion sich komplett ändert. Jedoch ändert sich sonst an der Überweisung nichts, wodurch sie vom Netzwerk akzeptiert werden kann. Es kann aber auch die originale Transaktion akzeptiert werden, jedoch nur eine von beiden. Das Geld wird also in jedem Fall von Mt. Gox abgezogen und den Adressen gutgeschrieben.

Hat das Netzwerk die veränderte Transaktion akzeptiert, dann hat sich auch deren Name geändert, der Mt. Gox bekannt ist. Nun beschweren sich unsere Bösewichte bei Mt. Gox, dass das Geld nicht angekommen sei (obwohl es das ist!). Mt. Gox findet den Transaktionsnamen nicht und zahlt erneut aus. Die Bösen haben also 2x kassiert.

Wo manipuliert wird ist mir nicht ganz klar. Entweder geschieht das, indem man die Transaktion abfängt und verändert weiterschickt oder beim "einbrennen" selber. Dass man selber beim "einbrennen" beteiligt sein kann ist jedoch sehr unwahrscheinlich. Bei meinem PC ist das beispielsweise im Schnitt ca ein mal in 200 Jahren. Das Abfangen muss sehr früh passieren, da sich sonst die originale Transaktion verbreitet hat und damit keine veränderte Version vom Netzwerk akzeptiert wird. Ist ist also sehr schwer, die Transaktion zu manipulieren oder ich übersehe etwas. Das ist jedoch egal, denn es ist möglich.

Mt. Gox soll halt dann genauer prüfen

Es reicht also nicht für den Mt. Gox, einfach die Transaktions ID zu prüfen. Jedoch kann er problemlos die Transaktionen speichern und bei Reklamationen überprüfen, ob die Zieladresse den Betrag erhalten hat. Das ist jedoch etwas mehr Aufwand aber durchaus umsetzbar. Jedoch ist mir jetzt nicht klar, wieso sie generell Auszahlungen stoppen. Sie haben mit den langweiligen, herkömmlichen Währungen ja schon eine Weile lang Probleme, auszuzahlen. Dadurch, dass sie jetzt auch noch keine Bitcoins auszahlen, machen sie sich keine Freunde.

Somit gilt: Eure Wallets sind nach wie vor sicher solange ihr darauf aufpasst! Niemals würde ich meine Bitcoins, falls ich welche habe, anderen online anvertrauen.

Und cool ist, dass man billig einkaufen kann :P

Der "Bug" im Bitcoin Netz ist übrigens seit 2011 bekannt und dokumentiert und Mt. Gox hätte schon lange darauf reagieren können.