a) as already pointed out, 1 satoshi transactions are banned
b) trust issues (how can a "contract" enforce that both parties keep their word)
c) bloating of bitcoin blockchain (if microtransactions are used for share movement)
I have been also having thoughts about this and presented my idea yesterday with a similar approach but creating instead a "share-coin" where 1 satoshi transactions are allowed (each one representing a share) and an in-build automatic escrow.
https://bitcointalksearch.org/topic/possible-quick-and-simple-solution-for-a-decentralized-exchange-308841
I have given this a quick thought and come to what I can foresee as a fast solution to this. I have taken ideas from several people in the group and simplified them as much as possible and added some thoughts of my own. I’m sure there will be several flows as I have many things going on and I haven’t dedicated more than a few hours to this.
Ok, so I will explain the idea: basically a “Sharecoin” is to be created, which will be 100% pre-mined and one share will correspond to the lowest divisible amount of the coin (“share-satoshi” if you will). A wallet will be created in BTC fashion and have a balance of X shares in it, public/private keys, etc, plus a field indicating the number of shares which are "locked" (unconfirmed sale) or "pending" (unconfirmed purchase).
A share transaction shall be completed in 3 steps:
1- Share seller and buyer agree a price (initially in BTC, but other altcoins could be supported in the future) with each other using whichever means they prefer.
2- The share seller sends a Sharecoin “payment request” transaction with an embedded message indicating:
a. Number of shares to be sold
b. Price in BTC per share
c. BTC address where payment is to be sent
d. Sharecoin address of buyer
e. Timeout of the transaction
This transaction is to be signed with the private key of the seller in order to prove the origin.
3- After the transaction is confirmed (one confirmation should do) the shares are “locked” so that they can’t be sold twice (any request transaction involving locked shares is to be rejected immediately) and added as "pending" to the buyer's wallet. The buyer takes note of its code and sends the payment to the indicated BTC address and posts a "payment confirmation" Sharecoin transaction (signed with his/her private key) indicating:
a. BTC transaction code
b. Sharecoin transaction code of the original request
Now all the network has to do is to check that the payment has really been made and confirmed (maybe it can even be confirmed by Sharecoin nodes prioritizing that particular BTC transaction to give some speed, although I’m not sure if this is possible) and immediately the shares of the transaction shall be confirmed by the Sharecoin network. The shares assigned to the buyer’s wallet will no longer be "pending" and the locked shares will be removed from the seller's wallet.
After the defined timeout no "payment confirmation" transaction shall be accepted by the network. If after this defined timeout no payment has been received, the seller must send an “unlock request” transaction to be able to sell the shares to someone else. After confirmation of this transaction, the shares can be put on sale again.
This approach solves trust issues and removes the need for any middlemen, as the Sharecoin protocol would implicitly function as an escrow. It also avoids bloating the BTC blockchain with additional micro-transactions used to send messages. It does however require a certain linkage between the BTC and Sharecoin networks, and the way it is devised Sharecoin miners would not receive any rewards for confirming transactions or generating blocks. A possible variation to solve this last point would be to allow subdividing the shares (for example, leaving 1/1000th of a share for the miner confirming the transaction)
I'll be glad to receive your comments/criticism
P.S. I have no experience in Bitcoin-related development and my knowledge of the intricacies of the protocol isn't at pro-level either so I do realize I might have made some dumb assumptions.
In any case, I hope that if we join our efforts we can come to a working solution