Monthly Archives: October 2015

X.EUR October 16th statement

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

X.EUR statement, issued on 16/10/2015

Close              : 0.00456726 BTC (-0.00031291 BTC / -6.41%)
Close imp. EUR/BTC : 218.95 EUR/BTC 
Open interest      : 6`786          (+2`032 X.EUR / +42.74%)
Volume             : 5`085          (+  223 X.EUR / + 4.59%)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG Deluxe v1.4.13 (Amstrad CPC 6128)

iQEcBAEBAgAGBQJWIQ/bAAoJEBMojqsBcTQojyQH/ioYHVyLgTZkaQyy6LflEv6a
KOH3DahShfeMfpJDRROGDsiV2IJ+yh62DdbueY0yhw6hBF2L3oGgmJXPVF8wsb5o
r99I6x9Vo541OeEV2/xe+UYNmxcjqlxLjQwK+ZPswXRLKfolGiF4+sdAiN0s9EvL
KbZSVgLorvtRUxbCbTGAyk9Yb5FRKhnudFlWhnPsGxMJdnEmdEp32gPTSnhTYAkA
Lrt5yo1REtJAR0htUja56XTamoE+bjnqDDPEdtyn0BX0XzjotuwkFQQBYVehHGw5
bLqe4+1D9YtQKzP4v84lbdMjiz6STeiYfWQbD02cqDZM57E47vrzt/gxNE+uZxs=
=6k+8
-----END PGP SIGNATURE-----

Why GPG subkeys must die

I’ve always looked at GPG subkeys with a bit of fascination, thinking it’s the thing that separates GPG aristocrats from ignorant crypto-peasants like myself. Turns out that, while the idea of having master and slave keys is cryptographically sound, the GPG implementation is insecure.

As usual, #bitcoin-assets has it, and tells us exactly why.

Yes, the reason is simply that what glues the master and the sub together, is a SHA1 hash. According to Schneier it cost ~$3mn in 2012 to find an arbitrary SHA1 collision. That alone is grounds to burn the whole thing down.

Now imagine what the figure has become in 2015, when the Bitcoin-world has spent the last six years relentlessly looking for more efficient ways to bruteforce the living crap out of SHA2.

One of the reasons, among others, that re-doing GPG has been on #b-a’s TODO for a while.

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 !