JSON RPC und Python

Einfach nur toll!

JSON-RPC ist ein einfaches Protokoll, um remote auf einem Server Funktionen aufzurufen.

Hierbei kann eine Kommunikation ganz einfach so aussehen:

--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- { "result": "Hello JSON-RPC", "error": null, "id": 1}

Serverseitig wird die Methode ‚echo‘ aufgerufen. Als Parameter wird (in diesem Fall) ein Array mit einem einzelnen String übergeben.

Das alleine ist noch nicht das tollste … In Verbindung mit Python ist das richtig genial …

from jsonrpc import ServiceProxy
s = ServiceProxy("http://.../jsonrpc")
print s.echo("Hello JSON-RPC")

gibt auf der Konsole aus:

Hello JSON-RPC

Selbstverständlich muss der Server die Methode unterstützen.

Auf Client-Seite muss man mit Python die Methode ‚echo‘ nicht definieren. Man ruft eine Methode mit einem beliebigem Namen auf und die Library erstellt daraus JSON-RPC-Requests, die an den Server geschickt werden. Der Methoden-Name wandert hierbei in das Feld „method“, die Parameter nach „params“. Die Library fängt auch Fehlerfälle ab, wie z.B. die Methode existiert nicht, oder es ist irgendein anderer Fehler aufgetreten.

So einfach ist das!

Demnächst mehr auf Server-Seite in Java … 🙂

Advertisements

FPGA Virtex6 Bitcoin Miner

Ui, da hab ich doch tatsächlich bei uns in der Arbeit ein ungenutztes Virtex6-Board gefunden.

In Windeseile den Xilinx-VHDL-Port des Open-Source Bitcoin Miners untergeladen und etwas für das ML605-Board und Virtex-6 angepasst.

Im Grunde musste ich nur den DCM durch einen neueren Clock-Generating-Core für V6 ersetzen, was gleich gemacht war.

Danach war der Source auch schon synthetisierbar.

Das Resultat ist ganz beachtlich. Es wird – laut Synthese-Tool – eine maximale Taktfrequenz von ca 100MHz erreicht, was mit einem einzigen Mining-Core schon um die 100MHash/s ergibt.

Der Mining-Core besteht aus einem kleinen UART-Modul für die Kommunikation mit dem PC und dem eigentlichen Miner, der selbst aus etwas Logik zum Inkrementieren der nonce und dem Vergleich auf das Target und zwei SHA256 besteht (Double-Hashing SHA256(SHA256(X))). Beeindruckend ist hierbei, dass pro SHA256 alle 64 Iterationen vollständig unrolled wurden, d.h. jeder SHA256 hat eine 64stufige Pipeline, die dann effektiv für 1MHash/s bei 1MHz sorgt.

In den Wahnsinns-Virtex (XC6VLX240T-1FFG1156) passen zwei komplette Miner, was insgesamt 4 SHA256-Cores und eine gesamt Hashrate von 200MHash/sec ergibt.

Mit zwei kompletten vollständig ausgerollten Minern ist der Virtex6 mit ungefähr 80% ausgelastet … Man müsste dann eigentlich noch einen langsameren Core hineinkriegen, der nur jeweils 32 Pipeline-Stufen hat. Vlt bekommt man so nochmal 25-50MHash/s zusätzlich raus … Muss ich ausprobieren 🙂

Dabei liegt der Stromverbrauch bei um die 30W (geschätzt, noch nicht nachgemessen), was natürlich unschlagbar ist.

Einziger Nachteil, der aber nur am Anfang nervt, bis alles läuft: Synthese + Implementierung dauern über 1,5h auf meinem Arbeitsrechner … Seufz!

Bitcoin-Desaster mit bitcoin-24.com

Mann, da hab ich ja immer ein Timing …

Als ich zuletzt im Juni 2011 mal etwas Spielgeld an MtGox per Sepa überweisen wollte, wurde 1 Tag später MtGox gehackt. Die Seite war erstmal einige Zeit down und sie rollten damals die Datenbank zurück, was zu viel Verluste geführt hat. Netterweise wurde ich von meiner Bank damals angerufen, ob ich wirklich die Überweisung tätigen möchte, was ich dann erleichtert verneinte 😉

Dieses mal wollte ich das Spielgeld an bitcoin-24.com überweisen. Nach etwas Googeln schien bitcoin-24 doch ziemlich glaubhaft zu sein … Sie akzeptierten giropay, was das Aufladen des Kontos dort doch wesentlich beschleunigt und vereinfacht hat.

Weniger als 24h, nachdem ich mein Geld dort hatte, passierte es plötzlich. Es wurden einige Fehler der Trading-Engine gemeldet, die dazu führten, dass mehrere Orders gleichzeitig ausgeführt wurden, obwohl Benutzer garnicht genügend Guthaben hatten, was dazu führte, dass sie dann plötzlich mehr bitcoins hatten, als sie sich hätten leisten können.

Die Geschehnisse werden z.B. hier und hier diskutiert.

Beim Durchlesen der Threads fand ich einen Link zu StackOverflow, zu einem Beitrag, der „PHP / MySQL – how to prevent two requests“ hieß. Dort ging es darum, dass bei schnellem Handel es Probleme geben kann, die dazu führen können, dass Geld vom Guthaben-Konto doppelt ausgegeben werden kann.

Ich hab mir gedacht, das ist irgendein Kiddie, das sich dachte, mal eben eine Bitcoin-Börse in PHP + MYSQL zu coden. Ohne Kenntnisse was wahrscheinlich InnoDB-Tabellen sind und was MySQL-Transaktionen sind … Ich fand das eigentlich sehr drollig 🙂

In einem anderen Thread fand ich dann heraus, dass der Benutzer, der dort registriert ist und dem bitcoin-24 gehört, den Nicknamen TAIS hat. ( „von allen Exchages die ich bisher genutzt habe gehört der Service von TAiS46 zu den besten“ )

Der Benutzer, der auf StackOverflow die Frage zu Transaktionen gestellt hat, war ebenfalls von einem TAIS verfasst.

Ich bin wirklich fassungslos … Vorallem, weil die Plattform schon seit hmm … Mai 2012 läuft, im Februar wurde die Frage gestellt, und vor fast 2 Wochen häuften sich die ersten Meldungen, dass mit der Engine was nicht stimmt. Dazu gibt es sogar ein youtube-Video, was davor warnt …

Das wurde wohl ignoriert … Das ist schon echt ein starkes Stück und ein Paradebeispiel, was man alles verpfuschen kann und was das für Auswirkungen haben kann …

So, die Frage ist natürlich, was passiert jetzt und kriegt man seine BTCs und sein richtiges Geld zurück?

Keine Ahnung … Wenn BTCs verschwunden sind, sind sie sicherlich weg … Solche Transaktionen sind nicht rückgängig zu machen. Es hatten genügend Leute genügend Zeit, ihr Geld, das sie zuviel hatten, in Bitcoins zu tauschen. Oder ihr Zuviel an Bitcoins in Geld und wieder in Bitcoins zu tauschen.

Ob er dafür haftbar ist? Gute Frage … Ich hab in irgendeinem Thread gelesen, dass er eine Limited betreibt mit einem Postkasten in England … Was das heißt, dürfte jedem klar sein 😉

Noch eins …

Lektion 14 ist fertisch … Nur noch eine Lektion, dann bin ich mit dem Buch fertig.

Erstaunlich, dass ich dann wirklich Lektion 15 verstehen können soll / werde … Ich weiß noch, wie ich mir diese Lektion einfach mal so angeschaut habe und überhaupt nichts verstanden habe. Und plötzlich – nur ein paar Lektionen weiter – ist die richtig verständlich.

Freu mich schon, wenn ich das Buch endlich hinter mir habe … Dann ist ein Meilenstein erreicht und neue Motivation macht sich breit 🙂

Chilis Umgetpoft

Ich musste gestern nochmal Geld für Gemüseerde, Töpfe und eine Schale ausgeben … Das summiert sich ganz schön …

Bisher hat die Chili-Saison wahrscheinlich schon 100EUR gekostet, wobei das Verbrauchsmaterial (Erde) nur den geringsten Teil ausmachen. Regal, Beleuchtung, Töpfe, … Nächstes Jahr sollte ich dann wesentlich günstiger wegkommen 🙂

Gestern topfte ich die ersten Chilis um. 4 * Bhut Jolokia und 2 * Thai Dragon … Schön, dass gerade die BJ damals als erstes aufgegangen sind … Ist schon erstaunlich, was da 3 Wochen ausmachen …

chili

Die Thai Dragon sahen nur so groß aus, in Wirklichkeit waren sie nicht weiter entwickelt, als die anderen kleinen Habaneros mit dem echten Blätterpaar. Die ist wohl von hausaus hochwachsend …

Stellt sich mir jetzt die Frage, ob das eine gute Entscheidung war, die jetzt schon in Gemüseerde umzutopfen … Gemüseerde ist normalerweise etwas gedüngt, was gerade bei Jungpflanzen zu zwei Probleme führen könnte.

– Die Pflanzen werden faul, d.h. sie entwickeln die Wurzeln nicht richtig. Müssen sie ja auch nicht, wenn sie in der vorgedüngten Erde auch so genug Nährstoffe finden.

– Die Wurzeln sind so empfindlich, dass der Dünger die Wurzeln verbrennen könnte.

Deshalb gibt es Anzuchterde, die (oft) keimfrei und nährstoffarm ist … Eigentlich hätte ich die 2 * TD nochmal in Anzuchterde pflanzen sollen, aber ich hoffe, es macht nicht soviel Unterschied.

Man kann ja auch alles übertreiben 🙂

MythTV und DVB-C + DVB-T

Nachdem die Grundverschlüsselung im Kabel endlich abgeschalten wurde, habe ich mir einen DVB-C USB-Stick gekauft, um meinen MythTV mit Kabel-Programmen aufzurüsten.

Der Stick war erstaunlich schnell installiert und konfiguriert …

Mein MythTV besitzt jetzt 2 * DVB-T und 1 * DVB-C …

Ich fragte mich erst, wie klug MythTV sein würde, wenn ich gleiche Sender auf unterschiedlichen Sticks mit unterschiedlichen Frequenzen haben würde und ob es dann anfangen würde, auf DVB-T und DVB-C die gleiche Sendung aufzunehmen, weil die unterschiedlichen Video-Sources (und damit auch Kanal-Listen) zugeordnet sind.

Zu meiner Überraschung macht es MythTV ganz richtig … Beim Erstellen einer Aufnahmeregel ´ala „Auf diesem Sender immer aufnehmen“ wählt es ganz korrekt DVB-C (aufgrund eingestellter Priorität) und nimmt aber das gleiche Programm nicht über DVB-T auf, obwohl dort ja ebenfalls die gleiche Sendung läuft. Das macht es ebenfalls, wenn ich in meiner Program-Guide eine Sendung vom DVB-T wähle … Channels sind zweimal in der Program-Guide … Die doppelten kann ich aber weit nach hinten sortieren, sodass ich sie garnicht mehr sehe und es werden trotzdem die DVB-C Kanäle verwendet, wenn ich einen DVB-T Kanal aufnehme … Sehr clever alles!

Hin und wieder kann es aber vorkommen, dass EPG-Daten auseinanderlaufen, weshalb eine Sendung dann tatsächlich auf beiden aufgenommen werden würde … Wenn ich aber den EIT-Grabber deaktiviere und lieber einen 10er im Jahr für gute EPG-Daten investieren würde, könnte ich dieses Problem auch noch lösen.

Aber egal … Im Grunde funktioniert es genau so, wie es sein sollte und Ausnahmen werden dann einfach gelöscht 🙂

MythTV ist schon echt super … Die Multi-Tuner und -Quellen Unterstützung ist schon echt Hammer ausgereift! 🙂

Chilis Update

Die kleinen wachsen und wachsen und sind schon bald nicht mehr so klein …

Erstaunlich, was 3-4 Wochen Vorsprung in der Größe ausmacht!

Die Bhut-Jolokia sind deutlich größer als alle anderen … Wenn alle anderen in 3-4 Wochen ebenfalls so groß sind, kriege ich ein ziemliches Platzproblem …

chili-2013-04-01

Ich muss mir dringend kleine Töpfe kaufen und die großen umtopfen … 🙂