The super chain is definitely the way to go it just needs to:
1) hold a private key to accounts in both bitcoin and each secondary coin (not sure how this would work, keys must be.secret.from everyone)
2) keep a database of all bids and asks for each coin with the moneys escrowed in its account
3) distribute coins from its accounts when bids and asks cross
4) only initiate sends and distributions once txns have enough confirmations to be effectively.irreversible (a reorg of the database is okay, a reorg of txns that.have been executed destroys the.system)
I've been struggling with these same questions myself, but didn't want to get into the meat of it until it was time. There are definitely some challenges that need to be overcome, but I think a P2P Exchange system is an interesting problem that can be solved and potentially expanded to include real-world currencies and commodities (topics for later discussion).
1) Keys... I don't think they would be needed. At first I did, but then as my thoughts developed into the process I describe below, I don't think so...
2) database... this is easy. It would be built right into the blockchain... as traders trade, the ask/bid spread is automatically updated and you have your prices automatically transmitted to every client in the network.
3) My original thought, was to accept inputs from any given coin at a given value, then distribute the pot to the recipients in their desired currency. However, this process got very complicated very quickly, requiring all kinds of keys to be tossed around in the open. I think I came up with a workable solution... read on if you dare.
4) Agreed. This was a major stumbling block as I think about how to make the whole P2P process work. Your questions triggered some more thoughts in my screwed up mind, and I think I actually managed to figure out a solution to the whole problem.
Now, I'm not sure if what I describe here is purely a business process (which is how I'm describing it), or if it would require mathematical proof, but I'm leaning towards the former...
First, some values: BTC/NMC @ 0.005; BTC/MBX @ 0.125 (1BTC = 200NMC = 8MBX)
Second, assume a transaction value of 0.3%, divided by 3 for each type of coin.
Bob advertises NMC for sale, Alice sees that advertisement and issues a buy against it for 200NMC. Both clients exchange the necessary information to construct the transactions as follows:
Bob sends an MBX transaction
* 8 MBX deposit
* 0.008 MBX tx fee
* properly signed transaction to send 200 NMC to Alice (including tx fees)
Alice sends a similar transaction with deposit, fees, and BTC payload
The MBX network, seeing a valid exchange transaction, would broadcast the NMC and BTC transactions to their respective networks.
Once a mutually agreed upon confirmation period expires, MBX would then process the deposits, refunding each or awarding both to one party or the other if one of the 3rd party transactions failed.
There is one specific challenge I'm not ready to think about yet, and that's determining if a transaction has been rejected or is still waiting to get into a block.