Topic: Announcing Project Invictus: a P2P Exchange Collaboration - page 6. (Read 11191 times)

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. 

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

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.

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

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.


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


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.

This is precisely how Marketcoin works.


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.


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


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.


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?

Interesting. I may be in

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.



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.

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

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.  

This is correct. At the very least such an exchange must meet the following criterion:

http://bitcoin.stackexchange.com/questions/11116/what-is-the-definition-of-a-p2p-exchange

Just to be sure, is this about distributed, decentralized p2p exchanges as opposed to centralized ones like bitcoin.de?

Still skeptic but interested, email sent ; )

I'm in 

Ah Joel, I don't think he's going to the conference in Amsterdam this September. I guess you didn't bother clicking the link.


If I see him Chuck, I'll be sure to tell him that you said hello though.

https://twitter.com/JoelKatz

Who's David?

Lol, ok Matt. Have fun and say hello to David for me.

I guess I'll come back when something is viable then. Until then, can't wait to meet the OT guys in Amsterdam when they discuss openly with Ripple's developers about this topic. Good luck!

If there is a consensus in the workgroup about a viable p2p exchange tech, then we will make the announcement at Jeff Tucker's October C3 conference at the earliest. Any technology has to be drafted into a whitepaper, prototype source code composed and a credible cryptographer has to review the implementation for flaws.    


And a lot of people in the Bitcoin community who are passionate about education are eternally grateful for this fact. BTW at almost 2,000 students now.