The code seemed rather trivial and I may have lost track of what @dirvine had been asking for, so I'll just assume it wasn't meant to display anything extraordinary.
Now, I've been reading your posts regarding the use of multi-signature addresses for trade execution, and am still trying to wrap my head around the logistics of that process.
So, let me just outline how I envision it based on the assumptions I've had to make to fill the gaps, and please bear with me here as I'm a very technical person and prefer specifics over abstracts. (Devil is always in the details)
In our typical scenario, user A has BTC and wants to buy ETH, and user B has ETH and wants to sell them for BTC.
1. At some point in time, user A submits an order expressing his intent to buy 100 ETH @ 0.1 BTC/ETH price
2. At another point in time, user B submits an order expressing her intent to sell 50 ETH @ 0.1 BTC/ETH price
3. A match is detected by the validator V (although the match is partial)
(here I have to start making assumptions based on what you've described before)
4. V creates two 2-of-2 multisig addresses: V&A (BTC) and V&B (ETH).
5. V requests A to send 5 BTC to V&A
6. V requests B to send 50 ETH to V&B
7. V is awaiting the payments
8. A broadcasts a transaction on the Bitcoin blockchain and sends 5 BTC to V&A from its private Bitcoin address
9. B broadcasts a transaction on the Ethereum blockchain and sends 50 ETH to V&B from their private Ethereum address
10. Now they all wait, especially since Bitcoin is involved, - could be several minutes to an hour or longer
11. V monitors both V&A and V&B until both payments have been received.
12. V validates the amounts received
13. V requests A to sign and return a 2-of-2 transaction for sending the previously deposited 5 BTC from V&A to B
14. V requests B to sign and return a 2-of-2 transaction for sending the previously deposited 50 ETH from V&B to A
15. Once both transactions have been signed and returned, V parses and validates them to ensure conformance with the original order and amounts/rate etc.
16. V signs both V&A and V&B transactions using its own escrow key (unique for each trade)
17. V broadcasts the V&A transaction, effectively sending 5 BTC to B
18. V broadcasts the V&B transaction, effectively sending 50 ETH to A
19. V destroys the private keys/addresses related to the completed trade
20. V modifies the original order submitted by A to reflect the partial fulfillment, - to 50 ETH target
21. V marks the original order submitted by B as 100% fulfilled, and removes it from the queue
So, assuming this is roughly what takes place, there are a couple areas of concern that I'd appreciate your comments on:
1. What happens if the validator loses connection or crashes between steps 17 and 18?
I mean, we don't have anything like MSDTC for distributed transactions or two-phase commits here, so how do you envision handling such conditions? For example, would a newly created instance of the validator detect this abnormal termination and complete the process?
2. Given the need for the 2-of-2 escrow addresses, the flow of funds in each direction during a trade would supposedly double the amount of transaction fees incurred. (e.g. A=>V&A=>B)
Has this been taken into account? There have been remarks that the 0.2% exchange fee applied on top of the transaction fees may be too excessive and could completely negate any benefits provided by a decentralized exchange.
This issue becomes especially noticeable when multiple transactions are required to fill a single order (which is almost always the case, except when a buy and sell orders produce an absolute 100% match).
3. The whitepaper does not mention multi-sig in the context of online trading, but it does so for the potential implementation of offline trading. And where it does mention that, it also says that the use of multi-sig makes the exchange non-decentralized since the escrow/validator effectively holds the funds for some time.
Now, if multi-sig will need to be used for online trading in order to prevent double-spend, that would make online trading non-decentralized as well. - Is that a correct assumption?
I have provided this step-by-step outline of what the process might look like, so that all of us technical folks on this forum would be able to reference those steps for sharing opinions and ideas, and come to a pretty clear understanding of what a viable solution might look like.
Please do bear in mind that despite my almost 30 years in software development I have never coded anything for blockchains in particular, and the above is purely my attempt at putting together the puzzle of all the scattered piecemeal information I've read and heard so far on this thread and what I could infer from it.
I strongly believe that this particular area of the implementation will be the absolute defining factor in the success or failure of this project, therefore I think the discussion should focus on this area as it has remained extremely vague thus far.
Hopefully, focusing on the technical aspects will let us address all the concerns and help all the potential investors move forward with their contributions.