Category Archives: Bitcoin

BitBet receivership first progress report

State of the receivership process

After working a few days on the BitBet receivership process I am pleased to present all interested parties with my first progress report. The work I have undertaken during these few days focused mainly on the identification and accounting of the theoretically available assets, as well as the listing of existing claims against BitBet.

As of today, I have received:
– from Matic Kočevar: the deedbot’d DB, codebase, and contents of the hot wallet amounting to 4.83337474 BTC [1, 2]
– from Mircea Popescu: the domain and the sum of 750.5 BTC.

Auctioneering of the source code, database and domain name

The source code, database, and domain will be auctioned as a single package during the next week, bids should be published directly in the comments, the highest bid at the end of Wednesday the 6th of April 2016 will be retained as buyer for the whole package.

After the completion of the auction I will publish a final list of assets, the list of certified claims (after resolving whatever bets can actually be resolved at that point in order to maximize the fee revenue). After that I shall give a few days for interested parties to comment and finally proceed to the actual transfers (Bitcoin and other assets).

State of the assets and liabilities

As of the today, the minimum  value of the assets in my possession is ~755 BTC, while the maximum total amount for the liabilities, should all claims be certified, is ~981 BTC.

  - Cash: 954.78385211 BTC (of which 755.33337474 BTC is currently under my control): 
    (1) Outstanding bets: 942.81955914 BTC,
    (2) Unpaid resolved bets: 8.75451297 BTC,
    (3) Zeroconf bets on unhandled proposals: 1.99978000 BTC,
    (4) Gracious donations: 1.21000000 BTC.

  - Non-cash assets for which the value is to be determined during the auction:
    - the '' domain name,
    - the BitBet database,
    - the BitBet source code.

Liabilities: 981.54108013 BTC, detailed as:
 - Mircea Popescu's bill: 17.94766149 BTC
 - Receiver's fee: 13.37 BTC
 - Bettor winnings: 331.69291390 BTC (335.04334737 BTC before 1% fee)
 - Bettor refunds for unresolved bets: 616.53072474 BTC
 - Bettor refunds for zeroconf bets on un-handled proposals: 1.99978000 BTC

Data used for this report

See the data files in plain text format, or in CSV format.

The lists of Bitcoin addresses to be used by BitBet, as transmitted by Matic Kočevar and clearsigned by Mircea Popescu [1, 2].

April 6th update: additional data as per my response to hanbot’s comment. It includes the outstanding bets as well as the resolved but unpaid ones. It also has the resolution timestamp included.

BitBet receivership formal application and letter of intent

As sad as it is, it appears BitBet has gone into receivership territory, and is therefore in need of a liquidator.

This letter of intent constitutes a formal offer from me, David François, senior lord of Bitcoin, TMSR~, to actually implement this liquidation, with the goal of maximizing stakeholder revenue, and if at all possible ensure operational continuity.

The actual implementation of the liquidation would consist of the following steps, as per Mircea Popescu’s description:

  • construction of the list of existing claims,
  • certification or rejection of each individual claim,
  • open sale of the disposable assets (either as a package, or separately),
  • payment of the liabilities on a best-effort basis, ordered by priority (certified bills, bet winnings & refunds, shareholders)

In order to accept my appointment as liquidator and proceed with these actions, I require:

  • A signed acceptance statement by Mircea Popescu, and Matic Kočevar,
  • the actual assets (cash, domain, code, database).

The transfer of the BitBet cash is to be made to the 1DavouTAsveznCFHsz688xvbrRAq4u2qm8 Bitcoin address and should include a 0.001 BTC fee that will be certified as a valid expense against BitBet.

The liquidation implementation will be charged against BitBet in the form of a certified 13.37 BTC bill for which I shall be the beneficiary.

The contemplated timeframe for completion of the liquidation is two weeks starting from the moment all the BitBet assets are under my control.

X.EUR March 16th 2016 statement

Hash: SHA1

X.EUR statement, issued on Wednesday the 16th of March 2016 at 10:47 CEST

Close              : 0.00292981 BTC (+0.00009713 BTC / +3.43%)
Close imp. EUR/BTC : 341.32 EUR/BTC 
Open interest      : 5`413          (-2`124 X.EUR / -28.18%)
Volume             : 15`767         (   -34 X.EUR /  -0.22%)
Collateral         : 40 BTC

Version: GnuPG v1 ( Bitcoin computer)


X.EUR February 17th 2016 statement

Hash: SHA1

X.EUR statement, issued on Wednesday the 17th of February 2016 at 11:14 CEST

Close              : 0.00283268 BTC (+0.00024458 BTC / +9.45%)
Close imp. EUR/BTC : 353.02 EUR/BTC 
Open interest      : 7`537          (  -855 X.EUR / -10.19%)
Volume             : 15`801         (+3`553 X.EUR / +29.01%)

Version: GnuPG v1


X.EUR January 15th 2016 statement

Hash: SHA1

X.EUR statement, issued on 15/01/2016 16:27 CEST

Close              : 0.00258810 BTC (+0.00011601 BTC / +4.69%)
Close imp. EUR/BTC : 386.38 EUR/BTC 
Open interest      : 8`392          (-1`586 X.EUR / -15.89%)
Volume             : 12`248         (+4`794 X.EUR / +64.31%)

Version: GnuPG v1


X.EUR December 16th statement

Hash: SHA1

X.EUR statement, issued on 16/12/2015 15:15 CEST

Close              : 0.00247209 BTC (-0.00095922 BTC / -27.95%)
Close imp. EUR/BTC : 404.52 EUR/BTC 
Open interest      : 9`978          (+1`578 X.EUR / +18.79%)
Volume             : 7`454          (+1`391 X.EUR / +22.94%)

Version: GnuPG v1


X.EUR November 15th statement

Hash: SHA1

X.EUR statement, issued on 15/11/2015

Close              : 0.00343131 BTC (-0.00113595 BTC / -24.87%)
Close imp. EUR/BTC : 291.43 EUR/BTC 
Open interest      : 8`400          (+1`614 X.EUR / +23.78%)
Volume             : 6`063          (+  978 X.EUR / +19.23%)

Version: GnuPG v1.4.13 (GlutenFree(tm) edition)


X.EUR October 16th statement

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%)

Version: GnuPG Deluxe v1.4.13 (Amstrad CPC 6128)


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 !

Paymium releases a remittance protocol RFC

Download the RFC document.

After witnessing the Coinbase and BoA derps trying to patent “increased molecular agitation of dihydrogen monoxyde”[1], Paymium has decided to release its remittance protocol RFC to the public.

The process described by this protocol is in no way rocket science, but will still greatly benefit from being properly timestamped, and documented. Never hurts interoperability to speak the same language. This document is a work in progress, feedback is very welcome.

The implementation of remittances settled with Bitcoin obviously require liquidity sources on both ends of the remittance tunnel, this specification is to be implemented by exchanges or brokers that can efficiently transfer money in their local zone.

It leverages these local liquidity sources in order to provide streamlined money transmission features to end-users, without relying on the Bitcoin network to support the load of individual transfers[2], but only for settlement operations.

In essence, the remittance protocol is simply a way for an exchange to quote another exchange for a requested amount in fiat.

If, for example, Rhonda in the U.S. wants to send 2,000 € to Jean-Robert, in France, Rhonda’s exchange will end up presenting her with a “Please confirm you’d like to send 2,000 € to Jean-Robert at Paymium. This will cost you $2,250.67” message.

The settlement part isn’t covered by the document, for the pretty simple reason that settlement is a business matter, not a technical challenge. It would also vastly complicate everything. Maintaining a balance, manually settling daily, automating Bitcoin transfers when a threshold is reached are all valid approaches to settling these remittances.

May the capital flow!

[1] Commonly referred to as “hot water”.

[2] Read: “without relying on the big-blocks insanity”.