 Show Posts
|
|
Pages: [1] 2 »
|
It's now confirmed already bro. Congrats Thanks for this! You mind if I ask how you're doing it? The txes you're claiming credit for here are all mined by different pools (mine was slush, the next few you claimed were 58coin, viabtc, antpool, bitfury, btc.top and viabtc again) - that's not consistent with using an accelerator. So if you are responsible you must have some other means. Granted the viabtc and antpool could be due to their accelerators, but I'm not aware that the others have that facility. (not complaining, just curious) |
|
|
|
4ece5ecfa7e77a6eeb745492c263ca0c111a04c9906de2d85a21707a588f760b Pretty please?  |
|
|
|
I've been finding on the bitfinex platform today that orders wont cancel when i've clicked the cancel button, takes constant clicking of cancel and about 15 mins for it to work.
ditto. |
|
|
|
I just make a withdrawal 5 hours ago and yet the status shown as pending approval even though I receive an email Withdrawal has been approved. What does this pending review status really mean?
From what I understand, "Pending Review" means there was a soft error during your withdrawal and it needs a manual check to proceed. Some time ago I was told (by Raphael I think, not sure now tbh) that you should open a ticket for these. (i.e. email support@bitfinex.com) |
|
|
|
Yes, another annoying stresstest done to proof that we need bigger blocks to protect against blockchain spam. They do this since yesterday. For referenceI've been watching this tx for a while, and I'm inclined to think now that the delay isn't a result of the spam (the fee here is 0.0009). Actually, for a short while after this was broadcast, blocktrail was claiming this was an orphaned chain - and given that bitfinex appear to spend their outputs before they're confirmed, I wonder did they do an unintentional double spend? There's a lot of money involved here anyway, so I'm confident there'll be a happy ending. (my withdrawal is only a very small part of this) |
|
|
|
Looks like a bunch of bitfinex customers are stuck with a 0-confirmation withdrawal for the last 10(?) hours or so: https://www.blocktrail.com/BTC/tx/2e9ceda8a520f4d0deca82158cfb389848575f505e6f5e9b2011c152918de146~1736 BTC in this transaction and others hanging from it. Looks like it currently has 2 unconfirmed inputs, so the delay is likely further back the line. Anyone know enough blockchain-fu to understand what's going on here? (I'm one of the people affected by this - my wallet is showing this tx as 'conflicted') |
|
|
|
withdraw 18 BTC to my wallet pending > 30 minutes  How long time to process it? Last time, it still 1 minute Usually it's included in the next block. You got it already, don't you? Their hot wallet might be empty. I have waited over 1 hour already...  LTC withdrawals have been taking 4-6 hours for the last 2 days (where they were previously instant). It *could* be a hot wallet issue I guess, but I doubt they'd leave the hot wallet empty for so long. |
|
|
|
|
Hi xspdr.
Your path for the websocket is wrong (that's what a 404 means). It should be 'wss://ws.bitfinex.com:3333/websocket'.
You will almost certainly need to go through the js on the site to see how to connection works, this is very unlike okcoin, and there are several steps involved in getting this working. I'd suggest actually that you wait for the "official" websocket api to be release (along with documentation) - it can't be very far away now.
Note: what I've said above still stands as far as I know - the orderbook this gives is still incomplete. This is why no one uses it.
Please don't PM me your questions again.
thanks
Edit: and then he goes off and deletes his post so that my reply is pointless. Thanks for that dude.
|
|
|
|
An update from a Finex employee would be appreciated. Thanks
+1 Several folk getting very concerned about the strange behaviour on the books over the last few days. Some speed bumps with the alphapoint integration are to be expected of course, but a public acknowledgement of same would be expected too. |
|
|
|
Have you found out a trades channel? I tried trade, trades, trade.btcusd and trades.btcusd to no avail.
Yeah, it's working, tried it just now: > ["websocket_rails.subscribe", {"data":{"channel": "trade.btcusd" }}]
< text: [["websocket_rails.channel_token",{"id":null,"channel":"trade.btcusd","user_id":null,"data":{"token":"fa1222b8-0e2f-4e8b-bcbb-165ea6d40d35"},"success":null,"result":null,"token":null,"server_token":null}]]
< text: [["websocket_rails.subscribe",{"id":null,"channel":null,"user_id":null,"data":null,"success":true,"result":null,"token":null,"server_token":null}]]
< text: [["trade.new",{"id":null,"channel":"trade.btcusd","user_id":null,"data":{"pair":"BTCUSD","price":"235.4","amount":"4.81834136","side":1,"timestamp":"1429709841.026109114"},"success":null,"result":null,"token":"fa1222b8-0e2f-4e8b-bcbb-165ea6d40d35","server_token":"MsoF3fiWaVg1YKThhtQ48g"}]]
< text: [["trade.new",{"id":null,"channel":"trade.btcusd","user_id":null,"data":{"pair":"BTCUSD","price":"235.4","amount":"0.18165864","side":1,"timestamp":"1429709841.114709611"},"success":null,"result":null,"token":"fa1222b8-0e2f-4e8b-bcbb-165ea6d40d35","server_token":"MsoF3fiWaVg1YKThhtQ48g"}]]
|
|
|
|
ah cool it worked thanks! I had spied on the pongs of the bitfinex.com client and didn't see the connectionId being passed, weird.
Very welcome If you can get a reliable book out of it please let me know how you do it! Been messing around with it again over the last 24 hrs, and it is soooooo tantalizingly close! |
|
|
|
I wasn't getting disconnected, but the socket went silent (after maybe a minute?) if I didn't reply to pings - maybe that's what's happening to you? The implementation is actually very straightforward - take a look at the application-*.js file on the bitfinex site to see how they do it.
(never did a websocket client myself in node, so I can't help you on that front I'm afraid)
I thought it was that at first, but I keep getting the behavior you describe, even when I pong back. Are you authenticated? No, I'm not authenticated. Maybe you're not sending back the connection_id in your pong? (I had posted a bunch of code here, but I think there's no point, you're almost certainly missing the connection_id) This is what the pong should look like: ["websocket_rails.pong", {"data":{"connection_id": "%s" }}]where the %s is your connection_id (you'll get that in your first 'client_connected' message you get back) Did anyone gets a message on the depth.pair channel?
Yes (read the thread!)  |
|
|
|
bricky, I get disconnected like after 10 seconds when I connect from nodejs. Do you have the same problem?
I wasn't getting disconnected, but the socket went silent (after maybe a minute?) if I didn't reply to pings - maybe that's what's happening to you? The implementation is actually very straightforward - take a look at the application-*.js file on the bitfinex site to see how they do it. (never did a websocket client myself in node, so I can't help you on that front I'm afraid) Also how did you discover the channels that are available (like depth) ?
By looking through the client on the website (it uses the websocket for tickers and order tracking for example), some googling, and plain guesswork |
|
|
|
Yup, it's still working (just checked depth.ltcbtc), but the order book it gives is still wrong. Edit: to clarify I first take a snapshot of the order book via the regular api, then modify it as changes come through the websocket. Most of the websocket events are correct - but it seems to be missing either the order change or cancel events, so over time an error builds up. As it is it's unusable. (although it's completely possible that I'm just doing something stupid and it's fully functional!) |
|
|
|
so they changed their site to use websocket -a guy here claims its using ajax polling
It uses ajax for the order book, but it uses websockets for the ticker and for tracking your own open orders (those pnotify messages for example are in response to websocket events). I subscribed to the depth.pair channels also (with much hope!), but the orderbook it gives is incorrect. It does appear to be related to the real order book, but I think (at a guess) it might be missing order replace and order cancel events. (Curiously though, I think it might be leaking some hidden order data) Anyway, I live in hope for the new api they're promising |
|
|
|
Has anyone successfully used the (undocumented) websockets api for, well, anything? Would really appreciate some pointers from anyone who uses it. (I posted a thread here about it last week, but I guess this thread is more likely to get noticed) |
|
|
|
Been messing around with the bitfinex streaming api on ws.bitfinex.com:3333 with a view to getting a realtime order book. The server is obviously websocket-rails, and the bitfinex website itself provides a fairly complete client (in its application-XXX.js file). When I subscribe to "ticker", I get "ticker.new" messages like this: {"pair":"BTCUSD","buying":"270.15","selling":"270.36","last":"270.38","daily_change":"-9.82"}These are great of course, but not sufficient to build up an order book. There's also a "trade.btcusd" (and presumably other pairs) which gives: {"pair":"BTCUSD","price":"270.97","amount":"0.27","side":0,"timestamp":"1425505661.56676188"}for every trade (presumably). I've tried all kinds of variations of order, book, orderbook, books (with various pairs added to the end), but I can't find what to subscribe to for a realtime order book. (of course I'm only guessing that such a thing is there) |
|
|
|
Finally, some non-FRR discussion. I am glad you are excited about this. I am too! I am working on the simulation environment exactly for that reason. It will give users the ability to test, and try strategies. I believe access will be limited to users who request it and are approved, but I think most people here are exactly the sort of users we want to encourage to test it out.
The API will remain the same, at least the current version (I think we will have a new version of the REST API at some point) and there will be other ways to access the backend. We are going to have the FIX gateway, and the websockets API.
The API will not be affected, because we have a "bridge" that will ensure that the backend can understand the current messages. Of course, all of this requires very rigorous testing. We are moving forward incrementally, and trying to stress test each piece, and run as many "corner cases" to try to catch as many bugs as possible before setting up the simulated environment.
So, basically, although the backend will be completely new, the frontend and the API should continue to function exactly as before. Thanks so much for your comments, I wish more people had responded to that part of my post...
Great! When there's a procedure in place for requesting access - let us know. And thanks once again |
|
|
|
|
