Bitcoin-Central - why don't people use this exchange??

[DannyM]

I really think not being on bitcoincharts.com anymore hurts the volume and liquidity at bitcoin-central.net. A lot of people won't bother to manually add an extra feed to their trading system and so they don't even notice the site.

[1713867480]

1713867480

[davout]

All that ends up being your problem, you know...

Yep, it is also my pleasure and passion

I'm using bitcoins the way there were intended to use,

I don't believe there is such a thing. But as long as you find somthing useful in them it's all good.

but I've already pointed several persons to your exchange and guess what... they didn't want to use it because of the €15 SEPA withdrawal fee and went to Intersango.

Competition is healthy, if they like Intersango they ought to keep using them, that happens at BC as well, returning customers are the bulk of the volume.

You are the one losing customers, not me :-)

Imaginary information is convenient, isn't it ? BC is not making a killing, but it's definitely gaining customers <3

[davout]

I really think not being on bitcoincharts.com anymore hurts the volume and liquidity at bitcoin-central.net. A lot of people won't bother to manually add an extra feed to their trading system and so they don't even notice the site.

Haha, yeah that is so right, BC used to be there, but at some point they required the API to change which I hadn't time to do at that moment.
It just got on top of my TODO

[davout]

Are you operating from France? Paytunia is a French company, isn't it?
Since the banque de France decision that MtGox needed banking permits, wouldn't the same be valid to Bitcoin-central for it to operate legally?

Not that I care about respecting stupid laws per se, but I do care about having my money lost or worse in case your exchange is shut down by the Elysée's mafia...

Let me elaborate on that, because that is a really important question.

First of all, I if remember correctly the judge of the Tribunal de Commerce de Créteil ruled that the bank had a right to terminate the account because it was not used for its original purpose, which was to be the primary account for a tiny software development company called Macaraja (see previous link).


Regarding Paytunia and Bitcoin-Central : Paytunia is a brand of a French company called Paymium that also operates Instawallet, I'm the CTO of Paymium. If you happen to be in Paris you're welcome to visit us in our office (metro Porte de Saint-Cloud) !

Bitcoin-Central, on the other hand, legally is a service operated by Tivoli HK Ltd. which is a company incorporated in the Hong-Kong jurisdiction.

Legally, what the Bitcoin-Central service is, is the simplest it could be :

• It buys a digital commodity called Bitcoin from individuals or corporations by crediting a client account, and performing actual payments upon request,
• It sells a digital commodity called Bitcoin from individuals or corporations who have pre-paid a certain amount of fiat currency,
• It does both of the previous things at the same time, which functionally makes it similar to a FOREX, but legally similar to an import/export business

Please bear with me while I go back in time and give some context :

When I started BC I accepted deposits on my personal bank account, this quickly proved to be suboptimal, my account balance pretty much exploded. I didn't want to put myself at risk of being rape-caged and fined, and I didn't want my users to be at risk of losing funds.

So the next thing I thought was : "hey, there's lots of potential, let's incorporate properly". Problems started when the actual implemtation details had to be figured out. The first tough question was : "what is Bitcoin ?", because the answer to that is the prerequisite : to proper accounting, proper tax-payment, and ultimately avoidance of the dreaded rape-cage.

Options were :

• Bitcoin is currency. That would have made things easy, opening a money-changing business is comparatively easy to the other options,
• Bitcoin is a commodity. Less easy, that would have meant incorporating as a proper commodity marketplace, which is really hard if you don't have the proper resources,
• Finally, the conservative and safe option was to treat Bitcoin as a generic virtual good/service. Awesome, that's easy to incorporate for, the blocking point was the Value Added Tax that is due for sales to individuals.

VAT is the keyword, its one of the primary sources of income for the French government, so let me tell you that they take it *seriously*. What would the implications of VAT have been for someone who buys stuff from individuals and immediately sells it to others. It's pretty simple, it's 19.6%.

Practically, that would have meant that users could sell coins for X, and BC would have had to resell the same coins immediately for (X * 1.196). Users would have had to pay an extra 20% in taxes to the French government to buy coins at Bitcoin-Central. Did not happen obviously.

So we're coming to the Hong-Kong thing.

Hong-Kong's legislation has a very interesting property, it has 0% VAT if you do business outside of Hong-Kong: perfect fit!

That basically meant to me that I could incorporate a company in HK that would buy and sell a digital generic good/service free of taxes, without making risky assumptions regarding its legal nature. Opening a bank account in SEPA zone for a Hong-Kong corporation was a headache but ultimately succeeded (the hard part was always explaining Bitcoin ).

This setup enables BC to do the following thing :

• Buy Bitcoins,
• Sell Bitcoins with 0% VAT without making risky legal assumptions,
• Provide users with the convenience of a SEPA zone account

The main point here is : it's the most legally conservative, and safe setup I think is possible in Europe. Having less users, pay more to intermediates for a more complicated setup, and take the hard path is OK to me if that's what it takes to do business securely. My peace of mind has no price

We think being open to users and curious people is a good thing, so if you have further questions, don't hesitate to ask here, or visit us for a cup of coffee

[EhVedadoOAnonimato]

Thank you davout for your lengthy explanation. Congratulations for everything you've built.

I still have two questions though:

• Is your SEPA-enabled bank account in Hong Kong jurisdiction, or outside it? If it's in another jurisdiction, doesn't the simple fact of having a bank account there make you vulnerable to this jurisdiction's laws?
• Does the French government care about where your data actually is? I mean, I know governments that don't give a damn about where your servers are, if you live in their jurisdiction and you're doing some "Internet business" they don't approve, they will get you.

[davout]

Is your SEPA-enabled bank account in Hong Kong jurisdiction, or outside it? If it's in another jurisdiction, doesn't the simple fact of having a bank account there make you vulnerable to this jurisdiction's laws?

The bank is the Rietumu bank, it's located in Latvia. To be honest I don't think that a zero-risk setup exists, if someone tells you something is  zero-risk you should pay even closer attention. If Japan starts frowning upon Bitcoin mtgox is dead. The main risk is if countries start to coordinate and hunt down Bitcoin exchanges one after one, in this case I don't think we'd be the first to fall.

Also, if everything goes well and our efforts at Paymium are successful, we won't need it anymore because we'll be able to do business quietly and securely in a well-regulated framework.

Does the French government care about where your data actually is? I mean, I know governments that don't give a damn about where your servers are, if you live in their jurisdiction and you're doing some "Internet business" they don't approve, they will get you.

Not every country is the United-States

I take responsibility for my actions, I setup everything in what, I and the people I consulted, believe is a legal way.
If knowing that, the government still wants to go after me, I can't do much to stop them I guess, except for arguing that we've been honest, open and working jointly with the regulation authorities in order to come to a reasonable regulation framework.

[eliale]

Hello,

Are you going to register your site with:

http://bitcoincharts.com/markets/

?

It is quite convenient for arbitrage

Thank you

[davout]

Are you going to register your site with:

http://bitcoincharts.com/markets/

Yes, there will be an API update ASAP in order to support it.

[btctree]

Yes, but you should also know that bcrypt use more complicated algorithm to slow down the speed of calculation, this can be used as a vulnerable of DDOS attack.

You could impose a delay after a failed attempt. And also impose a delay for re-login after a logout.

Yes, a failed login times verification is needed.
thank you

[btcx]

Don't reinvent the wheel, use bcrypt, it was designed specifically for that use case, it is designed to be slow which is a good thing for a password hash function.

You don't want to rely on a specific hasher as your only means of security.  Realistically, it prevents brute forcing but dictionary attacks are still possible (which is where you should really focus on).  bcrypt does make it slow for the normal person to crack but there are still big unknowns in it and the more "secure" scrypt.

bcrypt has two known problems: it's not as slow as originally thought if you threw enough money at it (FPGA, ASIC) and there is a problem with the implementation that gives it something like at least a 4% chance of collisions.  They have not been studied enough, hence it is somewhat like security through obscurity (it took them many years of use before they found out that the standard implementation of bcrypt that just about everyone uses was flawed and would take many more years to completely phase out the bad implementation).

And as was already mentioned, if it's not used with proper safeguards, DoS attacks are possible.

[davout]

You don't want to rely on a specific hasher as your only means of security.  Realistically, it prevents brute forcing but dictionary attacks are still possible (which is where you should really focus on).  bcrypt does make it slow for the normal person to crack but there are still big unknowns in it and the more "secure" scrypt.

bcrypt has two known problems: it's not as slow as originally thought if you threw enough money at it (FPGA, ASIC) and there is a problem with the implementation that gives it something like at least a 4% chance of collisions.  They have not been studied enough, hence it is somewhat like security through obscurity (it took them many years of use before they found out that the standard implementation of bcrypt that just about everyone uses was flawed and would take many more years to completely phase out the bad implementation).

And as was already mentioned, if it's not used with proper safeguards, DoS attacks are possible.

Interesting, prompted me to read this which really sums everything nicely up.

[btcx]

Interesting, prompted me to read this which really sums everything nicely up.

The first answer is a good summary but the designer's criticism of DES based encryption should also be viewed with the same type of criticism for bcrypt/scrypt.  DES and other NIST type encryptions are heavily studied and analyzed, resulting in the breakthroughs in finding the vulnerabilities that the designers claim as a failure of DES/SHA.  If the same amount of resources were put into bcrypt/scrypt analysis, it's likely that breakthroughs specific to those crypt methods would be found as well.  If you don't think it to be the case, the recent finding that the reference implementation of bcrypt that is used in almost all programs is flawed after 10 years of use should serve as a warning: http://news.ycombinator.com/item?id=2654586.  The creation of scrypt after 10 years is also a testament to bcrypt's lack of analysis; scrypt is an attempt to slow down the hashing even further due to the rise of technology that was available 10 years ago for those with big budgets.  In a sense, it is security through obscurity (very little research compared to the "defective" algorithms).  I don't think there has ever been any real proof that what's being done with bcrypt doesn't weaken the crypto and people are just taking the designer's word on it.  What is undeniable is bcrypt/scrypt are generally slower than SHA on easily accessible hardware.

The thing to get out of it is also in that answer under the "What NIST recommends" section:

While I recommend bcrypt, I still follow NIST in that if you implement PBKDF2 and use it properly (with a "high" iteration count), then it is quite probable that password storage is no longer the worst of your security issues.

So even though in theory scrypt is possibly better, PBKDF2 is safer and is sufficient (the principle of high iterations hashing behind bcrypt/scrypt is the same as PBKDF2).  The general recommendation is to use well established crypto instead of creating your own.  I'd put bcrypt/scrypt on that sort of level because there hasn't been enough crypto experts checking to see if what's being done with the secure blowfish encryption doesn't weaken the cryptography after many iterations.  In some cases, combining or using the same secure crypto will weaken it.  In other cases, doing it multiple times will make it more secure (3DES).

I'd avoid bcrypt altogether unless you have a fixed implementation, but that would mean you're now non-standard.  If you're going to compile your own code instead of using standard, unpatched code, I'd use scrypt instead.

Once something is "secure enough," you should focus on the next weak link.  If you're going to use secure password storage crypto, it's not going to be of much help if you allow users to use weak passwords like "password", which happens to be in the top 3 cracked passwords on several social networking sites.

[davout]

Hello,

Are you going to register your site with:

http://bitcoincharts.com/markets/

?

It is quite convenient for arbitrage

Thank you

As promised, we're now back on bitcoincharts.com