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 bitbet.us 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.

Assets:
  - 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 'bitbet.us' 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

-----BEGIN PGP SIGNED MESSAGE-----
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1 (21.co Bitcoin computer)

iQEcBAEBAgAGBQJW6S0hAAoJEBMojqsBcTQo1fIH/RLzG5Ku4lJifwZIie3yzdLL
t6EkeZkWrJ0/uvXNBDJavmVpNNRM9ihah1vTVqU09WiyUR61oOHpSFvO56r4ySts
x4HakPwCp7X2k6s8fdE5IwmUGx73ADdHnUTP/DxmX2+gz4XPNWsu26FL9HG+kdij
D6GB/DxL5girN4H2vlDeeVKqsYlK3M9lXJHB0Llh09749tCwI+HFhUJLB528nnIr
3e8Lm2xUOZ4g/3xoyHSnYrAEfGBlus/U+U5itizbR8IVmFd5+lJ8r+0AfbIQY2Su
o1gaanh2z3WbNyMbLsvbQSr+phiNzW1phTnSaKqFxE9QWG6Sw1r2/buI01Zbewc=
=Znu7
-----END PGP SIGNATURE-----

X.EUR February 17th 2016 statement

-----BEGIN PGP SIGNED MESSAGE-----
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%)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWxEgJAAoJEBMojqsBcTQo7WcH/0vBOCOuJTfOcVqlBrlakWcL
9ibyDXC+I6cRTSKEuAu82vJa/xbtZEokc5l14grmqNjifJybz00jDaRPlAmUb6yc
vpKzgxxMQfTM6sWhEF6cU2TL3cThZrzhAO5QU4DSM08IZaLaUpa6CjsXRmRGq3f2
aOiXqzuaKtOx5kAFZ13DKzcGvBvHSEwGRL+HKEpHPMQf2WBbaLRqNdlRF45xn5Oc
VR2azuat4kZjuMyxRYq1Utpy2XMXlk7zwx8xnkfIn6XNayVYxwBSLdMRNVyrSWrY
CjCsInAw/kwXJfrqvpXq109b+kO8HMWCIX7YCmkfIAdsjwSLUhJZx/dUybXU7g8=
=31vn
-----END PGP SIGNATURE-----

X.EUR January 15th 2016 statement

-----BEGIN PGP SIGNED MESSAGE-----
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%)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWmRFzAAoJEBMojqsBcTQoUVAH/Rzghn+z/m7VIdbPE1uBwWdV
pGONx5y4aAo0ljeJD/PrFv9Q/NNCwlZf5Ar1W9zadfjG731qvECqhivuqmzpX6Ow
7rEZeCH8CrnZxkIsugIc7lWHtNWqgaWc/SCvRHmpI6J4Kbc4N7Ull47kkbq7UzY2
T0t921QVBc+i0RjYaV3Y9Y75J8ozG5VtGFyJP8u8rhrcoh9ho6Fs6IIhrN9pcIFo
bM8b9Z6DIVG+DbCTxajdqpB7wzQCL1SAI2YXPHWc1OUvdSNLf0It77XLvgHbqSk+
3P6AmEXeRg5mUBagDZT7B6jg5g9xQ1KiU5tRHwmdjTysyx41fmBvtgsbuMa7nWE=
=4+10
-----END PGP SIGNATURE-----

X.EUR December 16th statement

-----BEGIN PGP SIGNED MESSAGE-----
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%)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWcXIvAAoJEBMojqsBcTQophcIAIRxQU4EvVtvB7CqtSf27RfB
Sym8uZ2zrWNDG5vaup0iaQ87KbBD9Bx/HaPsKQj7AAdJr0gLsomPR1AA2B5L2cPY
YHBhN9CAqfAbDqs/GMa+XHPJhp7V2mR8u/ZhbiRbKNBwUwkkw0D/AxqjKhNz+P2t
TmSNFkrtWGlvD05rET3FHbeJwLXcDf74ihW3S0NtLPw0f1kUkFBuhX95N7aN3+3R
b8sH76ttqLwfW4VnZLM3yIKFY423XM0ePlQ8O+FnDFD4loj689TmjLnTX6EaSTsu
xkUiguUUWaSVlAiTMCLjbjKtfS72c43wyGlsXfQNr+m3CMBLkRNOzbfyRyKhpkQ=
=pUGw
-----END PGP SIGNATURE-----

X.EUR November 15th statement

-----BEGIN PGP SIGNED MESSAGE-----
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%)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GlutenFree(tm) edition)

iQEcBAEBAgAGBQJWSN9MAAoJEBMojqsBcTQorI8IAIYxPh69m1Mw7RSFA25qFGxZ
kGsqZQInaWdCWs5nC+rIf0mEAVT0cgo4fDCFtKrg3Hc/zkychYBctX47pk4vv614
kytFfw0nEYZNaqe+XU45lEN4wEFqsTx7WeEqBJ6CWPuzlm8ApyVXscB6UpL/ixx6
+3jNcNvijwXdc89FKkIsVQugvTdtVVo7SWCeFqMgm5ZHGfa751nMzvWMlN5JFKOf
bvOikgLhdiTUK81ohe7MZVibqYZcBFozWDjbyjEoiAmkkqIvojjztfskSNQ42qL1
QkGKPawRNjeXhZdh2omwvai4OGBHZeBw7LO8Fz6dyKnQsszH7ieOlkqAMwVdwJs=
=yZKW
-----END PGP SIGNATURE-----

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 !