Announcing Project Invictus: a P2P Exchange Collaboration

[bytemaster]

We have had this discussion in other places, but I think the problem needs to be divided into several distinct areas:

1) Escrow Services:    
    The purpose of these services is only to facilitate already agreed upon trades over a long distance as in-person trades in theory require no escrow.  Escrow exchanges are almost by-definition multi-day events due to the slowness of traditional banking.  
    
      * The challenge posed by escrow is that all banking transactions are 'reversible' and therefore simply confirming a wire transfer, bank transfer, credit card payment, paypal, or dweller transfer is not enough.        
      * The third party is in theory subject to various laws if they actually hold fiat to facilitate the trade.  This third party also risks being brought into any investigation the government may have regarding that transaction.
       * The most decentralized version is NashX, though NashX only works between two people who already own crypto-assets.

     I would submit that the P2P exchange system should not attempt to solve the escrow problem because 'traditional' escrow services that are entirely legal and 'not exchanges' nor 'money transmitters' could be used.   There are other approaches that could be taken as well.   1) Both parties could have certified identities with a signed arbitration agreement with Judge.me or something similar.  2) Both parties could post and maintain a surety deposit that is entirely independent of the 'escrow' transaction.   These approaches would probably be sufficient for anyone involved with a lot of trades but the 'setup time' would make the 'first transaction' the most difficult.    This approach is also not as 'anonymous', but then again if you are transferring money through the traditional banking system it isn't really anonymous anyway.   Lastly, do you really want to 'trade fiat' for 'bitcoins' with a random stranger via direct bank transfer in an environment where governments are cracking down on all such exchanges?

 2) Digital/Crypto Currencies    
        - These carry value and can facilitate trade and be used as collateral.  If a crypto-currency could be created that maintained near parity with actual dollars or gold then it could be used as part of a P2P exchange and enable in-person trades without having to worry about the exchange risk.  I think this is probably the biggest part of establishing a truly decentralized exchange.

 3) P2P  Exchanges    
         - Ripple already covers this in a manner that is relatively fast, unfortunately Ripple depends upon people publicly publishing their 'trust' for others.  The ultimate result of Ripple is that all parties are public and ultimately they end up trusting a 'centralized' gateway which will almost certainly require all of the same licensing as Mt. Gox.    If Mt. Gox is not viable then neither is Ripple.  

         - A true P2P exchange would have to deal with digital crypto-equivalent of various currencies and ultimately not depend upon any 'public' issuer.  If there is a 'public' issuer they would be breaking laws, represent a 'concentration of wealth' and thus a profitable target for government action.   Therefore if there are issuers they must be anonymous.

         - Any 'IOU' is only as valuable as the person standing behind it or the collateral they post to back it.  As a result, IOUs are not perfectly fungible unless the collateral has sufficient margin and is held in a decentralized manner.   The conclusion here is that short of 'ripple without gateways', all decentralized exchanges will require a means of holding collateral in a decentralized manner.   The challenge then becomes how do you resolve disputes regarding collateral?  Can it be managed by an algorithm?  If the collateral is 'held by a 3rd party' how can we trust that 3rd party?     I conclude from this that all collateral, margin, settling, and trading must be performed by some kind of crypto-currency with pre-defined rules that does not require trusting any 3rd party to hold funds nor settle disputes.  

         - Lastly, any P2P exchange will suffer from the 'speed-of-light' problem synchronization overhead.  If it truly is a global order-book, then all orders must be matched, confirmed, and settled in a defined order.   These exchanges will never be able to have Mt.Gox like performance until faster-than-light communication is possible.   The closes we could hope for is something along the lines of many Open Transactions servers that run behind a 'BitMessage' like anonymous system with the backing of the OT servers being held in an anonymous, peer-to-peer manner.  OT currently depends upon non-anonymous issuers who must be trusted and who ultimately could be shutdown by the government.    

 4) High Speed Exchanges    
        
          - These are 'centralized' but anonymous.  They have to be 'trusted' in some manner, perhaps by having a surety bond posted somewhere to back all trades on their exchange.   I do not think that 'high-frequency' trading is a *requirement* for a P2P exchange because as long as a low-frequency trading P2P exchange is available someone can and probably will set up anonymous high-frequency trading sites.   The key to making high-speed exchanges decentralized is to make them so easy to setup and run that it could be done in an afternoon.   Unfortunately, part of high-frequency trading is having a large market and the more 'decentralized' you make these exchanges the fewer people will exist at any one.  As a result, we can conclude that high-frequency trading will always tend to be centralized with perhaps 1-3 major players in each jurisdictions as the upper limit to what the market could support.


To conclude, I believe that the requirements mentioned here:   http://bitcoin.stackexchange.com/questions/11116/what-is-the-definition-of-a-p2p-exchange  are mixing too many different and logically incompatible systems.  So, instead we should attempt to break these requirements down into individual 'parts' and decentralize each part as much as possible given the constraints.

So here is my approach:

First we must establish that the *goal* is to exchange 'value' or 'purchasing power'.  You don't actually need gold or silver so long as you have purchasing power that enables you to buy gold or silver without exchange rate risk.   With this concept in mind we need to focus on moving and exchanging purchasing power without exchange rate risks in a decentralized manner.  To move purchasing power does not mean a decentralized system must move the underlying asset.

1) We need a crypto-currency to back all trades and serve as collateral.  If you want 'trustless IOUs' then the IOU must be collateralized in a 'trustless' manner and that implies some kind of crypto-currency block-chain that holds the collateral *AND* distributes it without needing to trust any party.  No voting, disputes, or requirements for 'outside' information.   These IOUs must not depend upon any action taken by any specific individual to 'fulfill'.

2) To be without any central points of failure, no-one must publicly back the issuance of any IOUs whether in the form of colored coins or new alt-chains.  As a result, all debts must ultimately be settled via crypto-currency even if the debt was denominated in gold or silver.   If an IOU requires a debt to be settled in actual gold, silver, or dollars and the person dies then you have a 'defaulted IOU' and thus a failure.   These kind of negotiable digital bearer instruments are already 'illegal' in many places and there is no way for a decentralized system to force someone to make good on this kind of IOU or even be able to tell that they defaulted on it!   The solution here is to have an 'IOU 1 $USD' backed by 2x that value in crypto-currency that will automatically be sold to cover the position and therefore no one is ever out the 'value of a dollar'.  

3) All IOUs involve risk and in any sane would would have an opportunity cost associated with not paying them off.  In effect, all loans must pay interest to the lenders in order to motivate both parties to take part in the transaction.   What incentive does someone have to 'lend' a $USD to someone else while taking risks in gray areas of the law?

Given the above we can create a decentralized bitcoin-like crypto currency that pays dividends.  We can then use this dividend paying crypto currency as the collateral for IOUs where the dividends serve as the 'opportunity cost' to the borrower and the reward to the 'lender'.    A P2P exchange can be encoded into the blockchain that allows people to trade these collateralized crypto IOUs and establish a market price from which automatic covering via block-chain rules can be applied.    The result will be a P2P system with trust-free IOUs denominated in Gold, Silver, USD, etc that also pays dividends.  

This P2P system can then be the foundation upon which anonymous centralized exchanges can offer high-frequency trading and by which 'local-bitcoins' can facilitate much larger local markets for trust-free in-person exchanges.   It would still be 'difficult' to move over $5K at a time as you would have to meet up with various people, but it should still be possible with a proper 'trusted' escrow agent.  

[charleshoskinson]

Bytemaster I'm glad you could make it here. Your feedback is always welcome and I look forward to collaborating with you in the future. I like some of the ideas you bring to the table.

[XertroV]

As an FYI to everyone, I'm currently working on a completely trustless p2p exchange for trading between altchains.

Copy pasta (mostly) from the foundation's forum in the p2p exchange thread:


I am working on something like this currently. The only exception is point 5: Have three-user (trustless) trading, so a non-interested 3rd party always hosts the trade between the buyer and seller. (And should provide Escrow too!))

Marketcoin (the name of the system) doesn't require three-user trading for trustlessness. It wouldn't be difficult to implement though, I suspect.

Marketcoin is required to be a new cryptocoin; I've looking into the chain-trade style setups, and there seem to be issues. Introducing a new cryptocoin allows these issues to be solved because we can make the new network have rules that eliminate these risks. (IE: after the orders are matched the onus is all on the buyer; the worst that can happen is the buyer sends the altcoin but doesn't redeem the marketcoin and they are returned to the original owner, furthermore, as marketcoin is a new blockchain, we can force it to take the risk to enable trustless exchange)

Note that Marketcoin is only compatible with Cryptocoins; however, pegged cryptocoins are also compatible.

Github (Whitepaper - not yet complete)

A P2P Distributed Exchange MUST:

1. Be without any central points of failure, since a government or two WILL be coming after it one day. I suggest a Bitorrent-like software schematic.
Marketcoin is based on a PoW blockchain and is as decentralised as Bitcoin (it will be forked from Bitcoin, after all)
Thus inherits properties of Bitcoin relevant to this point.

2. Show everyone a very large number of possible trades to choose from, (thousands?) so assets can form a stable price. (e.g. a Bitcoin is going for $120)
Number of trades is basically volume. Marketcoin (the exchange) will inherit this as the network matures. (Just like any other exchange). On this note, the same scaling issues are present in Marketcoin as in Bitcoin, and it will have similar transaction capacity.

3. Transact trades pretty much INSTANTANEOUSLY, so when you're watching a graph and want to trade at a very specific time you can do so. (This is extremely important for arbitragers and other traders who help keep the price fluctuation down.)
The successful finalisation of a trade has similar probabilistic natures as in Bitcoin. Required steps: broadcast order, order is confirmed in block, payment made on altcoin network, payment confirmed in a block on altchain, finalisation broadcast on Marketcoin network. After this control of the disbursement of the Marketcoin funds falls to the buyer.
I suspect the average time taken for trades will be 10-20 minutes or so. (5 minute blocks on marketcoin, requires a conf from altcoin network, then broadcasting the finalisation on marketcoin network; can be very fast, but higher risk, the converse is also true)

4. Offer Graphs and APIs for for graphing like MtGox does.
Getting market history is as trivial as getting past history in Bitcoin. The Marketcoin blockexplorer *is* the equivalent of BitcoinCharts. Charts will probably be built into the client too, though this isn't the most crucial priority.

5. Have three-user (trustless) trading, so a non-interested 3rd party always hosts the trade between the buyer and seller. (And should provide Escrow too!)
See above. This is not required but is possible (I suspect, since Marketcoin will inherit many of the scripts of Bitcoin (opcodes and whatnot)). In some frames of reference the network itself is this third party.

6. Hold and transfer VALUE, not just IOUs. (With Cryptocurrency this is easy... With fiat? Not so much.)
Trades involve real transactions of Altcoin and Marketcoin. For coins to be redeemed proof of payment (a standard transaction) must occur on the Altcoin network.
Work on Marketcoin is slow at the moment; I'm working full time and am trying to do what I can where I can. I'm also trying to be as transparent as possible as this provides the best chance of a successful launch for a new cryptocoin. Furthermore, for it's longevity it needs to get the market structure and dynamics right from the get-go, which is exactly why it can't be monetized.


On the note of fiat, I think the best way to move forward is to allow entry into a pegged cryptocoin. Then you inherit many of the nice properties of Bitcoin like irreversible transactions. Ultimately I think every discussion of integrating fiat with P2P exchanges is considering where the trust lies. I'm pretty confident you can't integrate fiat without some form of trust. In an OT/BitMessage style exchange the trust is with the other party accepting the trade; so trust is different for each user, thus each user will have a slightly different experience but the network is somewhat resilient. On the other hand with a centralised trust system (like a pegged cryptocoin) all trust lies with one (or a few) organisation(s) which might result in cataclysmic failure in the even of a regulatory-crackdown or change in legislation.

Also, I think that instant trades on an exchange is a terrible idea. We've the chance to reinvent the market, let's try and make it fair. (I can explain this point some more if anyone would like, but I'm at work in a foreign country atm, so I should probably get back to it)

On a random note, if someone can figure out a way to use cash + Zerocoin (with physical cash -> blockchain) then we might solve the p2p cash issue. Anyone want to start a bank which takes deposits and gives out zerocoins?

[bytemaster]

On the note of fiat, I think the best way to move forward is to allow entry into a pegged cryptocoin. Then you inherit many of the nice properties of Bitcoin like irreversible transactions. Ultimately I think every discussion of integrating fiat with P2P exchanges is considering where the trust lies. I'm pretty confident you can't integrate fiat without some form of trust. In an OT/BitMessage style exchange the trust is with the other party accepting the trade; so trust is different for each user, thus each user will have a slightly different experience but the network is somewhat resilient. On the other hand with a centralised trust system (like a pegged cryptocoin) all trust lies with one (or a few) organisation(s) which might result in cataclysmic failure in the even of a regulatory-crackdown or change in legislation.

The only way to create a 'peg' is via market forces and thus the 'peg' must fluctuate +/- a couple of percent around the actual market price.  Any "fiat" peg to 'fiat' would have to be backed by a central issuer and could be taken out if the right people were hit by busses.  

Like I said in my prior post, I am able to integrate a crypto-currency that tracks the purchasing power of 'fiat' without having any 'trust' except in the backing crypto-currency and automated margin covering rules.   I think this is the only approach that is viable, truly decentralized, and not subject to failure due to busses.  

New Requirement for P2P Exchange:  It must not have failure-due-to-random-bus killing someone.

Also, I think that instant trades on an exchange is a terrible idea. We've the chance to reinvent the market, let's try and make it fair. (I can explain this point some more if anyone would like, but I'm at work in a foreign country atm, so I should probably get back to it)

I agree.  Markets are more meaningful if people are making 'value plays' based upon outside information.   If there is only one exchange, then there is no need to play the differences between two exchanges in 'real time'.  Besides, I think it is technically impossible (due to the speed of light) to implement sub-second trades in a P2P manner.  

That said, the "best" and in my opinion "fairest" approach is to have all parties broadcast their bids and have them included in a block.  The following block can then deterministically make all trades.  If you want 'high-speed' trading, then you can broadcast multiple times including a higher-fee each time in an effort to get the miners to include the proper bid in the block.    If you want 'highest-possible speed' trading then you must mine the blocks yourself so you can select what *new* bids get into the block, but you cannot do anything about old 'unfilled' bids from prior blocks.   If you assume everyone is attempting to prioritize the bids and a large number of miners simply want the fees, then it is clear the difficulty would increase and decentralization of the mining process would occur as there is a new 'profit' motive for mining.  

One thing about 'block-chain' style trading is that a fork that lasts even a few hours could undo a large number of trades.  In other words, you cannot trade on the 'minority fork' at all as there would be no way to integrate those trades back into the main fork.   This means it is critical to detect a minority fork ASAP and stop all trading until it merges back.    This also means that the proceeds of all trades cannot be spent (or used in new trades) for say 24 hours.  

If you are integrating with other alt-coins like MarketCoin is then it must also handle the potential for forks of the alt-coin.  I suppose you could put the onus on individuals doing the trading to take that risk.      

Here is one question I have about MarketCoin... does it require users to manually participate in the trades by taking action on the 'alt-coin' network?   Or does MarketCoin come 'bundled' with a set of alt-coins that it supports and automatically executes trades on all networks?    It would seem that no trades could occur while a node was 'off-line' because the private keys on that node are required to complete the trade.  Therefore, your 20 minute trade time is only true for 'active users'.  This means that either the network needs to 'know' that the user is ONLINE and thus harm privacy and reduce the number of participants *or* some users might get paired with 'hung' trades that are unable to go through until the other user comes back from a 3 week vacation.   *or* the transaction times out and the user missed a buying / selling opportunity.   This creates an interesting attack vector where people place bids and then never respond and thus make the exchange unusable.  

I think a requirement of a P2P exchange is to allow 'off-line' and ATOMIC trades between currencies.  

This last requirement is perhaps the hardest of all to satisfy, and yet is something that my approach does solve.

[digicoin]

Interesting. I may be in

[XertroV]

The only way to create a 'peg' is via market forces and thus the 'peg' must fluctuate +/- a couple of percent around the actual market price.  Any "fiat" peg to 'fiat' would have to be backed by a central issuer and could be taken out if the right people were hit by busses.

You can create artificial market forces via a central-ish authority that exchanges 1:1. The black market might differ by a few %, but it should be reasonably stable. Maybe. Until we have an implementation we might not be able to truly tell what will happen.

Like I said in my prior post, I am able to integrate a crypto-currency that tracks the purchasing power of 'fiat' without having any 'trust' except in the backing crypto-currency and automated margin covering rules.   I think this is the only approach that is viable, truly decentralized, and not subject to failure due to busses.  

I'd like to hear more about this. At the end of the post I ask if you're talking about BitShares.

New Requirement for P2P Exchange:  It must not have failure-due-to-random-bus killing someone.

Agreed. Marketcoin simpliciter will not fail due to someone being hit by a bus.

In Marketcoin, after orders are matched:

• Seller of MKC gets hit by a bus: Trade continues as normal as onus is on buyer
• Buyer of MKC gets hit by a bus: If the altcoin payment has not been made then a short while (24hrs maybe) later the trade reverses; if the altcoin payment has been made but the trade is not finalised then the buyer might end up with their MKC returned and the Altcoin payment.

instant trades on an exchange is a terrible idea.

I agree.  Markets are more meaningful if people are making 'value plays' based upon outside information.   If there is only one exchange, then there is no need to play the differences between two exchanges in 'real time'.  Besides, I think it is technically impossible (due to the speed of light) to implement sub-second trades in a P2P manner.  

That said, the "best" and in my opinion "fairest" approach is to have all parties broadcast their bids and have them included in a block.  The following block can then deterministically make all trades.  If you want 'high-speed' trading, then you can broadcast multiple times including a higher-fee each time in an effort to get the miners to include the proper bid in the block.    If you want 'highest-possible speed' trading then you must mine the blocks yourself so you can select what *new* bids get into the block, but you cannot do anything about old 'unfilled' bids from prior blocks.   If you assume everyone is attempting to prioritize the bids and a large number of miners simply want the fees, then it is clear the difficulty would increase and decentralization of the mining process would occur as there is a new 'profit' motive for mining.  

This is precisely how Marketcoin works.

One thing about 'block-chain' style trading is that a fork that lasts even a few hours could undo a large number of trades.  In other words, you cannot trade on the 'minority fork' at all as there would be no way to integrate those trades back into the main fork.   This means it is critical to detect a minority fork ASAP and stop all trading until it merges back.    This also means that the proceeds of all trades cannot be spent (or used in new trades) for say 24 hours.  

If you are integrating with other alt-coins like MarketCoin is then it must also handle the potential for forks of the alt-coin.  I suppose you could put the onus on individuals doing the trading to take that risk.

This is an issue. I don't think we need to halt the exchange, as it is the onus of users (like when a blockchain fork occurs in Bitcoin) to determine when they will accept the transaction/trade. The advantage of Marketcoin is you can wait to broadcast the finalisation; you can make the payment on the altcoin network and wait an hour or ten before broadcasting the finalisation, this gives ample time to make sure blockchain forks haven't occurred. With some nice code it shouldn't be too difficult to have some sort of basic alert to let users know that trading may be unstable at the current point in time due to blockchain forks (on altcoin or otherwise). An advantage of Marketcoin is the uncertainty only falls on the currencypair affiliated with the forked altcoin, other markets will keep working.

I think the best way to structure the system is to give onus to users and not try and let the network fuddy-duddy around with txs trying to repair damage. Bitcoin doesn't do it, Marketcoin shouldn't either.

Here is one question I have about MarketCoin... does it require users to manually participate in the trades by taking action on the 'alt-coin' network?   Or does MarketCoin come 'bundled' with a set of alt-coins that it supports and automatically executes trades on all networks?

I think the best thing is to make the Marketcoin client connect with alt-clients in the style Armory uses, and possibly a little RPC as well. This lets the Marketcoin client be a bit lighter and even supports remote servers while still maintaining some degree of separation from the altcoin client.

Keep in mind Marketcoin is aware of all blocks on the altcoin network and will have access to the most recent ones. [It stores the block headers indefinitely and keeps blocks for 24/36 hours in order to fully validate payments]

I'd like to automate things as much as possible, something like a mode where it prompts you to interface with your Bitcoin client and executes payments as needed but also allows for manual transactions (if you want to separate things a little more or use a light client).

It would seem that no trades could occur while a node was 'off-line' because the private keys on that node are required to complete the trade.  Therefore, your 20 minute trade time is only true for 'active users'.  This means that either the network needs to 'know' that the user is ONLINE and thus harm privacy and reduce the number of participants *or* some users might get paired with 'hung' trades that are unable to go through until the other user comes back from a 3 week vacation.   *or* the transaction times out and the user missed a buying / selling opportunity.   This creates an interesting attack vector where people place bids and then never respond and thus make the exchange unusable.

One idea I had was using the same keypairs in Marketcoin as in the altcoins, which cuts down on the information transfered and means Marketcoin can sign txs for the altcoin network and submit them on its own. Knowing all the blocks and having a connection to the altcoin network lets you automate everything.

Part of the Marketcoin protocol is a 'trade-timeout' condition. An amply long period of time should be provided (24hrs say) but not so long that it ties money up for an unacceptable period of time (3 weeks).

20 minutes is a rough figure off the top of my head. We won't be able to tell till the network has a testnet. Ultimately it depends on block times and some other things. Keep in mind that for a transaction on the Bitcoin network to complete it can be instant (if you want to accept zero-confs) or it could an hour or more, depending on your own criteria. Likewise, a Marketcoin trade can occur in 10/15/20 minutes but if the buyer wishes to delay it (for added security against chain forks and the like) they can submit payment on the altcoin network and finalise on the Marketcoin network much later. They could even broadcast the finalisation with a minimum block number and it will be only included after that point.

All the measurements of ~24hrs and things I keep saying is an approximation, really it would be 144 blocks or whatever is expected for 24hrs.

I think a requirement of a P2P exchange is to allow 'off-line' and ATOMIC trades between currencies.  

This last requirement is perhaps the hardest of all to satisfy, and yet is something that my approach does solve.

Marketcoin facilitates offline or cold trades (similar to offline / cold transactions on Bitcoin). But, like Bitcoin, you'd have to move the data yourself.

I presume 'atomic' means trading 1 satoshi and the like. Marketcoin allows this but it may be restricted to minimize dust trades (similar to what Bitcoin-QT does with transactions now).

When you talk about your approach do you mean BitShares?

[BTCLuke]

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:

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.

[tumak]

As I'm one of developers of p2ptrade let me just say that it would be nice if more people would focus on implementation (yes, there are several projects out there - bitcoinx, pybonds, bitsofproof..).

Op is, however, just "contributing" useless blabber on forums and reddit.

There is vast amount of good and well researched ideas, what's missing is workable implementations with a chance for massive adoption. I'd suggest op to first try lurk more and contact relevant projects, instead of another a`la buttercoin trolling.

Thanks.

[bytemaster]

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:

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).  

[bytemaster]

As I'm one of developers of p2ptrade let me just say that it would be nice if more people would focus on implementation (yes, there are several projects out there - bitcoinx, pybonds, bitsofproof..).

Op is, however, just "contributing" useless blabber on forums and reddit.

There is vast amount of good and well researched ideas, what's missing is workable implementations with a chance for massive adoption. I'd suggest op to first try lurk more and contact relevant projects, instead of another a`la buttercoin trolling.

Thanks.

I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality.   What I think the OP is really after is getting everyone on the same page and working together.    Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place. 

To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change.   I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine.  This bounty will then serve to help get the project funded and going.   

That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is. 

[Matthew N. Wright]

Op is, however, just "contributing" useless blabber on forums and reddit.

I'm not sure if that will be the case forever, but the following canned response to a deeply thought out submission doesn't exactly inspire confidence.

We have had this discussion in other places, but I think the problem needs to be divided into several distinct areas:

1) Escrow Services:    
    The purpose of these services is only to facilitate already agreed upon trades over a long distance as in-person trades in theory require no escrow.  Escrow exchanges are almost by-definition multi-day events due to the slowness of traditional banking.   
     
      * The challenge posed by escrow is that all banking transactions are 'reversible' and therefore simply confirming a wire transfer, bank transfer, credit card payment, paypal, or dweller transfer is not enough.         
      * The third party is in theory subject to various laws if they actually hold fiat to facilitate the trade.  This third party also risks being brought into any investigation the government may have regarding that transaction.
       * The most decentralized version is NashX, though NashX only works between two people who already own crypto-assets.

     I would submit that the P2P exchange system should not attempt to solve the escrow problem because 'traditional' escrow services that are entirely legal and 'not exchanges' nor 'money transmitters' could be used.   There are other approaches that could be taken as well.   1) Both parties could have certified identities with a signed arbitration agreement with Judge.me or something similar.  2) Both parties could post and maintain a surety deposit that is entirely independent of the 'escrow' transaction.   These approaches would probably be sufficient for anyone involved with a lot of trades but the 'setup time' would make the 'first transaction' the most difficult.    This approach is also not as 'anonymous', but then again if you are transferring money through the traditional banking system it isn't really anonymous anyway.   Lastly, do you really want to 'trade fiat' for 'bitcoins' with a random stranger via direct bank transfer in an environment where governments are cracking down on all such exchanges?

 2) Digital/Crypto Currencies    
        - These carry value and can facilitate trade and be used as collateral.  If a crypto-currency could be created that maintained near parity with actual dollars or gold then it could be used as part of a P2P exchange and enable in-person trades without having to worry about the exchange risk.  I think this is probably the biggest part of establishing a truly decentralized exchange.

 3) P2P  Exchanges   
         - Ripple already covers this in a manner that is relatively fast, unfortunately Ripple depends upon people publicly publishing their 'trust' for others.  The ultimate result of Ripple is that all parties are public and ultimately they end up trusting a 'centralized' gateway which will almost certainly require all of the same licensing as Mt. Gox.    If Mt. Gox is not viable then neither is Ripple.   

         - A true P2P exchange would have to deal with digital crypto-equivalent of various currencies and ultimately not depend upon any 'public' issuer.  If there is a 'public' issuer they would be breaking laws, represent a 'concentration of wealth' and thus a profitable target for government action.   Therefore if there are issuers they must be anonymous.

         - Any 'IOU' is only as valuable as the person standing behind it or the collateral they post to back it.  As a result, IOUs are not perfectly fungible unless the collateral has sufficient margin and is held in a decentralized manner.   The conclusion here is that short of 'ripple without gateways', all decentralized exchanges will require a means of holding collateral in a decentralized manner.   The challenge then becomes how do you resolve disputes regarding collateral?  Can it be managed by an algorithm?  If the collateral is 'held by a 3rd party' how can we trust that 3rd party?     I conclude from this that all collateral, margin, settling, and trading must be performed by some kind of crypto-currency with pre-defined rules that does not require trusting any 3rd party to hold funds nor settle disputes. 

         - Lastly, any P2P exchange will suffer from the 'speed-of-light' problem synchronization overhead.  If it truly is a global order-book, then all orders must be matched, confirmed, and settled in a defined order.   These exchanges will never be able to have Mt.Gox like performance until faster-than-light communication is possible.   The closes we could hope for is something along the lines of many Open Transactions servers that run behind a 'BitMessage' like anonymous system with the backing of the OT servers being held in an anonymous, peer-to-peer manner.  OT currently depends upon non-anonymous issuers who must be trusted and who ultimately could be shutdown by the government.   

 4) High Speed Exchanges   
       
          - These are 'centralized' but anonymous.  They have to be 'trusted' in some manner, perhaps by having a surety bond posted somewhere to back all trades on their exchange.   I do not think that 'high-frequency' trading is a *requirement* for a P2P exchange because as long as a low-frequency trading P2P exchange is available someone can and probably will set up anonymous high-frequency trading sites.   The key to making high-speed exchanges decentralized is to make them so easy to setup and run that it could be done in an afternoon.   Unfortunately, part of high-frequency trading is having a large market and the more 'decentralized' you make these exchanges the fewer people will exist at any one.  As a result, we can conclude that high-frequency trading will always tend to be centralized with perhaps 1-3 major players in each jurisdictions as the upper limit to what the market could support.


To conclude, I believe that the requirements mentioned here:   http://bitcoin.stackexchange.com/questions/11116/what-is-the-definition-of-a-p2p-exchange  are mixing too many different and logically incompatible systems.  So, instead we should attempt to break these requirements down into individual 'parts' and decentralize each part as much as possible given the constraints.

So here is my approach:

First we must establish that the *goal* is to exchange 'value' or 'purchasing power'.  You don't actually need gold or silver so long as you have purchasing power that enables you to buy gold or silver without exchange rate risk.   With this concept in mind we need to focus on moving and exchanging purchasing power without exchange rate risks in a decentralized manner.  To move purchasing power does not mean a decentralized system must move the underlying asset.

1) We need a crypto-currency to back all trades and serve as collateral.  If you want 'trustless IOUs' then the IOU must be collateralized in a 'trustless' manner and that implies some kind of crypto-currency block-chain that holds the collateral *AND* distributes it without needing to trust any party.  No voting, disputes, or requirements for 'outside' information.   These IOUs must not depend upon any action taken by any specific individual to 'fulfill'.

2) To be without any central points of failure, no-one must publicly back the issuance of any IOUs whether in the form of colored coins or new alt-chains.  As a result, all debts must ultimately be settled via crypto-currency even if the debt was denominated in gold or silver.   If an IOU requires a debt to be settled in actual gold, silver, or dollars and the person dies then you have a 'defaulted IOU' and thus a failure.   These kind of negotiable digital bearer instruments are already 'illegal' in many places and there is no way for a decentralized system to force someone to make good on this kind of IOU or even be able to tell that they defaulted on it!   The solution here is to have an 'IOU 1 $USD' backed by 2x that value in crypto-currency that will automatically be sold to cover the position and therefore no one is ever out the 'value of a dollar'. 

3) All IOUs involve risk and in any sane would would have an opportunity cost associated with not paying them off.  In effect, all loans must pay interest to the lenders in order to motivate both parties to take part in the transaction.   What incentive does someone have to 'lend' a $USD to someone else while taking risks in gray areas of the law?

Given the above we can create a decentralized bitcoin-like crypto currency that pays dividends.  We can then use this dividend paying crypto currency as the collateral for IOUs where the dividends serve as the 'opportunity cost' to the borrower and the reward to the 'lender'.    A P2P exchange can be encoded into the blockchain that allows people to trade these collateralized crypto IOUs and establish a market price from which automatic covering via block-chain rules can be applied.    The result will be a P2P system with trust-free IOUs denominated in Gold, Silver, USD, etc that also pays dividends. 

This P2P system can then be the foundation upon which anonymous centralized exchanges can offer high-frequency trading and by which 'local-bitcoins' can facilitate much larger local markets for trust-free in-person exchanges.   It would still be 'difficult' to move over $5K at a time as you would have to meet up with various people, but it should still be possible with a proper 'trusted' escrow agent.   

Bytemaster I'm glad you could make it here. Your feedback is always welcome and I look forward to collaborating with you in the future. I like some of the ideas you bring to the table.

[charleshoskinson]

I'm not sure if that will be the case forever, but the following canned response to a deeply thought out submission doesn't exactly inspire confidence.

Matt just please stay out of my threads. I've had numerous hour long skype calls with bytemaster on his system and I've been reading his whitepaper. Please do not interject yourself into a conversation you obviously know nothing about

[tumak]

I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality.   What I think the OP is really after is getting everyone on the same page and working together.    Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place.  

To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change.   I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine.  This bounty will then serve to help get the project funded and going.  

That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is.  

Problem is all I can see in your bitshare-bitcoin repo is few few markdown files. Also, this: https://github.com/bytemaster/bitshare_bitcoin_branch/commit/b4bb2acb075181d7e34834763ef6a01cc0483cd0

So which is it, do you want to joint-design protocol, or IPO an vaporware you have not written single line of code? At least ripple people have *something*, though they premine too

Remember, english text does not count. People reinvent ideas on this forum every second.

Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.

[Matthew N. Wright]

Matt just please stay out of my threads.

Didn't you just get through inviting the entire community into it?

I've had numerous hour long skype calls with bytemaster on his system and I've been reading his whitepaper. Please do not interject yourself into a conversation you obviously know nothing about

I wasn't aware this public thread was a private conversation, nor that it was common knowledge that your short, uninspiring dismissive response to his long post could be considered adequate by a bystander who is otherwise unaware of your private conversations.

I'm happy to point out your inadequacies in public presentation (once again), but please stop making this about you. We're all here because we care about decentralized exchange. If you're going to "lead", then lead, and as a leader, when someone posts something in your thread publicly for critique and commentary, don't ignore the points-- respond to them. Otherwise, you risk people not taking you seriously as a leader.

[charleshoskinson]

I'm happy to point out your inadequacies in public presentation (once again), but please stop making this about you. We're all here because we care about decentralized exchange. If you're going to "lead", then lead, and as a leader, when someone posts something in your thread publicly for critique and commentary, don't ignore the points-- respond to them. Otherwise, you risk people not taking you seriously as a leader.

This is the last time I'm ever going to reply to a post you make thus I suppose you should savor it while you can. You have been arrogant, dismissive and condescending during my entire time at Bitcointalk. I'm not the one with an untrustworthy tag nor the one fired from his own magazine.

I have nothing to prove, but apparently you have everything to prove. One can never win an argument with a man in such a setting because you're beyond reason. Please enjoy the discussion here and please enjoy the products of BEP as they become available. I wish you well and I really hope you find the help you need.  

Ignore List On (Thank you Technology )

[bytemaster]

I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality.   What I think the OP is really after is getting everyone on the same page and working together.    Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place.  

To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change.   I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine.  This bounty will then serve to help get the project funded and going.  

That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is.  

Problem is all I can see in your bitshare-bitcoin repo is few few markdown files. Also, this: https://github.com/bytemaster/bitshare_bitcoin_branch/commit/b4bb2acb075181d7e34834763ef6a01cc0483cd0

So which is it, do you want to joint-design protocol, or IPO an vaporware you have not written single line of code? At least ripple people have *something*, though they premine too

Remember, english text does not count. People reinvent ideas on this forum every second.

Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.

I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
git@github.com:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.

[tumak]

I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
git@github.com:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.

Yep, checked it out before and was disappointed it's just "draft specification by C++". By bitcoin integration I didn't mean to use bitcoin-qt as shared code base (starting from scratch is probably indeed wiser especially if the ledger is architecturally too far from bitcoin), but to allow markets within bitcoin main blockchain. Sure that is cumbersome (various coloring and sigscript schemes), but the point is to serve existing userbase.

That being said, I'm looking forward to functional prototype, altcoins (and ledgers like OT) are still very interesting from research perspective, getting the "adoption" part right is a tough one though. Ask fellowtraveller.

[Matthew N. Wright]

You have been arrogant, dismissive and condescending during my entire time at Bitcointalk.

You have been delusional, self important and borderline sociopathic during your entire time at bitcointalk. My reaction to is just that, a reaction.

I'm not the one with an untrustworthy tag nor the one fired from his own magazine.

If you had an untrustworthy tag, would it make a difference to who you are? Does it make you untrustworthy? Mine is the sole opinion of Theymos, whose integrity can be called into question on multiple occasions I might add (he supports ponzis, refuses to give BFL a scammer tag, reverses "absolute" positions constantly, and continues to collect funds for the forum that have yet to be put to use in 12 months, despite the now probably millions of dollars collected).

As for the magazine, I have a very good relationship with everyone there, I was not fired, I resigned to ensure the longevity of my project (and was actually looking for a replacement months before that). Your misinformation fuels further ignorance, your lack of interest in learning contradicts your earlier statements of being "passionate about education", which calls your leadership and sincerity into question as anything other than the short sighted efforts of a sociopath.

One can never win an argument with a man in such a setting because you're beyond reason.

I think it's more that you don't know how to argue on the internet, nor understand how you appear when your every other statement is something to the tune of "What I am doing right now will change the face of the earth-- HOW COME NO ON IS LOOKING AT ME!". Feel free to ignore me or anyone else in the future that calls you out on how you present yourself. You're only hurting yourself.

@TOPIC: To everyone who is interested in putting a project for p2p exchange together, don't let the likes of this clown stop you. I've been distracted by the smooth talking of people before on this forum only to find out that they are in it for self promotion, and wasted time I could have otherwise have been spending being useful to others (all the while they stole my ideas and branded them as their own).

You do not need this guy to make your project work, you don't even need this forum, but when there are already tools available, a large flourishing community of like minded developers at your fingertips, and someone comes along asking for you to do all the work, but under his personally named umbrella, this should be setting off alarm bells. Stop giving others credibility by bringing them into your own projects, unless they are capable of matching your workload 50/50. I'd be interested to be proven wrong about the OP, but I don't see a single bit of work from him.

[bytemaster]

I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
git@github.com:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.

Yep, checked it out before and was disappointed it's just "draft specification by C++". By bitcoin integration I didn't mean to use bitcoin-qt as shared code base (starting from scratch is probably indeed wiser especially if the ledger is architecturally too far from bitcoin), but to allow markets within bitcoin main blockchain. Sure that is cumbersome (various coloring and sigscript schemes), but the point is to serve existing userbase.

That being said, I'm looking forward to functional prototype, altcoins (and ledgers like OT) are still very interesting from research perspective, getting the "adoption" part right is a tough one though. Ask fellowtraveller.

Like I said in other places, it is impossible to add the features I need to bitcoin even with new custom scripts.  The 'market making' function must be performed by all nodes as well as collateral enforcement.  There is no way to have a 'public' / 'automatic' dispersal of collateral held in the bitcoin block-chain and therefore the best you can hope for is some anonymous centralized service that operates the private keys.

The unchecked in code has more implementation, but you are correct the current checkin is mostly high-level but then again I only started it less than 1 week ago!

[XertroV]

Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.

This is where something like Marketcoin is very useful, quick trustless exchange of value between chains means altchains only need one function (like a zerocoin altchain or a bitshares altchain) in order to be useful. We should function on creating functional, innovative coins instead of trying to cram everything into Bitcoin. Bitcoin is wonderful, but it is designed as money and I think it would be good to keep it that way. The entire point of open source is that if someone want's to improve or alter Bitcoin they can.

Like I said in other places, it is impossible to add the features I need to bitcoin even with new custom scripts.

Exactly. It is commonly believed that trading between chains trustlessly is impossible with the current Bitcoin implementation. There is plenty of discussion on the Bitcoin wiki about the chain-trade algorithm and why it isn't good enough. It could work but only with mutually assured destruction (if the trade falls through all funds are lost).

[...] 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.

Edit:
I realised I didn't really address the above. Marketcoin incentivises early payment and late finalisation. The speed is determined by the buyer's eagerness. (When I talk about buyer and seller this is in the context of MKC). In this sense the seller will know if they've been paid before the network (and anyone else who checks the address). There's probably room for improvement here.
/Edit

Currently I'm leaning towards the idea of the buyer of MKC offering a 'pledge' which is sacrificed if they fail the trade. This shows intent to trade. The seller isn't required to do this because after orders are matched the trade is out of their hands.

The pledge could go to miners (but not to the miner who has the opportunity to block finalisation) or to the seller of MKC, or a combination. That would at least be some recompense for having the trade fall through. It also limits market manipulation. If the trade succeeds the pledge is returned to the buyer.

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.

This is and isn't an issue; my current vision for Marketcoin does not include an order book. In this way, trades will only stay active as long as you specify (similar to locktime) and if you're selling MKC then you don't have to worry about that.

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.

My original idea included using the same keypairs on both the Marketcoin chain and altchain (same privkey -> same pubkey -> different address). This lets Marketcoin handle everything on it's own, but only if you leave the keys unencrypted or have the password in memory. Not fantastic solutions, but my phone has unencrypted keys after all.

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.

The 'freshness' idea is similar to what I've got down at the moment.

The unpredictability is mitigated somewhat by having multiple trades with slightly different offers which are less likely to have the same buyer. The exchange

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'.  

Very similar to what I've got down, but there's also a pledge on the part of the buyer. Marketcoin is always one currency being transacted and the pledge is also made in MKC.

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.

Remember that the network incentivises fast payment and slow redemption. In the sense you provide, Marketcoin is not atomic, but I'm not really sure atomic is a good word to use.

24hrs is an arbitrary number, remember. It needs to be long enough to avoid fallout from chainforks but short enough to be tolerable.

Also, no two people can make identical trades, just like no two transactions on the Bitcoin network are identical unless they are, in fact, the same transaction.

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.

This is where I see Marketcoin standing. It is not the whole puzzle, but I think it is the most important piece, as we won't be using fiat much longer (because it just can't compete). Well, at least I'll be trying my hardest to ensure fiat dies out as quickly as possible. [I'll be running for the Australian senate in 3 yrs, and every 3 years thereafter]

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).  

I agree that escrow and exchange should be separated when talking about fiat.

For me, a fiat -> cryptocoin exchange has one main purpose and one main property:

PROPERTY: Can't be prevented by third parties
PURPOSE: To facilitate a transfer of value from fiat to cryptocoins (I like to call this type of money 'factum' money, and could possibly be a larger set than just cryptocurrency. It's a bit of a joke because fiat means 'let it be so' (roughly) and factum means 'done'. Also, I like the idea of calling something fact based money, or fact backed money.)


Another thing about Marketcoin: one of the things that will slow adoption is that, like Bitcoin, it's difficult to get into. To trade large volumes very fast you'd need some sort of other exchange to give you a large enough sum of MKC straight away. I do have one plan to help with that, but it isn't trustless, just easy.

This is because you have to make a 'pledge' to buy MKC. This is easy to deal with from a network standpoint with policy:

1. small trades require no pledge
2. number of small trades per block is limited (yay competition)


TL;DR Spam mitigation is a bitch.