Ingenico Group and Paymium team up to integrate Bitcoin payments on the Telium Tetra next-generation terminals

Ingenico Group and Paymium team up to integrate Bitcoin payments on the TELIUM TETRA next-generation terminals, allowing brick-and-mortar retailers to accept payments in Bitcoin.

Press releases:
English – Ingenico Group and Paymium team up to integrate Bitcoin payments on the TELIUM TETRA next-generation terminals
Français – Ingenico Group et Paymium s’associent pour proposer le paiement en Bitcoin sur la nouvelle génération de terminaux TELIUM TETRA

Read More now accepting Bitcoin payments with Paymium

Paymium is delighted and proud to announce that is now accepting Bitcoin payments in Europe, using Paymium’s merchant solution. becomes the largest European retailer to accept Bitcoin payments.

Press releases: now accepting Bitcoin payments with Paymium accepte les paiements en bitcoins en Europe avec Paymium

Read More

In 30 days, Bitcoin-Central will change its name to Paymium

UPDATE – Monday 23rd, June 2014:

The switch is done. Goodbye Bitcoin-Central, hello Paymium !

To access your customer trading account, simply go to and login as usual. Your credentials remain the same, and your user interface is about the same as well.

If you experience any issue with the new website, please open a ticket (or send us an e-mail if you can’t access your account). Your input is always welcome, do not hesitate to give us your feedback and tell us how we can improve.

Developers: API endpoints will live on both domains until January 2015.

Kind regards, the Paymium team.

Read More

Security, solvency and transparency of a Bitcoin exchange

In the aftermath of the oldest bitcoin exchange (MTGOX) shutting down, what is the plan at Bitcoin Central to handle security concerns ?


Ever since the new has been deployed last October (2013), all 100 % of bitcoins sent by customers to their account are put in « cold storage » “: Bitcoin Central does not store any bitcoin private key on customer-facing servers.

Each individual private key is split in n shares by a cryptographic secret splitting scheme that requires to gather p out of n shares to recover the key (p < n). The secret shares are printed on paper and put in sealed waterproof envelopes, stored in safe locations accross several jurisdictions. Thanks to this process, even if one or more (up to n-p) shares were compromised or destroyed, it would be possible to recover the key with the remaining shares.

2) Adequately rigorous technical and financial processes have been implemented, including a manual check of all bitcoin withdrawals before any bitcoin transaction is sent out.

This way, Bitcoin Central can prevent attempts at exploiting the malleability of bitcoin transactions.

External auditors specialized in computer security and in the Bitcoin protocol have thoroughly reviewed Bitcoin Central systems and processes.

3) Our customers have been briefed  about the basics of home computer security: use of a strong password different from other passwords used on other sites, two-factor authentication via yubikey or Google Auth.

What about « proof of solvency » ?

Until the inception of Bitcoin, there was no easy way for a financial service provider to prove its solvency.

By virtue of the Bitcoin technology, we can now devise new ways to proactively share information proving our solvency without disclosing any sensitive individual account data.

We will publish as soon as possible a periodic bitcoin solvency report, most likely a quarterly solvency report, as a first step.

The level of transparency we are aiming at is unknown in the traditional banking sector. It is made possible by the unique properties of Bitcoin.

We are considering several options, some of them having been discussed already on the forums.

Obviously, the disclosure should not open up any security vulnerability.
For instance, we cannot simply publish simultaneously a cold storage address and a message signed by the corresponding private key.

Doing so would defeat our purpose because signing the message entails pulling out the private key from its « cold storage» safe status, by definition.

We are currently evaluating solutions that would enable each customer to verify Bitcoin Central solvency while disclosing only the data strictly necessary to perform such verification. Stay tuned.

The CloudFlare MITM

EDIT 13/05/2014 : I didn’t know it when writing these lines, but Cloudflare was actually hacked a little while ago, this makes the following only more relevant.


A trend we’ve seen in the last couple years in the Bitcoin ecosystem is the usage of various DDoS protection services such as CloudFlare and Prolexic.

The way these services work is that they sit between the internet and the website to protect and “filter” the malicious packets and only let “legitimate” requests through. That’s usually referred to as a “Man-In-The-Middle”, or MITM.

Currently CloudFlare seems to be the most popular, so we’ll use it as an example, but the arguments apply just as well to any similar service.

In addition to DDoS mitigation, CloudFlare provides websites with a bunch of additional goodies: CDN, analytics, first level WAF, service of static pages when the website is overloaded etc. All these features make it a pretty popular choice for a lot of websites.

Using CloudFlare has some downsides though, especially if you handle sensitive data, such as financial data, and even more sensitive data: Bitcoin-related information.

What could possibly go wrong?

For an SSL-protected website, using CloudFlare has major security implications. When your website is secured with an SSL certificate CloudFlare requires it do be able to do its job. In other words, all your traffic transits in clear through the CloudFlare servers. If your trade is organic cupcakes, you probably won’t care. If you’re CTO at Bitstamp, then keep reading.

It wouldn’t be that bad if you handed over your SSL certificate to some random guy on the internet, because that guy would still have to manage to listen to your connections. In the CloudFlare case it’s much worse, you’re voluntarily setting up a permanent MITM, and giving the attacker all the cryptographic keys to decrypt your traffic on the fly on the way in, and alter the response on the way out.

Just a couple of things that can be done easily, and with the assurance of not being detected, if one can access the unencrypted channel:

  • Your passwords could be sniffed,
  • your sessions could be hijacked (and 2FA won’t help),
  • your identification documents could be stolen,
  • a foreign government could subpoena CloudFlare

A big part of the problem is that most of these attacks would go undetected, and that they could be performed selectively. There would also be no way to relate an account getting mysteriously compromised to a password having been leaked at CloudFlare.


This reality won’t change no matter how much marketing talk is poured over the issue, by using DDoS mitigation you’re allowing someone you don’t know to look at your unencrypted traffic.

And that’s why, at Bitcoin-Central, we don’t use CloudFlare.

The Chameleon, first impressions

The Chameleon USB stick is advertised as a way to securely and transparently encrypt portions of a file-system by performing the actual encryption directly on the hardware device using a symmetric AES-256 key.

It’s pitched as an easy way to benefit from strong encryption for your sensitive data with the protection of a physical token. This sounded interesting, so I thought I’d give it a shot and report the results.

It didn’t go very far.

Chameleon supports Windows XP, Vista, and 7.

That was quick. None of us uses Windows so the hands-on review ended here.

Out of curiosity I kept reading the manual to find out that you can “duplicate” a lost Chameleon:

The dialog box of shame

The way it works is that when setting the Chameleon up you can provide it with a passphrase, from which the actual encryption key is derived. By doing so it limits the entropy of the key to the entropy of the passphrase. And for most users that’ll dramatically weaken the encryption.

People being really bad at generating randomness is something that you should know if you manufacture a secure hardware element.

Should encrypted data get stolen it would be possible to crack the key with the usual offline-cracking methods that enable attackers to break long and seemingly strong passwords.

Tools like the password haystack are very misleading when assessing the strength of a passphrase or a password. That’s because they don’t check whether your passphrase matches a common pattern or whether it has a meaning as a sentence for example. Such tools would be accurate only if the characters, or words, were chosen purely randomly.

Fortunately that can be fixed without changing the hardware: let the user provide a passphrase but mix it up with the output of a decent RNG, derive a 256 bit secret from it. That’s the secret that would need to be backed-up and from which the actual key would be derived.

This point is, incidentally, the very reason why brainwallets, unless done rigth, are a very bad idea from a security point of view.

If this got overlooked, what else did?

Malleability, not a problem for us

The issue of transaction malleability has been a prominent one during the last couple of weeks. It’s quite likely MtGox, and maybe others, suffered some losses because of it.

The core of the issue is that the ID of Bitcoin transactions can, under certain conditions, be changed. It is just the ID that can be changed though, not the transaction contents.

This has been exploited by some malicious users who managed to get some exchanges to send money multiple times for the same withdrawal request.

The reason for which this is not a problem for Bitcoin-Central is that we understand that it’s not wise to let an automated system send large amounts of money in irreversible transactions without constant human oversight.

We’re not immune because we have specific technical measures in place, we are immune because we track what we do, we can track what we do because we’re properly organized to do so. When you send a single transaction per day batching all the withdrawal requests it is much easier to not get fooled by a user who claims he didn’t receive his funds.

The security of an automated system also lies in the organizational procedures that are in place to ensure proper human oversight on sensitive actions.

It wouldn’t be very secure to let an ATM dispense gold ingots, it’s not very secure either to let an automated system send hard cash over the internet.