Quote from: BTCLuke on June 10, 2013, 05:56:05 AM

Guys, let's please not turn this thread into another "My system solves X,Y,Z" threads... The project forum is already overflowing with those... And then bluemeanie1 always jumps on to fight with fellowtraveller and we all abandon ship soon thereafter... So let's stay on topic for once!

In the OP Charles said:

Quote

I'm also open to ideas about how the project should be structured and the specific set of goals we should have.

One idea I have is to make a chart.

On the X axis we have the current 8 criteria. On the Y axis we have different systems like Ripple, BMOT, Metalair's, bytemaster's, mine, and all newcomers to get added too.

Then in the grid we simply pick winners by feature. Some kind of voting or even a donation-based feature election... With all donations going toward building the eventually-chosen software.

This would cause a problem when the best feature to fit criteria 6 doesn't work in the system with another best criteria 4, but we could get closer and raise funds this way, and at least pick the best one to fund by the highest number of features won in a single system.

Just my two bitcents.

At this point I am simply trying to understand the systems and establish criteria / break down the problem. Any references to BitShares or MarketCoin is merely to demonstrate a design criteria, motivations, and potential solutions. So, what I think we have gleamed from the discussion of MarketCoin is a need to define how fast 'instant' is.

1) It could be within 24 hours.
2) It could be within 5 minutes.
3) It could be less than 1 minute.

MarketCoin brings up a new dimension to the problem: requiring 'interactive' support for bids to clear. What I mean by this is that if you place a bid well below market, then leave for vacation and while you are gone the market drops and your bid gets accepted you are SOL and so is the counter-party. The 24 hour timeout would occur and both parties lost out on the transaction. This occurs because the trades depend upon private keys which requires interaction with on behalf of all parties for trades to execute. What I can conclude from this is that all bids on MarketCoin should require some kind of 'freshness' and thus should expire after 24 hours if they are not accepted. Assuming MarketCoin can automate integration with all other chains then the user experience will be seamless from the perspective of managing the transactions. The only problem is that the experience will be UNPREDICTABLE as some times trades will happen quickly, other times trades will fail and you have to start over the next day. When you start over the next day you are still subject to failure. Lastly, there is still an attack vector here by placing bids but not following through. One solution to this problem is to have one side of all bids be MarketCoin and thus controlled by the network. To place a 'bid' you give control over your money to the network which can then prevent fake bids and ensure that trades happen in a timely manner with only 'one' party having to be 'interactive'.

When I suggested earlier that trades be ATOMIC I meant it in the since of making multiple updates to a shared resource without any 'contention', ie they either all happen or none of them happen. A trade that 'starts' at 8 AM and doesn't close until 8 PM and might fail *depending upon the counter party* is not atomic. Two people that make identical trades at 8 AM will get very different results depending upon their counter-party. A potential solution to this is to reduce the window to 30 minutes and include a 'fee' assessed to the defaulting party and paid to the other party in the event the transaction fails. This would require all nodes to be online and active and provide predictable results.

Conclusion: MarketCoin with a few tweaks is a very suitable piece in the puzzel for decentralized exchanges and certainly some problems BitShares does not. In fact, MarketCoin might be a part of the solution of allowing people to trade any alt-coin for any BitShare or related fiat-coin and in a sense complement one another.

What we are left with is how to deal with Fiat and I believe BTC Luke's proposal is similar to BitShares in spirit if not in specific approach:

1) All parties must post collateral held in crypto-currency.
2) Parties issue fiat-bonds backed by crypto-currency that can be traded like BTC.

The only question becomes how do we value these fiat bonds, how do we manage the collateral, and how do we handle defaults.

Can we at least agree that 'escrow' and 'exchange' needs to be separated into two different jobs? We need a crypto-fiat that can be traded/exchanged by something like MarketCoin or BitShares and then we need a separate 'escrow' system for either backing the crypto-fiat (BTC Luke) or exchange crypto-fiat for fiat (BitShares).