What is the usual turnaround time for emails to [email protected] for ACH withdraw verification?
-Dave
Topic: BitFloor.com Rocks! - page 2. (Read 17612 times)
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
Coulda sworn the first limit sell order I entered approximated the +0.1% rebate... not anymore.
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).
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. 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.
Would it be possible to provide full order book via api? Currently it looks like this:
http://btccharts.com/#m=bitfloor-BTC-USD
http://btccharts.com/#m=bitfloor-BTC-USD
I will look at expanding the number of returned levels (currently 50 on each side). It is doubtful that the full book will ever be provided since information about trades at prices of 1$ or 2000$ and such is not relevant to current market conditions. The goal of the REST API book is to provide information about the current relevant conditions.
If you want the entire stream as the data comes in, you can use the websocket API which has no restrictions but is more complex to use.
Hey, I also can agree that this info is relevant for calculateing composite orderbook volume and for comparison with other axchanges orderbooks volumes.
We use it on our bitcoin-analytics.com service to calculate different bid/ask prices depending on BTC volume 10,100,1000, 10000, 100000.
I am surprized that your api do not provide full orderbook, especially that this was not explicitly stated anywhere
Is it possible to provide full orderbook mode?
Would it be possible to provide full order book via api? Currently it looks like this:
http://btccharts.com/#m=bitfloor-BTC-USD
http://btccharts.com/#m=bitfloor-BTC-USD
I will look at expanding the number of returned levels (currently 50 on each side). It is doubtful that the full book will ever be provided since information about trades at prices of 1$ or 2000$ and such is not relevant to current market conditions. The goal of the REST API book is to provide information about the current relevant conditions.
If you want the entire stream as the data comes in, you can use the websocket API which has no restrictions but is more complex to use.
Umm how exactly is this not relevant as it provides information on the overall liquidity of the exchange.
Would it be possible to provide full order book via api? Currently it looks like this:
http://btccharts.com/#m=bitfloor-BTC-USD
http://btccharts.com/#m=bitfloor-BTC-USD
I will look at expanding the number of returned levels (currently 50 on each side). It is doubtful that the full book will ever be provided since information about trades at prices of 1$ or 2000$ and such is not relevant to current market conditions. The goal of the REST API book is to provide information about the current relevant conditions.
If you want the entire stream as the data comes in, you can use the websocket API which has no restrictions but is more complex to use.
I use Clark Moody's display of their orderbook: http://bitcoin.clarkmoody.com/bitfloor/
It would be nice if the orderbook on the website had a bit more depth. 20-30 spaces instead of 10 would be great.
Would it be possible to provide full order book via api? Currently it looks like this:
http://btccharts.com/#m=bitfloor-BTC-USD
http://btccharts.com/#m=bitfloor-BTC-USD
My understanding is that there are two APIs already, one with the full order book and one with the narrow order book. I think btccharts.com is just using the wrong one.
-bgc
Would it be possible to provide full order book via api? Currently it looks like this:
http://btccharts.com/#m=bitfloor-BTC-USD
http://btccharts.com/#m=bitfloor-BTC-USD
Speaking of ID... Can someone from Bitfloor say something about what information they need the ID for, what they do with that information, and how they store that information? Thanks
In the event of an ACH dispute or other transaction issue with the receiving bank, we need to know who owns the account where the funds are going. It is important that the ID and name on file match what your bank expects.
We do not store your ID on our servers. It is kept in offline storage as a record if needed. We certainly don't give this information out to any third party and only use it to make sure your transactions go smoothly. The entire point of us handling the ACH process ourselves is to make it quick and also avoid exposing your data to third parties.
Speaking of ID... Can someone from Bitfloor say something about what information they need the ID for, what they do with that information, and how they store that information? Thanks
Jump to: