I provided the answers to your question in my original post in bold.

I see - I missed them since they were embedded inside the quoted text. Thanks alot!

In response to to this question:

    Is it possible to create a market order to buy or sell assets? For your average consumer who just wants to move wealth in and out (akin to normal forex transfers), a limit order would mean waiting around for it to fill or paying above market price?


A market order is just buying at lowest ask or selling at the highest bid. You can obviously do that now...

A market order isn't a straightforward BUY or SELL at the lowest ASK or BID price though. A market order steps up the price paid, or drops down the price offered until either the requested number of assets has been obtained or expended. E.g. Sell 1000 BTSX for BITUSD - at whatever price you can get, and keep selling until all the BTSX have been sold.

Buying at either the lowest ask, or selling to the highest bid would be a limit order. E.g. Sell whatever I can into this BID or ASK, and then just leave the rest on the order book if the full amount was not sold or purchased.

So, the question still stands; does the ability to liqudate or fill a position at any price automatically exist, or does the system only support limit orders?

In BTSX exchange you always "get what you ask for" in the exchange... ie: if you are willing to pay X per Y then you will pay X for all Y even if some Y are available for less than X.   This prevents front running and encourages traders to trade on value rather than technicals.   If you want a "market order" that will have to be done slowly via multi-step process.

Ok, that makes sense. What about the other questions? I find it slightly hard to believe:

Basically BitShares has no limits lol

however well thought-out and implemented Bitshares may be.

It generally makes it easier to convince people of the merits of a system if you can also indicate its short-comings. Bitcoin has plenty of shortcomings, but it does have the benefit of the network effect.

I'd appreciate if anyone can provide any more detailed answers to the questions I've asked.

Thanks once again.

Cluttering of the directory is definitely an issue though, we already have hundreds if not thousands of scam accounts with nearly identical names, all seemingly designed to profit from accidental transfers. Some kind of pruning of account names over time would definitely be welcome.

Perhaps leveraging the existing voting technology? and/or proof of stake? Anything with less than X BTSX shares or a negative vote would be filtered by default. Infact, voting for accounts retaining a minimum BTSX balance would make the most sense since it would demand that for a vote to be cast and valid, a voter must hold a certain number of BTSX. This would hopefully limit spammers from down-voting accounts they don't like - since it would tie up BTSX (cost money) to do it.

Alternatively, could explore some kind of PKI certificate - so - for example - COMCAST or COINBASE could register themselves using their normal X59 certificates used for securing https traffic, and you'd filter the list based on those with valid certificates.

This and "REGEX validation for MEMO field" would be awesome

Thank you very much for your detailed reply. This is exactly what I was looking for.

With regards to your answer in point 4:

BitShares X has Bitcoin-style addresses included in the wallet, and you can use them to transfer. Under the hood I think it works a lot like Bitcoin. The idea here is that for most purposes, account names are better as they are easier to type and remember. In any case, exchanges, developers etc. will have to experiment and customize solutions for given applications.

I've read some of the documentation and I can see that the account name and public key abstract the transaction layer, allowing for 'behind-the-scenes' generation of unique key-pairs for each transaction. I realize that this is to address the perceived flaw in address reuse that is prevalent in Bitcoin, but I'm still not clear as to whether generating a "per-account, per-customer" mechanism is an acceptable solution over the existing "single-account, memo-per-customer" method employed by bter.

For example; if I deposit Bitcoins to Bitstamp.net, I do so to a unique Bitcoin address that has been generated for me. This eliminates (almost) any chance of the Bitcoins that I send not being credited to my account.

In a comparable scenario with BitsharesX and bter.com - the reconciliation of funds to a customer account is done using the memo field. This means that if a customer mis-types the value, or forgets to enter it (and they will), the funds - while credited to bter.com - will not be credited to the customers account. This will generate significant support overhead as originating funds that do not contain the reference must then be manually reconciled.

So, firstly, is there a way to enforce a memo value - possibly allowing the provider to apply a regular expression pattern embedded into their public account (like website field now) that allows them to reject transactions that don't contain a recognized memo pattern. Or; would it be better for me - as a marketplace/exchange etc - to generate an account for each of my customers that register and give them the account name and public key to deposit their funds. This way, eliminating then need for any memo value?

If you have any use-cases for illustrating how BitsharesX would work in the context of a marketplace/exchange deposit and in the context of a BitPay/Coinbase merchant<->customer transaction - that'd be awesome.

One last slightly different question; I created two accounts within the client and when I tried to send funds from one account to the other, I was required to enter both the account name (E.g. "willabie") and the public key. The client refused to send the funds unless both values were present. I was under the possibly erroneous impression that the account name was a 'friendly' way of deriving the public key and as such, either that or the public key should be sufficient to send the funds onwards? (I'm also aware it might just be an eccentricity of the client and that the RPC commands do support this functionality - some clarity would be great)

On a side note; I firmly believe that BitsharesX is a contender for the future of crypto-currency, but how the user experience is presented will be key to gaining that adoption.