Author

Topic: [ANN] KRAKEN.COM - Exchange with USD EUR GBP JPY CAD BTC LTC XRP NMC XDG STR ETH - page 297. (Read 628889 times)

full member
Activity: 149
Merit: 100
Over the last few days, the story about the latest update of my WP8 Kraken app spread like a wildfire on twitter and the internet in general Smiley A lot of websites wrote a story about it, here are a couple of important sites:

Tweakers.net (largest Dutch/Belgian tech website, around 600.000 registered users): http://tweakers.net/nieuws/93916/microsoft-laat-eerste-bitcoin-app-toe-op-windows-phone-platform.html
WMPowerUser (second largest Windows Phone community website): http://wmpoweruser.com/kraken-is-the-first-bitcoin-trading-app-for-windows-phone/
Frontpage of /r/bitcoin: http://www.reddit.com/r/Bitcoin/comments/1w4v3x/microsoft_allows_bitcoin_trading_app_on_windows/

A lot of niche sites wrote about it as well. To name a few: CoinCourant, CoinReporter, TechieNews, BitcoinExaminer, etc.

I've seen a massive increase in downloads over the last few days. Keep in mind that Kraken is growing with ~2000 users per day (December 2013), and doubling their use base every month (source). The Windows Phone 8 platform is also seeing a consistent growth every month, it outsells iPhone in 24 countries (source). In a lot of European countries, Windows Phone is the second largest OS. This coincides with Kraken's userbase which consists of 75% EU customers, 10% US customers and 15% customers from other countries (see angel.co source). Right now, Kraken is the #2 bitcoin exchange when it comes to XBT/EUR volume (source).
jr. member
Activity: 58
Merit: 10
Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!



No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

Smiley

It's not even close - first, the XBT/USD volumes are too low. Secondly, because withdrawing USD takes a long time and seems to be unreliable, there's a Gox-like premium for buying XBT with USD.

If Kraken were to use their bank to convert USD to EUR (the way bitstamp does, but in the other direction), they would benefit from increased trade volume from all the USD deposits.



Well, let's have a look, shall we?

01-29-14 01:33:04 +11:00
Last Updated: 6 seconds ago


USD$806.08009 = 1 XBT.

1 XBT = 588.06182 Euros


www.xe.com

USD$806.08009 = 589.191 Euros

That's interesting, it does look quite close.

Smiley



Are you looking at the correct buy/sell sides? Right now, buying 1 BTC will cost USD 829.99 (the XBT/USD buy/sell spread is 1.5%). This equals EUR 607.

Selling that 1 BTC will net just EUR 581.

This changes constantly, but clearly the difference is big - 26 EUR, which is 4.37% over the average. And that's not even counting commissions...
hero member
Activity: 532
Merit: 500
Are you like these guys?
Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!



No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

Smiley

It's not even close - first, the XBT/USD volumes are too low. Secondly, because withdrawing USD takes a long time and seems to be unreliable, there's a Gox-like premium for buying XBT with USD.

If Kraken were to use their bank to convert USD to EUR (the way bitstamp does, but in the other direction), they would benefit from increased trade volume from all the USD deposits.




Well, let's have a look, shall we?

01-29-14 01:33:04 +11:00
Last Updated: 6 seconds ago


USD$806.08009 = 1 XBT.

1 XBT = 588.06182 Euros


www.xe.com

USD$806.08009 = 589.191 Euros

That's interesting, it does look quite close.

Smiley

hero member
Activity: 910
Merit: 1000
Same-day deposits and same-day withdrawals.. Everything works great! I suspect most of the people who have problem this actually has to do with their bank. My initial deposit a few months ago took ~2 weeks (the teller at the bank looked at me funny when I told him to send it via SEPA). Since then, I have switched to another bank, more modern and with proper online banking. Now everything works smoothly.
newbie
Activity: 34
Merit: 0
no update about the order book bug yet?

We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.

There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:

sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110

So current ask is 130 and bid is 127.

A new order is placed to buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100.  Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).

So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.

In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed.  In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).  
I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.

This is how it works now, but not before. Before the timestamp on an order was just the time of order entry, and this timestamp carried over to orders that triggered from advanced orders. Now the timestamp is determined by the time the order is created, so an order that triggers from an advanced order is given a new timestamp. Apparently in the original design of the trade engine, triggered orders got a new timestamp, but at some point this was changed to the timestamp just being the time of order entry because that was simpler and it was thought that it wouldn't be a problem.

Suppose the orders in the example are placed in the following sequence:

sell 1 lot @ 130
sell 0.5 lot @ trailing stop 126, limit 100
buy 0.5 lot @ 120
buy 0.5 lot @ 127
buy 1 lot @ 110
sell 1 lot at 125

As you say, the newest order initiates, but before this meant that the buy order @ 120 would initiate because it was considered newest and this would result in a fill at 100. Apparently there was also an issue with sorting that sometimes caused the older order to initiate (resulting in a fill at 120), but this has been fixed as well.

With both of the fixes, the newest order always initiates and the age of an order is determined by when it is created (so an order that triggers from another gets a new timestamp). In the example, this means that the triggered sell @ 100 will always initiates and the fill will be at 120.

I'm not sure when we'll have the time to do this, but at some point we'd like to write up a document explaining all the rules of the trade engine so the technical details of how trade matching works exactly are available. Some exchanges have done this for basic order types, but I'm not sure any exchange has ever done it to include the advanced orders (but let me know if you know of one).    
Ok that explains a lot. Regarding documentation, i don't know of any bitcoin exchanges having advanced orders like kraken at all, are there any? Strangely enough i couldn't find the matching rules for advanced orders on any regular exchange either, although they must be publicized somewhere.

I do have a few questions about the matching if you can answer them yourself, if not i can wait for the document.
- How is the price protection calculated for market orders?
- Is order matching atomic? I.e. if a orders crosses the market, will it match orders as far as possible before anything else happens, or is it possible for incoming/triggered orders to be added as the order 'walks' the book.
- I understand that any triggered order will be handled as a new limit/market order with a fresh timestamp. So this means that if multiple orders are triggered by the same trade/order being executed, they will arrive with the stame timestamp right? How is execution priority handled in that case?
full member
Activity: 149
Merit: 100
Today Kraken was the #2 in EUR volume Cheesy https://bitcoinaverage.com/markets.htm#EUR

Volume is still way too low though.
jr. member
Activity: 58
Merit: 10
Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!



No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

Smiley

It's not even close - first, the XBT/USD volumes are too low. Secondly, because withdrawing USD takes a long time and seems to be unreliable, there's a Gox-like premium for buying XBT with USD.

If Kraken were to use their bank to convert USD to EUR (the way bitstamp does, but in the other direction), they would benefit from increased trade volume from all the USD deposits.
hero member
Activity: 532
Merit: 500
Are you like these guys?
Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!



No, it's not.

What is possible though is sell USD to XBT, then with the XBT buy EUR.

Check Bloomberg, Reuters, XE.com or another reputable site to get the latest fx rates and see if doing USD to XBT to EUR gives a commensurate exchange rate.

Good luck!

Smiley
jr. member
Activity: 58
Merit: 10
Hi, is it possible to convert a USD balance (resulting from an XBT/USD trade) into EUR at the prevailing exchange rate?

Thanks!
sr. member
Activity: 434
Merit: 250
would just like to post my appreciation of Kraken once more.
3 days since SEPA withdrawal (UK bank) and funds arrived this morning.

keep up the great work guys.

 Grin
hero member
Activity: 728
Merit: 500
A question in the category "quite non-urgent":

In the language settings there is an option for both "English (GB)" and "British English". What's the difference?
legendary
Activity: 1820
Merit: 1000
no update about the order book bug yet?

We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.

There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:

sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110

So current ask is 130 and bid is 127.

A new order is placed to buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100.  Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).

So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.

In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed.  In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).  
I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.

This is how it works now, but not before. Before the timestamp on an order was just the time of order entry, and this timestamp carried over to orders that triggered from advanced orders. Now the timestamp is determined by the time the order is created, so an order that triggers from an advanced order is given a new timestamp. Apparently in the original design of the trade engine, triggered orders got a new timestamp, but at some point this was changed to the timestamp just being the time of order entry because that was simpler and it was thought that it wouldn't be a problem.

Suppose the orders in the example are placed in the following sequence:

sell 1 lot @ 130
sell 0.5 lot @ trailing stop 126, limit 100
buy 0.5 lot @ 120
buy 0.5 lot @ 127
buy 1 lot @ 110
sell 1 lot at 125

As you say, the newest order initiates, but before this meant that the buy order @ 120 would initiate because it was considered newest and this would result in a fill at 100. Apparently there was also an issue with sorting that sometimes caused the older order to initiate (resulting in a fill at 120), but this has been fixed as well.

With both of the fixes, the newest order always initiates and the age of an order is determined by when it is created (so an order that triggers from another gets a new timestamp). In the example, this means that the triggered sell @ 100 will always initiates and the fill will be at 120.

I'm not sure when we'll have the time to do this, but at some point we'd like to write up a document explaining all the rules of the trade engine so the technical details of how trade matching works exactly are available. Some exchanges have done this for basic order types, but I'm not sure any exchange has ever done it to include the advanced orders (but let me know if you know of one).    
legendary
Activity: 2968
Merit: 1133
today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?

One of our team (and nobody else) is experiencing some issues as well. We think it might be a routing problem affecting some users. If anyone else is having issues, please report.
At the moment everything is fine again...
But how about the "No trades currently available." on the market data on "recent trades" after refreshing the page? Me and also others get this in about 25% of the time, not only now.  Now with this high traffic it seems like it's 50% off the time. Kind of frustrating.
legendary
Activity: 1820
Merit: 1000
today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?

One of our team (and nobody else) is experiencing some issues as well. We think it might be a routing problem affecting some users. If anyone else is having issues, please report.
legendary
Activity: 2968
Merit: 1133
today during this crash and also now kraken was/is slow =/
I often got/get the message "This data is not currently available. Please try again later." when I try to see my history. And submitting an order takes 5 seconds instead of 1 second.
or is it just me?
newbie
Activity: 21
Merit: 0
Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.
A USD/EURO deposit? Banks don't work in the weekend(I love bitcoin Cheesy ). Your payment should be processed somewhere today so maybe you get it today or tomorrow.

All good. I receive my euros. Thanks a lot kraken.
newbie
Activity: 34
Merit: 0
no update about the order book bug yet?

We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.

There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:

sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110

So current ask is 130 and bid is 127.

A new order is placed to buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100.  Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).

So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.

In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed.  In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).  
I don't really follow your explanation. How do you determine the side which initiates the trade? In this case the bid of 120 was there before the stop was triggered, so the sell order came last and is the initiating side right? I don't see how this ever could lead to a scenario where the trades executing at a price beyond the best bid/ask.
sr. member
Activity: 266
Merit: 250
Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.
A USD/EURO deposit? Banks don't work in the weekend(I love bitcoin Cheesy ). Your payment should be processed somewhere today so maybe you get it today or tomorrow.
newbie
Activity: 21
Merit: 0
Deposit made on saturday, waiting for the funds to be available. I guess the weekend does exist in this business. If kraken support is around I made a request : #18205.
legendary
Activity: 1820
Merit: 1000
no update about the order book bug yet?

We think we've fixed all the issues people were seeing, and all those fixes are now live. So please let us know if you see anything that still doesn't look right.

There were a variety of cases, but all of them were caused by a bid > ask condition. For example, suppose the book contains these orders:

sell 1 lot @ 130
buy 0.5 lot @ 127
buy 0.5 lot @ 120
sell 0.5 lot @ trailing stop 126, limit 100
buy 1 lot @ 110

So current ask is 130 and bid is 127.

A new order is placed to buy sell 1 lot at 125.  The order picks up the 0.5 lots @ 127 and then the rest of it goes on the book as 0.5 lot @ 125. Now the current ask is 125 and bid is 120.

The 120 bid triggers the trailing stop @ 126 and puts in a limit sell order at 100.  Now the bid is 120 and ask is 100 (bid > ask condition). If the ask side initiates the trade, the trade will be done at $120. If the bid side initiates the trade, the trade will be done at $100 (which appears to have skipped over the buy @ 110).

So those of you who thought you were being skipped over, you weren't. It's just that someone with a higher bid in the book got filled at a price below your offer. Of course, the converse could happen too, where someone on the ask side might appear to have been skipped over when in fact someone with a lower ask just got filled at a higher price.

In one sense, this isn't really a bug, because whichever side initiates is supposed to get the best offer on the book from their perspective. So if the buy side initiates, they should get the lowest ask on the book - i.e. $100 in the case above. It's just that when bid > ask, this normally sound principle leads to unexpected price action that doesn't look right. And we'd probably be answering support tickets and questions on social media forever if it wasn't fixed.  In the scenario above, the fix is that the trade will execute at $120 regardless of which side initiates the trade. That seemed the best solution, and will avoid the strange price action, but it also means that the side initiating the trade under this bid > ask condition isn't always going to get the best offer on the book (as they normally would when ask > bid).  
Jump to: