Announcing Project Invictus: a P2P Exchange Collaboration

[Prophet]

So do we just add suggestions for inclusion at the site?

[1714906502]

1714906502

[1714906502]

1714906502

[1714906502]

1714906502

[1714906502]

1714906502

[bytemaster]

3. It must transact trades almost instantaneously. When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so. (This is extremely important for arbitragers and other traders who help keep the price fluctuation down.)

There are two parts to a trade - matching and locking the orders, and transferring value. "When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so." Really I think this means "When you are watching a graph of trades and you would like to make a trade at that current price, you must be able to do so, or have the same ability to do so as every other member of the exchange". Trades with fiat can't be instantaneous, but locking in a price can be.

You're shooting too low, it certainly is possible.

We must duplicate the instantaneous nature of fiat->crypto trading that mtgox currently offers.

In fact we must be even faster. The market demands it.

What this requires, of course, is that criteria 6 be an actual transference of value.

Or you use SSL logs to proof (almost) instantaneous transaction of fiat as described in https://bitcointalk.org/index.php?topic=173220.0.

I think a perfect p2p-exchange should allow instantaneous AND non-instantaneous trade fulfilling because it is always a trade-off. The users should be able to choose what they prefer. If you place an order you should be able to specify to what terms you are willing to agree:

1) in case of dispute, the seller has to proof using SSL-logs that he didn't receive the fiat.
2) in case of dispute, the buyer has to proof using SSL-logs that he did send the fiat.
3) in case of dispute, both parties have to proof using SSL-logs that they send or didn't receive the money.
4) the bitcoin-buyer has to provide instant proof of payment using SSL-logs.
5) in case of dispute, nothing happens. Just use supplied user ratings similar to bitcoin-otc.
6) use 2-party shared bitcoin collateral and both loose if trade is not fulfilled.

Options 1-4 would involve an escrow and the recording of SSL logs of your banking session and sending it to the escrow.
Option 4 would even allow instantaneous trades between bitcoin and fiat without IOUs.
Option 5 would be based on user supplied ratings similar to bitcoin-otc
Option 6 would be possible without escrow.

I think there are many good reasons why some users might prefer one of these methods over another. Why not let each user decide which way to trade (speed vs. risk vs. price etc.). In this way, the exchange market will automatically determine different prices for different trust levels and order types.

So I would actually change #3 to:

3a. It must match trades almost instantaneously.When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so.
3b. It must be possible to fulfill matched trades almost instantaneously if the chosen fiat transfer mechanism allows it.

*EDIT* Btw, the options which I specified above obviously focus on direct trading of fiat vs bitcoin. Of course it would be nice to have in addition to this some IOU based trading or something like a peged crypto-fiat like bitshares.

I think that all of these ideas are great approaches to the escrow problem.    My ultimate goal would be to make local exchanges as easy and simple as possible by eliminating exchange-rate spread/risk from the local exchanges.   

I think that you could eliminate the need for escrow entirely with the following setup:

1) A trusted company will certify someone's identity (Name, Address, Government ID)
2) Both parties will digitally sign an arbitration agreement with someone like judge-me with their crypto-graphic identity.
3) Both parties then sign the 'exchange terms' with this ID.
4) Now they can trade with the knowledge that even without escrow they will end up with a court-enforceable judgment.
5) This arrangement could be made even more 'secure' if the trusted company would 'insure' the transaction for a small fee.

The result is that for most people, once they have a signed ID they can 'trust' others with a signed ID and therefore avoid escrow.   The 'trusted company' wouldn't actually have to accept any fiat or crypto-currency except as payment for the 'service' of signing/certifying their ID and agreement to arbitrate.    This will solve many of the 'legal' issues associated with operating as an escrow agent. 


 

[XertroV]

As my dad once said, "I find your lack of faith disturbing."  

I am always ready to be proven wrong, especially when the benefit of the community is at stake.

 With that said, what is the logical result of a P2P exchange in the extreme?  Every individual *is* an exchange.

It seems to me this depends on how we look at that last sentence. Is Marketcoin a P2P exchange in the extreme? How do you then reconcile the idea of a unified single system such as Marketcoin. On the other hand, looking at systems like Bitcoin, one can argue that every individual *is* a bank, and so I can see that it can be resolved with a particular frame of reference.

Ultimately this is a small point to argue, but I'd like to see some academic investigation into it. (Though now is not the time or place to try and resolve such differences since I think we can all agree you're certainly correct enough for this conversation).

  I think there currently 4 categories of exchanges:  1) those like local-bitcoins or OTC  2) those like Mt. Gox  3) those based upon decentralized issuers of 'dollar-denominated crypto-currency'  that can be traded / exchanged via systems like MarketCoin or even anonymous exchanges. and last but not least, dollar-denominated crypto-currency without any specific issuer and that has value *independent* from any individual backing it.

  Assuming you can have a dollar-denominated crypto-currency with no issuers *then* you have already achieved the ultimate P2P exchange where *everyone* is an exchange you no longer require a system to 'pair' the highest USD/BTC bidder against the lowest 'ask'.   Everyone who wants into a dollar-denominated crypto-currency is a match against everyone who wants out of it and back into paper dollars.  Therefore, it is as decentralized as possible.

I agree that 4. is the ideal, though I'm not sure how easily it can be achieved. Still need to read the BitShares whitepaper though, so don't take my word for it. As a side point, I'd anticipate that Marketcoin would be compatible with such systems.

 I am going to go one-step further and claim that BTCLuke and I both require a nearly identical blockchain based trading platform.  We both require collateral with a crypto-currency.  All that remains to be solved is:
    1) how are new dollar-denominated crypto-bonds issued?
    2) how is the collateral requirement determined?
    3) how is default detected and the collateral paid out?
    4) how is the bond fulfilled?

A lot of 'ifs' there, though I look forward to your solutions

  I have answers to the 4 questions, and would like to see what answers BTCluke has.  

I think I've found a way around the 3rd party in one case. I'm sooooooooo close to having it all documented...

For normal trading, such as buying USD with Bitcoins, or Bitcoins with USD, I'm still planning to use the 3rd party to actually move the values of the currencies after the trade has "been made" in real time.

For purchasing the representation of the USD, I think there is a semi-trustless 2-way exchange option. (Yes, with no central authorities.) I'll detail it in my upcoming whitepaper.

more . I look forward to it.

3a. It must match trades almost instantaneously.When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so.
3b. It must be possible to fulfill matched trades almost instantaneously if the chosen fiat transfer mechanism allows it.

I agree with this, it's certainly a two part issue, and I think this separation is important.


On the note of using SSL style systems, these are probably one of the better ways of dealing with the issues fiat raises, and it helps p2p trade of fiat without needing to buy into a cryptocurrency solution; as always there's two sides of the coin, but having more options is always beneficial.


Has anyone else thought about applying for a grant from the Bitcoin Foundation?. I'm applying for one with Marketcoin; though only a little one to begin with. If anyone has systems they'd like to develop but don't have the funds I'd really encourage it. Peter, Gaving and Lindsay all encouraged me to write one for Marketcoin. You can find my application here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md


Edit: Tumak has updated the crosschain p2ptrade algorithm to be clearer, please find the updated version here: https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade

[tumak]

Has anyone else thought about applying for a grant from the Bitcoin Foundation?. I'm applying for one with Marketcoin; though only a little one to begin with. If anyone has systems they'd like to develop but don't have the funds I'd really encourage it. Peter, Gaving and Lindsay all encouraged me to write one for Marketcoin. You can find my application here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md

Edit: Tumak has updated the crosschain p2ptrade algorithm to be clearer, please find the updated version here: https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade

Good, glad to see someone finally being serious about this.

I think you'd want to get demo of crosschain p2pt running before asking foundation to fund it, if I see repo with sensible code, I'll even help you. The wording in the paper is a bit unfortunate imho, it sounds a bit like heresy - your altchain is designed to support fragmentation of Bitcoin ecosystem and you're asking Bitcoin foundation to support that? Maybe you want to tweak your wording a bit. There are far more productive use cases for cp2pt than just faciliating BTC x LTC x otherscamltc p2ptrade.

[XertroV]

I think you'd want to get demo of crosschain p2pt running before asking foundation to fund it, if I see repo with sensible code, I'll even help you. The wording in the paper is a bit unfortunate imho, it sounds a bit like heresy - your altchain is designed to support fragmentation of Bitcoin ecosystem and you're asking Bitcoin foundation to support that? Maybe you want to tweak your wording a bit. There are far more productive use cases for cp2pt than just faciliating BTC x LTC x otherscamltc p2ptrade.

As I mentioned in the proposal I'm not looking to fund development, just community stuff at this stage. Once there's a community and some development then I'll consider asking for development funding. The whitepaper is very much a work in progress. I'm quitting one of my jobs at the end of June so I can work on Marketcoin part time.

Unfortunately the only use ATM is trading to Litecoin or shitecoin, but I don't see these altcoins being particularly useful. Ultimately I'm looking to create infrastructure that will help exchange between Bitcoin and purposeful currencies, be they local currencies or for novel purposes (like Namecoin).

Also, I don't expect this grant to be successful. Worst case is the board reads it and says no; I'll be working on it either way, though it might be a little slower without a grant. I'll be applying for another in 3 months in any case. At least they hear about it and there'll be some discussion.

I believe that Marketcoin will not fragment the Bitcoin ecosystem; rather it will help it flourish. The philosophy behind Bitcoin is present in Marketcoin, and will continue to be.

Edit: Grant Proposal submitted. View it here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md

[bytemaster]

Unfortunately the only use ATM is trading to Litecoin or shitecoin, but I don't see these altcoins being particularly useful. Ultimately I'm looking to create infrastructure that will help exchange between Bitcoin and purposeful currencies, be they local currencies or for novel purposes (like Namecoin).

This is my primary concern with MarketCoin.    Assuming we had it built today it wouldn't provide that much value to the current system.   It also assumes that all alt-coins will be compatible with bitcoin-style RPC api and scripts.   Therefore, any alt-coin that wanted to integrate with MarketCoin would have to use some kind of 'plugin' system or be designed specifically for MarketCoin.

So my question is this:  suppose you were to create a new Alt Chain, what features should this chain support for best integration with MarketCoin?

[bytemaster]

Has anyone else thought about applying for a grant from the Bitcoin Foundation?. I'm applying for one with Marketcoin; though only a little one to begin with. If anyone has systems they'd like to develop but don't have the funds I'd really encourage it. Peter, Gaving and Lindsay all encouraged me to write one for Marketcoin. You can find my application here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md

Edit: Tumak has updated the crosschain p2ptrade algorithm to be clearer, please find the updated version here: https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade

Good, glad to see someone finally being serious about this.

I think you'd want to get demo of crosschain p2pt running before asking foundation to fund it, if I see repo with sensible code, I'll even help you. The wording in the paper is a bit unfortunate imho, it sounds a bit like heresy - your altchain is designed to support fragmentation of Bitcoin ecosystem and you're asking Bitcoin foundation to support that? Maybe you want to tweak your wording a bit. There are far more productive use cases for cp2pt than just faciliating BTC x LTC x otherscamltc p2ptrade.

Please enlighten me on these more productive uses?   

Would the 'bitcoin' foundation ever sponsor an alt-coin if it looked to solve problems that couldn't be added to or directly integrated with Bitcoin?

[charleshoskinson]

Good, glad to see someone finally being serious about this.

I think you'd want to get demo of crosschain p2pt running before asking foundation to fund it, if I see repo with sensible code, I'll even help you. The wording in the paper is a bit unfortunate imho, it sounds a bit like heresy - your altchain is designed to support fragmentation of Bitcoin ecosystem and you're asking Bitcoin foundation to support that? Maybe you want to tweak your wording a bit. There are far more productive use cases for cp2pt than just faciliating BTC x LTC x otherscamltc p2ptrade.

I really do find this comment condescending. I've just received a 22 page whitepaper BTCLuke and I have numerous others. Some members here have been writing actual code to test their ideas. I have access to considerable funding and will spend it to ensure this project moves in the proper direction. I don't really understand your definition of serious, but I will inform you that the foundation's behavior and funding patterns are impossible to divine. I wouldn't ever get into bed with them on any project.

[bytemaster]

Definitions:
BitShare -  A 'dividend paying, bitcoin-like, crypto-currency'.
crypto-bond - an IOU denominated in one asset and backed by either BitShares or a crypto-bond denominated in another asset.
crypto-USD -  a crypto-bond denominated in USD with collateral in the form of BitShare's held by the block chain.
crypto-EUR-USD  - a crypto-bond denominated in EUR and backed by crypto-USD.
crypto-BS-USD  - a crypto-bond denominated in BS and backed by crypto-USD

Use Cases:

1)  Grandma wants to earn a 10% return on her dollars, but is unable to use a computer.   Her grandson decides to help her out, so he receives the dollars from his grandmother and then uses them to buy crypto-USD.   He buys his crypto-USD by posting an ad on craigslist saying that he is looking to buy some.    Someone responds to the add and they meet up to exchange crypto-USD for paper dollars.  The grandson then prints out the private-key and gives it to his grandmother to hold on to.

2) A year later Grandma wants to get her dollars back, so she contacts her grandson and gives him her private key.  The grandson then gets on crags list and sees an ad for someone near by who wants to buy some crypto-USD.   They meet up and trade and the grandson then gives the money to his grandmother.

3) George lives in the middle of nowhere and the nearest person with crypto-USD is over 2 hours away.    Fortunately, he has family who live in a major city, so he calls up his brother and offers him $10 to buy $1000 worth of crypto-USD from another local.  His brother agrees, so George sends him $1010 and his brother then buys 1000 crypto-USD and then transfers (via BitShare) those crypto-USD to George in the middle of nowhere.

4) Sam is a trader who specializes in crypto-currencies.  He has been watching the market and sees that BitShares are 'undervalued' relative to crypto-USD and so he decides to 'short' crypto-USD by selling it into the market.  To do this he is giving up his dividends.   If he was right, the value of crypto-USD will fall (relative to BitShares) and he will be able to buy back the crypto-USD for less and make a profit greater than his dividends.    If he was wrong, then the value of crypto-USD could rise and the network could cover his position causing Sam to lose money.    As a result, it is only profitable to short if you expect the price to fall at a rate faster than the dividends you give up!

5) Alex is an early adopter of BitShares, he has mined 100 BS and believes that they will triple in value in the months ahead.   He could simply hold his position, but instead he wants to leverage up.   As a result, Alex shorts crypto-USD.   If he is right, then he will gain more from this short position than the dividends he might have earned by simply holding BS.    In this way Alex is creating crypto-USD for the 'risk-adverse' in the early days when BitShares are already appreciating rapidly and paying a very high dividend.  

6) Alice is a currency trader who wants to play the EUR/USD market.   Alice mines some BitShares and then uses them to buy crypto-EUR.   She then uses her crypto-EUR to short crypto-USD (creating crypto-USD-EUR) because she expects EUR to go up relative to USD.

7) David thinks that BitShares are overpriced in a new bubble, so he buys crypto-USD then uses it to short BitShares creating crypto-BS-USD.  

Andrew, like Alex, believes that BitShares will go up in value; however, he doesn't like the exposure of going short USD, Gold, or anything else.   Instead he deciders to go long crypto-BS-USD.   Because crypto-USD pays 2x the dividends (in BS) as the equal value in BS, and crypto-BS-USD requires 2x margin held in crypto-USD to back the crypto-BS-USD, then Andrew can earn 4x the dividend rate by purchasing crypto-BS-USD without having to expose himself to any other currency.

9)  Fernando runs an online store and wants to accept payments via a crypto-currency.  Unfortunately, all of his suppliers price things in USD.   Fernando instead opts to price things in crypto-USD.  As a result his customers get price stability, Fernando avoids all exchange fees that would be incurred if using something like Mt.Gox merchant services, and Fernando gets to earn interest while he waits to cash out.

10) Luke has some Bitcoins and wants to buy crypto-USD, using the BitShare exchange.   First, Luke must acquire some crypto-Bitcoins so he finds Charles who has crypto-BTC and is looking to get real BTC.    So, Luke and Charles use this algorithm: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading   to exchange Crypto-BTC for BTC without having to worry too much about the 'exchange rate' as it should be about 1:1.     This 'feature' for cross-chain-trading would be 'built-in' to the BitShare client where Luke and charles would only need to specify the 'addresses' in each chain and the exact exact exchange ratio.   The clients would support 'broadcasting' bids/asks to negotiate 'real-time' counter-parties and all transactions would 'expire' within 20 minutes.   Because the trading range on BTC to crypto-BTC is very small the market should be very liquid and very quick and can easily require all nodes to be alive and interactive without having to worry about a 'thin' market.  It would likely work even if only 2 people were online at the same time.

Given the above 'cross-chain' trading algorithm, I believe that it would be entirely possible to allow much faster trading between all of my crypto-currencies provided all users involved in the trades are 'online' and are not taking out a 'short' position.    Only the process of creating a new short position would require going through the built-in exchange.   Any trades outside of the 'slow' multi-block process would be restricted to valuations between the current bid/ask price in the block chain.


Conclusion:
  I believe that BitShares would enable all of the above interactions without the need for 'market coin'.  When dealing entirely with crypto-currencies, no escrow would be required to get BTC,LTC,NMC,etc in/out of BitShares.    Once you have crypto-BTC it would be easy to do a lot of exchanges between any other crypto* sub-currency without having to always find a real-time counter party (like MarketCoin would require).  

 With this latest setup I believe I have 'unified'  MarktCoin, BitShares, and BTC Luke's crypto-bond system.   I have significantly simplified the ability to find local people to trade with by minimizing the buy-sell spread between crypto-USD and USD and demonstrated how someone like Grandma can use a trusted (decentralized) 3rd party to gain benefits from the system without even having to use a computer.  

 The only peace missing from this system is 'escrow' for long-distance trades between crypto-USD and USD.   As this piece doesn't involve a 'trading engine' I think it falls outside the scope of a p2p exchange.   I suspect that companies like BitInstant which already are licensed would enable such a service to complete the overall solution.  BitInstant would not be a requirement, but would serve to help while they are legal.

[bytemaster]

Regarding long-distance crypto-USD.   This could be done in an anonymous manner via a P2P escrow system where the crypto-currency side of the transaction places their funds in escrow with an 'bonded' escrow agent with a pre-signed arbitration agreement.   This escrow agent would then control the release of the crypto-currency provided both parties confirm receipt of fiat.   Only in the case of a dispute would the escrow agent have to know the financial details of the transaction, especially if the 'hash' of the agreement was encoded into the block chain.

The escrow-agent only gets involved if there is a dispute and does not have to take any actions at all if there is no dispute.    Failure of either party to communicate with the escrow agent (in a dispute) will be considered 'default'.   The escrow agent could be used without any pre-arranged agreement with the escrow agent *provided* the transaction includes a hash of the arbitration agreement and pays a small fee to the agent.

The sender of the crypto-currency would actually place 120% in escrow.  If they claim they didn't receive the fiat and the sender of the fiat can prove otherwise then the sender wins 120% to cover the cost of the dispute.  If both parties agree then 100% is forwarded on to one party and 20% is returned to the other. 

Why can they trust the escrow agent?  Because the agent is bonded and has a large amount of BTC in escrow with one or more other agents.  If there is a dispute with the escrow agent then it can be taken up a level. 

Why would an escrow agent post a bond?  So they could earn fees on every transaction that uses their services.   Why would they be fair?  Because it is more profitable to be fair than to cheat as you could only cheat once.   If all escrow agents are 'bonded' with many other 'escrow' agents then it would be easy to trust them provided even one of the escrow agents was had a known and trusted reputation. 

Based upon this, the blockchain should support this kind of 'escrow' arrangement built in.

[bytemaster]

More Details on P2P Escrow:

1) all communication would be done via bitmessage.
2) all escrow agents would get to pre-define their terms:  (fee, surety rate (20% above) time tables, bitmessage address, required evidence, etc) in the block chain
3) The escrow agent does not collect the fee until the transaction settles and can only divide the funds between the two parties.
4) Escrow agents could place their bond with another escrow which will create a 'web' of trust, only a few of the escrow agents would have to be 'public' or 'known' to enable all escrow agents to function honestly.
5) The block-chain would then automatically enforce the fees, time tables, and other aspects of the escrow contract.
6) When funds are released by the escrow agent, it may be 'challenged' in the block chain for 24 hours.  If a 'challenge' transaction is placed into the chain then a new dispute is raised with the agents bond on the line.    
7) This process of appeal can continue until you reach a non-bonded agent (presumably the trusted public figure) or 3 consecutive appeals result in the same decision.

Because all communication occurs over BitMessage it can all be integrated into the BitShare client app which will be able to 'track the progress' of the dispute, confirm payment, etc.   Because all escrow agents, transactions, and dispute decisions are logged in the blockchain, it is easy to discover and follow which escrow agents have been used the most, have resolved the most disputes, what their fees / schedules are, and how long it takes them to resolve disputes.   It would also give you insight into how often one agent is involved in a dispute and which side of the dispute they side with (normally).  All of this information would make the 'outliers' stand out and help people choose anonymous escrow agents.

End result?  Cheap, 'trustless', escrow with anonymous dispute resolution necessary to facilitate fiat-trade.

[bytemaster]

Regarding requirements on a P2P exchange...    should we add the ability to take out short positions? 

[charleshoskinson]

Yes, if the system is robust enough to support a wide array of derivatives, then we should expect faster and more institutional adoption. He's the rule, if Goldman Sachs is making money off of it, then don't expect a government shutdown anytime soon.

[charleshoskinson]

http://bitcoinmagazine.com/libertybit-suspends-operations/

Feeling the pressure yet?

[bytemaster]

Criteria of the Ideal P2P Exchange

 1.  It must be without any central points of failure.

 2.  It must present a deep market with a large number of bids and asks.

 3.  It must enable orders of any size to be filled in a single transaction (provided there is reasonable market depth at a given price)

 4.  It would enable all forms of financial transactions including: long, short, put and call options.

 5.  Trades must be atomic and not subject to failure after a bid and ask have been paired.

 6.  It must lock in all trades in minutes and finalize those trades within 24 hours.

 7.  It must enable secure escrow of fiat transfers between parties.

 8.  It must be easy enough for anyone who can use Bitcoin and an existing centralized exchange to understand.

 9.  All trade data must be public to enable the creation of charts necessary to facilitate trading.

 10. It must be scalable

 11. It must not depend upon 'external' price sources of price information (tickers, voting, self-reporting, etc)

 12. It must shelter as many users and transactions from legal liability as possible.

 13. It should address known scalability issues with Bitcoin

[XertroV]

So my question is this:  suppose you were to create a new Alt Chain, what features should this chain support for best integration with MarketCoin?

I think the current requirements for integration with the system as I've written up are:

• Can be used as a parent chain for merged mining
• Uses transactions where outputs can be confirmed
• Uses transactions which are confirmed in a blockchain
• Irreversible transactions

One of the advantages is it works with standard Bitcoin transactions, and can be used with addresses (instead of pubkeys) if the same keypair is used on both the Bitcoin and Marketcoin network.

The last three properties are important for proof-of-payment, the first is important for having a perfect-knowledge system (or close enough for these purposes; not sure of the limits here). Maybe knowledge discovery is a better term.

I'm planning to expand the proof-of-payment algorithm so 'pledges' (similar to what Marketcoin uses) can be used as proof-of-intent-to-pay, where once the trade is made coins will be released. This is a little more complex though. It would be nice to support this for the first mainnet release, but I'm unsure if it's properly do-able or feasible as I haven't put that much thought into it yet.

Please enlighten me on these more productive uses?   

I think there plenty of productive uses if we use liberal amounts of imagination, in terms of salient productive uses, not so sure.

Would the 'bitcoin' foundation ever sponsor an alt-coin if it looked to solve problems that couldn't be added to or directly integrated with Bitcoin?

I hope so, that's what Marketcoin is, ultimately. Let's see in 6 weeks

Conclusion:
  I believe that BitShares would enable all of the above interactions without the need for 'market coin'.  When dealing entirely with crypto-currencies, no escrow would be required to get BTC,LTC,NMC,etc in/out of BitShares.    Once you have crypto-BTC it would be easy to do a lot of exchanges between any other crypto* sub-currency without having to always find a real-time counter party (like MarketCoin would require).  

 With this latest setup I believe I have 'unified'  MarktCoin, BitShares, and BTC Luke's crypto-bond system.   I have significantly simplified the ability to find local people to trade with by minimizing the buy-sell spread between crypto-USD and USD and demonstrated how someone like Grandma can use a trusted (decentralized) 3rd party to gain benefits from the system without even having to use a computer.  

Awesome! I look forward to seeing how this pans out!

On the note of the atomic trading alg and comparing it to Marketcoin:

• Marketcoin requires no changes to the Bitcoin/altcoin network
• Marketcoin does not use nLockTime (Marketcoin's finalisation system is different, you can look at the reversal as similar to nLockTime but it isn't the same thing)
• Marketcoin has very interesting economic properties such as eliminating arbitrage between all currencies on the exchange
• After the orders are locked in a block only one party has to do anything, the seller of MKC just sits back and waits
• Way fewer steps
• Possibly less opcode needs, but this won't fall either way until the protocol is fully developed

Also, love the use cases.

[XertroV]

Criteria of the Ideal P2P Exchange

 1.  It must be without any central points of failure.

 2.  It must present a deep market with a large number of bids and asks.

 3.  It must enable orders of any size to be filled in a single transaction (provided there is reasonable market depth at a given price)

 4.  It would enable all forms of financial transactions including: long, short, put and call options.

 5.  Trades must be atomic and not subject to failure after a bid and ask have been paired.

 6.  It must lock in all trades in minutes and finalize those trades within 24 hours.

 7.  It must enable secure escrow of fiat transfers between parties.

 8.  It must be easy enough for anyone who can use Bitcoin and an existing centralized exchange to understand.

 9.  All trade data must be public to enable the creation of charts necessary to facilitate trading.

 10. It must be scalable

 11. It must not depend upon 'external' price sources of price information (tickers, voting, self-reporting, etc)

 12. It must shelter as many users and transactions from legal liability as possible.

 13. It should address known scalability issues with Bitcoin

2. Isn't this a function of the userbase? How do you present a large number of bids/asks on an otherwise perfect P2P exchange that only 7 people worldwide use? I think this should be removed, but I understand why it's here.

Suggestion: "It must present the deepest market possible given outside constrains on the system, such as userbase"

7. I've voiced my concern about putting requirements for fiat in these criteria. I won't go into too much detail (again) but I would actually suggest that fiat is a corruption of 'ideal money' and so necessitates a corruption of the 'ideal exchange'. I hope we're not using fiat in 10/50/100 years time, and what is an 'ideal' exchange will be different because of that, and probably won't mention fiat. Just a thought.

13. I'd like to suggest an expansion to this "It should address known scalability issues with Bitcoin or be able to take advantages of scalability improvements when they are made to Bitcoin". Not the most elegant wording, but hopefully you can understand what I mean by that. It worries me if we try and develop too much at this stage we'll miss the opportunities for innovation. Scalability is an issue for Bitcoin, but not just yet. We'll see what develops over the next few years.

[bytemaster]

2. Isn't this a function of the userbase? How do you present a large number of bids/asks on an otherwise perfect P2P exchange that only 7 people worldwide use? I think this should be removed, but I understand why it's here.

Suggestion: "It must present the deepest market possible given outside constrains on the system, such as userbase"

7. I've voiced my concern about putting requirements for fiat in these criteria. I won't go into too much detail (again) but I would actually suggest that fiat is a corruption of 'ideal money' and so necessitates a corruption of the 'ideal exchange'. I hope we're not using fiat in 10/50/100 years time, and what is an 'ideal' exchange will be different because of that, and probably won't mention fiat. Just a thought.

13. I'd like to suggest an expansion to this "It should address known scalability issues with Bitcoin or be able to take advantages of scalability improvements when they are made to Bitcoin". Not the most elegant wording, but hopefully you can understand what I mean by that. It worries me if we try and develop too much at this stage we'll miss the opportunities for innovation. Scalability is an issue for Bitcoin, but not just yet. We'll see what develops over the next few years.

Agreed with #2

I originally agreed with you on #7 but only because I thought it was 'too difficult' and 'orthogonal' to the trading function.   But when you consider the #1 complaint against earlier versions of BitShares was that you 'still have to use escrow' you realize that the *primary purpose* of most exchanges is escrow.  The key thing to understand / avoid in creating a P2P exchange is how to avoid using 'escrow' at every time a bid/ask is matched because escrow and moving fiat is way to slow to be placed in this bottle neck.   Thus you want to create an escrow system that helps people get into / out of crypto-bonds.

Why should escrow be built in?   Because money held in escrow faces exchange rate risk and therefore you want the 'escrow-funds' to be denominated in the same unit as the fiat funds.   Two, you want to avoid trusting a 3rd party at all if both parties execute a successful transaction and in the event of a conflict you want the escrow agent to be restricted in who they can send the funds to.   Third, you want the escrow agents to be anonymous, decentralized, and profitable to ensure they have profit motive for providing just arbitration services.   Fourth, you want the escrow agents bonded so that their decisions can be disputed by yet another 'anonymous' agent.

All of these 'features' of escrow are best implemented via a blockchain and to avoid the blockchain synchronization issues it is best to integrate escrow into the P2P exchange chain as a simple addition of a few output scripts.   

So in conclusion, the 'ideal' exchange seamlessly supports escrow and thus handles fiat.  The fact that it makes fraud almost impossible means that it will not be 'profitable' to attempt fraud and thus all users can trade confidently even with fiat without having to deal with capturing their SSL logs and potentially compromising their account information even on successful transactions.   It also avoids artificial limits on the means of performing the fiat exchange as (cash, check, money order, wire transfer, paypal, etc... ) could all be used provided evidence of the 'transfer' could be captured and presented to the 'anonymous' escrow agent. 

#13  agreed.

[bytemaster]

Based upon some of the recent updates / additions to BitShares here is a summary of the 'changes' to Bitcoin.

 A BitShare is a new crypto-currency that has most of the properties of BitCoin.  They are mined into
 existence, transferred via a block-chain, secured by encryption and proof of work.  The primary difference
 between a BitShare and a BitCoin is that a BitShare will pay you dividends via 50% of the transaction fees
 and mining rewards.

 The BitShare block-chain introduces a few new rules and transaction types that turn it into a secure,
 multi-currency, bank, exchange and escrow service.


 Definitions:
 1) BitShare        - Dividend Paying Crypto-Currency
 2) CryptoBond      - An IOU secured by a BitShare or other CryptoBond
 3) CryptoUSD       - An IOU USD secured by BitShares.
 4) CryptoGold-USD  - An IOU Gold secured by CryptoUSD
 5) CryptoBS-USD    - An IOU BitShare secured by CryptoUSD

 I will now go over these new transactions:

 1) Short Sell

    - A transaction that provides collateral as input and specifies an ask for a CryptoBond at
    a specified exchange rate.  This transaction may be canceled.

 2) Bid

    - A transaction that provides a payment BitShare or CryptoBond and a request to purchase a BitShare or CryptoBond
      at the specified exchange rate.

 3) Call / Put

    - A transaction that gives another party the right to claim the output at the specified price by the specified date (block).  The
    output of this transaction represents two sides of the trade and both sides can exchange their position with other addresses.  Call
    options come due once per month.   These instruments may be traded like CryptoBonds or BitShares via the exchange system.  The collateral
    necessary to secure the position is held for the duration of the instrument.

 5) Register Escrow Agent
    - specifies the fee and surety requirement, term limits, hash of the arbitration agreement, BitMessage address, Surety bond, and a list of
    other Escrow Agents that may release the Surety bond along with an expiration date.  The input to this transaction is
    the surety bond and may be denominated in any CryptoBond.

 5) Escrow Transaction
    - A transaction that specifies an escrow agent and pays an escrow fee and surety requirement and a hash of the 'agreed contract' signed by both
    parties.  If dispute is filed, this transaction automatically clears after a certain amount of time.  No new transactions may be issued
    using a particular escrow agent if there is an open dispute

 6) Escrow Release
    - A transaction signed by a party to the Escrow Transaction to release their funds to the other party and the fee to the escrow agent.

 7) Escrow Dispute
    - A transaction signed by either party to lock the funds until they are released by the escrow agent.

  Escrow Dispute Resolution
    - A transaction signed by an escrow agent that divides the escrow funds among the two parties.  This transaction may be disputed as
    well and will be resolved by whoever is allowed to release the surety bond.


 9) Foreign Chain Trade
   - A set of transactions that implement atomic cross-chain trading.


Built-in Exchange Rules:

   Every block the miner is responsible for deterministically pairing bids/asks that are already present in the chain.  The Miner is
   also responsible for giving all margin calls priority over all other bids.  The process of pairing bids/asks and resolving
   Margin Calls is deterministic.  Transactions matched by the miner may not be spent for 24 hours when the mining reward is released.

   Between blocks, no transaction may exchange value between two CryptoBonds unless done at an exchange rate between
   the bid and ask price of the prior block.  This will enable rapid off-chain negotiation and instant spending of the resulting
   trade when it gets included in the next block.  This rapid off-chain negotiation can only occur between parties with an
   active connection to the network and the ability to sign with their private keys.

   The miner may collect a 5% fee anytime Margin is called.

   Anytime a position runs out of margin, it is liquidated and the proceeds are paid out as dividends.

[bytemaster]

Scaleability issues that must be addressed:

1) Every block must update the dividends per share of all bond types and this information must be tracked as far back as the oldest 'unspent' output.  Dividend calculations are required for every input and must either query every prior block's divided table or there must be a lookup table based upon 'coinage'.   

2) The number of potential trades / exchanges grows with O(N^2) of the number of currency units thus for 8 units, there are 56 possible short/long combos each of which requires 16 bytes / block 'forever'.

3) Even storing just the 'unspent' outputs at under 50 bytes each would result in TB of data in short order assuming transaction volume similar to Bitcoin, but exchanges will probably have several orders of magnitude more trades than bitcoin experiences and therefore unspent outputs must be managed better than Bitcoin.

Conclusion:
   Transaction fees must be based more upon the net gain in unspent outputs rather than the total size of the transaction.  We can 'forget' all of the inputs after enough proof of work, but the outputs we will pay for forever.   

   We want to motivate people to combine dust and this can be done in two ways, reduced trx fees *and* not paying dividends below a certain threshold. 

   We must recover old transactions and force people to keep all outputs 'current' to limit the amount of 'dividend history' that must be maintained.  At the very least, any dividends that go unclaimed for more than 1 or 2 years could be 'forfeited' and thus all outputs must be spent every 2 years or they lose their dividends.   Though a more 'pro-active' approach of 'taxing' 2+ year old outputs and paying them out as dividends would serve to keep all outputs current and recover value lost to lost private keys.   This 'tax' can be thought of as an 'inactivity fee' that banks charge accounts and as a means of reimbursing the network for holding on to your unspent output for a very long time which has significant costs when you factor in the total number of nodes that must replicate and index that output. 

   The chain must support 'cross-chain' trading to allow parallel BitShare chains to develop that enable trading in a wider range of currencies, stocks, and commodities as well as higher volumes than could ever be supported by a single chain.    Thus when the transaction fees get too high on one chain, the market can create a new parallel chain that complements the existing chain.  Because every chain enables trading any asset type it is easy to synchronize value between the chains with only a subset of nodes performing arbitrage roles.

While BitShares is the only proposal that I know of to have a dividend component, the unspent output scalability issue as well as the O(N^2) trading pairs and higher transaction volumes will mean that any block-chain based approach will need to have an efficient mechanism to 'go-parallel'.     

  Addressing these scalability issues is a critical component.