I wouldn't do that if I were you. The problem is that just because somebody else did a Purchase Offer already does not mean he will end up getting it. The position of your transaction in the block could still be above the one send earlier.
It doesn't necessarily have to be a hide, it can be a highlight/color change etc - just something to let the user know that there is already an accept visible on the blockchain for this sell and thus their accept is likely to be invalidated.
You're correct in that there is nothing stopping the user (protocol wise) from sending their own accept and hoping it gets included earlier in the block than the accept already visible.
That's essentially the crux of the scalability problem - an exchange where the lowest ask sell can only be bought once every (on average) 10 minutes just doesn't scale. To avoid everyone trying to accept the same sell we need a way to consider that lowest sell 'pending acceptance' (or 'Purchase Offered') and have users look to the next lowest sell intra-block to make it scalable in my opinion.
A color indication would be a great idea. I personally would still try to get the cheapest option since I have just as much chance of getting it then the person who already submitted an offer. All I wanted to convey is that the first message seen by a certain node has no increased chance of being the first one in the block. I would prefer the cheapest option, even if I need to fight for it. But by coloring it you at least give people an option to decide what is important for them.
You know I may have been operating on a bad assumption re the above; being as an unconfirmed transaction propagated throughout the network it would be added to the bottom of the (currently being mined) block template, thus transactions broadcast earlier would have a better chance of being first in the block. It sounds like you're saying this is not the case? (Is there some kind of block reorganization etc?) As I mentioned early on I'm quite new on this cryptocurrency 'scene' and have just been teaching myself by reading as much bitcoin literature (wikis, papers, forum posts etc) as I can get my hands on - so I'm certainly more than happy to be corrected if my interpretation is wrong!
An interesting dynamic will come out of this, where MSC buyers will have to decide whether they want to go for the best price (and maybe/probably not get it) or pay a bit more for an offer in order to have a better chance of being first to accept.
When we do the distributed eschange messages between MSC and other MSC-derived currencies like smart property and GoldCoins, the buyer doesn't have to specify which seller they are buying from - we can just match up buy/sell offers which happen to match automatically. Currently the spec doesn't state this very well (I need to fix that).
Unfortunately, the scalability problem will always remain when exchanging MSC/BTC. Once someone has purchased MSC and is completely in the MSC ecosystem, everything gets way easier.
Thanks for the additional info
I'm just going to throw out an idea I've been playing with to see what you guys think (feel free to tear it apart if it's not a good idea!). What about an additional
optional message. An 'acknowledge' if you will. MSC/BTC exchange could function as per the discussion so far but have additional support for the user that created the sell to broadcast a message to 'acknowledge' a specific accept/Purchase Offer before it's confirmed in a block. So:
Wallet broadcasts sell offer > Wallet sees a valid accept/Purchase offer in the block template > Wallet broadcasts an 'acknowledge' including the ID of the accept/Purchase offer it's agreeing to > Trade is considered locked in & waiting to be funded > Other parties see no point trying to accept this sell now and move on to the next
All of that can happen intra-block, as long as the user (specifically their wallet) participating in trading stays online.
Of course a wallet can also simply post a sell, go offline and have it bought by the first accept/Purchase in a block as per the current spec if there is no 'acknowledge' already sent by the seller.
I am concerned that perhaps doing anything at all with unconfirmed messages at a fundamental level regardless of how we structure it is a bad idea because we can't be 100% sure those unconfirmed transactions will be included in the next block. Appreciate your thoughts
