Développer un serveur de micropayment bitcoin
Retour d'expérience sur deux implémentations
Conférence donnée à Open Source Summit PARIS, le 16 novembre 2016
Développer un serveur de micropayment bitcoin - REX sur 2 implémentations - Open Source Summit PARIS
1. PREMIER EVENEMENT EUROPEEN
LIBRE & OPEN SOURCE
#OSSPARIS16
Implémenter un serveur de
micro-transactions en Bitcoin
Théorie et Pratique : retour sur 2 implémentations
Track « Blockchain et systèmes distribués »
Par Vidal CHRIQUI
@vidal007
Mercredi 16 novembre 2016
3. Protocole et Monnaie
5
Attention : le même terme est utilisé pour désigner un protocole et une monnaie
La monnaie bitcoin Le protocole Bitcoin
Utilisée pour des échanges de biens et
services
• par des marchands et e-commerçants
• par des individus
Utilisée à travers des portefeuilles (wallets)
Transferts « instantanés » dans le monde
Désigné par l’acronyme BTC (ou XBT)
Monnaie déflationniste et divisible jusqu’au
satoshi (10-8 BTC)
Un ensemble de règles permettant aux
différents nœuds du réseau Bitcoin de
fonctionner ensemble
• L’architecture générale
• L’algorithme de consensus et les
messages que les nœuds peuvent
échanger
• Le fonctionnement des wallets
• La façon d’utiliser les clés publiques et
clés privées
• Les règles d’émission monétaires
• etc…
4. Le chainage des transactions
Tx 0Tx 0
out 0
out 1
In 0100k
satoshis
Tx 1Tx 1
out 0In 040k
satoshis
Tx 2Tx 2
out 0
out 1
In 0
50k
satoshis
Tx 3Tx 3
out 0In 030k
satoshis
Tx 4Tx 4
out 0In 020k
satoshis
Tx 5Tx 5
out 0In 0
20k
satoshis
Tx 6Tx 6
out 0In 0
10k
satoshis
10k
UTXO
In 1
10k
satoshis
20k
UTXO
5. Frais de transactions
Principes
Les frais de transactions ne sont pas renseignés explicitement
dans la transaction. Il s’agit du montant d’unité de compte bitcoin
non affecté dans un transaction output.
La pratique dans l’univers bitcoin est que les frais de
transactions sont supportés par le payeur
Les frais de transactions ne sont pas obligatoires dans le
protocole. Toutefois, les utilisateurs sont encouragés à payer de
petits frais de transaction sur une base volontaire pour une
confirmation plus rapide et pour rémunérer les mineurs.
Cela sert également de protection contre les utilisateurs
émettant des transactions pour surcharger le réseau.
Tx 0Tx 0
out 0
out 1
In 01
BTC
0,1
BTC
0,899
BTC
Frais de transactions : 1- 0.1 – 0.899 = 0.001 BTC
6. Frais de transactions
Montants des frais de transaction
En pratique, ce sont les portefeuilles (wallets) qui calculent les
frais de transactions optimaux en fonction du degré
d’encombrement du réseau au moment du transfert.
Les mineurs traitent les transactions par ordre de priorité qui est
fonction du montant, de l’ancienneté et de la taille de transaction
La tarification actuelle
- Tarif de 0.00001 BTC/kb sur la taille (en octets) de la
transaction
- Exemple : 0.0001 BTC pour une transaction à 0.001 BTC
priority =
𝑆𝑈𝑀 𝑖𝑛𝑝𝑢𝑡_𝑣𝑎𝑙𝑢𝑒_𝑖𝑛_𝑏𝑎𝑠𝑒_𝑢𝑛𝑖𝑡𝑠 ∗ 𝑖𝑛𝑝𝑢𝑡_𝑎𝑔𝑒
𝑠𝑖𝑧𝑒_𝑖𝑛_𝑏𝑦𝑡𝑒𝑠
Source bitcoin Wiki
https://en.bitcoin.it/wiki/Transaction_fees
8. Micro-paiements
Problématiques
Le micro-paiement on-chain s’avère peu pratique :
• Envoyer beaucoup de transactions trop rapidement induira
une diminution de priorité voire un non relai des transactions
en raison du mécanisme de protection « anti flooding » du
réseau Bitcoin
• Il y a implicitement un montant minimal de transaction induit
par les frais de transactions à minima d’une transaction
• La personne qui reçoit trop de paiement à faibles montants se
retrouve avec des « dusts » difficiles (frais) à dépenser
9. Micro-paiements
Use cases
Micro-achat de contenu web
• Achat d’un article
• Visionnage vidéo
Paiement à l’usage sans créer de compte
• Appel téléphonique
• Consommation Wifi
• Recharge électrique
• Appel d’API
• Etc…
11. Payment Chanel
Analogie – L’ardoise dans un café ou un hôtel
Principe
- Le client donne une emprunte bancaire par rapport à un
montant maximal de dépense (exemple 100 euros)
- Il consomme au fur et à mesure et à chaque consommation
il signe pour confirmer son solde et dans la limite du montant
maximal défini (hors réseau CB)
- Quand il finit, il paie son solde
Intérêt du procédé
- Le réseau de paiement (ici réseau de CB) ne voit que 2
transactions, la première et la dernière et aucune de toutes
les autres « micro » transactions intermédiaires
- On ne paie moins de commissions de transactions que de
consommations effectuées.
Mettez
cette
dépense
sur ma
chambre
Mettez
cette
dépense
sur ma
chambre
12. Canal de paiement
Le canal de paiement en pratique
Un protocole en 3 étapes clés
Documenté dans le wiki bitcoin
https://bitcoin.org/en/developer-guide#micropayment-channel
Une implémentation de référence dans la libraire Java BitcoinJ
D’autres variantes et implémentations et notamment :
- 21 Inc (Python)
- Your Network (node.js)
- JoyStream (C++/QT)
- Et tout ceux qui travaillent sur le réseau Lightning (8)
Illustration extraite de
https://bitcoin.org/en/developer-guide#micropayment-channel
13. Pour le détail du protocole, je vais faire
appel aux célébrités crypto ……………
14. Pour le détail du protocole, je vais faire
appel aux célébrités crypto Alice et Bob
16. Alice
(Acheteur)
Bob
(Marchand)
22
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
17. Alice
(Acheteur)
Bob
(Marchand)
33
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
3 - Alice soumet un refund (non signé) qui rembourse l’output
18. Alice
(Acheteur)
Bob
(Marchand)
44
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
3 - Alice soumet un refund (non signé) qui rembourse l’output
19. Alice
(Acheteur)
Bob
(Marchand)
55
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
20. Alice
(Acheteur)
Bob
(Marchand)
6.16.1
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
Payment 1Payment 1
Out-contract
5000 satoshis
Out-contract
5000 satoshis
4900 satoshis4900 satoshis
100 satoshis100 satoshis
6 – (N fois) Alice crée un paiement comparable à un refund partiel
6 – (N fois) Bob vérifie la signature et continue à fournir le service
21. Alice
(Acheteur)
Bob
(Marchand)
6.26.2
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
Payment 2Payment 2
Out-contract
5000 satoshis
Out-contract
5000 satoshis
4800 satoshis4800 satoshis
200 satoshis200 satoshis
6 – (N fois) Alice crée un paiement comparable à un refund partiel
6 – (N fois) Bob vérifie la signature et continue à fournir le service
22. Alice
(Acheteur)
Bob
(Marchand)
6.N6.N
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
Payment NPayment N
Out-contract
5000 satoshis
Out-contract
5000 satoshis
4000 satoshis4000 satoshis
1000 satoshis1000 satoshis
6 – (N fois) Alice crée un paiement comparable à un refund partiel
6 – (N fois) Bob vérifie la signature et continue à fournir le service
23. Alice
(Acheteur)
Bob
(Marchand)
7.17.1
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
Payment NPayment N
Out-contract
5000 satoshis
Out-contract
5000 satoshis
4000 satoshis4000 satoshis
1000 satoshis1000 satoshis
6 – (N fois) Alice crée un paiement comparable à un refund partiel
6 – (N fois) Bob vérifie la signature et continue à fournir le service
7.1 – (normal) Clôture du canal, Bob signe et publie le paiement N
24. Alice
(Acheteur)
Bob
(Marchand)
7.27.2
1 - Alice génère une clé (pub) et demande une clé (pub) à Bob
ContractContract
Out-contract
5000 satoshis
Out-contract
5000 satoshis
InputInput
2 - Alice soumet un contrat (non signé) avec output multi-sig
RefundRefund
Out-contract
5000 satoshis
Out-contract
5000 satoshis
5000 satoshis5000 satoshis
4 – Bob signe le refund timelocké à 24h
5 - Alice vérifie, signe et publie la transaction « contract »
3 - Alice soumet un refund (non signé) qui rembourse l’output
Payment NPayment N
Out-contract
5000 satoshis
Out-contract
5000 satoshis
4000 satoshis4000 satoshis
1000 satoshis1000 satoshis
6 – (N fois) Alice crée un paiement comparable à un refund partiel
6 – (N fois) Bob vérifie la signature et continue à fournir le service
7.1 – (normal) Clôture du canal, Bob signe et publie le paiement N
7.2 – (absence) Clôture du canal (24h), Alice signe et publie
25. Focus sur le refund
Script de timelocking
OP_IF <Bob's public key>
OP_CHECKSIGVERIFY
OP_ELSE
1452955945 OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_ENDIF
<Alice's public key> OP_CHECKSIG
27. Implementation via 21
Utilisation de la librairie python -
OP_IF <Bob's public key>
OP_CHECKSIGVERIFY
OP_ELSE
1452955945 OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_ENDIF
<Alice's public key> OP_CHECKSIG
31. Pour aller plus loin
Variantes et évolutions du protocole décrit
• Duplex Micropayement channel
Canal de paiement similaire à celui décrit dans cette conférence
ave un aspect bi-directionnel
• Lightning network
Réseau de paiement offchain basé sur un ensemble de canaux
bidirectionnels ouverts et qui réalisent de la compensation de
paiement
32. #OSSPARIS16
Merci de votre attention
THANK YOU
Partagez vos commentaires sur #OSSPARIS2016
Retrouvez moi sur twitter @vidal007
Merci à @OSS_PARIS