BitFloor.com Rocks!

[rjk]

Prices at 1$ and 2000$ are nowhere near relevant for current market activity. What do you glean from knowing that someone wants 0.01 BTC at 1$?. In some cases (equity exchanges, etc) trading wil leven halt if the price of the market moves too dramatically over a given timeframe.

Some heuristic bots might be very interested in that data.

[1714180612]

1714180612

[1714180612]

1714180612

[1714180612]

1714180612

[shtylman]

Prices at 1$ and 2000$ are nowhere near relevant for current market activity. What do you glean from knowing that someone wants 0.01 BTC at 1$?. In some cases (equity exchanges, etc) trading wil leven halt if the price of the market moves too dramatically over a given timeframe.

Some heuristic bots might be very interested in that data.

Sure, or they may not be

It can be obtained via the websocket API. As I mentioned earlier, I will look at adding the full order book via REST, but it will have certain query requirements since polling it would be a waste of resources for everyone (even the bots). I don't disagree that this information should be available (and I will say again that it is ALREADY available via the websocket API, just not via the REST API).

[TheButterZone]

Any idea why limit sell orders are approximating the fee to -0.4%? Don't limit orders get the +0.1% rebate because they are providers?

Coulda sworn the first limit sell order I entered approximated the +0.1% rebate... not anymore.

[notme]

Any idea why limit sell orders are approximating the fee to -0.4%? Don't limit orders get the +0.1% rebate because they are providers?

Coulda sworn the first limit sell order I entered approximated the +0.1% rebate... not anymore.

Limit orders only get rebates if they don't match an existing order.

[TheButterZone]

Any idea why limit sell orders are approximating the fee to -0.4%? Don't limit orders get the +0.1% rebate because they are providers?

Coulda sworn the first limit sell order I entered approximated the +0.1% rebate... not anymore.

Limit orders only get rebates if they don't match an existing order.

If there were an existing order matched, wouldn't the limit sell have filled immediately? When I entered the second one, it didn't fill. So the approximation is now being made as if there were an existing order, when there isn't. (The first limit order with the +0.1% approximated didn't fill immediately either, so I cancelled it to add more BTC.)

[shtylman]

Any idea why limit sell orders are approximating the fee to -0.4%? Don't limit orders get the +0.1% rebate because they are providers?

Coulda sworn the first limit sell order I entered approximated the +0.1% rebate... not anymore.

The approximation is made for a worst case scenario (as it notes your actual fees may differ). The taker fee (0.4%) is used in the approximation since you must have that amount to enter the trade (it will be put on hold). Only after your trades go in and execute is the 0.1% rebate decided and given to you. It is possible for your order to have some part of it execute right away and another part remain on the book. These two parts will receive different fee treatments. All of this is only known after execution.

[TheButterZone]

It just seems like something must have changed in the code, for the approximation to use -0.4% now, and +0.1% earlier. So earlier it was set to best-case scenario, and now it's worst-case, it seems.

[shtylman]

It just seems like something must have changed in the code, for the approximation to use -0.4% now, and +0.1% earlier. So earlier it was set to best-case scenario, and now it's worst-case, it seems.

The limit orders calculator was not approximating fees at all before. It now calculates the amount including fees which you will need available in order to place the order. It does not indicate final fees and is an approximation.

[TheButterZone]

Weird. I thought the first time, I multiplied BTC to the furthest decimal place by unit price and got a slightly lower result on my calculator than the site showed. Oh well.

[davecoin]

What is the usual turnaround time for emails to support@bitfloor.com for ACH withdraw verification?

-Dave

[shtylman]

What is the usual turnaround time for emails to support@bitfloor.com for ACH withdraw verification?

-Dave

Usually a day. No ACH is processed on weekends so new ACH accounts are setup toward the end of the weekend in preparation for the new week.

[ErebusBat]

What is the usual turnaround time for emails to support@bitfloor.com for ACH withdraw verification?

-Dave

Mine was less than 24 hours, around 12 IIRC.

[davecoin]

Very easy to use and excellent support from shtylman.

Thanks,
Davecoin

[jwzguy]

Have you all looked into Dwolla deposits as an option?

They used to take Dwolla, I'm guessing they quit for very good reasons...like the fact that Dwolla is run by thieves and liars.

I'm very glad they don't, I have no worries that they'll be at risk of insolvency from Dwolla fraud.

[ErebusBat]

Have you all looked into Dwolla deposits as an option?

They used to take Dwolla, I'm guessing they quit for very good reasons...like the fact that Dwolla is run by thieves and liars.

I'm very glad they don't, I have no worries that they'll be at risk of insolvency from Dwolla fraud.

It is also my understanding that dwolla doesn't like btc and will shut you down / freeze your funds. GOX had to get a special contract

[genuise]

I am surprized that your api do not provide full orderbook, especially that this was not explicitly stated anywhere

From the docs:
"The L2 book shows the top 50 levels for each side. Each side is a list of the levels with bids being sorted from highest price to lowest and asks from lowest to highest. This makes the first element of the bid and ask side equivalent to the L1 book bid and ask."

I will look at expanding the REST order book levels. If you want a more detailed picture, use the websocket API for the streaming data.

Prices at 1$ and 2000$ are nowhere near relevant for current market activity. What do you glean from knowing that someone wants 0.01 BTC at 1$?. In some cases (equity exchanges, etc) trading wil leven halt if the price of the market moves too dramatically over a given timeframe.

I will look at expending the levels as I previously mentioned, but it will continue to be the inside book for some N levels. A full book may be available via REST in the future with some limited query requirements to make it clear that it should not be continuously polled. Users who want up to date info are strongly encouraged to use the streaming API and maintain their order book state. All of the above are advanced uses which target only a small faction of our user base.

Hi! sorry for my remark. I should first search before asking

I have read socket.io api docs carefully now as I am interested in implementing the book thru your api. And I even made some modifications to your example to analyze and prepare myself.
And I have a technical question if you don't mind. If you think this is not proper place for it please suggest where we can continue.

As I can understand from your api to build a book I first need to get full book and then listen for all events and modify the book state accordingly.
In general I have no problem with it except one thing.

As long as initial full book you provide in the form array of price/volume tuples and all next events arrive with order_id which can be used to find and select and filter orders to follow thier further state and alter or not the state of my local book.
What I stuck with is that initially I do not know ids of orders which are already in the book and thus I cannot understand how those already existing orders can be identified in subsiquent order events to be able to update local book correctly.

Can you please advice?

From what I can see it I would suggest to extend initial book response with order_id of each order currently in the book. this whould greatly simplify the task of keeping local book state.

thank you in advance

[epetroel]

I'm thinking this would work similar to the Gox order book and socket.io API where the order id's aren't provided either.

You don't actually need to know the order id's, you just need to know the total volume at each price point.  So you keep a map where the key is the price and the value is the volume at that price.  Then you just update the values in the map at each price point as depth updates come in.

[genuise]

My concerns are about this:
in api docs we read

Order New (order_new)
Order New is emitted when the matching engine receives a new valid order. The order has not yet been executed against or put on the order book. It is simply an acknowledgement that the matching engine has accepted the order.

This event will be emitted for ALL new orders received by the matching engine. Unless you are interested in potential order flow you can generally ignore this message since it does not indicate a change in market state.

which basically mean that not all orders will make it into orderbook.

next we read that

Order Done (order_done)
Order Done is emitted when the order will no longer be executed against. The order was either filled or canceled.

This event will be emitted for ALL orders. If the order was on the order book, you will need to update your order book accordingly.

And if right after I got initial book response there comes order_done event then I cannot tell for sure whether this done order was previously on orderbook or not, and thus cannot correctly decide whether to subtract the volume from local book or not.

What am I missing here?

[shtylman]

My concerns are about this:
in api docs we read

Order New (order_new)
Order New is emitted when the matching engine receives a new valid order. The order has not yet been executed against or put on the order book. It is simply an acknowledgement that the matching engine has accepted the order.

This event will be emitted for ALL new orders received by the matching engine. Unless you are interested in potential order flow you can generally ignore this message since it does not indicate a change in market state.

which basically mean that not all orders will make it into orderbook.

next we read that

Order Done (order_done)
Order Done is emitted when the order will no longer be executed against. The order was either filled or canceled.

This event will be emitted for ALL orders. If the order was on the order book, you will need to update your order book accordingly.

And if right after I got initial book response there comes order_done event then I cannot tell for sure whether this done order was previously on orderbook or not, and thus cannot correctly decide whether to subtract the volume from local book or not.

What am I missing here?

It will be implied from the side of the order. Lets say you get an order done even for a buy order at a price above the highest bid you know about. This means that this buy could not have existed on your order book and you don't need to remove it. Like wise if a sell order done comes in for a price below the lowest ask, you know it was for an order which removed liquidity and does not require an order book update. Does that make sense? If you would like more clarification or examples please feel free to email support@bitfloor.com and I will be more than happy to go into more details. I will note that the websocket API is used on both our website and the clarkmoody site without issues so all of the relevant data to track the feed is there

[peasant]

Just finished the final option i didn't test previously which was the ACH withdrawl. Worked smoothly. Now
BitFloor really does rock.