If the buyer and seller agree to multiple transactions for the same amount, your protocol may get confused.
Perhaps I haven't expressed the idea correctly. Such situations shouldn't happen. Could you elaborate why you think it is possible?
Your proposal states "If a match occurs between Richy and Mike then Richy has to send to Mike’s address the specified amount of BTC in the specified timout (1.5) otherwise he should lose the collateral pledged. When Richy’s transaction sending BTC to Mike is confirmed -> delegates should include the required information in the blockchain so other nodes can easily verify. And transfer required amount BTSX from Mike to Richy"
Suppose Mike has two orders each offering 14000 BTSX for 1 BTC. Suppose both orders are matched by Richy. Then Richy sends 1 BTC to Mike. If the logic is "if there exists a recent transaction which sends 1 BTC from Richy to Mike, then consider the order to be filled," this condition will trigger for
both orders and Richy will get 28000 BTSX even though only 1 BTC was sent.
If Mike’s transaction is canceled or timeout all the funds are not instantly released. Instead BTC transaction confirmation time should pass before the funds are released. This is to make sure Richy hasn’t already sent BTC and to allow Richy to act if his transaction is pending but not included in block by some reason.
My proposal [1] establishes a particular txid for every user-to-user transaction, thus there is no confusion if the same users transact for the same amount again and again.
So does mine. Have you seen both proposals?
I've read both, but AFAICT the network / delegates choose what txid to associate with a particular user-to-user transaction (and may get it wrong). In my proposal, the users agree on the txid of the user-to-user transaction (but network must still check that it sends the correct amount to the correct recipient).
Your proposal is not atomic. When the timeout expires, if the transaction has propagated across the Bitcoin network, but is too slow to confirm due to no fault of the buyer, the BTSX seller can end up with both the BTC and the BTSX. In my proposal, this cannot happen. I just added a section at the end adding detail to the mechanics of this part, which is a little harder than it needs to be due to an oddity in the BTC protocol.
You get what you ask for. However when the timeout expires the offer becomes invalid but the funds are not released until <BTC Confirmation> time has passed. In case of timeout you still need to wait 6+ BTC blocks incase the BTC buyer has send the funds.
The other day I had a small Bitcoin transaction take hours to verify. Waiting for <BTC Confirmation> time is past protects you against forks and double spends, but there is no guarantee an unconfirmed transaction will be confirmed within <BTC Confirmation> for
any value of <BTC Confirmation>. (The latest addition to) my proposal gets around this by allowing
Mike to use a "deadline transaction" sending Richy's BTC back to Richy if Richy doesn't deliver. If the deadline transaction is confirmed, the delivery transaction cannot be, so it's safe to give Mike his BTSX back since we can
prove the Bitcoin network will ultimately reject the delivery transaction no matter how long it takes to show up.