Mon ami noir, ou les remittances en questions

Je ne suis pas raciste : j’ai un ami noir, il s’appelle Gilles Cadignan. Suite à l’article Paymium releases a remittance protocol RFC il a eu la gentillesse de me faire un retour intéressant qui nous permet d’aller un peu plus loin sur le sujet. En attendant la deuxième version du document qui les prendra tous en compte !

Une des premières choses précisée dans le document est l’externalisation de la partie « settlement » du protocole. Cela donne une grande liberté d’implémentation aux différents échanges et possiblement autant d’implémentations que d’accords inter-échanges. On pourrait donc se retrouver avec une multitudes d’implémentations au sein d’un meme échange ayant passé plusieurs accords. Au final cela représenterait des coûts supplémentaires à la fois pour la mise en place d’un accord spécifique et sa maintenance au fil du temps. Notre première question est donc la suivante : pourquoi ne pas standardiser le settlement au sein du protocole ? Pourquoi ne pas utiliser le protocole Bitcoin pour proposer une solution générique de settlement qui serait paramétrable en fonction des différents accords commerciaux passés ?

Le settlement est clairement une partie essentielle d’un arrangement business permettant à un tunnel de fonctionner correctement. Toutefois, étant donné la disparité des situations, des arrangements possibles et de la confiance mutuelle que se portent les deux sources de liquidité il paraît préférable de ne pas complexifier inutilement la description des interactions techniques automatisées entre les deux partenaires.

Et c’est la un autre point important, si un document décrit un protocole technique c’est, au moins en partie, dans le but d’en automatiser le fonctionnement. Et à mon sens (et l’expérience l’a montré plusieurs fois), s’il y a bien une chose à ne pas automatiser, c’est bien les transactions Bitcoin, pour toutes les raisons qu’on connaît.

L’API propose d’identifier le destinataire à l’aide de son login au sein de l’échange cible. Ce login représente une information personnelle et potentiellement une donnée exploitable par l’émetteur et d’autres acteurs malveillants. Pourquoi ne pas utiliser un identifiant pseudonyme, une adresse BTC par exemple, que le destinataire fournirait à l’émetteur pour effectuer son envoi ?

Les exemples mentionnent en effet des adresses e-mail, cependant ça n’a rien d’une contrainte, l’identifiant est laissé à la convenance des parties qui conviennent d’une “identifying string for the beneficiary”.

La mise en place d’un tel protocole implique un consensus entre tout ou partie des échanges bitcoin. Cela implique également l’existence d’un groupe ou organisme dédié à sa maintenance et sa gouvernance. Le succès d’une telle initiative repose sur son adoption par un nombre conséquent d’échanges et implique un consensus global sur le sujet. Avez-vous discuté de cette idée avec d’autre échanges ? Est-il prévu la création d’un organisme ou « syndicat » mondial des échanges bitcoin ?

L’utilisation du protocole n’implique pas de consensus particulier, si ce n’est entre les deux parties qui l’utilisent. Le mécanisme fondamental de consensus qui sous-tend un possible réseau mondial de partenaires 2-à-2 existe déjà, c’est Bitcoin !

One thought on “Mon ami noir, ou les remittances en questions

  1. Mircea Popescu

    Le settlement est clairement une partie essentielle d’un arrangement business permettant à un tunnel de fonctionner correctement. Toutefois, étant donné la disparité des situations, des arrangements possibles et de la confiance mutuelle que se portent les deux sources de liquidité il paraît préférable de ne pas complexifier inutilement la description des interactions techniques automatisées entre les deux partenaires.

    Nevertheless, this is the bread and butter of standardization : it takes complex situations and provides complete solutions. In order to have a standard in the first place these two requirements must be met, that a) any question which may arise in the field will be answered by the standard, as a hard guarantee and b) that any answer is implementable in finite time with finite resources. If either a or b are unsatisfied, why would this be a standard in the first place ?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *