Comment fonctionne les transactions bitcoins pour les nuls.

Comprendre comment fonctionne le système de transactions des bitcoins n'est pas simple, on trouve bien ce schéma sur zerohedge qui a le mérite de faire une bonne synthèse mais ne s'adresse pas exactement à des "nuls". Je me propose donc de le faire ici, car je suis aussi un "nul".

Lorsque je parle de bitcoins avec mes amis l'idée d'une monnaie virtuelle ne plait pas beaucoup, parce que c'est virtuelle justement. J'ai souvent pas trop de mal à contrecarrer cet argument en expliquant que finalement une monnaie papier est tout aussi virtuelle, c'est une norme imposée par une banque centrale et qu'à tout moment on risque une très grosse inflation, si cette banque a envie de faire marcher son imprimerie.

Prenons l'or ou l'argent, bitcoins est beaucoup plus proche de ces valeurs d'échanges que ne pourrait l'être l'euro ou le dollar. Aucune banque ne peut émettre artificiellement de l'or. Si on veut mettre plus d'or sur le marché il faut le sortir des mines et de toute façon les ressources sont physiquement limités par les réserves naturelles de la planète, plus ça va plus obtenir de l'or devient dur.

Et bien bitcoins suit exactement cette règle. Il s'agit de séquences numériques obéissant à des propriétés mathématiques particulières qui font qu'elles sont  limitées en nombre (21 millions de séquences possibles) et plus ça va plus c'est difficile à trouver.

A ce stade vous me direz qu'à la différence de l'or le bitcoin n'est qu'une séquence numérique, je n'ai qu'à faire un copier coller. Avec de l'or ou de l'argent (ou avec sa copine) on ne peut pas faire de copier coller. Comment est-ce qu'on garantit que quelqu'un n'envoie pas deux fois le même bitcoins à des personnes différentes ?

Et bien c'est ici qu'intervient ce que l'on appelle le journal des transactions, à chaque fois que vous versez un bitcoins à quelqu'un vous le déclarez à tout le réseau et tous les nœuds l'enregistrent dans leur journal de transaction. Finalement le bénéficiaire du bitcoin recevra des confirmations des autres membres du réseau lui signifiant que cette transaction est valide.

Si par exemple le noeud 1 après avoir envoyé des bitcoins au noeud 2 tente d'envoyer maintenant les mêmes bitcoins au noeud 3 il pourra le faire mais cette transaction ne sera pas validée par les autres noeuds qui dans leur journal de transaction auront enregistré que les bitcoins sont bien en possessions du noeud 2 et ne peuvent donc plus être transférés depuis le noeud 1.

En fait si le noeud 3 a un journal de transaction à jour il pourra lui-même invalider ce transfert car il pourra y lire que le noeud 1 a déjà donné ces bitcoins au noeud 2.

Oui mais là vous pourriez m'opposer cet argument : qui détient la vérité ? Comme nous sommes sur un système décentralisé chacun maintient le journal des transaction. N'oublions pas que c'est le journal de toutes les transactions ! Tout les échanges qui ont pu avoir lieu depuis la création du bitcoin sont enregistrés dans ce journal.  Donc ça pèse assez lourd sur un PC ...

Dans cette capture vous constatez que mon journal fait bientôt 8 Go ...

Et puis encore une autre question : si le logiciel est hors ligne pendant trois mois, comment remet-il à jour son journal quand il revient en ligne.

Ici mon client bitcoins remet son journal des transactions à jour, il a 11 semaines de retards.

Et bien la réponse à ces deux questions (qui détient la vérité et comment un journal de transactions est-il mis à jour) est la même : c'est celui qui à la plus longue qui a raison !

Non non, ça n'est pas ce que vous croyez, quand je parle de la plus longue, je parle évidemment de la longueur du journal des transactions. Ce journal de transaction est plus connus sous le nom de chaîne de blocks. Donc celui qui a raison est celui qui a la chaîne de blocks la plus longue. Et quand un client doit se remettre à jour il recopie la chaîne de blocks la plus longue disponible sur le réseau.

A ce stade on peut se poser deux questions : pourquoi des chaines de blocks, et pourquoi la plus longue est-elle la gagnante ?

On parle de chaine blocks parce que les transactions ne sont pas ajoutées une à une au journal des transactions mais elles sont regroupées en blocks et sont ensuite intégrées au journal de transaction.

Mais ce processus d'intégration du block est un processus qui exige de la puissance processeurs et surtout qui peut être fait collectivement. Ainsi 10 processeurs répartis sur le réseau travaillant collectivement à l'intégration d'un block ira plus vite que 5 processeurs ayant les mêmes caractéristiques. Ce qui nous amène à ceci : s'il y a plus de gens honnêtes qui travaillent pour intégrer des blocks que de gens malhonnêtes alors la chaîne de blocks qui détient la vérité sera la plus longue ...

Pour ne pas aider ceux qui serait tenter de "réécrire l'histoire des transactions", l'intégration d'un block dépend toujours du block précédent.

Supposons que je sois un pirate qui décide de réécrire l'histoire des transactions et que je décide de changer une transaction située dans le bloc b3.

Je ne devrai pas seulement refaire l'intégration de b3 à la chaine mais aussi de b4, b5 et b6, ce qui va exiger du temps et de la ressource. Pendant ce temps les nœuds honnêtes continue d'ajouter des blocks, ils sont donc toujours en mesure de présenter une chaîne plus longue que celle je tente péniblement de réécrire.

En fait on montre que la probabilité qu'un pirate rattrape les blocks diminue exponentiellement a chaque bloc de retard. Et pendant que le bénéficiaire attend les validations de nouveaux blocks sont ajoutés.

Mais alors comment sont rémunérés ceux qui valident les blocks. Et bien vous pouvez accélérer les validations en intégrant des frais de transactions, le nœud qui aura intégré votre transaction dans la chaîne recevra ces frais.

Pour conclure on a un système qui est garanti par une information faisant autorité sans que cette information soit garantie par une autorité. C'est quelque chose de complètement nouveau qui n'a pas de précédent dans l'histoire.

Transformation vs Job in kettle

When I started to learn kettle I bump into two keywords : Job and Tranformation. And I was unable discriminate bettwen the two.

 Transformation is about managing a flow of column. By managing I mean getting it from an output like a csv file, adding new columns, transforming their values or assigning values, doing cartesian product, removing etc to finally send them to an output like a table in a database.

 Here is an example in the Spoon IDE of a transformation that load a dimension table:
A transformation is made of steps (max_dim_staff_last_update, Staff, Select values ...) that alterate the flow of columns.

Job manage the transformations. A job is made of  transformations. The job define in wich order the transformation are going to be called. For instance you first need to update all the dimensions tables before updating the facts table in an olap cube. Here is a Job in the Spoon IDE, you can notice that all the dims are loaded before the facts :

Another difference is about the flow of data. In a transformation when a line is done in a step, it's passed to the next step and doen't wait that all the lines are done. But in a Job the data is passed from a transformation to the next when all the lines in the previous transformations are treated.

Actually, often no data are passed from a transformation to another. For instance nothing is passed from load_dim_staff to load_dim_customer.

Créer un pool de connexion Olap avec Olap4J et DBCP

Olap4J est un projet qui a (entre autre) pour but d'exposer les connexions et les requètes Olap comme des requêtes JDBC. Cela présente beaucoup d'avantage comme par exemple le fait de se retrouver avec des api que l'on connait déjà bien ou de pouvoir utiliser les efforts déjà fait sur les pool de connexion comme C3P0 ou common DBCP.

J'ai rencontré quelques difficultés en utilisant DBCP 1.2.1, et vous devrez pour des raisons de "legacy" souvent travailler avec cette version de la librairie. A la suite je présente le code que l'on pourrait utiliser avec dbcp 1.4

Getting the number of weeks in a year

Why using memcached instead of a local cache solution

I decide to have a look to memcached and see what  it is all about. I found this small self-explenatory story in their wiki. I finally understood that memcached let you use the ram of other servers in your network. Actually you query this distributed cache through TCP-IP

Memcached has an algorithm that choose the server based on the key input.

But it supposes you buy new servers, connect them to your network. And if you need to increase your cache to, let's say 1 Gb, you need to buy a new server ! This caching solution look expensive to me and do not compete with a local cache. It is true that accessing data in the RAM is much faster than accessing data on a local storage, but there is the overhead of the TCP connections.. ...

On his blog  Artur Ejmond compares APC (Which is a local cache solution) and memcached. The result is clear APC is much faster and much cheaper.

Then why using memcached instead of a local cache solution ?

I can see two reasons  :

1. You have more than one client for the cache and you want all of them to share the same cache
2. Theres's a lot of write on the cache and your disk risk to bottleneck

I know that many major sites like wikipedia or twitter use memcached, but I would be happy to hear why you choose memcached over a local cache solution. 

Algobox Challenge

Pour tous ceux qui connaissent Algobox j'ai un petit défi à leur proposer : Dessiner un flocon de Von Koch avec AlgoBox.

Pour être plus précis en fonction du nombre d'itération n défini par l'utilisateur on réalise le flocon.



C'est un défi car en général ces problèmes sont faciles a résoudre avec la récursivité, mais Algobox ne permet pas de faire de la récursivité.

Dans mon cas j'ai un peu dégénéré le flocon en faisant le carré central plus court pour mieux voir les contours.

n = 2

 n = 3

 n = 4

 n = 5

Cette exercice est le plus avancé que je propose sur Algobox. Les heureux challengers se verront cités sur twitter et je confirmerai leur compétence sur Viadeo en Algorithmique (super prix ;-).

Bon courage.

Testing your email with papercut

If like me you developp application that send emails you wonder how to test them.

Papercut is a very simple and efficient solution.

Download the zip on http://papercut.codeplex.com/

Papercut is a simple smtp server that take any mail send to localhost and whow them in its GUI.

Start Papercut


Then every time an email is sent I can see it on the gui


I changed nothing on my php.ini

[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP = localhost
; http://php.net/smtp-port
smtp_port = 25


Really really useful and easy to set up.