[ANN] KRAKEN.COM - Exchange with USD EUR GBP JPY CAD BTC LTC XRP NMC XDG STR ETH

[becoin]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

[1714003906]

1714003906

[1714003906]

1714003906

[1714003906]

1714003906

[Dargo]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

[becoin]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

[Dargo]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.

[becoin]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.

So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right?

[Dargo]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.

So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right?

I haven't changed anything but have assumed from the start that the bid @590 is put on the book after the other orders (should have made that clear).

[becoin]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.

So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right?

I haven't changed anything but have assumed from the start that the bid @590 is put on the book after the other orders (should have made that clear).

Didn't you say the following:

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590.

There is a very simple solution to this 'bug'.

Out-of-the-market limit orders:
- ask initiated below highest bid
- bid initiated above lowest ask

Every out-of-the-market limit order should be transformed into market order as soon as it is initiated! This is also safety measure against so called 'fat finger' mistakes.

[Dargo]

Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.

A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?

You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.

To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:

sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @590
buy 1 BTC @529

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.

This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.

I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?

In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 - my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.

On the contrary, it does mean ask @545 is skipped. The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?

Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.

So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right?

I haven't changed anything but have assumed from the start that the bid @590 is put on the book after the other orders (should have made that clear).

Didn't you say the following:

If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590.

I mean something different by "initiates the trade" from what you take me to mean. In the example we have been discussing, if the sell side initiates the trade, then the ask @530 gets the most favorable match, which is to match with the 590 buy order @590. If on the other hand the buy side initiates the trade, then the bid @590 gets the most favorable match, which is to match with the 530 sell order @530.

There is a very simple solution to this 'bug'.

Out-of-the-market limit orders:
- ask initiated below highest bid
- bid initiated above lowest ask

Every out-of-the-market limit order should be transformed into market order as soon as it is initiated! This is also safety measure against so called 'fat finger' mistakes.

Well you are right that a bid placed on the book above the lowest ask is expected to behave similar in some ways to a market order. But you can't just transform it into a market order because a market order will continue to fill against whatever orders are on the book no matter the price, whereas a limit order can't fill beyond a certain price. And transforming the limit order into a market order wouldn't protect against fat finger trades. In fact, in some cases it might make things worse. Suppose we have the following orders on the book:

sell 1 BTC @550
sell 1 BTC @531
sell 1 BTC @530

buy 1 BTC @529

Then we place a buy order for 3 BTC @532. What should happen is that this order should get partially filled at 530 and 531 with the remainder of the order staying on the book as a 1 BTC buy @532. But if it just gets transformed into a market order, then it will get filled in part by the 1 BTC order @550 and that's clearly not what you want.

Again, this bug may have been completely fixed a long time ago and the current bug may be something else entirely - just brought it up to show how you could have a bug where a trade could happen @590 even though an ask @545 didn't get skipped.

[Atdhe]

Thanks for the explanation (finally): http://blog.kraken.com/post/148976188862/kraken-phishing-warning

[aesma]

Wow, it's really a fuck up of Google and co to allow such ads !

[Timeline]

Wow, it's really a fuck up of Google and co to allow such ads !

Yes it's really odd that such criminal fake website ads can be displeyed. I falled victim of it. I managed to change password before any damage was done and luckily didn't lose anything.

[LouisVuitton]

Thank you Kraken for providing a reliable trading experience. You guys have definetly improved in the past few months.

[luxuryvilla]

Do you have more plans to add new strong altcoin? 

[birr]

Do you have more plans to add new strong altcoin? 

I sent in a request many months ago to add the coin of which you speak.
Perhaps the good people at Kraken will take another look.

[ExpertNeeded]

Does Kraken (and other exchanges) perform any type of blockchain analysis on the coins that are being traded on its site?
In order to find out if the source of the coins are from darknet sites such as silkroad?  or from reported hacks where bitcoins have been stolen?
Regards

[birr]

Does Kraken (and other exchanges) perform any type of blockchain analysis on the coins that are being traded on its site?
In order to find out if the source of the coins are from darknet sites such as silkroad?  or from reported hacks where bitcoins have been stolen?
Regards

Coinbase tracks coins that you withdraw from your account.  They will close your account if they find out you sent the withdrawn coins to a gambling site.
I don't know if any other exchanges do things like that.

[MusX]

Just came to say thanks to the kraken exchange for adding ETC currency to the market, and preventing the attack made by ETHFoundation against Ethereum project and its community which stands for decentralized and immutable blockchain based currency. ETH currency before the fork was perfectly fine, only DAO had an issue. ETHF simply failed to resolve reported DAO security issue on time, and continues their mistakes later on. We are having enough of TBTF (too big to fail) already. For those which are not up to date with the ETH-ETC story I recommend to read "hard fork timeline" on https://ethereumclassic.github.io/
I'm not saying new ETH is bad, but it is against the principles that are foundation for true cryptocurrencies. I still see a lot of potential in ETH, generally for institution that requires central authority over currency so TBTF can eventually be applied when needed.

[MatTheCat]

Thank you Kraken for providing a reliable trading experience. You guys have definetly improved in the past few months.

Thankyou Kraken for emptying my account, and then telling me to go sing and whistle.

After this incident, I realised how corrupt and outside the law that Bitcoin exchanges operate, and came oh so close to getting everything out my main Bitcoin trading account on Bitfinex..............

[TheLAWNoob]

My bank account disappeared so I can't withdraw.

Tried to add it again and says duplicate withdraw info.

Help?

Edit: I re added the info with a different name and it let me withdraw, but do I have to wait for Kraken to re-confirm my bank account? I need the money pretty soon.

[io8621]

Ethereum deposit is still closed?? Any news about deposit?