Bitcoin Forum
April 26, 2024, 03:16:45 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Limit orders: ask - possible to end up with more than your ask price?  (Read 684 times)
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
December 13, 2012, 10:34:21 AM
 #1

Hi guys,

So, if I place a limit sell order on one of the exchanges, is it possible that I get a higher price than what I asked for?

I'm thinking the answer is no, because if I were buying instead of selling, the exchange tries to find me the cheapest price, doesn't it? So visa versa I shouldn't be able to get more than my ask. Yet, this definition suggests otherwise:

http://www.sec.gov/answers/limit.htm

What's the truth of it?

Cheers, Paul.
The forum was founded in 2009 by Satoshi and Sirius. It replaced a SourceForge forum.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
December 13, 2012, 10:53:43 AM
 #2

Yet, this definition suggests otherwise:

Not sure what saw in there, but that only says that you won't pay more than you bid or sell for less than you asked.

Each exchange has differing order matching methods and some have fees, liquidity rebates and other things that make them not all equal.

But Mt. Gox, for example, will use standard best price matching. 

So if the order book has the following Asks:

 Qty 10 @ 13.60
 Qty 10 @ 13.61

Any you put a bid for 15 @ 13.65,
then Mt. Gox will buy you 10 BTC at $13.60 and then 5 BTC at $13.61.


If you are selling the the inverse occurs.  For the Bids:

 Qty 10 @ 13.50
 Qty 10 @ 13.49

And you sell 15 AT $13.45, 
then Mt. Gox will sell 10 BTC at $13.50 and then 5 BTC a $13.49.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
December 13, 2012, 01:00:37 PM
 #3

Yet, this definition suggests otherwise:

Not sure what saw in there, but that only says that you won't pay more than you bid or sell for less than you asked.

Each exchange has differing order matching methods and some have fees, liquidity rebates and other things that make them not all equal.

But Mt. Gox, for example, will use standard best price matching. 

So if the order book has the following Asks:

 Qty 10 @ 13.60
 Qty 10 @ 13.61

Any you put a bid for 15 @ 13.65,
then Mt. Gox will buy you 10 BTC at $13.60 and then 5 BTC at $13.61.


If you are selling the the inverse occurs.  For the Bids:

 Qty 10 @ 13.50
 Qty 10 @ 13.49

And you sell 15 AT $13.45, 
then Mt. Gox will sell 10 BTC at $13.50 and then 5 BTC a $13.49.

That confuses me as its not symmetric - the system has favoured me (first as buyer and then as seller) in both situations.

Shouldn't the system always be trying to get the best price for the buyer? In your second example, the buyers are the two bid orders:

 Qty 10 @ 13.50
 Qty 10 @ 13.49

Since I have put in an ask of:

15 AT $13.45

Shouldn't it try to get the best price for the two bidders, and sell at my ask price, just as it did in your first example when I was the bidder?

Sorry if this seems obvious, I'm new to the whole thing!

Cheers, Paul.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
December 14, 2012, 03:31:50 AM
 #4

Shouldn't the system always be trying to get the best price for the buyer?

Nope.  The benefit goes to the party that is placing the new order.

If the newest buy order is for a price higher than was needed, that buy order gets filled at a lower price (advantage to the buyer).

If the newest sell order is for a price lower than was needed even, that sell order gets traded at the higher price (advantage to the seller).




Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
December 14, 2012, 08:48:23 AM
 #5

Shouldn't the system always be trying to get the best price for the buyer?

Nope.  The benefit goes to the party that is placing the new order.

If the newest buy order is for a price higher than was needed, that buy order gets filled at a lower price (advantage to the buyer).

If the newest sell order is for a price lower than was needed even, that sell order gets traded at the higher price (advantage to the seller).

Ahhh, I see. What a strange system! Ok, thanks for clearing that up! Smiley

edit: so that means its advantageous to constantly 'be' the new order, maybe by entering and cancelling bids if they're not immediately filled?

Cheers, Paul.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
December 14, 2012, 09:42:30 AM
 #6

edit: so that means its advantageous to constantly 'be' the new order, maybe by entering and cancelling bids if they're not immediately filled?

Well, there are various order types for various markets. 

So far for bitcoin exchanges, there are two types of orders, market orders or limit orders.

Other financial markets such as stock markets and others have "kill or fill" (FOK) orders, and "immediate or cancel" (IOC) orders.

You might be interested in what immediate or cancel (IOC) provides.

 - http://en.wikipedia.org/wiki/Immediate_or_cancel

There aren't any bitcoin exchanges that offer this (yet).

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!