|
This was a UI/websocket display bug. At no point was the matching engine actually in a crossed state.
|
|
|
|
And their site still says 1%. When did this fee go up? And why hasn't bitfloor changed their notice?
BitFloor does not charge any fees for cash deposits. All fees are charged by LocalTill, which is a third party processor. There are no hidden fees. I will update the notice for clarity. Thank you for the feedback. |
|
|
|
If an account holder (or a group) were to pursue this debt through the court system they would probably get a judgement and gain access to BitFloor's funds -- and if you have funds (USD or bitcoins) in a Bitfloor account, those are Bitfloor's funds as far as what a judgement against Bitfloor would have access to.
Please stop spreading misinformation about the debt responsibilities and client holdings of BitFloor as it relates to the US legal system. I am not a lawyer, however .... There is no question that my account shows that my balance of bitcoins today shows "hold" and that I am being refused access to my coins. This makes BitFloor in default of its obligation to me. From another thread: BF is pretty much bailing itself out by taking a forced 0% interest loan on people who have coins "on hold" there.
So... They're holding funds hostage AND reopening for business WHILE being technically bankrupt? I don't know what can be intelligently said about that. Except that it can't possibly be legal anywhere. When a company becomes insolvent or enters the zone of insolvency, things change -- directors and officers become fiduciaries of the corporate assets for the benefit of creditors. Each time a person withdraws funds from BitFloor, that is a disbursement to its creditors. That ability to obtain funds is not offered to all creditors equally because today I am still being denied access to my funds that have been on my account since before the September breach. I don't know in the State of NY, but in some areas that would be considered preferential transfer that could even be clawed back (up to two years worth of any payments to creditors): - http://www.thebankruptcysite.org/resources/bankruptcy/filing-bankruptcy/the-clawback-provision-preferential-transfers.htmNow, if several creditors who together have a big enough claim go petition to have a judge approve a wind down or get a judge to freeze BitFloor's bank funds (to halt further preferential disbursement) then it isn't shtylman who decides who gets access to their USDs and their bitcoins. BitFloor could file today for bankruptcy protection so this doesn't happen, but the same thing -- anyone with USD or BTC funds held with BitFloor would not be able to withdraw them as bankruptcy law then determines who gets paid what and when. I would only suggest that you stop confusing bitcoins and USD. The two are not the same thing. |
|
|
|
If an account holder (or a group) were to pursue this debt through the court system they would probably get a judgement and gain access to BitFloor's funds -- and if you have funds (USD or bitcoins) in a Bitfloor account, those are Bitfloor's funds as far as what a judgement against Bitfloor would have access to.
Please stop spreading misinformation about the debt responsibilities and client holdings of BitFloor as it relates to the US legal system. |
|
|
|
I think we should make an opensource trade lib as a reference implementation.
I just wanted to ask one question to all people here thinking about the exchange API standarization: Why don't use an existing standard like eg. FIX protocol? http://en.wikipedia.org/wiki/Financial_Information_eXchangeTheoretically it alrady has everything that's required. So what are the roadblocks? Are they technical or ideological? Maybe a software architecture mismatch? Is FIX simply too difficult? Or is FIX considered tainted for some reason? Thanks in advance for any light you may shine on this question. BitFloor has had a FIX gateway for months. I would link you to our docs but the server is offline because the data center lost power -> hosted in NYC  and the storm has done a serious number of the power situation. Should be back online soon. |
|
|
|
|
The server is back online. However, due to the continued power problems in the NYC area connectivity may be intermittent at times.
|
|
|
|
|
Due to the recent hurricane in the Northeastern part of the US, our hosting facility has lost power. They are working to resolve the situation and restart their backup generators however as of this moment do not have updates on when servers will be back online.
~Roman
|
|
|
|
Roman,
Please tell us why Chase deposits into Bitfloor are not available this morning. Makes me wonder if your account was frozen by Chase.
It was not frozen but they are closing it (details of which are private). I will be moving to a new cash deposit system which will also include more banks; however the transition will take a few weeks. The new system will continue to allow for free deposits. Apologies for any inconvenience this may cause to anyone using the Chase deposits. |
|
|
|
Any reasonable way for you to prove these claims? Or someway for users to verify these claims themselves (this would be even better) ..."In reopening, a number of improvements to both the wallet storage and website have been made. Bitfloor aims to be safe and reliable platform and as a result have changed our fund storage policy to 100% offline storage for your funds. Daily transactions through out hot wallet will be backed by Bitfloor funds, never putting client funds at risk."... ..."Bitfloor is now running on dedicated servers in a PCI compliant data center based in the US. Bitfloor services are further isolated based on exposure. Testnet and development are not located in the same data center or hosting provider to ensure further isolation. Backups are encrypted and write only on all of the servers. Hot wallet files are encrypted even further and unavailable even with physical access to the disk."... Please? New security continues to be unverified... There are no reasonable ways for many of your questions to be verified. The production and testnet separation can be confirmed through a traceroute on the respective domains. I welcome suggestions for reasonable ways in which you believe your requests can be confirmed without compromising user identities, trading activity, or balances. |
|
|
|
Sounds good. The recent down times have been getting me worried.
Understandable given what has happened in the past. However, I do want to stress that the issues have all been separate incidents and in no way related to any sort of compromise or attack on the servers. As mentioned in the previous post (and per the sentiment expressed by my users), serious server downtime will always be mentioned on our blog as well as our twitter account (@bitfloor) as soon as possible. |
|
|
|
|
Apologies for the site downtime today. It was cased by a crash on the web and API server. I have brought all services back up and posted about the outage on the bitfloor blog. In the future, serious downtime issues will always be mentioned on the blog.
|
|
|
|
|
I apologize for the downtime. It was the result of a minor issue with the website. The API, trading, withdrawal, deposit, and other services were not affected.
|
|
|
|
So what's the point of the secret-key then?
Sounds like you guys just discovered that you should have been storing the secret-key as a salted hash instead of cleartext. But instead of simply fixing that, you bolted on a whole new secondary password system that makes the original one redundant.
This does not instill confidence.
The secret key is used to check your message signature and as such we must use it to calculate the signature and check it for validity. The signature ensures that your message was not tampered with by a MITM. If you would like any clarification about the relevance of the fields please contact support@bitfloor.com and I will be happy to go over the details. It will help me in understanding how the documentation can be clarified. |
|
|
|
This is precisely the difference. By having a passphrase which is selected by the user, having access to the api key and secret key (database dump or otherwise), will not allow the attacker to create phony API requests. The API still generates a strong secret key for signatures which is not user selected.
Doesn't this also mean that if we want, users can require typing in the passphrase whenever starting up our custom apps? That way the "keys to the kingdom" are not simply laying around on my computer's hard drive. Correct. How you choose to handle passphrase storage and usage is completely up to you. If your programs operate in such a way that you can enter the passphrase only during startup then you will further prevent tampering or use of your trading programs without your authorization. |
|
|
|
The only difference I can see is that the passphrase is chosen by the user rather than being randomly generated by bitfloor.
This is precisely the difference. By having a passphrase which is selected by the user, having access to the api key and secret key (database dump or otherwise), will not allow the attacker to create phony API requests. The API still generates a strong secret key for signatures which is not user selected. Previously (and with many current exchange APIs), if an attacker is able to get a list of api keys and secrets, and the exchange does not detect or react quickly enough, then the attacker can simply use the keys to make API calls as if they were you (no intercepting or other complex action required on the server by the attacker). Using a passphrase which is stored using a one way salted hash ensures that even with key access the attacker will not be able to make requests without knowing your user selected passphrase. The use of a passphrase sets up a shared responsibility to secure secrets between the client and the server without all of the required data being stored by our server to make the API request. |
|
|
|
Shtylman, Any thoughts on creating a secondary market where "on hold" BTC can be bought/sold? I'd be willing to purchase some "on hold" BTC from those who might be in a hurry to cash out if I could get them at an exchange rate that is slightly more favorable than the current rate for BTC that are not "on hold". If you could create a way for these BTC to be identified and traded, then you would allow those customers of yours who have fears or are in urgent need to cash out to transfer the BTC to those who are just hoarding and have no immediate need. This would significantly improve customer satisfaction. I'd even guess that buyers of "on hold" BTC would be willing to pay a transaction fee to the exchange in the form of "on hold" BTC (which would remove those BTC from the pool of BTC that the exchange would need to repay). (perhaps I should send this question in an email to ensure Shtylman sees it). That is an excellent suggestion. Various forms of debt are sold, with varying risks as to whether or not that debt will be repaid. It has value. Wanted to say that I appreciate the suggestion and have taken it under consideration as a way to handle the stolen fund balances. I think that if done correctly it can be a viable way to shift the burden. |
|
|
|
I noticed at 9:00 EST this morning that bitfloor could no longer be logged in to -- there was simply a message saying it was down for maintenance. An hour or two later I noticed my browser timed out when I attempted to load the homepage. This is still happening. I would like an update from Shtylman as to what is going on with the site. Makes me wonder if this is the new permanent state of bitfloor. Hope not.
I am migrating the bitfloor servers. As the migration to new servers takes effect you will see the website again. This should take no more than 24 hours before you can access the site again. |
|
|
|
|
So is the hotel the final venue decision? Are there conference funds to cover it?
|
|
|
|
|
Show Posts
